CoreOS – Cluster Discovery

This entry is part of 3 in the series Distributed Container with CoreOS

Bei der Einrichtung eines neuen CoreOS Clusters muss man sich für eine Variante entscheiden, mit der sich die einzelnen Server untereinander bekannt machen. In Wirklichkeit ist es auch kein CoreOS-, sondern ein etcd-Cluster. Der Key-Value Store, etcd genannt, ist die Kernkomponente die dazu genutzt wird, Informationen über mehrere Server hinweg zu speichern. Im ersten Schritt müssen diese Nodes aber davon in Kenntnis gesetzt werden, dass sie zusammengehören. Wissen sie erst mal voneinander, finden sie auch den weg zueinander. Etcd besitzt mehrere Mechanismen, um diesen ersten Kontakt herzustellen. Bekanntermaßen werden die einzelnen CoreOS Dienste in der cloud-config konfiguriert. Diese Datei wird beim Start geladen und umgesetzt. Meine unten aufgeführten Beispiele stellen keine vollständige cloud-config dar, lediglich die relevanten Teile einer solchen.

Initial Cluster State

Viel Frust kann man sich sparen, indem man die Option initial-cluster-state richtig verwendet. Wird ein neues etcd-Cluster erstellt, muss diese Einstellung auf new gesetzt sein. Fügt man hingegen eine Node einem Cluster hinzu, ist der Wert zwingend auf existing einzustellen. Andernfalls wird der neue Server trotz Discovery Mechanismen versuchen ein neues Cluster zu initiieren.

Statische Konfiguration

Bei einer statischen Konfiguration werden alle Nodes in der cloud-config fest eingetragen. Kommen Server hinzu oder fallen sie weg, muss die Konfiguration ebenfalls angepasst werden.

#cloud-config
coreos:
  etcd2:
    listen-client-urls: http://0.0.0.0:2379
    listen-peer-urls: http://$private_ipv4:2380
    initial-cluster: srv1=http://10.0.0.1:2380,srv2=http://10.0.0.3:2380,srv3=http://10.0.0.3:2380

Diese Art der Konfiguration bietet sich an, wenn alle Nodes dieselbe cloud-config laden. Die Anzahl der Server sollte sich nicht oft ändern, da man sonst viel Zeit mit dem Umbau der Konfiguration verbringt. Durch die festen Einträge geht viel von der Dynamik verloren, die CoreOS so charmant macht. Mal eben Server dazu zu stellen oder abbauen ist nicht mehr ohne Weiteres möglich.

etcd.io Discovery Service

Die Macher von etcd haben einen Service im großen weiten Internet stehen, so wie sich das für ein anständiges Tool in der heutigen Zeit nun mal gehört. Bei diesem Service lassen sich unter einer eindeutigen ID die eigenen CoreOS/Etcd Nodes eintragen und verwalten. Das muss nicht manuell gemacht werden, sondern geschieht automatisch nach Angabe bestimmter Parameter.

Das ganze funktioneirt so:

    1. Man erstellt eine neue, eindeutige ID. Unter dieser werden die eigenen Einträge dann gespeichert.
      curl 'https://discovery.etcd.io/new?size=3'
    2. Die URL die man geliefert bekommt, wird dann in der cloud-config hinterlegen. Somit weis etcd beim Start automatisch wo er sich anzumelden hat. Zusätzlich bekommt er dort Informationen über bestehende Nodes.
#cloud-config
coreos:
  etcd2:
    listen-client-urls: http://0.0.0.0:2379
    listen-peer-urls: http://10.0.0.1:2380
    discovery: https://discovery.etcd.io/e8bd58c845d69485b1d0767541bc72bd

DNS Discovery

Hier kommt mein persönlicher Favorit. Es ist quasi eine Kombination aus den zwei genannten Variationen. Bei der DNS Discovery werden unter einer festgelegten Subdomain DNS SRV Einträge gesetzt. Jeder Host der Teil des etcd-Clusters ist, wird eingetragen. Beim Start eines Servers fragt er selbstständig die hinterlegte Subdomain ab und erfährt somit die Hostnamen aller im Cluster vorhandenen Server.

~> dig -t SRV +short _etcd-server._tcp.coreos.netways.de
0 100 2380 node1.coreos.netways.de.
0 100 2380 node2.coreos.netways.de.
0 100 2380 node3.coreos.netways.de.
0 100 2380 node4.coreos.netways.de.
0 100 2380 node5.coreos.netways.de.

Die cloud-config muss entsprechend konfiguriert werden.

#cloud-config
coreos:
  etcd2:
    discovery-srv: coreos.netways.de
    listen-client-urls: http://0.0.0.0:2379
    listen-peer-urls: http://node1.coreos.netways.de:2380
Blerim Sheqa

Autor: Blerim Sheqa

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Coreos Übersicht

This entry is part 1 of 3 in the series Distributed Container with CoreOS

Docker, Docker Docker! So oder so ähnlich wird teilweise hämisch oder motivierend auf Ideen kommentiert, seine Anwendung in einen bzw. mehrere Docker Container zu migrieren. Für eine produktive Umgebung reicht das Standard Set von Docker nicht aus, zumindest nicht ohne Docker Swarm, Compose und Machine. Es gibt mittlerweile und gab neben den Produkten aus dem Hause Docker bereits Lösungen, die sich um das Deployment und Managen von Containern kümmern können. Eine sehr gute Alternative ist Mesos, aber auch CoreOS.

In der mehrteiligen Blogserie zu CoreOS werden die einzelnen Komponenten, Features und Vorzüge von CoreOS genauer betrachtet. Im ersten Beitrag zur Serie soll ein erster grober Überblick vermittelt werden.

Three-Tier-Webapp

CoreOS ist ein leichtgewichtiges auf dem Linux Kernel aufbauendes Open Source Betriebssystem. Das System ist auf das Nötigste reduziert, kommt ohne Paketmanager aus und nutzt systemd als init. Neben den essentiellen Userland Tools besteht es im wesentlichen aus: Container Runtime (Docker/Rkt), etcd und fleet. Es kann auf diversen Plattformen betrieben werden wie Vagrant, EC2, KVM, VMware, OpenStack, Digital Ocean Droplets, und natürlich auf eigener Hardware. Updates werden durch Reboots vollzogen.

Eine Variante der Installation ist über PXE/iPXE. Hier wird für die entsprechenden VMs oder Hardware-Server ein korrespondierender PXE-Boot-Eintrag erstellt, der das aktuelle CoreOS Image vorhält. Die einzelnen Maschinen können individuell auf ihre zukünftige Rolle mit einer sogenannten cloud-config konfiguriert werden. Beim boot liest das System diese in YAML formatierte Datei ein und konfiguriert sich entsprechend. Es kann der Discovery Service Endpoint, fleet, etcd, ssh-keys und Dateien konfiguriert werden.

Beispiel cloud-config.yaml:
#cloud-config
coreos:
units:
- name: etcd.service
command: start
- name: fleet.service
command: start
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABA....AAAYQC2++odpaavdW2/AU0l7RZiE=

Das Discovery dient zur Clusterbildung und wird von CoreOS bereitgestellt. Natürlich kann man auch seinen eigenen Discovery-Service nutzen. Unter einem eindeutigen Token wird ein neuer Cluster definiert. Die erste Maschine, die startet nimmt Kontakt auf und registriert sich als Leader für den Cluster. Alle weiteren Maschinen, lesen die bereits teilnehmenden Cluster-Nodes aus und können sich entsprechend integrieren und verbinden. Für die Services etcd und fleet sind diese Informationen essentiell.

etcd ist ein verteilter Key-Value-Store, der für Service-Discovery und Konfiguration benutzt wird. Es kümmert sich mit Hilfe des Raft Protokolls um Consensus.

fleet kann man sich als Serverübergreifender systemd vorstellen. Mit Hilfe von Unit-Files erstellt man Services die fleet im Cluster nach Regeln verteilt und startet bzw. stoppt. Ein Service ist in der Regel ein Container.

Beispiel Unit-File:
[Unit]
Description=MyApp
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill busybox1
ExecStartPre=-/usr/bin/docker rm busybox1
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop=/usr/bin/docker stop busybox1

In den nächsten Blogposts der Serie werden die einzelnen Komponenten und weitere wie Loadbalancer etc. genauer betrachtet und anhand von Beispielen näher auf die Vorzüge eines Setups mit CoreOS und mögliche Workflows eingegangen.

Sebastian Saemann

Autor: Sebastian Saemann

Sepp kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet zusammen mit Martin das Managed Services Team. Wenn er nicht gerade Server in MCollective einbindet, versucht er mit seinem Motorrad einen neuen Geschwindigkeitsrekord aufzustellen.

CoreOS und etcd

This entry is part 2 of 3 in the series Distributed Container with CoreOS

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.

Sebastian Saemann

Autor: Sebastian Saemann

Sepp kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet zusammen mit Martin das Managed Services Team. Wenn er nicht gerade Server in MCollective einbindet, versucht er mit seinem Motorrad einen neuen Geschwindigkeitsrekord aufzustellen.