Continuous Integration und Continuous Deployment (CI/CD) sind integraler Bestandteil jedes modernen Softwareentwicklungszyklus. Ein DevOps-Engineer hat die Aufgabe, dafür zu sorgen, dass die Anwendung getestet, erstellt und ordnungsgemäß in einer QA-Umgebung bereitgestellt und/oder rechtzeitig und lauffähig an den Kunden ausgeliefert wird. Diese Pipeline läuft in der Regel mehrmals am Tag und die Ergebnisse jedes einzelnen Jobs werden sofort dokumentiert. Wenn zum Beispiel ein Unit-Test fehlschlägt oder der Code syntaktische Fehler aufweist, wird das Team sofort benachrichtigt und beginnt mit der Behebung des Problems. Nachdem das Deployment abgeschlossen ist, können potenzielle Laufzeitfehler auftreten, welche dazu führen, dass die Anwendung nicht ordnungsgemäß beendet wird. Der fehlgeschlagene Verbindungsaufbau zur Datenbank, die nicht erfolgreiche Validierung von Umgebungsvariablen und die Fehlkonfiguration von Docker-Containern sind Beispiele für Probleme, die erst nach Abschluss der CI/CD-Pipeline erkannt werden können.
Wenn Ihr System keine ausgefeilten Überwachungstools wie Prometheus und Grafana beinhaltet, kann ein einfacher Apache Airflow DAG diese Aufgabe gut übernehmen. Dieser wird alle paar Stunden ausgeführt, kann problematische Docker-Container identifizieren und einen Report erstellen, der per E-Mail an das DevOps-Team oder als Benachrichtigung an einen Google-Space-Gruppenchat gesendet wird. Im Folgenden betrachten wir, wie ein solcher DAG implementiert werden kann.
Unsere Beispielapplikation besteht aus einer REST-API und einer Postgres-Datenbank. Dieses Paar wird jedes Mal in der QA-Umgebung bereitgestellt, wenn wir einen Merge Request eröffnen, und sie werden erneut bereitgestellt, wenn neue Commits verfügbar sind. Allen Containernamen wird der Projektname vorangestellt (in diesem Beispiel "my-project"), gefolgt vom Namen des Git Branches.
Zunächst entwickeln wir zwei Shell-Skripte, um nicht ordnungsgemäß beendete und neu startende Container zu identifizieren. Glücklicherweise kann dies durch die Nutzung der leistungsstarken Docker-CLI und des Grep-Tools erreicht werden.
collect_exited_containers.sh
#!/bin/bash
docker ps -a --filter 'status=exited' --format '\t\t\t\t' | grep -v 'Exited (0)' | grep “my-project”
collect_restarting_containers.sh
#!/bin/bash
docker ps -a --filter 'status=restarting' --format '\t\t\t\t' | grep nexthub
Die Skripte filtern alle Docker-Container auf der Grundlage ihres Status (beendet oder neu gestartet), formatieren die Ausgabe und wählen nur diejenigen aus, die mit unserem Projekt verbunden sind. Beachten Sie, dass wir Container ausschließen, die mit dem Statuscode 0 beendet werden, da dies auf eine normale Beendigung hinweist.
Außerdem geben wir beiden Skripten Ausführungsrechte.
$ chmod +x collect_exited_containers.sh collect_restarting_containers.sh
Die DAG besteht aus fünf Tasks:
Die ersten beiden sind selbsterklärend. Wir haben bereits beschrieben, wie die Shell-Skripte bei der Identifizierung problematischer Container helfen, sodass die Implementierung des Tasks vergleichsweise einfach ist.
Der Bericht wird durch diese einfache Python-Callback-Funktion erstellt.
Die Ergebnisse der beiden vorangegangenen Aufgaben werden abgerufen, und sofern diese nicht leer sind, werden sie der fertigen Nachricht hinzugefügt. Eine typische Nachricht würde wie folgt aussehen:
Abnormally exited containers:
my-project_api_documentation-upgrades Exited (137) 2 days ago
my-project_api_localization-data-refactoring Exited (137) 2 days ago
Restarting containers:
my-project_api_establish_db_connection Restarting (2) 6 seconds ago
Please check the containers logs in order to fix the related issues.
Das Senden eines E-Mail-Reports kann mit dem EmailOperator durchgeführt werden.
Und das Senden einer Benachrichtigung an einen Google-Chat-Sapce erfolgt durch Senden eines POST-Request an einen vordefinierten Webhook.
Die Tasks können auf diese Weise angeordnet werden, wodurch Abhängigkeiten zwischen ihnen entstehen.
Mit dieser einfachen Abfolge von Tasks können wir einen Mechanismus erstellen, der für die Überwachung der bereitgestellten Docker-Container einer Anwendung zuständig ist und uns benachrichtigt, wenn etwas nicht stimmt. Dieser Anwendungsfall zeigt wieder einmal sehr deutlich die Vielseitigkeit von Airflow, da es in der Lage ist, mehrere Systeme zu integrieren und mit ihnen zu kommunizieren.
Sie können den gesamten Code für diesen DAG hier finden. Wenn Sie Fragen zu dieser Implementierung haben oder sich fragen, wie Sie Apache Airflow nutzen können, um Ihr datengesteuertes Unternehmen zu stärken, helfen wir Ihnen gerne weiter. Kontaktieren Sie noch heute das Data Science und Engineering Team bei Nextlytics.