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:
- Man erstellt eine neue, eindeutige ID. Unter dieser werden die eigenen Einträge dann gespeichert.
curl 'https://discovery.etcd.io/new?size=3'
- 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
0 Comments