xoxys/geeklabor_legacy
Archived
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fix small typos
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse Source
This commit is contained in:
Robert Kaussow 2019-02-04 19:44:16 +01:00
parent fed7745d87
commit 764d26e19f
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
content/post/continious-deployment-hugo/index.md
View File

@ -1,9 +1,9 @@
--- ---
title: "Continous Deployment mit Hugo und Drone CI" title: "Continuous Deployment mit Hugo und Drone CI"
date: 2019-02-04T18:00:00+02:00 date: 2019-02-04T18:00:00+02:00
draft: false draft: false
author: robert-kaussow author: robert-kaussow
description: "Static Site Generatoren sind gerade stark in Mode. Doch was voher das Blogsystem automatisch gemacht hat, muss jetzt vom Benutzer selbst durchgeführt werden. Mit Hilfe von Continous Deployment Strategien lässt sich der Arbeitsaufwand aber auf ein Minimum reduzieren." description: "Static Site Generatoren sind gerade stark in Mode. Doch was voher das Blogsystem automatisch gemacht hat, muss jetzt vom Benutzer selbst durchgeführt werden. Mit Hilfe von Continuous Deployment Strategien lässt sich der Arbeitsaufwand aber auf ein Minimum reduzieren."
keywords: keywords:
- open - open
- source - source
@ -11,7 +11,7 @@ keywords:
- static site generator - static site generator
- devops - devops
- cicd - cicd
- continious - continuous
- deployment - deployment
- integration - integration
- automation - automation
@ -27,7 +27,7 @@ resources:
title: Drone Pipeline bei Änderungen am Content-Repository title: Drone Pipeline bei Änderungen am Content-Repository
--- ---
Wie bereits in einem früheren Beitrag erwähnt, nutze ich für meinen Blog mittlerweile Hugo, einen Static Site Generator, anstelle einer Blog-Engine oder eines Content Management Systems. Bisher habe ich die Entscheidung nicht bereut, musste aber feststellen, dass sich mein Workflow im ersten Schritt nicht wirklich verbessert hat. Um das zu beheben, muss man sich als Erstes zwei Dinge anschauen: Wie hat es bisher funktioniert und wo will ich eigentlich hin? Dieser Beitrag soll eine Art Retrospektive sein und meinen Weg zu einer Continuos Deployment Strategie mit Hugo und Drone CI betrachten. Wie bereits in einem früheren Beitrag erwähnt, nutze ich für meinen Blog mittlerweile Hugo, einen Static Site Generator, anstelle einer Blog-Engine oder eines Content Management Systems. Bisher habe ich die Entscheidung nicht bereut, musste aber feststellen, dass sich mein Workflow im ersten Schritt nicht wirklich verbessert hat. Um das zu beheben, muss man sich als Erstes zwei Dinge anschauen: Wie hat es bisher funktioniert und wo will ich eigentlich hin? Dieser Beitrag soll eine Art Retrospektive sein und meinen Weg zu einer Continuous Deployment Strategie mit Hugo und Drone CI betrachten.
Den notwendigen Neuaufbau meiner Infrastruktur habe ich nicht nur zum Anlass genommen, um alles vollständig auf Ansible umzustellen, sondern auch um meinen Softwarestack kritisch zu hinterfragen und aufzuräumen. Jede Software erfüllt natürlich einen Zweck, entscheidend für mich war aber: Wie wartungsintensiv ist die Lösung, wie leicht lässt sie sich automatisch deployen und rechtfertigt der Aufwand den Zweck. Im Fall von meiner Blog-Engine Serendipity (s9y) bin ich zu dem Schluss gekommen, dass ich darauf eigentlich ganz gut verzichten kann. Nebenbei empfand ich mittlerweile die Weboberfläche zur Verwaltung meiner Beiträge als nicht optimal für mich. Ich wollte lieber in einem Artikel meiner Wahl, am besten auch Oflline arbeiten können als in einem Onlineeditor. Außerdem musste man für etwas komplexere Formatierungen dann doch wieder zu HTML und CSS wechseln, weil der WYSIWYG-Editor das nicht hergab und Markdown im Standard da auch relativ beschränkt ist. Damit war die Entscheidung auch schon getroffen, es soll eine neue Lösung her. Den notwendigen Neuaufbau meiner Infrastruktur habe ich nicht nur zum Anlass genommen, um alles vollständig auf Ansible umzustellen, sondern auch um meinen Softwarestack kritisch zu hinterfragen und aufzuräumen. Jede Software erfüllt natürlich einen Zweck, entscheidend für mich war aber: Wie wartungsintensiv ist die Lösung, wie leicht lässt sie sich automatisch deployen und rechtfertigt der Aufwand den Zweck. Im Fall von meiner Blog-Engine Serendipity (s9y) bin ich zu dem Schluss gekommen, dass ich darauf eigentlich ganz gut verzichten kann. Nebenbei empfand ich mittlerweile die Weboberfläche zur Verwaltung meiner Beiträge als nicht optimal für mich. Ich wollte lieber in einem Artikel meiner Wahl, am besten auch Oflline arbeiten können als in einem Onlineeditor. Außerdem musste man für etwas komplexere Formatierungen dann doch wieder zu HTML und CSS wechseln, weil der WYSIWYG-Editor das nicht hergab und Markdown im Standard da auch relativ beschränkt ist. Damit war die Entscheidung auch schon getroffen, es soll eine neue Lösung her.
@ -64,7 +64,7 @@ Ich habe mich für die zweite Methode entschieden und arbeite mit [Git Submodule
- CSS Minify/Beautify für das Theme sicherstellen - CSS Minify/Beautify für das Theme sicherstellen
- Automatisierung des Deployments bei neuen Artikeln oder Änderungen am Theme - Automatisierung des Deployments bei neuen Artikeln oder Änderungen am Theme
Um Bandbreite bei der Übertragung zu sparen kann man CSS oder auch JavaScript Dateien verkleinern. In der Praxis geschieht das im Wesentlichen durch das Entfernen nicht benötigter Zeichen wie Leerzeichen, Leerzeilen und Zeilenumbrüchen. Automatisieren lassen sich solche Tasks beispielsweise mit [gulp.js](https://gulpjs.com/). Mithilfe von Plugins können so beliebige Tasks gruppiert werden. Ein Gulp Task kann beispielsweise so aussehen: Um Bandbreite bei der Übertragung zu sparen, kann man CSS oder auch JavaScript Dateien verkleinern. In der Praxis geschieht das im Wesentlichen durch das Entfernen nicht benötigter Zeichen wie Leerzeichen, Leerzeilen und Zeilenumbrüchen. Automatisieren lassen sich solche Tasks beispielsweise mit [gulp.js](https://gulpjs.com/). Mithilfe von Plugins können so beliebige Tasks gruppiert werden. Ein Gulp Task kann beispielsweise so aussehen:
{{< highlight bash "linenos=table" >}} {{< highlight bash "linenos=table" >}}
const gulp = require('gulp'); const gulp = require('gulp');
@ -103,11 +103,11 @@ Der hier zusammengestellte _defaultTask_ macht der Reihe nach folgendes:
Die aufbereitete Datei _default.min.css_ wird dann als CSS Datei für die fertige Seite verwendet. Wie gesagt, die Tasks lassen sich beliebig erweitern und bei Bedarf unterschiedlich gruppieren. Denkbar ist auch das Kompilieren von SASS oder SCSS Dateien. Die aufbereitete Datei _default.min.css_ wird dann als CSS Datei für die fertige Seite verwendet. Wie gesagt, die Tasks lassen sich beliebig erweitern und bei Bedarf unterschiedlich gruppieren. Denkbar ist auch das Kompilieren von SASS oder SCSS Dateien.
Bleibt zum Schluss nur noch eines. Bei Änderungen sollen automatisch meine Gulp Tasks ausgeführt, die Seite generiert und auf meinen Webspace deployed werden. Am besten eignet sich dazu ein Continuos Integration System wie beispielsweise Travis CI. Ich habe mich allerdings für [Drone CI](https://drone.io/) entschieden. Drone selbst wird als Docker Image bereitgestellt und kann auf dem eigenen Server betrieben werden. Wem das Zuviel Aufwand ist, für den gibt es mittlerweile aber auch eine [Cloud Version](https://cloud.drone.io/). Wie bei den meisten CI Lösungen wird für jedes Repository eine Pipeline definiert, die beschreibt, welche Schritte bei welcher Aktion (Push, Tag, Pull Request) ausgeführt werden sollen. Drone führt dabei jeden Schritt der Pipeline in einem eigenen Docker Container aus. Meine definierten Pipelines für das [Theme-Repository](https://gitea.rknet.org/xoxys/theme-geeklab/src/branch/master/.drone.yml) und das [Content-Repository](https://gitea.rknet.org/xoxys/theme-geeklab/src/branch/master/.drone.yml) findet ihr auf meiner Gitea Instanz. Ich habe an dieser Stelle nur den Ablauf für beide Repositories skizziert. Bleibt zum Schluss nur noch eines. Bei Änderungen sollen automatisch meine Gulp Tasks ausgeführt, die Seite generiert und auf meinen Webspace deployed werden. Am besten eignet sich dazu ein Continuous Integration System wie beispielsweise Travis CI. Ich habe mich allerdings für [Drone CI](https://drone.io/) entschieden. Drone selbst wird als Docker Image bereitgestellt und kann auf dem eigenen Server betrieben werden. Wem das zuviel Aufwand ist, für den gibt es mittlerweile aber auch eine [Cloud Version](https://cloud.drone.io/). Wie bei den meisten CI Lösungen wird für jedes Repository eine Pipeline definiert, die beschreibt, welche Schritte bei welcher Aktion (Push, Tag, Pull Request) ausgeführt werden sollen. Drone führt dabei jeden Schritt der Pipeline in einem eigenen Docker Container aus. Meine definierten Pipelines für das [Theme-Repository](https://gitea.rknet.org/xoxys/theme-geeklab/src/branch/master/.drone.yml) und das [Content-Repository](https://gitea.rknet.org/xoxys/theme-geeklab/src/branch/master/.drone.yml) findet ihr auf meiner Gitea Instanz. Ich habe an dieser Stelle nur den Ablauf für beide Repositories skizziert.
{{< imgproc theme resize "950x" />}} {{< imgproc theme resize "950x" />}}
Die Pipeline für das Theme-Repository ist relativ einfach gehalten. Gulp Tasks ausführen, bei Bedarf geänderte und bereinigte CSS Dateien (Assets) mittels eines Bots zurück in das Repo pushen und eine Benachrichtigung mit dem Status der Pipeline in einen privaten Matrix Channel senden. Fertig. Änderungen an dem Theme werden derzeit bewusst nicht automatisch durch die CI in das Content-Repository übernommen. Möglich wäre das durchaus, ich machte diesen Schritt aber vorerst manuell um Änderungen besser steuern zu können. Die Pipeline für das Theme-Repository ist relativ einfach gehalten. Gulp Tasks ausführen, bei Bedarf geänderte und bereinigte CSS Dateien (Assets) mittels eines Bots zurück in das Repo pushen und eine Benachrichtigung mit dem Status der Pipeline in einen privaten Matrix Channel senden. Fertig. Änderungen an dem Theme werden derzeit bewusst nicht automatisch durch die CI in das Content-Repository übernommen. Möglich wäre das durchaus, ich mache diesen Schritt aber vorerst manuell um Änderungen besser steuern zu können.
{{< imgproc content resize "950x" />}} {{< imgproc content resize "950x" />}}