Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
docker.io @ CentOS 7 - Secure And Portable Containers Made Easyinovex GmbH
The speaker Jürgen Brunks works for inovex GmbH as a senior linux systems engineer and designs, optimises and deploys highly scalable, automated linux environments for customers. For over 20 years he has been professionally with Unix/Linux and open source and could through numerous projects gained extensive practical experience. His duties include the design, construction and operation of systems. His focus is here in the Automation and Virtualization of highly available and highly scalable infrastructures.
Bei der Konzeption von End-2-End-Tests ist eine der größten Problemstellungen die Frage, wie die Testausführung möglichst robust, reproduzierbar und parallelisierbar gestaltet werden kann. Diese Hürde lässt sich meist mit klassischen Ansätzen nicht überwinden.
Einen eleganten Ausweg bieten in Container verpackte Testumgebungen. Dadurch wird es möglich, einen definierten Systemstand reproduzierbar aufzurufen und Tests performant auszuführen. Anhand typischer E2E-Tests wird gezeigt, wie z. B. parallele GUI-Tests in verschiedenen Umgebungen zur Qualitätssicherung beitragen. Die Beispiele sind mit dem Open-Source-Tools „Sakuli“ und „Docker“ realisiert und testen Web- und Rich-Client-Applikationen. Um die Integration in eine Continous-Deployment-Pipeline zu demonstrieren, wird eine rein auf Container-Technologie basierende Testumgebung durch das CI-Tool Jenkins aufgebaut, um darauf automatisierte End-2-End-Tests headless zur Ausführung zu bringen.
Ziel ist es, dem Zuhörer aufzuzeigen, wie das Potenzial von Container-Technologien genutzt werden kann, um die Softwarequalität zu erhöhen und den manuellen Testaufwand drastisch zu verringern. Eine abschließende Bewertung der Erfahrungen sowie ein Ausblick auf weitere Einsatzszenarien und Entwicklungsschritte runden den Vortrag ab.
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
docker.io @ CentOS 7 - Secure And Portable Containers Made Easyinovex GmbH
The speaker Jürgen Brunks works for inovex GmbH as a senior linux systems engineer and designs, optimises and deploys highly scalable, automated linux environments for customers. For over 20 years he has been professionally with Unix/Linux and open source and could through numerous projects gained extensive practical experience. His duties include the design, construction and operation of systems. His focus is here in the Automation and Virtualization of highly available and highly scalable infrastructures.
Bei der Konzeption von End-2-End-Tests ist eine der größten Problemstellungen die Frage, wie die Testausführung möglichst robust, reproduzierbar und parallelisierbar gestaltet werden kann. Diese Hürde lässt sich meist mit klassischen Ansätzen nicht überwinden.
Einen eleganten Ausweg bieten in Container verpackte Testumgebungen. Dadurch wird es möglich, einen definierten Systemstand reproduzierbar aufzurufen und Tests performant auszuführen. Anhand typischer E2E-Tests wird gezeigt, wie z. B. parallele GUI-Tests in verschiedenen Umgebungen zur Qualitätssicherung beitragen. Die Beispiele sind mit dem Open-Source-Tools „Sakuli“ und „Docker“ realisiert und testen Web- und Rich-Client-Applikationen. Um die Integration in eine Continous-Deployment-Pipeline zu demonstrieren, wird eine rein auf Container-Technologie basierende Testumgebung durch das CI-Tool Jenkins aufgebaut, um darauf automatisierte End-2-End-Tests headless zur Ausführung zu bringen.
Ziel ist es, dem Zuhörer aufzuzeigen, wie das Potenzial von Container-Technologien genutzt werden kann, um die Softwarequalität zu erhöhen und den manuellen Testaufwand drastisch zu verringern. Eine abschließende Bewertung der Erfahrungen sowie ein Ausblick auf weitere Einsatzszenarien und Entwicklungsschritte runden den Vortrag ab.
Provisionierung von Dockerhosts und -Containern mit Terraform, Ansible und LXD auf Blech und Cloud
Lästige und aufwändige manuelle Serverinstallation kann auf einfache Art durch automatisierte Provisionierung und Konfiguration der Infrastruktur ersetzt werden. Dieser Vortrag zeigt einen Ansatz, bei dem die Definition der Infrastruktur in voll maschinenlesbarer und ausführbarer Form in einem git repo anstatt in den Köpfen der (oder des) Engineers vorhanden sind.
Es wird gezeigt, wie das Verfahren sowohl auf Blech (d.h. auf lokalen physischen Maschinen) als auch in der Cloud angewendet werden kann, und somit eine grosse Übereinstimmung zwischen Test-/Integrations- und Produktionsinfrastruktur erreicht wird.
Die vorgestellten Werkzeuge sind terraform und ansible für Provisionierung und Konfigurationsmanagement, sowie lxd (nur lokal) und docker für System- und Applikationscontainer. Die vollständige Codebasis ist auf github verfügbar, so dass alle TeilnehmerInnen auch sofort mit eigenen Experimenten loslegen können.
Containerized End-2-End Testing - JUG Saxony DayTobias Schneck
Bei der Konzeption von End-2-End-Tests ist eine der größten Probleme die Frage, wie die Testausführung robust, reproduzierbar und skalierbar gestaltet werden kann. Einen eleganten Ausweg bieten in Container verpackte Testumgebungen. Dadurch wird es möglich, einen definierten Systemstand reproduzierbar und performant zu testen. Anhand der Open-SourceTools „Sakuli“ und „Docker“ wird gezeigt, wie parallele GUI-Tests in nativen Umgebungen Web- und Rich-Client-Anwendungen performant testen.
This presentation will show you how to use docker-compose in a practical example, discuss some alternative approaches and teach best practices (in german).
Oracle unterstützt seit längerem die Nutzung von Docker für die Oracle Datenbanken. In der Theorie wird mit einem einfacher docker run aus einem Docker Image ein Container instanziiert. Doch wieso ist der DB Container nicht in wenigen Sekunden bereit? Wo kommt mein Oracle DB Image überhaupt her und was geschieht, wenn der Container wieder gestoppt wird? Dieser Vortrag erläutert, wie Oracle DBs in einem Docker Image installiert, konfiguriert und anschliessend als Container betrieben werden.
Verteilte Anwendungen bei Azure mit Docker und KubernetesGregor Biswanger
Kubernetes ermöglicht eine Automatisierung der Bereitstellung, Skalierung und Verwaltung von verteilten Docker-Container. Der Einstieg, die Umsetzung und Wartung hingegen ist eine extreme Herausforderung und kostet am Ende nicht nur viel Geld, sondern auch Ihre Nerven. Microsoft Azure bietet mit den Azure Kubernetes Services (Kurz AKS) die Erlösung, der soeben genannten Schmerzen. In dieser Session zeigt Ihnen der Docker- und Azure-Experte Gregor Biswanger einen Überblick von Kubernetes und wie einfach Azure für uns eine Kuberenetes-Landschaft herbeizaubern kann.
Einführung in Vagrant und wie es als lokale Entwicklungsumgebung verwendet werden kann.
Präsentation von März 2015.
Themen: Vagrant CLI, vagrant share, Provider, Boxes, Provisioning, Netzwerk, Synced Folders, Multi-Maschine Setup, Vergleich mit Docker
http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Vortrag auf dem TYPO3 Meetup 3 am 13.11.2017 bei sitegeist
über Docker Umgebungen für TYPO3 zu Präsentationszwecken und als Entwicklungsumgebung mit xdebug.
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...NETWAYS
Dieser Workshop ist in erster Linie für Konferenzteilnehmer gedacht, die sich für Plugin-Programmierung interessieren.
Der Workshop zeigt auf, welche überwachenswerten Daten und Parameter es auf einem NetApp-Filer gibt und wie die Zugänge zu diesen Daten (Telnet, HTTP, SNMP, SSH, XML/Webservices, Data ONTAP APIs) sind. Ingo Lantschner wird eine theoretische Einführung und Demonstration an Hand des NetApp-Simulators präsentieren und mit den Teilnehmern ein Demo-Plugin auf Basis der o.g. Erkenntnisse entwickeln, anschließend erfolgt der Upload des Plugins auf Nagios-Exchange.
OSMC 2011 | Collectd in der großen weiten Welt - Anbindung des Datensammlers ...NETWAYS
collectd ist ein mächtiges Werkzeug zum effizienten Sammeln und Verarbeiten von Performance-Daten. Diese werden neben der Performance-Analyse, Kapazitätsplanung und Fehler- bzw. Ursachensuche auch zum Monitoring benötigt. collectd hat sich auf die Erfassung dieser Daten spezialisiert. Gleichzeitig werden einige Schnittstellen zur Umwelt geboten, welche eine Integration in andere Systeme, wie Monitoring-Lösungen erlauben.
Bei der Software handelt es sich um einen UNIX-Daemon, welcher periodisch Leistungsdaten von Rechnern oder Rechenzentrumshardware abfragen, verarbeiten und speichern kann. Durch sein modulares Design wird ein hohes Maß an Flexibilität und Erweiterbarkeit erreicht, wodurch eine Vielzahl von Einsatzmöglichkeiten und -bereichen eröffnet wird.
Weiterhin wird der Overhead der Datenabfrage auf ein Minimum begrenzt, indem der Daemon dauerhaft im Hintergrund läuft und zur Abfrage von Werten keine externen Programme oder Skripte aufruft. Dadurch wird eine Standardauflösung von 10 Sekunden ermöglicht, ohne das System nennenswert zu belasten. Damit eignet sich collectd hervorragend als Datensammler für andere Systeme.
Dieser Vortrag stellt den Daemon und seine wichtigsten Eigenschaften vor. Danach werden Erweiterungsmöglichkeiten und externe Schnittstellen der Software erläutert und gezeigt, wie eine Anbindung an Nagios/Icinga ermöglicht wird. Abschließend wird ein Ausblick auf künftige Entwicklungen in diesem Gebiet gegeben.
Provisionierung von Dockerhosts und -Containern mit Terraform, Ansible und LXD auf Blech und Cloud
Lästige und aufwändige manuelle Serverinstallation kann auf einfache Art durch automatisierte Provisionierung und Konfiguration der Infrastruktur ersetzt werden. Dieser Vortrag zeigt einen Ansatz, bei dem die Definition der Infrastruktur in voll maschinenlesbarer und ausführbarer Form in einem git repo anstatt in den Köpfen der (oder des) Engineers vorhanden sind.
Es wird gezeigt, wie das Verfahren sowohl auf Blech (d.h. auf lokalen physischen Maschinen) als auch in der Cloud angewendet werden kann, und somit eine grosse Übereinstimmung zwischen Test-/Integrations- und Produktionsinfrastruktur erreicht wird.
Die vorgestellten Werkzeuge sind terraform und ansible für Provisionierung und Konfigurationsmanagement, sowie lxd (nur lokal) und docker für System- und Applikationscontainer. Die vollständige Codebasis ist auf github verfügbar, so dass alle TeilnehmerInnen auch sofort mit eigenen Experimenten loslegen können.
Containerized End-2-End Testing - JUG Saxony DayTobias Schneck
Bei der Konzeption von End-2-End-Tests ist eine der größten Probleme die Frage, wie die Testausführung robust, reproduzierbar und skalierbar gestaltet werden kann. Einen eleganten Ausweg bieten in Container verpackte Testumgebungen. Dadurch wird es möglich, einen definierten Systemstand reproduzierbar und performant zu testen. Anhand der Open-SourceTools „Sakuli“ und „Docker“ wird gezeigt, wie parallele GUI-Tests in nativen Umgebungen Web- und Rich-Client-Anwendungen performant testen.
This presentation will show you how to use docker-compose in a practical example, discuss some alternative approaches and teach best practices (in german).
Oracle unterstützt seit längerem die Nutzung von Docker für die Oracle Datenbanken. In der Theorie wird mit einem einfacher docker run aus einem Docker Image ein Container instanziiert. Doch wieso ist der DB Container nicht in wenigen Sekunden bereit? Wo kommt mein Oracle DB Image überhaupt her und was geschieht, wenn der Container wieder gestoppt wird? Dieser Vortrag erläutert, wie Oracle DBs in einem Docker Image installiert, konfiguriert und anschliessend als Container betrieben werden.
Verteilte Anwendungen bei Azure mit Docker und KubernetesGregor Biswanger
Kubernetes ermöglicht eine Automatisierung der Bereitstellung, Skalierung und Verwaltung von verteilten Docker-Container. Der Einstieg, die Umsetzung und Wartung hingegen ist eine extreme Herausforderung und kostet am Ende nicht nur viel Geld, sondern auch Ihre Nerven. Microsoft Azure bietet mit den Azure Kubernetes Services (Kurz AKS) die Erlösung, der soeben genannten Schmerzen. In dieser Session zeigt Ihnen der Docker- und Azure-Experte Gregor Biswanger einen Überblick von Kubernetes und wie einfach Azure für uns eine Kuberenetes-Landschaft herbeizaubern kann.
Einführung in Vagrant und wie es als lokale Entwicklungsumgebung verwendet werden kann.
Präsentation von März 2015.
Themen: Vagrant CLI, vagrant share, Provider, Boxes, Provisioning, Netzwerk, Synced Folders, Multi-Maschine Setup, Vergleich mit Docker
http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Vortrag auf dem TYPO3 Meetup 3 am 13.11.2017 bei sitegeist
über Docker Umgebungen für TYPO3 zu Präsentationszwecken und als Entwicklungsumgebung mit xdebug.
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...NETWAYS
Dieser Workshop ist in erster Linie für Konferenzteilnehmer gedacht, die sich für Plugin-Programmierung interessieren.
Der Workshop zeigt auf, welche überwachenswerten Daten und Parameter es auf einem NetApp-Filer gibt und wie die Zugänge zu diesen Daten (Telnet, HTTP, SNMP, SSH, XML/Webservices, Data ONTAP APIs) sind. Ingo Lantschner wird eine theoretische Einführung und Demonstration an Hand des NetApp-Simulators präsentieren und mit den Teilnehmern ein Demo-Plugin auf Basis der o.g. Erkenntnisse entwickeln, anschließend erfolgt der Upload des Plugins auf Nagios-Exchange.
OSMC 2011 | Collectd in der großen weiten Welt - Anbindung des Datensammlers ...NETWAYS
collectd ist ein mächtiges Werkzeug zum effizienten Sammeln und Verarbeiten von Performance-Daten. Diese werden neben der Performance-Analyse, Kapazitätsplanung und Fehler- bzw. Ursachensuche auch zum Monitoring benötigt. collectd hat sich auf die Erfassung dieser Daten spezialisiert. Gleichzeitig werden einige Schnittstellen zur Umwelt geboten, welche eine Integration in andere Systeme, wie Monitoring-Lösungen erlauben.
Bei der Software handelt es sich um einen UNIX-Daemon, welcher periodisch Leistungsdaten von Rechnern oder Rechenzentrumshardware abfragen, verarbeiten und speichern kann. Durch sein modulares Design wird ein hohes Maß an Flexibilität und Erweiterbarkeit erreicht, wodurch eine Vielzahl von Einsatzmöglichkeiten und -bereichen eröffnet wird.
Weiterhin wird der Overhead der Datenabfrage auf ein Minimum begrenzt, indem der Daemon dauerhaft im Hintergrund läuft und zur Abfrage von Werten keine externen Programme oder Skripte aufruft. Dadurch wird eine Standardauflösung von 10 Sekunden ermöglicht, ohne das System nennenswert zu belasten. Damit eignet sich collectd hervorragend als Datensammler für andere Systeme.
Dieser Vortrag stellt den Daemon und seine wichtigsten Eigenschaften vor. Danach werden Erweiterungsmöglichkeiten und externe Schnittstellen der Software erläutert und gezeigt, wie eine Anbindung an Nagios/Icinga ermöglicht wird. Abschließend wird ein Ausblick auf künftige Entwicklungen in diesem Gebiet gegeben.
4. Was bedeutet produktiv?
• Betriebsszenarien:
– Docker lokal betreiben
– auf einem Intranet‐Server
– auf einem eigenen Webserver
– auf mehreren eigenen Servern
– auf cloud‐basierter Infrastruktur
• unterscheiden sich in Zielen und
Anforderungen
Dockerbank 2, Jens Piegsa 4
5. Docker lokal betreiben
• Ziele:
– leichtgewichtige Instanz einer vollständigen
Umgebung zu Testzwecken
– Entwicklung / Debugging von Docker Images
• Maßnahmen:
– Einsatz vertrauenswürdiger Images
(keine Schadcode)
– Verwendung von Volumes
(kein Datenverlust zwischen mehreren Session)
– Durchführung manueller Backups
Dockerbank 2, Jens Piegsa 5
7. Docker auf einem Webserver
• Ziele:
– dauerhafter Betrieb
– kurzzeitiger Betrieb zu Test‐, Demonstrationszwecken
• Maßnahmen:
– Serverzertifikate, verschlüsselte Kommunikation
– Monitoring, Logging
– Hardening des Host‐Systems, restriktive Firewall‐
Konfiguration
Dockerbank 2, Jens Piegsa 7
8. Docker auf mehreren Servern
• Ziele:
– Skalierung, Ausfallsicherheit von Diensten
– mehrere Mandanten
– Sicherheit: Trennung durch Netzwerkzonen, VMs
– Testumgebung
• Maßnahmen:
– Orchestrierung
– Konfigurationsmanagement, Secret Management
– Private Docker Registry
– CI/CD Pipelines
Dockerbank 2, Jens Piegsa 8
9. Docker produktiv: Antipatterns
ø Datenhaltung im Container
ø Images mit umgebungsspezifischer Konfiguration bzw. sensiblen Daten;
umgebungsspezifische Tags
ø Einsatz nicht reproduzierbarer Images (mittels docker commit
erzeugt oder aus Fremdquellen)
ø Container‐Modifikationen (docker cp, docker exec)
ø langlebige Container
ø Ausführung mehrerer Prozesse innerhalb eines Containers
ø Images mit vielen Schichten
ø implizite oder explizite Ausführung / Abhängigkeit von latest
ø Veröffentlichung aller Ports via docker run -P
ø zeitliche Abhängigkeiten zwischen Containern
Dockerbank 2, Jens Piegsa 9
11. Konfigurationsmanagement
Docker Container
• Docker Image so entwickeln, dass
– sie unabhängig von der Umgebung (Entwicklung, Test,
QA, Staging, Produktion) bleiben
– initiale Konfigurationen über Umgebungsvariablen
vorgenommen werden können, die ggf. anwendungs‐
abhängig über ein Entrypoint‐Skript angewendet
werden
– veränderliche Konfigurationen aus Dateien,
idealerweise in separaten Verzeichnissen, gelesen
wird, die als (benannte) Volumes gemountet werden
– es keiner nachträglichen Modifikationen des
instanziierten Containers bedarf
Dockerbank 2, Jens Piegsa 11
12. Konfigurationsmanagement
Hostumgebung
• Einsatz herkömmlicher Konfigurations‐
managementwerkzeuge wie Puppet, Chef und
Ansible möglichst auf ein Minimum reduzieren
– Installation / Update der Hostumgebung
• docker, docker‐compose, Kubernetes‐, Mesos‐Cluster
– Einrichtung hybrider Umgebungen
– Sicherheitsvorkehrungen
Dockerbank 2, Jens Piegsa 12
14. Sicherheit: Container vs. VMs
Kriterium Virtuelle Maschinen (VM) Container
Isolation verfügen über eine zusätzliche Hypervisor‐
Schicht
teilen sich einen Kernel
Angriffsfläche enthalten viele Tools, die sich Angreifer
zunutze machen können
minimale Images
Kontrolle Begrenzung des Zugriffs auf Ressourcen Begrenzung des Zugriffs auf Ressourcen;
read‐only Dateisystem; Kernel Capabilities
Auditierung langlebig; divergieren vom Basisimage;
werden mittels Konfigurationsmanagement‐
software gepatcht
kurzlebig; Aktualisierung durch Austausch;
Image‐Anpassungen unter Versions‐
kontrolle; docker diff
Zuverlässigkeit haben sich in der Vergangenheit bewährt weniger Erfahrungswerte; rapide
Entwicklung
Fazit • kombinierter Einsatz von VMs und Containern: VMs zur Separierung von Container‐
Gruppen und Container als zusätzliche Sicherheit und wegen ihrer Features
• aktuell viele Bestrebungen VMs leichtgewichtiger und Container sicherer zu machen
• grundsätzlich: gestaffelte Sicherheitsvorkehrungen, Least‐Privilege‐Prinzip
Dockerbank 2, Jens Piegsa 14
15. Bedrohungen und Maßnahmen
Kernel‐
Exploits
Denial‐of‐
Service‐
Angriffe
Container‐
Breakouts
Vergiftete
Images
Verratene
Geheimnisse
Images auditieren (Dockerfile, statische Analyse)
Abgrenzung von Container‐Gruppen durch VMs
Gesamtes Container‐Dateisystem read‐only setzen
Sensible Volumes read‐only deklarieren
Kernel Capabilities einschränken
CPU‐Ressourcen zuweisen
Arbeitsspeicher limitieren
SETUID/SETGID‐Dateizugriffsrechte entfernen
Kommunikation zwischen Containern einschränken
Nicht‐Root USER im Dockerfile festlegen
Geheimnisse nicht in Umgebungsvariablen ablegen
Container nicht --privileged starten
Minimale Images ohne unnötige Pakete
AppArmor, SELinux, Seccomp
Dockerbank 2, Jens Piegsa 15
17. Schreibzugriffe einschränken
• gesamtes Dateisystem auf read‐only setzen:
(kombinierbar mit Schreibrechten für Volumes)
• sensibles Volume read‐only deklarieren:
Dockerbank 2, Jens Piegsa 17
docker run --read-only --rm alpine touch x
docker run -v $(pwd):/secrets:ro --rm
alpine touch /secrets/x
18. Kernel Capabilities einschränken
• bestimmte Capabilities deaktivieren:
• sämtliche Capabilities abschalten:
• Whitelist‐ und Blacklist‐Verfahren möglich durch
Kombination mit --cap-add
• siehe Man‐Pages: man capabilities
Dockerbank 2, Jens Piegsa 18
docker run --cap-drop SETGID --cap-drop SETUID
--rm alpine su -c whoami postgres
docker run --cap-drop ALL --rm alpine
ping localhost -c1
19. CPU‐Ressourcen zuweisen
• erfolgt anhand von relativer Wichtungen
• Wichtung beträgt standardmäßig 1024
• Beispiel erzeugt drei Container mit den Last‐
wichtungen 50%, 25% und 25%:
• Container entfernen mit docker rm -f …
Dockerbank 2, Jens Piegsa 19
docker run -d alpine sh -c 'yes>/dev/null' &&
docker run -d -c 512 alpine sh -c 'yes>/dev/null' &&
docker run -d -c 512 alpine sh -c 'yes>/dev/null' &&
top
20. Arbeitsspeicher limitieren
• einmalig Memory und Swap Limit Capabilities im
Host aktivieren (erfordert Neustart):
• Container auf 42MB Arbeits‐ und 42MB Swap‐
Speicher beschränken:
(Abbruch mittels der Tastenkombination Strg+C)
Dockerbank 2, Jens Piegsa 20
docker run -m 42m -d alpine tail -f /dev/null &&
docker stats
echo 'GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"'|
sudo tee -a /etc/default/grub &&
sudo update-grub && sudo reboot
21. Ausführbare Dateien mit setuid‐/setgid‐
Zugriffsrechten entschärfen
1. Alle privilegierten Dateien finden:
2. Neues Dockerfile erstellen, das bei der Image‐Erstellung allen
Dateien die kritischen Zugriffsrechte entzieht:
3. Container auf Basis des neuen Image erstellen und testen:
Dockerbank 2, Jens Piegsa 21
docker run --rm debian find / -type f -perm /6000
-exec stat -c "%A %a %n" {} ; 2>/dev/null
FROM debian:8.6
RUN find / -type f -perm /6000 -exec chmod a-s {} ; || true
USER daemon
docker build -t mostly-harmless . &&
docker run --rm mostly-harmless find / -type f -perm /6000
-exec stat -c "%n" {} ; 2>/dev/null | wc -l
22. Absicherung der Kommunikation zwischen
Containern (I)
• Docker‐Terminologie (expose / publish ports) lässt
vermuten, dass die Kommunikation zwischen
Containern standardmäßig eingeschränkt ist
• Experiment:
Dockerbank 2, Jens Piegsa 22
docker inspect $(docker run -d nginx:alpine)
docker run --rm alpine wget -qO - -T10 -t1 <IPAddress>:80
23. Absicherung der Kommunikation zwischen
Containern (II)
• generelle Deaktivierung mit Ausnahme bei Container‐Verlinkung:
• unter Debian/Ubuntu zusätzlich notwendige Anpassung mittels
sudoedit /lib/systemd/system/docker.service vornehmen:
• Neustart und Prüfen der Argumente mittels der Prozessliste:
Dockerbank 2, Jens Piegsa 23
echo 'DOCKER_OPTS="--icc=false --iptables"' |
sudo tee -a /etc/default/docker
...
[Service]
ExecStart=/usr/bin/docker -d -H fd:// $DOCKER_OPTS
EnvironmentFile=/etc/default/docker
...
sudo systemctl daemon-reload &&
sudo systemctl restart docker &&
ps aux | grep dockerd
24. Absicherung der Kommunikation zwischen
Containern (III)
• Experiment wiederholen:
• stattdessen Port‐Publishing über Host nutzen:
• oder alternativ mittels Container‐Verlinkung:
Dockerbank 2, Jens Piegsa 24
docker inspect $(docker run -d nginx:alpine)
docker run --rm alpine wget -qO - -T10 -t1 <IPAddress>:80
docker run -d -p 10080:80 nginx:alpine &&
docker run --rm alpine wget -qO - -T10 -t1 192.168.56.20:10080
docker run -d --name nginx nginx:alpine &&
docker run --rm --link nginx:web alpine sh -c
'wget -qO - -T10 -t1 $WEB_PORT_80_TCP_ADDR'
26. Sicherheitsanalyse
• automatisierte Analyse von Image‐Inhalten
anhand Liste bekannter Sicherheitslücken und
Schwachstellen (Common Vulnerabilities and
Exposures; CVE)
• unterschiedliche Techniken
– statische vs. dynamische Analyse
• verschiedene Integrationsmöglichkeiten
– manuelle Scans
– Registry‐ und Build‐Pipeline‐Integration
– Echtzeitbenachrichtigung
Dockerbank 2, Jens Piegsa 26
27. Kriterien zur Evaluierung von container‐
basierten Sicherheitsanalysewerkzeugen
• Technik
– Wie werden in einem Image enthaltene Softwareversionen detektiert?
(auf Basis des Paketmanagers oder binär)
– Welche Quellen u. Datenbanken bekannter Sicherheitslücken werden genutzt?
– Liegt der Analyseschwerpunkt eher auf anwendungs‐ oder docker‐spezifischen
Schwachstellen?
– Inwiefern werden in Produduktiveinsatz befindliche Images kontinuierlich
gescannt?
– Welche Container‐Technologien werden unterstützt?
• Integrierbarkeit
– Wo ist der Ansatzpunkt des Scanners in der eigenen Pipeline?
– Mit welchen Anwendungen arbeitet der Scanner zusammen (Registries, CI/CD‐
Lösungen, cloud‐basierten / selbstbetriebenen Orchestrierungsplattformen)?
– Wird neben der statischen Image‐Analyse auch Auditing der Host‐Umgebung
unterstützt (Konfiguration, Container)?
– Gibt es eine API für eine individuelle Integration (Erweiterbarkeit,
Benachrichtigungsmechanismen)?
Dockerbank 2, Jens Piegsa 27
28. Sicherheitsanalysewerkzeuge
Dockerbank 2, Jens Piegsa 28
• Docker Bench for Security (Docker, Apache‐Lizenz)
– prüft Docker‐ und Container‐Konfigurationen auf Einhaltung von "Best Practices" aufgestellt
vom Zentrum für Internet Security (CIS)
• Clair (CoreOS; Apache‐Lizenz)
– detektiert installierte Software über bekannte Paketmanager
– manuell installierte Komponenten bleiben unberücksichtigt
• Docker Security Scanning (Docker Inc.; kommerzielle Lizenz)
– Erkennung wird auf Binär‐Ebene durchgeführt, unabhängig vom Paketmanager
– integriert in Docker Cloud und Docker Datacenter, jedoch nicht unabhängig einsetzbar
• Twistlock Trust (sowohl freie, als auch kommerzielle Lizenz)
– Erkennung auf Binärebene
– berücksichtigt Zero‐Day‐Feeds
• OpenSCAP + Atomic Scan (Red Hat; GPL3‐Lizenz)
– spezialisiert auf Red‐Hat‐Linuxdistributionen
• Bluemix Vulnerability Advisor (IBM; kommerziell)
– integriert in cloud‐basierte Plattform Bluemix
siehe auch: https://www.alfresco.com/blogs/devops/2015/12/03/docker‐security‐
tools‐audit‐and‐vulnerability‐assessment/
29. Docker Bench for Security
• Skript, das automatisiert auf Schwachstellen bzw. Einhaltung von
"Best Practices" beim Produktiveinsatz von Docker prüft
• basiert auf dem Docker‐Security‐Benchmark des Center for Internet
Security (CIS): https://benchmarks.cisecurity.org/tools2/docker/
CIS_Docker_1.11.0_Benchmark_v1.0.0.pdf
• generierter Testbericht enthält Verweise auf die Kapitel im
Dokument mit den entsprechenden Handlungsempfehlungen
Dockerbank 2, Jens Piegsa 29
sudo apt-get install auditd
cd ~
git clone https://github.com/docker/docker-bench-security.git
cd ~/docker-bench-security
sudo sh docker-bench-security.sh
30. Clair lokal aufsetzen
Dockerbank 2, Jens Piegsa 30
mkdir -p ~/clair/clair_config &&
cd ~/clair &&
curl -L https://raw.githubusercontent.com/coreos/clair/v1.2.6/docker-compose.yml -o docker-compose.yml &&
curl -L https://raw.githubusercontent.com/coreos/clair/v1.2.6/config.example.yaml
-o clair_config/config.yaml &&
sed -i.bak 's* source:* source: postgresql://postgres:password@postgres:5432?sslmode=disable*g'
clair_config/config.yaml &&
printf 'n' >> docker-compose.yml &&
sed -i.bak -e 's/^$/ restart: unless-stopped/g' docker-compose.yml &&
docker-compose up -d &&
sudo apt-get -y install golang-go &&
printf 'nexport GOPATH=/usr/share/go/nexport PATH=$PATH:/usr/lib/go/binn' | sudo tee -a /etc/profile &&
sudo su -c 'go get -x -v -u github.com/coreos/clair/contrib/analyze-local-images' &&
docker-compose logs -f # wait until the vulerability database is updated
31. Clair mittels CLI einsetzen
• Workflow:
1. mittels docker pull oder docker build Image
lokal bereitstellen bzw. mittels docker images
auffinden
2. Einsatz: analyze-local-images myimage
3. Recherche anhand des Berichtes durchführen
4. Optionen:
a) keine Korrektur, bei geringfügigem Risiko
b) Image Maintainer um Korrektur bitten
c) Schwachstelle selbst beheben und ggf. dem Maintainer
rückmelden
d) alternatives Image einsetzen
5. Analyse regelmäßig wiederholen
Dockerbank 2, Jens Piegsa 31
32. Secret‐Management
Wo können Geheimnisse aufbewahrt werden?
Dockerbank 2, Jens Piegsa 32
im Docker Image
in Umgebungsvariablen
in Dateien innerhalb von Volumes
in einem Secret Store
34. Datenpersistenz in Containern
• Volume‐Arten: anonyme, host‐gebundene und benannte Volumes
• wird ein benanntes Volume impliziert bei Container‐Erzeugung
angelegt werden vorhandene Dateien aus dem zugeordneten
Verzeichnis des Image in das Volume kopiert
• wird bei Container‐Erzeugung ein bestehendes Volume gemountet
findet kein initialer Kopiervorgang statt
• mit dem Stopp eines Containers werden keine Inhalte gelöscht
• mit dem Löschen eines Containers gehen alle Inhalte des Container‐
Dateisystems verloren, Volumes bleiben jedoch erhalten
– anonyme Volumes lassen sich anschließend mittels docker volume
ls und docker volume inspect VID wieder auffinden und
nachnutzen
– wird docker rm mit dem Schalter -v ausgeführt, werden alle
anonymen Volumes eines Containers gelöscht, es sei denn, sie sind
mittels --volumes-from an weitere Container gebunden
Dockerbank 2, Jens Piegsa 34
35. Sicherungsmöglichkeiten
• Sicherung und Wiederherstellung von
– Docker‐Images
– Docker‐Containern
– Dateien / Verzeichnissen in Containern ohne Volume
– Dateien / Verzeichnissen aus anonymen Volumes
– benannten Volumes
– Datenbank‐Dumps
• manueller Backup‐Container
• kurzlebiger Backup‐Container über cronjob auf dem Host
• permanenter Backup‐Container mit cron im Vordergrund
Dockerbank 2, Jens Piegsa 35
36. Sicherung und Wiederherstellung von
Dateien in Containern ohne Volume
• Sicherungskopie des Ordners /data des Containers SOURCE im
aktuellen Arbeitsverzeichnis des Hostsystems anlegen:
• Kopie des Ordners data im aktuellen Arbeitsverzeichnis des
Hostsystems in das Verzeichniss /data des TARGET‐Containers:
• Nachteil: Applikation und Daten sind eng gekoppelt
• besser: Einsatz von Volumes vereinfacht Aktualisierung von
Containern und schafft Transparenz
Dockerbank 2, Jens Piegsa 36
docker cp SOURCE:/data $(pwd)/data
docker cp $(pwd)/data TARGET:/data
37. Sicherung und Wiederherstellung einzelner
Verzeichnisse aus anonymen Volumes
• Sicherung des Ordners /data des Containers SOURCE als
Archivdatei in das aktuelle Arbeitsverzeichnis des Hostsystems:
• Wiederherstellung des Ordners /data aus Archivdatei im aktuellen
Arbeitsverzeichnis des Hostsystems in den Containers TARGET:
• Nachteile: anonyme Volumes sind schwer zuzuordnen;
Backup‐Routine hat Zugriff auf alle Volumes
• besser: benannte Volumes
Dockerbank 2, Jens Piegsa 37
docker run --rm --volumes-from SOURCE:ro
-v $(pwd):/backup alpine
tar cvzf /backup/backup_$(date +%Y-%m-%d_%H%M).tar.gz /data
docker run --rm --volumes-from TARGET
-v $(pwd):/backup:ro alpine
tar xvf /backup/backup_2016-12-07_13-30.tar
38. Sicherung und Wiederherstellung von
benannten Volumes
• Sicherung aller Dateien des benannten Volumes SOURCE als
Archivdatei in das aktuelle Arbeitsverzeichnis des Hostsystems:
• Wiederherstellung aller Dateien aus Archivdatei im aktuellen
Arbeitsverzeichnis des Hostsystems in das Volume TARGET:
• Nachteile: Volume‐Namensschema bei Skalierung?
Dockerbank 2, Jens Piegsa 38
docker run --rm -v SOURCE:/data:ro
-v $(pwd):/backup alpine
tar cvzf /backup/backup_$(date +%Y-%m-%d_%H%M).tar.gz /data
docker run --rm -v TARGET:/data
-v $(pwd):/backup:ro alpine
tar xvf /backup/backup_2016-12-07_13-30.tar.gz
42. Möglichkeiten der Protokollierung
• docker logs ist die einfachste Lösung, hat jedoch für den
Produktiveinsatz einige Nachteile:
– kann nur mit STDOUT‐ und STDERR‐Ausgaben umgehen
– Protokolle gehen mit dem Entfernen eines Containers verloren
– das intern genutzte JSON‐Format ist speicherintensiv, erschwert
einfache Suchen und zerlegt Stacktraces zeilenweise in mehrere
Abschnitte
– unterstützt keine Log‐Rotation
• Log‐Dateien in ein Docker Volume schreiben
• spezialisierte Logging‐Dienste einsetzen
– z.B. syslog‐ng, rsyslog, logstash, logspout, filebeat, fluentd
• Komplettlösungen:
– ELK‐Stack: Elasticsearch, Logstash, Kibana
– Logentries (kommerzielle Lizenz)
Dockerbank 2, Jens Piegsa 42
43. Welche Protokolle werden
docker‐intern angelegt
• Docker‐Daemon‐Logs
– abhängig von der Linux‐Distribution
– für Debian / Ubuntu aktuell:
• Container‐Logs
– für alle Container anzeigen:
Dockerbank 2, Jens Piegsa 43
journalctl -u docker -n100
sudo su -c 'ls -Ralph /var/lib/docker/containers/*/*.log'