Jobs y Contenedores

En lugar de utilizar los runners provistos por github podemos utilizar runners definidos como queremos usando contenedores.

La ventaja de utilizar contenedores como nuestros runners es tener el control total del entorno y lo que está o no instalado para simular el entorno donde la aplicación estará ejecutándose.

Vimos anteriormente que el ubuntu-latest tiene varios softwares preinstalados, como por ejemplo java y estábamos ejecutando una aplicación nodejs. Ya usamos la opción de instalar softwares usando una action, pero sería mucho mejor si el runner ya estuviera listo para nuestro entorno, trayendo aún más velocidad en el workflow.

Podemos crear contenedores que se ejecutarán sobre los runners en un entorno completamente aislado. Dejemos claro que aún así el runner de github será utilizado, pero solo como un ejecutor de contenedor, aunque tenga todos aquellos softwares instalados, lo que importa es tener un container runtime también instalado.

Cuando definimos un contenedor todos los steps se utilizarán dentro del contenedor.

jobs:
  test:
    environment: testing
    runs-on: ubuntu-latest
    container:
      image: node:16
      # Las variables aquí son las necesarias para ejecutar el contenedor según lo que la imagen necesita.
      env:
        env1: value1
        env2: value2
    # Estas variables se vuelven extras en el shell del contenedor.
    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 los steps, incluso en la parte de caché o cualquier otra action continúan funcionando normalmente.

Podemos usar los contenedores como servicio dentro de un workflow, por ejemplo para proveer rápidamente una base de datos para pruebas. En lugar de mantener una base de datos solo para esta funcionalidad podemos quemar una imagen incluso con una base de datos poblada, probar nuestra aplicación y destruir. Cada vez que probamos tenemos una base de datos lista totalmente poblada. Es muy común este tipo de prueba. El service crea un contenedor sidecar en nuestro 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 # El nombre del servicio cuando
      MONGODB_USERNAME: root # mismas credenciales del mongo que estamos lado a lado
      MONGODB_PASSWORD: pass
      PORT: 8080
    services:
      mongodb: # este servicio
      image: mongo
      env:
        - MONGO_INITDB_ROOT_USERNAME: root
        - MONGO_INITDB_ROOT_PASSWORD: pass

Vale mencionar que todos los contenedores y services se inicializan antes de iniciar los steps.

Si no estamos utilizando contenedor y solo el runner normalmente no podemos referenciar el nombre del servicio, necesitamos utilizar el 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 # Mismo puerto externo del servicio mapeado
      MONGODB_USERNAME: root
      MONGODB_PASSWORD: pass
      PORT: 8080
    services:
      mongodb: # este servicio
      image: mongo
      ports:
        - 27017:27017 # mapeo de puerto del contenedor
      env:
        - MONGO_INITDB_ROOT_USERNAME: root
        - MONGO_INITDB_ROOT_PASSWORD: pass