Fotografie Blog

Ich habe lange Zeit an der Technik meines Blogs gefeilt. Inzwischen ist ein Stand erreicht, mit dem ich sehr zufrieden bin. Für Interessierte hier die Beschreibung der technischen Hintergründe.

Artikel drei von drei: Verwaltung der Inhalte und kostenloses Hosting mit Netlify und Bitbucket.

Übersicht

• Teil 1: Argumente gegen Wordpress
• Teil 2: Statische Webseiten mit Hugo
• Teil 3: Hosting und Deployment

Verwaltung der Inhalte und Konfiguration

In diesem Artikel werden Werkzeuge beschrieben, die vor allem Programmierern geläufig sind oder zumindest technisch orientierten Menschen, die häufig mit großen Mengen Text zu tun haben.

Auch in einem Blog geht es in der Regel um Text, der Informationen transportiert. Es gibt zwar auch Blogs, in denen keine einzige Zeile Text zu finden ist (zum Beispiel werden die Bilder-Streams auf tumblr auch als Blogs bezeichnet), für mich hat ein Blog jedoch mit Schreiben, also mit Text zu tun. Auch die Konfiguration eines Blogs, das statisch generiert wird, wird in einer Textdatei abgelegt.

Warum muss man sich über die Verwaltung von Texten Gedanken machen?

Sicher haben viele schon einmal ein Textdokument bearbeitet und es ist dabei eine der folgenden Fragen aufgetaucht:

• Wie sah das Dokument vor einem Jahr aus?
• Wer hat alles an diesem Dokument gearbeitet und wann?
• Welche Unterschiede gibt es zwischen dem jetzigen Dokument und dem Stand von vor drei Monaten?
• Wer hat einen bestimmten Satz in das Dokument eingefügt?
• Wie erkenne ich unbeabsichtigte Änderungen, zum Beispiel durch Abrutschen mit der Maus? Wie kann ich solche Änderungen wieder korrigieren?
• Das Dokument soll überarbeitet werden, so dass Abschnitt 1 den Stand von letzter Woche bekommt und Abschnitt drei den Stand von letztem Monat. Wie mache ich das am besten?
• Ein Vertragspartner behauptet, dass in seinem Dokument etwas anderes steht als in dem Dokument, das Sie vorliegen haben. Wie prüfen Sie das?

Kommt Ihnen das bekannt vor?

Falls Sie mit Word oder einer anderen Textverarbeitung arbeiten müssen und diese Probleme zu lösen haben, gehört Ihnen mein Mitgefühl. Wie so oft hat Microsoft hier schon bestehende Lösungen ignoriert oder gar nicht wahrgenommen.

Für Programmierer, die unter dem Betriebssystem Unix gearbeitet haben, gab es schon lange Zeit vor der Erfindung von Word Markup-Sprachen, mit denen man Dokumente inhaltlich strukturieren und dann geeignet formatiert ausgeben konnte.
Es lag also nahe, diese Dokumente genau so zu verwalten, wie man das mit den Quelltexten der Programme konnte: über so genannte Sourcecode-Verwaltungssysteme.
Für Programmierer ist so ein System sehr wichtig, da man häufig die Historie eines Programms kennen muss um bestimmte Entscheidungen darin zu verstehen. Auch das Wiederherstellen eines älteren Zustands im Programm ist ab und zu nötig. Und man kann auch mehrere Versionen eines Programms gleichzeitig mit einem solchen System verwalten.
Software-Firmen haben oft sehr viele Versionen ihrer Programme zu pflegen, sei es wegen unterschiedlicher Betriebssysteme, verschiedener Märkte oder einfach, weil auch noch die Pflege der Vor-Vor-Vorgängerversion der aktuellen Software einem Kunden vertraglich zugesichert wurde.

Was leisten solche Sourcecode-Verwaltungssysteme?

• Verwaltung der Geschichte eines Dokuments
  Von der Entstehung eines Dokuments bis zum aktuellen Tag läßt sich jede Änderung nachvollziehen und beantwortet folgende Fragen:
  • Wer hat die Änderung durchgeführt?
  • Was wurde geändert?
  • Wann wurde geändert?
  • Es ist auch möglich, sich die Änderungen als (in der Regel farblich markierte) Übersicht anzeigen zu lassen. Dabei kann man frei wählen welche Versionen man miteinander vergleichen möchte.
• Verwaltung mehrerer Ausprägungen eines Dokuments
  Zum Beispiel kann man ein Dokument in einer Version für den internen Gebrauch und in einer externen Version gleichzeitig verwalten. Konkret dieses Problem läßt sich auch anders lösen, es ist aber ein gutes Beispiel.
• Sicherung der Integrität
  Wenn Sie Dokumente speichern und diese später wieder verwenden wollen, müssen Sie sicher sein können, dass dieses Dokument nicht durch absichtliche oder unabsichtliche Änderungen verfälscht wurde. Die Speicherung auf Festplatten und auch anderen Medien ist prinzipiell fehleranfällig - alle Speichermedien können Fehler aufweisen, auch solche die nicht erkannt werden.
  Das Sourcecode-Verwaltungssystem muss solche Fehler auf jeden Fall erkennen und im besten Fall sogar korrigieren können. Leider ist es so, dass diese Aufgabe nicht von allen Systemen gemeistert wird.
• Gleichzeitige Bearbeitung durch mehrere Personen
  Sobald zwei Personen oder mehr an den Dokumenten oder Programmen gemeinsam arbeiten kann es passieren, dass Änderungen an den gleichen Dokumenten vorgenommen werden. Natürlich kann es dabei auch zu Konflikten kommen, weil die gleichen Textstellen verschieden verändert wurden. Ein Sourcecode-Verwaltungssystem muss solche Konflikte erkennen können und Möglichkeiten zu deren Auflösung bieten. Die Konfliktlösung ist die schwierigste Aufgabe eines solchen Systems.
• Auswahl und Übertragung einzelner Änderungen zwischen Versionen
  Ein sehr häufiger Anwendungsfall in der Software-Entwicklung ist die Übertragung einzelner Änderungen von einer Version in eine andere. Die Systeme unterstützen so etwas unterschiedlich gut - bei der Pflege eines Blogs dürfte die Pflege verschiedener Versionen selten eine Rolle spielen, also auch diese Funktion.
• Sicherung der Konsistenz des Gesamt-Datenbestands
  Dokumente (oder Programmtexte) stehen nicht für sich allein - in der Regel sind Dokumente nur im Zusammenhang mit anderen Dokumenten sinnvoll.
  Zum Beispiel habe ich in die Teile 1 und 2 dieser Artikelserie schon Links auf den Teil 3 eingebaut - solange Teil 3 nicht auf dem Blog veröffentlicht ist, machen die Links keinen Sinn. Die Veröffentlichung von Teil 3 muss also gemeinsam mit der Änderung von Teil 1 und Teil 2 erfolgen. Bei der Software-Entwicklung sind diese Abhängigkeiten meistens noch größer und weiter verzweigt.

git: ein modernes Sourcecode-Verwaltungssystem

Aus der großen Menge verfügbarer Systeme habe ich mich für git entschieden - das System ist freie Software, es ist dezentral, d.h. ich kann auch ohne einen zentralen Server arbeiten, es bietet Integritäts- und Konsistenzsicherung und es gibt einige Provider, die kostenlos kleinere git-Projekte hosten, wenn man doch einen zentralen Server benutzen möchte. Es gibt sogar eine deutsche Dokumentation.

git ist sehr flexibel und mächtig - für die tägliche Arbeit empfiehlt es sich, sich einen Arbeitsablauf und eine Vorschrift zur Versionsverwaltung zu überlegen. Hierzu gibt es Zusatzprogramme für git, die so etwas anbieten - eine grafische Benutzeroberfläche inklusive.

Ich benutze seit vielen Jahren das Programm SmartGit der deutschen Firma Syntevo GmbH, das sehr komfortabel und leistungsfähig ist. Für nichtkommerzielle Nutzung ist es kostenlos einsetzbar.
Aber Achtung: die nichtkommerzielle Nutzung ist eng gefaßt! Gibt es irgendeinen kommerziellen Aspekt der Nutzung, sollte man sich eine Lizenz holen - die ist auch nicht sehr teuer.

Hier sehen Sie das Hauptfenster von Smartgit:

Links oben sind die verschiedenen Projekte (Repositories) aufgeführt, rechts daneben die Übersicht über geänderte Dateien innerhalb des aktuell ausgewählten Repositorys.

Darunter sieht man die Änderungen einer ausgewählten Datei gegenüber ihrer Vorgängerversion. Im unteren Bereich schliesslich sind der Geschichtsverlauf (Log) des Repositorys und das Ausgabefenster für die git-Kommandos zu sehen. Ganz links sind verschiedene Versionszweige des Repositorys aufgeführt.

Im folgenden Bild sieht man das Log eines Repositorys in etwas ausführlichererer Form - hier das Log des von mir verwendeten Hugo-Themas:

An der grafischen Darstellung der Entwicklungslinien kann man sehr schön sehen, dass hier drei Leute parallel gearbeitet haben (rote, blaue und grüne Linie) und dass ihre Änderungen wieder zusammengeführt wurden.

git-Hosting

Ich hatte geschrieben, dass git ohne zentralen Server funktioniert und diese Aussage ist auch uneingeschränkt gültig. Aus verschiedenen Gründen, zum Beispiel um ein Backup seiner Daten zu haben, ist es aber trotzdem oft sinnvoll, einen zentralen Server zu benutzen. Dieser wird nicht ständig gebraucht, sondern man kann entscheiden, wann man einen Abgleich mit diesem vornimmt.

Einsetzbar ist ein solcher Server als Backup-Möglichkeit oder auch als Knotenpunkt für den Austausch mit anderen Mitarbeitern oder Team-Mitgliedern.

Es gibt mindestens drei große Anbieter für git-Hosting - vermutlich noch mehr - die kostenloses Hosting für kleine oder private Projekte anbieten. Man kann natürlich auch seinen eigenen git-Server betreiben, aber für die meisten Anwendungsfälle ist das einfach nicht sinnvoll. So etwas macht man eher bei Projekten, bei denen die Inhalte nur vertrauenswürdigen Personen zugänglich sein sollen und kein Zugriff offen über das Internet erfolgen soll.

Ein Blog ist normalerweise per Definition öffentlich - man kann also im Normalfall sogar sein Repository für den Blog öffentlich machen.

Die drei großen Provider für git-Hosting sind:

• github.com
• BitBucket und
• GitLab

GitHub bietet kostenloses Hosting für OpenSource an - das heißt, die Repositories sind öffentlich. Bei Bitbucket kann man auch private Repositories kostenlos hosten - hier ist die Anzahl der teilnehmenden Entwickler/Mitarbeiter eingeschränkt.

Ich benutze Bitbucket für meine privaten Repositories.

SmartGit bietet Unterstützung für alle drei dieser Provider an - es ist also sehr einfach, das git-Hosting in SmartGit einzurichten.

Bitbucket bietet übrigens auch ein kostenloses Programm an, das ähnlich wie SmartGit arbeitet: SourceTree. Ich selbst habe es noch nicht ausprobiert - es unterstützt jedoch eine Besonderheit von Bitbucket - die Verwaltung großer Dateien (LFS - large file support). In der restlichen Funktion unterscheidet es sich vermutlich nicht sehr von SmartGit.
Update: Inzwischen habe ich SourceTree ausprobiert und festgestellt, dass es einige Schwierigkeiten mit der Verwaltung von git Sub-Modulen hat. Wenn man keine Submodule einsetzt, ist das allerdings kein Problem.

Ein weiteres kostenloses Programm ist der GitHub Desktop. Das Programm habe ich nur kurz angetestet und es sieht recht brauchbar aus.

Welches Programm man benutzt ist letztendlich Geschmackssache. Man kann auch ganz auf eine grafische Oberfläche für git verzichten - alle Arbeiten sind auch in der Kommandozeile durchführbar (und manchmal nur da).

Hosting meines Blogs

Warum heisst diese Artikelserie eigentlich JamStack?

Vielleicht ist Ihnen der Begriff LAMP geläufig - dieser bezeichnet ein Hosting-System bestehend aus Linux, Apache, MySQL und PHP. Linux ist das Betriebssystem, Apache ist der Webserver, MySQL ist die Datenbank und PHP ist die Programmiersprache, in der viele Web-Anwendungen verfaßt sind. Die Zusammensetzung solcher Komponenten bezeichnet man in der IT-Branche als Stack (Stapel).

Inzwischen ist LAMP in die Jahre gekommen und für viele Anwendungen einfach nicht mehr zeitgemäß. Eine der Antworten darauf ist JamStack - die Nutzung von Javascript im Browser, APIs, die irgendwo im Internet angeboten werden und schon aufbereitetem Markup.

Mit Hugo (siehe letzter Artikel) hat man ein gutes Werkzeug, um ein entsprechendes System aufzubauen.

Die Generierung des HTML aus der Markup-Sprache (in meinem Fall Markdown) erledigt Hugo. Die generierten HTML-Dateien müssen dann auf irgendeinen Webserver geladen werden, um im Internet abrufbar zu sein.

Mein Web-Provider bietet natürlich auch das Hosting statischer Webseiten an. Man kann also bei Änderungen der Webseite bzw. des Blogs die Generierung mit Hugo durchführen und dann die HTML-Dateien zum Hoster hochladen.

Das hat einige Probleme:

• Das Hochladen kann relativ lange dauern. Falls man dabei die Dateien auf dem Webserver überschreibt, ist es denkbar dass dabei zum Benutzer eine inkonsistente Webseite ausgeliefert wird. Einige Seiten haben schon den neuen Stand, andere Seiten sind noch auf dem alten Stand.
• Selbst, wenn man das vorherige Problem in den Griff bekommt (was auch nicht schwer ist), hat man unter Umständen noch das Caching-Problem, das im letzten Artikel beschrieben wurde. Bei Benutzung von Caches muß man dafür sorgen, dass auch diese das Vorhandensein neuer oder geänderter Seiten mitbekommen müssen. Alles das ist unter Umständen kompliziert und aufwändig.

Diese Probleme haben einige Anbieter erkannt und bieten Rundum-Lösungen an, die die gesamte Infrastruktur und die passenden Prozesse realisieren.

Ein sehr guter Anbieter in diesem Bereich ist Netlify. Netlify übernimmt alles, was nach einer Änderung in den Quelltexten notwendig ist. Unter diesen Leistungen sind:

• Übernahme von Änderungen aus einem Sourcecode-Verwaltungssystem
• Generierung der HTML-Seiten
• Hochladen der HTML-Seiten zum Webserver
• Betrieb der Webserver
• Bereitstellung eines CDN (Content Delivery Network) - ein System, das die Inhalte näher zum Kunden bringt, um die Geschwindigkeit zu steigern und Kosten zu senken
• Bereitstellung von Webserver-Zertifikaten für TSL (https)
• Aktivierung einer neuen Version einer Webseite gleichzeitig(!) auf allen beteiligten Webservern und Caches
• Problemloses Zurückschalten auf einen älteren Stand des Blogs oder der Webseite falls das einmal nötig ist
• Programmierbare API
• Lambda-Funktionen
• Passwortschutz
• einstellbare HTML-Header
• DNS-Service in Zusammenarbeit mit einem großen DNS-Provider (ns1.com)

Alles das erhält man sogar kostenfrei, wenn man einen niedrigeren Service-Level wählt und keine Team-Funktionen benötigt.

Die Arbeitsweise für mich sieht so aus:

1. Ich ändere meinen Blog und prüfe die Änderungen über den eingebauten Webserver in Hugo.
2. Bin ich zufrieden, speichere ich die Änderungen in meinem lokalen git-Repository.
3. Ich synchronisiere mein git-repository mit demjenigen, das ich bei Bitbucket angelegt habe.
4. Netlify übernimmt den Rest!
   Netlify überträgt die Änderungen aus dem Bitbucket-Repository in sein System, generiert mit Hugo die statischen HTML-Seiten, verteilt diese in seinem weiltweiten CDN und aktiviert die neue Version überall zum gleichen Zeitpunkt.

Nach dem Schreiben reduziert sich die Arbeit für mich also auf einen einzigen Knopfdruck. Genial!

Zudem ist Netlify durchaus schnell und es ist jederzeit möglich, seine Webseite wieder auf einen eigenen Server zu packen. Man geht keinerlei Risiko ein.

Zusammenfassung und Ausblick

Das Zusammenspiel von Hugo, git und Bitbucket sowie Netlify bietet eine einfache, sichere und leistungsfähige Plattform, um einen Blog zu betreiben.
Wenn man sich einmal für die Benutzung statischer Webseiten entscheidet, sollte man sich die bekannten Webseitengeneratoren einmal ansehen und sich auf jeden Fall mit Providern wie z.B. Netlify befassen.