In diesem Blogpost möchte ich kurz auf die Continuous Deployment-Netzwerk eingehen, mit dem ich diesen Blog und campecho.de veröffentliche. Vorab: Meine Blog-Engine ist jekyll, und eigentlich ist es ein Static Site Generator und keine komplette Blog-Engine; sprich, jekyll generiert aus Config- und Post-Dateien einen Ordner, der dann auf Amazon S3, GitHub Pages oder (wie hier) auf einem eigenen Server laufen kann.

Schaubild Continuous Delivery

Das Konzept läuft folgendermaßen:

  1. An meinem lokalen Rechner habe ich alles, was ich zum Generieren des Blogs brauche. Wenn ich einen neuen Artikel schreibe, wird dieser mit git commit && git push auf ein GitHub hochgeladen.

  2. GitHub schickt dann einen Webhook zu imgbot, dort werden neue Bilder kleiner gerechnet und mir als Pull Request zurückgeschickt. Pull Request von imgbot imgbot ist übrigens von einem Microsoft-Mitarbeiter, der Azure ausprobieren möchte. Wenn ich das richtig verstehe, wird bei jedem Push eine Azure Function hochgefahren. Voll Cloud-native und so 🖖

  3. Bei jedem neuen Commit auf den Master-Branch schickt GitHub zudem einen Webhook an meinen Docker-Host, der bei Hetzner steht. Ein jeyemwey/docker-jekyll-Container empfängt diesen Webhhook, zieht sich den aktuellen Master und baut die statischen Seiten. Der fertige Ordner landet dann in einem Docker-Volume.

  4. Ein abiosoft/caddy-Container hat ebenfalls Zugriff auf das Docker-Volume und servt die Dateien via HTTP (:80) und HTTPS (:443). Dank Caddy muss ich mich nicht mehr um die HTTPS-Zertifikate kümmern.

Jetzt habe ich das Ganze einmal ausgeschrieben, eigentlich war das gar nicht soo kompliziert gedacht. 😳😬

Avatar

Veröffentlicht am von Jannik

Technik Open Source

19 | der blasse, dünne Junge aus der Nachbarschaft | Macht Web Design, Theatertechnik und Pfadfinder | Ist #Wö‑Leiter | Studiert was mit Medien