Was Netflix montags macht… Part III – Sprint 0

Wer nochmal sein Gedächtnis auffrischen will, hier geht’s zu Teil 1 und Teil 2. Heute wird’s allerdings deutlich technischer 😉.

In der agilen Entwicklung wird der Sprint 0 gerne als Proof-of-Concept genommen, ergo: Funktionieren die Technologien in der angedachten Zusammenstellung? Ich hatte ja versprochen, einen kleinen Prototyp zu bauen, ausgesucht als Technologie habe ich mir Saltstack. Als Beispiel dient die Installation von Docker in eine virtuelle Maschine (Ich glaube, ich werde das nochmal in einem weiteren Beitrag brauchen.).

Über die Grundstruktur von Saltstack kann man alles in der Doku und in diversen anderen Blogs lesen (siehe auch Quellen in Teil 2). Ich baue das ganze Masterless, weil ich es in dieser Form auch häufiger in der Entwicklung von Software benötige (z.B. um mir eine Entwicklungs-/Test-/Produktivumgebung aufzusetzen). Letztlich relevant ist also nur der State für Docker, der aus drei Teilen besteht:

docker_gpg_key:
  cmd.run:
    - name: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

==> Lädt den gpg-Key herunter und fügt ihn der lokalen Paketverwaltung hinzu

docker_repo_managed:
  pkgrepo.managed:
    - humanname: Docker
    - name: deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable

==> Prüft, ob in der lokalen Paketverwaltung docker als Quelle hinzugefügt ist

docker_installed:
  pkg.installed:
    - name: docker-ce

==> Prüft, ob Docker installiert ist

Anschließend noch ein Top-File erstellen:

base:
  '*':
    - docker

Und schon kann man den State „ausführen“, indem man in das Verzeichnis wechselt, in dem das Top-File liegt und in einem (Ubuntu-)Terminal folgendes ausführt:

salt-call --local state.apply docker

Man kann hier sicherlich noch einiges akkurater machen: Ubuntu ist hartcodiert angegeben, curl wird direkt ausgeführt statt eines deskriptiven Vorgehens etc., aber es geht ja hier um die grundlegenden Züge.

Auch wenn dem einen oder anderen die Technik hier recht kryptisch ist, so haben wir damit doch etwas sehr Wertvolles geschaffen, ohne dabei eine eigene Programmiersprache zu lernen (wir brauchen nur YAML und die Salt-Doku) oder auf dem Server x-Pakete zu installieren, damit das Ganze läuft. Auf diese Art kann man nämlich identische Umgebungen schaffen, die vollständig automatisiert (und damit testbar) erstellt werden können. Das löst u.a. das Problem „works for me“ und gibt enorme Geschwindigkeitsvorteile, da ein hoher Grad an Wiederverwendung erreicht werden kann.

Wer mitspielen will, findet hier als Zip-Datei alles Nötige, um den Prototyp lokal ausführen zu können. Eine tiefergehende Bewertung des Vollbrachten nehmen in wir dann in Teil 4 vor, bis dann…