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.
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.
