Ansible — Infrastructure as Code ohne Agenten

Zwanzig Server, jeder anders konfiguriert. Dokumentation nur im Kopf eines einzigen Admins. Wenn er in den Urlaub fährt, weiß niemand, wie man einen Server einrichtet. Infrastructure as Code mit Ansible hat das geändert — Server werden in YAML definiert und in Git versioniert.

Warum Ansible¶

Agentless: Ansible kommuniziert über SSH. Kein Agent auf den Servern, kein Daemon, keine zusätzliche Infrastruktur. Puppet und Chef erfordern einen Agenten — weitere Software, die gewartet werden muss. YAML: Playbooks in lesbarem YAML. Kein Ruby (Chef) oder DSL (Puppet).

Playbook-Beispiel¶

---
- hosts: webservers
  become: yes
  tasks:
    - name: Install Nginx
      apt: name=nginx state=latest
    - name: Deploy config
      template: src=nginx.conf.j2 dest=/etc/nginx/nginx.conf
      notify: Restart Nginx
    - name: Ensure running
      service: name=nginx state=started enabled=yes
  handlers:
    - name: Restart Nginx
      service: name=nginx state=restarted

Idempotenz und Roles¶

Jeder Task ist idempotent — führen Sie das Playbook 10-mal aus und das Ergebnis ist dasselbe. Roles organisieren Logik in wiederverwendbare Pakete: Role nginx, Role postgresql, Role java. Ansible Galaxy zum Teilen von Community-Roles.

Inventory und dynamisches Inventory¶

Statisches Inventory für feste Server. Für Cloud-Umgebungen ein dynamisches Inventory-Skript, das die AWS/Azure-API abfragt und die aktuelle Serverliste zurückgibt.

Server als Code¶

Ansible ist der zugänglichste Weg zu Infrastructure as Code. Agentless, YAML, SSH. Die Serverdokumentation lebt in Git; Onboarding bedeutet, das Playbook zu lesen.