Chciałem blog, w którym mogę powiedzieć “opublikuj to” i odejść. Żadnego logowania do CMS, żadnych manualnych deployów, żadnych edytorów drag-and-drop. Tylko rozmowa, git push i działający URL.

Tak to działa.

Stack

Hugo generuje statyczne HTML z plików markdown. Kontener nginx serwuje wynik. Całość chodzi na małej płytce ARM z 8 GB RAM, która hostuje też kilkanaście innych usług. Nie do końca infrastruktura enterprise, ale jeszcze nie padła.

Motyw to PaperMod. Czysty, szybki, minimalny.

Dockerfile jest banalnie prosty:

1
2
3
4
5
6
7
8

FROM hugomods/hugo:reg-0.154.5 AS builder
WORKDIR /src
COPY . .
RUN hugo --gc --minify

FROM nginx:alpine
COPY --from=builder /src/public /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf

Pisanie postów

Piszę posty w markdownie, zwykle zaczynając od notatek robionych w trakcie pracy. Asystent AI pomaga przy drafowaniu i edycji, ale ja decyduję co zostaje a co leci. Tooling ogarnia nudne rzeczy: frontmatter, generowanie sluga, okładkę, umieszczenie pliku.

Każdy post przechodzi przez zestaw reguł pisania, które usuwają typowe znaki tekstu wspomaganego przez AI. Żadnego “delving into” czegokolwiek. Żadnych em dash co drugie zdanie. Żadnych wymuszonych grup po trzy. AI pomaga mi pisać szybciej, ale głos jest mój.

Okładki

Każdy post dostaje okładkę wygenerowaną przez model obrazkowy Gemini. Ale surowe prompty dają generyczne obrazki. Więc przed generowaniem prompt przechodzi przez enhancer, który zamienia “okładka bloga o Dockerze” w szczegółowy art direction z konkretnym oświetleniem, kompozycją i referencjami stylu.

Generowanie działa jako zadanie w tle z logiką ponawiania prób. Jeśli API się zacina, próbuje ponownie. Jeśli padnie dwa razy, post publikuje się bez okładki.

Pipeline deployu

Kiedy pushuję na główny branch ze zmianami w katalogu blog/, odpala się workflow GitHub Actions. Chodzi na self-hosted runnerze siedzącym na tej samej płytce ARM:

  1. Checkout repo
  2. Build obrazu Docker (Hugo kompiluje stronę, nginx ją serwuje)
  3. Restart kontenera
  4. Health check endpoint

Workflow GitHub Actions wygląda tak:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

name: Deploy Blog

on:
  push:
    branches: [master]
    paths:
      - "blog/**"

jobs:
  deploy:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: true
      - name: Build and deploy
        working-directory: blog
        run: docker compose up -d --build --force-recreate
      - name: Health check
        run: |
          sleep 5
          curl -sf http://localhost:8090/ || exit 1

Całość zajmuje poniżej dwóch minut. Większość tego to Docker build layer cache robiący swoje.

Cotygodniowe newsy

Osobna automatyzacja przeszukuje co tydzień AI newsy za pomocą API wyszukiwarek. Zbiera wyniki z kilku tematów: agenty kodujące, prompt engineering, bezpieczeństwo, wzorce orkiestracji. Najlepsze znaleziska są streszczane w krótki post-digest i publikowane automatycznie.

Streszczenie też przechodzi przez te same reguły pisania. Automatyczne nie musi znaczyć robotyczne.

Co dalej

Będę pisał o czymkolwiek, co wydaje mi się ciekawe pracując nad infrastrukturą i automatyzacją. Spodziewajcie się postów o self-hostowanych usługach na małym sprzęcie, debugowaniu systemów produkcyjnych i okazjonalnym rant o formatach konfiguracji.

Taski automatyzujące bloga działają na Trigger.dev, self-hostowanym na tej samej płytce ARM. Jeśli ciekawi cię, ile to kosztuje w RAM i co trzeba zrobić, żeby to trzymać przy życiu, jest osobny wpis o self-hostowaniu Trigger.dev na ARM64.

Jeśli coś się spektakularnie popsuje, to też jest content.