In meinem Terraform-Beitrag erzählte ich von einem dramatischen und vor allem stressigen Ereignis, dass sich so ähnlich auch tatsächlich abgespielt hat. Im Grunde war der Einsatz mitten in der Nacht und das manuelle Wiederherstellen eines Servers auch der Startschuss vor einigen Jahren, sich mit dem Thema Automatisierung in der IT-Infrastruktur zu beschäftigen. Meist braucht es Grenzerfahrungen und der Schmerz muss groß werden, damit man tatsächlich Änderungen herbeiführt.

Nachdem ich also von Terraform berichtet habe, wie man damit die Basisinfrastruktur seines IT Betriebs steuern kann, habe ich die Frage offen gelassen, wie es jetzt weiter geht, denn am Ende des Artikels hatten wir einen (oder mehrere) laufende Server, aber die verrichten noch keine nutzbringende Arbeit. Nach dem Setup eines Servers muss also die benötigte Software installiert, Benutzer angelegt, Berechtigungen konfiguriert und die Sicherheitsmaßnahmen angewendet werden.

Für diese Aufgaben gibt es mittlerweile eine große Anzahl an Tools - einige von ihnen gibt es schon seit vielen Jahren - hier eine kurze Auflistung der bekanntesten Tools aus dem Open Source Bereich:

Im kommerziellen Umfeld und im Bereich SaaS-Systeme gibt es eine noch wesentlich größere, fast schon unüberschaubare Anzahl an Werkzeugen. All diese Systeme arbeiten nach einem ähnlichen Prinzip. Man schreibt Scripte (entweder in "echten" Programmiersprachen wie Ruby oder Bash Scripting, oder aber man schreibt in Beschreibungssprachen wie "yaml"). Diese Scripte werden vom entsprechenden System ausgeführt und die Provisionierung des Servers beginnt. Im Detail unterscheiden sich die Systeme erheblich. Einige benötigen einen Remote Zugriff auf den Server, bei manchen muss zuvor schon das Tool installiert sein (Henne-Ei-Problem).

Im Bereich der Cloud Server hat sich ein weiteres Tool als sehr nützlich erwiesen: cloud-init. Dabei handelt es sich um einen Industriestandard, der zunächst vom Ubuntu Hersteller Canonical vorgestellt wurde. Alle großen Cloud Provider wie

  • Amazon
  • Microsoft
  • Google
  • DigitalOcean
  • Hetzner
  • u.v.a.m.

unterstützen diesen Standard. Dabei wird beim Erstellen eines Cloud Servers ein cloud-init Script mitgeschickt, das Anweisungen enthält, was beim ersten Systemstart oder bei jedem Bootvorgang des Servers passieren soll. So kann mit diesem Tool das oben erwähnte Henne-Ei Problem gelöst werden, um die notwendige Software für z. B. Puppet einzurichten. Basierend auf den Basis Installationen des Cloud Anbieters kann man somit alle eigenen Cloud Server Instanzen nach dem immer gleichen Schema aufsetzen.

Hier ein Beispiel einer cloud-init Steuerdatei:

#cloud-config
apt:
  sources:
    docker.list:
      source: 'deb [arch=amd64] https://download.docker.com/linux/debian buster stable'
      keyid: 9DC858229FC7DD38854AE2D88D81803C0EBFCD88
packages:
  - ufw
  - curl
  - unzip
  - apt-transport-https
  - ca-certificates
  - software-properties-common
  - gnupg2
  - docker-ce
  - docker-ce-cli
  - containerd.io
package_update: true
package_upgrade: true
users:
  - name: consul
    shell: /bin/false
    system: true
  - name: vault
    shell: /bin/false
    system: true
  - name: nomad
    shell: /bin/false
    system: true
runcmd:
  - mkdir -p /etc/consul.d/certs
  - mkdir -p /var/lib/consul
  - mkdir -p /run/consul

Nachdem wir auf so gut wie allen Systemen Docker, eine lokale Firewall und Consul/Vault/Nomad für die das Management und die Steuerung unserer Cluster verwenden, werden diese Tools damit installiert und die entsprechenden Systembenutzer vorbereitet. Auch Tools für die Netzwerküberwachung, das Zertifikatsmanagement und das Paketmanagement können mit cloud-init sofort bei der Anlage eines Servers installiert werden. Wie das oben angeführte Beispiel zeigt, ist die Konfiguration sehr einfach, jedoch für manche Anwendungszwecke auch etwas zu eingeschränkt. Daher verwenden wir cloud-init als Ergänzung zu Ansible (das Tool, das wir für das weitere Provisionieren verwenden).

Übrigens wird cloud-init auch z. B. in OpenShift, VMWare oder Proxmox unterstützt und kann somit auch im eigenen Rechenzentrum verwendet werden. Damit lassen sich automatisiert identische Cloud Server an die eigenen Bedürfnisse anpassen. Für uns ist cloud-init zu einem wichtigen Helfer geworden, um unsere "Imutual Infrastructure" Strategie umzusetzen und lässt sich perfekt in unsere Toolchain rund um Terraform und Ansible einsetzen.

Ansible? Imutual Infrastructure? Schon wieder so spät? Das verlangt nach einem weiteren Beitrag in meiner "Code your Infrastructure" Reihe...