GitLab Runner: Budowanie obrazu Docker z Docker-in-Docker

Ta dokumentacja jest częścią przewodnika Budowanie obrazów Docker. Pełny przewodnik znajdziesz tutaj: Efektywne budowanie i wysyłanie obrazów Docker z pipeline’ów GitLab CI/CD przy użyciu runnerów Stackhero i Docker-in-Docker.

👋 Witamy w dokumentacji Stackhero!

Stackhero oferuje prostą usługę GitLab Runner cloud, która umożliwia wydajne i bezproblemowe uruchamianie zadań GitLab CI/CD. Oto, czego możesz się spodziewać:

• Nielimitowane minuty CI/CD: uruchamiaj swoje pipeline'y tak często, jak potrzebujesz, bez rozliczania za minuty i nieprzewidzianych kosztów.
• Wiele równoczesnych zadań: przyspiesz rozwój, uruchamiając kilka zadań jednocześnie.
• Docker executor z obsługą Docker-in-Docker: łatwo buduj i wysyłaj obrazy kontenerów w ramach procesu CI/CD.
• Działa bezproblemowo zarówno z GitLab.com, jak i z instancjami self-managed GitLab.
• Prywatna, dedykowana infrastruktura z szybkim dyskiem NVMe/SSD zapewnia stabilną i przewidywalną wydajność budowania.
• Dostępne w regionach 🇪🇺 Europa oraz 🇺🇸 USA, aby dopasować się do potrzeb Twojego zespołu.

Oszczędzaj czas: możesz podłączyć swojego pierwszego GitLab Runner i rozpocząć uruchamianie pipeline'ów w zaledwie kilka minut!

Możesz dodać poniższy przykładowy plik .gitlab-ci.yml do swojego repozytorium. Ta konfiguracja buduje Dockerfile znajdujący się w katalogu głównym projektu:

build-image:
  stage: build
  image: docker:29
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Zamień "my-image" na wybraną nazwę:
    - docker build -t my-image .
    # Opcjonalnie, uruchom szybki test na zbudowanym obrazie:
    # - docker run --rm my-image /path/to/tests

W tym przykładzie używamy obrazu Docker w wersji 29. Możesz użyć nowszej wersji, jeśli jest dostępna. Najnowsze tagi znajdziesz na oficjalnej stronie obrazu Docker.

W tej konfiguracji serwis docker:29-dind uruchamia demona Docker obok Twojego joba, a DOCKER_HOST: "tcp://docker:2375" wskazuje CLI docker, aby korzystało z tego demona. Zawsze ustawiaj DOCKER_HOST, gdy deklarujesz serwis docker:dind: bez tego CLI po cichu połączy się z innym demonem, przez co build może przejść mimo błędnej konfiguracji serwisu, co ukrywa rzeczywiste problemy (i powoduje błędy w narzędziach takich jak Testcontainers, które polegają na tym serwisie). DOCKER_TLS_CERTDIR: "" oznacza połączenie przez zwykły, niezaszyfrowany port 2375 w wewnętrznej sieci joba.

Jako prostszą alternatywę możesz pominąć blok services i obie zmienne: runner Stackhero udostępnia gotowego do użycia demona Docker przez zamontowany socket, więc polecenie docker build działa bez dodatkowej konfiguracji.