Uruchamianie Dockera w środowisku produkcyjnym

1. Wprowadzenie

Docker jest niezwykle popularny nie tylko w środowiskach deweloperskich, ale również w produkcji — dzięki swojej przenośności, prostocie wdrażania i łatwości skalowania. Jednak między środowiskiem developerskim (dev) a produkcyjnym (prod) istnieją istotne różnice w konfiguracji, bezpieczeństwie i zarządzaniu kontenerami.

W tej lekcji poznasz:

  • różnice między środowiskiem deweloperskim a produkcyjnym,
  • sposób przygotowania pliku docker-compose.yml do wdrożenia,
  • przykłady uruchomienia aplikacji Dockerowej na serwerze VPS lub w chmurze (DigitalOcean, AWS, Render).

2. Różnice między środowiskiem DEV a PROD

Środowisko developerskie służy do tworzenia, testowania i modyfikowania kodu, natomiast produkcyjne — do stabilnego i wydajnego uruchamiania aplikacji dla użytkowników.

2.1 Główne różnice

Element DEV (development) PROD (production)
Cel Szybki rozwój i testowanie Stabilność, wydajność, bezpieczeństwo
Docker Compose prosty, z zamontowanym kodem (volumes: .:/app) zoptymalizowany, zbudowany obraz z Dockerfile
Tryb uruchomienia docker-compose up docker-compose up -d (w tle)
Obrazy latest, lokalne buildy wersjonowane (myapp:1.0.0)
Logi interaktywne w konsoli zapisywane do plików lub systemów logowania
Zmienne środowiskowe .env.dev (lokalne) .env.prod (z sekretami, hasłami, kluczami API)
Bezpieczeństwo często pomijane kluczowe: nie-root user, aktualizacje, HTTPS
Skalowanie pojedyncze kontenery wieloserwisowe, często z load balancerem
Sieci / porty dostępne publicznie ograniczone do wewnętrznych sieci Dockera

2.2 Przykład: różne pliki Compose

docker-compose.dev.yml

docker-compose.prod.yml

W produkcji nie montujemy kodu z lokalnego katalogu, tylko korzystamy z gotowych, przetestowanych obrazów.

3. Konfiguracja Docker Compose dla serwera (VPS / chmura)

3.1 Przygotowanie serwera

Na serwerze produkcyjnym (np. Ubuntu 22.04) należy:

  • Zainstalować Dockera i Compose:
  • Utworzyć użytkownika Docker:
  • Upewnić się, że demon Dockera działa:

  • Skopiować pliki projektu na serwer:

  • przez scp, Git, lub CI/CD (np. GitHub Actions).

3.2 Plik docker-compose.prod.yml z optymalizacjami

Zmienne środowiskowe (SECRET_KEY, DB_PASSWORD) powinny znajdować się w pliku .env.prod, który nie jest wersjonowany w repozytorium.

3.3 Uruchomienie aplikacji

Na serwerze przejdź do katalogu projektu i uruchom:

Sprawdź, czy wszystko działa:

Podgląd logów:

3.4 Utrzymanie i aktualizacja

Aktualizacja aplikacji do nowej wersji:

Zatrzymanie aplikacji:

4. Przykład wdrożenia na DigitalOcean / AWS / Render

4.1 Wdrożenie na DigitalOcean (droplet VPS)

  • Utwórz Dropleta z Ubuntu (np. 2 vCPU, 2 GB RAM).
  • Połącz się przez SSH:
  • Zainstaluj Dockera i Docker Compose (jak w pkt 3.1).
  • Skopiuj pliki:
  • Uruchom aplikację:
  • Ustaw zaporę sieciową:

Aplikacja powinna być dostępna pod adresem http://your_droplet_ip.

4.2 Wdrożenie na AWS EC2

  • Utwórz instancję EC2 (np. Amazon Linux lub Ubuntu).
  • Zainstaluj Dockera:
  • Skopiuj obrazy z rejestru (np. Amazon ECR, Docker Hub).
  • Uruchom docker-compose.prod.yml:
  • Skonfiguruj domenę i HTTPS (np. z użyciem Nginx + certbot).

4.3 Wdrożenie na Render (Platform as a Service)

Render automatycznie obsługuje kontenery Dockera. Wystarczy:

  • Utworzyć repozytorium GitHub z plikiem Dockerfile.
  • Połączyć Render z repozytorium.

  • Render sam:

    • buduje obraz,
    • uruchamia kontener,
    • przypisuje domenę HTTPS.

Zalety:

  • brak potrzeby własnego VPS,
  • automatyczne aktualizacje przy pushu do main,
  • wbudowane logi i monitoring.

Wady:

  • mniejsza kontrola nad konfiguracją,
  • płatności za dodatkowe zasoby.

5. Najczęstsze problemy i ich rozwiązania

Problem Przyczyna Rozwiązanie
Kontenery restartują się w pętli Brak lub błędna zmienna środowiskowa Sprawdź .env.prod
Backend nie łączy się z bazą Niewłaściwa nazwa hosta lub sieć Użyj db jako hostname
Port 80 zajęty Inny serwer (np. Apache) działa Zatrzymaj (sudo systemctl stop apache2) lub zmień port
Zbyt duży rozmiar obrazu Brak multi-stage build Użyj FROM ... as builder
Dane bazy giną po restarcie Brak wolumenu Dodaj volumes: do usługi DB

6. Dobre praktyki wdrażania Dockera w produkcji

  1. Używaj stabilnych wersji obrazów (node:20.10.1, nie latest).
  2. Oddziel konfiguracje środowisk – docker-compose.dev.yml, docker-compose.prod.yml.
  3. Używaj .env.prod – bez umieszczania sekretów w kodzie.
  4. Ustaw restart usług (restart: always) – automatyczne ponowne uruchamianie.
  5. Korzystaj z HTTPS i reverse proxy (np. Nginx, Traefik).
  6. Monitoruj zasoby (docker stats, docker logs).
  7. Automatyzuj aktualizacje – CI/CD (GitHub Actions, GitLab CI).
  8. Regularnie czyszcz obrazy i wolumeny (docker system prune -a).
  9. Twórz kopie zapasowe danych (np. pg_dump dla PostgreSQL).
  10. Ogranicz dostęp SSH i aktualizuj system hosta.

7. Podsumowanie

Uruchomienie Dockera w środowisku produkcyjnym wymaga innego podejścia niż w fazie developmentu. Kluczowe jest zadbanie o:

  • stabilność – używaj wersjonowanych obrazów,
  • bezpieczeństwo – ochrona sekretów i ograniczenie uprawnień,
  • automatyzację – CI/CD, automatyczne buildy i wdrożenia,
  • wydajność – lekkie obrazy, multi-stage builds, monitoring.

Dzięki odpowiedniej konfiguracji docker-compose.prod.yml, możesz łatwo wdrożyć swoją aplikację na dowolny serwer (VPS, AWS, Render) w sposób szybki, powtarzalny i bezpieczny.

Docker w produkcji to nie tylko technologia — to strategia na niezawodne, skalowalne wdrażanie nowoczesnych aplikacji.

Wróć do spisu lekcji