Bellacosa Mainframe e o ansible sem misterios no Windows

☕ Um Café no Bellacosa Mainframe

Ansible sem Mistérios no Windows

O guia do Programador COBOL Padawan para automatizar Linux, Apache, Java, WebSphere e IBM Z sem abandonar o legado

Existe um momento na carreira de todo Programador COBOL em que ele percebe uma verdade desconfortável:

o programa pode estar perfeito, mas existe um universo inteiro entre o código-fonte e a produção.

É preciso compilar.

Fazer o link-edit.

Copiar módulos de carga.

Executar testes.

Atualizar bibliotecas.

Submeter JCL.

Configurar servidores.

Alterar arquivos.

Reiniciar serviços.

Verificar logs.

Validar portas.

Confirmar se a aplicação voltou a responder.

E, muitas vezes, repetir tudo isso em desenvolvimento, homologação, contingência e produção.

Durante décadas, essas tarefas foram realizadas por meio de procedimentos escritos em documentos, planilhas, scripts isolados e valiosos conhecimentos armazenados na memória de profissionais veteranos.

Funcionava?

Sim.

Mas também criava uma perigosa dependência de operações manuais.

Um comando digitado incorretamente, um membro copiado para a biblioteca errada ou uma configuração esquecida poderia transformar uma implantação aparentemente simples em um incidente digno de um alerta vermelho na ponte da USS Enterprise.

É justamente nesse espaço que entra o Ansible.

Ele não veio para substituir COBOL, JCL, CICS, Db2, IMS, Linux, Java ou WebSphere.

Ele veio para orquestrar essas tecnologias, transformando procedimentos manuais em automações documentadas, repetíveis, versionáveis e auditáveis.

Portanto, sente-se na cadeira de comando, Padawan. Neste artigo construiremos um laboratório gratuito no Windows, instalaremos o Ansible, criaremos nossos primeiros Playbooks, configuraremos Apache e Java e entenderemos como essa ferramenta se conecta ao universo do IBM Z.

1. Afinal, o que é o Ansible?

O Ansible é uma tecnologia de automação de TI capaz de executar tarefas como:

configuração de servidores;
instalação de programas;
implantação de aplicações;
provisionamento de infraestrutura;
execução de comandos;
administração de serviços;
automação de redes;
integração de ambientes híbridos;
orquestração de processos com várias etapas.

Em vez de um administrador acessar manualmente cada máquina, o Ansible recebe uma descrição do que deve ser feito e executa essas ações nos equipamentos selecionados.

A documentação oficial define o Ansible como uma tecnologia aberta capaz de descrever e automatizar ambientes de TI, desde pequenos laboratórios domésticos até infraestruturas corporativas de grande escala. (Ansible Docs)

Imagine que uma empresa tenha:

40 servidores Linux;
12 servidores Apache;
8 instâncias de WebSphere;
4 ambientes Java;
um IBM Z;
dezenas de regiões CICS;
centenas de bibliotecas e jobs.

Sem automação, alguém precisaria entrar máquina por máquina para realizar as alterações.

Com Ansible, podemos escrever uma instrução como:

- name: Garantir que o Apache esteja instalado
  ansible.builtin.apt:
    name: apache2
    state: present

Essa pequena tarefa declara um estado desejado:

“O pacote Apache deve estar instalado.”

O Ansible analisa o ambiente e tenta conduzi-lo até esse estado.

Essa diferença é fundamental.

Em um Shell Script tradicional, normalmente escrevemos uma sequência de comandos:

apt update
apt install apache2
systemctl start apache2

No Ansible, descrevemos principalmente o resultado que queremos alcançar.

Essa abordagem aproxima a infraestrutura do desenvolvimento de software.

2. Infraestrutura como código

Durante muito tempo, a infraestrutura foi tratada como algo quase artesanal.

Um especialista configurava um servidor.

Outro alterava uma propriedade.

Um terceiro modificava o firewall.

Cada mudança poderia ser registrada em um chamado, mas nem sempre era possível reconstruir exatamente o ambiente apenas lendo a documentação.

A Infraestrutura como Código, conhecida pela sigla IaC — Infrastructure as Code, muda essa lógica.

Configurações passam a ser armazenadas em arquivos.

Esses arquivos podem ser:

revisados;
comparados;
versionados no Git;
submetidos à aprovação;
testados;
executados novamente;
reutilizados em outros ambientes.

Para um Programador COBOL, a analogia é simples.

Imagine que a configuração de um servidor seja como um programa executável sem código-fonte.

Ele funciona, mas ninguém sabe exatamente como foi construído.

O Ansible devolve o “fonte” da infraestrutura.

O Playbook passa a representar a sequência lógica usada para construir ou configurar aquele ambiente.

3. Como o Ansible funciona?

O Ansible trabalha, de maneira simplificada, com dois lados:

┌──────────────────────────────┐
│       CONTROL NODE           │
│                              │
│ Ansible                      │
│ Inventários                  │
│ Playbooks                    │
│ Variáveis                    │
│ Credenciais                  │
└──────────────┬───────────────┘
               │
          SSH, APIs ou
       protocolos específicos
               │
 ┌─────────────┼───────────────┐
 │             │               │
 ▼             ▼               ▼
Linux       IBM Z          Windows
Apache      z/OS           Servidores
Java        USS            corporativos

O Control Node é a máquina onde o Ansible é executado.

Os Managed Nodes são os sistemas administrados.

Em ambientes Linux e Unix, a comunicação costuma ocorrer por SSH.

Para administrar Windows como destino, o Ansible pode utilizar mecanismos como WinRM. A documentação também oferece módulos específicos para instalar programas, administrar atualizações, usuários, grupos, serviços e outros componentes do Windows. (Ansible Docs)

No IBM Z, a comunicação depende da coleção utilizada e dos pré-requisitos configurados. A coleção IBM z/OS Core, por exemplo, permite que o Ansible execute módulos no z/OS e devolva os resultados ao controlador. (IBM GitHub)

4. O que significa dizer que o Ansible é “agentless”?

Muitas plataformas de administração precisam instalar permanentemente um agente em cada servidor.

Esse agente fica ativo, recebe comandos e informa o estado da máquina.

O Ansible adota uma abordagem diferente em muitos de seus cenários: ele normalmente utiliza mecanismos já existentes no sistema, como SSH, bibliotecas Python ou APIs.

Isso reduz a necessidade de manter um programa específico do Ansible permanentemente executando em cada Linux administrado.

Mas “agentless” não significa “sem requisitos”.

A máquina de destino ainda pode precisar de:

SSH configurado;
usuário autorizado;
Python compatível;
permissões administrativas;
bibliotecas adicionais;
APIs ou componentes específicos.

No z/OS, por exemplo, diferentes versões da coleção podem exigir combinações específicas de ansible-core, IBM Open Enterprise SDK for Python e Z Open Automation Utilities, o ZOAU. Por isso, sempre é necessário conferir a matriz de requisitos da versão utilizada. (IBM GitHub)

Esse é um erro comum do Padawan:

“Se não tem agente, então não precisa preparar nada.”

Precisa, sim.

A ausência de um agente próprio apenas simplifica parte da arquitetura.

5. Posso instalar Ansible no Windows?

A resposta correta é:

podemos estudar e executar Ansible em uma máquina Windows usando WSL, mas o Ansible não é executado nativamente no Windows como Control Node tradicional.

A documentação oficial informa que o Windows não é suportado como Control Node nativo, mas que é possível executar Ansible no Windows por meio do Windows Subsystem for Linux — WSL ou de um contêiner. A mesma documentação alerta que o uso de WSL como controlador não é suportado para sistemas de produção. Para aprendizado, testes locais e desenvolvimento, entretanto, ele é uma excelente estação de treinamento. (Ansible Docs)

Nossa arquitetura de laboratório será esta:

Windows 11
│
├── PowerShell
├── Navegador
├── Visual Studio Code
│
└── WSL 2
    └── Ubuntu
        ├── Bash
        ├── Python
        ├── Git
        ├── Ansible
        ├── Apache
        ├── Java
        └── Playbooks YAML

O Windows continuará sendo sua nave principal.

O Ubuntu no WSL será a sala de máquinas onde o Ansible será executado.

6. O que é WSL?

WSL significa Windows Subsystem for Linux.

Ele permite executar uma distribuição GNU/Linux diretamente no Windows, incluindo ferramentas de linha de comando, Bash, gerenciadores de pacotes e aplicações Linux, sem exigir uma instalação dual boot. A Microsoft apresenta o WSL justamente como uma maneira de utilizar ambientes Linux e Windows na mesma estação. (Microsoft Learn)

Para o nosso laboratório, usaremos o WSL 2.

Ele oferece um ambiente Linux muito mais próximo de uma instalação real, sendo adequado para estudar:

Bash;
SSH;
Git;
Python;
Ansible;
Apache;
Java;
Docker;
ferramentas DevOps.

Easter egg da Frota Estelar

O WSL é como o Holodeck da Enterprise.

Você continua fisicamente dentro do Windows, mas entra em um ambiente Linux suficientemente convincente para executar ferramentas, criar arquivos, instalar serviços e praticar comandos como se estivesse em outra nave.

A diferença é que, se o laboratório der errado, você não precisará chamar o Chefe O’Brien.

Na maioria das vezes.

7. Passo a passo: instalando o WSL 2

Abra o PowerShell como administrador.

Execute:

wsl --install

Esse é o método simplificado recomendado atualmente pela Microsoft. Ele habilita os componentes necessários e normalmente instala o Ubuntu como distribuição padrão. Depois da instalação, o computador poderá solicitar uma reinicialização. (Microsoft Learn)

Após reiniciar, abra novamente o PowerShell e execute:

wsl --list --verbose

Ou a forma abreviada:

wsl -l -v

Você deverá encontrar algo semelhante a:

  NAME      STATE           VERSION
* Ubuntu    Stopped         2

Caso o Ubuntu apareça como WSL 1, execute:

wsl --set-version Ubuntu 2

Para determinar que novas distribuições utilizem WSL 2 por padrão:

wsl --set-default-version 2

Novas instalações feitas por wsl --install normalmente já utilizam o WSL 2 por padrão. (Microsoft Learn)

Quando abrir o Ubuntu pela primeira vez, será necessário criar:

um nome de usuário Linux;
uma senha Linux.

Você pode escolher:

bellacosa

ou:

cobolpadawan

Ao digitar a senha no terminal Linux, nenhum asterisco aparecerá.

Não é erro.

Não é travamento.

Não é interferência dos Borg.

O Linux simplesmente não exibe os caracteres da senha.

8. Preparando o Ubuntu

Abra o Ubuntu e execute:

sudo apt update
sudo apt upgrade -y

O primeiro comando atualiza a lista de pacotes disponíveis.

O segundo instala as atualizações.

Depois, instale algumas ferramentas úteis:

sudo apt install git python3 python3-pip openssh-client nano curl -y

Essas ferramentas terão funções importantes:

git: versionamento;
python3: execução de módulos;
pip: instalação de pacotes Python;
openssh-client: conexões SSH;
nano: editor simples;
curl: testes de páginas e APIs.

9. Instalando o Ansible

Para um laboratório inicial no Ubuntu, podemos utilizar:

sudo apt install ansible -y

Depois, confirme:

ansible --version

A saída deve apresentar informações como:

ansible [core ...]
config file = ...
python version = ...
jinja version = ...

A documentação oficial também descreve métodos de instalação por pacotes das distribuições e por ferramentas do ecossistema Python. A melhor escolha depende do objetivo: simplicidade para estudo, controle rigoroso de versões, desenvolvimento de coleções ou uso corporativo. (Ansible Docs)

Para nosso primeiro Holodeck, o pacote do Ubuntu é suficiente.

10. Criando a estrutura do laboratório

No Ubuntu, execute:

mkdir -p ~/ansible-lab
cd ~/ansible-lab

Verifique:

pwd

O resultado deverá ser semelhante a:

/home/bellacosa/ansible-lab

Crie algumas pastas:

mkdir -p playbooks inventory files templates roles

Nossa estrutura ficará assim:

ansible-lab/
├── inventory/
├── playbooks/
├── files/
├── templates/
└── roles/

Não precisamos usar todas imediatamente.

Mas estamos preparando o laboratório para crescer de maneira organizada.

11. Inventário: o mapa estelar do Ansible

O inventário informa ao Ansible quais máquinas podem ser administradas.

Crie o arquivo:

nano inventory/hosts.ini

Digite:

[local]
localhost ansible_connection=local

Salve pressionando:

Ctrl + O
Enter
Ctrl + X

Esse inventário cria um grupo chamado local.

Dentro dele existe uma máquina:

localhost

A variável:

ansible_connection=local

informa que a execução será feita diretamente no Ubuntu do WSL, sem abrir uma conexão SSH.

A documentação do Ansible considera inventários, Playbooks, plays, tasks, roles e collections entre seus conceitos fundamentais. (Ansible Docs)

Pense no inventário como um mapa estelar:

[web]
web01
web02

[database]
db01

[mainframe]
zos01

[producao]
web01
web02
db01
zos01

Você pode agrupar os alvos por:

tecnologia;
ambiente;
localização;
aplicação;
função;
criticidade.

12. O primeiro contato: o módulo ping

Execute:

ansible all -i inventory/hosts.ini -m ping

Resultado esperado:

localhost | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Esse ping não é exatamente o mesmo comando de rede usado para testar ICMP.

O módulo do Ansible verifica se ele consegue executar corretamente no destino e obter uma resposta.

Podemos decompor o comando:

ansible

Programa usado para executar uma ação rápida.

all

Todos os hosts do inventário.

-i inventory/hosts.ini

Arquivo de inventário utilizado.

-m ping

Módulo que será executado.

Esse tipo de comando é chamado de ad hoc command.

São ordens rápidas, úteis para consultas, diagnósticos e pequenas operações.

13. Coletando informações do Linux

Execute:

ansible all -i inventory/hosts.ini -m setup

O Ansible retornará uma grande quantidade de informações:

distribuição Linux;
versão do sistema;
processadores;
memória;
interfaces de rede;
endereços IP;
arquitetura;
variáveis do ambiente;
discos;
hostname.

Essas informações são chamadas de facts.

Podemos filtrar a resposta:

ansible all -i inventory/hosts.ini -m setup \
  -a "filter=ansible_distribution*"

Ou consultar a memória:

ansible all -i inventory/hosts.ini -m setup \
  -a "filter=ansible_memtotal_mb"

Os facts podem ser usados nos Playbooks para tomar decisões.

Exemplo conceitual:

- name: Instalar pacote no Ubuntu
  ansible.builtin.apt:
    name: apache2
    state: present
  when: ansible_distribution == "Ubuntu"

Assim, a automação pode adaptar-se ao sistema encontrado.

14. O que é um Playbook?

Um Playbook é um arquivo YAML que descreve uma ou mais automações.

A documentação oficial explica que Playbooks reúnem tarefas e módulos para executar mudanças de maneira organizada nos sistemas selecionados. (Ansible Docs)

Crie:

nano playbooks/primeiro-playbook.yml

Conteúdo:

---
- name: Primeiro treinamento Bellacosa Mainframe
  hosts: local
  connection: local
  gather_facts: true

  tasks:
    - name: Criar diretório do laboratório
      ansible.builtin.file:
        path: /tmp/bellacosa-lab
        state: directory
        mode: "0755"

    - name: Criar mensagem para o Padawan
      ansible.builtin.copy:
        dest: /tmp/bellacosa-lab/mensagem.txt
        content: |
          Laboratório Ansible em funcionamento.
          Automação autorizada pela Frota Estelar.
          O COBOL continua vivo.
        mode: "0644"

    - name: Mostrar a distribuição Linux
      ansible.builtin.debug:
        msg: "Sistema detectado: {{ ansible_distribution }} {{ ansible_distribution_version }}"

Execute:

ansible-playbook \
  -i inventory/hosts.ini \
  playbooks/primeiro-playbook.yml

Confira o arquivo:

cat /tmp/bellacosa-lab/mensagem.txt

15. Entendendo o YAML sem entrar em um buraco negro

YAML é um formato de serialização muito utilizado em configurações.

Sua estrutura depende fortemente de indentação.

Exemplo:

tripulante:
  nome: Bellacosa
  funcao: Programador COBOL
  nivel: Padawan
  tecnologias:
    - COBOL
    - JCL
    - Ansible

O YAML possui:

pares de chave e valor;
listas;
objetos aninhados;
valores booleanos;
números;
textos.

No Ansible:

- name: Criar arquivo
  ansible.builtin.file:
    path: /tmp/teste.txt
    state: touch

Temos:

uma tarefa;
um nome descritivo;
um módulo;
parâmetros enviados ao módulo.

Regra de ouro

Use espaços.

Não utilize tabulação.

Uma indentação incorreta pode impedir a leitura do arquivo ou, pior, alterar sua estrutura lógica.

Para verificar a sintaxe:

ansible-playbook \
  -i inventory/hosts.ini \
  playbooks/primeiro-playbook.yml \
  --syntax-check

16. Idempotência: a disciplina vulcana

Execute novamente o primeiro Playbook.

Na primeira execução, algumas tarefas podem aparecer como:

changed

Na segunda, provavelmente aparecerão como:

ok

Por quê?

Porque o diretório e o arquivo já estão no estado desejado.

Esse comportamento é chamado de idempotência.

A documentação observa que módulos idempotentes procuram produzir o mesmo resultado independentemente de o Playbook ser executado uma ou várias vezes, embora nem todo Playbook seja automaticamente idempotente. (Ansible Docs)

Matematicamente, a ideia lembra:

f(f(x)) = f(x)

Depois que o estado desejado é alcançado, repetir a operação não deveria criar uma situação diferente.

Para um veterano do batch, podemos comparar com um processo restartable bem projetado.

Um job confiável deve saber:

o que já foi processado;
onde continuar;
quando não repetir uma ação destrutiva;
como retornar ao estado esperado.

A idempotência é uma das bases da automação segura.

17. Instalando Apache com Ansible

Agora teremos nossa primeira missão real.

Crie:

nano playbooks/apache.yml

Conteúdo:

---
- name: Configurar Apache no Holodeck
  hosts: local
  connection: local
  become: true

  tasks:
    - name: Atualizar cache de pacotes
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Instalar Apache
      ansible.builtin.apt:
        name: apache2
        state: present

    - name: Publicar página Bellacosa
      ansible.builtin.copy:
        dest: /var/www/html/index.html
        content: |
          <!DOCTYPE html>
          <html lang="pt-BR">
          <head>
            <meta charset="UTF-8">
            <title>Bellacosa Ansible Lab</title>
          </head>
          <body>
            <h1>Ansible sem Mistérios</h1>
            <p>Servidor Apache configurado automaticamente.</p>
            <p>Mensagem da ponte: o COBOL está integrado ao futuro.</p>
          </body>
          </html>
        mode: "0644"
      notify: Reiniciar Apache

    - name: Garantir que o Apache esteja iniciado
      ansible.builtin.service:
        name: apache2
        state: started
        enabled: true

  handlers:
    - name: Reiniciar Apache
      ansible.builtin.service:
        name: apache2
        state: restarted

Execute:

ansible-playbook \
  -i inventory/hosts.ini \
  playbooks/apache.yml \
  --ask-become-pass

Digite a senha do usuário Ubuntu.

Depois, teste:

curl http://localhost

Abra também no navegador do Windows:

http://localhost

Se tudo funcionar, você verá a página criada pelo Ansible.

O que é `become`?

A instrução:

become: true

indica que determinadas tarefas precisam de privilégios elevados, normalmente usando sudo.

O que é um handler?

O handler é uma tarefa acionada por uma notificação.

Observe:

notify: Reiniciar Apache

O Apache será reiniciado apenas quando a tarefa que publica a página realmente provocar uma mudança.

Isso evita reinicializações desnecessárias.

É como dizer:

“Não acorde o Capitão apenas para informar que nada mudou.”

18. Instalando Java

Crie:

nano playbooks/java.yml

Conteúdo:

---
- name: Preparar ambiente Java
  hosts: local
  connection: local
  become: true

  tasks:
    - name: Instalar OpenJDK
      ansible.builtin.apt:
        name: openjdk-17-jdk
        state: present
        update_cache: true

    - name: Consultar versão do Java
      ansible.builtin.command:
        cmd: java -version
      register: resultado_java
      changed_when: false

    - name: Exibir versão instalada
      ansible.builtin.debug:
        var: resultado_java.stderr_lines

Execute:

ansible-playbook \
  -i inventory/hosts.ini \
  playbooks/java.yml \
  --ask-become-pass

O parâmetro:

register: resultado_java

guarda a resposta de uma tarefa em uma variável.

Depois, usamos:

ansible.builtin.debug:
  var: resultado_java.stderr_lines

para mostrar parte dessa resposta.

A instrução:

changed_when: false

informa que a consulta à versão do Java não modifica o sistema.

Sem isso, determinados comandos podem ser marcados como mudança mesmo quando apenas realizam uma leitura.

19. Como o Ansible se relaciona com Java?

O Ansible não substitui a JVM nem escreve automaticamente a lógica da aplicação.

Ele automatiza o ambiente no qual a aplicação Java será executada.

Pode, por exemplo:

instalar o Java;
criar usuários de serviço;
criar diretórios;
copiar arquivos JAR;
distribuir arquivos WAR e EAR;
configurar variáveis de ambiente;
alterar parâmetros da JVM;
criar certificados;
instalar serviços;
configurar logs;
iniciar e parar aplicações;
validar portas;
testar URLs de saúde;
executar scripts de implantação.

Uma aplicação Java pode ser construída em um pipeline e depois entregue por Ansible:

Git
  ↓
Compilação Maven ou Gradle
  ↓
Testes
  ↓
Artefato JAR, WAR ou EAR
  ↓
Ansible
  ↓
Tomcat, Liberty ou WebSphere

O Ansible representa o oficial de transporte.

Ele recebe o artefato e garante que chegue ao destino correto, com a configuração correta.

20. E o WebSphere?

WebSphere é uma plataforma corporativa complexa.

Uma automação pode envolver:

Deployment Manager;
Node Agents;
clusters;
servidores de aplicação;
aplicações EAR;
DataSources;
JDBC Providers;
JMS;
segurança;
propriedades da JVM;
certificados;
scripts wsadmin;
arquivos de configuração;
rotinas de health check.

No WebSphere tradicional, o Ansible pode ser usado para coordenar comandos e scripts administrativos existentes.

Um fluxo conceitual seria:

1. Retirar servidor do balanceamento
2. Parar aplicação
3. Copiar novo EAR
4. Executar script wsadmin
5. Sincronizar nós
6. Iniciar aplicação
7. Testar URL
8. Recolocar servidor no balanceamento

O valor do Ansible não está apenas em executar um comando.

Está em organizar toda a sequência, aplicar condições, capturar erros e impedir que a próxima etapa seja executada quando a anterior falhar.

Cuidado de Engenharia

Não trate WebSphere como se fosse apenas um diretório onde você copia um EAR.

Uma implantação corporativa pode exigir:

sincronização;
rollout gradual;
controle de sessão;
compatibilidade entre versões;
rollback;
validação de dependências;
gestão de certificados;
aprovação operacional.

O Ansible automatiza o procedimento, mas não elimina a necessidade de compreendê-lo.

21. Conectando Ansible ao IBM Z

Agora chegamos ao setor onde pulsa o coração do Bellacosa Mainframe.

A IBM disponibiliza conteúdo Ansible voltado ao IBM Z. O objetivo é integrar o IBM Z à estratégia mais ampla de automação corporativa, unificando configuração, provisionamento, implantação e orquestração de fluxos. (Ansible Collections)

A coleção IBM z/OS Core oferece módulos para atividades como:

criar data sets;
copiar conteúdo;
submeter jobs;
consultar jobs;
recuperar saídas do JES;
executar comandos;
trabalhar com arquivos USS;
processar codificações;
manipular recursos do z/OS.

A documentação oficial destaca explicitamente operações como criação de data sets, submissão e consulta de jobs, recuperação de output e codificação de dados. (IBM GitHub)

Para instalar a coleção no laboratório:

ansible-galaxy collection install ibm.ibm_zos_core

Confira:

ansible-galaxy collection list

A documentação IBM informa que coleções podem ser obtidas por meios como Ansible Galaxy, Ansible Automation Hub ou construção local, dependendo da distribuição e do modelo de suporte adotado. (IBM GitHub)

22. Criando um Playbook conceitual para z/OS

Mesmo sem acesso imediato a um mainframe, você pode começar a estudar a estrutura.

Crie:

nano playbooks/zos-exemplo.yml

Conteúdo conceitual:

---
- name: Laboratório conceitual IBM Z
  hosts: zos
  gather_facts: false

  tasks:
    - name: Criar data set sequencial
      ibm.ibm_zos_core.zos_data_set:
        name: BELLACOS.TRAINING.DATA
        type: seq
        state: present
        record_format: fb
        record_length: 80

    - name: Submeter JCL de treinamento
      ibm.ibm_zos_core.zos_job_submit:
        src: BELLACOS.TRAINING.JCL(HELLO)
        location: data_set
        wait_time_s: 30

A documentação do módulo zos_job_submit informa que ele pode submeter JCL armazenado em data set, arquivo no USS ou arquivo localizado no controlador, além de acompanhar a conclusão do job. (IBM GitHub)

Para executar de verdade, será necessário preparar:

host z/OS;
acesso de rede;
SSH;
usuário e permissões;
USS;
Python suportado;
ZOAU;
variáveis de ambiente;
inventário;
versões compatíveis.

Instalar a coleção no WSL não cria um mainframe mágico dentro do notebook.

Ela apenas prepara o controlador para conversar com um ambiente IBM Z que atenda aos requisitos.

23. Exemplo de inventário para IBM Z

Um inventário conceitual poderia ser:

[zos]
zos01 ansible_host=mainframe.empresa.local

[zos:vars]
ansible_connection=ssh
ansible_user=USUARIO
ansible_python_interpreter=/usr/lpp/IBM/cyp/v3r*/pyz/bin/python3

Os caminhos e parâmetros reais dependem da instalação da empresa.

Nunca copie cegamente configurações de um artigo para produção.

Consulte:

versão da coleção;
versão do z/OS;
versão do Python;
versão do ZOAU;
política de segurança;
configuração de SSH;
padrões internos.

Essa é uma lição essencial:

Um bom Playbook é reutilizável. Uma boa implantação, porém, respeita as particularidades do ambiente.

24. Ansible e JCL: inimigos ou aliados?

Eles são aliados.

O Ansible não substitui JCL.

JCL continua sendo a linguagem de controle dos jobs no z/OS.

O que o Ansible pode fazer é:

selecionar o JCL;
transferi-lo;
alterar variáveis;
submetê-lo;
acompanhar o job;
verificar o return code;
coletar o spool;
decidir se o pipeline pode continuar.

Imagine:

Ansible
   ↓
Submete JCL de compilação
   ↓
Espera conclusão
   ↓
Verifica RC
   ├── RC 0: continua
   ├── RC 4: aplica regra definida
   └── RC 8+: interrompe implantação

Essa combinação preserva a força do JCL e adiciona uma camada moderna de orquestração.

É como instalar um painel LCARS na frente de uma sala de máquinas histórica.

O motor continua sendo poderoso.

A interface e a integração tornam-se mais modernas.

25. Ansible, COBOL e DevOps

Um pipeline híbrido poderia funcionar assim:

1. Desenvolvedor envia código COBOL ao Git
2. Pipeline inicia
3. Build é executado
4. Testes automatizados são realizados
5. Ansible transfere componentes
6. JCL de implantação é submetido
7. Módulos de carga são atualizados
8. BIND de Db2 é executado
9. Aplicação é validada
10. Relatório é produzido

Em uma solução distribuída:

1. COBOL processa regras de negócio no IBM Z
2. Java fornece uma camada de serviços
3. WebSphere ou Liberty hospeda aplicações
4. Apache atua como servidor ou proxy
5. Ansible coordena a configuração
6. Jenkins ou outra ferramenta inicia o pipeline
7. Git guarda código e Playbooks

O Programador COBOL que aprende Ansible deixa de enxergar apenas o programa e passa a compreender o fluxo operacional completo.

Esse profissional consegue conversar com:

desenvolvimento;
infraestrutura;
middleware;
segurança;
produção;
DevOps;
arquitetura;
cloud;
equipes Linux;
equipes IBM Z.

26. Segurança: nunca coloque senhas no Playbook

Nunca faça isto:

senha: MinhaSenha123

E muito menos envie esse arquivo para o Git.

Credenciais podem ser tratadas com mecanismos como:

Ansible Vault;
variáveis protegidas;
gerenciadores de segredos;
credenciais da plataforma corporativa;
chaves SSH;
tokens de curta duração;
cofres externos.

Para criar um arquivo protegido com Ansible Vault:

ansible-vault create secrets.yml

Para editar:

ansible-vault edit secrets.yml

Para visualizar:

ansible-vault view secrets.yml

O objetivo não é esconder uma senha de maneira improvisada.

É impedir que segredos sejam armazenados em texto aberto ou espalhados por scripts.

Regra de segurança da Frota

Um Playbook pode ser compartilhado.

Uma senha não.

27. Modos seguros de teste

Antes de executar uma automação em ambiente importante, use ferramentas de validação.

Verificar a sintaxe

ansible-playbook playbooks/apache.yml --syntax-check

Simular alterações

ansible-playbook \
  -i inventory/hosts.ini \
  playbooks/apache.yml \
  --check

O modo --check tenta indicar o que seria modificado sem aplicar todas as mudanças.

Entretanto, nem todo módulo consegue simular perfeitamente suas ações.

Portanto, --check ajuda, mas não substitui um ambiente de teste.

Mostrar diferenças

ansible-playbook \
  -i inventory/hosts.ini \
  playbooks/apache.yml \
  --check \
  --diff

Limitar a execução

ansible-playbook \
  -i inventory/hosts.ini \
  playbooks/apache.yml \
  --limit localhost

Em ambientes reais, --limit é valioso para realizar um teste controlado em uma única máquina antes de alcançar todo o grupo.

28. Use nomes que expliquem a operação

Evite:

- name: Executar comando

Prefira:

- name: Reiniciar Apache após alteração do arquivo de configuração

Evite:

- name: Copiar arquivo

Prefira:

- name: Publicar página inicial do portal de treinamento

O Playbook deve funcionar como documentação executável.

Um operador deve conseguir lê-lo e compreender:

o que acontecerá;
em quais máquinas;
em que sequência;
sob quais condições.

Código misterioso pertence aos arquivos secretos da Seção 31, não à automação corporativa.

29. Não abuse dos módulos command e shell

É possível executar:

ansible.builtin.command:
  cmd: touch /tmp/arquivo.txt

Mas existe um módulo específico para arquivos:

ansible.builtin.file:
  path: /tmp/arquivo.txt
  state: touch

O módulo especializado geralmente conhece melhor o recurso.

Ele pode:

verificar o estado;
detectar mudanças;
validar parâmetros;
oferecer melhor idempotência;
retornar informações estruturadas.

Use command ou shell quando necessário, mas pesquise antes se existe um módulo apropriado.

A documentação do Ansible mantém um índice de módulos disponíveis nas diversas coleções. (Ansible Docs)

30. Evoluindo para templates

Imagine um arquivo de configuração do Apache diferente para cada ambiente.

Em desenvolvimento:

ServerName dev.bellacosa.local

Em produção:

ServerName www.bellacosa.com

Em vez de manter dois arquivos quase iguais, podemos utilizar um template Jinja2.

Crie:

nano templates/site.conf.j2

Conteúdo:

ServerName {{ nome_servidor }}
DocumentRoot {{ diretorio_site }}

No Playbook:

- name: Gerar configuração do site
  ansible.builtin.template:
    src: ../templates/site.conf.j2
    dest: /etc/apache2/sites-available/bellacosa.conf
    mode: "0644"

Com variáveis:

vars:
  nome_servidor: localhost
  diretorio_site: /var/www/html

Os templates permitem criar configurações dinâmicas sem duplicar arquivos.

Para o Programador COBOL, pense em um template como um esqueleto parametrizado, semelhante a uma PROC de JCL que recebe símbolos.

31. Roles: transformando Playbooks em componentes reutilizáveis

Quando o laboratório crescer, um único arquivo poderá ficar enorme.

As roles organizam a automação em componentes.

Exemplo:

roles/
└── apache/
    ├── tasks/
    │   └── main.yml
    ├── handlers/
    │   └── main.yml
    ├── templates/
    ├── files/
    ├── defaults/
    │   └── main.yml
    └── vars/
        └── main.yml

Uma role poderia representar:

instalação do Apache;
preparação de Java;
implantação WebSphere;
configuração do MQ;
preparação de um servidor;
submissão de jobs z/OS;
validação de uma aplicação COBOL.

O Playbook principal passa a ser simples:

---
- name: Preparar servidor web
  hosts: web
  become: true

  roles:
    - apache
    - java

Esse modelo melhora:

manutenção;
reutilização;
padronização;
testes;
documentação.

32. Ansible Community e Ansible Automation Platform

No laboratório, estamos usando a tecnologia aberta pela linha de comando.

Em empresas, também existe a Red Hat Ansible Automation Platform, voltada à execução, governança e escala corporativa da automação. (redhat.com)

Uma plataforma corporativa pode adicionar recursos como:

interface central;
controle de acesso;
inventários gerenciados;
credenciais;
agendamentos;
registros de execução;
aprovação;
ambientes de execução;
integração com pipelines;
governança.

Mas não espere conhecer a plataforma corporativa para aprender.

Comece por:

YAML
Inventário
Módulos
Playbooks
Variáveis
Handlers
Templates
Roles
Git

A plataforma será muito mais fácil quando os fundamentos estiverem sólidos.

33. Visual Studio Code como painel LCARS

Instale no Windows:

Visual Studio Code;
extensão WSL;
extensão YAML;
extensão Ansible da Red Hat.

No Ubuntu:

cd ~/ansible-lab
code .

O VS Code abrirá a pasta dentro do ambiente WSL.

Essa combinação oferece:

destaque de sintaxe;
terminal integrado;
validação;
navegação de arquivos;
integração com Git;
sugestões;
pesquisa;
comparação de versões.

O terminal continuará sendo importante, mas você terá uma ponte de comando mais confortável.

34. Um laboratório com vários servidores

Depois de dominar o localhost, avance para múltiplos destinos.

Você pode usar:

máquinas virtuais;
servidores Linux antigos;
instâncias em nuvem;
contêineres de laboratório;
Raspberry Pi;
outro computador da rede.

Arquitetura:

WSL Ubuntu — Control Node
│
├── linux-web-01
├── linux-web-02
├── linux-java-01
└── zos-treinamento

Um inventário poderia ser:

[web]
linux-web-01
linux-web-02

[java]
linux-java-01

[linux:children]
web
java

Teste apenas o grupo web:

ansible web -i inventory/hosts.ini -m ping

Execute apenas em um host:

ansible linux-web-01 -i inventory/hosts.ini -m ping

Esse é o momento em que o laboratório deixa de parecer uma ferramenta local e começa a revelar sua capacidade de orquestração.

35. Plano de ação de 12 semanas

Semanas 1 e 2 — Academia da Frota

Objetivos:

instalar WSL 2;
conhecer comandos Linux;
instalar Ansible;
criar inventário local;
executar ping e setup.

Missão prática:

Criar um Playbook que gere três arquivos em /tmp.

Semanas 3 e 4 — YAML e módulos

Estudar:

listas;
dicionários;
variáveis;
file;
copy;
package;
service;
debug.

Missão prática:

Criar usuários, diretórios e arquivos de configuração em um Linux de laboratório.

Semanas 5 e 6 — Apache e Java

Estudar:

instalação de pacotes;
handlers;
templates;
serviços;
validação por URL;
variáveis registradas.

Missão prática:

Instalar Apache e Java e publicar uma página que mostre informações do servidor.

Semanas 7 e 8 — Git e organização

Estudar:

repositórios;
commits;
branches;
revisão;
roles;
estrutura de projetos;
Ansible Vault.

Missão prática:

Transformar a automação do Apache em uma role versionada no Git.

Semanas 9 e 10 — IBM Z

Estudar:

USS;
SSH no z/OS;
Python;
ZOAU;
coleções IBM;
zos_data_set;
zos_copy;
zos_job_submit;
consulta de jobs.

Missão prática:

Escrever Playbooks conceituais e, quando houver acesso, testá-los em um ambiente educacional autorizado.

Semanas 11 e 12 — Projeto final

Construir um fluxo que:

prepare Linux;
instale Java;
configure Apache;
publique uma aplicação;
execute health check;
gere relatório;
inclua uma etapa conceitual para IBM Z.

Ao final, publique a documentação do projeto em seu repositório.

36. Dez erros clássicos do Padawan

1. Aprender somente copiando Playbooks

Copiar ajuda, mas você precisa entender cada tarefa.

2. Testar primeiro em produção

Produção não é Holodeck.

3. Armazenar senha no Git

Uma credencial vazada pode comprometer todo o ambiente.

4. Usar `shell` para tudo

Prefira módulos especializados.

5. Ignorar o inventário

Executar no grupo errado pode causar um desastre.

6. Não usar nomes descritivos

Uma tarefa sem descrição é um enigma para o operador.

7. Não verificar resultados

Instalação concluída não significa aplicação saudável.

8. Confundir automação com ausência de controle

Quanto maior o poder, maior deve ser a governança.

9. Ignorar versões

Coleções, Python, Ansible e sistemas precisam ser compatíveis.

10. Querer automatizar sem conhecer o processo

Se você não consegue executar o procedimento manualmente, provavelmente ainda não está pronto para automatizá-lo.

37. Curiosidades da sala de máquinas

O nome “Ansible” foi inspirado no conceito de um dispositivo fictício de comunicação instantânea encontrado na ficção científica.

É uma escolha perfeita.

O Ansible conecta sistemas distantes e transmite instruções de maneira coordenada, quase como se uma única ponte comandasse diferentes naves de uma frota.

Outra curiosidade importante é que o Ansible não está limitado à instalação de pacotes. Ele pode atuar na administração de redes, nuvens, sistemas operacionais, middleware, contêineres e mainframes.

Seu verdadeiro poder não está no comando individual.

Está na orquestração.

Instalar Apache é fácil.

Difícil é:

retirar o servidor do balanceador;
fazer backup;
atualizar a aplicação;
alterar configurações;
reiniciar serviços;
validar a página;
restaurar o tráfego;
interromper tudo e executar rollback se a validação falhar.

Esse fluxo completo é onde a automação se transforma em engenharia.

38. Por que um Programador COBOL deveria aprender Ansible?

Porque o mainframe não vive isolado.

Uma transação pode começar em:

aplicativo móvel;
navegador;
API;
microsserviço;
servidor Java;
mensageria;
z/OS Connect;
CICS;
programa COBOL;
Db2.

O COBOL pode continuar sendo o coração da regra de negócio, mas sua operação está conectada a um ecossistema híbrido.

O profissional que conhece apenas o programa vê uma sala.

O profissional que conhece automação vê a nave inteira.

Aprender Ansible ajuda o Programador COBOL a:

compreender DevOps;
participar de pipelines;
automatizar tarefas repetitivas;
reduzir erros;
dialogar com equipes Linux;
integrar IBM Z a ambientes distribuídos;
transformar procedimentos em código;
documentar operações;
colaborar com arquitetos;
modernizar sem destruir o legado.

Não se trata de abandonar COBOL.

Trata-se de colocar o COBOL dentro de uma estratégia de engenharia contemporânea.

39. A mensagem escondida no console

Existe um easter egg nesta jornada.

O verdadeiro tema deste artigo nunca foi apenas Ansible.

Foi repetibilidade.

Um programa confiável produz resultados previsíveis.

Um job confiável pode ser reiniciado.

Uma transação confiável preserva consistência.

Uma automação confiável conduz o ambiente até um estado conhecido.

COBOL e Ansible nasceram em épocas diferentes, mas compartilham um valor fundamental:

sistemas empresariais precisam ser compreensíveis, controláveis e previsíveis.

O COBOL organiza regras de negócio.

O JCL organiza processamento batch.

O Ansible organiza operações e infraestrutura.

Eles não são inimigos de gerações diferentes.

São oficiais de departamentos diferentes servindo na mesma nave.

Conclusão — O Padawan assume o console

Você não precisa comprar uma licença especial nem construir um data center para começar.

Com um computador Windows 11, WSL 2, Ubuntu e algumas horas de prática, já é possível montar um excelente laboratório de Ansible.

Comece pequeno:

localhost

Depois instale:

Apache

Em seguida:

Java

Aprenda:

Inventários
Playbooks
Módulos
Variáveis
Handlers
Templates
Roles
Vault
Git

Só então avance para:

WebSphere
Linux remoto
Pipelines
IBM Z
z/OS
Ambientes híbridos

Não tente automatizar toda a galáxia no primeiro Playbook.

Automatize uma tarefa.

Teste.

Execute novamente.

Observe a idempotência.

Documente.

Versione.

Melhore.

Depois automatize a próxima.

O futuro do mainframe não será construído apenas por quem conhece tecnologias novas, nem apenas por quem conhece tecnologias antigas.

Será construído por profissionais capazes de fazer essas tecnologias trabalharem juntas.

E quando alguém perguntar:

“Um Programador COBOL realmente precisa aprender Ansible?”

Você poderá responder:

“Não preciso aprender para abandonar o mainframe. Preciso aprender para comandar tudo o que existe ao redor dele.”

Esse é o caminho do Programador COBOL Padawan.

Do terminal 3270 ao YAML.

Do JCL ao Playbook.

Do batch noturno à automação contínua.

Do porão da sala de máquinas à cadeira de comando.

Vida longa ao COBOL. Vida longa à automação. E que nenhum deployment seja realizado manualmente numa sexta-feira à noite.

Translate

sábado, 16 de maio de 2020

Ansible sem Mistérios no Windows

☕ Um Café no Bellacosa Mainframe

Ansible sem Mistérios no Windows

O guia do Programador COBOL Padawan para automatizar Linux, Apache, Java, WebSphere e IBM Z sem abandonar o legado

1. Afinal, o que é o Ansible?

2. Infraestrutura como código

3. Como o Ansible funciona?

4. O que significa dizer que o Ansible é “agentless”?

5. Posso instalar Ansible no Windows?

6. O que é WSL?

Easter egg da Frota Estelar

7. Passo a passo: instalando o WSL 2

8. Preparando o Ubuntu

9. Instalando o Ansible

10. Criando a estrutura do laboratório

11. Inventário: o mapa estelar do Ansible

12. O primeiro contato: o módulo ping

13. Coletando informações do Linux

14. O que é um Playbook?

15. Entendendo o YAML sem entrar em um buraco negro

Regra de ouro

16. Idempotência: a disciplina vulcana

17. Instalando Apache com Ansible

O que é become?

O que é um handler?

18. Instalando Java

19. Como o Ansible se relaciona com Java?

20. E o WebSphere?

Cuidado de Engenharia

21. Conectando Ansible ao IBM Z

22. Criando um Playbook conceitual para z/OS

23. Exemplo de inventário para IBM Z

24. Ansible e JCL: inimigos ou aliados?

25. Ansible, COBOL e DevOps

26. Segurança: nunca coloque senhas no Playbook

Regra de segurança da Frota

27. Modos seguros de teste

Verificar a sintaxe

Simular alterações

Mostrar diferenças

Limitar a execução

28. Use nomes que expliquem a operação

29. Não abuse dos módulos command e shell

30. Evoluindo para templates

31. Roles: transformando Playbooks em componentes reutilizáveis

32. Ansible Community e Ansible Automation Platform

33. Visual Studio Code como painel LCARS

34. Um laboratório com vários servidores

35. Plano de ação de 12 semanas

Semanas 1 e 2 — Academia da Frota

Semanas 3 e 4 — YAML e módulos

Semanas 5 e 6 — Apache e Java

Semanas 7 e 8 — Git e organização

Semanas 9 e 10 — IBM Z

Semanas 11 e 12 — Projeto final

36. Dez erros clássicos do Padawan

1. Aprender somente copiando Playbooks

2. Testar primeiro em produção

3. Armazenar senha no Git

4. Usar shell para tudo

5. Ignorar o inventário

6. Não usar nomes descritivos

7. Não verificar resultados

8. Confundir automação com ausência de controle

9. Ignorar versões

10. Querer automatizar sem conhecer o processo

37. Curiosidades da sala de máquinas

38. Por que um Programador COBOL deveria aprender Ansible?

39. A mensagem escondida no console

Conclusão — O Padawan assume o console

Sem comentários:

Enviar um comentário

O que é `become`?

4. Usar `shell` para tudo