Seite wählen

Ergebnisse für " docker "

Poor man's Docker mit ownCloud

Docket basketFür mich privat betreibe ich momentan 3 eigene Server, für WordPress, ownCloud, GitLab, E-Mail und lauter anderer Kleinkram der mich privat interessiert, oder einfach nicht in die Cloud legen möchte.
Früher habe ich von Hand einen Apache Server kompiliert, dann Pakete verstanden und genutzt, und jetzt gibt es da diese Docker… – Magie für viele.
Ich habe mich längere Zeit gefragt, wie ich, oder eine kleinere Firma effektiv mit Containern arbeiten kann. Ganz ohne eine große Cloud, und komplexe Prozesse die man erst aufbauen muss.
Eigentlich ist es ganz einfach, nur ein paar Grundregeln muss man verstehen:

  • Eine Anwendung pro Container
  • Mehrere Container zusammen geben eine große Anwendung
  • Ggf. sorgt ein Webserver davor für Bereitstellung ans Internet, und SSL
  • Der Server auf dem die Container laufen sollte eingeschränkt werden

Im folgenden möchte ich erklären wie ich meine eigene private ownCloud betreibe, vielleicht hilft es jemandem.
mehr lesen…

Logging mit Docker

Wir beschäftigen uns bei Netways viel mit den Themen Logging, Log Management und der Visualisierung eben dieser. Kein Wunder, gehört Logging doch mit zu den essenziellen Teilen eines jeden guten Monitorings. Logs sind seit jeher sowohl für Entwickler auch als auf Adminitratoren wichtig, also quasi total devops. So zieht sich dieses Thema mit der Zeit durch alle Techniken während immer weiter neue Lösungen entwickelt und alte verbessert werden. Es ist also keine Überraschung das es auch in Bezug auf Docker, dem größten Hype überhaupt in letzter Zeit, nicht zu vernachlässigen ist. Wir werden oft gefragt, was denn jetzt nun die richtige Lösung ist  um an die Logs der geliebten Docker Container zu kommen. Nun, eine pauschalte Antwort darauf gibt es wohl nicht, ich kann aber einen Überblick geben.
Wenn wir über Docker und Logs reden ist es wichtig zu wissen, das es dabei (meist) ausschließlich um den Standard-Output des jeweiligen Containers geht. In der Regel besteht ein Container aus einem einzigen Prozess der die gewünschte Applikation startet und nichts weiter. Ein Syslog Daemon ist also nicht vorhanden und somit gibt es innerhalb des Containers auch kein richtiges Logging. Man könnte jeden Container aufblähen und ihm ordentliches Logging verpassen mit einem ordentlichen Syslog Daemon, der kategorisieren und an weitere Syslogs Server schicken kann. Die bevorzugte Variante ist jedoch alles nach stdout und sdterr zu schicken, da man darauf auch von außerhalb des Containers zugreifen kann.
Überblick
Docker unterstützt verschiedene Driver für das Logging. Anhand eines gewählten Drivers beim Start des Cointainers lässt sich steuern wohin Logs weitergeleitet werden. Zu jedem Driver gibt es Optionen die mitgegeben werden können.

   docker run --log-driver=... --log-opt ...

Immer wieder kommen mit neuen Docker Versionen neue Features oder gar neue Driver hinzu. Neben den verschiedenen Log Drivern lässt sich auch none einstellen, um das Logging komplett zu deaktivieren.
Der Standard
Zugegeben, Logging war zu Beginn nicht gerade ein priorisiertes Thema im Docker Projekt. Dennoch gibt es schon lange eine rudimentäre Stütze zum auslesen von Logs. Standardmäßig wird alles in json-Dateien geschrieben. Auslesen kann man diese dann am einfachsten mit dem docker logs Kommando.

   docker run -d ubuntu bash -c "while true; do echo `uptime`; sleep 10; done"
   docker logs 1a2e14a58c75
     10:53:34 up 4 days, 13:29, 4 users, load average: 0.38, 0.33, 0.35
     10:53:34 up 4 days, 13:29, 4 users, load average: 0.38, 0.33, 0.35

Der Alleskönner
Syslog ist der Alleskönner unter den Docker Logging Drivers. Unter Verwendung des Syslog Standards werden Logs an entfernte Daemons weitergeleitet. Das macht es lohnenswert diese für die weitere Verarbeitung und Analyse an Logstash zu schicken.

   docker run -i -t --log-driver=syslog --log-opt syslog-address=udp://logstash.netways.de:514 ubuntu bash -c "while true; do echo `uptime`; sleep 10; done"

Zusätzlich zum Syslog Server lassen sich auch ein paar weitere Optionen setzen:

   --log-opt syslog-facility=daemon
   --log-opt syslog-tag="myContainer"

Der Neue
Mit der Docker Version 1.8 verzeichnete das Projekt Graylog einen Erfolg in der Zusammenarbeit mit Docker. Ihr bekanntes Format GELF (Graylog Extended Log Format) wurde mit aufgenommen und ist seitdem als eigener Log Driver verfügbar. Da sich das Format nicht nur mit dem dazugehörigen Prodokut Graylog benutzen lässt, sondern auch von Logstash unterstützt wird, ist es eine echte alternative zum klassischen Syslog.

   docker run -i -t --log-driver=gelf --log-opt gelf-address=udp://logstash.netways.de --log-opt gelf-tag="myContainer" ubuntu bash -c "while true; do echo `uptime`; sleep 10; done"

Die Anderen
Die genannten Möglichkeiten sind nicht alle, es gibt auch Log Driver für FluentD und journald, dazu aber ein anderes Mal mehr.

Blerim Sheqa
Blerim Sheqa
COO

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. Inzwischen ist Blerim als COO für Icinga tätig und kümmert sich dort um die organisatorische Leitung.

docker-compose

Docker LogoAuf der diesjährigen DockerCon in San Francisco wurden viele Neuerungen vorgestellt. Neben der eigentlichen Docker Engine wurde auch eine neue Version von Compose vorgestellt. Mit docker-compose kann man ganze Anwendungsumgebungen definieren und mit einem Befehl starten. Dies ist vor allem für Setups mit mehreren Containern hilfreich. Man definiert in einer zentralen Datei (docker-compose.yml) die benötigten Container und deren Parameter und führt den Befehl docker-compose up aus. Wer Vagrant benutzt erkennt sofort die parallelen zur Vagrantfile. Compose sorgt dann dafür, dass die Container wie definiert gestartet werden.
Die docker-compose.yml ist im einfachen YAML-Format gehalten. Im folgendem ein kurzes Beispiel aus der offiziellen Dokumentation:

web:
  build: ./web/
  ports:
   - "5000:3333"
  links:
   - redis
  volumes:
   - .:/code
redis:
  image: redis

In diesem Beispiel wird für den Container web ein Image mit Hilfe der ./web/Dockerfile gebaut (build: ./web/), der Port 5000 wird an den Container Port 3333 weitergeleitet, es wird ein Link zum Container redis erstellt und es wird das Volume /code gemountet. Für den redis Container wird einfach das Image von DockerHub heruntergeladen.
docker-compose up -d startet web und redis im Hintergrund und mit docker-compose ps werden die aktuell laufenden Container angezeigt. docker-compose stop beendet diese wieder.
Am Besten einfach selber ausprobieren. docker-compose selbst kann man einfach mit pip installieren.

# pip install -U websocket
# pip install -U docker-compose
Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Alles Docker oder was?

Docker ist ein fantastisches Stück Software. Es ist immer wieder Thema bei unseren Konferenzen, wir bieten passende Workshops an, nutzen es selbst und bloggen darüber. Docker wirbelt seit einiger Zeit den Markt für Container richtig auf, auch wenn es erst mal unter der Haube nichts großartig Neues entwickelt hat. Docker nutzt in erster Linie Mechanismen die schon da sind, aber auf kreativ-konsequente Art und Weise. Durch seine Popularität trug und trägt es natürlich intensiv dazu bei, seine Grundbausteine zu verbessern. Docker nutzt alles was der Kernel so rund um Container bereitstellt und je nach persönlicher Vorliebe echte oder virtuelle Filesysteme, für die exzessives Erstellen von Snapshots per Design eh schon vorgesehen und damit nicht teuer ist. Du wolltest immer schon wie du das von der Software-Entwicklung kennst bei Bedarf nach jedem Handgriff einen „Commit“ eines ganzen Servers? Docker könnte deine neue Liebe sein!
Du gehörst zu den Snapshot-Geschädigten, denen schon mal das sündhaft teure Storage-System dank Snapshot-Voodoo fast um die Ohren geflogen wäre? Bist geprägt von der erbärmlichen Performance von LVM-Snapshots? Keine Sorge, richtig gemacht sind auch tausende von Snapshots auf einem System heute kein Problem mehr. Klar, der Haken ist wie immer dieses „richtig gemacht“, aber da hilft Docker. Man hat out-of-the-box zwar keinen Ferrari, aber einen halbwegs aktuellen Diesel-Golf der zuverlässig ohne ohne zu murren dahintuckert. Wobei Tuckern keinesfalls im Sinne eines alten Traktors zu verstehen ist. Man kriegt mit Docker ohne ölverschmiert rumwerkeln zu müssen frei Haus zumindest einen richtig sportlichen GT oder dergleichen. Und wer sich die Hände schmutzig machen will kriegt das Ferrari-Pferdchen nicht nur als Aufkleber auf die Motorhaube sondern mit all seinen schnellen Freunden auch unter selbige.
Was ich absolut jedem empfehlen kann: eine Probefahrt! Schnapp dir Docker und probier es aus. Spiel damit! Wenn dir das Spielen allein keinen Spaß macht, dann komm zu einem unserer Workshops, gerne auch zur OSDC 2015, mit Gleichgesinnten macht es definitiv mehr Freude! Auch wenn es nicht das richtige Tool für dich ist – es erweitert definitiv den eigenen Horizont. Es tickt und „denkt“ anders, als du das gewohnt bist. Warum es nicht das richtige Tool sein könnte? Weil sehr viele Anwendungen sich nur schwer so kapseln lassen, als dass sie mit Docker sofort Spaß machen würden. Ich kann zwar problemlos mit Docker vollwertige Systeme mit SSH, lokalem Mailer und allem was dazugehört betreiben – aber das ist eigentlich nicht im Sinne des Erfinders. Docker möchte nämlich je eine Applikation pro Container betreiben. Die meisten Applikationen sind dafür schlicht nicht ausgelegt. Wer jetzt also mal eben schnell seine Oracle-Datenbank in einen Docker-Container packen will, der wird sich schwer tun. Was nicht heißt dass es nicht geht, aber so war’s halt erst mal nicht gedacht.
Es ist gar nicht so einfach in wenigen Worten zu beschreiben, wie so eine „eigenständige“ Applikation aussehen soll. Eine interessante Lektüre rund um dieses Thema bietet die Twelve-Factor App. Wenn deine Anwendung diese zwölf Punkte umsetzen kann stehen die Chancen gut, dass sie sich in einem Default-Docker-Container pudelwohl fühlt. Was nicht heißen muss, dass man jetzt all seine Anwendungen sofort umschreiben muss. Mit dem Thema beschäftigen sollte man sich auf alle Fälle, auch hier stehen die Chancen nämlich gut, dass man hinter der Cloud plötzlich wieder ein neues Stück Horizont entdeckt.
Docker setzt eine ganz neue Arbeitsweise voraus und nimmt damit Einfluss auf alles. Quer durch die Bank wird vom Testing über das Konfigurationsmanagement, vom Logging und Mail-Routing bis zum Monitoring alles durcheinandergewirbelt. Für den einen ist das der neue heilige Gral, der andere nutzt es nur um den durch automatisierte Tests generierten Overhead zu minimieren. Was ich aber ausnahmslos jedem ans Herz legen möchte sind die dem Prinzip von Docker zugrunde liegenden Techniken.
Egal ob mit Docker „so wie es sein soll“, ob mit zu System-Containern aufgeblasenen Docker-Containern oder gleich klassisch mit LXC, du solltest diese Werkzeuge kennen, nutzen und lieben lernen! Der Linux-Kernel stellt schon eine ganze Weile mächtige Komponenten zum Verwalten von Containern bereit. Und noch viel viel länger gibt es Kernel-Patches die ähnliches bieten konnten. Ich habe schon vor über 10 Jahren Container unter Linux in sensiblen Umgebungen produktiv einsetzen können und es nie bereut. Die laufen immer noch! Auf meinem Arbeits-Notebook lebt ein ganzer Zoo an internen LANs, Bridges, Firewalls und Containern. Wenn ich ein paar neue leere Debian-Container brauche, habe ich die in wenigen Sekunden am Laufen. Auch wenn ich offline bin. Cgroups erlauben es, Prozessgruppen gezielt zu isolieren und deren Resourcen-Nutzung fein granular zu steuern. Braucht nicht jeder, aber gut zu Wissen, dass es bei Bedarf möglich ist.
Und einen ganz speziellen Charme hat natürlich das ganze Snapshotting-Thema. Aber bevor ich dazu auch noch weiter aushole, was rede ich mir eigentlich den Mund fusselig? Probiert es einfach aus. Jetzt. Gleich. Oder geht doch lieber Skifahren.
Wünsche euch allen ein schönes Wochenende!!

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.

Weekly Snap: Docker, Heap Fragmentation & Bacula vs. Bareos

weekly snap16 – 20 December brought us closer to Christmas with developer tools, developer lawsuits and a new course calendar for 2014.
Eva counted 113 days to the OSDC 2014 with Falk Stern’s presentation on ‘Data Center Management with Racktables’, and announced the dates for our Puppet, Logstash and Graphite training courses next year.
Sebastian discovered Docker, a framework to create lean and portable LXC containers, as Gunnar created a profiler called fprofil.cpp to analyse heap fragmentation.
To close the week, Bernd gave his take on Bacula’s copyright lawsuit against its open source fork, Bareos.