Kolumne

Docker rockt Java: Neuigkeiten aus dem Docker-Ökosystem

Peter Roßbach

Das Docker-Ökosystem wächst unaufhaltsam, und alle zwei Monate gibt es ein neues Release der Docker-Werkzeuge. Das Release von Anfang 2016 bringt größere Veränderungen und schafft neue Möglichkeiten. Denn erstmalig ist das Docker-Image-Format grundlegend verändert worden. Docker-Compose realisiert ein neues Format mit der Unterstützung von Multi-Host-Network- und Volume-Management.

Neben zahlreichen kleinen Ergänzungen und vielen Bugfixes bringt das neue Engine-Release eine sicherere Grundlage für die Referenzierung von Images und Layern. Endlich werden die Image-IDs auf der Basis der Inhalte eines Layers gebildet. Die neuen IDs ermöglichen dem Docker-Hub und der neuen Registry 2.3 endlich eine bessere Deduplication-Erkennung und damit das effektive Sparen von jeder Menge Plattenplatz. Images lassen sich nun einfach auf verschiedenen Hosts erzeugen, gleiche Inhalte generieren nun dieselben IDs. Außerdem ermöglicht ein neues Manifestformat schnelleres Laden von Layern. Nach dem Start der neuen Engine wird nun eine automatische Aktualisierung bestehender Images durchgeführt. Wer viele Images auf einem Docker-Host installiert hat, kann deshalb mit einer längeren Wartezeit rechnen. Für diesen Zweck ist das Docker-Migration-Tool besser geeignet.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Anleitung zur Migration der Docker-Images auf das neue Format

  • Stopp der alten Docker-Engine
  • Back-up des Docker-Hosts vor dem Update
  • Start der alten Docker-Engine
  • Start der Migration mit docker run –rm -v /var/lib/docker:/var/lib/docker –privileged docker/v1.10-migrator
  • Stopp der alten Docker-Engine
  • Update auf die neue Docker-Engine 10 und Start der neue Engine mit Containern

Eine erfreuliche Erweiterung ist die Möglichkeit, zur Laufzeit die Beschränkungen der Ressourcen CPU, Memory und I/O zur Laufzeit mit dem Docker-Befehl docker update verändern zu können, siehe Listing 1. Weitere Sicherheitsmerkmale sind in der Docker-Engine mit der Unterstützung von User-Maps zur Isolierung von Nutzern in Containern und der Nutzung des Seccomp-Standards hinzugekommen. Weitere Plug-in-APIs für Authentifikation und IPAM-Management sorgen für zusätzliche Möglichkeiten, die Engine zu erweitern. Für die flexiblere und schnellere Namensauflösung sorgt nun ein lokaler DNS-Server.

$ docker run -d --name node1 \
  --cpu-shares 2048 --cpuset-cpus 0,1 infrabricks/stress
$ docker run -d --name node2 \
  --cpu-shares 512 --cpuset-cpus 0,1 infrabricks/stress
$ docker stats
$ docker update --cpu-shares 4069 node2
$ docker stats
$ docker update --cpu-shares 2048 --cpuset-cpus 2,3 node2
$ docker stats
$ docker stop node1 node2
$ docker rm node1 node2

Docker Compose 1.6: Jetzt mit Volume- und Multi-Host-Netzwerken

Die Erweiterungen von Compose sind mit dem Release 1.6 vielfältig. Das neue Beschreibungsformat bringt zahlreiche Neuerungen, siehe Listing 2 und 6. Endlich können Docker-Files und Build-Argumente in der Build-Deklaration angegeben werden. In der Kombination mit der Imageanweisung lässt sich das Docker-Image nun gleich mit einem verwendbaren Namen erzeugen. Wichtige Neuerungen sind auch die Unterstützung von Volume- und Multi-Host-Netzwerken. Ein Container kann nun gleich mit mehreren verschiedenen Netzwerken generiert werden. In Compose ist die Integration von Swarm stark verbessert worden. Das gesamte REST-Docker-Engine-API 1.23 zur Erzeugungen von Containern lässt sich nun mit Compose konfigurieren.

version: "2"
services:
  app:
    build:
      context: .
      args:
        buildno: 1
      dockerfile: Dockerfile.dev
    image: infrabricks/demo-inc-app
    links:
      - redis
    ports:
      - "8080"
    networks:
      - app
      - db
    environment:
      - "affinity:container!=*app*"
  redis:
    image: redis
    ports:
      - "6379"
    networks:
      - db
    command: [ "redis-server", "--appendonly", "yes" ]
    volumes:
      - redisdata:/data
networks:
  db:
    driver: overlay
  app:
    driver: overlay
volumes:
  redisdata: {}

Docker Swarm 1.1: Rescheduling als Experimental

Viele Kleinigkeiten behebt das Release Docker Swarm 1.1. Und es verbessert die Unterstützung des Docker-Engine-API. Weiterhin wird der alternative Mesos-Scheduler immer leistungsfähiger. Ein paar entscheidende Merkmale fehlen in Docker-Swarm bisher, die Kubernetes oder Mesos-Marathon schon lange unterstützen. Den Neustart von Containern unterstützt die Docker-Engine schon länger, aber Swarm fehlen bisher die Features Rescheduling und Autoscaling. In Swarm 1.1 wird nun das Rescheduling als Experimentalfeature integriert, siehe Listing 3. Container, die mit einem Rescheduling-Flag als Label oder einer Environment-Variable markiert sind, können nach einem Crash einer Maschine auf andere Maschinen automatisch verteilt werden:

# Generierung des Cluster mit der Swarm Option -experimental nicht vergessen!
$ eval $(docker-machine env mob-net-001 --swarm)
$ docker run -d --env="reschedule:on-node-failure" redis
$ docker run -d -l 'com.docker.swarm.reschedule-policy=["on-node-failure"]' redis

Leider wird bei dem Umzug das Volume nicht einfach mit umgezogen, außer das installierte Volume-Plug-in, z. B. das Plug-in Flocker, unterstützt dies. Im Test wechselte der umgezogene Container noch die IP-Adresse im Overlay-Network. Vielleicht kann dies in naher Zukunft besser gelöst werden.

 

Mehr Stabilität mit Docker Machine 0.6

Kleine Bugfixes und eine Vielzahl von Stabilitätsfeatures prägen das Release Docker Machine 0.6. Außerdem ist Dokumentation verbessert worden. Das Skript create-network.sh zeigt die Verwendung zur Anlage eines lokalen Multi-Host-Network-Swarm-Clusters, siehe Listing 3. In einer separaten Maschine wird Consul installiert, um als Key-Value Store für das Overlay-Netzwerk und den Swarm-Cluster zu dienen. In einer Schleife werden dann die Docker-Hosts für den Cluster erzeugt (Listing 3).

#!/bin/bash
SWARM_OPT="--swarm-opt -experimental"
_s=$(docker-machine status moby-consul)
if [ $? -eq 1 ] ; then
  docker-machine create \
      -d virtualbox \
      --engine-label "cluster=moby" \
      moby-consul

  docker $(docker-machine config moby-consul) run -d \
      -e "GOMAXPROCS=2" \
      -p "8500:8500" \
      -h "consul" \
      --restart=always \
      progrium/consul -server \
        -advertise $(docker-machine ip moby-consul) \
        -ui-dir=/ui -data-dir=/data -bootstrap
  sleep 5
fi

: ${NODE_FIRST:=1}
: ${NODE_LAST:=2}
: ${NODE_MEMORY:=1024}
: ${NODE_CPU:=1}

for NODE in $(seq -f "%03g" ${NODE_FIRST} 1 ${NODE_LAST}) ; do
  _s=$(docker-machine status moby-net-${NODE})
  if [ $? -eq 1 ] ; then
    if [ "$NODE" == "001" ] ; then
      MASTER="--swarm-master"
    else
      MASTER=""
    fi

    docker-machine create \
      -d virtualbox \
      --virtualbox-memory ${NODE_MEMORY} \
      --virtualbox-cpu-count ${NODE_CPU} \
      --engine-opt="cluster-store=consul://$(docker-machine ip moby-consul):8500" \
      --engine-opt="cluster-advertise=eth1:2376" \
      --engine-label="cluster=moby" \
      --swarm $MASTER $SWARM_OPT \
      --swarm-discovery consul://$(docker-machine ip moby-consul):8500/moby \
      moby-net-${NODE}
  fi
done

Die Verteilung von Containern auf mehrere Maschinen durch den Swarm-Master moby-net-001 erfolgt mithilfe des Docker-Compose-Files aus Listing 2. Die Skalierung der Anwendung app kann auf verschiedene Maschinen durch die Affinity-Deklaration des App-Service gesteuert werden. Alle Anwendungen sind im DB-Netz und erreichen über die Linkanweisung dasselbe Redis-Backend. Aufpassen beim Neustart des eigenen Rechners müssen die Virtualbox-Maschinen mit denselben IP-Adressen, bzw. die in derselben Reihenfolge gestartet werden.

$ NODE_FIRST=1 NODE_LAST=3 ./create-network.sh
$ eval $(docker-machine env mob-net-001 —swarm)
$ docker-compose up -d
$ docker-compose scale app=3

Fazit

Das Stöbern in der Dokumentation nach weiteren Neuigkeiten lohnt. Natürlich gibt es für die Mac- und Windows-Nutzer eine aktuelle Docker-Toolbox. Wünsche für weitere Docker-Features bleiben natürlich immer bestehen. Docker Machine fehlt noch eine individuelle Provisionierungsmöglichkeit, die nach der Installation der Maschine erfolgt. Die Installation von Docker-Plug-ins ist nur mit individuellen Skripten oder Ansible möglich. Hilfreich wäre es natürlich auch, wenn lokale Installationen mit verschiedenen Linux-Distributionen unterstützt würden. Nach einer Bereitstellung von einem Docker-Machine-Cluster wäre es hilfreich, verschiedene Docker-Compose-Befehle auszuführen. Das Thema Volume-Management und automatische Migration auf andere Docker-Hosts wird sehnlichst von vielen Docker-Nutzern erwartet. Vielleicht bringt die geplante Unterstützung von ZFS in Ubuntu 16.04 hier bald Abhilfe [1], [2]. Mit der Bereitstellung der kommerziellen CaaS-Plattform von Docker Inc. gibt es sicherlich gute Chancen für die baldige Erfüllung einiger dieser Wünsche in naher Zukunft. Ein Blick auf die Fortschritte der Projekte Mesos, Kubernetes, OpenShift oder anderer Docker-Cloud-Angebote lohnt sich.

Geschrieben von
Peter Roßbach
Peter Roßbach
Peter Roßbach ist ein Infracoder, Systemarchitekt und Berater vieler Websysteme. Sein besonderes Interesse gilt dem Design und der Entwicklung von komplexen Infrastrukturen. Er ist Apache Tomcat Committer und Apache Member. Mit der bee42 solutions gmbh realisiert er Infrastrukturprodukte und bietet Schulungen auf der Grundlage des Docker-Ökosystems, aktuellen Webtechnologien, NoSQL-Datenbanken und Cloud-Plattformen an.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: