Ejemplo CI

Para ejecutar los steps de cada uno de los stages es necesario que tengamos runners que hagan esta tarea. Podemos utilizar los runners de Harness Cloud validando una tarjeta de crédito. Otra idea es crear los runners localmente en tu propia máquina para que haga el procesamiento utilizando contenedores.

Podemos crear los runners en kubernetes como vimos anteriormente en el ejemplo de CD pero esta vez vamos a docker cambiando el escenario.

La documentación está en https://developer.harness.io/docs/continuous-integration/use-ci/set-up-build-infrastructure/define-a-docker-build-infrastructure.

Requisitos:

Docker instalado es un requisito para este ejemplo.
Cuenta en DockerHub para hacer el push de la imagen durante el pipeline.

Vamos a crear un connector en la cuenta para tener acceso a tu cuenta de DockerHub. La dirección predeterminada de DockerHub si no tienes una personalizada es https://registry.hub.docker.com/v2. Pon tu usuario y contraseña para que se conecte. Da un nombre fácil para identificar. Documentación Docker Connector.

alt text

wget https://raw.githubusercontent.com/harness/harness-docker-runner/master/scripts/script-prod.sh -O script.sh
sh script.sh TuAccountID TuDelegateToken 24.07.83605

En realidad la parte principal del script es un comando docker pasando el accountID y un Delegate Token que montará un nuevo delegate pero ahora, no en kubernetes sino directamente en la máquina principal.

# Código principal del script ejemplo
docker run --cpus=1 --memory=2g \
  -e DELEGATE_NAME=docker-delegate \
  -e NEXT_GEN="true" \
  -e DELEGATE_TYPE="DOCKER" \
  -e ACCOUNT_ID=H5W8iol5TNWc4G9h5A2MXg \
  -e DELEGATE_TOKEN=YOUR_API_TOKEN \
  -e LOG_STREAMING_SERVICE_URL=https://app.harness.io/gratis/log-service/ \
  -e DELEGATE_TAGS="windows-amd64" \
  -e RUNNER_URL=http://WINDOWS_MACHINE_HOSTNAME_OR_IP:3000 \
  -e MANAGER_HOST_AND_PORT=https://app.harness.io/gratis harness/delegate:23.02.78306

Una cosa muy importante es recordar que estamos creando estos delegates (runners) para la cuenta entera, pero podría ser creado por org o proyecto así como varios otros recursos. En este caso, cualquier otro proyecto podría usar este mismo delegate.

¿Será que este delegate crea otro contenedor para ejecutar la tarea siendo solamente un punto de entrada o es de hecho el runner? Vamos a descubrir pronto.

Puedes crear más tokens en lugar de usar siempre el predeterminado.

delegateToken

alt text

Aplicación

Vamos a utilizar una aplicación ejemplo hecha en golang. Haz el fork de este proyecto para algún repositorio git que uses y esté disponible en Harness.

alt text

Observa que ya encontró la carpeta .harness/pipelines donde tenemos nuestro yaml.

alt text

Tomando el yaml que define el pipeline en este repositorio, creó un pipeline en el proyecto dentro de la plataforma de Harness, pero no modificó el pipeline que está definido en el repositorio.

¿Si modificamos el pipeline en el repositorio se reflejará en Harness? ¿Si modificamos en Harness hará commit en el repo? Sí, lo hará si le permites.

Nos mostrará de forma visual lo que está en el yaml y necesitamos completar algunos detalles para que el pipeline funcione pues si observas bien en el código tendremos algunas cosas parecidas al código abajo.

# Fragmento sacado del pipeline
              - step:
                  type: BuildAndPushDockerRegistry
                  name: Build And Push Docker Registry
                  identifier: Build_And_Push_Docker_Registry
                  spec:
                    connectorRef: <+input> # Será necesario poner en el momento del run
                    repo: <+input> # Será necesario poner en el momento del run
                    tags:
                      - latest

Si fuera definido de forma fija no aparecerían todos los inputs, pero como es un ejemplo y necesita servir para todos así fue hecho.

Si mandamos ejecutar el pipeline directamente algunos detalles serán pedidos como input.

alt text

Aplicación​

Aplicación