В моем кластере Kubernetes я использую GitLab-ee 15.8.0 с GitLab Runner. Этот бегун настроен для исполнителя kubernetes, и я смонтировал /var/run/docker.sock
для этого бегуна в configmap. При запуске конвейера, который вызывает docker-compose-test.yml, я вижу, что все модули, существующие в kubernetes, начинают давать сбой и перезапускаются. После этого я вижу, что пайплайн все еще находится в состоянии Running
, но ни один раннер над ним не работает. Последней командой, которую бегун выполнил в конвейере, была: docker-compose -f docker-compose-test.yml up -d
.
Я ожидал, что конвейер просто вызовет контейнеры докеров и запустит тесты Laravel с использованием контейнера базы данных и контейнера приложения, но вместо этого он испортил ресурс Nginx-Ingress.
Я использую GitLab-ee:15.8.0 с версией gitlab-runner 15.8.2.
Вот gitlab-ci.yml:
image: docker:20.10.16
services:
- docker:20.10.16-dind
variables:
DOCKER_COMPOSE_CMD: "docker-compose -f docker-compose-test.yml"
stages:
- test
- build
test:
stage: test
script:
- docker-compose --version
- $DOCKER_COMPOSE_CMD down --volumes --remove-orphans
- $DOCKER_COMPOSE_CMD up -d
- $DOCKER_COMPOSE_CMD exec -T -e APP_ENV=testing laravel-api-test ./scripts/wait-for.sh database-test:54321 -t 60 -- echo "Database connection established"
- $DOCKER_COMPOSE_CMD exec -T -e APP_ENV=testing laravel-api-test php artisan passport:keys
- $DOCKER_COMPOSE_CMD exec -T -e APP_ENV=testing laravel-api-test php artisan migrate
- $DOCKER_COMPOSE_CMD exec -T -e APP_ENV=testing laravel-api-test sh -c "vendor/bin/phpunit ./tests $PARAMETERS --coverage-text --colors=never --stderr"
- $DOCKER_COMPOSE_CMD down --volumes --remove-orphans
# only:
# - tags
build:
stage: build
script:
- export IMAGE_TAG=$(echo "$CI_COMMIT_TAG" | awk -F '/' '{print $NF}')
- docker build -t laravel-api:"$IMAGE_TAG" .
- docker login -u "$CONTAINER_REGISTRY_USERNAME" -p "$CONTAINER_REGISTRY_PASSWORD" "$CONTAINER_REGISTRY_URL"
- docker push laravel-api:"$IMAGE_TAG"
only:
- tags
И это docker-compose-test.yml, который, кажется, все испортил:
version: "3.7"
services:
laravel-api-test:
build:
args:
user: laravel
uid: 1000
context: .
dockerfile: docker/development/Dockerfile
working_dir: /var/www/
volumes:
- ./:/var/www
ports:
- ${APP_PORT}:9000
networks:
- application
database-test:
image: postgres:15.1-alpine
ports:
- 54321:5432
environment:
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_USER: ${DB_USERNAME}
networks:
- application
networks:
application:
driver: bridge
Последнее, что, вероятно, важно, это конфиг gitlab-runner:
apiVersion: v1
kind: ConfigMap
metadata:
name: gitlab-runner-config
namespace: gitlab-runner
data:
config.toml: |-
concurrent = 4
[[runners]]
name = "Runner_1"
url = "https://gitlab.project.com/ci"
token = "my-token"
executor = "kubernetes"
[runners.kubernetes]
namespace = "gitlab-runner"
privileged = true
poll_timeout = 600
cpu_request = "1"
service_cpu_request = "200m"
[[runners.kubernetes.volumes.host_path]]
name = "docker"
mount_path = "/var/run/docker.sock"
host_path = "/var/run/docker.sock"
Наконец, это вывод конвейера после его сбоя:
Running with gitlab-runner 15.8.2 (4d1ca121)
on Runner_1 eNNz4y9k, system ID: r_y3jEhmF8fN58
Preparing the "kubernetes" executor
00:00
Using Kubernetes namespace: gitlab-runner
Using Kubernetes executor with image docker:20.10.16 ...
Using attach strategy to execute scripts...
Preparing environment
00:04
Waiting for pod gitlab-runner/runner-ennz4y9k-project-117-concurrent-0f24cx to be running, status is Pending
Running on runner-ennz4y9k-project-117-concurrent-0f24cx via gitlab-runner-56cd6f4bb5-zrbd9...
Getting source from Git repository
00:01
Fetching changes with git depth set to 20...
Initialized empty Git repository in /builds/Clients/opus-volvere/laravel-api/.git/
Created fresh repository.
Checking out 3890412c as main...
Skipping Git submodules setup
Executing "step_script" stage of the job script
$ docker-compose --version
Docker Compose version v2.6.0
$ $DOCKER_COMPOSE_CMD down --volumes --remove-orphans
Container laravel-api-database-test-1 Stopping
Container laravel-api-laravel-api-test-1 Stopping
Container laravel-api-database-test-1 Stopping
Container laravel-api-laravel-api-test-1 Stopping
Container laravel-api-database-test-1 Stopped
Container laravel-api-database-test-1 Removing
Container laravel-api-laravel-api-test-1 Stopped
Container laravel-api-laravel-api-test-1 Removing
Container laravel-api-laravel-api-test-1 Removed
Container laravel-api-database-test-1 Removed
Network laravel-api_application Removing
Network laravel-api_application Removed
$ $DOCKER_COMPOSE_CMD up -d
#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 827B done
#1 DONE 0.1s
#2 [internal] load .dockerignore
#2 transferring context: 88B done
#2 DONE 0.1s
Я не совсем уверен, где искать, с файлами журнала или чем-то еще, поэтому очень ценится некоторая помощь в отладке этой проблемы...
Насколько я вижу, запускается только при попытке запустить docker compose. Я уже создал образ в конвейере, и он работал так, как должен, но он начинает идти не так, как надо, когда я на самом деле пытаюсь запустить контейнеры. Может быть, это помогает? Это просто очень раздражающая проблема, которая не является моим настоящим опытом или чем-то еще, поэтому я много читаю, учусь и пробую :(
Я следовал этому туториалу о том, как добавить gitlab runner в kubernetes. Возможно, это как-то связано с тем, что он пытается создать новый модуль для конвейера, потому что в отправленном мной руководстве говорится:
Второй — это ServiceAccount, Role и RoleBinding, чтобы дать Запустите привилегии для добавления новых модулей в пространство имен.
Опять же, я не знаком со всеми этими вещами, поэтому для меня это тоже выстрел в темноту, но я очень хочу, чтобы это было исправлено, чтобы я мог продолжить работу над этим проектом.
Что может привести к тому, что этот конвейер GitLab приведет к сбою всего моего kubernetes?
Никогда не подвергайте среду выполнения хост-контейнера рабочей нагрузке внутри кластера. Это может привести к тому, что GitLab runner «подчистит» и удалит контейнеры, в которых работают компоненты вашего кластера.
В дополнение к этому вы привязываетесь к конкретной среде выполнения контейнера, которая должна быть деталью реализации вашего кластера.
В качестве альтернативы вы можете использовать docker-in-docker, например, для GitLab runner.
Точно, не делайте этого, запустите для него отдельный докер-в-докере.
Может я что-то не правильно понимаю, но для работы DinD
нужно ли запускать новый деплой или что-то рядом с gitlab-runner или это уже что-то внутри gitlab-runner. Я много читал об изменениях в версии докера 18.09
где нужен или не нужен динд? Сейчас снял крепление розетки, но теперь получаю: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
. Я думаю, мне нужно изменить env docker_host, верно?
Я добавил атрибут tls_verify = false
к [runners.kubernetes]
и добавил DOCKER_HOST: "tcp://docker:2375"
, но все равно получил: Cannot connect to the Docker daemon at tcp://docker:2375. Is the docker daemon running?
Вам нужно запустить экземпляр докера как часть бегуна. В зависимости от метода вы можете либо совместно использовать сокет этого демона докера (не хосты!), использовать localhost в качестве хоста докера или предоставить службу dind as kubernetes.
Просто чтобы быть уверенным, что под «запуском экземпляра докера как части бегуна» вы имеете в виду создание нового развертывания в моем кластере, которое запускает докер в том же пространстве имен, что и мой бегун gitlab?
Это один вариант, другой — добавить контейнер DIND в определение модуля бегуна как runners.kubernetes.services.
Я попытался запустить развертывание docker-dind со службой, которая перенаправляет порт 2375 в развертывание, но я не могу заставить это работать. Не могли бы вы привести пример того, как я могу добавить определение модуля как runners.kubernetes.services. При работе в качестве отдельного модуля я получаю эту ошибку: error during connect: Get "http://docker-svc:2375/v1.24/containers/json?all=1&filters=%7B%22label%22%3A%7B%22com.docker.compose.project%3Dlaravel-api%22%3Atrue%7D%7D&limit=0": dial tcp: lookup docker-svc on 10.152.183.10:53: no such host
Я думаю, что это лучше подходит для другого вопроса.
Хорошо, я поставил проблему в этом вопросе: stackoverflow.com/questions/75460620/…
Так что я не должен монтировать docker.sock внутри бегуна gitlab?