In einem vorherigen Artikel habe ich über den allgemeinen Aufbau des Ambassador in einem gemeinsamen Projekt der LeanIX GmbH mit der codecentric AG geschrieben. In diesem Artikel werde ich weiter auf die technischen Details des Ambassador Containers eingehen.
Die Funktion des Ambassadors wird durch HAProxy realisiert. Auf Grund von Beschränkungen durch Docker und die Anforderung, die Konfiguration des HAProxy dynamisch und ohne Neustart des Containers ändern zu können, sind noch einige weitere Komponenten nötig:
supervisord
supervisord betreiben wir als root-Prozess im Ambassador Docker Container. Dies ist nötig, da der HAProxy für die Aktualisierung der Konfiguration neue Prozesse mit der neuen Konfiguration startet. Sollte der HAProxy als root-Prozess des Docker-Containers laufen, würde sich dieser beim Aktualisieren der Konfiguration beenden.
etcd
etcd ist ein verteilter Key Value Store. In unserem Fall speichern wir in etcd Parameter für die Konfiguration des HAProxy, genauer gesagt, welche Backends HAProxy für einen Dienst zur Verfügung stehen.
confd
confd dient dazu, Variablen aus einem Backend zu lesen und vorhandene Templates mit deren Werten zu füllen und ggf. Befehle auszuführen. In unserem Projekt überwacht confd bestimmte Einträge in etcd, überträgt diese in ein Template einer HAProxy-Konfigurationsdatei und gibt bei Änderungen dem HAProxy den Befehl seine Konfiguration neu zu laden.
Drei dieser vier Komponenten werden in einem Docker Container betrieben:
- supervisord
- confd
- HAProxy
Diese Komponenten machen unseren Ambassador aus. Es gibt noch eine Diskussion darüber, ob wirklich mehrere Prozesse in einem Docker-Container laufen sollten. Eine Sichtweise dazu kommt aus dem Phusion-Projekt und wird in diesem Ambassador umgesetzt.
Der etcd ist nicht Teil des Ambassador Containers, sondern kann in beliebiger Form, auch als Docker-Container, an beliebiger Stelle laufen. Er muss lediglich über ein Netzwerk erreichbar sein.
Implementierung
Zuerst einmal das Grundgerüst für alles, das Dockerfile:
1# Dockerfile for haproxy 2# Version 1.0 3FROM ubuntu:14.04 4 5MAINTAINER Christian Zunker <christian.zunker@codecentric.de> 6 7RUN apt-get update && apt-get install -y haproxy supervisor netcat 8 9RUN mkdir -p /var/log/supervisor 10COPY supervisord.conf /etc/supervisor/conf.d/ambassador.conf 11 12ADD confd-0.7.1-linux-amd64 /usr/local/bin/confd 13RUN chmod +x /usr/local/bin/confd 14ADD haproxy.toml /etc/confd/conf.d/haproxy.toml 15ADD haproxy.cfg.tmpl /etc/confd/templates/haproxy.cfg.tmpl 16 17CMD ["/usr/bin/supervisord"]
Im Dockerfile ist festgelegt, dass supervisord gestartet werden soll. Dieser ist aber nur ein Mittel zum Zweck. Er startet die weiteren Dienste:
1[supervisord] 2nodaemon=true 3 4[program:confd] 5command=/usr/local/bin/confd -interval %(ENV_CONFD_INTERVAL)s -node %(ENV_ETCD_SERVER)s -config-file /etc/confd/conf.d/haproxy.toml 6stdout_logfile=/dev/stdout 7stdout_logfile_maxbytes=0 8stderr_logfile=/dev/stderr 9stderr_logfile_maxbytes=0 10priority=18 11 12[program:haproxy] 13command=haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid 14stdout_logfile=/dev/stdout 15stdout_logfile_maxbytes=0 16stderr_logfile=/dev/stderr 17stderr_logfile_maxbytes=0 18priority=19
Der supervisord startet unter anderem auch den confd. Dieser erhält über Umgebungsvariablen die Verbindungsdaten zum etcd und eine Konfigurationsdatei, in der sein Verhalten beschrieben wird:
1[template] 2src = "haproxy.cfg.tmpl" 3dest = "/etc/haproxy/haproxy.cfg" 4keys = [ 5 "/backends", 6 "/vhosts" 7] 8reload_cmd = "haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)"
In der confd-Konfigurationsdatei wird auf das Template für die HAProxy-Konfiguration verwiesen und mit welchem Befehl der Reload des HAProxy durchzuführen ist. Die Informationen aus den Verzeichnissen /backends und /vhosts des etcd schreibt confd in die Template-Datei:
1{{ $service_port := printf "%s" (getenv "SERVICE_PORT") }} 2{{ $etcd_prefix := printf "%s" (getenv "ETCD_PREFIX") }} 3{{ $service_type := printf "%s" (getenv "SERVICE_TYPE") }} 4 5frontend {{ $service_type }} 6 bind *:{{ $service_port }} 7 mode tcp 8 use_backend backend-{{ $service_type }} if TRUE 9 10backend backend-{{ $service_type }} 11 mode tcp 12 balance roundrobin 13 {{ $service_path := printf "%s/*" $etcd_prefix }} 14 {{ range gets $service_path }} 15 server {{base .Key}} {{.Value}} check 16 {{ end }}
Damit man eine bessere Vorstellung davon bekommt, welche Daten confd in das Template schreibt, hier ein möglicher Aufbau der Daten in etcd:
1/vhosts/leanix.acme.com/services/export/server1: 192.168.110.11:9100 2/backends/solr/solr1: 192.168.110.11:8983 3/backends/db/db1: 192.168.110.11:3306 4/backends/mail/mail1: 192.168.110.11:25
Die Daten im etcd können während der Laufzeit geändert werden. confd prüft in regelmäßigen Abständen, ob es Änderungen gegeben hat. Ist das der Fall, passt confd die Konfiguration des HAProxy an und lässt diesen damit neu starten. So können im laufenden Betrieb neue Backends hinzugenommen oder auch wieder entfernt werden. Für den Docker-Container, der das Backend eigentlich nutzen möchte, sind die Änderungen transparent, da er seine Anfragen nur an den Ambassador stellt.
Die technischen Details dieser Umsetzung sind sicherlich projektspezifisch, können aber als Vorlage für andere Projekte verwendet werden um das Ambassador Pattern in angepasster Version umzusetzen.
Über die LeanIX GmbH :
LeanIX bietet eine innovative Lösung für das Enterprise Architecture Management (EAM) als Software-as-a-Service in der Public-Cloud oder im Rechenzentrum des Kunden. Die web-basierte Plattform besticht gegenüber traditionellen Ansätzen durch eine intuitive Benutzeroberfläche, ein flexibles Reporting und offene APIs. Dadurch lässt sich leanIX mit minimalem Trainingsaufwand schnell im Unternehmen einführen und nach kurzer Zeit Mehrwert generieren. Sowohl kleine bis mittlere als auch große Unternehmen aus verschiedenen Branchen vertrauen auf die Lösung, wie z.B. Axel Springer, Helvetia, RWE, Vaillant und Trusted Shops. Unabhängig von der Unternehmensgröße werden immer mehr Unternehmen als Kunden gewonnen, die bisher Berührungsängste mit dem Thema EAM hatten oder frustriert sind von schwerfälligen Tools. Gegründet wurde die LeanIX GmbH 2012 von Jörg G. Beyer und André Christ. Der Sitz der Gesellschaft befindet sich in Bonn, unterstützt von einem breiten Partnernetzwerk in Europa, Australien und Amerika.
Über die codecentric AG :
Als Experte für individuelle Software-Entwicklungen ist die codecentric AG der Vordenker für agile Software-Entwicklung und innovative Technologien in Deutschland. Rund 280 Mitarbeiter an dreizehn europäischen Standorten entwickeln Software-Lösungen der Zukunft. Dafür kombiniert codecentric das Know-how der besten IT-Architekten und Software-Entwickler mit dem Praxiswissen aus zahlreichen Projekten in den Bereichen Continuous Delivery, Big Data, Performance Solutions, Agile und Enterprise Development. Für optimale Java Performance, Skalierbarkeit und Stabilität haben codecentric-Kunden Zugriff auf umfassende Risiko-Management-, Troubleshooting-, Java-Optimierungs- und Performance-Management-Services nebst Werkzeugen.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Christian Zunker
9.8.2021 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Christian Zunker
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.