O que é DevOps de verdade (e o que não é) – Guia Sysadmin Urbano 2025

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 que é DevOps de verdade (e o que não é)

DevOps é, provavelmente, uma das palavras mais mal interpretadas da TI moderna. Entre slogans de marketing e confusões internas, a essência de DevOps muitas vezes se perde.

Hoje, vamos esclarecer o que DevOps realmente significa — e, tão importante quanto, o que ele definitivamente não é.

1. DevOps é Cultura, Não Cargo

DevOps é um conjunto de práticas que une desenvolvimento e operações, com o objetivo de acelerar entregas de software de forma segura e confiável. Ele é, antes de tudo, uma mudança de mentalidade organizacional.

DevOps não é um "cargo de DevOps Engineer" que trabalha isoladamente. Se apenas uma pessoa carrega o "peso do DevOps", a empresa não entendeu o conceito. DevOps é **cultura compartilhada** — times inteiros operando com responsabilidade mútua pelo ciclo de vida das aplicações.

2. DevOps Não é Ferramenta

Ferramentas são parte da implementação de práticas DevOps — mas elas, por si só, **não são DevOps**.

Jenkins, Kubernetes, Terraform, GitLab CI — todas são ferramentas que ajudam a praticar automação, integração contínua e entrega contínua. Porém, adotar essas tecnologias sem mudanças de processo, comunicação e mentalidade é apenas modernizar o caos.

3. DevOps é Comunicação Eficiente

Se um pipeline automatizado gera uma falha, mas ninguém da equipe de desenvolvimento e operações conversa sobre isso, o DevOps morreu ali.

Comunicação aberta, rápida e objetiva entre times é a fundação para que o ciclo DevOps realmente funcione: planejar, construir, testar, lançar, operar, monitorar e aprender continuamente.

4. DevOps Exige Confiança Mútua

Uma organização que pune experimentação e erro não está pronta para DevOps. Cultura de confiança significa permitir que times falhem rapidamente, aprendam rapidamente e melhorem continuamente sem medo de retaliação.

Quando um sysadmin não confia nos testes automatizados, ou quando o desenvolvedor não confia no time de operações, o ciclo quebra.

5. DevOps Não Substitui o SysOps

Outro mito comum: "Com DevOps, não precisamos mais de times de operações." Errado.

DevOps aumenta a colaboração, mas a necessidade de especialistas em infraestrutura, segurança, redes e sistemas operacionais **não desaparece** — apenas muda de formato.

Infraestrutura continua sendo a base invisível que sustenta o delivery de software. Sem uma base sólida, a automação não salva ninguém.

Conclusão

DevOps não é mágica. Não é apenas ferramenta. Não é título de LinkedIn.

DevOps é prática contínua, é cultura de responsabilidade conjunta, é automação com propósito, é comunicação real entre pessoas técnicas.

Se você quer "fazer DevOps", comece mudando como seus times colaboram — antes de sair instalando novas ferramentas.

DevOps de verdade é humano, difícil, mas profundamente transformador.

Sobre o Sysadmin Urbano

O Sysadmin Urbano nasceu da vivência real no front das operações de infraestrutura moderna. Aqui falamos de servidores, containers, automação, boas práticas e também dos desafios invisíveis da rotina de quem mantém sistemas vivos. Sem fórmulas mágicas, sem tutoriais pela metade — apenas conteúdo prático, direto e feito para quem sabe que a TI é tanto técnica quanto sobrevivência.

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

Waiting for confirmation of MySQL service startup...

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

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

Docker travado em “Waiting for confirmation of MySQL service startup”

Esse erro, apesar de simples à primeira vista, é um dos travamentos mais silenciosos e frustrantes ao tentar migrar containers MySQL. Logo após o primeiro docker run, o container trava antes mesmo de subir:

Waiting for confirmation of MySQL service startup

Esse tipo de erro normalmente indica que algo no volume de dados está impedindo a inicialização do banco, e o entrypoint padrão do container está preso esperando algo que não virá.

🔍 Possíveis causas

• Volume com dados parcialmente migrados ou corrompidos
• Permissões erradas nos arquivos do MySQL
• Arquivos de instalação (como ibdata1, auto.cnf) presentes mas inválidos
• Configuração personalizada my.cnf quebrada ou incompatível

🛠️ Como resolver

1️⃣ Testar sem volume

Rode o container limpo, sem montar volume. Se funcionar, o problema está nos dados:

docker run -e MYSQL_ROOT_PASSWORD=test --rm mysql:5.7

2️⃣ Verificar estrutura do volume

Confira se o volume está realmente com os arquivos corretos do MySQL:

ls -la /var/lib/mysql

Se necessário, corrija permissões:

chown -R mysql:mysql /var/lib/mysql

3️⃣ Apagar arquivos de PID ou socket

Se você migrou arquivos com o banco ligado, talvez arquivos "fantasmas" estejam bloqueando o start:

rm -f /var/run/mysqld/mysqld.pid
rm -f /var/run/mysqld/mysqld.sock

4️⃣ Ver logs detalhados

Use essas variáveis para visualizar o que está acontecendo:

-e MYSQL_LOG_CONSOLE=true
--log-error-verbosity=3

5️⃣ Teste interativo

Entre no container antes do daemon tentar iniciar:

docker run -it --rm -e MYSQL_ROOT_PASSWORD=test mysql:5.7 bash
mysqld --initialize --user=mysql
mysqld
  

Isso revelará erros internos antes que o script padrão tente inicializar o banco e trave.

"Nem sempre o MySQL trava por estar corrompido. Às vezes ele só está perdido em um novo lugar, tentando achar o caminho de casa."

Ao migrar um container MySQL, certifique-se de que os dados estão íntegros, as permissões corretas e o ambiente limpo. Um banco de dados exige cuidado — mesmo em um mundo de containers descartáveis.

Migrando Containers

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

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

Como Migrar um Container Docker para Outro Servidor

Saiba como transportar containers e volumes com segurança entre máquinas diferentes usando comandos simples.

📦 Método 1: Exportar container e volumes manualmente

1. Crie a imagem a partir do container

docker commit meu_container minha_imagem:latest

2. Exporte a imagem para um arquivo

docker save minha_imagem:latest -o minha_imagem.tar

3. Exporte dados do volume (se aplicável)

tar czf meus_dados.tar.gz /caminho/do/volume

4. Transfira para o novo servidor

scp minha_imagem.tar meus_dados.tar.gz usuario@servidor:/caminho/destino

5. Importe a imagem e os dados no novo host

docker load -i minha_imagem.tar
tar xzf meus_dados.tar.gz -C /caminho/destino

6. Suba novamente o container

docker run -d -v /caminho/destino:/dados minha_imagem

🧩 Método 2: Usando Docker Compose (ideal para múltiplos serviços)

1. Copie o arquivo docker-compose.yml e os volumes

Garanta que os dados estejam compactados ou montados via diretórios locais.

2. No novo servidor, execute:

docker-compose up -d

Essa abordagem é mais prática para aplicações complexas ou multi-containers.

"Containers são passageiros, mas dados são valiosos. Cuide da migração de ambos."

Sobre o Sysadmin Urbano

O Sysadmin Urbano nasceu da vivência real no front das operações de infraestrutura moderna. Aqui falamos de servidores, containers, automação, boas práticas e também dos desafios invisíveis da rotina de quem mantém sistemas vivos. Sem fórmulas mágicas, sem tutoriais pela metade — apenas conteúdo prático, direto e feito para quem sabe que a TI é tanto técnica quanto sobrevivência.

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

Como expurgar binlogs do MySQL

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

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

Como expurgar binlogs do MySQL quando a partição está 100% cheia

O que fazer quando o disco enche e o MySQL trava por conta dos binlogs acumulados.

📦 O problema

Quando a partição do servidor MySQL atinge 100% de uso, o banco de dados não consegue mais gravar novos arquivos binários nem atualizar o index (mysql-bin.index), impedindo o expurgo automático dos binlogs antigos.

🔧 Solução recomendada (com MySQL parado)

1. Pare o MySQL

sudo systemctl stop mysql

2. Acesse a pasta dos binlogs

cd /var/lib/mysql

3. Liste os arquivos e remova os antigos manualmente

ls -lh mysql-bin.*
sudo rm mysql-bin.000001 mysql-bin.000002

4. Edite o index mysql-bin.index

Remova as linhas que apontam para os arquivos deletados:

sudo nano mysql-bin.index

5. Inicie novamente o MySQL

sudo systemctl start mysql

💡 Alternativa com o MySQL em execução

Caso o MySQL ainda esteja rodando (com algum espaço livre):

PURGE BINARY LOGS TO 'mysql-bin.000010';

ou:

PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;

✅ Dica de prevenção

Adicione ao seu my.cnf:

expire_logs_days = 7
max_binlog_size = 100M

"Às vezes, apagar com cuidado é a melhor forma de manter o controle."

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.

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.