Testinfrastruktur mit Saltstack, Docker und Testinfra

Wir betreiben ein paar (virtuelle) Server, nichts Besonderes. Es ist ziemlich einfach, diese Maschinen in Schneeflocken zu verwandeln. Um dies zu verhindern, haben wir Salt eingeführt. Salt leistet gute Arbeit bei der Verteilung von Software auf Servern und deren Aktualisierung, wenn es regelmäßig ausgeführt wird. Aber wie können wir Probleme vermeiden, wenn wir die Salt-Konfiguration selbst ändern? Die Lösung ist einfach: Testen Sie!

Ich habe weder vor, meine Änderungen direkt in unserer Live-Umgebung zu testen, noch möchte ich eine solche dynamische Umgebung lokal einrichten und pflegen. Ich möchte so viel Konfiguration wie möglich unter Versionskontrolle (Git) stellen. Was ich überprüfen möchte, ist, ob die Bereitstellung einer Umgebung funktioniert und ob die wichtigsten Dienste online sind. Ich interessiere mich nicht so sehr für die einzelnen Zustände. Es ist das Gesamtergebnis, das ich überprüfen möchte. Das ist es, was in der Produktion laufen wird, das ist also der wichtige Teil. Nehmen wir an, ich möchte einen Jenkins-Master einrichten. Ich möchte meine Konfiguration so weit wie möglich lokal erstellen und testen, vielleicht sogar die Bereitstellung verschiedener Betriebssysteme testen. Möglicherweise möchte ich meine Konfiguration auf unserem CI-Server validieren. Ein Beispiel finden Sie in meinem Salt formula testing Repository auf GitHub. Ich habe eine kleine top.sls-Datei für die Salt-Umgebung erstellt: [sourcecode lang="plain"] base: 'jenkins.*':

• git
• java
• jenkins
• Knoten [/sourcecode] Und fügen Sie die erforderliche Salzformel hinzu. So weit, so gut. Von diesem Punkt an gibt es zwei Dinge, die ich tun kann:
  1. Richten Sie eine VM ein, verbinden Sie sie als Minion mit unserer Salt-Umgebung und starten Sie die Bereitstellung.
  2. Testen Sie es vor Ort.

  Sie sehen wahrscheinlich, dass die Strategie 1 einige Nachteile hat. Wenn ich die Formel ändern möchte, muss ich die VM neu bereitstellen, was an sich schon zu einer Konfigurationsabweichung führen kann. Das heißt, wenn ich mit der Konfiguration fertig bin, muss ich die VM entfernen und eine neue erstellen (und dann hoffen, dass ich nichts übersehen habe). Noch schlimmer: Ich teste in einer Live-Umgebung. Ich möchte mir gar nicht ausmalen, was passieren könnte, wenn die Umgebung mit meinen Zwischenergebnissen erneut bereitgestellt wird.

  Stattdessen erstelle ich lokal mit Vagrant eine Salt-Testumgebung (ein Segen, wenn Sie kein Linux auf Ihrem Laptop ausführen). Die Konfigurationen selbst möchte ich auf "die einfachste Art und Weise" bereitstellen: in einem Docker-Container. Ich habe erwogen, nur Vagrant-Images zu verwenden, aber Docker-Container sind viel schneller und am Ende geht es nur um das Feedback. Schließlich möchte ich sicherstellen, dass die richtigen Dienste ausgeführt werden. Im Fall dieses Beispiels ist das Jenkins, das auf Port 8080 lauscht. Hierfür verwende ich ein Tool namens Testinfra. Testinfra hat eine schöne Schnittstelle zur Testinfrastruktur und baut auf Pytest auf. Meine Prüfungen sind für den Anfang einfach: [sourcecode lang="python"] import pytest HOST_ID = "jenkins" @pytest.fixture(scope="module", autouse=True) def provision(Docker): Docker.provision_as(HOST_ID) def test_service_running(Docker): Service = Docker.get_module("Service") assert Service("jenkins").is_running def test_service_listening_on_port_8080(Docker, Slow): import time Socket = Docker.get_module("Socket") Slow(lambda: Socket("tcp://:::8080").is_listening) [/sourcecode] Die schwere Arbeit wird in conftest.py. Diese Testkonfigurationsdatei wird von Pytest standardmäßig geladen. Da ich sowieso mit Salt arbeite, kann die VM auch von Salt bereitgestellt werden. Fügen wir unsere Testkonfiguration zur top.sls hinzu: [sourcecode lang="plain"] 'salt-dev':

• Docker
• testinfra [/sourcecode] Bei dieser Konfiguration möchte ich sicherstellen, dass ich über die erforderlichen Tools (Docker und Testinfra) verfüge und ein paar Docker-Images bereithalte. Diese Images ahmen die Konfiguration der echten VMs nach. Die Ausführung der Tests wird so einfach wie möglich: [sourcecode lang="plain"] [vagrant@salt-dev test]$ testinfra -v ============================= test session starts ============================== platform linux2 -- Python 2.7.5, pytest-2.8.7, py-1.4.31, pluggy-0.3.1 -- /usr/bin/python cachedir: .cache rootdir: /srv/test, inifile: plugins: testinfra-1.0.1 4 Elemente gesammelt test_jenkins.py::test_service_running[centos7-salt-local] PASSED test_jenkins.py::test_service_listening_on_port_8080[centos7-salt-local] PASSED test_jenkins.py::test_service_running[ubuntu15-salt-local] PASSED test_jenkins.py::test_service_listening_on_port_8080[ubuntu15-salt-local] PASSED ========================== 4 bestanden in 228.02 Sekunden ========================== [/sourcecode] Ist das nicht schön? Mit wenig Aufwand kann ich komplette Salt-Rollouts überprüfen und sicherstellen, dass sie korrekt installiert sind. Auf diese Weise wurden bereits einige Regressionsfehler gefunden.

  Überlegungen

  Vielleicht möchten Sie die Tests auf Ihrem CI-Server ausführen. Das ist eine gute Idee und wird mit Sicherheit einige Regressionen aufdecken. Wie Sie sehen, müssen Sie noch ein paar Minuten warten, um zu sehen, ob alle Tests erfolgreich sind. Je nach Ihrer CI-Infrastruktur sind möglicherweise einige Anpassungen erforderlich. (Offene Frage: Wie geht man dann mit Pillar-Daten um?)

  Vielleicht möchten Sie die Skripte von den Docker-Containern entkoppeln und sie auch zur Überprüfung der Produktionsinfrastruktur verwenden. Testinfra kann in einem Format ausgeben, das von Nagios verstanden wird, was für die Überwachung von Diensten von Vorteil ist. Source Repository: Salt formula testing.