Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Docker und Kubernetes Patterns & Anti-Patterns

Docker und Kubernetes Patterns & Anti-Patterns

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.

Josef Adersberger

March 13, 2018
Tweet

More Decks by Josef Adersberger

Other Decks in Technology

Transcript

  1. Safe Harbor Statement • Selbst identifizierte und recherchierte Patterns -

    
 teilweise noch nicht geläufig • Haben sich in realen Projekten als wertvoll erwiesen • Auswahl, kein Anspruch auf Vollständigkeit • Kein Pattern-Formalismus
  2. WIE ????? … so dass es mir bei der Entwicklung

    und in Produktion nicht auf die Nase fällt.
  3. docker run -it -v /var/run/docker.sock:/var/run/docker.sock qaware/devbox Dings Bums * *

    Abstraktionsgrad Sweetspot für Docker/k8s Patterns/Antipatterns Abstraktion stabil genug Konkrete Beispiele möglich
  4. OPS COMPONENT DESIGN Design Components • Complexity unit • Data

    integrity unit • Cohesive feature unit • Decoupled unit PATTERN • Planning unit • Team assignment unit • Development unit • Integration unit BUILD Dev Components + RUN Ops Components • Release unit • Deployment unit • Runtime unit • Scaling unit +
  5. Container = Verpackung für Ops Components Standard-Schnittstellen für Standard-Betriebsprozeduren Einfach

    zu transportierende, schnell zu startende und mit wenig Overhead ausführbare Software-Einheiten
  6. Container Prozess
 (pid 1) Well-behaved Process reagiert auf SIGTERM [1]

    oder 
 definiert ein STOPSIGNAL [2] für einen
 würdevollen Abgang gibt sinnvolle Exit Codes zurück [3]:
 0 = OK, 1 = allgemeiner Fehler, … schreibt Log-Ausgaben auf 
 STDOUT/STDERR [4], damit sie per 
 Docker Log Driver verschifft werden 
 können Vordergrund-Prozess, kein 
 Daemon- oder Hintergrund-Prozess
 CMD ["nginx", "-g", "daemon off;"] [1] https://medium.com/@gchudnov/trapping-signals-in-docker- containers-7a57fdda7d86 [2] https://docs.docker.com/engine/reference/builder/#stopsignal [3] http://tldp.org/LDP/abs/html/exitcodes.html [4] https://success.docker.com/article/Docker_Reference_Architecture- _Docker_Logging_Design_and_Best_Practices [5] http://label-schema.org/rc1 [6] https://alexei-led.github.io/post/docker_testing Container Interface EXPOSE von allen 
 von außen zugänglichen Ports
 EXPOSE 80 443 Alle Umgebungsvariablen,
 die von außen gesetzt werden können
 per ENV definieren und möglichst mit
 sinnvollem Default-Wert besetzen
 ENV NGINX_VERSION 1.9.9 Dockerfile als Interface Definition Kommentare und LABEL [5] ENV, EXPOSE und VOLUME
 (möglichst im Block und ganz am Schluss) ENTRYPOINT für Prozessstart und 
 CMD für Default-Argumente
 ENTRYPOINT ["/entrypoint.sh"] 
 CMD ["--db", "localhost","--user", “root”] Standard-Entrypoints 
 (z.B. docker run my-container /usr/bin/test) run: Container produktiv laufen lassen (default) run-dev: im Dev-Modus laufen mit z.B. Verbose Log test: Testfälle im Container durchlaufen lassen HEALTHCHECK: einen Healthcheck durchführen debug: eine passende interaktive Shell öffnen help: einen Hilfe zur Verwendung anzeigen
  7. CONTAINER INITIALIZER PATTERN Container Initializer
 (pid 1) Prozess Prozess- management


    (Exit, SIG, Zombies) Log- Umleitung (syslog, files) Config- Dateien schreiben Cron Warten auf TCP/HTTP Endpunkt Chaperone
 (veraltet) x x x x Dockerize x x x Tini 
 (in Docker > 1.13 enthalten) x dumb-init x pid1 x TrivialRC x phusion baseimage x x x … oder eigenes Shell-Skript oder Go-Programm (aber Achtung: Prozess stets mit exec starten!)
  8. IMAGE LAYER ARCHITECTURE PATTERN Layer 2 Layer 4 Layer 3

    My Image Layer 1 FROM debian:jessie ENV NGINX_VERSION 1.12.2-1~jessie RUN apt-get update && \ apt-get install -y ca-certificates && \
 nginx=${NGINX_VERSION} && \ rm -rf /var/lib/apt/lists/* RUN ln -sf /dev/stderr /var/log/nginx/error.log EXPOSE 80 443 CMD ["nginx", "-g", "daemon off;"] Layer 5 jede Instruktion im Dockerfile erzeugt einen neuen Layer (manche einen mit 0 Bytes) Base Image Scratch Niemals latest Tag nutzen!
  9. Layer 2 Layer 4 Layer 3 My Image Layer 1

    Layer 5 Änderung FROM debian:jessie ENV NGINX_VERSION 1.12.2-1~jessie RUN apt-get update && \ apt-get install -y ca-certificates && \
 wget nginx=${NGINX_VERSION} && \ rm -rf /var/lib/apt/lists/* RUN ln -sf /dev/stderr /var/log/nginx/error.log EXPOSE 80 443 CMD ["nginx", "-g", "daemon off;"] Cache wird invalidiert [1]: Muss neu gebaut und transportiert werden! [1] mehr zu Docker Caching: https://www.ctl.io/developers/blog/post/caching-docker-images
  10. Layer 2 Layer 4 Layer 3 My Image Layer 1

    Layer 5 Änderungs- und Transporteinheit klein geringer Impact von Änderungen
  11. Layer 2 Layer 4 Layer 3 My Image Layer 1

    Layer 5 Base Image volatil stabil klein groß klein: Alpine-*, Baseimage- Docker, Busybox, Scratch • Minimale Docker Images mit Java 9: https://blog.dekstroza.io/building-minimal-docker-containers-with-java-9 • Security Checks von Docker Images: Clair & docker-bench-security & dockscan 1. Abhängigkeiten 2. Applikation 3. Konfiguration 4. Metadaten / Schnittstelle
  12. IMAGE SHRINKING 101 • Unnötige Layer vermeiden • RUN Chaining:

    
 RUN apk add --update wget git && rm -rf /var/cache/apk/* • Alle Layer verschmelzen zu einem (nur bei Basis-Images empfehlenswert): 
 docker export + docker import
 • Platzschonende Installation von Paketen
 RUN apt-get update && apt-get install -y —no-install-recommends apache2 wget && apt-get clean && rm -rf /var/lib/apt/lists/*
  13. STATEFUL CONTAINER ANTIPATTERN mycontainer Prozess Container FileSystem • Zustand im

    Hauptspeicher: User-Session • Zustand auf Platte: Logs, Anwendungsdaten • Container sind flüchtig: Zustand kann verloren gehen • Das Container FS ist langsam mycontainer VOLUME In-Memory 
 DB/Grid 
 (z.B. redis, Ignite, Hazelcast) Für Log-Dateien: RUN ln -sf /proc/1/fd/1 /var/log/test.log Prozess
  14. CONTAINER UNIT TESTING PATTERN nginx-container-test.rb describe package('nginx') do it {

    should be_installed } end describe port(80) do it { should be_listening } end https://www.inspec.io Alternativen: goss+dgoss, ServerSpec, Bats, Testinfra
  15. ENTERPRISE POD ANTIPATTERN Pod Web
 Server Data- base App
 Server

    • verletzt das Single
 Responsibility Prinzip • Scheduling schwierig 
 durch hohe Anforderungen • unzureichende Isolation 
 (Netzwerk, Volumes, IPC,
 Hostname, PID) MQ
 Broker
  16. STRUCTURAL CONTAINER PATTERNS • Scheduling (Quartz) • Failbot Pod Application

    Container Pattern Container Other Container “Design patterns for container-based distributed systems”. Brendan Burns, David Oppenheimer. 2016 Sidecar (Sidekick): Enhance container behaviour Ambassador: Proxy communication • TLS tunnel (Stunnel, ghosttunnel, istio) • Circuit Breaking (linkerd, istio) • Request monitoring (linkerd, istio) Adapter: Provide standardized interface • Configuration (ConfigMaps & Secrets to files) • Log extraction / re-formatting / shipping (fluentd)
  17. EXTERNALIZED CONFIGURATION apiVersion: v1 kind: ConfigMap metadata: name: april-aos-runtime-config data:

    april-aos.properties: | com.foo.iap.april.jwt.secret=some-secret osmc.username=april osmc.url=https://www.magic.works ... april-feature-togglz.properties: | WRITE_TEXT5_TO_SOFAK_INVOICES=false ... log4j2.xml: | <?xml version="1.0" encoding="UTF-8"?> <Configuration monitorInterval="60"> <Appenders> ... </Appenders> <Loggers> ... </Loggers> </Configuration> spec: containers: - name: april-aos-runtime image: 'april-aos-runtime:1.5.0' imagePullPolicy: Always ports: - containerPort: 8080 volumeMounts: - mountPath: /april/cfg name: april-aos-runtime-config-vol volumes: - name: april-aos-runtime-config-vol configMap: name: april-aos-runtime-config PATTERN Umgebungsspezifische Konfiguration: ConfigMap ENV Dynamische Konfiguration: ConfigMap Files Statische Konfiguration: Config Files im Container
  18. PACKAGE MANAGEMENT PATTERN • kubectl, kubectl, kubectl, … • Konfiguration?

    • Endpunkte? https://helm.sh • Chart suchen auf https://hub.kubeapps.com • Doku dort lesen (README.md) • Konfigurationsparameter lesen: 
 helm inspect stable/spark • Chart starten mit überschriebener Konfiguration:
 helm install --name my-release 
 -f values.yaml stable/spark
  19. SERVICE MESH PATTERN Pod Pod Pod • Sichere Kommunikation (2-Way-SSL,

    Token Relay) • Resilienz (Circuit Breaker) • Policy Enforcement • Diagnostizierbarkeit (Traces, Logs, Metriken) • A/B Testing, Canary Releases • Fault Injection, Latency Testing • Location Transparency Pod Pod Pod Proxy Proxy Proxy Mesh Control Plane • ohne Anpassung der Anwendungen! • zentral gesteuert!
  20. DIAGNOSABILITY TRIANGLE Metrics (RED = rate, errors, duration) Events /

    Logs Distributed Traces Diagnosability Triangle
  21. OPERATORS (Betriebsroboter) [1] https://coreos.com/operators [2] https://kubernetes.io/docs/concepts/api-extension/custom-resources [3] https://github.com/giantswarm/operatorkit [4] https://github.com/sapcc/kubernetes-operators

    [5] https://www.youtube.com/watch?v=cj5uk1uje_Y Zustandsbehaftete 
 Infrastruktur
 (z.B. Datenbanken) • Cluster Join / Leave • Failover auslösen • Fehlerzustände erkennen • Migration von Daten Standard-
 Betriebsprozeduren für Anwendungen • Zertifikate einspielen • Neue Konfiguration einspielen • Komplexe Rollout-Szenarien • Alerting …
  22. DEV ORCHESTRATION PATTERN • schnelle Roundtrips • geringe Komplexität •

    lokales Troubleshooting Bei einzelnen lokalen Prozessen, die in ein existierendes Remote- Cluster gehängt werden sollen: https://www.telepresence.io kompose K8s and OpenShift Deployment YAML Dockerfile + docker-compose.yml Local Development Cloud Deployment
  23. QUELLEN • Generell • Container Patterns: https://l0rd.github.io/containerspatterns/#1 • Docker •

    DockerFile Best Practices: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#use-a-dockerignore-file • Docker Tools: https://github.com/veggiemonk/awesome-docker • OpenShift General Docker Guidelines: https://docs.openshift.com/enterprise/3.0/creating_images/guidelines.html • Common Docker Mistakes: https://runnable.com/blog/9-common-dockerfile-mistakes • Kubernetes • Kubernetes Patterns: https://vimeo.com/233785743 • Kubernetes Best Practices: https://www.youtube.com/watch?v=BznjDNxp4Hs • Continuous Delivery • Continuous Delivery Patterns: https://continuousdelivery.com/implementing/patterns/
  24. 42