GitLab Runner: Uruchamianie testów z Testcontainers

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!

Testcontainers to biblioteka testowa dostępna dla Java, Go, Node.js, Python, .NET i innych języków, która uruchamia rzeczywiste usługi jako tymczasowe kontenery Docker podczas wykonywania testów. Zamiast mockować bazę danych czy broker wiadomości, testy integracyjne komunikują się z prawdziwą instancją PostgreSQL, MySQL, Redis lub Kafka, utworzoną przed testami i usuwaną zaraz po nich. Rozwiązanie to jest szczególnie popularne w projektach Java i Spring.

Testcontainers wymaga demona Docker, więc działa dokładnie z tą samą konfiguracją Docker-in-Docker jak powyżej. Nie są potrzebne dodatkowe zmienne:

test:
  stage: test
  # Użyj obrazu wymaganego przez Twoje testy (tutaj JDK), niekoniecznie obrazu docker:
  image: gradle:jdk21
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  script:
    - gradle test

Testcontainers odczytuje DOCKER_HOST, aby znaleźć demona, i używa tej samej nazwy hosta docker, aby uzyskać dostęp do portów publikowanych przez uruchamiane kontenery. Oba mechanizmy działają niezależnie, ponieważ alias docker jest rozpoznawany w sieci joba.

Zachowaj DOCKER_HOST w jobach korzystających z Testcontainers. Bez tej zmiennej Testcontainers użyje socketu Docker zamontowanego przez runnera, a następnie spróbuje połączyć się z kontenerami testowymi przez adres IP hosta, do którego job nie ma dostępu. Typowym objawem jest błąd kontenera pomocniczego Ryuk: Wait strategy failed. Container is removed lub Timed out waiting for log output matching '.*Started.*'.