Ansible na Prática #7 – playbook com módulos YUM e APT

Ansible na prática #8  - TAGS
Por:  Adelmo da Silva – consultor de sistemas

Uma das principais responsabilidades de um profissional de T.I é manter os ambientes actualizados e/ou instalar novos recursos para que tudo funcione perfeitamente. Isso permite que ambientes de desenvolvimento, homologação e produção estejam com os mesmos pacotes e nas mesmas versões de sistemas operacionais para que os produtos criados sejam da mais alta qualidade.

Agora, imagine este cenário:

Ansible na Prática #7 - Playbook com Módulos YUM e APT

Neste exemplo temos 3 ambientes: DESENVOLVIMENTO, HOMOLOGAÇÃO e PRODUÇÃO. Cada um com os seus respectivos servidores. Claro que, normalmente, o ambiente de produção possui maior robustez de recursos. Mas isso não é motivo para deixarmos os outros dois de lado. Inclusive, este é um dos principais problemas na área de desenvolvimento: a diferença entre ambientes e que geralmente ocasiona quebra de pacotes quando implantados de um ambiente para outro.

new_cognito

Tendo em vista a imagem anterior, o nosso inventário no Ansible ficaria assim:

[db]

192.168.50.10 # Desenvolvimento de banco de dados

192.168.60.5 # DB Homólogo

new_cognito

192.168.70.22 # # DB Prod

[balanceador de carga]

192.168.50.1#LB Dev

192.168.60.2 #LB Homólogo

new_cognito

192.168.70.1##LB Prod

[aplicativo]

192.168.50.[20-21] #Desenvolvedor de APP

192.168.60.[30-32] # APP Homólogo

new_cognito

192.168.70.[50-54] # APP Prod

Bem, estabelecidos os nossos ambientes, continuemos.

Podem existir versões diferentes de pacotes, bibliotecas, sistemas operacionais entre os ambientes, o que pode resultar na “quebra” do pacote, ou pacotes, que será implantado.

Em nosso exemplo, temos 17 servidores no total entre os ambientes, divididos entre servidores de aplicação, banco de dados, de webservices, entre outros. Se fossemos actualizar um por um, seria uma tarefa demorada e repetitiva. Ainda bem que temos o nosso Ansible para isso.

new_cognito

Playbook e comandos Ad-Hoc com os Módulos APT e YUM

Existem duas formas que podemos utilizar no Ansible em uma tarefa como esta: Playbooks e Comandos Ad-Hoc. Já expliquei em artigos anteriores o que são. Contudo, o que quero mostrar neste artigo é, especificamente, como utilizar os módulos YUM e APT, que são os mais conhecidos dentre as distros Linux das famílias Red Hat e Debian.

Estrutura dos módulos YUM e APT via comandos Ad-Hoc

Comandos ad hoc

Como já demonstrei em artigos anteriores, a estrutura de um comando ad-hoc básico é:

new_cognito

ansible <grupo ou host> -m <módulo> -a “argumentos/parâmetros do módulo”

No caso dos módulos de gerenciamento de pacotes devemos passar os argumentos ‘name’ que é o nome do pacote e ‘state’ que é o estado do pacote (latest = última versão, present = apenas instalação e absent = remoção). Estes dois argumentos já são suficientes para a instalação e/ou actualização de qualquer pacote. Em nossos ambientes o servidor Nginx será instalado em um CentOS, que pertence à família Red Hat. Portanto, utiliza o gerenciador YUM:

ansible webservices -m yum -a “nome=estado nginx=presente

Com esse comando ad-hoc o pacote Nginx será instalado. O comando acima pode ser utilizado tanto para o gerenciador YUM quanto para o APT.

new_cognito

Lembrando sempre de uma coisa extremamente importante: existem nomes diferentes do mesmo serviço/aplicação entre nas famílias Linux. Por exemplo, o serviço apache. Com o Yum utilizamos o nome de pacote HTTPD. Já no APT, utilizamos APACHE2.

E se precisássemos actualizar o ambiente como um todo, como seria feito? Vamos actualizar todos os servidores CentOS-APP de uma vez em todos os ambientes para que não aconteça quebra de pacotes e bibliotecas no uso dos Apps desenvolvidos. Para isso, utilizaremos o comando:

aplicativo ansible -m yum -a “nome=* estado=mais recente

Veja que utilizamos um “*” para definirmos todos os pacotes. Desta forma, será executado um yum update ao invés de um yum install para todos os servidores do grupo APP.

Outro parâmetro que podemos utilizar para que o comando ad-hoc seja mais efectivo é o update_cache. Este parâmetro executa um equivalente ao apt/yum update antes do comando principal. É usado para especificar se o cache do gerenciador de pacotes YUM/APT deve ser actualizado antes de executar as operações de instalação ou remoção de pacotes.

new_cognito

Neste caso, nosso comando completo será:

aplicativo ansible -m yum -a “nome=* estado=última atualização_cache=yes

Mais uma vez, o mesmo vale para o módulo APT.

Após isso, todos os servers do grupo APP estarão actualizados para que nenhuma aplicação “quebre” ao ser implantada.

new_cognito

É um manual?

 

– anfitriões: aplicativo

  reunir_fatcs: sim

  usuário_remoto: root

new_cognito

  tornar-se: sim

 

  tarefas:

    name: Atualizando CentOS do grupo APP

new_cognito

    hum:

         nome: *

         estado: mais recente

         update_cache: sim

new_cognito

Pronto! Agora só salvar como um nome sugestivo, como por exemplo, update_system. yaml, e rodar com o comando:

ansible-playbook update_system.yaml

Por meio destas duas formas você terá seus ambientes atualizados e um tempo para tomar aquele cafezinho!

Até o próximo artigo…

new_cognito

Já assistiu aos nossos vídeos no YouTube? Inscreva-se no nosso canal clicando aqui  !!!

Partilhar artigo:

Versao3 - Cópia

Somos um portal de notícias, voltado às tecnologias de informação e inovação tecnológica. Informamos com Rigor, Objectividade e Imparcialidade. Primamos pela qualidade, oferecendo aos nossos leitores, a inclusão tecnológica e a literacia digital

+(244) 930747817

info@pti.ao | redaccao@pti.ao

Mais Lidas

Últimos Artigos

Desenvolvido Por SP Media