Cloud, Docker i DevOps — szybkie i niezawodne wdrożenia
Wszystkie aplikacje umieszczamy w kontenerach Dockera, orkiestrujemy je za pomocą Docker Compose (albo Kubernetesa w projektach korporacyjnych), konfigurujemy Caddy jako reverse proxy z automatycznym SSL i automatyzujemy cały cykl wdrożenia przez GitHub Actions — od commita do produkcji.
Konteneryzacja z Dockerem i Docker Compose
Każda usługa ma własny wieloetapowy Dockerfile: etap budowania, który instaluje zależności i kompiluje, oraz minimalny etap końcowy (distroless albo alpine) zawierający wyłącznie potrzebne artefakty. Typowy obraz Next.js mieści się poniżej 150 MB, obraz FastAPI poniżej 80 MB. Obrazy są przebudowywane przy każdym scaleniu do gałęzi main i tagowane semantycznie (`v1.2.3` oraz `latest`).
Docker Compose opisuje cały stos: frontend, API, bazę danych, Redisa i workera. Wrażliwe zmienne (hasło do bazy, klucze API, sekret Stripe'a) trzymamy w pliku `.env` wykluczonym z gita — nigdy na sztywno w obrazie. Health checki w Compose gwarantują, że zależności są gotowe przed startem (baza gotowa → startuje API → startuje frontend).
- Cache budowania z `--mount=type=cache` — przyspiesza `npm ci` na CI
- Zoptymalizowana kolejność warstw: najpierw stabilne zależności, potem kod źródłowy
- Zarządzanie sekretami przez Docker secrets albo HashiCorp Vault w projektach korporacyjnych
- `restart: unless-stopped` i `docker compose up --no-deps` dla atomowego wdrożenia
Caddy — nowoczesny reverse proxy z automatycznym SSL
Caddy 2.8 obsługuje SSL/TLS automatycznie przez ACME (Let's Encrypt albo ZeroSSL) — żadnego wygasłego certyfikatu, żadnej ręcznej konfiguracji. HTTP/2 i HTTP/3 (QUIC) są włączone domyślnie. Nagłówki bezpieczeństwa (HSTS, X-Frame-Options, CSP) ustawiamy globalnie w wielokrotnie używanych snippetach. Deklaratywną konfigurację Caddyfile można porównywać poleceniem diff i wersjonować w gicie.
Ograniczanie liczby żądań, kompresję gzip/brotli i ustrukturyzowane logowanie w JSON włączamy natywnymi dyrektywami Caddy'ego — bez modułów Nginxa i bez rozbudowanej konfiguracji Apache'a. Dostęp do wrażliwych ścieżek (`/admin`, `.env`, `.git`) zwraca kod 444 (brak odpowiedzi), ustawiony w globalnym snippecie bezpieczeństwa.
- Ocena A+ w SSL Labs od pierwszego dnia — wyłącznie TLS 1.3 z nowoczesnymi zestawami szyfrów
- TLS na żądanie dla wielodostępnych SaaS-ów z dynamicznymi subdomenami
- Przeładowanie konfiguracji — `caddy reload` nie zrywa aktywnych połączeń
- Logi Caddy'ego → Loki → Grafana — analiza ruchu i alerty o anomaliach
CI/CD w GitHub Actions i monitoring
Pipeline CI uruchamia się przy każdym PR: lint, kontrola typów, testy jednostkowe, budowa obrazu Dockera i skanowanie podatności (Trivy). Jeśli wszystko przejdzie, obraz trafia do rejestru, a wdrożenie na staging odbywa się automatycznie. Scalenie do gałęzi main oznacza automatyczne wdrożenie na produkcję z health checkiem po wdrożeniu. Jeżeli health check nie powiedzie się w ciągu 60 sekund, następuje automatyczne wycofanie zmian.
Monitorujemy przez Grafanę i Prometheusa metryki aplikacji (opóźnienie, odsetek błędów, długość kolejki), a przez Loki agregujemy logi. Alerty konfigurujemy na Slacku lub w poczcie: odsetek błędów powyżej 1%, opóźnienie P95 powyżej 500 ms, zajętość dysku powyżej 85%. Zewnętrzny monitoring dostępności prowadzi Better Uptime — publiczny panel SLA udostępniamy na życzenie.
- Skanowanie podatności obrazów przez Trivy — krytyczne CVE blokują wdrożenie
- Dependabot z automatycznym scalaniem aktualizacji poprawkowych (wymagana zielona CI)
- Automatyczna kopia zapasowa bazy danych w magazynie zgodnym z S3 (nocna, przechowywana 30 dni)
Zalety i ograniczenia
Zalety
- Wdrożenie z automatycznym wycofaniem po nieudanym health checku.
- Automatyczne SSL/TLS dzięki Caddy'emu — żaden certyfikat nie wygaśnie przez zaniedbanie.
- Odtwarzalne środowisko: ten sam obraz Dockera na deweloperce, stagingu i produkcji.
- Monitoring i alerty (Grafana, Loki) — problemy widać wcześniej niż użytkownicy.
Ograniczenia
- Docker Compose nie skaluje się jak Kubernetes przy korporacyjnych instalacjach wielowęzłowych.
- Początkowa konfiguracja CI/CD wymaga czasu i doświadczenia DevOps.
- Obrazy i logi zajmują miejsce na dysku — trzeba je okresowo czyścić.
- Pełny monitoring (Prometheus i Grafana) dokłada kolejne usługi do utrzymania.
Krótki werdykt
Docker, Caddy i GitHub Actions to idealne połączenie do niezawodnych wdrożeń na VPS-ie lub kilku węzłach. Przy dziesiątkach węzłów i agresywnym autoskalowaniu przejdź na Kubernetesa.
Tabela specyfikacji
| Możliwość | Limit / próg | Typowe zastosowanie | |
|---|---|---|---|
| Orkiestracja | Docker Compose, pełny stos | Pojedynczy węzeł; przy wielu potrzebny Swarm lub K8s | VPS, projekty małe i średnie |
| Reverse proxy | Caddy 2.8, HTTP/3, automatyczne SSL | Bardzo złożone reguły wymagają rozbudowanej konfiguracji | Wiele domen, wielu najemców |
| CI/CD | GitHub Actions, automatyczne wdrożenie od commita | Minuty CI są płatne powyżej darmowego planu | Automatycznie od commita do produkcji |
| Typowy koszt | VPS od około 5 €/miesiąc | Monitoring i kopie zapasowe podnoszą koszt | Od pojedynczej strony po wiele marek |
Docker Compose a Kubernetes
| Kryterium | Docker Compose | Kubernetes |
|---|---|---|
| Złożoność konfiguracji | Niska | Wysoka |
| Skalowanie wielowęzłowe i autoskalowanie | Ograniczone (jeden węzeł) | Znakomite |
| Odpowiedni dla | VPS, projekty małe i średnie | Duże środowiska, zastosowania korporacyjne |
Najczęstsze pytania
Dlaczego Caddy, a nie Nginx?
Caddy obsługuje SSL/TLS automatycznie przez ACME, domyślnie włącza HTTP/2 i HTTP/3 oraz ma krótką, deklaratywną konfigurację. Nginx wymaga certbota i znacznie więcej ręcznej pracy, by osiągnąć ten sam efekt.
Czy potrzebuję Kubernetesa?
W przypadku większości stron nie. Docker Compose na VPS-ie niezawodnie obsługuje jedną witrynę albo kilka usług. Kubernetes zaczyna się opłacać dopiero przy dziesiątkach węzłów i agresywnym autoskalowaniu.
Jak przebiega wdrożenie nowej wersji?
GitHub Actions buduje nowy obraz, uruchamia go obok starego, wykonuje health check, a następnie przełącza ruch. Jeśli health check nie powiedzie się w ciągu 60 sekund, system automatycznie wraca do poprzedniej wersji.
Jaki monitoring polecacie?
Grafanę i Prometheusa do metryk (opóźnienie, odsetek błędów) oraz Loki do zagregowanych logów, z alertami na Slacku lub w poczcie. Do zewnętrznego badania dostępności dokładamy niezależną usługę, na przykład Better Uptime.