Docker Workbench
1 gefällt mir919 aufrufe
Das Dokument ist eine Präsentation über Docker-Compose, die die Vorteile und Herausforderungen von Container-Management erläutert und praktische Beispiele anhand von Atlassian-Services präsentiert. Es werden Best Practices für die Konfiguration, Backup-Strategien und Lastverteilung diskutiert, um die Effizienz in der Entwicklung mit Docker zu steigern. Alternativen zu Docker-Compose, wie Kubernetes und Mesos, werden ebenfalls erwähnt.
Docker Workbench
- 1. Docker Workbench dunkelfrosch.com | twitter.com/dunkelfrosch | github.com/paterik v0.9.5, german image: https://en.wikipedia.org/wiki/MV_Rena#/media/File:NZ_Defence_Force_assistance_to_OP_Rena.jpg 1
- 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
- 6. Compose why? ❖ Warum docker-compose? ❖ Composition: Vereinfachung eines komplexen Verbund-Container-Managements (Micro-Services). ❖ Configuration: YAML basierendes, einfaches, übersichtliches Konfigurations-Schema. ❖ Consistence: Einheitliche Verwaltungs-Struktur. ❖ Convenience: Einfache Handhabung der (doch recht umständlichen) nativen Docker Verwaltungs-Prozesse. 6
- 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
- 8. Compose why? ❖ Nachteile von docker-compose ❖ intern noch als „vorläufiges Tool“ gekennzeichnet ❖ ungenügende observer/monitoring Funktionalität ❖ fehlendes Kommunikations-Pattern (sockets) ❖ fehlendes Container Exec Return Code Handling ❖ problematische Abhängigkeits-Erkennung (< v1.6) ❖ unvollständiger Docker-Funktionsumfang (< v1.6) 8
- 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
- 19. 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 ⇢Architektur/Grundstruktur 19
- 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
- 22. Atlassian Workbench ❖ Konfigurations-Struktur ⇢ NGINX ⇢ JIRA ⇢ BITBUCKET ⇢ CONFLUENCE ⇢ MySQL Micro-Services (inklusive Daten-Container) 22 ⇢ Quellen stehen im Repository zur Verfügung
- 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
- 31. Questions ? 31
- 32. Thank You ❖ Links/Referenzen ❖ https://blog.codecentric.de/2015/05/microservice- deployment-ganz-einfach-mit-docker-compose ❖ https://blog.codeship.com/docker-machine-compose-and- swarm-how-they-work-together/ ❖ Beispiel-Code Repository ❖ https://github.com/dunkelfrosch/docker-atlassian-wb 32