Der Release Candidate von PHP 8.5 war bereits seit einigen Monaten auf unserer Plattform verfügbar. Nun wurde die finale Version 8.5.0 veröffentlicht. Sie steht ab sofort bei Servivum zur Verfügung.

Die neue Version bietet viele spannende Features wie die neue URI-Extension, den Pipe-Operator, Property-Modifikation beim Klonen, das NoDiscard-Attribut und vieles mehr. Natürlich bringt PHP 8.5 auch wieder viele Performance-Verbesserungen mit sich.

Weitere Details zur neuen Version sowie einen Migration Guide findet ihr auf der offiziellen Website.

Die aktuell bei Servivum verfügbaren Module und Extensions für PHP 8.5 könnt ihr auf unserer PHP-Info-Seite einsehen.

Viel Spaß mit PHP 8.5!

Foto von Ben Griffiths (unsplash.com)

Mehrere unserer Kunden haben heute Phishing-E-Mails erhalten, die sich als Servivum ausgeben. Bitte sei wachsam.

Woran erkennst du die Fälschung?

Die betrügerische E-Mail hat den Betreff "Action Required: Your Storage Limit Expires" und behauptet, dein Speicherplatz läuft ab.

Das ist Betrug, denn:

• Servivum verschickt KEINE Storage-Warnungen per E-Mail
• Wir fragen NIEMALS per E-Mail nach deinen Login-Daten
• Die E-Mail kommt nicht von unseren Servern

Was solltest du tun?

✅ E-Mail erhalten? → Sofort löschen, nicht auf Links klicken
🚨 Bereits geklickt? → Ändere sofort dein Passwort über servivum.com

Wie konnte das passieren?

Die Angreifer haben KEINE Kundendaten erbeutet. Sie identifizieren Servivum-Kunden über öffentliche DNS-Einträge und verschicken dann Massen-Phishing-Mails. Das ist eine gängige Methode und bedeutet kein Datenleck.

Was unternehmen wir?

• E-Mail-Sicherheit wurde verschärft
• Gefälschte Mails werden künftig automatisch blockiert

Wichtig zu merken

Echte Servivum-E-Mails:

• Kommen nur von @servivum.com
• Enthalten nie Login-Aufforderungen
• Drohen nicht mit Kontosperrung

Fragen?

Unsicher, ob eine E-Mail echt ist? Kontaktiere uns:

Support: support@servivum.com
Sicherheit: security@servivum.com

Vielen Dank für deine Aufmerksamkeit und dein Vertrauen.

Dein Servivum Team

Der Release Candidate von PHP 8.4 war bereits seit einigen Monaten auf unserer Plattform verfügbar. Gestern wurde nun die finale Version 8.4.1 veröffentlicht. Sie steht nun ebenfalls bei Servivum zur Verfügung.

Die neue Version bietet viele spannende Features wie Property Hooks, Asymmetric Visibility, BCMath Object API und vieles mehr. Natürlich bringt PHP 8.4 auch wieder viele Performance-Verbesserungen mit sich.‌‌

Weitere Details zur neuen Version sowie einen Migration Guide findet ihr auf der offiziellen Website.‌‌

Viel Spaß mit PHP 8.4!

Foto von Ben Griffiths (unsplash.com)

In den letzten Tagen wurde bekannt, dass die Domain polyfill.io, über die die bekannte JavaScript-Bibliothek Polyfill.js bereitgestellt wird, von einer chinesischen Firma übernommen wurde und nun Schadcode verbreitet.

Diese Bibliothek wird verwendet, um in älteren Browsern moderne Funktionen nachzurüsten, was man auch als Polyfill bezeichnet. Aufgrund der nun offengelegten Sicherheitslücke ist es dringend erforderlich, dass alle, die diesen Polyfill über polyfill.io eingebunden haben, sofort handeln, um ihre Websites und ihre Nutzer:innen zu schützen.

Was ist passiert?

Polyfill.js ist eine Open-Source-Bibliothek und kann sicher über Plattformen wie GitHub heruntergeladen und eingebunden werden. Häufig wurde dies nicht getan, sondern die Polyfill-Bibliothek wurde mittels Skript-Tag von der externen Domain polyfill.io heruntergeladen. Diese Domain wurde mittlerweile aber von einer chinesischen Firma übernommen, und statt der Originalversion wird nun eine manipulierte Version mit Schadcode ausgeliefert. Hier sind einige der Artikel, die das Problem im Detail beschreiben:

• Sansec: Polyfill Supply Chain Attack
• Heise: Schadcode über CDN des JavaScript-Service Polyfill.io verteilt
• Golem: Angriff via polyfill.io - Über 100.000 Webseiten verbreiten plötzlich Malware

Warum Polyfill nicht mehr benötigt wird

Der Autor von Polyfill.js hat bereits darauf hingewiesen, dass man es nicht mehr verwenden soll. Das hat damit zu tun, dass ältere Browser, die diese Polyfills benötigen, mittlerweile einen sehr geringen Marktanteil haben. Modernen Browser hingegen benötigen keine Polyfills mehr. Solltest du alte Applikationen betreiben, die auf die Kompatibilität zu älteren Browser angewiesen ist, z. B. für interne Prozesse, kannst die gehosteten Alternativen von Polyfill.js bei Cloudflare oder Fastly nutzen oder noch besser eine eigene Version mit deiner Applikation bereitstellen, sodass du nicht von externen Quellen abhängig bist.

Maßnahmen zur Vermeidung solcher Angriffe

Diese Art von Angriffen nennt man Supply Chain Attack. Heutige Apps können aufgrund der Komplexität nicht komplett selbstständig entwickelt werden, sondern benötigen in der Regel externe Abhängigkeiten. Daher werden Supply Chain Attacks immer häufiger. Hier ein paar Maßnahmen, die du ganz generell ergreifen kannst, um deine Applikation auch vor ähnlichen Angriffen in Zukunft zu schützen.

Aktualisiert eure Bibliotheken: Nutzt nur vertrauenswürdige und aktuelle Bibliotheken.

Nutzt sichere Quellen: Ladet externe Bibliotheken direkt von vertrauenswürdigen Quellen wie GitHub herunter, um sicherzustellen, dass ihr die Originalversion verwendet. Nutzt keine Ressourcen von externen CDNs, wenn dies nicht notwendig ist. Ladet die benötigten Dateien herunter und stellt sie über eure eigene App bereit. Dies gibt euch die Kontrolle darüber, welche Version der Datei verwendet wird, und schützt euch vor unerwünschten Änderungen durch Dritte. Mit dem Aufkommen von HTTP/2 sind die früheren Vorteile von CDNs, wie schnelleres Laden und geringere Latenz bei der Integration von Assets geringer geworden. CDNs sind weiterhin sinnvoll, wenn der gesamte Inhalt darüber ausgeliefert und damit beschleunigt wird.

Verwendet Subresource Integrity (SRI): SRI erlaubt es, eine Integritätsprüfung (einen Hash) anzugeben, um sicherzustellen, dass der heruntergeladene Inhalt nicht verändert wurde. Hier ein Beispiel:

<script src="https://cdnjs.cloudflare.com/polyfill/v3/polyfill.min.js?version=4.8.0" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxFf/2g+7t1LZ8q7v6AJN0GRd3vZ1sT" crossorigin="anonymous"></script>

Mit SRI wird das Skript nur geladen, wenn der Hash des heruntergeladenen Skripts mit dem angegebenen Hash übereinstimmt. Wenn der Inhalt geändert wurde, lädt der Browser das Skript nicht.

Verwendet Content Security Policy (CSP): Implementiert eine Content Security Policy, um zu kontrollieren, welche Skripte und Ressourcen auf euren Webseiten geladen werden dürfen. Eine CSP kann das Nachladen von Schadcode von nicht autorisierten Domains unterbinden. Zum Beispiel hätte eine CSP in diesem Fall das Laden von Schadcode von www.googie-anaiytics.com verhindert.

Um CSP in einer nginx-Konfiguration zu aktivieren, könnt ihr folgenden Code verwenden:

add_header Content-Security-Policy "script-src 'self' https://cdnjs.cloudflare.com/polyfill/v3/polyfill.min.js?version=4.8.0";

Diese Richtlinie erlaubt nur Skripte von der eigenen Domain (self) und von cdnjs.cloudflare.com. Da der Schadcode von einer anderen Domain nachgeladen wird, hätte die CSP dies verhindert.

Bleibt informiert: Abonniert Sicherheitsupdates und informiert euch regelmäßig über potenzielle Bedrohungen.

Indem ihr diese Maßnahmen befolgt, könnt ihr das Risiko von Supply Chain Angriffen erheblich reduzieren und die Sicherheit eurer Websites gewährleisten.

Wir freuen uns sehr, euch unsere brandneue Website zu präsentieren. Seit unserer Gründung im Jahr 2012 haben wir kontinuierlich daran gearbeitet, nicht nur eine zuverlässige, sondern auch intuitive Hosting-Plattform anzubieten. Unsere Website hinkte dabei den aktuellen Entwicklungen immer ein bisschen hinterher, aber das ändert sich nun.

Unsere neue Website deckt jetzt umfassender als zuvor alle unsere Leistungen ab, von Apps über Domains bis hin zum E-Mail-Hosting. Wie immer legen wir großen Wert auf Einfachheit. Die Inhalte sollen klar und verständlich sein. Wir hoffen, das ist uns mit der neuen Website gelungen. Uns ist wichtig, dass neue Kund:innen noch besser als zuvor unsere Philosophie für ein faires und nachhaltiges Hosting-Angebot begreifen.

Wir sind auch sehr stolz, so viele positive Kund:innenstimmen für unsere Website erhalten zu haben. Besonders unser Support wird hier immer wieder lobend erwähnt. Um den Support gar nicht erst notwendig zu machen, haben wir die Produktseiten um passende Fragen und Antworten ergänzt, die wir häufig erhalten. Das einfache Preismodell ist dort ebenfalls zu finden.

Nicht weniger stolz sind wir darauf, wie gut unsere Website beim Website Carbon Calculator abschneidet. Dies unterstreicht unsere Bemühungen zu einem sauberen und effizienten Hosting-Angebot.

Für die Entwicklung unserer Website haben wir auf Next.js und Tailwind UI gesetzt, zwei herausragende Tools, die es ermöglichen, eine schnelle, responsive und ästhetisch ansprechende Websites zu kreieren. Vielen Dank an die Macher:innen dieser tollen Tools 🙏

Und nun viel Spaß mit der neuen Website ✨

Foto von OC Gonzalez (unsplash.com)

Entdecke die neueste Version bereits bei Servivum

Wir freuen uns, eine spannende Nachricht mit euch zu teilen: PHP 8.3 ist nun offiziell veröffentlicht und bei Servivum verfügbar! Nach einer erfolgreichen Testphase mit dem Release Candidate, in der wir wichtige Erkenntnisse sammeln konnten, steht dir jetzt die finale Version von PHP 8.3 zur Verfügung.

Was bedeutet das für dich? Die finale Version von PHP 8.3 bringt eine Fülle von Verbesserungen und neuen Features, die deine Entwicklungserfahrung auf ein neues Niveau heben werden. Von optimierter Performance bis hin zu neuen Sprachfunktionen – PHP 8.3 ist darauf ausgerichtet, deine Applikationen effizienter, schneller und sicherer zu machen.

Einige Highlights von PHP 8.3 umfassen:

• Verbesserte Performance: Genieße eine schnellere Ausführung deiner Anwendungen dank weitreichender Optmierungen.
• Neue Sprachfeatures: Entdecke neue Sprach-Features, die es dir ermöglichen, eleganteren und update-freundlicheren Code zu schreiben.
• Erhöhte Sicherheit: Mit verbesserten Sicherheitsmechanismen kannst du sicher sein, dass deine Anwendungen noch robuster gegenüber Bedrohungen sind.

Die Umstellung auf PHP 8.3 ist einfach. Wenn du bereits den Release Candidate genutzt hast, braucht du nichts weiter tun. Wir kümmern uns um das Update. Falls du noch bei einer älteren Version bist, kannst du ganz unkompliziert über unser Servivum App die Version für jede deiner Applikation anpassen.

Als große PHP-Fans sind wir bei Servivum stolz darauf mit PHP 8.3 den nächsten wichtigen Meilenstein in der technologischen Entwicklungen anbieten zu können. Uns ist es wichtig, dass wir dir die Tools bieten, die deine tägliche Arbeit verbessern.

Für weitere Informationen zu den neuen Funktionen von PHP 8.3 schau auf der offiziellen Seite vorbei oder bei den Kolleg:innen von Laravel News. Viel Spaß!

Foto von Mohammad Rahmani (unsplash.com)

Wir haben tolle Neuigkeiten. Ab sofort bieten wir für unsere Servivum Apps PHP in der Version 8.3 als Release Candidate an. Was das bedeutet? Du hast schon jetzt die Möglichkeit, die brandneuen Features von PHP 8.3 zu testen.

Derzeit läuft bei uns der Release Candidate 4 (RC4). Die finale Version von PHP 8.3 wird voraussichtlich am 23. November 2023 veröffentlicht. Bis dahin werden wir dich natürlich mit allen weiteren Release Candidates versorgen und auch die finale Version wird dir automatisch zur Verfügung stehen.

Was genau ist ein Release Candidate? Ein Release Candidate (RC) ist quasi die "Generalprobe" vor der großen Premiere. Es ist eine Version, die fast fertig ist und nur noch auf das finale Go wartet. Hier und da kann es noch kleine Unstimmigkeiten geben, aber genau dafür ist ein RC da: Die letzten Fehler auszumerzen.

Weitere Informationen zu PHP 8.3 findest du in diesem Artikel von Zend.

Wir bemühen uns bei Servivum immer am Puls der Zeit zu sein und freuen uns sehr, dir diese Neuerung präsentieren zu können. Probiere PHP 8.3 aus und lass uns wissen, wie es dir gefällt!

Foto von Ben Griffiths (unsplash.com)

Lange wurde hier im Blog nichts mehr geschrieben, aber nun möchte ich das Schreiben wieder aufnehmen. Bitte entschuldigt, wenn der Satzbau noch etwas holprig ist. Das wird sich mit den kommenden Artikel alles wieder finden.

Ich möchte heute ein paar Worte über die Einrichtung eines Servers mit Docker, also einem Docker-Host verlieren.

Für den schnellen Going-Live einer Applikation bietet sich noch immer ein Root-Server, egal ob Bare Metal oder VM, an. VMs gibt es mittlerweile wie Sand am Meer und man ist noch nicht mal gezwungen zu einem der drei Großen (AWS, Azure, Google Cloud) zu gehen. Empfehlen kann ich beispielsweise die VMs in der Hetzner Cloud.

Ich gehe in diesem Beispiel von einer Maschine mit Debian Buster aus, zu der ihr Root-Zugang erhalten haben solltet. Debian ist bei mir das Mittel der Wahl, weil es im Verhältnis zu einigen anderen Distributionen, wie beispielsweise Ubuntu noch mal deutlich schlanker daherkommt. Weniger Pakete reduzieren den Update-Aufwand und die möglichen Angriffsvektoren. Das Host-System muss ja auch eigentlich gar nicht viel können. Im Gegenteil: Ich möchte es sauber halten, um mich vom Wirt nicht zu stark abhängig zu machen und ihn im Zweifel auch schnell wieder ersetzen zu können - parasite mode on!

Docker Engine - der Stoff aus dem die Träume gemacht sind 🐳

Die offizielle Dokumentation beschreibt ziemlich gut, wie man Docker auf der Maschine installiert bekommt. Ein paar Gedanken dazu:

1. Ich nutze grundsätzlich die Installation mittels Repository, worauf in diesem Artikel auch der Fokus liegt.
2. Eine Ausnahme stellt nur die Installation von Docker auf einem RaspberryPi dar. Da dies über das Repository nicht funktioniert. Dann greife ich auf das Convenience Script zurück.
3. Das Anpinnen einer bestimmten Docker-Version ist sinnvoll, allerdings versuche ich immer mit der aktuellen stabilen Version zu arbeiten. Derzeit ist das 19.03.5. Ich pinne die Version also in der Regel nicht an.

Auf der Debian-Maschine wird durch den Root-Login kein sudo genutzt. Das können wir also weglassen.

Zunächst wird der Paket-Index aktualisiert:

apt-get update

Als nächstes werden die Abhängigkeiten installiert:

apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg2 \
    software-properties-common

Jetzt lädt man den GPG-Schlüssel von Docker, um die Signierung des Pakets zu überprüfen:

curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -

Anschließend kann man den Fingerprint des Paketes überprüfen:

apt-key fingerprint 0EBFCD88

Nun wird dem Paket-Manager apt eine neue Quelle hinzugefügt, über die die Docker-Engine heruntergeladen werden kann:

add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/debian \
   $(lsb_release -cs) \
   stable"

Jetzt wird der Paket-Index erneut aktualisiert und Docker installiert:

apt-get update
apt-get install docker-ce docker-ce-cli containerd.io

Anschließend kann man einen ersten Hallo-Welt-Container starten, um die Funktionsfähigkeit von Docker zu überprüfen.

docker run hello-world

Erhält man eine passende Ausgabe, haben wir Docker erfolgreich installiert.

Nützliches

Ein paar nützliche Helfer dürfen es natürlich doch sein:

apt install fail2ban git htop nano mc rsync sudo unzip

• fail2ban blockt ungewünschte SSH-Verbindungen
• git kann man für die Arbeit mit Git-Repos immer gebrauchen
• htop für die Anzeige der Auslastung in einer moderneren Darstellung als es top ermöglicht.
• nano: Ja, ich nutze nano und nicht vi oder vim
• mc: Manchmal finde ich die Darstellung des Midnight Commanders auch ganz praktisch.
• rsync ist ideal, um Daten auch über die Grenzen von Maschinen hinweg zu bewegen
• sudo macht für das Herabsetzen von Nutzerprivilegien Sinn.
• Um mit gezippten Daten zu arbeiten, macht auch unzip Sinn.

Hierbei bringt jeder sicherlich noch seine persönlichen Präferenzen ein, aber diese Liste soll ein erster Anhaltspunkt sein.

Post-Installation Steps

Wie in der offiziellen Doku erwähnt, kann man nun auch noch weitere Maßnahmen ergreifen, sobald die Docker Engine installiert ist. Interessant finde ich die Einrichtung eines weiteren Systemnutzers, damit man nicht immer auf den Root-Nutzer zurückgreifen muss, wenngleich der zusätzliche Systemnutzer Zugriff auf den Docker-Socket bekommt und dadurch Root-ähnliche Rechte erhält. Docker rootless zu betreiben ist seit Längerem ein Thema. Hier kann man dazu Weiteres lesen.

Zurück zum Thema! Bei der Docker-Installation unter Debian wird bereits eine Gruppe "docker" angelegt. Es braucht also nur noch einen eigenen Systemnutzer und anschließend weisen wir dem die Docker-Gruppe zu.

adduser deploy
usermod -aG docker deploy

Anschließend sollte es möglich sein einen Hallo-Welt-Container als Nutzer "deploy" zu starten.

su deploy
docker run hello-world

Wenn man auch nun wieder wieder Ausgabe des Containers sehen kann, hat die Einrichtung funktioniert.

Kernel Tweaks

Docker setzt im Wesentlichen auf Features des Linux-Kernels, wie chroot, Namespaces, etc. Der Kernel ist somit essentiell für das Betreiben von Containern. Über die Jahre haben sich so einige Probleme mit Limits, die im Kernel gesetzt sind ergeben. Auf manche stößt man recht schnell. Beispielsweise beim Starten von Redis oder Elasticsearch, wird man darauf hingewiesen gewisse Einstellungen zu tätigen, um die volle Leistung nutzen zu können. Auf andere Probleme stößt man erst, wenn man die 10. MySQL-Instanz auf der Maschine starten möchte.

Es folgen meine Kernel Tweaks, die sich im Laufe der Jahre durch den langen Betrieb von Containern ergeben haben. Diese lege ich in einer eigenen Datei unter /etc/sysctl.d/80-docker.conf ab.

# Elasticsearch optimization
vm.max_map_count=262144

# MySQL optimization
fs.aio-max-nr=1048576

# Redis optimization
vm.overcommit_memory=1
net.core.somaxconn=65535

# Have a larger connection range available
net.ipv4.ip_local_port_range=1024 65000

# Reuse closed sockets faster
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_fin_timeout=15

# The maximum number of "backlogged sockets".  Default is 128.
# net.core.somaxconn=4096
net.core.netdev_max_backlog=4096

# 16 MB per socket - which sounds like a lot, but will virtually never consume that much.
net.core.rmem_max=16777216
net.core.wmem_max=16777216

# Various network tunables
net.ipv4.tcp_max_syn_backlog=20480
net.ipv4.tcp_max_tw_buckets=400000
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_syn_retries=2
net.ipv4.tcp_synack_retries=2
net.ipv4.tcp_wmem=4096 65536 16777216
#vm.min_free_kbytes=65536

# Connection tracking to prevent dropped connections (usually issue on LBs)
net.netfilter.nf_conntrack_max=262144
# Error by setting the following: cannot stat /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout: No such file or directory
net.ipv4.netfilter.ip_conntrack_generic_timeout=120
net.netfilter.nf_conntrack_tcp_timeout_established=86400

# ARP cache settings for a highly loaded Docker Swarm
net.ipv4.neigh.default.gc_thresh1=8096
net.ipv4.neigh.default.gc_thresh2=12288
net.ipv4.neigh.default.gc_thresh3=16384

System sauber halten

Trotz schlanker Container, wird beim kontinuierlichen Bauen und Ausrollen neuer Versionen das System doch schnell voll. Dafür bietet Docker die Prune-Befehle, die ich auch in diesem Artikel thematisiert habe, allerdings nutze ich die darin beschrieben automatischen Möglichkeiten so nicht mehr. Mittlerweile ist dafür ein eigenes Projekt entstanden, welches auf GitHub zu finden ist.

Beim Deployment von Containern setze ich auf den Swarm Mode und so starte ich den Service zum regelmäßigen Aufräumen der Maschine als Docker Stack.

Zunächst lade ich das Compose-File dazu in einen neuen Ordner:

mkdir -p /var/www/srv-cleanup
cd /var/www/srv-cleanup
wget https://raw.githubusercontent.com/servivum/docker-host-cleanup/master/docker-compose.production.yml

Nun initialisiere ich den Swarm Mode und starte den Stack:

docker swarm init
docker stack deploy -c docker-compose.production.yml srv-cleanup

Abschließend kann man noch einen Blick darauf werfen, ob der Dienst erfolgreich gestartet wurde, was natürlich etwas dauert, da zunächst noch das Container-Image aus dem Docker Hub geladen werden muss.

docker stack services srv-cleanup

Abschließende Gedanken

Um ein produktives System zu betreiben, reichen diese Maßnahmen natürlich noch nicht aus. Es braucht ein Backup-and-Restore-Konzept, sowie ein Monitoring, welches über den Zustand der Maschine berichtet.

Interessant ist zudem, wie man Web-Applikationen schnell und einfach mit HTTPS-Verschlüsselung online bringen kann. Diesem Thema widme ich mich in einem der kommenden Beiträge.

Bild von Taylor Vick

Nach vielen vielen gebauten und gestarteten Containern möchte ich ein paar praktische Tipps zum Image-Bau geben, die einem das Leben erleichtern. Entstehen soll ein ganzheitlicher Blick von der lokalen Entwicklungsumgebung, über das Bauen und Testen in der Continuous Delivery Pipeline, bis zum Betrieb in Produktion.

Beware of the Layers

Eine der ersten Regeln, die man sich beim Bau von Images vor Augen führen sollte, ist das Kombinieren von Befehlen, um keine unnötigen Layer zu erzeugen. Dateien, die in einem Layer erzeugt wurden, können in einem anderen Layer nicht mehr entfernt werden, um Speicherplatz zu reduzieren.

# Do
RUN apt-get update && \
    apt-get install -y \
    package-bar \
    && \
    rm -rf /var/lib/apt/lists/*

# Don't
RUN apt-get update
RUN apt-get install package-bar
RUN rm -rf /var/lib/apt/lists/*

Zudem spielen Layer eine wichtige Rolle, wenn es um die Build-Geschwindigkeit geht, da hier der Build Cache für Beschleunigung sorgt.

Ein Dockerfile dem Befehl „docker container commit“ vorziehen

Man muss kein Dockerfile als Basis für seine Applikation nutzen. Stattdessen kann man auch einfach einen Basis-Container mit der Linux-Distribution meiner Wahl hochfahren, um „from scratch“ zu starten. Anschließend kann man manuell seine Applikation und Abhängigkeiten über die Shell hinzufügen. Mit docker container commit lässt sich dann der Container wieder als Image verpacken. Für ein erstes Rumprobieren halte ich diese Vorgehensweise für nützlich und zielführend.

Im Gegensatz dazu, steht die Möglichkeit ein Image basierend auf einem Dockerfile zu bauen. In dieser textlichen Form ist es versionierbar, ist dadurch auch für die Kollegen nachvollziehbar und sorgt für eine bessere Automation und Reproduzierbarkeit, die im Umfeld von CI/CD sehr wichtig ist. Wer seit Längerem mit Continuous Delivery Pipelines zu tun hat, weiß aber, dass externe Abhängigkeiten die Reproduzierbarkeit torpedieren können. Wenn der Server, von dem ich eine Abhängigkeit wie ein Tar-Ball oder dergleichen beziehe, offline ist, habe ich trotzdem ein Problem. Das sollte man im Hinterkopf behalten.

It runs on my laptop != It runs in production ⚠️

Wir alle kennen das: Das gerade frisch entwickelte neue Feature funktioniert tadellos auf der eigenen Maschine, aber nicht in Produktion. Die Docker-Container sollen dies aufgrund ihrer Parität (Parity) jedoch minimieren. Ich schreibe bewusst minimieren, denn wir verfolgen mit den verschiedenen Umgebungen verschiedene Interessen. Lokal wollen wir schnell und komfortabel entwickeln. In der Test-Umgebung soll möglichst automatisiert eine Überprüfung der Qualität statttfinden. Auf dem Produktivsystem wünschen wir uns, dass die Applikation möglichst 24/7 erreichbar ist. Das fasst die Ziele natürlich nur ganz grob zusammen, aber ein grundsätzlicher Unterschied, der dadurch entsteht, ist die Verwendung von Volumes in der Produktivumgebung, die nicht die Applikation, sondern nur die Daten persistieren sollen. Lokal arbeitet man in der Regel so, dass die komplette Applikation aus dem Git-Repository ausgecheckt wird und auf der Host-Maschine liegt. Host-Mounts, die unsere Änderung in die gestarteten Container bringen, werden dadurch notwendig. Bereits das ist ein Unterschied, der nicht zu vernachlässigen ist und es geht weiter mit dem Orchestrator. Lokal arbeitet man unter Umständen mit Docker-Compose und das verteilte Live-System wird mit Docker Swarm gesteurt. Eine Anwendungen zentral auf einer Entwicklungsmaschine zu betreiben unterscheidet sich vom Betrieb in verteilten Systemen.

In meinen Augen sollte man daher dafür sorgen, dass zumindest die Images in allen Umgebungen identisch sind. Da ein Dockerfile die Basis für ein Image darstellt, ist es auch der Ausgangspunkt, um eine möglichst große Parität zu erhalten. Ein Image muss daher über die notwendige Intelligenz verfügen, lokal in Debugging-Szenarien zur Seite zu stehen, was in Production mittels Environment Variable oder reingerichter Konfigurationsdatei deaktiviert wird. Das Image stellt also den gemeinsamen Nenner dar und kann mittels Host-Mounts, Ports, Env-Variablen, Secrets und Configs an die jeweilige Umgebung angepasst werden. Das Thema Sicherheit steckt hier natürlich die Grenzen ab. Am Ende wollen wir nicht den lokalen Komfort in der Entwicklung über die Sicherheit im Produktivsystem stellen.

DevOps 👯‍♂️

Ich bin ein Freund des Ansatzes „You build it, you run it!“, der im Zusammenhang mit dem DevOps-Ansatz immer wieder Erwähnung findet. Als Entwickler*in bekommt man mit Docker ein Werkzeug an die Hand, wodurch man sich zwangsläufig mehr mit der Laufzeitumgebung Gedanken machen muss, die man zuvor in Ops Händen gesehen hat. Dadurch stellt sich ein breiteres Wissen selbst bei den Technologien ein, die man bereits jahrelang genutzt hat. Als PHP-Entwickler*in lernt man, wie der FastCGI Process Manager (FPM) arbeitet, wo er seine Log-Dateien und sein Process File ablegt. In meinen Augen bekommt man einen ganzheitlicheren Blick, den man für das Betreiben in der Live-Umgebung auch wirklich benötigt. Menschen, die man klassischer Weise Operations zuordnen würde, fungieren mehr als Makro-Architekten und stecken die Grenzen für Entwickler*innen ab, welche mit Containern sehr viel mehr Freiheiten bekommen.

Offizielle Images

Nutzt die offiziellen Images! Sie stellen ein absolut solides Fundament für eure Applikation dar und werden von Leuten betreut, die sich damit auskennen. Dinge selbst von der Pieke auf zu erstellen, sorgt für einen gehörigen Aufwand, den man nicht unterschätzen sollte. Schnell hat man sich ein Image aus dem Docker Hub geladen und zum Laufen gebracht, aber wer garantiert einem, dass dieses Image sicher ist oder in einem halben Jahr noch gepflegt wird? Mit den offiziellen Images haben die Verantwortlichen bereits ihren langen Atem bei der Pflege der Software-Pakete bewiesen.

Alpine Linux

Es lohnt sich mit dem kleinen Alpine Linux und dessen Paket Manager auseinander zu setzen. Meine ersten Docker-Gehversuche habe ich mit Debian gestartet, weil mir apt vertraut war. Nachdem ich mich mit Alpine auseinander gesetzt habe, kann ich euch nur wärmstens dazu raten, denn die kleinen Images machen beim Bewegen und Bauen extrem viel Spaß. Die CI-/CD-Pipeline wird enorm beschleunigt und auch die lokale Entwicklungsumgebung ist in Nullkommanichts aufgesetzt. Spaß beim Entwickeln ist in meinen Augen ein unterschätztes Gut, was es als Verantwortlicher zu jeder Zeit zu wahren gilt. Das einzig Negative, was ich über Alpine Linux berichten kann, ist der verwendete C Compiler, der in seltenen Fällen für Probleme sorgt und das ein oder andere Derivat an CLI-Tools, was sich vielleicht doch etwas vom Original unterscheidet. Ein Blick wert ist es aber auf jeden Fall und wenn es nur der schmale Footprint ist. Ja auch als Entwickler*in kann man seinen Beitrag zum Umweltschutz leisten. 🌳

Dockerfile Best Practices

Docker selbst hat in seiner Dokumentation Best Practices zum Schreiben von Dockerfiles definiert, die jeder mal gelesen haben sollte. Zur Überprüfung des Regelwerks wurden ein paar Linter-Projekte ins Leben gerufen. Eine Empfehlung dafür kann ich bisher jedoch noch nicht aussprechen.

.dockerignore

Die Datei .dockerignore bekommt für mein Empfinden zu wenig Aufmerksamkeit, obwohl sie den Build-Prozess ähnlich stark beeinflussen kann, wie das schlanke Alpine Linux. Dazu muss man sich jedoch vor Augen führen, wie aus dem Dockerfile ein Image gebaut wird. Wichtig bei diesem Vorgang ist der sogenannte Kontext. Das ist ein Ort, aus dem sich Docker beim Bau von Images bedient, um Anweisungen wie COPY auszuführen. Dateien werden also nicht direkt vom lokalen Dateisystem in das Docker-Image kopiert, sondern gehen einen Umweg über den Kontext. Der Kontext entspricht, wenn nicht anders definiert, dem Ordner in dem ich docker image build .ausführe. Alle Dateien und Ordner innerhalb dieses Verzeichnisses werden also vor dem eigentlichen Build-Prozess zum Docker Daemon übertragen, was bei großen Projekten einige Zeit in Anspruch nimmt, nur um anschließend Dinge aus diesem Kontext ins finale Image zu kopieren. Hier kommt die Datei .dockerignore ins Spiel. Damit kann man, ähnliche Gits „.gitignore“, Dateien und Ordner ausnehmen, damit diese nicht zum Docker Daemon übertragen werden. Klassische Einträge dieser Datei umfassen den Ordner .git, die Dokumentation des Projektes, Pipeline as Code, Infrastructure as Code, Secrets, die im finalen Container nichts zu suchen haben. Mit dieser Datei auseinander gesetzt, kann man die CI/CD Pipeline spürbar beschleunigen.

Build and Runtime Dependencies

Mach dir Gedanken darüber, welche Abhängigkeiten es zur Laufzeit und welche es zur Build Time gibt. Ein Beispiel wäre make zum Kompilieren, welches zur Laufzeit nicht benötigt wird und entsprechend in einem Layer installiert, damit kompiliert und anschließend wieder entfernt werden kann. Gleichzeitig sollte man eine Entwickler*in nicht einschränken. Wenn er makebenötigt, muss das Tool natürlich auch im Container zur Verfügung stehen.

Labels

Das absolute Mindestmaß an Metadaten, das ein Image-Bauer zur Verfügung stellen sollte, sind sein Name und die Kontaktdaten. So sieht man schnell, wer diese Datei verzapft hat und kann sich bei Fragen an ihn wenden. Wer sich hier mehr wünscht, kann sich mit dem Label Schema beschäftigen, welches dafür eine Spezifikation liefert (veraltet). Alternativ kann man bei Project Atomic oder der Open Container Initiative in entsprechende Entwürfe einarbeiten.

FROM golang:1.9.2-alpine3.7
LABEL maintainer "Patrick Baber <patrick.baber@ueber.io>"

Multi-Stage-Builds

Diesem Thema habe ich einen eigenen Artikel gewidmet, weil es sich um eine mächtige Möglichkeit handelt, ein Image basierend auf mehreren Base-Images zu erstellen. Assets bauen, mit Node, die man dann in ein nginx-Image kopiert. Solche Dinge werden damit möglich.

Abschließendes Gebrabbel

Es lohnt sich in schlanke und robuste Images zu investieren. Die Lernkurve ist meiner Meinung nach nicht besonders steil, da man sich den verschiedenen Themen peu à peu annehmen kann, ohne gezwungen zu sein, gleich alles zu erledigen. Im Fokus sollte die Verwendbarkeit des Images in den verschiedenen Umgebungen stehen, was zwar ein wenig zusätzliche Logik erfordert, sich aber zur Freude von Dev und Ops lohnen wird.

Bild von Nick Hirche

Applikationscontainer sind vor allem als isoliert laufende Prozesse zu sehen, weshalb der Vergleich mit virtuellen Maschinen stark hinkt. Nichtsdestotrotz gibt es Szenarien, in denen mehr als ein Prozess im Container Sinn macht. supervisor als selbsternanntes „Process Control System“ hilft hier weiter.

supervisor kommt aus der Prä-Container-Ära und hilft bei der Verwendung simpler Programme, die vielleicht kein eigenes Prozess-Management mitbringen. Damit lässt sich beispielsweise die Ausgabe eines Prozesses fangen und diese in ein Logfile schreiben oder wacklige Tools können damit neu gestartet werden. SIGTERMS zu den Subprozessen werden auch weitergeleitet. Wird supervisord angewiesen sich zu beenden, leitet es dies also an seine Subprozesse weiter.

Die Einsatzmöglichkeiten sind vielfältig, wie ein kurzer Blick in die Dokumentation zeigt. Weitere Tools in dem Bereich sind runit und S6. Ich greife gern auf supervisor zurück, weil es in den meisten Distributionen enthalten ist und damit schnell installiert und auch eingerichtet ist. Wer es leichtgewichtiger mag, kann auch über ein Bash-Skript nachdenken, wie es in der offiziellen Docker-Doku skizziert wird.

OK, wie machen wir's?

Ziel soll es sein, PHP zusammen mit einem Cronjob laufen zu lassen. Legen wir los und betrachten das folgende Dockerfile.

FROM php:7.2-fpm-alpine
LABEL maintainer "Patrick Baber <patrick.baber@ueber.io>"

# Install supervisor
RUN apk --update add supervisor

# Configure supervisor
COPY supervisord.conf /etc/supervisor/supervisord.conf

# Configure cron
COPY crontab /etc/cron/crontab

# Init cron
RUN crontab /etc/cron/crontab

# Run supervisor
CMD ["supervisord", "-c", "/etc/supervisor/supervisord.conf"]

Uns soll zunächst ein einfaches PHP-Image als Fundament dienen. Dann installieren wir das Paket supervisor und kopieren dafür die Konfigurationsdatei. Es folgt alles Notwendige für cron. Was das ist, kann meinem vorigen Artikel entnommen werden.

Abschließend definieren wir das Kommando, welches später im Container laufen soll, dem wir den Pfad zur Konfigurationsdatei übergeben.

Spannend wird nun der Inhalt der Datei supervisord.conf, die im selben Verzeichnis abgelegt ist.

[supervisord]
logfile = /dev/null
loglevel = info
pidfile = /var/run/supervisord.pid
nodaemon = true

;[include]
;files = /etc/supervisor/conf.d/*.conf

[program:php-fpm]
command = php-fpm
autostart = true
autorestart = true
stdout_logfile = /dev/stdout
stdout_logfile_maxbytes = 0
stderr_logfile = /dev/stderr
stderr_logfile_maxbytes = 0

[program:crond]
command = crond -f
autostart = true
autorestart = true
stdout_logfile = /dev/stdout
stdout_logfile_maxbytes = 0
stderr_logfile = /dev/stderr
stderr_logfile_maxbytes = 0

Die Syntax entspricht einer klassischen .ini-Datei, die über Sections in eckigen Klammern strukturiert wird.

[supervisord]

In der ersten Section wird der Daemon (supervisord) konfiguriert, den wir bereits in der ersten Zeile dazu anleiten kein Daemon zu sein, damit der Prozess im Vordergrund läuft und seine Ausgaben nach stdout schreibt, wie man sich das bei Docker-Containern wünscht. Ein zusätzliches Logfile benötigen wir daher nicht, weshalb wir es mit logfile = /dev/null deaktivieren.

[include]

Wer sich mehr Struktur wünscht, kann seine Konfiguration auch in mehrere Dateien aufteilen, was gerade bei der Verwendung vieler Prozesse innerhalb des Containers Sinn macht, allerdings führt man damit das Prinzip der isolierten Prozesse ad absurdum. Die include-Anweisung ist dennoch recht nützlich, weshalb ich sie auskommentiert hier aufgenommen habe.

[program:XYZ]

Hier sind wir nun beim spannenden Teil angelangt. Wir können nun für jedes Programm, einen eigenen Abschnitt definieren, der als zentrale Eigenschaft vor allem das Kommando zum Starten des Prozesses benötigt. Man merkt, ich verwende Programm und Prozess hier synonym. Vorbereitet ist eine Sektion für php-fpm, was im offiziellen PHP-Image von dem wir ableiten, der einzige Prozess wäre, gefolgt von einem Abschnitt für den zweiten Subprozess crond -f. Ich habe hier keinerlei crontab, die den Cronjob auch nur eine Sache ausführen lassen würde, aber dies soll nur als Beispiel dienen. Wer einen vollwärtigen Cronjob nutzen möchte, schaut bitte in diesen Artikel. autorestart startet die Anwendung neu, ob sie bewusst oder unbewusst heruntergefahren wurde. Es folgen nun Einstellungen, welche die Programmausgabe von stdout und stderr direkt an Docker weiterleiten.

Bevor wir uns ans Bauen des Images machen können, benötigen wir noch die crontab, die in der Realität eher ein PHP-Skript asychron zum herkömmlichen Aufruf per FastCGI ausführt. Hier übernehme ich einfach die Crontab aus meinem vorigen Artikel, die für eine einfache Shell-Ausgabe sorgt. Zur Veranschaulichung unseres Vorhabens soll das aber reichen.

* * * * * echo "Hello world" >> /dev/stdout 2>&1
# crontab requires empty line at end of file

Build 'n' Run

Das Image kann nun gebaut und der Container gestartet werden.

# Build
docker image build -t supervisor-image .

# Run
docker container run --rm --name supervisor-container supervisor-image

Es folgt die Ausgabe des Containers.

2017-12-11 16:17:50,592 CRIT Supervisor running as root (no user in config file)
2017-12-11 16:17:50,593 INFO supervisord started with pid 1
2017-12-11 16:17:51,597 INFO spawned: 'php-fpm' with pid 9
2017-12-11 16:17:51,599 INFO spawned: 'crond' with pid 10
[11-Dec-2017 16:17:51] NOTICE: fpm is running, pid 9
[11-Dec-2017 16:17:51] NOTICE: ready to handle connections
2017-12-11 16:17:52,624 INFO success: php-fpm entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2017-12-11 16:17:52,624 INFO success: crond entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Hello world
Hello world

Die erste Meldung lässt einen direkt unangenehm aufstoßen. Sie lässt sich vermeiden, indem man supervisord durch einen anderen Benutzer startet. Die Rechte des Nutzers müssen allerdings für die Tätigkeit des Subprozesses reichen. Um beispielsweise einen Low-Port (< 1024) zu öffnen, braucht es root-Rechte oder zumindest die entsprechende Capability aus dem Kernel. Das Thema ist zu groß, um es in diesem Artikel zu behandelt, allerdings möchte ich darauf hinweisen.

Darüber hinaus entnehmen wir dem Log, dass supervisord korrekt startet und seine Subprozesse ebenfalls. Anschließend produziert PHP auch die erste Ausgabe - zu erkennen an der anderen Datumsformatierung. Das ist nicht ideal. Falls jemand weiß, wie man das eleganter lösen kann, dabei aber trotzdem die Infos bei Docker ankommen, gibt Bescheid.

Zusätzlich gibt es noch die Info von supervisord, dass es zufrieden mit den beiden Prozessen ist und ihren Zustand entsprechend als RUNNING definiert.

Nach spätestens einer Minute meldet sich dann auch crond mit seiner Testausgabe „Hello world“.

Die beiden Prozesse verrichten also, wie gewünscht, ihren Dienst. Ist also alles schnell umgesetzt. Viel Spaß mit mehreren Prozessen im Container!

Bild von Nick Hirche

Für zeitgesteuerte Aufgaben hilft noch immer das gute alte crond. In diesem Beitrag möchte ich zeigen, wie man auf Basis eines schlanken Alpine Linux wiederkehrende Befehle ausführt.

Ich beginne mit einer schmalen Datei (crontab) in Cron-Syntax. Die Ausgabe wird, wie für einen Docker-Container üblich, nach /dev/stdout geschrieben, damit Docker sie fangen und je nach gewählten Logging Driver (Beitrag dazu) verarbeiten kann. Im Standard lässt sich die Ausgabe einfach mit docker container logs verfolgen. Man beachte die Leerzeile am Ende der Datei (!!!).

* * * * * echo "Hello world" >> /dev/stdout 2>&1
# crontab requires an empty line at the end of the file

Nun brauchen wir einen Bauplan für unser Container-Image in Form des Dockerfiles. Ich gehe davon aus, dass unsere beiden Dateien im gleichen Verzeichnis liegen.

FROM alpine:3.8
LABEL maintainer "Patrick Baber <patrick.baber@ueber.io>"

# Configure cron
COPY crontab /etc/cron/crontab

# Init cron
RUN crontab /etc/cron/crontab

CMD ["crond", "-f"]

Um ein möglichst kleines Image zu erhalten, wähle ich als Base-Image alpine mit dem Tag 3.8, um eine konkrete Version im Sinne der Reproduzierbarkeit zu erhalten. Es wird unsere zuvor erstellte Datei im Image platziert. Der nachfolgende Schritt ist wichtig. Er führt crontab aus und veranlasst somit unsere Datei dorthin zu verschieben, wo sie crond erwartet. Nebenbei werden auch noch die Dateirechte angepasst. Zum Abschluss des Dockerfiles wird der Cron-Daemon im Vordergrund gestartet.

Wir haben nun alle Zutaten parat und beginnen mit dem Bau des Docker Images und starten im Anschluss unser Werk.

# Build
docker image build -t cron-image .

# Run
docker container run -d --rm --name cron-container cron-image

Ob alles funktioniert überprüfen wir in den Logs, die nach einem kurzen In-den-Stuhl-fallen-lassen die erwartete Meldung auch bereits zeigen.

$ docker container logs cron-container
Hello world
Hello world
Hello world

Das Image ist mit seinen knapp 4 MB nun bereit für größere Aufgaben. Es braucht also nicht immer ein „full-blown“ Ubuntu als Basis. Ein Blick in die Kommandozeilenhilfe von crond zeigt weitere interessante Einstellungen, wie das Log-Level.

Gern wird ein Cronjob auch im PHP-Umfeld gebraucht, um asynchrone Aufgabe anzustoßen. Tipp: Unter Umständen braucht es hier nur PHP als CLI und nicht den FPM (FastCGI Process Manager).

Bild von Noor Younis

Ja klar, Applikationscontainer sind klein und leichtgewichtig, aber durch Methoden, wie CI/CD werden die Release-Zyklen immer kleiner. Es wird also immer häufiger gebaut und verschifft. Dadurch entstehen zwar kleine, aber viele ungenutzte Images, Container, Volumes und Netzwerke.

So geschehen auf unserem Jenkins-Server. Um für Ordnung zu sorgen gibt es seit Docker Version 1.13 den Befehl docker system prune. Alternativ kann man auch kleinteiliger vorgehen und einen der folgenden Befehle nutzen:

# Remove unused images
docker image prune

# Remove all stopped containers
docker container prune

# Remove all unused volumes
docker volume prune

# Remove all unused networks
docker network prune

Auf der eigenen Entwicklungsmaschine reicht es sicher einen solchen Befehl gelegentlich mal auszuführen. Im Produktivsystem könnte man auf jedem Docker Host einen Cronjob einrichten, der regelmäßig einen solchen Aufräum-Befehle startet, allerdings gibt es eine elegantere Variante. Wir nutzen den Swarm Mode von Docker, der als Orchestrator die Möglichkeit besitzt Container auf den verschiedenen Nodes im Cluster laufen zu lassen. Wir halten also gleich unser gesamtes Docker Cluster sauber! Im Container benötigen wir dafür lediglich Docker CLI und den Docker Socket (/var/run/docker.sock) des Host-Systems, damit der Aufräum-Befehl auf dem Host ausgeführt werden kann. Den Code dazu findet ihr auf GitHub und das Image liegt im Docker Hub.

Einen eingerichteten Swarm Mode vorausgesetzt, könnt ihr die Putzfee per docker service create anstoßen oder per Stack File. Das Ganze sieht dann so aus:

# Option 1: docker service command
docker service create \
    --name docker-system-prune \
    --mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
    --mode global \
    --restart-delay 86400s \
    servivum/docker-system-prune

# Option 2: Docker stack file
docker stack deploy -c docker-compose.yml docker-system-prune

Für Option 2 wird natürlich noch das Compose File benötigt. Das findet man ebenfalls auf GitHub. --restart-delay 86400s sorgt dafür, dass einmal am Tag der Container neugestartet wird, denn nach dem Reinigungsprozess beendet sich der Container von selbst. Und so konnte ich auch unseren Jenkins-Server von Altlasten befreien: Total reclaimed space: 342.6GB

Bild von Jeshoots

Oft etwas vernachlässigt, bietet das Logging eine Möglichkeit, das diffuse Bild einer Container-Applikation aufzuklaren. Der generische Ansatz von Docker hilft dabei unterschiedlichsten Applikationen gerecht zu werden. Nach einer kurzen Einführung in das Docker-Logging soll dieser Artikel eine Anbindung an journald erläutern.

Starten der Demo-Applikation

Um ein Gefühl für Logging mit Docker zu erhalten, benötigen wir zunächst einen Applikationscontainer. Ein nginx, der als Webserver fungiert und im schlanken Alpine-Gewand daherkommt, erfüllt diesen Zweck hervorragend. Auf einem Linux-Host starten wir also den Container ...

$ docker container run -p 80:80 -d --name=web nginx:1.15-alpine

docker container logs

Anschließend rufen wir im Browser die Demo-Seite ein paar mal auf, da nginx jeden Aufruf protokolliert. Die Logs des Containers rufen wir über den Namen oder die ID ab. In unserem Fall mit docker container logs web. Zusätzlich gibt es noch eine Handvoll Flags für den Befehl, um beispielsweise genauere Timesstamps zu erhalten oder die Ergebnismenge einzugrenzen. Dies ist die Ausgabe der einfachen Befehlsform:

127.0.0.1 - - [21/Jul/2017:17:04:09 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36" "-"
127.0.0.1 - - [21/Jul/2017:17:04:10 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36" "-"
127.0.0.1 - - [21/Jul/2017:17:04:11 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36" "-"

Docker sammelt grundsätzlich alles, was die Applikation im Container in stdout und stderr schreibt. Im offiziellen Docker-Image des nginx linken die Standard-Logdateien „access.log“ und „error.log“ nach /dev/stdout und /dev/stderr, wie dem Dockerfile zu entnehmen ist. Ein Hand-Anlegen ist also nicht notwendig. Doch schauen wir uns den Container mit docker container inspect web doch mal genauer an:

[
    {
        // [...]
        "LogPath": "/var/lib/docker/containers/0c6f45-gekuerzt-json.log",
        // [...]
        "HostConfig": {
            // [...]
            "LogConfig": {
                "Type": "json-file",
                "Config": {}
            },
        },
        // [...]
    }
]

Unter dem angegebenen LogPath werden die von Docker gesammelten Logs auf die Festplatte geschrieben. Zudem wird angezeigt, welcher Logging Driver für den verwendeten Container im Einsatz ist. Standardmäßig ist das json-file. Ruft man diese mit cat /var/lib/docker/containers/0c6f45-gekuerzt-json.log direkt auf, sieht das formatiert so aus:

{
  "log": "127.0.0.1 - - [21/Jul/2017:17:04:10 +0000] \"GET / HTTP/1.1\" 304 0 \"-\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36\" \"-\"\n",
  "stream": "stdout",
  "time": "2017-07-21T17:04:09.625609119Z"
}
{
  "log": "127.0.0.1 - - [21/Jul/2017:17:04:11 +0000] \"GET / HTTP/1.1\" 304 0 \"-\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36\" \"-\"\n",
  "stream": "stdout",
  "time": "2017-07-21T17:04:10.591183632Z"
}
{
  "log": "127.0.0.1 - - [21/Jul/2017:17:04:12 +0000] \"GET / HTTP/1.1\" 304 0 \"-\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36\" \"-\"\n",
  "stream": "stdout",
  "time": "2017-07-21T17:04:11.134125994Z"
}

Wir erhalten einen deutlich tieferen Blick in Dockers Logging-Mechanismus und sehen zusätzlich noch aus welchem stream (stdout/stderr) der Log-Eintrag stammt und erhalten nun auch genaueren Zeitstempel. nginx schreibt übrigens beim Aufruf eines nicht vorhandenen Pfads, also bei einem Fehler 404, in stderr.

Logging Driver

Docker bringt von Hause eine Vielzahl von Logging Drivers mit. Neben dem Einsatz einer JSON-Datei können Logs beispielsweise zum syslog Daemon des Host-Systems übergeben werden. Das Graylog Extended Log Format, kurz gelf, kann gewählt werden, um die Log-Einträge an einen Graylog-Server oder Logstash zu übertragen. Produkte der bekannten Cloud-Provider sind natürlich ebenfalls nutzbar.

Ich möchte mich jedoch zunächst mit dem Treiber für journald beschäftigen. journald kommt zusammen mit dem Init-System systemd und ist bei diversen Linux Distributionen vorinstalliert. Als dedizierter Logging-Dienst beherrscht er unter anderem Logrotation, was json-file fehlt.

Die Zuweisung eines Logging Drivers kann auf vielen verschiedenen Ebenen stattfinden.

# Definition am Container
$ docker container run --log-driver journald --log-opt env=SOME_ENV_VAR [...]

# Definition am Service
$ docker service create --log-driver journald --log-opt env=SOME_ENV_VAR [...]

# Definition am Service im Docker Compose File
$ cat docker-compose.yml
version: "3"

services:
  web:
    image: nginx:1.12-alpine
    ports:
      - "80:80"
    logging:
      driver: "journald"
      options:
        env: "SOME_ENV_VAR"

An den Beispielen sieht man, dass je nach Log-Treiber auch noch Optionen übergeben werden können, wie Zugangsdaten zu einem externen Dienst. Welche das sind, erfährt man in der ausführlichen Dokumentation.

Logging im Docker Daemon

Neben den oben gezeigten Möglichkeiten zur Definition eines Logging-Treibers auf sehr kleinteiliger Ebene, können wir auch einen generellen Treiber im Docker Daemon bestimmen, der dann für die gestarteten Container genutzt wird. Laut Dokumentation wird nach dieser Config-Datei geschaut: /etc/docker/daemon.json. Unter Debian kann ich das nicht bestätigen. Hier ist noch ein zusätzlicher Kniff notwendig, aber der folgt nach dem Inhalt der JSON-Datei.

$ cat > /etc/docker/daemon.json << EOF
{
  "log-driver": "journald"
}
EOF

Unter Debian, und ich vermute auch Ubuntu, müssen wir dem Docker Daemon noch klarmachen, dass er die Config-Datei beim Start hinzuziehen soll. Wir erweitern daher das Docker-Profil in systemd und starten den Dienst anschließend neu.

$ mkdir -p /etc/systemd/system/docker.service.d
$ cat > /etc/systemd/system/docker.service.d/dockerd.conf << EOF
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --config-file /etc/docker/daemon.json
EOF
$ systemctl daemon-reload
$ service docker restart

In der Ausgabe von docker info taucht nun Folgendes auf: Logging Driver: journald

Verwendung von journald

Docker ermöglicht nun weiterhin die Nutzung von docker container logs web, da Docker mit journald umzugehen weiß, allerdings lassen sich die Logs nun auch mit dem journalctl abrufen. Beispielsweise so:

$ journalctl CONTAINER_NAME=webserver

Detailliert auf journald einzugehen, würde an dieser Stelle zu weit führen, weshalb ich auf die Dokumentation von journald und journalctl und den Eintrag zum Docker Logging Driver verweisen möchte.

Fazit

Zusammen mit den Healthchecks, die Aufschluss über den Gesundheitszustand unserer App geben und dem Monitoring, also dem Sammeln von Metriken, z. B. mit Prometheus, stellt das Logging ein essentielles Werkzeug zur Überprüfung dar. journald ist dabei nur eine von vielen verschiedenen Möglichkeiten, die Log-Einträge der Applikationscontainer zu sammeln. Gemessen am verwendeten Standard Logging Driver json-file, der als Basis-Einstellung zu verstehen ist, hat sich journald allerdings im Linux-Umfeld einen Namen gemacht und findet sich daher in diversen Linux Distros, wo es an die eigenen Anforderungen, wie Logrotation und Per­sis­tenz, angepasst werden kann. Es lohnt sich daher dem Thema Logging etwas mehr Aufmerksamkeit zu schenken.

Bild von Patryk Grądys

Am Beispiel einer PHP-Applikation auf Basis von Laravel möchte ich den Umgang mit Schema-Änderungen (Migrations) demonstrieren, die darauf warten müssen, dass ein benachbarter MySQL-Container bereit ist.

Zunächst ein schneller Blick auf das Stack-File, welches später mit docker stack deploy die Applikation startet. Die Datei ist etwas gekürzt, um den Fokus nicht zu verlieren. Zusätzliche Netzwerke sind ebenso entfernt, wie auch die Behandlung von TLS-Zertifikaten im nginx. Über die Eigenschaft deploy:, die in Swarm Clustern besonders nützlich ist, verliere ich später noch ein Wort.

version: "3.7"

services:
  nginx:
    image: registry.example.com/project/nginx
    ports:
      - "80:80"
  php:
    image: registry.example.com/project/php
    environment:
      ENV_FILE_SOURCE: /run/secrets/php_env
    secrets:
      - php_env
  mysql:
    image: mariadb:10.4
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root_password
      MYSQL_DATABASE_FILE: /run/secrets/mysql_name
      MYSQL_USER_FILE: /run/secrets/mysql_user
      MYSQL_PASSWORD_FILE: /run/secrets/mysql_password
    secrets:
      - mysql_root_password
      - mysql_name
      - mysql_user
      - mysql_password

secrets:
  php_env:
    file: secrets/php_env.txt
  mysql_root_password:
    file: secrets/mysql_root_password.txt
  mysql_name:
    file: secrets/mysql_name.txt
  mysql_user:
    file: secrets/mysql_user.txt
  mysql_password:
    file: secrets/mysql_password.txt

Für die Zugangsdaten sind die Docker Secrets im Einsatz, die in diesem Artikel genauer von mir erörtert werden. Das MariaDB-Image kann damit von Hause aus umgehen. Jeder einzelne Wert schlummert dabei in einer eigenen Datei und wird per Secret in den Dienst gegeben. Anschließend wird per Environment Variable der Pfad zum Secret übergeben. Das Secret php_env beinhaltet Laravels .env Datei.

Docker hochseetauglich

Zunächst einmal sollte man sich Gedanken über die Abhängigkeiten machen. nginx nimmt Anfragen der Benutzer entgegen und leitet diese an den PHP-Server weiter. Der PHP-Dienst, der die Projekt-Dateien beinhaltet, soll später den Befehl zur Datenbank-Migration ausführen und benötigt dazu eine Verbindung zum MariaDB-Server. Dabei ist allerdings Vorsicht geboten, denn nur weil der MariaDB-Container läuft, heißt es noch lange nicht, dass der Dienst auch per TCP erreichbar ist. MariaDB verhält sich da genau wie seine antiquierte Bruder MySQL und verrichtet allerlei Dinge, wie das Überprüfen von korrupten Tabellen, bevor es seine Schotten öffnet - doch dazu später mehr.

Leider berücksichtigt docker stack deploy die im Standard des Docker Compose Files nützliche Eigenschaft depends_on nicht, womit Dienste aufeinander warten, wenn sie einander bedingen. Darüber ist in den GitHub-Issues eine rege Diskussion entbrannt. Viele sind der Meinung, dass der Gesundheitszustand eines Containers, der mittels HEALTHCHECK überprüft wird, hinzugezogen werden sollte, bevor der davon abhängige Dienst gestartet wird. Auf der anderen Seite wird mit „Resilience“ argumentiert, denn die einzelnen Dienste sollten mit dem Ausfall eines benötigen Dienst umgehen können. Das Verhalten des Containers beim Ausrollen sei ja mit der in Version 3 integrierten Eigenschaft deploy steuerbar. Nachzulesen ist die Diskussion hier, hier und hier.

Asynchron, er arbeitet asynchron!

Die obige docker-compose.yml wird, nachdem die darin gebrauchten Images in der Registry abgelegt sind, auf einen Manager Node übertragen. Theoretisch ginge das auch über einen geöffneten Port des Docker Daemons, aber der müsste wieder abgesichert werden, was uns an dieser Stelle zu aufwendig ist. Aus diesem Grund landet die Datei per SCP, rsync oder Quantenteleportation auf dem Docker Swarm Manager unserer Wahl. Ich lege eine solche Datei meist in einen Ordner, wie /var/www/project, um zumindest die Stack-Definition dort liegen zu haben, denn dank Applikations-Containern liegen die Projektdaten dort nicht mehr.

Tipp: Der Swarm Mode lässt sich auch auf dem eigenen Rechner mit dem Befehl docker swarm init einrichten. Anschließend ist man in der Lage, Stack-Files auf der lokalen Maschine „auszurollen“. Im Hinterkopf sollte man nur behalten, dass das Cluster nur aus einem Node besteht, womit sich viele Probleme, wie die Beziehung zwischen Container und Volume, gar nicht ergeben.

Weiter im Text: Um einen Stack zu erstellen, nutzen wir nun also den folgenden Befehl.

docker stack deploy -c docker-compose.yml --with-registry-auth --prune mystack

Beim Pfad zur docker-compose.yml sollte man darauf achten, dass eventuell darin enthaltene Verknüpfungen wie z. B. env_file: .env-mysql nicht aufgelöst werden können, sollte man den oberen Befehl nicht aus dem Verzeichnis, in dem die Datei selbst liegt, aufrufen. Mit --with-registry-auth werden die Authentifizierungsinformationen im Swarm Cluster verteilt, damit andere Nodes in die Lage versetzt werden das geschützte Image aus der Registry zu laden. Vorausgesetzt wird dabei natürlich, dass auf dem Manager Node zuvor ein docker login durchgeführt wurde. Es kann auch nicht schaden, das mit in die CI-/CD-Pipeline mit aufzunehmen.

Achtung: Mit dem Flag --prune, der mit Version 17.05 Einzug gehalten hat, werden nicht mehr nötige Dienste automatisch entfernt.

Nun könnte jemand meinen, dass man sich jetzt einfach mit geschicktem Filtern die ID des PHP-Containers schnappt und mit docker exec CONTAINER_ID die Schema-Migration anstößt. docker stack deploy arbeitet allerdings asynchron. Nach Bestätigen des Befehls wird man nur kurz über die aus dem Stack-File resultierenden Dienste informiert und landet dann auch schon wieder im Shell-Prompt. Ein Großteil der Magie, wie das Erzeugen der Tasks, das Laden der Images und Starten der Container passiert im Hintergrund und braucht seine Zeit. Mit docker service ls lässt sich ein flüchtiger Blick auf die Spalte Replicas werfen. Bei 0/1 scheint er also noch nicht fertig zu sein. Alternativ lässt sich mit docker service ps --no-trunc SERVICE_ID ein Blick in die Tasks werfen oder es wird noch genauer mit docker service inspect SERVICE_ID. Sich anhand dieser Infos einen Prozess in seiner CI-/CD-Pipline zu bauen halte ich aber auch für etwas umständlich.

Entrypoint to the Rescue

Mein Tipp an dieser Stelle ist mal wieder der Gebrauch eines Shell-Scripts, welches im Container als ENTRYPOINT fungiert. Netter Nebeneffekt ist, dass unsere CI-/CD-Skripte schlanker werden und weitere Logik zum Betreiben der App, wie eben das Ausführen unserer Migrations, in das Container-Image wandern, wo es ja auch gut aufgehoben ist. Der Container erhält somit mehr Intelligenz. Gemessen an dem, was so alles im ENTRYPOINT des MariaDB-Images passiert, hält sich das bei uns allerdings in Grenzen. Nach einem kurzen Blick in das Dockerfile des PHP-Images, folgt der Inhalt der Datei docker-entrypoint.sh.

FROM php:7.1-fpm-alpine

# Build app
[...]

# Helper for MySQL readiness
RUN curl -o /usr/local/bin/wait-for https://raw.githubusercontent.com/Eficode/wait-for/master/wait-for && \
    chmod +x /usr/local/bin/wait-for

# Entrypoint
COPY entrypoint.sh /usr/local/bin
ENTRYPOINT ["entrypoint.sh"]
CMD ["php-fpm"]

Im Dockerfile wird die PHP-Applikation zusammengebaut. Anschließend laden wir ein kleines Helfer-Skript von GitHub, welches ohne weitere Abhängigkeiten, einfach mit der Shell funktioniert. Anschließend wird der ENTRYPOINT definiert.

#!/bin/sh
set -e

ENV_FILE_DESTINATION="/var/www/html/.env"
MYSQL_HOST="mysql"
MYSQL_PORT="3306"
MYSQL_TIMEOUT="60"

# Link secret for production environment
if [ -s "$ENV_FILE_SOURCE" ];then
    ln -s "$ENV_FILE_SOURCE" "$ENV_FILE_DESTINATION"
    echo "Secret linked."
else
    echo "No secret linked."
fi

echo "$(date) Waiting for MySQL service ..."
wait-for --timeout="$MYSQL_TIMEOUT" "$MYSQL_HOST":"$MYSQL_PORT" -- \
echo "$(date)" php artisan migrate --force

exec "$@"

Laravels Konfigurationsdatei .env gelangt per Secret in den Container und wird nun per Symlink an die richtige Stelle befördert. Mittels Helfer wait-for wird nun auf den benachbarten Container mit dem Hostnamen mysql gewartet, um anschließend die Datenbank-Migration mit dem Befehl php artisan migrate --force durchzuführen. Sollte der MySQL-Dienst nicht innerhalb von 60 Sekunden (--timeout=60) zur Verfügung stehen, bricht wait-for den Vorgang ab. Mit den beiden Datumsausgaben im Skript lässt sich schnell verifizieren, wie lange es gedauert hat, bis der MySQL-Dienst erreichbar ist.

Fazit

Mit unserer Arbeit stellen wir sicher, dass der PHP-Container wartet bis der MySQL-Dienst zur Verfügung steht. Dieser führt die Datenbank-Migration durch und startet anschließend den eigentlichen PHP-Dienst, damit nginx Anfragen an ihn stellen kann. Die Ausführungen sollen selbstverständlich nur als erster Ansatz dienen. Der MySQL-Hostname ließe sich beispielsweise per Environment Variable in den ENTRYPOINT einschleusen, statt ihn statisch zu hinterlegen. Den Timeout von wait-for könnte man auch noch weiter verarbeiten und z. B. das weitere Starten des PHP-Prozesses (php-fpm) unterbinden. Dann würde sich der Swarm Mode mit einer restart-policy, die man in der docker-compose.yml mit der Direktive deploy definiert, darum kümmern, den Container neu zu starten. Weiteres dazu kann man selbstverständlich in der offiziellen Dokumentation nachlesen. Wem das alles noch nicht reicht, dem empfehle ich einen Blick auf Flyway zu werfen.

Bild von Erda Estremera

Hier ein schneller Tipp, der gerade im Zusammenhang mit Legacy-Applikationen helfen kann, bei denen man einen SQL-Dump beim Starten des MySQL-Containers auch gleich importiert haben möchte.

In meiner docker-compose.yml nutze ich das offizielle MariaDB-Image. Mit dem MySQL-Image funktioniert das aber genauso. Man achte auf die letzte Zeile. Dort wird mittels Host-Mount ein SQL-Dump aus dem Projekt-Verzeichnis innerhalb des Containers, im Ordner /docker-entrypoint-initdb.d, verfügbar gemacht.

version: "3.7"

services:
  db:
    image: mariadb:10.4
    environment:
      MYSQL_ROOT_PASSWORD: myrootpassword
      MYSQL_DATABASE: mydatabase
      MYSQL_USER: myuser
      MYSQL_PASSWORD: mypassword
    ports:
      - 3306:3306
    volumes:
      - ./sql/dump.sql:/docker-entrypoint-initdb.d/dump.sql

Mit docker-compose up wird nun der Dienst gestartet und der SQL-Dump in die angegebene Datenbank importiert. Wer die Magie verstehen möchte, muss nur einen Blick in die als ENTRYPOINT hinterlegte Datei docker-entrypoint.sh des Images werfen. Dort wird nämlich innerhalb des Ordners nach Dateien mit den Endungen .sh, .sql und .sql.gz geschaut und diese ausgeführt, bzw. importiert. Möglich ist somit auch das Importieren mehrerer SQL-Dumps, indem man den gesamten Ordner mountet.

Bild von Ian Battaglia