Docker

+ Docker-Compose

12. Webmontag Kassel, 25.11.2016

Über mich

  • Web-/Softwareentwicklung
  • Linux (und BSD) "Serverkram" (lies: DevOps)
  • aus Paderborn
  • 13 Monate Zürich
  • jetzt Kassel ;)

Projekt in Zürich

  • (neben NodeJS)
  • Docker: CI + internes Test-Deployment
  • ab ~ Oktober 2014 docker-compose (release: 1.0)
  • Docker für Entwicklungsinfrastruktur
  • später mehr…

Was ist Docker?

  • Tool zur Isolation von Anwendungen
  • Paketierung samt aller Abhängigkeiten (libraries, module)
  • damit portable Images (Voraussetzung: Docker-Engine)
  • "Framework" für skalierbare Deployments (docker-machine, docker-swarm)
  • …auch unter Mac und Windows "irgendwie" möglich

Funktionsweise

  • Images ("Blaupause") werden erstellt (docker build)
  • Container ("Instanz", basierend auf Image) starten (docker run)
  • Container-Prozess isoliert vom Hostsystem
  • Veränderung nur im Overlay-Dateisystem

(Pseudo-) Live-Coding

                        
[:~] % docker run -it centos:latest /bin/bash
Unable to find image 'centos:latest' locally
latest: Pulling from library/centos
fa5be2806d4c: Pull complete
2bf4902415e3: Downloading [=======================> ] 65.4 MB/70.51 MB
86bcb57631bd: Download complete
c8a648134623: Pulling fs layer
[root@5906c1e05931 /]# cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)
[root@2f8abb19aec1 /]# ls -d /home
/home/
[root@2f8abb19aec1 /]# rm -rf /home/
[root@2f8abb19aec1 /]# ls -d /home
ls: cannot access /home/: No such file or directory

was ist passiert?

  • Image geladen vom Docker Hub
  • andere Distribution
  • eigenes Dateisystem
  • (Docker-) internes Netzwerk

Overlay Dateisysteme

Analogie: Ebenen in Bildverarbeitung
Overlay

Dies gibt uns:

  • Schnelles instanziieren ("klonen")
  • Verwerfen/Rollback
  • geringer Speicherbedarf

Isolation vs Virtualisierung

Virtualisierung

  • "virtueller Computer"
  • eigener Kernel
  • eigenes Userland
  • recht hoher Overhead
  • flexibel: fast jedes Betriebssystem lässt sich ausführen

Typische Vertreter: VMWare, Virtualbox, KVM

Isolation

  • gleicher Kernel
  • eigenes Userland
  • kaum Overhead

Typischer Vertreter: Solaris Zones, FreeBSD Jails, LXC, OpenVZ, "docker"

docker nutzt Kernel-Namespaces und cgroups (früher LXC)

Raus aus der Isolation!

  • Ports von außen weiterleiten
  • Volumes (Dateien) einbinden (z.B. Webserver)
  • Verbindung von Container untereinander

Ports Weiterleiten

…vom Host-Interface zum Docker-Container
docker run -d --name rabbitmq-master \
                    -p 8080:15672 \
                    rabbitmq:management

Container untereinander


# zuerst noch ein paar benötigte Container starten
docker run -d --name mongo-master mongo:2
docker run -d --name redis-master redis
# nun unsere Anwendung
docker run -d -p 80:3000 --name app-master \
    --link redis-master:redis \
    --link mongo-master:mongo \
    --link rabbitmq-master:rabbitmq \
    -e NODE_ENV=production \
    myApp:master

Environment Variablen nun z.B.:

  • RABBITMQ_PORT_5672_TCP_ADDR=172.17.0.2
  • RABBITMQ_PORT_15672_TCP=tcp://172.17.0.2:15672

Commands eintippen ist mühsam…

Man stelle sich vor… jetzt kommt noch der ELK-Stack obendrauf…

docker-compose!

docker-compose.yml für unser Beispiel von vorhin: 

rabbitmq:
  image: rabbitmq:management
  ports:
    - "8080:15672"
mongo:
    image: mongo:latest
redis:
  image: redis
app:
  image: myApp
  environment:
    - NODE_ENV=production
  links:
    - rabbitmq
    - mongo
    - redis
Alles starten: 
$ docker-compose -p master up -d
schönes Beispiel: docker-elk

Was haben wir jetzt?

Entwicklungs-Umgebung

  • docker-compose.yml in VCS einchecken ("Infrastructure as code")
  • keine Installationsorgien
  • jeder Entwickler hat die gleiche Version (und immer die passende für das jeweilige Projekt)
  • passende Konfiguration kann mitgeliefert werden (siehe ELK-Stack)
  • disposable — Dev-Umgebung kann leicht resettet werden
  • Services laufen nicht ständig (Resourcen auf Workstation)

CI

  • beliebig viele Instanzen können nebeneinander getestet/gestartet werden (Isolation!)
  • Workflow: Image auf Herz und Nieren testen, dann exakt das Image deployen
  • Selenium (UI-Tests) im Docker Container (kein X auf dem Server installieren!)
  • Build-Agent hat nur docker als Abhängigkeit

Deployment

  • Images können an den Prod-Server geschickt werden
  • einfache "INSTALL.md"
  • "linken" von Containern ist Netzwerk-Transparent
  • einfachere Konsolidation mehrerer Anwendung auf einem Server (Isolation!)

Hands-on

  • Docker-Compose für Dev-Infrastruktur
  • Docker für CI Workflow
  • docker build
  • Docker auf BTRFS!
  • Security
  • (Image-) Updates

The end…

Elmar Athmer
@oxyfodu
elmar@athmer.org