Felsöka vanliga problem när du använder Terraform på Azure

Den här artikeln innehåller vanliga problem och möjliga lösningar när du använder Terraform på Azure.

Om du stöter på ett problem som är specifikt för Terraform använder du en av HashiCorps community-supportkanaler.

• Det går inte att lista providerns registreringsstatus
• VPN-fel

HashiCorp Terraform-specifika supportkanaler

• Frågor, användningsfall och användbara mönster: Terraform-avsnittet i HashiCorp-communityportalen
• Frågor, användningsfall och användbara mönster: Terraform-avsnittet i HashiCorp-communityportalen

Det går inte att lista providerns registreringsstatus

Felmeddelande:

Fel: Det går inte att lista providerns registreringsstatus. Det här felet kan inträffa på grund av ogiltiga autentiseringsuppgifter eller på grund av att tjänstens huvudnamn inte har behörighet att använda Resource Manager-API:et. Azure fel: resurser. ProvidersClient#List: Det gick inte att svara på begäran: StatusCode=403 – Ursprungligt fel: autorest/azure: Tjänsten returnerade ett fel. Status=403 Code="AuthorizationFailed" Message="Klienten '00000000-0000-0000-0000-000000000000' med objekt-ID '00000000-0000-0000-0000-000000000000' har inte behörighet att utföra åtgärden 'Microsoft.Resources/subscriptions/providers/read' för omfånget '/subscriptions/00000000-0000-0000-0000-000000000000' eller så är omfånget ogiltigt." Uppdatera dina autentiseringsuppgifter om åtkomsten beviljades nyligen."

Bakgrund: Om du kör Terraform-kommandon från Cloud Shell och definierar vissa Terraform/Azure miljövariabler kan det uppstå konflikter. I följande tabell visas miljövariablerna och de Azure värden som de representerar:

Orsak: När detta skrivs skriver Terraform-skriptet som körs i Cloud Shell över miljövariablerna ARM_SUBSCRIPTION_ID och ARM_TENANT_ID med hjälp av värden från den aktuella Azure-prenumerationen. Som ett resultat misslyckas Terraform-åtgärderna om tjänstens huvudobjekt som miljövariablerna refererar till inte har behörighet till den aktuella Azure-prenumerationen.

Fel vid hämtning av statuslås

Felmeddelande:

Fel: Fel vid hämtning av tillståndslåset; Felmeddelande: 2 fel inträffade:
* En statusblob är redan låst
* blobmetadata "terraformlockid" var tom
Terraform skaffar ett state-lås för att skydda state så att det inte skrivs av flera användare samtidigt. Lös problemet ovan och försök igen. För de flesta kommandon kan du inaktivera låsning med flaggan "-lock=false", men detta rekommenderas inte.

Bakgrund: Om du kör Terraform-kommandon mot en Terraform-tillståndsfil och det här felet är det enda meddelandet som visas kan följande orsaker gälla. Det här felet gäller lokala filer och fjärrtillståndsfiler.

Orsak: Det finns två möjliga orsaker till det här felet. Den första orsaken är att ett Terraform-kommando redan körs mot tillståndsfilen och har låst filen, så att inget går sönder. Den andra potentiella orsaken är att ett anslutningsavbrott inträffade mellan tillståndsfilen och CLI när kommandon kördes. Det här avbrottet inträffar oftast när du använder fjärrtillståndsfiler.

Lösning: Kontrollera först att du inte redan kör några kommandon mot tillståndsfilen. Om du arbetar med en lokal tillståndsfil, kontrollera om du har några terminalfönster där kommandon körs. Du kan också kontrollera dina distributionspipelines för att se om något som körs kan använda tillståndsfilen. Om det här villkoret inte löser problemet är det möjligt att den andra orsaken utlöste felet. För en fjärrlagrad tillståndsfil som lagras i en container i ett Azure Storage-konto kan du leta reda på filen och använda knappen Bryt lease.

Om du använder andra backend-lösningar för att lagra din tillståndsfil, finns rekommendationer i HashiCorp-dokumentationen.

VPN-fel

Information om hur du löser VPN-fel finns i artikeln Felsöka en VPN-hybridanslutning.

Terraform planerar att ta bort och återskapa ett lagringskonto

Terraform kan planera att ta bort och återskapa ett Azure lagringskonto när Azure har ändrat lagringskontot utanför Terraform. Det här beteendet kan inträffa under en konvertering av redundans för ett Azure Storage-konto som stöds, där account_replication_type går över gränsen mellan den icke-zonbaserade uppsättningen (LRS, GRS, RA-GRS) och den zonbaserade uppsättningen (ZRS, GZRS, RA-GZRS).

Innan du tillämpar planen granskar du de föreslagna ändringarna och bekräftar varför Terraform anser att lagringskontobytet är nödvändigt. Om du återskapar ett lagringskonto kan det orsaka programavbrott eller dataförlust.

Så här minskar du risken:

• Inaktivera automatiskt godkännande för distributioner som hanterar lagringskonton och granska varje terraform plan.
• Konfigurera prevent_destroy = true i lagringskontoresursens lifecycle block.
• Innan du påbörjar konverteringen lägger du tillfälligt till account_replication_type i ignore_changes.
• Efter konverteringen kör du terraform apply -refresh-only för att uppdatera Terraform-tillståndet och uppdaterar sedan Terraform-konfigurationen så att den matchar det distribuerade lagringskontot.
• Ta bara bort ignore_changes när du har kört terraform plan och bekräfta att det inte rapporterar några oväntade ändringar.

Detaljerad konverteringsvägledning finns i Förhindra Terraform-drift för tillståndskänsliga Azure resurser.