Infrastructure as Code: Terraform, Ansible

Infrastructure as Code: Terraform, Ansible

1) Warum IaC und wie sich die Werkzeuge unterscheiden

Terraform - declarative orchestrator-IaC: erstellt/ändert eine Cloud-Infrastruktur (VPC, K8s, LB, DB, IAM) über Provider. Verwaltet den Lebenszyklus von Ressourcen und speichert den Status.
Ansible - prozedurales config-IaC und Konfigurationsmanagement: konfiguriert Hosts/Software (Pakete, Dateien, Dienste), kann Anwendungen sehen, Templeating, Orchestrierung von Schritten. Ohne Agent (SSH/WinRM), mit Idempotenz der Aufgaben.

Die Kombination: Terraform - „woraus die Plattform besteht“, Ansible - „wie sie aufgebaut ist und läuft“.

2) Aufbau von Repositories und Layern

1. Foundation (Landing Zone): Netzwerke, IAM, KMS, Basisprotokolle/Monitoring.

2. Plattform: Kubernetes-Cluster, Basen, Warteschlangen, Observability-Stack.

3. Workloads: Räume/Neymspaces, Servicekonten, Richtlinien, Configs.

• „iac/terraform/“ - Module und Umgebungen („ modules/“, „envs/“).
• „iac/ansible/“ - Rollen („ roles/“), Playbooks („playbooks/“), Inventar („ inventories/“).
• „policies/“ - OPA/Conftest-Regeln.
• „pipelines/“ - CI/CD-Skripte (lint/plan/apply/test).

3) Terraform: Module, Staat, Umgebungen

3. 1 Module

Kleine, wiederverwendete: „vpc“, „eks“, „rds“, „redis“, „alb“, „iam-role“.
Eingänge → 'variables. tf', die Ausgänge → 'outputs. tf', Versionen - über die Registrierung von Modulen/git-Tags.

hcl module "vpc" {
source = "git::ssh://git@repo/iac. git//modules/vpc? ref=v1. 6. 0"
name  = "prod-core"
cidr  = "10. 0. 0. 0/16"
azs  = ["eu-central-1a","eu-central-1b"]
}

3. 2 Zustand (Zustand)

Remote Backend (S3/GCS + DynamoDB/LockTable) + Sperren.
Einteilung nach Umgebung: 'prod. tfstate`, `staging. tfstate`.
State-drift: „terraform plan“ in CI nach Zeitplan; alert beim Driften.

hcl terraform {
backend "s3" {
bucket     = "iac-state"
key      = "prod/network/terraform. tfstate"
region     = "eu-central-1"
dynamodb_table = "iac-locks"
encrypt    = true
}
}

3. 3 Workspaces / Envs

• Die einzelnen Verzeichnisse' envs/prod', 'envs/stage' (übersichtlich).
• Workspaces für leichte Variationen, aber vermeiden Sie das Mischen von Geheimnissen.
• Parameter über 'tfvars': 'prod. tfvars`, `stage. tfvars`.

4) Ansible: Rollen, Inventar, Idempotenz

4. 1 Rollen und Playbooks

roles/
nginx/
tasks/main. yml templates/.j2 handlers/main. yml defaults/main. yml playbooks/
site. yml

yaml
- hosts: web become: true roles:
- role: nginx vars:
nginx_listen_port: 8080

4. 2 Inventar und Dynamik

`inventories/prod/hosts. yml'+ Variablen 'group _ vars/host _ vars'.
Dynamisches Inventar: 'aws _ ec2', 'gcp _ compute', 'kubernetes. core`.

4. 3 Idempotenz

Verwenden Sie Module (nicht 'shell') wo möglich.
'changed _ when '/' check _ mode' für Trockenläufe.
Handler reflektieren nur, wenn sie wechseln.

5) Geheimnisse und Configs

Terraform: Sekretion von Werten durch 'sensitiv = wahr'; Die Geheimnisse selbst befinden sich nicht im Staat (speichern Sie im AWS Secrets Manager/HashiCorp Vault/KMS und beziehen Sie sich auf die Datenquelle).
Ansible: Vault zur Verschlüsselung von Variablen ('ansible-vault encrypt'), Integration mit HashiCorp Vault/KMS.
GitOps: Geheimnisse in einem separaten Repo/Tresor, Zugriff durch Least-Privilege.

6) Richtlinien und Compliance (Policy as Code)

OPA/Conftest für Terraform Pläne: Verbot von öffentlichen S3, offene SG, unmarkierte Ressourcen (Tags).
Terraform Cloud/Enterprise - Sentinel als Alternative.
Ansible Lint: Stil und Sicherheit (ohne' sudo: yes' wo nicht notwendig, ohne raw-shell).

rego package terraform. security

deny[msg] {
input. resource_type == "aws_security_group_rule"
input. values. cidr_blocks[_] == "0. 0. 0. 0/0"
input. values. from_port == 22 msg:= "SSH from 0. 0. 0. 0/0 is forbidden"
}

7) IaC-Prüfung

Terraform: 'tflint',' tfsec'/' checkov', Terratest (Go) für Integrationsprüfungen.
Ansible: 'ansible-lint', Molecule (+ Docker/Podman/EC2) zum Überprüfen der Rollen.
Smoke-Tests nach Anwendung: HTTP-Proben, Port/Prozesse, Rechte.

8) CI/CD и GitOps

1. Lint/Sec: tflint, tfsec/checkov, ansible-lint.

2. Plan: 'terraform plan' mit Veröffentlichung des Artefakts (Kommentar in MR).

3. Policy Gate: Conftest/Sentinel.

4. Apply (manual/approved): nur auf main mit der Signatur der Artefakte.

5. Ansible deploy: '--check' auf der Bühne, dann '--diff' in prod.

6. Post-checks: synthetics/Probe, dashboard release annotation.

• Bewahren Sie Manifeste als Quelle der Wahrheit auf; Argo CD/Flux für Kubernetes, aber die grundlegenden Cluster/Primitive sind über Terraform.

9) Muster für Kubernetes, Netze, DB

9. 1 Kubernetes

Terraform: EKS/GKE/AKS Cluster, Knoten, IAM, StorageClass, LB.
Ansible: Vorbereitung von AMIs/Bastionen, Montage von Images/Repositories, Post-Install (Logger/Agenten/OTel).

9. 2 Netzwerke und Perimeter

Terraform: VPC/Subnetze/NAT/Transit-Gateway/WAF, Routen.
Ansible: config NGINX/Envoy/HAProxy, TLS, config WAF Regeln.

9. 3 Basen/Caches/Warteschlangen

Terraform: RDS/CloudSQL-Parametergruppen, Redis/ElastiCache, Kafka/MSK.
Ansible: Cache-Aufwärmen, Migrationsaufträge, Konfiguration von Backups/Agenten.

10) Beispiele für Config

10. 1 Terraform — RDS PostgreSQL + SG

hcl module "db" {
source        = "terraform-aws-modules/rds/aws"
engine        = "postgres"
engine_version    = "15. 4"
instance_class    = "db. m6g. large"
allocated_storage  = 100 name         = "core"
username       = var. db_user password       = var. db_password # см. secret data source vpc_security_group_ids = [module. db_sg. security_group_id]
multi_az       = true backup_retention   = 7
}

module "db_sg" {
source = "terraform-aws-modules/security-group/aws"
name  = "db-core"
vpc_id = module. vpc. vpc_id ingress_cidr_blocks = ["10. 0. 0. 0/8"]
ingress_rules    = ["postgresql-tcp"]
}

10. 2 Terraform - Datenquelle des Geheimnisses

hcl data "aws_secretsmanager_secret_version" "db" {
secret_id = "prod/db/core"
}
variable "db_password" {
type   = string sensitive = true default  = jsondecode(data. aws_secretsmanager_secret_version. db. secret_string). password
}

10. 3 Ansible - die Rolle des postgresql-Clients (Fragment)

yaml
- name: Install packages apt:
name: [ "postgresql-client-15" ]
state: present update_cache: yes

- name: Create. pgpass copy:
dest: /home/deploy/.pgpass mode: '0600'
content: "{{ db_host }}:5432:core:{{ db_user }}:{{ db_password }}"
no_log: true

- name: Smoke query shell: psql -h {{ db_host }} -U {{ db_user }} -d core -c "select 1"
register: psql_out changed_when: false

10. 4 Ansible - NGINX mit Template

yaml
- name: Deploy nginx. conf template:
src: templates/nginx. conf. j2 dest: /etc/nginx/nginx. conf notify: Restart nginx

- name: Ensure nginx running service:
name: nginx state: started enabled: true

handlers:
- name: Restart nginx service: { name: nginx, state: restarted }

11) Drift- und Compliance-Management

Periodischer 'terraform plan' im read-only Schlüssel; erstellt ein Ticket bei einer Diskrepanz.
Ansible --check nach Zeitplan für kritische Rollen (Audit-Modus).
Berichte: OPA/Conftest-Richtlinien nicht erfüllt, Ressourcen ohne Tags/Backup/Überwachung.

12) Beobachtbarkeit und Audit

'terraform apply' -Protokolle und Planartefakte - im Objektspeicher speichern.
Ansible: 'callback _ plugins' (json) → zentrales Log/ELK; Aktivieren Sie Job-ID, Commit SHA, trace_id.
Metriken: Ausführungszeit der Pläne/Playbooks, Änderungshäufigkeit, Testabdeckung.

13) Sicherheit

Signieren Sie Module/Rollen oder feste Tags/Hashes.
Minimale IAM-Rechte ('plan' ≠ 'apply'), trennen Sie die Rollen von CI und Appruver-Person.
Status-/Logverschlüsselung, private Modul-/Rollenregister.
Politik „keine plaintext Geheimnisse in VCS“, geheime Scanner (gitleaks/trufflehog).

14) Anti-Muster

Ein Terraform-Monster „für alles“; keine Modulversionen.
Lokal 'terraform. tfstate' und keine Sperren.
Manuelle Änderungen in der Cloud über IaC → ewige Drift.
Ansible' shell '/' command 'anstelle von Modulen (bricht Idempotenz).
Inventar „in einer Datei“ ohne Gruppen/Variablen, Mischung prod/stage.
Geheimnisse in vars/repository, kein Vault/KMS.
Bewerben Sie sich ohne Plan und ohne Peer Review.

15) Implementierung Checkliste (0-45 Tage)

0-10 Tage

Konfigurieren Sie Remote Backend/Lock, erweitern Sie Terraform-Module.
Aktivieren Sie tflint/tfsec/checkov, ansible-lint; verhandeln über Ressourcen-Tags/Labels.
Starten Sie Ansible Rollen für NGINX/Agenten/Logger; organisieren Inventar.

11-25 Tage

Fügen Sie Conftest/OPA, Terratest und Molecule für kritische Module/Rollen hinzu.
CI: 'plan' auf MR, Artefakt des Plans, manuelle Anwendung mit Appruv; Ansible `--check` на stage.
Integration von Secret Storage (Vault/KMS/Secrets Manager).

26-45 Tage

Auto-Plan nach Zeitplan für Drift-Detect, Berichte über Richtlinien.
Modul-/Rollenkatalog mit Versionierung; Dokumentation 'README. md 'in jedem.
GitOps: Release-Annotationen, Verknüpfung mit Monitoring und Alert-Gates.

16) Reifegradkennzahlen

% der Umgebungen mit Remote-Status und Locs = 100%.
Der Anteil der Module/Rollen mit Tests (Terratest/Molecule) ≥ 70%.
Die durchschnittliche Zeit von MR bis apply (prod) ist Stunden, nicht Tage.
Null „manuelle Drift“ (alle Änderungen gehen über MR).
100% der kritischen Ressourcen werden durch Policy as Code (Tags, Verschlüsselung, Backup) abgedeckt.

17) Fazit

Terraform legt eine vorhersehbare, wiederholbare Infrastruktur-Basis fest; Ansible bringt Hosts und Services in den gewünschten Zustand. Fügen Sie Policy as Code, Remote State mit Standort, Tests, Secret Management und CI/CD mit plan→review→apply hinzu - und Ihre IaC-Schleife wird überschaubar, sicher und schnell und die Releases sind atomar und reversibel.