Twee mensen draaien tegelijk terraform apply en de state is corrupt
Remote state met locking is verplicht zodra je met meer dan één persoon werkt. S3+DynamoDB voor AWS, Storage Account voor Azure, GCS voor GCP. Eén keer instellen, daarna nooit meer een race-condition.
support/cloud-platforms/terraform-state-locking-dynamodbstappen: 5
Probeer dit eerst zelf
- Maak een S3-bucket met versioning aan voor je state-files. Een aparte bucket per environment scheelt blast-radius.
- Maak een DynamoDB-tabel met primary key LockID (string). Geen capacity-zorgen, on-demand billing-mode is genoeg.
- Configureer in elke Terraform-config het backend met bucket, key, region en dynamodb_table. Run terraform init -migrate-state.
- Op Azure: Storage Account met use_azuread_auth = true en lock via blob lease. Op GCP: GCS-bucket met versioning, lock-mechanisme is ingebouwd.
- Activeer state-encryption (S3 default-encryption + bucket-policy die TLS afdwingt). State bevat secrets, daar wil je AES en TLS op.
Wanneer ons inschakelen
Heb je een corrupte state-file en is import-werk nodig om resources weer op één lijn te krijgen, neem iemand erbij die terraform import dagelijks doet. Dat scheelt schade.
Zie ook
- Iedereen logt in met het root-account van AWSHet root-account is voor noodgevallen en facturatie. Dagelijks werk hoort via IAM-users of SSO.
- Iedere developer heeft AdministratorAccessAdministratorAccess overal is gemak nu, drama later. Begin met rolgebaseerde policies.
- Iedereen heeft losse IAM-users met eigen wachtwoordIdentity Center (voorheen AWS SSO) koppelt aan je IdP en geeft tijdelijke credentials per sessie.
Past het bovenstaande niet?
Beschrijf je situatie hieronder. We sturen jouw input plus de stappen die je al zag naar onze AI en geven gericht vervolg-advies. Als het te risicovol is om zelf te doen, zeggen we dat ook.
Of doe het helemaal niet zelf
Onze Managed IT-klanten zoeken dit soort vragen niet op. Eén aanspreekpunt, vaste prijs per maand, en het is binnen werktijd opgelost.