Translate

Mostrar mensagens com a etiqueta Open Source. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Open Source. Mostrar todas as mensagens

segunda-feira, 23 de março de 2026

☁️💥 Do JCL ao Kubernetes: Como um Padawan Pode Dominar a Nuvem Sem Virar Vapor

 

Bellacosa Mainframe do JCL ao Kubernetes

☁️💥 Do JCL ao Kubernetes: Como um Padawan Pode Dominar a Nuvem Sem Virar Vapor

“Na galáxia da TI, alguns pilotam X-Wings… outros ainda estão aprendendo a ligar o hyperdrive.”

Se você é um Padawan da Cloud — ou até um Jedi do mainframe explorando novos planetas — este artigo é para você. Vamos atravessar juntos o caminho do zero até arquiteto, com exemplos reais, curiosidades, easter eggs e aquela pitada Bellacosa de conhecimento que não se aprende em slide corporativo. ☕🖥️☁️


🧠 Episódio I — O Despertar da Nuvem

Antes de containers, Kubernetes ou nomes complicados…

👉 Cloud é só alguém rodando computadores para você — em escala absurda.

No mundo on-premises:

  • Você compra hardware 💸
  • Instala tudo 🧱
  • Mantém tudo 🔧
  • Culpa o ar-condicionado quando cai 🧊

Na cloud:

  • Você aluga capacidade
  • Paga pelo uso
  • Escala sob demanda

💡 Curiosidade mainframe:
O modelo pay-per-use da cloud lembra MUITO o velho conceito de capacity on demand dos grandes sistemas.


🏗️ Episódio II — IaaS, PaaS, SaaS… ou “Quem Faz o Trabalho?”

Imagine que você quer comer pizza 🍕

  • 🧱 On-Prem → você planta o trigo, cria a vaca e assa
  • 🏗️ IaaS → você assa
  • ⚙️ PaaS → você só coloca o recheio
  • 🍕 SaaS → entregam pronta

👉 Quanto mais alto na pilha, menos trabalho (e menos controle).


🌍 Episódio III — Onde Mora a Nuvem?

Modelos de deployment:

  • ☁️ Public — infraestrutura compartilhada
  • 🏢 Private — exclusiva
  • 🌗 Hybrid — mistura dos dois
  • 🌍 Multicloud — vários provedores
  • 🤝 Community — organizações com interesses comuns

💡 Exemplo real:
Banco com dados críticos on-prem + analytics na nuvem = Hybrid.


📦 Episódio IV — Storage: O Cofre dos Dados

Três tipos dominam a galáxia:

🧱 Block Storage

Disco bruto — ideal para bancos.

👉 Pense: DASD virtual.


📂 File Storage

Pastas e arquivos hierárquicos.

👉 Tipo um compartilhamento NFS/SMB.


🎬 Object Storage

Para dados não estruturados:

  • Vídeos
  • Fotos
  • Logs
  • Backups

💡 Easter egg:
Object storage não tem “diretórios de verdade”. Aquela pastinha é só uma ilusão… tipo o Millennium Falcon parado no espaço.


🐳 Episódio V — Containers: O Segredo da Cloud Moderna

VMs são como apartamentos completos 🏢
Containers são kitnets minimalistas 🐳

Containers:

✔️ Mais leves
✔️ Iniciam rápido
✔️ Compartilham o kernel
✔️ Escalam fácil


🧾 Dockerfile — A Receita do Container

FROM ubuntu
COPY app /app
CMD ["./app"]

👉 Isso vira uma imagem → que vira container → que roda seu app.

💡 Comentário Bellacosa:
Se JCL descreve job steps… o Dockerfile descreve build steps.


☸️ Episódio VI — Kubernetes: O Maestro dos Containers

Se Docker cria containers, Kubernetes governa exércitos deles.

Principais conceitos:

  • Pod → unidade mínima
  • Node → máquina
  • Cluster → várias máquinas
  • Service → endereço fixo
  • Deployment → controla versões

🗄️ etcd — O Cérebro do Cluster

👉 Banco de dados que guarda TODO o estado.

Sem ele:

Kubernetes vira um amnésico digital.


⚡ Episódio VII — Serverless: Código Sem Servidor?

Sim e não.

Você não vê o servidor.

FaaS roda código:

  • Sob demanda
  • Escala automática
  • Paga só pelo uso

💡 Ideal para eventos, APIs simples e automações.


🔐 Episódio VIII — Segurança e Sensibilidade

Nem tudo deve ir para public cloud.

Private ou hybrid são comuns quando há:

  • Dados financeiros 🏦
  • Dados médicos 🏥
  • Segredos governamentais 🏛️

🤖 Episódio IX — Infraestrutura Imutável

Antigamente:

👉 Atualize o servidor.

Hoje:

👉 Destrua e recrie.

Isso reduz inconsistências e bugs misteriosos.

💡 Analogia:
Trocar a nave inteira em vez de consertar no espaço.


🧬 Episódio X — Cloud-Native vs Monólito

🧱 Monólito

Tudo num bloco só.

Vantagem: simples.
Desvantagem: difícil de escalar.


☁️ Cloud-Native

  • Microservices
  • APIs
  • Containers
  • Automação
  • Observabilidade

👉 Projetado para falhar e continuar funcionando.


🏆 Episódio XI — O Caminho do Arquiteto

Um arquiteto cloud não escolhe tecnologia… escolhe compromissos:

⚖️ Custo × Performance × Segurança × Resiliência

Princípios Jedi:

  • 🛡️ Design for failure
  • 📈 Scale out
  • 🔗 Loose coupling
  • 🤖 Automação
  • 💰 Otimização de custos

☕ Easter Egg Mainframe Edition

Cloud parece nova… mas várias ideias nasceram no mainframe:

  • Time sharing → multi-tenant
  • Capacity on demand → elasticidade
  • Virtualização → VMs
  • Alta disponibilidade → Sysplex

👉 A nuvem não reinventou a roda. Só colocou foguetes nela.


🚀 Missão Final para o Padawan

Se você quer evoluir de dev para arquiteto:

1️⃣ Entenda fundamentos
2️⃣ Aprenda containers
3️⃣ Domine Kubernetes
4️⃣ Explore serverless
5️⃣ Pense em arquitetura, não em código


🌟 Conclusão — Que a Força da Nuvem Esteja com Você

Cloud não é só tecnologia.

É uma nova forma de operar sistemas em escala planetária.

Você não precisa saber tudo.
Precisa saber como as peças se encaixam.

“Um Padawan aprende ferramentas.
Um Jedi entende sistemas.”

 

quarta-feira, 28 de janeiro de 2026

💥 Git no z/OS: O Casamento IMPROVÁVEL que Virou Revolução DevOps no Mainframe

 

Bellacosa Mainframe apresenta o GIT para padawans em Mainframe

💥 Git no z/OS: O Casamento IMPROVÁVEL que Virou Revolução DevOps no Mainframe


🧠 Contexto: Antes era “impossível”… hoje é padrão

Em 2018, falar de git rodando dentro do z/OS era quase heresia.

  • Não existia Z Open Automation Utilities
  • Open Source no mainframe? Ainda engatinhando
  • DevOps? Só no mundo distribuído

Hoje… 👇
👉 Temos comunidade ativa
👉 Bash rodando no USS
👉 Ferramentas open source integradas
👉 E sim… git funcionando NATIVAMENTE no z/OS

💣 Traduzindo: o mainframe deixou de ser isolado e entrou no jogo moderno.


🔗 Parte 1 — Conectando z/OS ao GitHub (SSH)

Aqui começa a mágica.

🧩 Problema clássico

z/OS “raiz” muitas vezes não tem DNS configurado.

🔧 Solução (tradução + comentário)

vi /etc/resolv.conf

Adicione:

nameserver 8.8.8.8

💡 Comentário Bellacosa:
Isso aqui parece simples, mas é o que separa você de:

❌ “Host desconhecido”
✔️ Integração com o mundo externo


🔄 Restart do resolver

opercmd "stop resolver"
opercmd "start resolver"

💥 Aqui entra realidade de mainframe:

  • Precisa permissão
  • Ou chama o sysprog amigo 😎

🔍 Teste de DNS

host github.com

Se vier IP → 🎯 sucesso


🔐 Parte 2 — Criando chave SSH (segurança de verdade)

ssh-keygen -t rsa -b 4096 -C "seu-email"

👉 Isso gera:

  • chave privada (fica no z/OS)
  • chave pública (vai pro GitHub)

🚀 Ativando agente SSH

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

📋 Copiando chave pública

vi ~/.ssh/id_rsa.pub

Cola no GitHub:

  • Settings
  • SSH Keys
  • New Key

💡 Insight Bellacosa:
Isso elimina senha.
Você entra no mundo:

👉 autenticação forte
👉 automação
👉 pipelines DevOps reais


🧰 Parte 3 — Instalando Git no z/OS

Aqui é onde muita gente trava.

📦 Solução moderna:

zopen install -y git

🔥 Isso instala:

  • git
  • dependências
  • bash (ESSENCIAL!)

💡 Tradução prática:
Você acabou de transformar seu z/OS em um mini Linux dentro do USS.


🧪 Testando conexão com GitHub

ssh git@github.com

Saída esperada:

You've successfully authenticated, but GitHub does not provide shell access.

💣 Isso aqui é perfeito.
Significa:

👉 conexão OK
👉 autenticação OK
👉 pronto pra usar git


⚙️ Parte 4 — Configuração do ambiente

Edite o profile:

vi ~/.profile

Adicione:

git config --global user.name "Seu Nome"
git config --global user.email "seu-email"
git config --global init.defaultBranch main
bash

💡 Insight poderoso:

👉 O bash aqui muda o jogo
👉 Você sai do shell limitado e entra num ambiente moderno


🔄 Reinicie sessão e valide

ps

Se aparecer:

bash

🎯 Missão cumprida


📂 Parte 5 — Clonando repositório

git clone git@github.com:usuario/repositorio.git
cd repositorio

💡 Aqui começa o DevOps REAL no mainframe.


🌿 Trabalhando com branch (fluxo moderno)

Criar branch

git checkout -b WordPressChange

Adicionar alteração

git add setenv.sh

Validar

git status

Commit

git commit

Enviar pro GitHub

git push origin WordPressChange

💥 TRADUÇÃO BELLACOSA:

Você acabou de fazer isso no z/OS:

👉 versionamento moderno
👉 branch strategy
👉 integração com GitHub
👉 colaboração distribuída

🔥 ISSO É DEVOPS NO MAINFRAME


🧠 Camada EXTRA — O que ninguém te conta

💣 1. USS é o segredo

Sem USS (Unix System Services), isso aqui não existiria.


💣 2. Git não entende dataset nativo

Você está trabalhando com:

👉 arquivos USS
👉 não diretamente com PDS/VSAM


💣 3. Ponte com COBOL

Fluxo real:

  1. Código COBOL no USS
  2. Versionado com git
  3. Deploy → dataset
  4. Compilação via JCL

🔥 Isso conecta dois mundos.


💣 4. Open Source salvando o mainframe

Sem a comunidade:

👉 nada disso existiria
👉 IBM acelerou depois


🧪 Exemplo real (mentalidade enterprise)

Imagine:

  • Squad distribuído
  • Dev Java + Dev COBOL
  • Pipeline CI/CD

👉 GitHub → z/OS → compile → deploy → CICS

🔥 Isso já é realidade hoje


🏁 Conclusão estilo Bellacosa

💥 O que antes era “mainframe isolado” virou:

👉 plataforma integrada
👉 DevOps-ready
👉 open source friendly

E o git?

👉 virou a ponte entre gerações de tecnologia


☕ Frase pra fechar no estilo raiz:

“O mainframe não ficou ultrapassado…
você que ainda não viu ele rodando com git.” 😎🔥

 

terça-feira, 1 de outubro de 2024

💻 Zowe: O Guia Completo de Server, CLI, SDK e Explorer para Mainframe

 

Bellacosa Mainframe apresenta o zowe 3.0

💻 Zowe: O Guia Completo de Server, CLI, SDK e Explorer para Mainframe

Se você está entrando no universo Zowe, seja para modernizar aplicações z/OS ou integrar ambientes DevOps, este guia é para você. Vamos destrinchar componentes do Zowe, pacotes de instalação, SDKs, CLI, Explorer e políticas de suporte, do jeito Bellacosa Mainframe: direto, didático e cheio de dicas de prova IBM.


1️⃣ O que é Zowe?

Zowe é um framework open source que permite que desenvolvedores, mesmo sem profundo conhecimento de z/OS, acessem e integrem recursos mainframe usando CLI, APIs REST e GUI.
Ele suporta tanto z/OS nativo quanto ambientes containerizados (Docker/Kubernetes), trazendo agilidade e modernidade para o mainframe.

Principais objetivos:

  • Tornar z/OS acessível a desenvolvedores modernos

  • Permitir integração com DevOps e pipelines CI/CD

  • Oferecer APIs REST, CLI e GUI para operações mainframe


2️⃣ Zowe Server Components

O Zowe Server é distribuído em vários componentes que podem rodar no z/OS ou em containers.

Principais componentes:

ComponenteFunçãoPlataforma
ZLUXGUI web para navegação e dashboardsz/OS / Container
API GatewayMediação e roteamento de APIs RESTz/OS / Container
ZSS (Zowe Security Server)Autenticação, autorização e gerenciamento de tokensz/OS
File Explorer APIServiços REST para manipulação de arquivos USS e PDSz/OS / Container

⚠️ Nota: O Zowe CLI não é um servidor — ele roda no cliente.

Pacotes de distribuição do Zowe Server

Zowe Server pode ser instalado usando diferentes formatos:

  • SMP/E Package – Método clássico IBM para z/OS (RECEIVE → APPLY → ACCEPT)

  • Convenience Build (.pax file) – Binários compactados para extração e instalação em USS

  • Docker Container – Permite execução em containers Linux/Kubernetes

Dica Bellacosa: .msi e .deb não são usados para Zowe Server; eles são apenas para clientes ou sistemas externos.


3️⃣ Instalando Zowe via SMP/E

O SMP/E package contém:

  • FMID do Zowe (compactado em .pax)

  • Program Directory

  • Jobs auxiliares para instalação

Passo a passo:

  1. Transferir o arquivo .pax para o USS

  2. Extrair o conteúdo

  3. Usar SMP/E commands: RECEIVE, APPLY, ACCEPT

  4. Aplicar PTFs de correções ou atualizações

Atenção: após a instalação, é necessário criar instância Zowe, configurar segurança e iniciar started tasks. Não basta instalar o FMID.


4️⃣ Zowe CLI – A linha de comando

O Zowe CLI é um cliente que roda em Windows, Linux ou macOS.
Ele permite que você consuma APIs REST, interaja com USS, DB2, Jobs e muito mais, sem precisar abrir TSO ou ISPF.

Pré-requisitos:

  • Node.js + npm instalado no sistema

Comandos básicos de instalação:

npm install -g @zowe/cli zowe plugins install <plugin-name> zowe profiles create zosmf-profile

Dicas de uso:

  • Cada máquina que usa o CLI precisa de sua própria instalação

  • Você pode criar profiles para armazenar endereços de host e credenciais

  • É possível instalar múltiplos plug-ins para estender funcionalidades


5️⃣ Zowe Client SDKs

Zowe oferece SDKs para Python e Node.js, permitindo desenvolver scripts e aplicações customizadas usando APIs Zowe.

Instalação:

  • Python SDK:

pip install zowe_zos_files_for_zowe_sdk-<version>.whl
  • Node.js SDK:

npm install @zowe/core-for-zowe-sdk

Dica Bellacosa: Python SDK usa pip e Node.js SDK usa npm. Não confunda os dois!


6️⃣ Zowe Explorer – GUI no VSCode

O Zowe Explorer é uma extensão para VSCode, permitindo interações gráficas com z/OS.

Requisitos:

  • VSCode instalado

  • Perfis Zowe ou Zowe Team configurados (TCP/IP + credenciais)

Funcionalidades:

  • Navegação visual de USS e PDS

  • Execução de jobs TSO

  • Extensibilidade via VSCode APIs ou Zowe Explorer APIs

Dica: extensões adicionais podem ser criadas para expandir o Zowe Explorer.


7️⃣ Suporte das versões Zowe

A política de suporte segue o modelo clássico Active / Maintenance / End-of-Support:

VersãoStatusReleases / Correções
V3.x.xActiveNovas funcionalidades a cada 6 semanas + fixes críticos e de segurança
V2.x.xMaintenanceApenas fixes críticos e de segurança, sem novas funcionalidades
V1.x.xEnd-of-SupportNenhum fix, nenhuma atualização

Atenção a pegadinhas de prova IBM:

  • Active = novas features + fixes

  • Maintenance = apenas fixes críticos

  • End-of-Support = nada


8️⃣ Conclusão

Zowe é a porta de entrada moderna para o mainframe, combinando:

  • Zowe Server (z/OS ou container)

  • Zowe CLI (Windows/Linux/macOS)

  • Zowe SDKs (Python/Node.js)

  • Zowe Explorer (GUI VSCode)

Se você quer dominar DevOps mainframe, integração z/OS e modernização de aplicações, Zowe é o seu aliado.

💡 Dica final Bellacosa Mainframe: memorize Server vs Client vs SDK vs Explorer, entenda instalação, perfis e suporte, e nunca confunda pip vs npm vs SMP/E. Isso salva em prova IBM e na vida real.