This presentation will show you how to use docker-compose in a practical example, discuss some alternative approaches and teach best practices (in german).
2. Introduction
❖ wer bin ich eigentlich ?
❖ PID: Patrick Paechnatz
❖ Task: Senior Backend Developer
❖ Host: move:elevator, Dresden
❖ UpTime: 38y (~17y Developer)
❖ ENV: C++, C#, Erlang, Python, PHP
dunkelfrosch.com | twitter.com/dunkelfrosch | github.com/paterik
2
3. Agenda
❖ Über was möchte ich sprechen ?
Dieser Vortrag soll euch docker-compose an einem
praktischen Beispiel zeigen, alternative Ansätze erläutern
und auch einige Best-Practices auf den Weg geben …
❖ Docker composition: „Compose Why“?
⇢ 8 slides
❖ Composition, practical: „Atlassian Workbench“
⇢ 15 slides
3
4. docker in action, … composing and practical issues
DOCKER
WORKBENCH
Part 1, Compose … why?
image: https://upload.wikimedia.org/wikipedia/commons/9/94/Maersk_Majestic.jpg
4
5. Compose why?
❖ Warum docker-compose?
❖ Vorteile von docker-compose …
❖ Nachteile von docker-compose …
❖ Best Practices
❖ Was gibt es Neues?
❖ Alternativen?
❖ Mesos, Kubernetes, Tutum
5
7. Compose why?
❖ Vorteile von docker-compose
❖ Verhindert „eigene“ Scripting-Ansätze für wieder-
kehrende Container-Verwaltungs-Prozesse.
❖ Services und deren Abhängigkeiten sind unabhängig von
der zugrundeliegenden Infrastruktur leicht auflösbar
und kombinierbar.
❖ Einfaches Container Networking (lightweight nodes)
❖ Bestandteil der Docker „Trinity“ (d/dc/dm)
7
9. Compose why?
❖ Best Practices
❖ Verwendung von Server Verzeichnisstrukturen
❖ Weitestgehender Verzicht auf Linking zugunsten des
Networking-Features.
❖ Prüfung auf Möglichkeit zur vordefinierten Last-
Verteilung über CPU-Share/-Quota/-Sets.
❖ Zeitnahe Anpassung an neuen verfügbare Basis-
Versionen von docker-compose/docker / dm
9
10. Compose why?
❖ Was gibt es Neues?
❖ Neues Konfigurations-Schema.
❖ Vollständige Implementierung Networking Feature.
❖ Möglichkeit feinteiligen Service-Network Platzierung.
❖ Möglichkeit zur vordefinierten Build-Reihenfolge.
❖ Unterstützung von zusätzlichen Build-Argumenten.
❖ Allgemeine Verbesserung in der YAML-Struktur.
10
11. Compose why?
❖ Alternativen
❖ Dusty (https://github.com/gamechanger/dusty)
❖ Ansatz einer nativen Workbench, Inter-Container
File-Transfer, sehr gute OS-X Integration, spec’s
❖ Gockerize (https://github.com/aerofs/gockerize)
❖ Compose Ansatz für das container-basierende
micro-service deployment von GO Applikationen.
11
12. Compose why?
❖ Alternativen
❖ Rocket/CoreOS (Enterprise Container Plattform)
❖ Rocket (rkt) als Alternative zu Docker
❖ Key/Value Store Communication (etcd)
❖ Direkte Unterstützung von Kubernetes
❖ Warehouse-Scale Computer (systemd@fleet)
❖ Docker-kompatible Definitions-Struktur
12
13. Compose why?
❖ Alternativen
❖ Kubernetes (Enterprise Container Management)
❖ Das Tool zur Orchestration von Container Cluster
❖ Umfangreiches Management dieser „Pod’s“
❖ Verwaltung der zugehörigen Laufzeitumgebung
❖ wirklich persistente Volumen-Container
❖ sehr guter Network Layer (flannel) + etcd Unterstützung
13
14. docker in action, … composing and practical issues
DOCKER
COMPOSE
Part 2, Atlassian Workbench
14
15. Atlassian Workbench
❖ Was ist eine Workbench?
❖ praktisches Beispiel „Atlassian Services“
❖ Ziel & Service-Architektur
❖ Konfigurations-Struktur
❖ Backup-Strategien
❖ Lastverteilungs-Strategien
❖ Best Practices
15
16. Atlassian Workbench
❖ Was ist eine Workbench?
❖ „Application-Node Service Stack (Development)“
❖ Bereitstellung einer Container-Node-Kopie von
komplexen Anwendung-Infrastrukturen als
lokale Entwicklungs-Umgebungen.
❖ „Application-Group Service Stack (Productive)“
❖ Eine gruppierte Container Infrastruktur
verschiedener Dienste mit Anwendungs-Charakter.
16
17. Atlassian Workbench
❖ praktisches Beispiel „Atlassian Services“ ⇢Ziel?
❖ Aufbau einer Service-Infrastruktur zur
Container-basierenden Bereitstellung von
drei verschiedenen Atlassian Applikationen
❖ JIRA, Confluence, Bitbucket-Server
❖ Verwendung eigener docker-images ⇢ docker-hub
❖ Container sollten lastoptimiert konfiguriert werden.
17
18. Atlassian Workbench
❖ praktisches Beispiel „Atlassian Services“ ⇢Architektur
❖ NGINX Proxy als Service-Kommunikator
❖ JIRA, Confluence, Bitbucket-Server in aktueller
Version als Einzel-Container
❖ Drei Anwendungsspezifische MySQL Container
❖ Möglichkeit zur Nutzung von Daten-Containern für
MySQL- und Atlassian-Data Volumes schaffen.
18
20. Atlassian Workbench
JIRA
(tomcat)
NGINX
(Reverse Proxy)
MySQL db
CONFLUENCE
(tomcat)
MySQL db
BITBUCKET
(tomcat)
MySQL db
user
data only data only data only
ssh
80/443
3306 3306 3306
79998080 79908090
⇢Architektur/Grundstruktur+Ports
20
21. Atlassian Workbench
❖ Konfigurations-Struktur ⇢ docker-compose.yml
❖ Verwendung des neuen Konfigurations-Formats
❖ Networking als Link-Ersatz
❖ Container-Dependencies zur genauen Definition der
geforderten Build-Reihenfolge
❖ Definition einer „Lastgrenze“ für alle sich in der
Workbench befindlichen Container.
21
23. Atlassian Workbench
❖ Backup Strategien
❖ Anwendungs-Container benötigen funktionierende
Backup-Strategien!
❖ Container sind isolierte Prozesse, besitzen daher
nur zur Laufzeit Daten-Persistenz
❖ Container sind vom Host aus jederzeit erreichbar
❖ Ich möchte 3 verschiedene Ansätze vorstellen …
23
24. Atlassian Workbench
❖ Backup Strategien
1. Der Data-Volume Ansatz:
⇢ Ein definiertes Host-Verzeichnis wird dem Container
Als Daten-Verzeichnis zur Verfügung gestellt.
2. Der Daten-Container Ansatz:
⇢ Eine zur Startzeitpunkt erstellte „Schattenkopie“
des Ziel-Containers dient als eigentliches Union-FS
…
24
25. Atlassian Workbench
❖ Backup Strategien
3. Der „Exec-Pipe“ Ansatz:
⇢ Script für Atlassian DB- und File-Backup findet
ihr im GIT Repository unter „df-atls-base/scripts“
25
26. Atlassian Workbench
❖ Lastverteilungs-Strategien
❖ Ein aktiver Container unter Last nutzt alle
verfügbaren Ressourcen desTrägersystems.
⇢ dies kann (in Verbindung mit dem Restart-Feature)
zu unangenehmen Nebenwirkungen führen!
❖ Eine Vor-Definition der Verfügbaren Ressourcen ist
Grundsätzlich keine schlechte Idee.
26
28. Atlassian Workbench
❖ Best Practices
❖ Docker
❖ Bitte keine Container Umzugs-Hysterie entwickeln.
❖ Falls doch, den Micro-Service in angepasster
Umgebung leben lassen.
❖ Keine multiplen Dienste in einem Container
platzieren und diese über supervisor laufen lassen.
28
29. Atlassian Workbench
❖ Best Practices
❖ Dockerfile-Struktur
❖ Zusammenhängende Bild-Prozesse aneinander
binden, somit überflüssige Layer vermeiden.
❖ Umgebungsvariablen für Setup nutzen.
❖ Verwendung von Start-/CleanUp-Scripts
anstreben.
29
30. Atlassian Workbench
❖ Best Practices
❖ Allgemeines
❖ Bash Skripte/Alias-Definitionen für Docker-
Commands erstellen.
❖ Laufzeit Monitoring nicht vernachlässigen
❖ Vorsichtiger Einsatz in Produktiv-Umgebungen.
30