ANSIBLE SERIES: YML … ask before run >> tower/awx “survey”
BOOOOO!!!! 👻 Um Feliz Dia das Bruxas pra você também RSRS ( … ) Logo mais, um sucessor espiritual do último capítulo 😁 Ou somente a “PARTE 02”, caso goste de simplificar. Fique comigo, e embarque nesse NOVO POST do blog @machinesbecomeservices
Pré-requisitos: yet another method to linux
Sim, isso mesmo. Não, você não leu errado. Esse será apenas mais um método dentre tantos outros para instalar, configurar e preparar o Linux para efeitos de estudo. Na infraestrutura, isso é o que chamamos de provisionamento. Para saber mais, leia este artigo que escrevi há algum tempo (https://machinesbecomeservices.com/2021/01/22/ansible-series-teoria-5-v-conceitos-fundamentais/)
Agora ao que importa … Para fins didáticos e nivelamento vou pressupor duas coisas aqui hoje: primeiro que o leitor caiu de paraquedas (ou seja, ainda não possui nenhum ambiente configurado) e segundo que o mesmo usa Windows como sistema principal. Então, sendo assim, recomendo que baixe e instale os seguintes programas:
- VirtualBox (https://www.virtualbox.org/)
- Vagrant (https://www.vagrantup.com/)
- Git for Windows (https://git-scm.com/)
NEXT, NEXT, NEXT, FINISH e reiniciar o computador … Nada demais, apenas o bom e velho padrão “windows” 😉
Vagrant: Automatizando Máquinas Virtuais
Automatizar é preciso, viver não é preciso (ABREU, vicrlda. 2021) Ops! Não, não. Quis dizer, Fernando Pessoa. Escritor e Poeta. Lusitano com obras destacadas no início do século XX.
Depois de reiniciada a máquina, verifique se o vagrant foi instalado corretamente e se o sistema consegue executá-lo como qualquer software habitual:
cmd.exe
vagrant version

Sucesso absoluto! Vamos a próxima etapa, trocando a localização atual (C:\) por outra partição que não seja a do próprio sistema. Isso garante que nenhum de nós, e tão pouco o Vagrant, faça besteira ou bagunce arquivos e pastas do Windows. No caso, mudarei para o driver G: do computador, que na verdade é o padrão do meu Google ONE (R.I.P. GoogleDrive) instalado localmente, e definido durante a configuração dele. Sinta-se livre para fazer igual ou até mesmo criar uma nova partição do zero, por exemplo, (D:\) (E:\) (X:\) (Y:\) (Z:\) Lembrete: antes faça backup dos seus arquivos pois nunca se sabe 🙃 Não importa quanta experiência você tenha! Ok?

Note que caso opte pelo Google ONE (G:\) a aplicação não permite adicionar nada na raiz do diretório, tendo que criar um nível abaixo.
MKDIR "MEU DIRVE"\NOME_PASTA
CD "MEU DRIVE"\NOME_PASTA
Paralelamente ao GNOME Boxes, VirtualBox, VMware, e afins, precisamos de uma imagem para instanciar a VM em questão. Graças a HashiCorp, empresa por trás e detentora do projeto VAGRANT, isso está a poucos cliques de distância. Basta acessar a Vagrant Cloud (https://app.vagrantup.com/boxes/search) e pesquisar o nome da distro/app/database:

Escolhida a BOX e sua versão, hora de inicializá-la via comando:
vagrant init centos/7
dir

Se for de sua preferência, visualize o arquivo antes de prosseguir, dessa forma irá se acostumando com a linguagem da ferramenta e as particularidades:

Tudo pronto! Agora sim, vamos subir a máquina e dar BOOT:
vagrant up


Observe se algo está realmente rodando:
vagrant status

E melhor ainda, veja que o START já foi dado no VirtualBox. Automaticamente, sem nenhuma intervenção humana, a VM está executando e pronta para uso 🙂

Vagrant: Configurando SSH e o PuTTY
Uma rede de computadores é caracterizada pela conexão entre diferentes máquinas. Isso vai desde as grandes redes (ex: a Internet) até as mais singelas (ex: LAN com duas máquinas e um cabo crossover). Administradores Windows utilizam bastante o RDP (Remote Desktop Protocol), seja para acessar nós clientes (Win7, 8, 10, 11) ou nós servidores (WinR2 2008, 2012, 2016, 2019). Já no mundo Linux o SSH é indiscutivelmente o padrão. Portanto, não é surpresa pra ninguém que gerenciá-lo faz parte do nosso trabalho (o time dos sysadmins,devops e SREs). Então, mãos à obra!
Começando com o básico, que é um comando embutido no próprio vagrant, o vagrant ssh


Percebam que o método pré-definido é a autenticação por chave privada (SSH-key). Graças ao trabalho de automação do VAGRANT não precisei digitar uma senha correspondente, pois o par de chaves está armazenada na VM e estamos acessando localmente do nosso computador (S.O. Windows)
Mas, e se um colega desenvolvedor precisa acessar também a máquina virtual? Ou melhor, se a VM foi criada na estação de trabalho da empresa e você está homeoffice? Como faria? É uma boa pergunta!
Primeiramente, aos que não conseguiram rodar o comando SSH, a razão talvez seja: uma versão obsoleta do Windows (7, 8, 8.1, XP, etc) que não tem instalado o cliente ou no caso do Windows 10 verifique se o mesmo está habilitado. Vá nas configurações > aplicativos > aplicativos e recursos > gerenciar recursos opcionais > cliente openssh
Se mesmo assim, os problemas persistirem, usaremos então duas ferramentas para contornar: o GIT BASH e o PuTTY. Baixe e instale ambos através dos links presentes na subseção pré-requisitos ☝ Com o git bash podemos dar comandos ao Windows como se estivéssemos no Linux. Por exemplo, ao invés de DIR para listar o conteúdo de uma pasta, digite LS e pronto. Feito!

Por questões de mera padronização, para que todos acompanhem valendo-se das mesmas coisas, a partir de agora, utilizarei somente ele para qualquer necessidade via terminal, deixando o prompt (cmd.exe) de lado e como última opção.

Quanto ao PuTTY, antes de testá-lo precisamos antes saber quais configurações a VM usa, especificamente o VAGRANT. Portanto execute vagrant ssh-config

Muita atenção aos detalhes! O endereço da máquina (ou hostname) é o 127.0.0.1/localhost. Ok, nada mais lógico correto? Afinal estamos hospedando no próprio computador e por isso ele deve olhar para si mesmo. Porém, a porta 22 padrão do SSH foi modificada para 2222. E por que? Bem, para fazer o que chamamos de port forwarding (encaminhamento de porta, em português). Isso permite ter várias máquinas rodando localmente, compartilhando recursos e hardware do hospedeiro, mas escutando e consequentemente funcionando em portas distintas. Do contrário, todas estariam na 22 e o Windows não saberia para qual encaminhar a requisição e demais pacotes do tráfego de rede.
Siga em frente e copie essas informações para o PuTTY. Ao final clique em OPEN:

Informe o usuário e a senha. Tudo minúsculo, vagrant/vagrant, respectivamente:

ACCEPT para continuar e adicionar a chave no registro. Não é perguntado novamente nas próximas tentativas.

Calma! Vamos aos poucos, cada parte por vez 😣 Lembra daquele colega de trabalho que também necessita entrar na máquina para contribuir com o projeto? Pois é, ele mesmo. Isso é a tela que ele vai se deparar quando tentar, caso você não repasse a chave. E mais, a chave “formatada” corretamente para o PuTTY. Não é qualquer uma não viu? Bom, para isso abra o gerador de chaves do PuTTY, identificado como PuTTYgen e clique em LOAD para carregar a chave privada que já existe no computador:

Navegue até o caminho do armazenamento, selecione ALL FILES(*.*), clique em OPEN, e depois SAVE private key


Quando perguntado se deseja salvar sem uma senha, por favor, diga sim. A praticidade e a agilidade de deixá-la em branco você entenderá mais tarde.


Um bom hábito a cultivar é validar tudo o que fazemos na vida, então confirme entrando na pasta e listando seu conteúdo:

Retorne ao PuTTY e insira novamente os dados mas não se preocupe, dessa vez iremos salvar. Só que antes adicione mais algumas informações importantes a sessão. Lado direito > CONNECTION > Data > Auto-login username > vagrant

A seguir, permanecendo em CONNECTION, expanda o menu SSH dando um clique no + e depois em Auth, e finalmente Browser

Salve a sessão com as configurações, e TAA-DAAAAAA 🤡


LAB (( pt.I )) nodeA RHEL-like nodeB DEBIAN-like
Parece uma eternidade, eu sei. Não vou mentir 🙁 Devo isso a cada um de vocês … Mas, se serve de consolo, estamos mais perto do que longe. A brincadeira aproxima-se do fim e a melhor parte chegou. Não esqueçam jamais nosso objetivo base, traduzido na prática como a ideia por trás do Ansible: gerenciar, orquestrar nós e hosts que estão do outro lado da conexão, na ponta diametralmente oposta. Combinados? Então sigam-me, por gentileza!
Acesse a pasta do vagrant usando o Windows Explorer e, renomeie para algo como ‘centos’ ou ‘centos7’. Queremos tornar mais fácil a sua identificação pois vem aí mais duas máquinas virtuais, que farão o papel de servidores remotos. Quando terminar, volte ao git BASH para iniciar o processo baixando os arquivos referentes às boxes, versão 21.04 do Ubuntu e o Centos 8, disponíveis na Vagrant Cloud.
vagrant init generic/ubuntu2104
vagrant init generic/centos8
vagrant up
vagrant status

Abrir o arquivo Vagrantfile para acrescentar uma configuração específica de rede. Tal instrução é para que a VM solicite IP no DHCP da rede doméstica/corporativa. Do contrário ela acabará pegando via DHCP interno, o que gera isolamento e visibilidade limitada ao Virtualbox, alcançando no máximo outros sistemas convidados rodando localmente. Saiba mais em https://www.vagrantup.com/docs/networking/public_network

Caso dê o START antes dessa pequena adição no código, será preciso parar e iniciar novamente a máquina. Escolha uma das três opções:
vagrant halt / vagrant up
vagrant reload
vagrant destroy / vagrant up

Entre nas máquinas para ver qual IP foi alocado respectivamente. Sem ele não somos capazes de adicioná-las no AWX, tão pouco realizar o teste mais básico: o ping.

LAB (( pt.II )) AWX quick-install CONTROLLER centos7
Desabilitar SELinux:
systemctl stop firewalld systemctl disable firewalld
Habilitar repositório epel:
yum install -y epel-release
Instalar pacotes necessários:
yum install -y yum-utils device-mapper-persistent-data lvm2 ansible git python-devel python-pip python-docker-py vim-enhanced
Configurar repositório stable do Docker e instalá-lo:
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install docker-ce -y yum install docker-compose
Iniciar serviço:
systemctl start docker systemctl enable docker
Clonar repositório AWX:
git clone -b 17.1.0 https://github.com/ansible/awx.git
Entrar na pasta de instalação:
cd awx/installer/
Ajustar o inventory:
vim inventory
Executar playbook da instalação:
ansible-playbook -i inventory install.yml



http://sidneiweber.com.br/instalar-ansible-awx-com-docker-no-centos-7/
https://www.vivaolinux.com.br/artigo/Ansible-AWX
LAB (( pt.III )) AWX web-configs SETUP inventory, credential, project, template
Para ganho de tempo e otimização, editarei as configurações padrão para se rodar um playbook no AWX. Elas são criadas pelo sistema durante o processo de instalação. Grande parte, senão todas, são nomeadas e estão identificadas como DEMO “alguma coisa”. Por exemplo: demo inventory, demo credential, demo project, etc. Ressaltando apenas que é viável sim adicionar suas próprias configurações. Aliás, não só possível como extremamente recomendado em casos de dois ou mais ambientes (DEV, HMLG, PROD) … várias equipes, inventários separados, projetos simultâneos, e assim por diante.
Ah, e se por acaso tiver um Deja Vu, talvez seja porque o caro leitor já leu meus outros artigos no passado, onde abordo tais configurações com mais atenção e riqueza de detalhes. É fácil encontrá-los, ou até mesmo revê-los, basta procurar aqui no BLOG 😉





LAB (( final )) SURVEY: Prompt questions … Data to add: LOGIN & PASSWORD
Já vimos que é o AWX é capaz de executar códigos hospedados na nuvem, não importando qual solução escolhida para tal fim: Git, GitHub, GitLab. Basta referenciar o link do repositório na aba PROJECTS, selecionar o playbook no menu TEMPLATES, e clicar em LAUNCH para a mágica acontecer. Bom, e se por algum motivo você não utiliza ferramentas de controle de versão para gerenciar códigos? E se por questões legais a empresa em que trabalha retém os dados gerados e propriedades concebidas fisicamente? E se porventura numa bela manhã ensolarada o link de internet cair, e aquela importante rotina que restaura o backup (script-shell, yaml file, etc) ficar inacessível? E se você, como eu 😁, é um sujeito simples e tudo o quer na vida é testar seus projetos localmente? Bem, para todas essas a resposta é um campo chamado Source Control Credential Type
Talvez passado despercebido, talvez não, o fato é que uma vez selecionado como Manual, o mesmo irá abrir mais dois subcampos. São eles: Project Base Path
e Playbook Directory

A lógica aqui é criar uma pasta por vez e separar cada um dos projetos, escolhendo somente aquela que lhe interessa no momento, para então executar o playbook contido ali. Caso tente acessar essa pasta padrão na própria VM centos7 muito provável que não encontre nada. Isso porque o AWX está rodando via Docker … Lembra? Então, precisaremos acessar o container encarregado, neste caso sendo o AWX_TASK.
sudo docker ps
sudo docker exec -it awx_task /bin/bash
pwd
cd /var/lib/awx/projects/
pwd
ls -l

mkdir add-sudo-survey-username-passwd_project
ls -l
cd add-sudo-survey-username-passwd_project/
touch add-sudo-debian-rhel.yml
ls -l

vi add-sudo-debian-rhel.yml
https://github.com/vicrlda/awx-tower/blob/main/playbooks/add-sudo-debian-rhel.yml
exit
sudo docker restart awx_task









REFERÊNCIAS:
https://www.unixarena.com/2018/10/ansible-how-to-install-and-configure-awx.html/
https://www.unixarena.com/2018/11/ansible-tower-awx-how-to-create-manual-scm-project.html/
https://github.com/ansible/awx/issues/1948
https://support.websoft9.com/docs/awx/admin-services.html#docker-compose
[…] https://automatesmachines.org/2021/11/02/ansible-series-yml-ask-before-run-awx-e-o-recurso-survey/ […]