VPS pod Dockera: dobór serwera i bezpieczna konfiguracja

Ile RAM potrzebuje VPS pod Dockera

Sam Docker jest lekki – pamięć zjadają kontenery, które uruchamiasz. Dlatego licz RAM według swojego stosu, a nie według liczby kontenerów. Baza danych i aplikacje w Javie lub z przeglądarką (np. Playwright) potrafią zająć więcej niż wszystkie pozostałe usługi razem.

Zostaw zapas na system i na moment aktualizacji: budowanie obrazu albo restart kilku kontenerów naraz chwilowo podbija zużycie pamięci. Na Linuksie warto też dodać plik swap jako bufor bezpieczeństwa – nie zastąpi RAM, ale uchroni przed nagłym zabiciem procesu.

• 1–2 GB RAM: jedna lekka aplikacja, reverse proxy, VPN lub bot
• 4 GB RAM: typowy stos – WordPress lub n8n z bazą danych, reverse proxy i kilka narzędzi
• 8 GB RAM i więcej: sklep, większe bazy danych, wiele projektów na jednym serwerze

Instalacja Docker Engine i Docker Compose

Wybierz świeży VPS z aktualnym Ubuntu lub Debianem. Instaluj Dockera z oficjalnego repozytorium Dockera, a nie z przestarzałych pakietów dystrybucji – dokumentacja Dockera ma gotową instrukcję dla każdego systemu. Docker Compose jest dziś wtyczką (polecenie „docker compose”), instalowaną razem z silnikiem.

• Zaktualizuj system i utwórz zwykłego użytkownika z sudo; logowanie po SSH tylko kluczem
• Dodaj oficjalne repozytorium Dockera i zainstaluj docker-ce oraz docker-compose-plugin
• Każdy projekt trzymaj w osobnym katalogu z plikiem compose.yaml
• Uruchamiaj usługi poleceniem „docker compose up -d” i ustaw restart: unless-stopped

Reverse proxy: Caddy albo Traefik

Nie wystawiaj każdego kontenera na osobnym porcie. Postaw jeden reverse proxy na portach 80 i 443, który przyjmuje ruch dla Twoich domen i przekazuje go do właściwych kontenerów w wewnętrznej sieci Dockera. Przy okazji automatycznie załatwi darmowe certyfikaty HTTPS z Let’s Encrypt.

Caddy jest najprostszy na start: kilka linijek w pliku Caddyfile i strona działa po HTTPS. Traefik lepiej sprawdza się przy wielu projektach, bo konfigurujesz go etykietami bezpośrednio w pliku compose. Oba są dobrym wyborem – wybierz jeden i trzymaj się go.

Wolumeny i kopie zapasowe

Kontener jest jednorazowy – dane nie. Wszystko, co ma przetrwać aktualizację obrazu, trzymaj w wolumenach Dockera albo w katalogach zamontowanych z serwera. Bez tego zaktualizujesz bazę danych i obudzisz się z pustą tabelą.

Kopie rób poza serwerem: zrzut bazy danych (np. pg_dump, mysqldump) plus archiwum wolumenów, wysyłane automatycznie do zewnętrznego magazynu. Snapshot u dostawcy to dobry dodatek, ale nie jedyna kopia – jeśli stracisz dostęp do konta, stracisz też snapshoty. I raz na jakiś czas sprawdź, czy z kopii da się coś odtworzyć.

Bezpieczeństwo: nie wystawiaj gniazda Dockera

Gniazdo Dockera (/var/run/docker.sock) daje pełną kontrolę nad serwerem. Nie montuj go do kontenerów, którym nie ufasz, i nigdy nie wystawiaj API Dockera na port w internecie. Jeśli narzędzie, np. panel do zarządzania kontenerami, wymaga dostępu do gniazda, ogranicz je proxy tylko do odczytu albo trzymaj panel za VPN.

Pamiętaj też, że porty opublikowane przez Dockera potrafią ominąć reguły zapory UFW. Publikuj na zewnątrz tylko reverse proxy, a bazy danych i usługi wewnętrzne zostaw w sieci Dockera albo przypisz do adresu 127.0.0.1. Dostawców z planami, które dobrze nadają się pod Dockera, pokazujemy w tabeli poniżej.

Aktualizacje obrazów bez niespodzianek

Przypinaj konkretne wersje obrazów zamiast tagu „latest”, zwłaszcza przy bazach danych – przeskok o wersję główną potrafi wymagać migracji danych. Aktualizuj świadomie: najpierw kopia, potem „docker compose pull” i „docker compose up -d”, a na koniec sprawdzenie logów. Co jakiś czas usuwaj nieużywane obrazy poleceniem „docker image prune”, bo potrafią zapełnić dysk.