Contentores de serviço

2025-04-03

Serviços de DevOps do Azure

Se o pipeline exigir o suporte de um ou mais serviços, talvez seja necessário criar, conectar-se e limpar os serviços para cada tarefa. Por exemplo, seu pipeline pode executar testes de integração que exigem acesso a um banco de dados recém-criado e cache de memória para cada trabalho no pipeline.

Um contêiner fornece uma maneira simples e portátil de executar um serviço do qual seu pipeline depende. Um contêiner de serviço permite criar, conectar e gerenciar automaticamente o ciclo de vida de um serviço em contêiner. Cada contêiner de serviço é acessível apenas para o trabalho que o exige. Os contêineres de serviço funcionam com qualquer tipo de trabalho, mas são mais comumente usados com trabalhos de contêiner.

Requisitos

Os contêineres de serviço devem definir um CMD ou ENTRYPOINT. O pipeline é executado docker run para o contêiner fornecido sem quaisquer argumentos.
Os Pipelines do Azure podem executar contêineres Linux ou Windows. Você pode usar o pool de contêineres do Ubuntu hospedado para contêineres do Linux ou o pool do Windows hospedado para contêineres do Windows. O pool macOS hospedado não suporta contêineres em execução.

Nota

Os contêineres de serviço não são suportados em pipelines clássicos.

Trabalho de contêiner único

A definição de pipeline YAML a seguir mostra uma única tarefa de contêiner.

resources:
  containers:
  - container: my_container
    image: buildpack-deps:focal
  - container: nginx
    image: nginx

pool:
  vmImage: 'ubuntu-latest'

container: my_container
services:
  nginx: nginx

steps:
- script: |
    curl nginx
  displayName: Show that nginx is running

O pipeline anterior busca os contentores nginx e buildpack-deps do Docker Hub e, em seguida, inicia os contentores. Os contentores estão ligados em rede para que possam chegar uns aos outros pelo seu services nome.

De dentro desse contêiner de trabalho, o nome do nginx host é resolvido para os serviços corretos usando a rede do Docker. Todos os contêineres na rede expõem automaticamente todas as portas entre si.

Trabalho único sem contêiner

Você também pode usar contêineres de serviço sem um contêiner de trabalho, como no exemplo a seguir.

resources:
  containers:
  - container: nginx
    image: nginx
    ports:
    - 8080:80
    env:
      NGINX_PORT: 80
  - container: redis
    image: redis
    ports:
    - 6379

pool:
  vmImage: 'ubuntu-latest'

services:
  nginx: nginx
  redis: redis

steps:
- script: |
    curl localhost:8080
    echo $AGENT_SERVICES_REDIS_PORTS_6379

A linha de montagem anterior inicia os contentores mais recentes nginx. Como o trabalho não está sendo executado em um contêiner, não há resolução automática de nomes. Em vez disso, é possível aceder aos serviços utilizando localhost. O exemplo fornece explicitamente a 8080:80 porta.

Uma abordagem alternativa é permitir que uma porta aleatória seja atribuída dinamicamente em tempo de execução. Em seguida, você pode acessar essas portas dinâmicas usando variáveis. Estas variáveis assumem a forma: agent.services.<serviceName>.ports.<port>. Em um script Bash, você pode acessar variáveis usando o ambiente de processo.

No exemplo anterior, redis é atribuída uma porta disponível aleatória no host. A agent.services.redis.ports.6379 variável contém o número da porta.

Vários trabalhos

Os contêineres de serviço também são úteis para executar as mesmas etapas em várias versões do mesmo serviço. No exemplo a seguir, as mesmas etapas são executadas em várias versões do PostgreSQL.

resources:
  containers:
  - container: my_container
    image: ubuntu:22.04
  - container: pg15
    image: postgres:15
  - container: pg14
    image: postgres:14

pool:
  vmImage: 'ubuntu-latest'

strategy:
  matrix:
    postgres15:
      postgresService: pg15
    postgres14:
      postgresService: pg14

container: my_container

services:
  postgres: $[ variables['postgresService'] ]
steps:
- script: printenv

Portas

Ao invocar um recurso de contêiner ou um contêiner embutido, você pode especificar uma matriz de ports para expor no contêiner, como no exemplo a seguir.

resources:
  containers:
  - container: my_service
    image: my_service:latest
    ports:
    - 8080:80
    - 5432

services:
  redis:
    image: redis
    ports:
    - 6379/tcp

A especificação ports não é necessária se o trabalho estiver sendo executado em um contêiner, porque os contêineres na mesma rede do Docker expõem automaticamente todas as portas umas às outras por padrão.

Se o seu trabalho estiver em execução no host, ports são necessários para aceder ao serviço. Uma porta assume a forma <hostPort>:<containerPort> ou apenas <containerPort> com um opcional /<protocol> no final. Por exemplo, 6379/tcp expõe tcp sobre a porta 6379, vinculado a uma porta aleatória na máquina host.

Para portas vinculadas a uma porta aleatória na máquina host, o pipeline cria uma variável no formato agent.services.<serviceName>.ports.<port>, permitindo que o trabalho aceda à porta. Por exemplo, agent.services.redis.ports.6379 corresponde à porta atribuída aleatoriamente na máquina anfitriã.

Volumes

Os volumes são úteis para compartilhar dados entre serviços ou para persistir dados entre várias execuções de um trabalho. Você especifica montagens de volume como uma matriz do volumes do formato <source>:<destinationPath>, onde <source> pode ser um volume nomeado ou um caminho absoluto na máquina anfitriã e <destinationPath> é um caminho absoluto no contêiner. Os volumes podem ser chamados volumes do Docker, volumes anónimos do Docker ou bind mounts no host.

services:
  my_service:
    image: myservice:latest
    volumes:
    - mydockervolume:/data/dir
    - /data/dir
    - /src/dir:/dst/dir

Nota

Se você usar pools hospedados pela Microsoft, seus volumes não serão persistidos entre os trabalhos, porque a máquina host será limpa após a conclusão de cada trabalho.

Opções de inicialização

Os contêineres de serviço compartilham os mesmos recursos de contêiner que os trabalhos de contêiner. Isso significa que você pode usar as mesmas opções de inicialização.

Verificação de Saúde

Se qualquer contentor de serviço especificar um HEALTHCHECK, o agente pode, opcionalmente, aguardar até que o contentor esteja íntegro antes de executar a tarefa.

Exemplo de vários contêineres com serviços

O exemplo a seguir tem um contêiner da web Django Python conectado a contêineres de banco de dados PostgreSQL e MySQL.

O banco de dados PostgreSQL é o banco de dados primário e seu contêiner é chamado db.
O db contêiner usa volume /data/db:/var/lib/postgresql/datae há três variáveis de banco de dados passadas para o contêiner via env.
O mysql contêiner usa porta 3306:3306, e também há variáveis de banco de dados passadas via env.
O web contêiner está aberto com porta 8000.

Nas etapas, pip instala dependências e, em seguida, os testes do Django são executados.

Para configurar um exemplo de trabalho, você precisa de um site Django configurado com dois bancos de dados. O exemplo assume que seu arquivo manage.py está no diretório raiz e seu projeto Django também está dentro desse diretório. Caso contrário, talvez seja necessário atualizar o /__w/1/s/ caminho no /__w/1/s/manage.py test.

resources:
  containers:
    - container: db
      image: postgres
      volumes:
          - '/data/db:/var/lib/postgresql/data'
      env:
        POSTGRES_DB: postgres
        POSTGRES_USER: postgres
        POSTGRES_PASSWORD: postgres
    - container: mysql
      image: 'mysql:5.7'
      ports:
         - '3306:3306'
      env:
        MYSQL_DATABASE: users
        MYSQL_USER: mysql
        MYSQL_PASSWORD: mysql
        MYSQL_ROOT_PASSWORD: mysql
    - container: web
      image: python
      volumes:
      - '/code'
      ports:
        - '8000:8000'

pool:
  vmImage: 'ubuntu-latest'

container: web
services:
  db: db
  mysql: mysql

steps:
    - script: |
        pip install django
        pip install psycopg2
        pip install mysqlclient
      displayName: set up django
    - script: |
          python /__w/1/s/manage.py test