Взаимодействие с контейнерами служб Docker
Контейнеры служб представляют собой контейнеры Docker, которые предоставляют простой портативный способ размещения служб, которые вам могут потребоваться для тестирования или эксплуатации приложения в рабочем процессе. Например, рабочему процессу может потребоваться выполнить тесты интеграции, требующие доступа к базе данных и кэшу памяти.
Контейнеры служб можно настроить для каждого задания в рабочем процессе. GitHub создаёт новый контейнер Docker для каждого сервиса, настроенного в рабочем процессе, и уничтожает контейнер сервиса после завершения задачи. Действия в задании могут взаимодействовать со всеми контейнерами служб, которые включены в одно задание. Однако нельзя создавать и использовать контейнеры служб в рамках составного действия.
Примечание.
Если в рабочих процессах используются действия контейнеров Docker, контейнеры заданий или контейнеры служб, необходимо использовать средство выполнения Linux:
- При использовании размещенных в GitHub средств выполнения необходимо применять средство выполнения Ubuntu.
- Если вы применяете локальные средства выполнения, необходимо использовать компьютер Linux в качестве средства выполнения, а Docker нужно установить.
Задания в рабочем процессе можно настроить для выполнения непосредственно на компьютере средства выполнения тестов или в контейнере Docker. Обмен данными между заданием и его контейнерами служб может варьироваться в зависимости от того, выполняется ли задание непосредственно на компьютере средства выполнения тестов или в контейнере.
Выполнение заданий в контейнере
Когда вы запускаете задачи в контейнере, GitHub сервисные контейнеры соединяются с задачей с помощью пользовательских мостовых сетей Docker. Дополнительные сведения см. в разделе "Сетевой драйвер Bridge" в документации по Docker.
Выполнение задания и служб в контейнере упрощает сетевой доступ. Вы можете получить доступ к контейнеру службы с помощью метки, настроенной в рабочем процессе. Имя узла контейнера службы автоматически сопоставляется с именем метки. Например, если вы создаете контейнер службы с меткой redis, имя узла контейнера службы будет redis.
Вам не потребуется настраивать порты для контейнеров служб. По умолчанию все контейнеры, которые являются частью одной сети Docker, предоставляют все порты друг другу, однако порты не предоставляются за пределами сети Docker.
Выполнение заданий на компьютере средства выполнения тестов
При выполнении заданий непосредственно на компьютере средства выполнения тестов можно получить доступ к контейнерам служб с помощью localhost:<port> или 127.0.0.1:<port>.
GitHub настраивает сеть контейнеров для обеспечения связи между сервисным контейнером и Docker-хостом.
Когда задание выполняется непосредственно на компьютере средства выполнения тестов, служба, запущенная в контейнере Docker, по умолчанию не предоставляет свои порты заданию в средстве выполнения тестов. Необходимо сопоставить порты в контейнере службы с узлом Docker. Дополнительные сведения см. в разделе Взаимодействие с контейнерами служб Docker.
Создание контейнеров служб
Ключевое слово services можно использовать для создания контейнеров служб, которые являются частью задания в рабочем процессе. Дополнительные сведения см. в статье jobs.<job_id>.services.
В этом примере создается служба, вызываемая redis в задании, вызываемом container-job. В этом примере узел Docker является контейнером node:16-bullseye.
name: Redis container example
on: push
jobs:
# Label of the container job
container-job:
# Containers must run in Linux based operating systems
runs-on: ubuntu-latest
# Docker Hub image that `container-job` executes in
container: node:16-bullseye
# Service containers to run with `container-job`
services:
# Label used to access the service container
redis:
# Docker Hub image
image: redis
name: Redis container example
on: push
jobs:
# Label of the container job
container-job:
# Containers must run in Linux based operating systems
runs-on: ubuntu-latest
# Docker Hub image that `container-job` executes in
container: node:16-bullseye
# Service containers to run with `container-job`
services:
# Label used to access the service container
redis:
# Docker Hub image
image: redis
Сопоставление портов узла Docker и контейнеров служб
Если задание выполняется в контейнере Docker, не требуется сопоставлять порты на узле или в контейнере службы. Если задание выполняется непосредственно на компьютере средства выполнения тестов, необходимо сопоставить все необходимые порты контейнера службы с портами на хост-компьютере средства выполнения тестов.
Вы можете сопоставить порты контейнеров служб с узлом Docker с помощью ключевого слова ports. Дополнительные сведения см. в статье jobs.<job_id>.services.
Значение параметра ports | Description |
|---|---|
8080:80 | Сопоставляет TCP-порт 80 в контейнере с портом 8080 на узле Docker. |
8080:80/udp | Сопоставляет UDP-порт 80 в контейнере с портом 8080 на узле Docker. |
8080/udp | Сопоставляет случайный выбранный порт на узле Docker с портом UDP 8080 в контейнере. |
Когда вы сопоставляете порты по ключевому ports слову, GitHub используйте --publish команду для публикации портов контейнера на хост Docker. Дополнительные сведения см . в разделе "Сеть контейнеров Docker" в документации по Docker.
Если указать порт контейнера, но не порт узла Docker, порт контейнера случайным образом назначается свободному порту.
GitHub задаёт назначенный контейнерный порт в контексте сервисного контейнера. Например, если для контейнера службы redis настроен порт узла Docker 5432, можно получить доступ к соответствующему порту контейнера с помощью контекста job.services.redis.ports[5432]. Дополнительные сведения см. в разделе Справочник по контекстам.
Пример сопоставления портов Redis
В этом примере порт контейнера службы redis 6379 сопоставляется с портом узла Docker 6379.
name: Redis Service Example
on: push
jobs:
# Label of the container job
runner-job:
# You must use a Linux environment when using service containers or container jobs
runs-on: ubuntu-latest
# Service containers to run with `runner-job`
services:
# Label used to access the service container
redis:
# Docker Hub image
image: redis
#
ports:
# Opens tcp port 6379 on the host and service container
- 6379:6379
name: Redis Service Example
on: push
jobs:
# Label of the container job
runner-job:
# You must use a Linux environment when using service containers or container jobs
runs-on: ubuntu-latest
# Service containers to run with `runner-job`
services:
# Label used to access the service container
redis:
# Docker Hub image
image: redis
#
ports:
# Opens tcp port 6379 on the host and service container
- 6379:6379
Проверка подлинности с помощью реестров образов
Вы можете указать учетные данные для контейнеров служб, если необходимо пройти проверку подлинности в реестре образов. Это позволяет использовать образы из частных реестров или увеличить ограничение скорости DockerHub.
Вот пример аутентификации с помощью Docker Hub и GitHubContainer registry:
jobs:
build:
services:
redis:
# Docker Hub image
image: redis
ports:
- 6379:6379
credentials:
username: ${{ secrets.dockerhub_username }}
password: ${{ secrets.dockerhub_password }}
db:
# Private registry image
image: ghcr.io/octocat/testdb:latest
credentials:
username: ${{ github.repository_owner }}
password: ${{ secrets.ghcr_password }}
jobs:
build:
services:
redis:
# Docker Hub image
image: redis
ports:
- 6379:6379
credentials:
username: ${{ secrets.dockerhub_username }}
password: ${{ secrets.dockerhub_password }}
db:
# Private registry image
image: ghcr.io/octocat/testdb:latest
credentials:
username: ${{ github.repository_owner }}
password: ${{ secrets.ghcr_password }}
Настройка точек входа и команд сервисного контейнера
По умолчанию сервисные контейнеры работают с точкой входа и командой, определёнными в образе Docker. Вы можете переобойти их с помощью entrypoint клавиш and command . Это полезно, когда нужно передавать флаги сервису (например, базе данных) или полностью менять входную точку изображения, не создавая собственный образ оболочки.
Клавиша command переопределяет команду изображения по умолчанию (CMD). В большинстве сценариев достаточно command— на изображении уже есть правильная точка входа, нужно просто передать флаги:
services:
mysql:
image: mysql:8
command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M
env:
MYSQL_ROOT_PASSWORD: test
ports:
- 3306:3306
services:
mysql:
image: mysql:8
command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M
env:
MYSQL_ROOT_PASSWORD: test
ports:
- 3306:3306
Клавиша entrypoint перекрывает изображение ENTRYPOINT. Вы можете комбинировать это с command для передачи аргументов в пользовательскую точку входа:
services:
etcd:
image: quay.io/coreos/etcd:v3.5.17
entrypoint: etcd
command: >-
--listen-client-urls http://0.0.0.0:2379
--advertise-client-urls http://0.0.0.0:2379
ports:
- 2379:2379
services:
etcd:
image: quay.io/coreos/etcd:v3.5.17
entrypoint: etcd
command: >-
--listen-client-urls http://0.0.0.0:2379
--advertise-client-urls http://0.0.0.0:2379
ports:
- 2379:2379
Название и поведение совпадают с Docker Compose. Дополнительные сведения см. в разделах jobs.<job_id>.services.<service_id>.command и jobs.<job_id>.services.<service_id>.entrypoint.
Дополнительные материалы
-
[AUTOTITLE](/actions/using-containerized-services/creating-redis-service-containers) -
[AUTOTITLE](/actions/using-containerized-services/creating-postgresql-service-containers)