Integracja Dockera z CI/CD

1. Wprowadzenie

Konteneryzacja i Docker idealnie wpisują się w nowoczesne praktyki DevOps. Ich połączenie z CI/CD (Continuous Integration / Continuous Deployment) umożliwia automatyczne:

budowanie i testowanie aplikacji,
tworzenie i publikowanie obrazów Dockerowych,
wdrażanie aktualnych wersji aplikacji na serwery lub do chmury.

W tej lekcji nauczysz się, jak:

zintegrować Dockera z pipeline’ami CI/CD (GitHub Actions i GitLab CI),
automatycznie budować i publikować obrazy,
wdrażać aplikacje z użyciem Docker Compose,
stosować najlepsze praktyki DevOps w oparciu o Dockera.

2. CI/CD – podstawowe pojęcia

2.1 CI (Continuous Integration)

Proces ciągłej integracji kodu — każdy commit lub merge do głównej gałęzi:

uruchamia automatyczne testy,
buduje aplikację i obraz Dockera,
sprawdza błędy i standardy kodu.

Celem CI jest wczesne wykrywanie błędów i utrzymanie spójności kodu w całym zespole.

2.2 CD (Continuous Delivery / Continuous Deployment)

To automatyczne wdrażanie przetestowanego kodu na środowisko staging lub produkcyjne. Różnice:

Typ	Opis
Continuous Delivery	Pipeline kończy się na gotowym do wdrożenia obrazie – wdrożenie wymaga potwierdzenia.
Continuous Deployment	Wdrożenie na produkcję odbywa się automatycznie po przejściu testów.

2.3 Docker w CI/CD

Docker idealnie wspiera CI/CD, ponieważ:

obrazy są powtarzalne i przenośne,
pipeline może budować te same kontenery, które działają lokalnie,
każdy etap (build, test, deploy) odbywa się w izolowanym środowisku,
wdrożenie to tylko uruchomienie docker-compose up -d z nowymi obrazami.

3. Budowanie i publikowanie obrazów Dockera w pipeline CI/CD

3.1 Koncepcja

Pipeline CI/CD składa się zazwyczaj z następujących kroków:

Checkout kodu z repozytorium
Budowanie obrazu Dockera
Uruchomienie testów (opcjonalnie)
Publikacja obrazu do rejestru (Docker Hub, GitHub Container Registry, GitLab Registry)
Wdrożenie nowej wersji na serwer

3.2 Przykład pipeline – GitHub Actions

Plik: .github/workflows/docker-build.yml

Co się dzieje:

Pipeline uruchamia się po każdym pushu do gałęzi main.
Obraz Dockera jest budowany z kodu z folderu backend.
Następnie jest tagowany i wysyłany do Docker Huba.

Dane logowania do Docker Huba są przechowywane bezpiecznie w sekcji Secrets GitHub Actions.

3.3 Przykład pipeline – GitLab CI

Plik: .gitlab-ci.yml

Co się dzieje:

Etap build tworzy obraz Dockera i wysyła go do GitLab Container Registry.
Etap deploy łączy się przez SSH z serwerem, pobiera nowy obraz i uruchamia aplikację.

4. Automatyczne wdrażanie z Docker Compose

4.1 Idea

Po zbudowaniu i opublikowaniu nowych obrazów, możesz automatycznie:

Połączyć się z serwerem (SSH lub API),
Pobrać najnowsze obrazy (docker-compose pull),
Uruchomić zaktualizowane kontenery (docker-compose up -d).

4.2 Przykład automatycznego wdrożenia (GitHub Actions)

Jak to działa:

Po zbudowaniu i wypchnięciu nowego obrazu pipeline automatycznie loguje się na serwer produkcyjny.
Wykonuje docker-compose pull, aby pobrać nowe wersje obrazów,
Następnie restartuje aplikację w tle (up -d).

To najprostszy i skuteczny sposób Continuous Deployment z Compose.

4.3 Automatyczne wersjonowanie obrazów

Aby każda wersja aplikacji miała unikalny tag:

W Compose możesz wskazać wersję dynamicznie:

W ten sposób każda wersja kodu ma własny obraz, co ułatwia rollback w razie problemów.

5. Najlepsze praktyki DevOps z Docker Compose

5.1 Używaj środowisk wersjonowanych

Oddzielne pliki Compose dla środowisk:
- docker-compose.dev.yml
- docker-compose.prod.yml
- W CI/CD używaj tylko wersji prod, bez montowania lokalnych katalogów.

5.2 Przechowuj sekrety w bezpieczny sposób

Nigdy nie commituj pliku .env.prod do repozytorium.
Używaj secrets w CI/CD:
- GitHub → Settings → Secrets and variables → Actions
- GitLab → Settings → CI/CD → Variables

5.3 Automatyzuj testy w kontenerach

Uruchamiaj testy jednostkowe w pipeline przed publikacją:

Dzięki temu masz pewność, że obraz jest sprawny zanim trafi do produkcji.

5.4 Wdrażaj tylko gotowe obrazy

Na serwerze produkcyjnym nigdy nie buduj obrazów. Budowanie odbywa się w CI/CD — serwer powinien jedynie:

pobrać obraz (docker pull),
uruchomić (docker-compose up -d).

5.5 Monitoruj wdrożenia i zasoby

Używaj docker logs i docker stats do monitorowania działania aplikacji.
W środowiskach zaawansowanych wdrażaj Prometheus + Grafana lub ELK Stack.
W pipeline możesz dodać krok monitorujący status kontenerów po wdrożeniu.

5.6 Wersjonuj swoje obrazy

Używaj tagów opartych o wersje lub commit SHA:

Dzięki temu łatwo cofnąć się do stabilnej wersji po nieudanym wdrożeniu.

5.7 Stosuj zasadę „immutable infrastructure”

Nie modyfikuj kontenerów ręcznie na serwerze. Każda zmiana powinna przechodzić przez pipeline CI/CD, który:

buduje nowy obraz,
publikuje go,
wdraża w sposób powtarzalny.

6. Korzyści z integracji Dockera z CI/CD

Korzyść	Opis
Powtarzalność	Pipeline zawsze buduje tę samą wersję obrazu z kodu.
Automatyzacja	Mniej błędów ludzkich, szybsze wdrożenia.
Skalowalność	Te same obrazy można wdrożyć w wielu środowiskach (staging, prod).
Bezpieczeństwo	Sekrety i dane uwierzytelniające przechowywane w systemie CI/CD.
Spójność	Ten sam kontener działa lokalnie, na testach i w produkcji.

7. Podsumowanie

Integracja Dockera z CI/CD to kluczowy krok w dojrzałym procesie DevOps. Dzięki niej zespół może budować, testować i wdrażać aplikacje szybciej, bezpieczniej i w sposób w pełni automatyczny.

Najważniejsze elementy:

Buduj i publikuj obrazy w pipeline (GitHub Actions / GitLab CI).
Automatycznie wdrażaj nowe wersje przy pomocy docker-compose pull i up -d.
Przechowuj sekrety w systemach CI/CD, nie w repozytorium.
Testuj kontenery w pipeline przed publikacją.
Stosuj wersjonowanie obrazów i rollbacki.
Traktuj infrastrukturę jako kod – każda zmiana przez pipeline.

Dzięki połączeniu Docker + CI/CD + Compose, cały cykl życia aplikacji — od kodu po wdrożenie produkcyjne — może być w pełni zautomatyzowany, bezpieczny i przewidywalny.