 |
| Bellacosa Mainframe apresenta ansible para mainframers |
☕ Um Café no Bellacosa Mainframe
Ansible for IBM Z & LinuxONE Foundations
Quando um Programador COBOL Descobre que Também Pode Automatizar o Mainframe
"Durante décadas, os profissionais de Mainframe aprenderam que havia uma maneira 'correta' de administrar um ambiente IBM Z: abrir uma sessão TSO, navegar pelo ISPF, editar datasets, submeter JCLs, acompanhar o SDSF e executar comandos manualmente. Funcionava muito bem... até que a escala dos sistemas cresceu. Hoje, um único ambiente pode possuir milhares de datasets, centenas de aplicações, dezenas de LPARs e pipelines de integração contínua. É nesse momento que surge uma pergunta inevitável: será que ainda faz sentido repetir manualmente tarefas que um computador pode executar sozinho?"
Essa pergunta é exatamente a razão da existência do Ansible.
Se você é um programador COBOL Júnior, talvez imagine que Ansible seja uma ferramenta exclusiva para administradores Linux ou profissionais DevOps. Na realidade, ela está se tornando uma das tecnologias mais importantes para qualquer profissional que trabalhe com IBM Z.
Neste artigo vamos entender, passo a passo, como o Ansible funciona, como ele conversa com o z/OS, quais componentes fazem parte da arquitetura e como um desenvolvedor COBOL pode utilizá-lo para automatizar tarefas do dia a dia.
Prepare seu café. Hoje vamos descobrir que YAML pode ser tão importante quanto JCL.
O problema que o Ansible veio resolver
Imagine que seu gerente peça para criar o mesmo ambiente em dez LPARs diferentes.
Manual seria algo parecido com isto:
abrir TSO;
acessar ISPF;
criar datasets;
copiar membros COBOL;
copiar PROC;
enviar JCL;
acompanhar o JOB;
repetir tudo novamente.
Agora imagine repetir isso cem vezes.
Ou mil vezes.
É exatamente aqui que nasce a automação.
Ao invés de repetir procedimentos, descrevemos o resultado esperado.
O computador faz o restante.
Uma comparação que todo programador COBOL entende
Imagine um JCL.
Você não diz ao sistema:
"Abra um DD, aloque espaço, carregue buffers..."
Você apenas escreve:
//STEP1 EXEC PGM=IEFBR14
O z/OS sabe como executar.
O Ansible segue exatamente essa filosofia.
Você não escreve scripts enormes.
Você descreve o estado desejado.
O que é o Ansible?
Ansible é uma plataforma de automação criada para executar tarefas repetitivas de maneira segura e previsível.
Ele permite automatizar:
instalação de softwares;
deploy de aplicações;
criação de datasets;
envio de JCL;
execução de comandos MVS;
administração de USS;
configuração de servidores Linux;
configuração de IBM Z;
administração de LinuxONE.
Tudo utilizando arquivos YAML extremamente simples.
Infrastructure as Code
Esse talvez seja o conceito mais importante de todo o artigo.
Durante décadas a infraestrutura era documentada em Word.
Algo parecido com:
Abra ISPF
Entre na opção 3.2
Crie um Dataset
Configure FB
LRECL 80
BLKSIZE 27920
O problema?
Se alguém esquecer um passo...
Tudo quebra.
Hoje fazemos diferente.
A infraestrutura vira código.
- name: Criar Dataset
zos_data_set:
name: USER.TEST
type: seq
state: present
Esse pequeno arquivo substitui páginas inteiras de documentação.
O Control Node
Todo ambiente Ansible possui um cérebro.
Chamado de Control Node.
Ele normalmente é um servidor Linux.
É nele que ficam:
Playbooks
Inventário
Roles
Collections
Variáveis
Arquivos YAML
Ele nunca precisa estar dentro do Mainframe.
Ele apenas envia instruções.
Managed Nodes
São as máquinas administradas.
Podem ser:
Linux
Windows
IBM Z
LinuxONE
AIX
z/OS
Pense nelas como os "clientes" do Control Node.
Como o Ansible conversa com o Mainframe?
Essa é uma das perguntas mais comuns.
Muitos imaginam que exista algum protocolo proprietário.
Na prática existem três formas principais.
1. SSH
A mais utilizada.
Ansible
↓
SSH
↓
USS
↓
z/OS
O Ansible acessa o Unix System Services e executa comandos.
2. z/OSMF
O z/OSMF disponibiliza APIs REST.
Então o fluxo fica:
Ansible
↓
HTTPS
↓
z/OSMF
↓
Serviços REST
↓
Mainframe
3. ZOAU
Talvez o componente mais importante.
ZOAU significa:
IBM Z Open Automation Utilities.
Ele oferece APIs para:
datasets
jobs
console
USS
comandos MVS
VSAM
É ele que faz a "ponte" entre o mundo moderno e o z/OS.
O que é YAML?
YAML é a linguagem utilizada pelo Ansible.
Ela foi criada para ser extremamente legível.
Exemplo:
nome: Bellacosa
idade: 52
linguagens:
- COBOL
- PL/I
- JCL
Perceba que praticamente parece português.
Atenção com a indentação
Esse é o erro número um dos iniciantes.
YAML usa espaços.
Nunca TAB.
Errado:
-name:
Correto:
- name:
Um único espaço errado pode impedir toda a execução.
O Inventário
O Inventário informa onde estão os servidores.
Exemplo:
[zos]
LPAR1
LPAR2
LPAR3
[linux]
WEB01
WEB02
Depois disso basta dizer:
hosts: zos
E todas as máquinas do grupo receberão a mesma automação.
O conceito de Playbook
Um Playbook é o equivalente ao nosso JCL.
Ele organiza tarefas.
Imagine:
Criar Dataset
↓
Copiar Programa
↓
Enviar Compile
↓
Executar Bind
↓
Executar Teste
Tudo isso pode estar em um único arquivo YAML.
Primeiro Playbook
---
- hosts: zos
tasks:
- name: Criar Dataset
zos_data_set:
name: USER.COBOL.TESTE
type: seq
state: present
Simples.
Legível.
Reproduzível.
Entendendo Task por Task
Cada Task representa uma ação.
Exemplo:
Task 1
Criar Dataset
↓
Task 2
Copiar Programa
↓
Task 3
Submeter JCL
↓
Task 4
Consultar Resultado
É exatamente como um fluxo Batch.
O conceito de Módulos
Cada Task utiliza um módulo.
Exemplos famosos:
copy
file
package
command
shell
No IBM Z existem módulos especializados.
Como:
zos_data_set
zos_copy
zos_fetch
zos_job_submit
zos_operator
zos_ping
Criando um Dataset
- name: Criar Dataset
zos_data_set:
name: BELLA.TESTE
type: pds
state: present
Resultado:
Caso exista:
Nada acontece.
Caso não exista:
Ele será criado.
Esse comportamento possui um nome
Idempotência.
É uma palavra difícil.
Mas um conceito simples.
Executar:
Playbook
↓
100 vezes
Produzirá exatamente o mesmo ambiente.
Não cria datasets duplicados.
Não reinstala componentes desnecessariamente.
Não destrói configurações.
Copiando um programa COBOL
- name: Copiar Fonte
zos_copy:
src: HELLO.cbl
dest: USER.COBOL(HELLO)
Muito parecido com copiar um arquivo no Windows.
Submetendo um JOB
- name: Compilar
zos_job_submit:
src: USER.JCL(COMPILE)
O JOB é enviado automaticamente ao JES.
Consultando o resultado
Depois podemos verificar o retorno.
CC 0000
↓
Sucesso
CC 0004
↓
Warning
CC 0008
↓
Erro
Sxxx
↓
Abend
Imagine integrar isso diretamente a um pipeline DevOps.
Estrutura recomendada de um projeto
Projeto
inventories/
roles/
playbooks/
group_vars/
host_vars/
collections/
README.md
Essa organização facilita manutenção e reutilização.
Collections
As Collections são bibliotecas prontas.
A principal para IBM Z é:
ibm.ibm_zos_core
Ela disponibiliza dezenas de módulos específicos para o z/OS.
Você não precisa reinventar a roda.
Exemplo completo
---
- hosts: zos
collections:
- ibm.ibm_zos_core
tasks:
- name: Criar Dataset
zos_data_set:
name: BELLA.SOURCE
type: pds
state: present
- name: Copiar Programa
zos_copy:
src: HELLO.cbl
dest: BELLA.SOURCE(HELLO)
- name: Executar Compile
zos_job_submit:
src: BELLA.JCL(COMPILE)
Perceba como o fluxo inteiro cabe em poucas linhas.
Relacionando com o dia a dia do COBOL
Imagine que um desenvolvedor novo entre na equipe.
Manual:
criar datasets;
copiar fontes;
copiar PROC;
copiar macros;
configurar ambiente.
Com Ansible:
ansible-playbook onboarding.yml
Em poucos minutos o ambiente está pronto.
Onde entra o Git?
Os Playbooks são armazenados em um repositório Git.
Isso significa:
histórico;
auditoria;
rollback;
revisão por pares;
integração com CI/CD.
Infraestrutura passa a evoluir exatamente como o código COBOL.
Integração com DevOps
O fluxo moderno normalmente funciona assim:
Git
↓
Pull Request
↓
Pipeline
↓
Ansible
↓
IBM Z
↓
Compile
↓
Teste
↓
Deploy
Observe que o desenvolvedor continua escrevendo COBOL.
Quem automatiza todo o restante é o Ansible.
O futuro do programador COBOL
Há alguns anos bastava conhecer:
COBOL;
JCL;
CICS;
DB2.
Hoje o mercado também valoriza conhecimentos em:
Git;
YAML;
APIs REST;
DevOps;
Docker (conceitos);
Zowe;
VS Code;
Ansible.
Isso não significa abandonar o COBOL.
Significa ampliar seu conjunto de ferramentas.
Erros comuns dos iniciantes
Misturar TAB e espaços no YAML.
Não organizar o inventário.
Executar playbooks diretamente em produção sem homologação.
Ignorar o conceito de idempotência.
Não versionar os playbooks no Git.
Esquecer de validar os retornos dos JOBs.
Criar playbooks gigantes em vez de reutilizar Roles e Collections.
Evitar esses erros desde o início torna a automação muito mais confiável.
Conclusão
Durante décadas aprendemos que administrar um Mainframe significava conhecer profundamente TSO, ISPF, JCL, JES2, RACF, SDSF e inúmeros comandos específicos. Esses conhecimentos continuam indispensáveis. O Ansible não substitui essa experiência; ele a potencializa.
Pense nele como um novo "JCL da infraestrutura". Em vez de automatizar apenas a execução de programas Batch, ele automatiza ambientes inteiros, permitindo criar datasets, copiar programas, submeter JCLs, consultar resultados, configurar servidores e integrar o IBM Z aos modernos pipelines de DevOps.
Para o programador COBOL Júnior, aprender Ansible é investir em uma habilidade que conecta o mundo tradicional do Mainframe às práticas atuais de automação. Você continuará escrevendo programas COBOL, entendendo CICS, DB2 e JCL, mas também será capaz de entregar soluções mais rápidas, reproduzíveis e confiáveis.
No Bellacosa Mainframe, costumamos dizer que o futuro do IBM Z não está em substituir tecnologias consolidadas, mas em integrá-las ao que há de mais moderno. O Ansible representa exatamente essa filosofia: respeitar décadas de robustez do Mainframe enquanto abraça a automação, a colaboração e a infraestrutura como código. Quem dominar esses dois universos estará preparado para construir a próxima geração de aplicações corporativas sobre a plataforma mais confiável do mercado.
Sem comentários:
Enviar um comentário