Blog 2.0 i migracja: Azure, .NET, Architecture

A więc stało się podążyłem za trendem #nowordpress i przeniosłem się ze swoim blog na static site generator. W tym post chciałbym opisać cały proces migracji, wybrany stos technologiczny oraz dlaczego zaczałem całą migrację mojego blog-a do nowej platformy.

Dlaczego to zrobiłem

Głównymi powodami była:

chęć odświeżenia blog-a
chciałem zająć się tylko pisaniem z wyłączeniem części związanej z zarządzaniem blogiem, serwerem i innymi rzeczami
redukcja kosztów hostingu
cheć skupienia wszystkich rzeczy u jednego dostawcy
nauka Azure i Azure DevOps
chęć poznania trendu static sites generators

To jest lista powodów jakimi się kierowałem przy całym procesie migracji, oraz były to zapalniki całego przedsięwzięcia.

Stare rozwiązanie

Poprzednie rozwiązanie było postawione na WordPress natomiast hosting został powierzony zenbox.pl z którego byłem bardzo zadowolony przez cały okres używania.

Najbardziej bolesną częścią rozwiązania był sam WordPress z milionem pluginów, oraz aktualizacje samej platform i pluginów.

The Plan

Plan migracji był prosty:

znaleźć platformę która będzie mi odpowiadać
wybór nowej platformy
eksport całej treści ze starej platformy
edycja postów
przepięcie wszystkich usług dookoła (Buffer, Mailchimp)
new and shiny blog

Po długich poszukiwaniach i próbach z Wyam, oraz Hugo wybór padł na tego ostatniego który jest stworzony w Go. Co ciekawe jest to język który bardzo mnie interesuje hobbistycznie i zawodowo.

Wyam był ciekawym rozwiązaniem stworzonym w .NET z którym jestem związany od lat ale niestety jego rozwój się zatrzymał na rzecz nowego rozwiązania Statiq dlatego też wybór finalnie padł na sprawdzoną platformę jaką jest Hugo.

Cloud & DevOps

W związku z moimi zainteresowaniami chmurą Azure wybór był dość oczywisty jak również uznałem, że koszty zbudowania infrastruktury nie będą porażające (póki co ta teza się sprawdza). Zawdzięczam to głównie wykorzystaniu Blob Storage i jego możliwości hostowanai statycznych treści. Kolejnymi elementami rozwiązania są:

Azure CDN

Dlaczego wybrałem Azure CDN vs Cloudflare tutaj odpowiedź jest prosta chciałem utrzymać całą infrastrukturę w jednym miejscu. Z Cloudflare byłem zadowolony gdy miałem blog postawiony na WordPress i nie wykluczam, że w przyszłości ten element rozwiązania może ulec zmianie. Szczególnie kuszącymi w Cloudflare są elementy związane z ich CDN na cały świecie, oraz inteligentą siecą która może znacząco przyśpieszyć działanie strony.

Azure Pipelines

Ten element miał na celu zbudowanie w pełni automatycznego środowiska do budowania i publikacji treści. Dodatkowo stanowi dla mnie poligon doświadczalny do testowania nowych koncepcji np. Static Web Apps (Preview).

Jak się okazało budowanie blog-a opartego o Hugo jest bardzo prostą operacją do wykonania na agencie macOS-latest oraz wykonanie dalszych kroków w procesie publikacji.

Dodatkowy plus to trzymanie całej konfiguracji w yaml jako element repozytorium. Poniżej pipeline jaki zastosowałem dla swojego rozwiązania.

trigger:
- master

pool:
  vmImage: 'macos-latest'

steps:
- script: brew install hugo
  displayName: Install Hugo

- script: hugo
  displayName: Build site

- script: |
    azcopy login --service-principal --application-id $(AppId) --tenant-id $(TenantId)
    azcopy rm '$(StoragePath)' --recursive
    azcopy cp 'public/*' '$(StoragePath)' --recursive
  displayName: Upload files

- task: AzureCLI@2
  displayName: Purge cache
  inputs:
    azureSubscription: '$(Subscription)'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      #purge everything
            az cdn endpoint purge -g $(ResourceGroup) --profile-name $(CDNProfile) -n $(CDNName) --content-paths "/*"

Migracja

Pierwszym krokiem do migracji był eksport wszystkich treści z blog-a opartego o WordPress do tego celu użyłem Jekyll Exporter. Dzięki temu narzędziu uzyskałem treści w postaci plików Markdown.

Tutaj pojawiły się pierwsze problem, a mianowicie manualna edycja wyeksportowanych treści. Niestety jak to bywa z narzędziami automatycznymi wiele elementów w plikach, grafika wymaga zmiany i ręcznej modyfikacji.

Również zaskoczyły mnie problemy z konwersją tabel HTML do formatu wspieranego przez Markdown.

Kolejnym elementem który wymagał ręcznej modyfikacji było przepięcie komentarzy Disqus ze względu na zmianę sposobu generacji URL na nowej platformie.

Co zostało jeszcze do zrobienia

Dokończenie migracji post-ów, oraz zbudowanie jakiegoś rozwiązania do integracji z Buffer oraz Mailchimp. Koncepcyjnie myślę nad integracją za pomocą Azure Functions lub Logic Apps.

Podsumowanie

W ramach podsumowania wybór Hugo był dobrym kierunkiem i pod kątem kosztów również odczuwam znazną poprawę.

Poprzednia platforma w skali roku kosztowałą ok. 300 PLN obecnie koszt miesięczny nowego rozwiązania to ~€0.05 i jest to opłata za Azure Storage.

Również koncepcja Static Site Generators jest bardzo fajnym podejściem i już myślę nad jej wykorzystaniem w projektach opartych o .NET Core.

Photo by Simon Rae on Unsplash