Use when provisioning or changing cloud infrastructure with Terraform or Ansible — modules, remote state with S3 native locking, workspaces vs directory-per-env, common AWS patterns, idempotent Ansible roles for Debian/Ubuntu, GitOps with ArgoCD/Flux, drift detection, and Vault secret injection.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Use when provisioning or changing cloud infrastructure with Terraform or Ansible — modules, remote state with S3 native locking, workspaces vs directory-per-env, common AWS patterns, idempotent Ansible roles for Debian/Ubuntu, GitOps with ArgoCD/Flux, drift detection, and Vault secret injection.
Snowflake servers — hand-configured, undocumented, irreplaceable — cause outages nobody can recover from. IaC puts environments in version-controlled code, making drift a diffable artifact and rebuilds a routine operation.
§1 Terraform Fundamentals
Terraform's core blocks:
Block
Role
terraform
required_providers, required_version, backend.
provider
Configures a provider (aws, google, kubernetes, helm, vault).
resource
Declares a managed object (e.g. aws_instance, aws_s3_bucket).
data
Reads existing infrastructure without managing it.
variable / output
Input/output contract of a configuration or module.
locals
Computed expressions reused inside the config.
module
Composition: include another configuration.
Pin provider and Terraform versions — a minor provider bump can silently change resource behaviour.
For a full VPC + ECS + RDS + S3 lifecycle example see references/aws-patterns.md.
§2 State Management
Never commit terraform.tfstate to Git — it stores secrets in plaintext and creates merge conflicts. Use a remote backend with locking.
The HashiCorp S3-backend documentation is explicit on locking:
Locking can be enabled via S3 or DynamoDB. However, DynamoDB-based locking is deprecated. To enable S3 state locking directly, use the use_lockfile argument (set to true).
The legacy dynamodb_table argument requires a table whose partition key is LockID of type String. New configurations should use use_lockfile = true; existing configurations may run both during transition.
Backend choice:
Backend
When
Locking
S3 + use_lockfile = true
AWS-hosted, current best practice
Native S3 conditional writes
S3 + dynamodb_table
Legacy; existing configs
DynamoDB partition key LockID (string)
GCS
GCP-hosted projects
Native object generation locking
Terraform Cloud / Enterprise
Hosted, team workflows
Built in
Importing existing infrastructure:
# Bring an existing AWS S3 bucket under Terraform management
terraform import aws_s3_bucket.assets acme-prod-assets
# Then write the resource block to match — terraform plan should show no diff.
terraform state list
terraform state show aws_s3_bucket.assets
terraform state rm aws_s3_bucket.assets # untrack without destroying
Split state per blast-radius boundary — network/, data/, app/ — and cross-reference outputs through terraform_remote_state. See references/terraform-modules-state.md.
§3 Module Design
A module is a directory of .tf files consumed via module "name" { source = "..." }. Pin to an exact Git tag — main can break you on any push.
Composability rule of thumb: a module should do one thing — a network, a database, a service. Avoid the "everything module" — it forces consumers to accept defaults they cannot opt out of. Deeper input/output contract patterns in references/terraform-modules-state.md.
§4 Workspaces and Environments
Pattern
When to use
Trade-off
terraform workspace (named workspaces, single backend key path)
Lightweight per-env separation in the same configuration
Easy to apply to the wrong env; small blast radius only.
Directory per environment (envs/dev, envs/staging, envs/prod) with separate backends
Strong isolation; each env has its own state
More duplication; manage with module composition.
Terragrunt-style stacks
Many envs / regions, DRY backend config
Extra tool to learn.
For production SaaS, prefer directory-per-env with module composition. For small projects, workspaces are fine:
When prod must live in a separate AWS account, directory-per-env is mandatory — workspaces share backend credentials.
§5 Ansible for Debian/Ubuntu
The Ansible playbook documentation defines the model:
A playbook consists of one or more "plays" in an ordered list. Each play executes part of the overall goal of the playbook, running one or more tasks. Each task calls an Ansible module.
Each play needs hosts (the targeted managed nodes) and at least one task. Plays and tasks execute top-to-bottom; each task runs against all matched hosts before the next task starts.
Minimum nginx role and inventory:
# inventories/prod/hosts.ini[web]
web1.example.com
web2.example.com
[debian:children]
web
[debian:vars]ansible_user=deploy
ansible_python_interpreter=/usr/bin/python3
Idempotency rule: running the playbook ten times leaves the system identical to running it once. Ansible modules are idempotent by default; raw shell commands are not — use ansible.builtin.file, apt, template, systemd, and only fall back to command/shell with explicit changed_when and failed_when.
Variable precedence (most-specific wins): -e > task > block > role > play > host > group > role defaults. Dry-run before prod with ansible-playbook -i inventories/prod site.yml --check --diff.
For role layout, dynamic AWS inventory, dependency declarations, and a baseline Ubuntu hardening playbook (ufw, fail2ban, unattended-upgrades, deploy user, SSH keys), see references/ansible-debian.md.
§6 GitOps — ArgoCD and Flux
The Git repo is the single source of truth; a controller continuously reconciles the live cluster to match.
ArgoCD's documented model:
Argo CD continuously monitors running applications and compares the current, live state against the desired target state (as specified in the Git repo). Applications that deviate from this target configuration are flagged as OutOfSync.
ArgoCD syncPolicy fields:
Field
Effect
automated.enabled
Activate automated sync.
automated.prune: true
Automatically delete resources removed from Git.
automated.selfHeal: true
Re-sync when the live cluster state deviates from Git.
automated.allowEmpty
Permit applications with empty manifests when pruning.
retry.refresh
Refresh on new revisions during sync retries.
ArgoCD also supports PreSync, Sync, and PostSync hooks for blue/green and canary rollouts, plus ApplicationSet for multi-cluster fan-out.
Flux is multi-controller and headless:
Controller
Role
source-controller
Watches Git/OCI/Helm repositories and produces an artifact for other controllers.
kustomize-controller
Reconciles Kubernetes resources from Kustomize overlays.
helm-controller
Ensures the state of the Helm release matches what is defined in the resource, performs a release if this is not the case.
notification-controller
Manages alerts, events, and outbound webhooks.
Image automation controllers
Detect new images and update Git automatically.
Decision rubric:
Need
Choice
First-class web UI for app teams
ArgoCD
Tight Helm + Kustomize integration with separable controllers
Flux
Image-update-driven promotion across environments
Flux (image-automation controllers)
ApplicationSet / multi-cluster fan-out
ArgoCD
Drift detection: ArgoCD flips Application to OutOfSync natively. For Terraform-managed resources, schedule terraform plan -detailed-exitcode every 6 hours and alert on exit code 2. Concrete manifests, bootstrap commands, and notification wiring live in references/gitops-argocd-flux.md.
§7 Terraform vs Ansible Decision Matrix
Dimension
Terraform
Ansible
Primary purpose
Provisioning cloud resources, declarative with a state file.
Server configuration and change application — procedural-feeling but idempotent modules.
Lifecycle model
Plan/apply against state; destroy is first-class.
Run-to-converge; no state file.
Best at
"Make these cloud resources exist."
"Make these existing servers look like this."
Worst at
Imperative, ordered changes on existing servers.
Tracking desired vs actual state of cloud resources at scale.
Idempotency model
State file plus provider plan.
Module-level idempotency checks.
Rule of thumb: Terraform creates the VPS; Ansible configures it. For Kubernetes, GitOps replaces both — Terraform creates the cluster, ArgoCD or Flux reconciles workloads from Git.
In practice the two cooperate: Terraform creates the EC2 instance and emits its IP into an Ansible inventory; Ansible installs nginx, users, firewall rules.
§8 Secrets at the IaC Boundary
Risks:
Secrets read by Terraform end up in plaintext inside the state file. Treat the state backend as a sensitive store — encrypt at rest, restrict IAM/ACL access, version the bucket.
sensitive = true on a variable or output suppresses console echo but does not encrypt state.
Ansible Vault encrypts variable files at rest, but the playbook process sees plaintext at runtime — secure the runner and the SSH path.
Patterns:
Pattern
Tooling
Notes
Pull at apply time from HashiCorp Vault
vault provider in Terraform; community.hashi_vault in Ansible
For Ansible, run a Vault Agent sidecar that renders secrets into /etc/app/db.env and have a systemd unit source it; the playbook installs the agent, never the secret. Cross-reference: cicd-devsecops covers Vault PKI, dynamic secrets, key rotation, and encryption-at-rest. This skill only handles the IaC entry point.
