Jobs e Containers

Ao invés de utilizar os runners providos pelo github podemos utilizar runner definidos como queremos utilizando containers.

A vantagem de utilizar containers como nossos runners é ter o total controle do ambiente e o que está ou não instalado para simular o ambiente de onde a aplicação estará rodando.

Vimos anteriormente que o ubuntu-latest possui vários software pré instalados, como por exemplo o java e estavamos rodando uma aplicação nodejs. Usamos já a opção de instalar softwares usando uma action, mas seria muito melhor se o runner já estivesse pronto para o nosso ambiente, trazendo ainda mais velocidade no workflow.

Podemos criar container que irão rodar em cima dos runners em um ambiente completamente isolado. Vamos deixar claro que ainda sim o runner do github será utilizando, mas só como um executor de container, mesmo que tenha todos aqueles softwares instalados, o que importa é ter um container runtime também instalado.

Quando definimos um container todos os steps serão utilizados dentro do container.

jobs:
  test:
    environment: testing
    runs-on: ubuntu-latest
    container:
      image: node:16
      # As variávels aqui são as necessárias para rodar o container de acordo com o que a imagem precisa.
      env:
        env1: value1
        env2: value2
    # Estas variáveis se tornam extras no shell do container.
    env:
      MONGODB_CONNECTION_PROTOCOL: mongodb+srv
      MONGODB_CLUSTER_ADDRESS: cluster0.ntrwp.mongodb.net
      MONGODB_USERNAME: ${{ secrets.MONGODB_USERNAME }}
      MONGODB_PASSWORD: ${{ secrets.MONGODB_PASSWORD }}
      PORT: 8080

Todos os steps, mesmo na parte de cache ou qualquer outra action continuam funcionando normalmente.

Podemos usar os containers como serviço dentro de um workflow, por exemplo para prover rapidamente um banco de dados para teste. Ao invés de manter um database somente para esta funcionalidade podemos queimar uma imagem inclusive com um banco populado, testar nossa aplicação e destruir. Toda vez que testamos temos um banco pronto totalmente populado. É muito comum esse tipo de teste. O service cria um container sidecar no nosso workflow para ser usado.

jobs:
  test:
    environment: testing
    runs-on: ubuntu-latest
    container:
      image: node:16
    env:
      MONGODB_CONNECTION_PROTOCOL: mongodb
      MONGODB_CLUSTER_ADDRESS: mongodb # O nome do service quando
      MONGODB_USERNAME: root # mesmas credenciais do mongo que estamos lado a lado
      MONGODB_PASSWORD: pass
      PORT: 8080
    services:
      mongodb: # esse service
      image: mongo
      env:
        - MONGO_INITDB_ROOT_USERNAME: root
        - MONGO_INITDB_ROOT_PASSWORD: pass

Vale mensionar que todos os container e service são inicializados antes de iniciar os steps.

Se não estivermos utilizando container e somente o runner normalmente não podemos referenciar o nome do service, precisamos utilizar o localhost.

jobs:
  test:
    environment: testing
    runs-on: ubuntu-latest
    # container:
    #   image: node:16
    env:
      MONGODB_CONNECTION_PROTOCOL: mongodb
      MONGODB_CLUSTER_ADDRESS: 127.0.0.1:27017 # Mesmo porta externa do service mapeado
      MONGODB_USERNAME: root
      MONGODB_PASSWORD: pass
      PORT: 8080
    services:
      mongodb: # esse service
      image: mongo
      ports:
        - 27017:27017 # mapeamento de porta do container
      env:
        - MONGO_INITDB_ROOT_USERNAME: root
        - MONGO_INITDB_ROOT_PASSWORD: pass