Skip to main content

Sample deployment CI

Para executar os steps de cada dos stages é necessário que tenhamos runners que façam essa tarefa. Podemos utilizar os runners do Harness Cloud validando um cartão de crédito. Uma outra idéia é criar os runners locamente na sua própria máquina para que faça o processamento utilizando container.

Podemos criar os runners no kubernetes como vimos anteriormente no exemplo de CD mas dessa vez vamos para o docker mudando o cenário.

A documentação esta em https://developer.harness.io/docs/continuous-integration/use-ci/set-up-build-infrastructure/define-a-docker-build-infrastructure.

Requisitos:

Vamos criar um connector na account para ter acesso a sua conta do DockerHub. O endereço padrão do DockerHub caso não tenha um personalizado é https://registry.hub.docker.com/v2. Coloque seu usuário e senha para ele se conectar. De um nome fácil para identificar. Documentação Docker Connector.

alt text

alt text

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

Na verdade a parte principal do script é um comando docker passando o accountID e um Delegate Token que montará um novo delegate porém agora, não no kubernetes e sim direto na máquina principal.

# Código principal do script exemplo
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

Uma coisa muito importante é lembrar que estamos criando esses delegate (runner) para a conta inteira, mas poderia ser criado por org ou projeto assim como vários outros recursos. Nesse caso, qualquer outro projeto poderia usar esse mesmo delegate.

Será que este delegate cria outro container para executar a tarefa sendo somente um ponto de entrada ou ele é de fato o runner? Vamos descobrir jájá.

Você pode criar mais tokens ao invés de usar sempre o default.

delegateToken

alt text

Aplicação​

Vamos utilizar uma aplicação exemplo feita em golang. Faça o fork deste projeto para a sua algum repositório git que você use e esteja disponível no Harness.

alt text

Observe que ele já encontrou a pasta .harness/pipelines que temos o nosso yaml.

alt text

Pegando o yaml que define o pipeline neste repositório, ele criou um pipeline no projeto dentro da plataform do Harness, mas não alterou o pipeline que esta definido no repositório.

Se alterarmos o pipeline no repositório refletirá no Harness? Se alterarmos no Harness comitará no repo? Sim ele fará se você permitir.

Ele mostrará para nós de forma visual o que esta no yaml e precisamos completar alguns detalhes para que o pipeline funcione pois se observar bem no código teremos algumas coisas parecida com o codigo abaixo.

# Trecho retirado do pipeline
              - step:
                  type: BuildAndPushDockerRegistry
                  name: Build And Push Docker Registry
                  identifier: Build_And_Push_Docker_Registry
                  spec:
                    connectorRef: <+input> # Será necessário colocar na hora do run
                    repo: <+input> # Será necessário colocar na hora do run
                    tags:
                      - latest

Se for definido de forma fixa não apareceria todos os inputs, mas como é um exemplo e precisa servir para todos assim foi feito.

Se mandarmos executar o pipeline diretamente alguns detalhes serão pedidos como input.

alt text

alt text