Dlaczego nie buduję obrazów Dockera na serwerze

Kuszące jest zrobić git pull && docker build prosto na serwerze. Jeden krok, żadnego rejestru, wszystko na miejscu. Robiłem tak przez pierwsze kilka miesięcy i za każdym razem żałowałem. Oto trzy powody, dla których budowanie przeniosłem w całości do CI.

1. Mały VPS nie jest maszyną do budowania

Mój serwer ma tyle RAM-u, ile potrzeba do uruchomienia aplikacji, a nie do jej kompilacji. Pierwszy poważny npm ci plus bundling frontu skończył się zabiciem procesu przez OOM-killera. Build, który w Actions trwa dwie minuty, na VPS-ie potrafił się ciągnąć kwadrans albo w ogóle nie kończyć.

Serwer produkcyjny ma jedno zadanie: obsługiwać ruch. Każda inna robota to ryzyko, że w trakcie padnie to, za co naprawdę odpowiada.

2. Build na produkcji to build bez izolacji

Kiedy kompiluję na tej samej maszynie, na której działają inne kontenery, konkuruję z nimi o CPU i pamięć. W praktyce oznaczało to, że deploy jednej strony spowalniał wszystkie pozostałe. GitHub Actions daje mi czystą, jednorazową maszynę — buduje, wypycha i znika.

3. Powtarzalność i cache

W CI mam ten sam obraz bazowy, ten sam lockfile i cache warstw między buildami. Lokalnie na serwerze cache puchł, zapełniał dysk i regularnie musiałem robić docker system prune. Teraz serwer widzi wyłącznie gotowy artefakt.

# cała rola serwera sprowadza się do:
docker pull ghcr.io/janolek83/app:latest
docker up -d   # i tyle — bez kompilacji

Wyjątek od reguły

Jest jeden przypadek, gdy buduję lokalnie: szybki eksperyment na własnym laptopie, którego nigdzie nie wystawiam. Ale wszystko, co ma dotknąć produkcji, przechodzi przez pipeline. Bez wyjątków — bo to właśnie „tylko ten jeden raz na szybko” kończy się awarią.

Sam pipeline opisałem krok po kroku we wpisie o deployu w 15 minut. Ta sama zasada — nic ważnego nie wykonuje się z prywatnej maszyny — dotyczy też infrastruktury opisanej deklaratywnie: przy Terraformie i Terrakube stosuję dokładnie to samo podejście do plan/apply.