Usando Podman + Podman Compose com Imagens do Harbor

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Usando Podman e Podman Compose com Imagens do Harbor: Configurações, Alternativas e Boas Práticas

Introdução

Em ambientes modernos de DevOps e infraestrutura como código, o uso de containers é central para isolar serviços, distribuir aplicações e garantir portabilidade. Enquanto o Docker é amplamente conhecido, o Podman tem se consolidado como uma alternativa sólida e mais segura. Ele elimina o daemon, permite execução rootless e segue o padrão OCI.

Neste artigo, vamos integrar o Harbor (registry privado de containers) com o Podman, abordando duas abordagens distintas:

• Uso direto com o Podman
• Gerenciamento orquestrado com o Podman Compose

Além disso, vamos configurar corretamente o uso de registries privados (com ou sem TLS), ajustar permissões, discutir boas práticas e entender quando usar cada modelo.

1. Instalando o Podman

RHEL / Oracle Linux / CentOS

sudo dnf install -y podman

Ubuntu / Debian

sudo apt update
sudo apt install -y podman

Verifique a instalação:

podman --version

2. Configurando acesso ao Harbor

Faça login (se necessário):

podman login harbor.seuservidor.com

2.1 Usando registries sem HTTPS (HTTP)

sudo mkdir -p /etc/containers/registries.conf.d
sudo nano /etc/containers/registries.conf.d/harbor.conf

Adicione:

[[registry]]
prefix = "harbor.seuservidor.com"
location = "harbor.seuservidor.com"
insecure = true

3. Puxando e rodando imagens do Harbor com Podman

podman pull harbor.seuservidor.com/devops/nginx-custom:1.0

podman run -d --name webapp \
  -p 8080:80 \
  harbor.seuservidor.com/devops/nginx-custom:1.0

• -d: executa o container em segundo plano (detached mode)
• --name: define um nome identificável para o container
• -p 8080:80: expõe a porta 80 do container na porta 8080 do host

Verificando a execução

podman ps

Isso mostrará todos os containers em execução, com ID, nome e portas mapeadas.

Acessando o serviço

Se o container oferece uma API ou serviço web, você pode testá-lo com:

curl http://localhost:8080

Ou acessando diretamente pelo navegador: http://localhost:8080

4. Alternativa: Usando Podman Compose

Para projetos com múltiplos serviços:

4.1 Instalação

pip install podman-compose

python3 -m venv venv
source venv/bin/activate
pip install podman-compose

5. Estrutura de Projeto

meu-app/
├── docker-compose.yml
└── .env (opcional)

Exemplo de docker-compose.yml

version: "3"
services:
  web:
    image: harbor.seuservidor.com/devops/nginx-custom:1.0
    ports:
      - "8080:80"
    restart: always

6. Subindo os serviços

podman-compose up -d

podman-compose logs

podman ps

podman-compose down

7. Comparativo: Podman direto vs Podman Compose

Critério	Podman (direto)	Podman Compose
Complexidade	Baixa	Média
Multi-serviços	Manual	Gerenciado via YAML
Escalabilidade	Limitada	Modular
Controle de rede	Simples	Mais granular
Ideal para	Containers isolados	Projetos multi-serviço

8. Boas práticas

• Armazene as credenciais com segurança.
• Evite usar a tag latest em produção.
• Use versões fixas para garantir reprodutibilidade.
• Crie redes próprias para isolar serviços:

podman network create meu_rede

Conclusão

Integrar o Harbor com Podman (com ou sem Compose) permite controle total sobre suas imagens, com mais segurança e independência do Docker daemon. O Podman direto é ideal para containers rápidos e isolados, enquanto o Compose se destaca em ambientes mais complexos.

Nos próximos capítulos, vamos explorar volumes persistentes, redes customizadas e estratégias de deploy em produção.

Por que não usar CentOS 8?

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

CentOS 8 - Downstream vs Upstream e alternativas viáveis

Para quem está acostumado com a confiabilidade e estabilidade de sistemas Linux em ambientes de produção, o CentOS sempre foi uma escolha quase automática. Gratuito, estável e baseado diretamente no RHEL (Red Hat Enterprise Linux), o CentOS tradicional era um clone fiel – o famoso downstream. Mas tudo mudou com o CentOS 8.

O que aconteceu com o CentOS 8?

A Red Hat anunciou que o CentOS 8 deixaria de ser uma reconstrução do RHEL para se tornar o CentOS Stream, um projeto upstream. Em termos práticos, isso significa que o CentOS deixou de ser um reflexo fiel das versões estáveis do RHEL para se tornar um laboratório, uma prévia do que poderá ou não entrar na próxima versão do RHEL.

Isso causou grande preocupação na comunidade e em administradores de sistemas. Afinal, o CentOS era utilizado em larga escala em produção exatamente por sua estabilidade herdada do RHEL. Com a mudança para upstream, ele passou a oferecer versões de pacotes mais recentes, ainda em testes ou ajustes, o que quebra o princípio de previsibilidade em ambientes críticos.

Downstream vs Upstream: Qual a diferença?

• Upstream: é a fonte. Tudo que é testado, proposto, ou modificado começa aqui. Bugs e novas features são esperadas.
• Downstream: é o refinado. O código já passou por testes rigorosos, correções e estabilização. É onde se busca confiabilidade.

O CentOS tradicional era um downstream do RHEL. O CentOS Stream, atual, é um degrau acima do RHEL. Ele recebe atualizações antes do Red Hat – e isso pode parecer bom, mas para produção, significa riscos.

Quais alternativas considerar?

A substituição do CentOS tradicional exige reflexão. Felizmente, surgiram projetos que retomam sua proposta original. Aqui estão os principais:

• AlmaLinux: projeto comunitário mantido pela CloudLinux. Totalmente compatível com RHEL, serve como downstream puro.
• Rocky Linux: fundado por um dos criadores originais do CentOS. Tem como missão continuar o legado do CentOS como distribuição estável para produção.
• Oracle Linux: também compatível com RHEL. Apesar de ser mantido pela Oracle, é gratuito e vem ganhando adeptos, especialmente pela opção de kernel otimizado (UEK).

Conclusão

A mudança do CentOS 8 para um modelo upstream não é "errada" — ela atende aos interesses de desenvolvimento da Red Hat. No entanto, para quem busca um sistema estável, confiável e previsível, é preciso olhar para alternativas que mantenham o conceito de downstream. AlmaLinux e Rocky Linux se tornaram, hoje, os principais herdeiros naturais do CentOS clássico.

A escolha do sistema operacional para seu datacenter ou ambiente corporativo deve sempre passar por testes e planejamento. Mas uma coisa é certa: CentOS 8 deixou de ser a solução ideal para produção.

IPv6 em Datacenters – Parte 4

IPv6 em Datacenters – Parte 4: Dual Stack na Prática

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

O sonho de uma internet totalmente em IPv6 ainda não é uma realidade para a maioria dos datacenters — e por isso, a coexistência de IPv4 e IPv6 continua sendo um desafio técnico e estratégico. Essa abordagem é conhecida como dual stack, e apesar de parecer simples na teoria, sua implementação exige atenção e planejamento.

Por que dual stack?

Porque apesar de o IPv6 resolver de forma definitiva a escassez de endereços, muitos sistemas, provedores, clientes e aplicações ainda dependem de IPv4. Adotar dual stack permite transicionar sem interromper serviços nem limitar a interoperabilidade com o mundo externo.

Principais desafios

• Duplicação de regras: Toda configuração de firewall, roteamento, NAT ou DNS precisa existir para ambas as pilhas.
• Testes em dobro: O monitoramento deve verificar se os serviços estão acessíveis em AAA.AAA.AAA.AAA e em 2001:db8::/32.
• Comportamentos inesperados: Alguns aplicativos escolhem automaticamente IPv6 (se disponível), o que pode causar problemas se a pilha não estiver bem configurada.
• Segurança: IPv6 pode “vazar” por túneis automáticos ou interfaces desprotegidas se não houver vigilância.

Boas práticas para uma operação dual stack eficiente

• Separar serviços internos e externos por políticas claras de rede: use IPv6 apenas quando necessário em aplicações críticas.
• Evite NAT64 e DNS64 salvo se estiver migrando serviços antigos sem dual stack.
• Eduque sua equipe: DNS reverso em IPv6 funciona de forma distinta. Ferramentas como ping6 e traceroute6 são essenciais.
• Documente rotas, sub-redes e escopos: A complexidade do IPv6 exige visibilidade e controle.

Validação e testes

Algumas abordagens úteis incluem:

• Rodar serviços locais com ::1 e 127.0.0.1 e validar comportamento cruzado
• Simular ambientes externos com NAT66 (quando possível)
• Ferramentas como nmap, ip -6 route, netstat -6, ss -6

Conclusão

Operar em dual stack é como viver em dois mundos ao mesmo tempo — exige consciência das regras, sincronia nas configurações e capacidade de identificar o que está funcionando em qual pilha. Mas também é o caminho mais seguro e compatível para datacenters que desejam migrar com responsabilidade.

Na próxima parte, vamos explorar segurança em ambientes IPv6, com foco em ataques modernos e proteções nativas.

IPv6 em Datacenters – Parte 3

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

IPv6 em Datacenters – Parte 3: Alta Disponibilidade, Failover e Continuidade

Adotar IPv6 em um ambiente corporativo não significa apenas substituir endereços. Significa repensar a forma como tratamos a disponibilidade de serviços. Nessa terceira parte, exploramos o uso do IPv6 em estruturas de alta disponibilidade (HA), focando em clusters, balanceadores, firewalls e testes de failover — sempre com um olhar técnico e prático.

🌐 Balanceadores e IPs flutuantes

Diferente do IPv4, no IPv6 não há NAT tradicional. Assim, o uso de endereços IPs globais diretos demanda novos cuidados.

• Utilize VRRPv3 com ferramentas como keepalived, que suporta endereços IPv6 nativamente.
• IP flutuante pode ser definido em /128 para vincular a apenas um nó por vez.

vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 50
  priority 100
  advert_int 1
  virtual_ipaddress {
    2001:db8::100/128
  }
}

🧱 HAProxy e NGINX com IPv6

Ambos suportam IPv6 diretamente e podem atuar como ponto único de entrada para clusters:

• bind [::]:443 ssl para escutar em IPv6;
• Backends podem ser definidos por IP ou DNS com registros AAAA;
• Para failover ativo/passivo, combine com keepalived ou Pacemaker.

🔁 Clusters com IPv6

Banco de Dados (PostgreSQL, MariaDB)

• Ambos suportam IPv6 nativamente;
• Em postgresql.conf, use listen_addresses = '*' e valide que o sistema escuta em IPv6.
• Utilize VIPs via Pacemaker para failover entre nós.

Servidores Web ou Aplicações

• Usar DNS com TTL baixo para atualização rápida em falhas;
• Considere IPv6-only para redes internas e dual-stack na borda.

🔐 Firewalls e segurança no failover

• As regras devem permitir tráfego de anúncios de VRRPv3 (protocol 112);
• Se usar nftables, crie conjuntos para os IPs flutuantes;
• Evite regras fixas por interface: use por endereço, garantindo portabilidade entre nós.

🧪 Testes e observabilidade

• Simule falhas desligando serviços e valide failover do VIP;
• Use tcpdump -i eth0 ip6 and vrrp para analisar pacotes de failover;
• Prometheus com blackbox_exporter permite pingar endpoints IPv6 e medir latência.

📌 Dica prática

Use scripts automáticos (Ansible, Bash) para verificar se o IP flutuante foi realocado após falha. Uma simples checagem com ip -6 addr já mostra a transição.

🔚 Conclusão

Alta disponibilidade com IPv6 é um passo além da adaptação de endereços. Envolve um novo entendimento da conectividade direta, da ausência de NAT e da transparência de rede. Com testes adequados e validação, seu datacenter pode ter um ambiente resiliente, moderno e alinhado com o futuro da internet.

IPv6 em Datacenters – Parte 2

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

IPv6 em Datacenters – Parte 2: Integração com Monitoramento, Automação e Segurança

Após estruturar a arquitetura de endereçamento com IPv6 em um datacenter, o próximo passo é integrar esse ecossistema com as ferramentas de gestão, automação e segurança já utilizadas no ambiente. Essa etapa é essencial para garantir visibilidade, controle e estabilidade operacional.

📊 Integração com ferramentas de monitoramento

Zabbix

• O Zabbix suporta IPv6 nativamente, tanto para agentes quanto servidores.
• No zabbix_agentd.conf, use ListenIP=:: para aceitar conexões IPv6.
• No frontend, cadastre os hosts com IPs IPv6 diretamente ou use DNS AAAA.

# Exemplo de item com IPv6
zabbix_get -s fd00:abcd::1001 -k system.uptime

Prometheus

• Configure os targets com IPs IPv6 dentro de colchetes: [fd00::2001]:9100
• Certifique-se de que os node_exporters estão escutando em [::]:9100

Grafana e InfluxDB

• Suporte total a conexões em IPv6 se as ferramentas forem configuradas para escutar em [::]
• Use proxies reversos (como Nginx) para centralizar acessos IPv6/IPv4.

⚙️ Automação com Ansible e Shell

• Adicione hosts em IPv6 no inventário: [meus_servers]
[fd00::1001]
• Use o parâmetro ansible_ssh_extra_args='-6' para forçar IPv6.
• Evite dependência de DNS se usar endereços diretos.

[web_ipv6]
fd00:abcd::10 ansible_user=admin ansible_ssh_extra_args='-6'

🛡️ Segurança e firewalls para IPv6

• Use nftables ou ip6tables separadamente do IPv4.
• Habilite ICMPv6 essencial para funcionamento correto da rede (RA, ND).
• Crie regras por prefixo e não apenas por IP direto, ex: fd00::/8
• Bloqueie endereços de escopo global para tráfego interno não autorizado.

🔐 Validações e auditoria

• ping6 e traceroute6 para diagnóstico de latência e roteamento
• nmap -6 para varredura de portas e validação de exposição de serviços
• Ferramentas como tcpdump -i eth0 ip6 são vitais para depuração

📌 Dica importante

Evite misturar stacks duplas mal configuradas (dual-stack desbalanceado) em serviços críticos. Priorize ambientes 100% IPv6 ou 100% IPv4 onde for possível.

🧭 Conclusão

Integrar IPv6 não é apenas configurar IPs. Envolve ajustar toda a cadeia de operações — do monitoramento à automação, da segurança à validação. Com isso, o datacenter se torna mais escalável, moderno e pronto para o futuro.

IPv6 para Datacenters - parte 1

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Implementação Completa de IPv6 para Datacenters

No universo moderno de redes, o suporte ao IPv6 deixou de ser uma opção e passou a ser uma necessidade real para ambientes de datacenter, especialmente com a escassez de IPv4 e o crescimento de ambientes escaláveis em cloud e bare metal.

📌 Divisão lógica: Pública e Privada

Ao contrário do IPv4, o IPv6 não possui faixas NAT privadas clássicas. Mas é possível utilizar as faixas fd00::/8 para simular redes internas privadas (ULA – Unique Local Address).

• Rede pública: usada para frontend, acesso externo, APIs abertas.
• Rede ULA (fd00): usada para comunicação entre bancos de dados, aplicações, serviços internos e recursivos (como DNS).

🔧 Configuração típica de componentes internos

• Servidores e VMs: Defina endereços ULA por interface, ex: fd00:abcd:1234::10
• Bancos de Dados: Vincule ao IP ULA e restrinja conexões com bind-address ou listen_address
• DNS Recursivo (ex: Unbound): Use somente ULA como origem permitida e configure escopo local
• Hypervisores e switches virtuais: Separe VLANs ou bridges por finalidade (pública / interna)
• Firewalls: Permita ICMPv6 e controle com precisão os escopos de IP

🧪 Exemplo de configuração prática

# Interface interna
iface eth1 inet6 static
  address fd00:abcd:1234::1
  netmask 64

# Exemplo de configuração no Postgres
listen_addresses = 'fd00:abcd:1234::10'

🛡️ Segurança e performance

• Utilize ip6tables ou nftables com políticas explícitas.
• Monitore tráfego com tcpdump -i eth0 ip6 ou iftop.
• Prefira endereços estáticos para facilitar debugging e regras claras.

📐 Diagramas e hierarquia

Uma estrutura bem pensada facilita a escalabilidade e troubleshooting. Exemplo:

• Hypervisor: fd00:1000::1
• VM Web: fd00:1000::10
• DB: fd00:1000::20
• DNS interno: fd00:1000::53

✅ Validação da estrutura

• Ping ULA entre serviços: ping6 fd00:abcd:1234::10
• Valide com traceroute6, nmap -6, e testes de aplicação
• Documente rotas e relacionamentos lógicos (topologias simples ajudam muito)

📌 Conclusão

O uso de IPv6 vai além da camada de acesso externo. Integrá-lo de forma completa no ambiente interno — com camadas de segurança e isolamento — é o próximo passo na evolução de um datacenter moderno.

IPv6 pode parecer complexo no início, mas ao entender seus conceitos fundamentais, ele se torna um aliado poderoso em ambientes escaláveis e limpos.

IPv6 DC

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Boas Práticas de IPv6 para Datacenters

Com a progressiva adoção do IPv6 em ambientes corporativos e datacenters, torna-se essencial compreender como planejar e aplicar boas práticas tanto na estrutura de rede externa quanto internamente — entre servidores, aplicações e sistemas de suporte.

🌐 Rede externa: visibilidade e roteabilidade

Diferente do IPv4, onde comumente usamos blocos privados (como 10.0.0.0/8 ou 192.168.0.0/16), o IPv6 não utiliza o conceito de IPs não roteáveis da mesma forma. Cada datacenter deve provisionar um bloco de endereços globais válidos e usar políticas de roteamento e firewall bem definidas para isolar segmentos.

🏗️ Segmentação interna: como substituir a NAT

No lugar da NAT, utiliza-se o controle de acesso por ACLs, firewalls e roteamento segmentado. Internamente, recomenda-se usar sub-redes /64 para cada rede lógica (ex: servidores de aplicação, banco de dados, infraestrutura).

🗄️ Aplicações e banco de dados

As aplicações devem ser preparadas para aceitar e registrar endereços IPv6. Evite hardcoding de IPs e utilize DNS sempre que possível. Para bancos de dados, certifique-se de configurar corretamente o listener IPv6 e as permissões de acesso baseadas no endereço.

🔁 DNS recursivo e IPv6

Em ambientes IPv4, é comum usar um IP privado fixo (como 10.0.0.53) para o DNS interno. Com IPv6, recomenda-se usar endereços ULA (Unique Local Address) do prefixo fd00::/8 para serviços internos como DNS recursivo, mantendo a segmentação segura e não roteável externamente.

“IPv6 não é apenas uma substituição. É uma reestruturação da forma como pensamos redes internas e segurança.” — Adaptado

🔐 Considerações finais

IPv6 elimina muitas das gambiarras que criamos com NAT e endereços privados. Porém, ele exige maturidade: seus controles de acesso, roteamento e segmentação precisam ser muito mais bem planejados. A migração para IPv6 em um datacenter deve vir acompanhada de uma revisão conceitual — e não apenas de uma troca de IP.