IaC na Azure [3/X] – Instalando e Configurando a VM agente

Agora que já temos nossa VM no ar, podemos fazer a instalação do Ansible e do Azure Agent para integrar as execuções na nossas futuras pipelines do Azure DevOps.

Começamos com o acesso SSH no nosso servidor (vide post anterior), viramos root e fazemos o upgrade.

sudo apt update && sudo apt upgrade && sudo apt autoremove

Eu gosto de sempre fazer um reboot, depois do upgrade. Principalmente de se teve atualização de Kernel.

Montando a partição do Agent

Para não concorrer com o espaço do SO e “travar” a maquina por causa dos logs e dados de execução do Azure Agent, nos já deixamos um disco criado na construção da nossa VM.

Esse parâmetro aqui:

--data-disk-sizes-gb 4

Se você não fez a criação por CLI, ou já tem uma VM, basta monta um novo disco dentro dela.

Quando o disco estiver “montado”, você vai precisar localiza-lo dentro da VM, temos um post explicando como fazer isso: http://3.139.95.241/2021/04/12/como-identificar-os-disco-da-azure-no-linux/

Outro material de referência: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/attach-disk-portal

Com o disco localizado, no meu caso o disco é o sdb, podemos fazer o comandos:

sudo parted /dev/sdb --script mklabel gpt mkpart ext4part ext4 0% 100%
sudo mkfs.ext4 /dev/sdb1
sudo partprobe /dev/sdb1

Desta forma criando a partição primaria do disco.

Disco formatado e particionando

Agora, precisamos localizar o UUID dessa partição, com o comando:

sudo blkid
Lista dos UUIDs dos discos

Definimos o diretório do ponto de montagem e cria-lo com o comando:

sudo mkdir -p /azure/agent

E agora fazer a configuração do arquivo “/etc/fstab” com o comando:

sudo bash -c 'echo "UUID=d0143a3c-1c91-42e6-8221-06c726340fbd /azure/agent ext4 defaults,noatime 0 2" >> /etc/fstab'

O “/etc/fstab” é responsável em remontar o disco depois de um reboot.

Solicitamos a montagem da partição:

sudo mount -a

E verificar que elas se encontra montada:

df -h
Comando df, mostrando a partição montada

Para garantir que tudo esta certo, nada melhor que um reboot no servidor e ver se ele montou sozinho novamente a nossa partição.

Criando um usuário não privilegiado na nossa VM Linux

Como boa pratica de segurança, recomenda-se não usar o root para executar qualquer “programa” dentro da sua maquina. E um agente de tarefas não seria diferente, então devemos criar um usuário para isso.

sudo groupadd -g 757 azagent
sudo useradd -u 757 -g azagent -m -d /home/azagent azagent

Eu escolhi os GIDs e UIDs 757 por ser algo acima de 500 e abaixo de 1000. Qualquer dia, posso escrever sobre a minha metodologia para criação de usuários.

Instalando o Azure Agent

Agora podemos iniciar a instalação do Agent Pool do DevOps. Existe essa documentação oficial sobre como fazer:

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops#download-and-configure-the-agent

Mas vou fazer as minhas adaptações para os pontos que acredito não estarem cobertos na documentação. Siga por sua conta e risco. (Brincadeira, nem muda tanto assim)

Começando, por onde fazer o download. A documentação oficial, da uma baita volta. Mais fácil, pegar o link de download aqui:

https://github.com/microsoft/azure-pipelines-agent/releases

No meu caso, a versão corrente é a V2.185.0, então uso curl:

sudo curl https://vstsagentpackage.azureedge.net/agent/2.185.0/vsts-agent-linux-x64-2.185.0.tar.gz --output /tmp/vsts-agent-linux-x64-2.185.0.tar.gz

Depois do download concluído, precisamos descompactar o arquivo. A versão que estou usando, não cria um diretório de saída com o conteúdo, deixando no diretório corrente tudo o que é extraído, por isso, vou usar o -C para indicar a saída.

sudo mkdir -p /azure/agent/vsts-agent
sudo tar -vxzpf /tmp/vsts-agent-linux-x64-2.185.0.tar.gz -C /azure/agent/vsts-agent

Vamos instalar as dependências que o agente precisa.

sudo /azure/agent/vsts-agent/bin/installdependencies.sh

Mudamos o diretório e o seu conteúdo para a permissão do usuário que criamos.

sudo chown -R azagent: /azure/agent/vsts-agent

Criando o Agent Pool no Azure DevOps

Antes de concluir a configuração do agente na VM, precisamos criar na Azure DevOps o pool que este agente vai ingressar.

Acesse a url do Azure DevOps: https://dev.azure.com/

No rodapé, tem a opção de configurações:

Choose Organization settings.

Depois você encontra Agent Pools:

Choose Agent pools tab.

Escolha a opção para criar um novo pool

Defina ele como self-hosted e escolha um nome. No meu caso, como estou montando esse pool para ser temporário, até eu não precisar mais ficar “trancado para fora”, não precisa ter um nome “definitivo”.

Aproveita e já pega seu token PAT, indo em Personal access token:

Go to your security details.

Depois em novo token:

Create a personal access token.

Pode criar um token como “Full access”, porque depois de ingressar o agente, você pode remove o token.

Com tudo isso em mãos, podemos configura o agente.

Iniciando a configuração do agente

Voltando para o terminal da VM, vamos mudar para o usuário não privilegiado e executar a configuração a partir dele.

sudo su - azagent
cd /azure/agent/vsts-agent/

comando para configuração do agente.

./config.sh

Depois de aceitar as licença ele ira pedir a sua url do Azure DevOps e o token PAT. Esse token precisa ser de um usuário que tenha permissão de gerenciar os agentes, server só para ingressar um novo agente. Aqui tem mais informações:

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops#permissions

Quando finalizado o processo, no Azure DevOps, o agente vai aparece no seu pool:

Podemos sair da sessão no terminal com o usuário não privilegiado (azagent) e voltar para nosso usuário padrão.

Agora, basta rodar o comando que cadastro do agente como serviço do Linux para que quando o servidor seja reiniciado, tudo volte ao normal.

sudo /azure/agent/vsts-agent/svc.sh install azagent

Para ligar o agente a primeira vez:

sudo /azure/agent/vsts-agent/svc.sh start
sudo /azure/agent/vsts-agent/svc.sh status

Esse foi o material para conseguir colocar um VM capas de rodar nossas primeiras pipelines. Agora, podemos realmente começar com o IaC e no futuro, trocar essa VM por outra já construida pelo próprio IaC. No fim, pra garantir: sudo reboot. 🙂