Komplettes Docker Feature Deployment mit Digital Ocean, Rancher, Traefik und Gitlab | Part 1

Auf der Symfony Live wurde mir mal wieder bewusst wie „rückständig“ man doch selbst ist. Bei Fragen bezüglich Docker und wer es einsetzt gingen 40-50% der Hände nach oben. Vermutlich ist die Dunkelziffer höher, da Entwickler bekanntlich melde faul sind 😉

Docker

Docker hat sich als quasi Standard in der Containerwelt durchgesetzt – das es aktuell scheinbar finanzielle Probleme hat beruhigt nicht unbedingt, ich gehe aber davon aus dass bei einem Niedergang der Firma eine Foundation geben wird (hier findet Ihr andere Optionen)

Auf das Grundprinzip von Docker gehe ich jetzt mal nicht ein, möchte aber kurz einige Vor- und Nachteile ansprechen.

Vorteile

1. Out-of-the-box Images – es gibt für fast jeden Zweck das passende Image und wenn was fehlt, erstellt man einfach selbst eine Dockerfile und erweitert diese
2. Schnelles aufsetzen von Kundenumgebungen ohne Overhead auf dem Entwicklungsrechner.
3. Immer bessere Integration bei großen Hostern mit gutem Support

Nachteile

1. Höherer initialer Aufwand durch Komplexität
2. Teilweise inkompatible/inperformant auf MacOs

docker-compose

Die meisten Projekte haben mehrere Container und daher bietet sich docker-compose als Tool an.

Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration. … Run docker-compose up and Compose starts and runs your entire app. (Quelle)

version: '3'

services:
  db:
    build: mysql
    environment:
      MYSQL_ROOT_PASSWORD: app
      MYSQL_USER: app
      MYSQL_PASSWORD: app
      MYSQL_DATABASE: app
    restart: always
    volumes:
      - ./mysql/dumps:/docker-entrypoint-initdb.d
  php:
    #build: php
    image: php:7.3-apache
    links:
      - db
    volumes:
      - ./shopware:/var/www/html
    ports:
      - 8100:80
    depends_on:
      - db

version

Beschreibt die docker-compose Version und ist wichtig, da einige tags entfernt wurden

services

Beschreibt die services/container und ist auf der Ebene 0

db & php

Sind einfach die Containernamen. Diese können wiederverwendet werden oder mit container-name überschrieben werden.

build & image

Hier könnt Ihr einfach zwischen einem bestehenden Image (docker.hub) oder einer eigenen Dockerfile auswählen. Im Beispiel von db wird eine Dockerfile in mysql gebaut.

enviroment

Hier werden einfach Umgebungsvariablen gesetzt die Ihr später wiederverwenden könnt

restart

Gibt an das der Service bei jedem up neugestartet werden soll

volumes

Linkt den lokalen Ordner direkt in den Container (hier um die *.sql Dateien beim hochfahren des Containers zu importieren)

depends_on

Der PHP Container hängt in diesem Fall vom Mysql Container ab und wartet bis dieser gestartet wurde

ports

Eigentlich nur interessant wenn Ihr lokal auf dem Rechner arbeitet. So lässt sich der Container später über 127.0.0.1:8100 aufrufen. Wenn Ihr networks nutzt mit static IPs funktioniert dies nicht mehr.

Shortcuts

Das erste was Ihr nach 1-2 Tagen Dockernutzung machen wollt ist aliases anlegen. Gerade der docker-compose Befehl ist relativ lang und nervig. Selbst mit autofill von fish-shell o.Ä. doch sehr zeitaufwendig.

################
#### Docker ####
################
alias build="docker-compose build"
alias upd="docker-compose up -d"
alias down="docker-compose down"

Basis Image

Mir ist bei einigen Open Source Projekten immer mal wieder Alpine aufgefallen und ich habe mich in diesem Projekt dann auch mal damit beschäftigt. Alpine ist ein Fliegengewicht wenn es um Unix Distributionen geht. Es ist mit der Docker Version ca. 30 mal kleiner als Debian (Jessie) – aber mehr dazu in diesem spannenden Blogbeitrag

Natürlich muss man sich etwas umgewöhnen was die Installation von Packages und bash angeht. Ich komme von Ubuntu und muss daher statt apt nun apk eingeben um z.B. Nano zu installieren und statt bash nun ash

Das ganze sieht dann für php7.2 mit fpm und alpine wie folgt aus:

FROM php:7.2-fpm-alpine3.10

RUN apk -U upgrade && \
    apk --update add nano

COPY php-config.ini /usr/local/etc/php/conf.d/

Tipp: Wenn Ihr die Images mehrfach baut und up’d und downe’d vergesst zwischendurch mal nicht den prune Befehl. Ich kille so alle 1-2 Wochen mal ALLE mit docker container prune && docker image prune && docker volume prune && docker network prune

PHP und Apache entkoppeln

Die obige docker-composer.yml enthält nur einen service für die PHP Applikation. Hier scheiden sich die Geister. Die einen schwören auf die Single Responsibility die anderen auf zusammen führen, was zusammen gehört.

Im Livebetrieb habe ich gehört das die Connection zwischen Apache/NGINX und php-fpm teilweise nicht stabil war und es zu höheren Latenzen kam. Aktuell nutze ich keine Docker Produktivumgebung und setze daher auf die apache+php Version – simpel aufzusetzen und kein fastcgi Stress…

Anderer Meinung oder bereits produktiv mit PHP und Apache getrennt im Einsatz? Gerne teilen 🙂

Use Case

Wofür also das ganze? Wir entwickeln an Shopware 5 und müssen auch zwischen MacOs und Ubuntu entwickeln. Hier macht es Sinn ein einheitliches Setup zu nutzen – man möchte ja nicht immer das Dev System updaten bzw. kann es hier zu Überschneidungen kommen (mehr dazu im Beitrag „Feature Branches in Shopware mit Rancher deployen“)

Der Import der Datenbank dauert ohne s_user* und s_order* und search* Tabellen knapp 10 Minuten. Also völlig im Rahmen für ein sauberes System

Für die Entwicklung macht es Sinn den Ordner/Repo direkt im Root Pfad der docker-compose.yml liegen zu haben. So könnt Ihr aktiv im Repository entwickeln und euer aktiver Container ist immer aktuell.

Für diesen Zweck habe ich im Shellscript eine –local option hinzugefügt. Bei dieser werden der /etc/hosts automatisch die entsprechenden Einträge hinterlegt. Im Review Modus möchte man keine Änderungen mehr machen – daher wird dort das entsprechende Repository gepulled und ist nicht über Volumes eingebunden.