Docker Overlay Network

In den letzten Versionen von Docker hat sich im Bereich Netzwerk einiges getan. Man konnte sich zwar schon seit längerem mit Projekten wie Calico, Flannel oder Socketplane ein Multihost Docker Netzwerk schaffen, aber seit dem Zusammenschluss von Docker und Socketplane und dem daraus gewachsenem libnetwork gibt es jetzt Multihost Docker Networking out of the box.

Damit man es nutzen kann benötigt man neben einer sehr aktuellen Docker Version auch einen zentralen Key-Value Store wie Zookeeper, Etcd oder Consul. Sofern alles richtig konfiguriert ist, erstellt man ein Netzwerk vom Typ ‘Overlay’ mit dem Docker-CLI oder wer es braucht über die Docker API.

docker network create --driver overlay --subnet=10.0.9.0/24 my-net

Ein Container, der sich diesem Netz anschließen soll wird dann ebenfalls wie gewohnt gestartet, jedoch zusätzlich mit dem Zusatz --net, der das entsprechende Netzwerk bestimmt.

docker run -itd --name=web --net=my-net nginx

Ein zweiter, dritter oder x-ter Container auf anderen Hosts wird nach dem gleichem Schema gestartet und schon hat man in dem angegeben IP-Subnetz ein eigenes und neues isoliertes Netzwerk über mehrere Hosts hinweg, über das die Container direkt miteinander kommunizieren können, ohne Umwege wie z.B. über einen Service-Discovery Loadbalancer machen zu müssen.

Das ganze wirkt fast schon magisch und ist für ein so komplexes Thema super leicht zu konfigurieren und zu nutzen. Hinter den Kulissen wird über den VxLAN Standard ein Layer2 Netzwerk (10.0.0.9/24) über Layer4 (UDP) hinweg getunnelt. Das Virtual extensible LAN verhält sich ähnlich zu einem gewöhnlichen Layer2 VLAN, hat jedoch in sehr großen Umgebungen seinem etabliertem VLAN Namensvetter einiges voraus. Die Anzahl der möglichen VLANs wächst von 4094 auf über 16 Millionen. Broadcast Traffic wird zu Multicasts gemapped und vieles mehr.

Wer mehr zu dem Thema wissen will und in entspannter Atmosphäre und isolierten Testumgebung ausprobieren möchte, dem sind unsere Docker Trainings und auch der Docker Workshop vor der OSDC sehr zu empfehlen.

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.

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.

WLAN Analyse mit Mac OS X Boardmitteln

Durch immer mehr WLAN Hotspots im Umkreis des eigenen Hotspots häufen sich oftmals die Verbindungsprobleme. Der Grund hierfür sind oftmals nicht der schlechte Empfang sondern Geräte die als Störer mit in das eigene Frequenzband funken. Im 2,4GHz Standard gibt es lediglich 3 Kanäle die genug Abstand in MHz zueinander haben, so dass es keine Störung des eigenen Kanals gibt. Das Problem ist jedoch, dass man Hotspots der Nachbarn oder angrenzenden Firmen selber nicht auf seine Vorstellungen konfigurieren kann, um eine bestmögliche Kanalwahl aller betroffenen Geräte steuern zu können. Eine gute Alternative ist, den stärksten Sender zu suchen und den gleichen Kanal zu wählen, damit sich die Geräte untereinander einigen können. Besser man geht auf eine Frequenz, die keiner nutzt. Aktuell gibt es im 5GHz Standard die Chance der einzigste im Umkreis zu sein. Falls nicht gibt es zumindest die Chance einen Kanal bzw. eine Frequenz zu erwischen, die einem allein zur Verfügung steht. Mit der Verbreitung von 5GHz tauglicher Hardware wird die Chance natürlich auch immer geringer.

Für eine entsprechende Analyse der Gegebenheiten im aktuellen Umkreis kann man mit den Boardmitteln von Mac OS X, die wirklich sehr versteckt zu finden sind, gut gearbeitet werden.

Mit gedrückter “alt”-Taste auf das WLAN-Symbol und anschließend die Diagnose öffnen. Es öffnet sich ein Assistent, der ignoriert werden kann. Im Menu “Fenster” können dann die verschiedensten Tools geöffnet werden. Interessant sind für oben beschriebenes Szenario die Programme “Scan” und “Leistung”.

Scan zeigt die aktuellen Netze mit gewähltem Frequenzbereich und -breite. Zudem den Received Signal Strength Indicator (RSSI) und die Stärke des Störsignals aus denen man den Signalrauschabstand ableiten kann.

Das Fenster Leitung stellt das ganze zusätzlich mit Hilfe eines sich aktualisierenden Graphen dar. Was sehr hilfreich werden kann, sobald man Räume oder Stockwerke wechselt und dessen Umgebung analysieren möchte.

WLAN-Leistung

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.

Viva la Revolución?

Viva la Revolución?

Docker ist in aller Munde und erfährt derzeit einen riesen Hype um sich. Es wird teilweise gar von „Revolution“ gesprochen. Doch ist das ganze wirklich so revolutionär? Die Lager in der DevOps Community sind sich hierüber nicht ganz einig und sind teilweise gespalten. Die eingesetzten Technologien aus denen Docker besteht sind eigentlich nicht neu und werfen den Mehrwert, den man in der letzten Zeit durch Configuration Management Tools wie Puppet, Chef etc. gewonnen hat, teilweise wieder zurück. Im wesentlichen besteht Docker aus einer Container-Virtualisierung, einem Copy on Write Filesystem bzw. Overlay Filesystem, einem Repository, einer Versionsverwaltung und einer mächtigen API. Das ganze zusammengeschnürt und einfach zu steuern und zu verwenden ist dann Docker.

 
Die Plattform verfolgt den Continious Integration Gedanken mit der man kontinuierlich Änderungen, möglichst automatisiert mit einer Kette an Tests, in die Produktion ausrollt. Der Workflow sieht im einfachsten Fall vor, dass man ein Image startet, Änderungen an diesem Image durchführt und diese dann als „commit“ speichert. Aus diesem kann man wiederum weitere Instanzen klonen und kann sie, sollte etwas nicht wie gewünscht funktionieren, wieder auf einen älteren Stand zurückrollen.

 
Wie immer und auch bei anderen Lösungen birgt Docker nicht nur Vorteile. Technisch gibt es einige Herausforderungen und Probleme die bei der Integration in die Produktion früher oder später auftauchen werden. (Noch) keine Möglichkeit Disk I/O zu limitieren, kein Quota auf AUFS, keine persistenten Anwendungsdaten, keine vollständige Isolation, dynamische Hostnames, Loadbalancing um nur einige zu nennen. Neben technischen Herausforderungen gibt es außerdem das Workflow Dilemma, das sich wie schon erwähnt teilweise mit den Config Management Tools beißt und deshalb auch die Lager spaltet.

 
Der richtige Weg ist aber wohl mehr eine Glaubensfrage oder am ehesten dem Use-Case gezollt. Jedes Unternehmen hat eigene Anforderungen und muss diese gegen den „Docker-Workflow“ evaluieren. Die bereits existierenden Schwierigkeiten, die es in einer automatisierten Umgebung und Continious Integretion gibt, löst Docker deshalb auch nicht, aber es zeigt einen interessanten alternativen Weg auf. Die Antwort auf die ursprüngliche Frage der revolutionären Ansätze und des Umdenkens, kann wohl erst in einigen Jahren gegeben werden nachdem Erfahrungen gemacht wurden und man den tatsächlichen Einfluss bewerten kann. Mehr zum Thema und Docker erfährt man bei uns in den Trainings.

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.