| Bellacosa Mainframe apresenta o Ansible |
☕ O Holocron do Ansible
Como um Padawan COBOL Pode Descobrir que Existe uma Forma de Administrar Milhares de Servidores sem Escrever um JCL para Cada Um Deles
Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma verdade desconfortável.
Os servidores estão se multiplicando.
Primeiro era apenas um LPAR.
Depois vieram dois ambientes.
DEV.
QA.
HML.
PRD.
DR.
Cloud.
Linux.
Windows.
Containers.
OpenShift.
Z/Linux.
zCX.
z/OS Connect.
MQ.
CICS.
DB2.
E de repente alguém faz uma pergunta aparentemente simples.
— Bellacosa... como atualizamos 800 servidores?
O Padawan pensa.
"Talvez um REXX."
"Talvez um script."
"Talvez um FTP."
"Talvez um JCL."
O Sysprog veterano apenas sorri.
Abre uma caneca de café.
E responde:
— Existe uma ferramenta chamada Ansible.
E ela parece magia.
Mas não é magia.
É apenas automação feita direito.
O que é o Ansible?
Ansible é uma plataforma de automação Open Source criada para executar tarefas administrativas em múltiplos sistemas de maneira centralizada.
Seu objetivo é simples:
Fazer uma única ação e replicá-la em centenas ou milhares de máquinas.
Por exemplo:
Instalar software.
Criar usuários.
Alterar permissões.
Subir serviços.
Executar scripts.
Aplicar patches.
Configurar firewalls.
Gerenciar cloud.
Criar containers.
Automatizar IBM Z.
Em outras palavras:
"Ansible é o equivalente moderno do JCL PROC para infraestrutura."
Se você já executou:
//STEP1 EXEC PROC=COBOLCOMP
Você já entendeu metade da filosofia do Ansible.
Origem do Ansible
O Ansible nasceu em 2012.
Criador:
Michael DeHaan.
O mesmo desenvolvedor que participou do projeto Cobbler.
A ideia era resolver problemas encontrados em ferramentas da época.
Chef
Puppet
CFEngine
Todas eram poderosas.
Mas tinham um problema.
Precisavam instalar agentes.
E agentes são chatos.
Consomem memória.
Precisam atualizar.
Quebram.
Geram vulnerabilidades.
Michael pensou:
"Por que não usar apenas SSH?"
Nascia o Ansible.
Em 2015 a Red Hat comprou a empresa.
Em 2019.
A IBM comprou a Red Hat.
Hoje Ansible faz parte do ecossistema IBM.
Padawan COBOL:
Sim.
Você pode automatizar o mainframe usando uma tecnologia que pertence ao mesmo guarda-chuva corporativo do IBM Z.
Versões
Atualmente temos:
Ansible Community
Open Source
Red Hat Ansible Automation Platform
Comercial
AWX
Projeto upstream
Ansible Navigator
CLI moderna
Automation Hub
Coleções certificadas
EDA
Event Driven Automation
O segredo do Ansible
Ele funciona usando três componentes.
Inventory
Lista de servidores.
hosts.ini
linux01
linux02
linux03
ou
all:
children:
prod:
hosts:
db01:
Playbook
É o JCL do Ansible.
Arquivo YAML.
Exemplo:
---
- hosts: all
tasks:
- name: Criar usuário
user:
name: padawan
state: present
Modules
São programas prontos.
Exemplos.
copy
service
yum
apt
shell
uri
zos_job_submit
zos_copy
zos_data_set
Existem milhares.
Por que YAML?
Porque YAML é legível.
Exemplo.
name: Bellacosa
idade: 52
profissao: Sysprog Jedi
Até um gerente consegue ler.
E isso assusta alguns desenvolvedores.
Instalação
Linux
sudo dnf install ansible
Ubuntu
sudo apt install ansible
Pip
pip install ansible
Verificar
ansible --version
Exemplo.
ansible [core 2.19]
Primeiro laboratório
Arquivo.
inventory.ini
localhost
Playbook.
hello.yml
---
- hosts: localhost
tasks:
- name: Mostrar mensagem
debug:
msg: "Olá Padawan"
Executar.
ansible-playbook hello.yml
Saída.
TASK
Olá Padawan
ok=1
Missão cumprida.
Exemplo real
Instalar Apache.
---
- hosts: webservers
tasks:
- name: Instalar
yum:
name: httpd
state: present
- name: Iniciar
service:
name: httpd
state: started
100 servidores.
1 comando.
Fim.
Ansible no Mainframe
Aqui a coisa fica divertida.
IBM criou a coleção.
IBM Z Ansible Collection.
Módulos.
zos_copy
zos_data_set
zos_job_submit
zos_operator
zos_tso_command
zos_ping
zos_fetch
Criando dataset
- name: criar
zos_data_set:
name: BELLA.TESTE
type: seq
state: present
Submeter JCL
- name: submit
zos_job_submit:
src: teste.jcl
Executar comando
zos_operator:
cmd: D IPLINFO
Casos reais
Deploy COBOL.
Copiar load modules.
Atualizar PROCLIB.
Executar REORG DB2.
Backup VSAM.
Verificar CICS.
Consultar JES2.
Gerenciar USS.
Criar usuários RACF.
Automatizar IPL checks.
Vantagens
Sem agentes
SSH.
WinRM.
z/OS.
Pronto.
Fácil aprender
Muito menos complexo que Puppet.
Reutilização
Roles.
Templates.
Collections.
Infraestrutura como Código
Git.
GitHub.
GitLab.
Azure DevOps.
Auditoria
Tudo fica registrado.
Desvantagens
SSH lento.
Em milhares de máquinas.
YAML depende de espaços.
Erro clássico.
tasks:
-name:
Kaboom.
Debug pode ser difícil.
Curva de aprendizado.
Jinja2.
Templates.
Loops.
Facts.
Truques Jedi
Dry Run
--check
Não altera nada.
Diff
--diff
Mostra mudanças.
Tags
tags:
- db2
Executar.
ansible-playbook play.yml --tags db2
Vault
Senhas criptografadas.
ansible-vault encrypt
Facts
debug:
var=ansible_hostname
Curiosidades
Ansible originalmente usava vacas ASCII.
Existe.
cowsay
Saída.
__________________
< Deploy completo >
------------------
\ ^__^
\ (oo)\_______
Pode trocar por animais.
Dragon.
Tux.
Moose.
Daemon.
Easter Eggs
Execute.
ansible all -m ping
Não é ICMP.
É um módulo.
Resposta.
pong
Outra curiosidade.
Existe um módulo chamado.
debug
Que é provavelmente o módulo mais utilizado do planeta.
Ansible e o Futuro do IBM Z
O IBM Z moderno está cada vez mais próximo das práticas DevOps.
Git.
Pipelines.
OpenShift.
Terraform.
Zowe.
Ansible.
O Sysprog de 2030 provavelmente não ficará digitando comandos repetitivos no SDSF.
Ele terá um repositório Git.
Um pipeline.
Um Playbook.
E um botão chamado:
Deploy em Produção
E talvez seja justamente isso que assuste alguns veteranos.
Porque durante décadas aprendemos que administrar infraestrutura exigia decorar centenas de comandos obscuros.
Ansible propõe outra filosofia.
Descreva o estado desejado.
A ferramenta cuida do restante.
É quase como ensinar um aprendiz Jedi.
Você não diz exatamente como mover cada músculo do braço.
Você apenas diz:
— Pegue o sabre.
E a Força faz o resto.
No universo do IBM Z, Ansible não substitui o conhecimento profundo de JES2, RACF, CICS, DB2 ou z/OS.
Mas permite que um Padawan COBOL transforme esse conhecimento em automação reproduzível, auditável e compartilhável.
E talvez este seja o maior ensinamento do Holocron do Ansible:
"Um Sysprog poderoso não é aquele que executa mil comandos por dia. É aquele que ensina uma máquina a executá-los corretamente para sempre."
Posso também criar a continuação "O Holocron do Ansible para IBM Z – 20 laboratórios práticos para Padawans COBOL", com exercícios usando zos_job_submit, zos_copy, zos_operator, RACF, CICS e DB2.
Sem comentários:
Enviar um comentário