Im zweiten Teil der Serie wird eine Kernkomponente von CoreOS beschrieben: etcd. Etcd ist ein distributed Key-Value-Store, der für die Konfiguration und das Service-Discovery innerhalb eines CoreOS Clusters verantwortlich ist. Wie viele Tools im Docker Umfeld ist auch etcd in Go geschrieben. Es zeichnet sich durch seine Geschwindigkeit, Verlässlichkeit, Sicherheit und Einfachheit aus. Für sein Konsens verwendet es das Raft Protokoll. Etcd kann man über API (HTTP+JSON) sowie über ein Command Line Interface (etcdctl) steuern.
Ein Beispiel verdeutlicht sehr schnell und einfach, wie etcd verwendet werden kann, um Daten zu schreiben bzw. sie wieder auszulesen:
$ etcdctl set /message Hello
Hello
$ etcdctl get /message
Hello
oder per HTTP-API
$ curl -L -X PUT http://127.0.0.1:4001/v2/keys/message -d value="Hello"
{"action":"set","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}
$ curl -L http://127.0.0.1:4001/v2/keys/message
{"action":"get","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}
Neben der erwähnten Konfiguration des CoreOS Clusters selbst ist es möglich seine gestarteten Container mit Hilfe von etcd wieder zu finden. Das Schlüsselwort ist „Service-Discovery“. Hierfür wird meist ein Sidekick Prozess gemeinsam mit dem eigentlichen Anwendungscontainer gestartet. Der Sidekick kümmert sich hierbei um das Registrieren der Anwendung. Wie im ersten Teil bereits beschrieben, startet man Container und Services über Fleet, das sich wiederum auf Unit-Files stützt.
[Unit]
Description=Announce myawesomeapp
BindsTo=myawesomeapp@%i.service
After=myawesomeapp@%i.service
[Service]
ExecStart=/bin/sh -c "while true; do etcdctl set /services/myawesomeapp/%i/status/current 'started' --ttl 60; etcdctl set /services/myawesomeapp/%i/status/expected 'started' --ttl 60; etcdctl set /services/myawesomeapp/%i/status/alive 'started' --ttl 60;etcdctl set /services/myawesomeapp/%i/location \"{\\\"host\\\": \\\"%H\\\", \\\"port\\\": \"`docker inspect --format='{{(index (index .NetworkSettings.Ports \"8080/tcp\") 0).HostPort}}' myawesomeapp`\"}\" --ttl 60; etcdctl set /domains/myawesomeapp.netways.de/type 'service' --ttl 60;etcdctl set /domains/myawesomeapp.netways.de/value 'myawesomeapp' --ttl 60;sleep 45;done"
ExecStop=/usr/bin/etcdctl rm /services/website/myawesomeapp@%i
[X-Fleet]
MachineOf=myawesomeapp@%i.service
Das Beispiel zeigt ein Unit-File, das für den Anwendungscontainer (myawesomeapp@.service) einen Sidekick startet. Der Sidekick schreibt verschiedene Informationen des Anwendungscontainers mit einer Gültigkeit (ttl) von 60 Sekunden in etcd unter anderem zum Beispiel seine Location: „etcdctl set /services/myawesomeapp/%i/location“
Das ist wichtig, da in einem Container Cluster die Container auf beliebigen Nodes mit beliebigen Ports gestartet werden können. Ein geeigneter Loadbalancer bzw. geeignete Software kann so dynamisch die aktuelle Umgebung auslesen und Requests an die laufenden Applikationen bzw. Container weiterleiten.
In den nächsten Teilen der Serie wird auf Loadbalancer und Fleet genauer eingegangen.
0 Kommentare