Skip to content

Victor Ricardo

infraascode

  • HOME
  • CONTATO
  • SOBRE
  • CATEGORIAS
    • Ansible
    • AWS
    • Blog
    • CentOS/RHEL
    • Docker
    • Kubernetes
    • OTOBO
    • OTRS
    • Terraform
    • TOPIC Out-of-the-box
    • Victor
    • Zabbix

ANSIBLE SERIES: YML … ask before run >> tower/awx “survey”

Ansible
Victor Ricardo in 02 nov 2021

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
Figura 01. 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?

Figura 02. mkdir

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:

Figura 03. vagrant cloud

Escolhida a BOX e sua versão, hora de inicializá-la via comando:

vagrant init centos/7
dir
Figura 04. 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:

Figura 05. Vagrantfile

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

vagrant up
Figura 06. vagrant up
Figura 07. vagrant up

Observe se algo está realmente rodando:

vagrant status
Figura 08. 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 🙂

Figura 09. virtualbox

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

Figura 10. vagrant up
Figura 11. 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!

Figura 12. git bash

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.

Figura 13. git bash

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

Figura 14. 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:

Figura 15. PuTTY configuration

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

Figura 16. alerta de segurança especificando qual chave será conectada

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

Figura 17. PasswordAuthetication no

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:

Figura 18. PuTTYgen

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

Figura 19. G:\Meu Drive\Vagrant\DEV\.vagrant\machines\default\virtualbox
Figura 20. 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.

Figura 21. passphrase
Figura 22. centos7-key

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

Figura 23. centos7-key

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

Figura 24. auto-login username

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

Figura 25. SSH Auth

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

Figura 26. save and open
Figura 27. auto-logon vagrant key

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
Figura 28. vagrant init generic/ubuntu2104

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

Figura 29. config.vm.network “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
Figura 30. adapter 2: bridged

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.

Figura 31. eth1

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
Figura 32. end of running
Figura 33. usr: admin / pass: password
Figura 34. home page

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 😉

Figura 35. demo inventory
Figura 36. demo credential
Figura 37. demo project
Figura 38. demo template
Figura 39. demo running

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

Figura 40. /var/lib/awx/projects

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
Figura 41. awx_task container
mkdir add-sudo-survey-username-passwd_project
ls -l
cd add-sudo-survey-username-passwd_project/
touch add-sudo-debian-rhel.yml
ls -l
Figura 42. mkdir
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
Figura 43. manual project
Figura 44. manual template
Figura 45. details > survey
Figura 46. add question
Figura 47. preview
Figura 48. pre launch
Figura 49. prompts
Figura 50. launch
Figura 51. the end 🙄

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

Compartilhe isso:

  • Facebook
  • 18+

Curtir isso:

Curtir Carregando...

Relacionado

Short URL https://vicrlda.com.br/?p=2359
Tagsansible-coreansible-playbookcentos7debian-likeinfraascodemgmtconfignodespiprhel-likerootsudotasksubuntuuseraddyaml

1 Comment

  1. ANSIBLE SERIES: YML … shutting down an employee >> removing linux credentials – Automates Machines .ORG disse:
    20 de fevereiro de 2022 às 12:16

    […] https://automatesmachines.org/2021/11/02/ansible-series-yml-ask-before-run-awx-e-o-recurso-survey/ […]

    Carregando...
    Responder

Deixe uma respostaCancelar resposta

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.

← Previous Post Next Post →

Search

Recent Posts

  • OTOBO SERIES: TEORIA … Um Fork do OTRS
    OTOBO SERIES: TEORIA … Um Fork do OTRS
     28 de setembro de 2023 Nenhum comentário
  • KUBERNETES SERIES: LAB … O primeiro POD
    KUBERNETES SERIES: LAB … O primeiro POD
     11 de julho de 2023 Nenhum comentário
  • KUBERNETES SERIES: LAB … Downloading on Linux: Minikube
    KUBERNETES SERIES: LAB … Downloading on Linux: Minikube
     6 de abril de 2023 Nenhum comentário
  • KUBERNETES SERIES: Clusters, História e Terminologia
    KUBERNETES SERIES: Clusters, História e Terminologia
     20 de março de 2023 1 comentário
  • DOCKER SERIES: Final … COMPOSE: Multicontainers
    DOCKER SERIES: Final … COMPOSE: Multicontainers
     2 de março de 2023 Nenhum comentário

Categories

  • Ansible
  • AWS
  • Docker
  • Terraform
  • OTRS
  • Victor
  • Zabbix
  • Kubernetes
  • CentOS/RHEL
  • Blog
  • OTOBO
  • TOPIC Out-of-the-box

© 2020-2025 Victor Ricardo

Powered by WordPress Whiteboard Theme

↑
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
Do not sell my personal information.
Cookie SettingsAccept
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Sempre ativado
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
CookieDuraçãoDescrição
cookielawinfo-checkbox-analytics11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytics
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Others
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
SALVAR E ACEITAR
Desenvolvido por CookieYes Logo
 

Carregando comentários...
 

    %d