Es ist immer gut, Dinge zu vereinfachen. Der letzte Beitrag Kontinuierliches Bloggen - Migration zu Docker Cloud war nicht wirklich fertig, und ich hatte versprochen, den Aspekt des “Continuous Deployment” zu optimieren.
Nach dem Fertigstellen eines Blogbeitrags und dem Pushen ins Repository musste ich immer noch manuell Docker-Images erstellen. Erst nach dem Pushen in die Registry wurden sie automatisch in die Produktion deployt. Nicht wirklich im “Continuous Deployment”-Stil.
Mein Ziel war: Nach dem Speichern, Committen und Pushen eines neuen Blogbeitrags ins Repository sollte alles automatisiert sein, sodass der Beitrag direkt auf einem System zum Korrekturlesen landet - wie einer Staging- oder User-Acceptance-Umgebung.
Nach dem Korrekturlesen, wenn alles in Ordnung ist, sollte das Ganze mit einem einfachen Git-Befehl in die Produktion wandern.
Das ist der finale Workflow nach dem Committen des Beitrags:
git push origin master
Das ist alles. Nach ein paar Sekunden werde ich in meinem Slack-Channel benachrichtigt, dass ein neues Image in meiner Docker Cloud deployt wurde. Dann lese ich unter einer Subdomain namens preview Korrektur, und wenn ich zuversichtlich bin, setze und pushe ich nur einen Tag:
git tag -f prod
git push -f --tags
Dann wieder ein wenig auf die Slack-Benachrichtigung warten. Schließlich kann alles unter der www-Subdomain gelesen werden.
Ich habe dies mit zwei zusätzlichen Schritten erreicht:
- Mein Docker-Image für Jekyll modifizieren.
- Automatisierte Build-Jobs zu Docker Cloud hinzufügen.
Der größte Unterschied war, dass ich Nginx nicht mehr benutzte und stattdessen Jekylls eingebauten Webserver zum Bereitstellen des Blogs verwendete. Dadurch konnte ich nur ein Docker-Image zum Bauen und Bereitstellen des Inhalts haben.
FROM jekyll/jekyll:3.4.0
MAINTAINER Cool Guy "guy@cool.com"
RUN gem install jekyll-gist therubyracer json --no-doc --no-ri
ADD. /srv/jekyll
CMD ["jekyll", "serve"]
Dieses Dockerfile wird vom Build-Server aufgegriffen, wann immer es einen Push zum Git-Repository gibt (z.B. GitHub oder Bitbucket).
Die Konfiguration der Build-Jobs ist einfach: Ich mappe Git-Tags auf entsprechende Docker-Tags.
Nachdem das Docker-Image gebaut wurde, wird es automatisch auf den Docker-Host redeployt.
Der Trick ist, den entsprechenden Service auf autoredeploy: true zu setzen:
lb-prod:
image: myloadbalancer:latest
autorestart: always
autoredeploy: true
links:
- myblog-prod
- myblog-preview
ports:
- "80:80"
roles:
- global
myblog-prod:
image: myblog:prod
autorestart: always
autoredeploy: true
myblog-preview:
image: myblog:latest
autorestart: always
autoredeploy: true
Das ist alles. Viel einfacher jetzt, einen neuen Beitrag online zu bringen.
Nur noch eine Sache übrig: lokale Vorschau und Debugging. Einfach!
Eine kurze docker-compose.yml und ein docker-compose up später kann der Blog lokal auf Port 4000 angesehen werden.
version: '2'
services:
jekyll:
build:
context:.
dockerfile: DOCKERFILE
Das war’s für heute!