Das neue Blog ist da

Nach 4 Jahren wurde es mal Zeit für ein neues Blog/Design. Mein Blog war ja eine simple Eigenentwicklung, ein PHP Script, dass Posts auflistet sowie eine Markdown-Textdatei durch einen Markdown2HTML Converter jagt. Schon wird der Post dargestellt. Auf unsichere, ressourcenhungrige, langsame und schwer updatefähige CMS wie Wordpress kann ich gerne verzichten.

Genau für diesen Zweck gibt es Static-Site Generatoren. Statt ohnehin statischen Content jedes mal auf’s neue dynmasich zu generieren, wird dieser einmal generiert und das fertige HTML hochgeladen.

Hugo: ein Static-Site-Generator

Ich benutze dazu Hugo, ein in GO geschriebener SSG. Per Bedarf kann direkt ein lokaler Webserver gestartet werden, der die Seite in Echtzeit generiert:

hugo server --ignoreCache --disableFastRender

Dank der GO-Binary kann man direkt loslegen, es hat eine Vielzahl an modernen Themes, und die alten Blog-URLs können auch übernommen werden. Reine HTML-Seiten kann man auch weiterhin benutzen, falls man einen Post/Seite direkt in HTML geschrieben hat.

Doch warum sollte ich alte Blog-URLs übernehmen statt diese einfach unverändert beizubehalten?

Das ist das große Problem von Hugo, man kann die URLs nicht ändern.

Zum Beispiel möchte ich, das sowohl die Übersicht der Blogposts als auch die Posts selbst unter /blog/ liegen. Die meisten Themes geben aber vor, dass diese unter /posts/ stehen. Oder nehmen wir eine Übersicht der Kategorien, diese hätte ich gerne unter /blog/categories/ verfügbar, diese stehen jedoch direkt unter /tags/. Dies ist zur Zeit leider nicht änderbar: Change the URL for categories and tags - support - Hugo Discussion

Wer eine Subdomain für’s Blog hat, den wird das sicher nicht stören. Ich habe mich damit abgefunden, da ich weder mein eigenes Theme schreiben möchte, noch die Index-Seiten selbst generieren will.

CI/CD

Nun möchte man ja vielleicht mal von unterwegs per WebGUI ganz unkompliziert einen Blogpost schreiben, statt da irgendwie erst eine Binary runterzuladen und auf der Kommandozeile rumhacken zu müssen, um den Hugo Server zu starten. Mit Continuous Integration / Continuous Deployment kein Problem: Bequem im Gitlab WebEditor oder sonstwo eine neue Markdown-Datei schreiben, commit drücken und die Änderungen werden automatisch neu “gebaut” und hochgeladen.

Hier Teile ich gerne mein .gitlab-ci.yml:

before_script:
  - apk add openssh-client bash rsync git
  - git submodule update --init --recursive
build:
  stage: build
  image: jojomi/hugo:0.53
  script:
  - hugo version
  - hugo -d public
  artifacts:
    paths:
    - public
    expire_in: 1 week
buildLatest:
  stage: build
  image: jojomi/hugo:latest
  script:
  - hugo version;
  - hugo -d latest;
  allow_failure: true
deploy:
  stage: deploy
  image: alpine
  script:
  - eval $(ssh-agent -s)
  - bash -c 'ssh-add <(echo "${SSH_PRIVATE_KEY}")'
#  - mkdir -p ~/.ssh
#  - echo "${SSH_HOST_KEY}" > ~/.ssh/known_hosts
  - time rsync -rtz --delete --stats -e 'ssh -p 22 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null' public/ "${SSH_USER_HOST}:${REMOTE_LOCATION}"
  dependencies:
    - build
  only:
  - master

Als Shell für den CI-User bietet sich rssh an, um den Zugriff auf rsync alleine einzugrenzen. rsync muss dazu erst in der rssh config freigeschalten werden.


Blog

467 Words

2019-02-06