Namensauflösung für LXC in Ubuntu 16.04

Um auf Services in einem Container, wie z.B. SSH oder MySQL zuzugreifen, benötigt man ja eigentlich die IP-Adresse des Containers. Mit ein paar Handgriffen kann man aber auch einfach den Hostnamen des Containers, wie im folgenden Beispiel benutzen.

lxc-create -n mysql1.lxc -t ubuntu -- --release=xenial
lxc-start -n mysql1.lxc -d
ssh ubuntu@mysql1.lxc

Um die interne Namensauflösung für die lxc-Domain zu aktivieren, muss folgende Zeile in /etc/default/lxc-net einkommentiert werden und der Dienst lxc-net neugestartet werden.

LXC_DOMAIN=lxc

LXC startet selbst den einfachen DNS- und DHCP-Server dnsmasq für sein Netzwerk, welcher auf die IP-Adresse 10.0.3.1 hört. Diese tragen wir einfach als Nameserver in /etc/resolvconf/resolv.conf.d/head ein:

nameserver 10.0.3.1

Danach muss die Datei resolv.conf mit folgendem Befehl aktualisiert und eventuell laufende Container neugestartet werden.

resolvconf -u
Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Docker

Die Devops-Tool-Chain hat seit einiger Zeit ein sehr interessantes neues Tool mit dem Namen “Docker”. Docker erfährt einen regelrechten Hype um sich, wobei die Meinungen um das Tool durchaus gemischt sind. Einen Blick ist es auf jeden Fall Wert. Aber was ist Docker eigentlich?
Docker ist ein Open-Source-Framework, das leichtgewichtige, portable, LXC-Container bereitstellt und steuert, die praktisch überall laufen können. Eine Anwendung kann also problemlos auf einem Laptop des Entwicklers, oder in großen Produktionsumgebungen auf Bare-Metal oder in der Cloud laufen. Das mit dem überall beschränkt sich dann aber doch auf einen Linux-Kernel mit LXC, aber das wiederum kann praktisch überall laufen. Die Use-Cases sind die Automatisierung von Deployments, das Bereitstellen von PaaS/SaaS Services, automatisierte Continuous-Integration-Tests und die Skalierung von Anwendungen. Spätestens jetzt ruft der erste “Bingo” beim Buzzword-Bingo.
In anderen Worten ist Docker ein Tool, vergleichbar mit Vagrant, mit dem sich Anwendungen einfach über Umgebungen hinweg portieren lassen.
docker run ubuntu /bin/echo hello world
Tatsächlich ist das aufgezeigte Beispiel vielleicht etwas ernüchternd: es gibt bei Erfolg lediglich “hello world” auf einer neuen Zeile zurück. Tatsächlich passiert aber viel mehr. Das Image ‘ubuntu’ wird heruntergeladen – wenn es nicht bereits lokal vorhanden ist – und in einem LXC-Container gestartet. In diesem wiederum wird /bin/echo ausgeführt und anschließend beendet sich der Container wieder.
Ein Container wird immer aus einem Image erzeugt und läuft so lange die Anwendung läuft – wird diese beendet, beendet sich auch der Container. Images sind über Repositories, bei Bedarf auch eigenen Repositories, verfügbar. Ähnlich wie mit Git lassen sich diese Images steuern. docker commit, docker pull, docker push erstellen neue Images und laden diese hoch bzw. runter.
docker run -i -t ubuntu /bin/bash
docker commit $ID my_fancy_app
docker run -p 80:3000 my_fancy_app rails server

In dem Beispiel wird ein LXC-Container mit Ubuntu gestartet mit einer interaktiven Shell. In der Sitzung installiert man seine Anwendung. Eleganter ist ein Dockerfile, dass das automatisch vornimmt. In dem Beispiel wird eine Ruby-on-Rails-Anwendung installiert und mit dem commit Befehl anschließend ein neues Image erzeugt. Nebenbei bemerkt: docker diff zeigt den Unterschied zum initialen Container. Abschließend wird das neue Image in einem neuem Container mit einer Portweiterleitung von 80 auf 3000 und der Anwendung (Webrick) gestartet. Die Anwendung ist dann unter der $IP:80 auf dem System, dass den Container hosted, verfügbar. Die Anwendung bzw. der Container kann jetzt beliebig oft sekundenschnell gestartet werden, solange der Netzwerkport natürlich nicht doppelt belegt wird. Der Container ist jetzt in der Lage auf jedem System gestartet zu werden, dabei ist es egal ob es eine Amazon AWS VM, KVM/XEN VM, Bare-Metal oder Virtualbox(Vagrant) ist.
Seine Container kann man auch mit Puppet steuern, verteilen und starten.
docker::run { 'my_app':
image => 'my_fancy_app',
command => 'rails start',
ports => ['80', '443'],
}

Zusammenfassend ist Docker ein geniales Framework für einige bestimmte Anwendungsfälle. Ich bin begeistert.
Mehr Information findet man auf docker.io

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

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.

Virtuelle Entwicklungsumgebungen mit Vagrant

Mit Vagrant beschreibt und erstellt man virtuelle Entwicklungsumgebungen, was Entwicklern das Leben deutlich vereinfacht. Es läuft unter Linux, Windows und Mac OS X. Wenige Handgriffe reichen, um eine virtuelle Maschine in Betrieb zu nehmen und einzurichten.
Die Umgebung wird über ein Vagrantfile konfiguriert, welches u.a. port forwarding, mounts, Netzwerkkonfiguration und automatische Installation von Software steuert. Letzteres ist über Shellskripte, Ansible, Chef oder Puppet möglich.
Vagrant kann out of the box mit VirtualBox verwendet werden. VMWare ist auch möglich, aber kostenpflichtig. Weitere provider wie lxc findet man auf github.
Warum Vagrant?
Hauptgrund ist die klar definierte Umgebung. Jeder arbeitet mit den exakt gleichen Bibliotheken und identischen Versionen von Software. Infrastrukturkomponenten müssen nicht lokal installiert werden und die Umgebung ist reproduzierbar.
Zum Weiterlesen empfehle ich die Anleitung für Einsteiger.

Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Nein, ich will keine ausgewachsenen VMs. Meistens.

Heutzutage wird alles virtualisiert – und das ist auch gut so. Als großer Freund der Virtualisierung stecke ich am liebsten jeden Dienst in seinen eigenen Container. In einen Container, aber nicht in eine ausgewachsene VM. Hypervisor wie KVM, XEN und VMware sind für viele Anforderungen ein enormer Oberhead. Um in die meisten Vorzüge der Virtualisierung zu kommen, man braucht keinen virtualisierten Kernel mit virtualisierter Hardware – es gibt auch weitaus schlankere Werkzeuge hierzu.
BSD nennt das Konzept Jails, unter Solaris sind es Zones – und auch unter Linux existiert Vergleichbares schon lange. Wegbereiter waren das von mir über Jahre intensiv genutzte Linux-vServer, sowie OpenVZ und andere. Allen gemein war, dass sie einen entsprechend gepatchten Kernel benötigten – eine Voraussetzung, die sich aufgrund entsprechender Policies nicht überall umsetzen lässt.
Capabilities, Namespaces, CGroups und andere Mechanismen im Kernel ebneten den Weg zum offiziellen Ersatz für genannte Kernel-Patches: die Linux-Container , kurz LXC genannt. Seit 2.6.29 Bestandteil des Upstream-Kernels wird LXC so langsam erwachsen, die anfängliche Lernkurve ist aber immer noch recht steil.
Container haben keinen direkten Hardware-Zugriff: nicht auf Blockdevices, nicht aufs Netzwerk und auch nicht auf den Arbeitsspeicher. Auch haben entsprechende Gäste keinen eigenen Kernel, man kann sie vereinfacht als bessere chroot-Umgebung mit voneinander isolierten Prozessen betrachten. Genau darin liegt aber der Charm dieser Lösung: virtuelle Server zeigen kaum Performance-Unterschiede zu auf dem Host selbst laufenden Prozessen, und ein einziger Kernel kümmert sich um den virtuellen Speicher. Dadurch lassen sich weit mehr virtuelle Server als z.B. mit einem ausgewachsenen VMware betreiben.
Die Beschränkung auf einen Kernel ist gar nicht so schwerwiegend wie es vielleicht klingen mag: man kann z.B. problemlos ein 32bit RHEL als Gast auf einem aktuellen 64bit Debian betreiben. Nicht möglicht ist natürlich der virtualisierte Einsatz von anderen Betriebssystemen wie Windows in so einem Container. Solange man aber nur Linux-Systeme virtualisiert ist LXC allemal einen Versuch wert. Noch viel mehr Freude macht es, wenn man dazu schon mal ein paar erste Gehversuche mit BTRFS wagt.
Da aktuelle Distributionen LXC meist schon mitbringen, bleibt mir nur noch, gutes Gelingen und viel Spaß zu wünschen!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.