Nowy silnik bloga po disasterze
Mój blog zdążył zniknąć z sieci, po tym jak OVH wskutek ich błędu usunęło mój serwer fizyczny. Powodem usunięcia serwera był brak powiadomienia o wyłączeniu usługi, które zawsze przychodzi, i od którego jest 7 dni na uregulowanie płatności i przywrócenie maszyny. Reklamacja została oczywiście odrzucona, a kopii danych nie było.
Ludzie dzielą się na tych, którzy robią backupy i na tych, którzy dopiero zaczną je robić
Robienie backupów nie jest procesem trywialnym. Jest kosztowny, wymaga infrastruktury, zaplanowania, i opracowania procedur odzyskiwania danych.
A co by było, gdyby… nie trzeba było robić backupu, a mimo tego istniałaby kopia zapasowa, a disaster recovery trwał nawet kilka minut?
Definicja problemu
Kod źródłowy CMS-a (bloga, strony firmowej, itp) przechowywane jest zazwyczaj w jakimś sytemie kontroli wersji, a przynajmniej taka powinna być praktyka. Zazwyczaj przechowywany jest też szablon i wszystkie statyczne assety. Te elementy są poddane kontroli wersji i w pewien sposób zabezpieczone kopią repozytorium na jakimś serwerze, np. usłudze GitHub albo GitLab .
Jednak treści wprowadzane do systemu CMS , czyli wszystkie tworzone przez edytorów w zespołach redakcyjnych, lub nawet przez indywidualnych twórców takich jak ja, czyli wszystkie elementy dynamiczne, przechowywane są w bazie danych, a wgrywane pliki multimedialne - na dyskach serwera a w najlepszym razie na jakimś cloudowym CDN-ie .
Trzeba zatem zauważyć, że najważniejsze i najcenniejsze informacje nie są w ogóle zabezpieczone przed utratą. A zabezpieczeń zazwyczaj się nie robi ze względu na skomplikowanie i kosztowność procesu, oraz… dlatego że ludzie dzielą się także na tych, którzy backupy dopiero zaczną robić :)
GIT
GIT jest względnie prostym systemem kontroli wersji. To podstawowe narzędzie programisty. Jego konstrukcja opiera się o dwa istotne elementy: diff/patch oraz klonowanie repozytoriów.
A gdyby całą tworzoną treść, tę dynamiczną i najcenniejszą, przechowywać nie w relacyjnej bazie danych a w repozytorium GIT , i zarazem “za darmo” mieć kontrolę wersji?
To jest możliwe, i na dodatek bardzo wygodne. Można potraktować GIT-a jako bazę danych (dane są wtedy zwykłymi plikami), która OOTB dostarcza mechanizm wersjonowania, i z tych danych generować docelową stronę internetową podobnie jak robią to serwery aplikacji w przypadku dynamicznych stron internetowych. Różnica polega tylko na tym, że generowanie jest robione raz - przy wdrożeniu, ze źródeł i danych zapisanych w repozytorium.
Hugo
Na Jamstack-u znajduje się obecnie informacja o ponad 300 generatorach statycznej treści. Zaryzykowałbym że jest ich więcej niż klasycznych systemów CMS. Z tej listy wybrałem kilka obiecujących rozwiązań (11ty , Pelican , Hugo ), a ostatecznie zdecydowałem się na Hugo zaprogramowanym w Go .
Jest bardzo szybki generator stron statycznych z bogatymi możliwościami konfiguracyjnymi, bazą wielu dodatków i dokumentacją. Po jednym dniu zapoznawania się można z nim wydajnie pracować. Czas napisania posta jest teraz równy czasowi myślenia i samego maszynopisania, ewentualnej korekty, a otoczka związana z uzupełnianiem treści obrazkami czy metainformacjami zabiera nie więcej niż pięć minut. Autozapis jest w edytorze tekstu, a kopia zapasowa robi się niemal automatycznie z każdym commitem. Możliwość tworzenia gałęzi jest tu dodatkowym atutem, jeśli tylko istnieje potrzeba współpracy w szerszym gronie.
Deployment strony sprowadza się do zrobienia builda i wgrania plików na
serwer, co mam zapakowane w targety w Makefile:
upgrade:
hugo && rsync -avz --delete public/ username@hostname:~/path/to/www/data/
runserver:
hugo serve --disableFastRender --ignoreCache
Podsumowanie
Od dziś Hugo “napędza” tego bloga, a mnie samego do pisania. Teraz mogę skupić się przede wszystkim na tworzeniu treści, która jest już zabezpieczona praktycznie w każdym momencie procesu twórczego.
GIT wraz z Hugo stały się narzędziami rozwiązującymi wiele moich problemów związanych z prowadzeniem bloga. Nie poznałbym ich nie mając incydentu z OVH , który zmusił mnie do poszukania alternatywy oszczędzającej czas i zapewniającej zabezpieczenie przed utratą danych.
To rozwiązanie jest z dziedziny Headless CMS . Istnieją bardzo ciekawe frontendy do takich CMS-ów, którym będę się przyglądał w najbliższym czasie, i pewnie coś na ich temat napiszę.