Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2024-09-25. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Sobre os contêineres de serviço

Você pode usar contêineres de serviço para conectar bancos de dados, serviços web, memória cache e outras ferramentas ao seu fluxo de trabalho.

Note

No momento, não há suporte para executores hospedados no GitHub no GitHub Enterprise Server. Você pode ver mais informações sobre o suporte futuro planejado no GitHub public roadmap.

Sobre os contêineres de serviço

Os contêineres de serviço são contêineres Docker que fornecem uma forma simples e portátil para os seus serviços de hospedagem que você pode precisar testar ou operar a sua aplicação em um fluxo de trabalho. Por exemplo, o seu fluxo de trabalho pode precisar executar testes de integração que necessitem de acesso a um banco de dados e a uma memória cache.

Você pode configurar os contêineres de serviço para cada trabalho em um fluxo de trabalho. GitHub cria um novo contêiner Docker para cada serviço configurado no fluxo de trabalho e destrói o contêiner de serviço quando o trabalho é concluído. As etapas em um trabalho podem comunicar-se com todos os contêineres de serviço que fazem parte do mesmo trabalho. No entanto, não é possível criar nem usar contêineres de serviço em uma ação composta.

Note

Se os fluxos de trabalho usarem ações de contêiner do Docker, contêineres de trabalho ou contêineres de serviço, você precisará usar um executor do Linux:

  • Se você estiver usando executores hospedados em GitHub, você deverá usar um executor do Ubuntu.
  • Se você estiver usando executores auto-hospedados, você deve usar uma máquina Linux, pois seu executor e o Docker precisam ser instalados.

Comunicar-se com os contêineres de serviço

Você pode configurar trabalhos em um fluxo de trabalho para ser executados diretamente em uma máquina executora ou em um contêiner Docker. A comunicação entre o trabalho e seus contêineres de serviço é diferente, dependendo se um trabalho é executado diretamente na máquina executora ou em um contêiner.

Executar trabalhos em um contêiner

Ao executar trabalhos em um contêiner, GitHub conecta os contêineres de serviço ao trabalho suando as redes de ponte definidas pelo usuário do Docker. Para obter mais informações, consulte "Driver de rede de ponte" na documentação do Docker.

Executar o trabalho e os serviços em um contêiner simplifica o acesso à rede. Você pode acessar um contêiner de serviço usando a etiqueta que você configurar no fluxo de trabalho. O nome de host do contêiner do serviço é mapeado automaticamente de acordo com o nome da etiqueta. Por exemplo, se você criar um contêiner de serviço com o rótulo redis, o nome do host do contêiner de serviço será redis.

Você não precisa configurar nenhuma porta para os contêineres de serviço. Por padrão, todos os contêineres que fazem parte da mesma rede do Docker expõem todas as portas entre si e nenhuma porta é exposta fora da rede do Docker.

Executar trabalhos na máquina executora

Ao executar trabalhos diretamente no computador do executor, você pode acessar os contêineres de serviço usando localhost:<port> ou 127.0.0.1:<port>. GitHub configura a rede do contêiner para habilitar a comunicação a partir do contêiner de serviço com o host do Docker.

Quando um trabalho é executado diretamente em uma máquina executora, o serviço executado no contêiner do Docker não expõe suas portas ao trabalho no executor por padrão. Você deve mapear as portas no contêiner de serviço com o host do Docker. Para obter mais informações, confira "Sobre os contêineres de serviço".

Criar contêineres de serviço

Use a palavra-chave services para criar contêineres de serviço que fazem parte de um trabalho no fluxo de trabalho. Para obter mais informações, confira jobs.<job_id>.services.

Este exemplo cria um serviço chamado redis em um trabalho chamado container-job. O host do Docker neste exemplo é o contêiner node:16-bullseye.

YAML
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

Mapear o host do Docker e as portas do contêiner de serviço

Se o seu trabalho for executado em um contêiner do Docker, você não precisará mapear as portas no host ou no contêiner de serviço. Se o seu trabalho for executado diretamente na máquina executora, você precisará mapear todas as portas do contêiner de serviço necessárias com as portas na máquina executora do host.

Você pode mapear portas de contêineres de serviço para o host do Docker usando a palavra-chave ports. Para obter mais informações, confira jobs.<job_id>.services.

Valor de portsDescrição
8080:80Mapeia a porta 80 TCP no contêiner com a porta 8080 no host do Docker.
8080:80/udpMapeia a porta 80 UDP no contêiner com a porta 8080 no host do Docker.
8080/udpMapeia a porta escolhida aleatoriamente no host do Docker para a porta 8080 UDP no contêiner.

Quando você mapeia portas usando a palavra-chave ports, o GitHub usa o comando --publish para publicar as portas do contêiner no host do Docker. Para obter mais informações, confira "Rede de contêineres do Docker" na documentação do Docker.

Ao especificar a porta do contêiner mas não a porta do Docker, a porta do contêiner será atribuída aleatoriamente a uma porta livre. GitHub define a porta do contêiner atribuída no contexto do contêiner de serviço. Por exemplo, para um contêiner de serviço redis, se você tiver configurado a porta de host do Docker 5432, poderá acessar a porta de contêiner correspondente usando o contexto job.services.redis.ports[5432]. Para obter mais informações, confira "Acessar informações contextuais sobre execuções de fluxo de trabalho".

Exemplo de mapeamento de portas Redis

Este exemplo mapeia a porta redis do contêiner de serviço 6379 para a porta 6379 do host do Docker.

YAML
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

Autenticando com registros de imagem

Você poderá especificar credenciais para os contêineres de serviço se precisar fazer autenticação com um registro de imagem. Isso permite a você usar imagens de registros privados ou aumentar o limite de taxa do DockerHub.

Este é um exemplo de autenticação com o Docker Hub e o GitHub Container registry:

YAML
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 }}

Leitura adicional