E-book - SRE na prática (Free)

Fala pessoal, blz?

Confiabilidade não acontece por sorte. Ela é medida, combinada e construída no dia a dia. Foi com essa ideia que eu escrevi o e-book gratuito SRE na Prática, um guia direto ao ponto para quem quer sair do modo "apagar incêndio" e operar sistemas com metas claras, alertas úteis e menos incidentes repetidos.

O problema da maioria dos times não é falta de ferramenta. É excesso de sinal e falta de critério. Painéis cheios de gráficos, alertas tocando de madrugada, discussões intermináveis entre quem quer entregar rápido e quem não quer que nada quebre. Sem números, toda decisão vira opinião.

"Podemos fazer o deploy hoje?"

"Esse alerta precisava mesmo acordar alguém?"

"Quanto de instabilidade o nosso usuário aguenta?"

O SRE responde essas perguntas com engenharia: indicadores, metas e um orçamento de erros que transforma a briga entre velocidade e estabilidade em uma conta simples.

O que você vai encontrar no e-book?

01. De onde vem o SREA origem no Google e a diferença entre SRE, DevOps e operação tradicional.

02. Fundamentos e toilOs seis pilares, a regra dos 50% e como medir e eliminar trabalho manual.

03. SLI, SLO e SLA na práticaComo escolher indicadores pela jornada do usuário e medir com Prometheus.

04. Error budgetPolítica por faixas, tabela de indisponibilidade e alertas por burn rate.

05. Rotina operacionalSinais de ouro, plantão sustentável, incidentes, runbooks e postmortem sem culpa.

06. Plano de 90 diasUm caminho realista para começar e um checklist de maturidade.

  Algumas páginas do e-book: exemplos reais, tabelas e modelos prontos.

Material para usar, não só para ler

• Consultas PromQL para medir disponibilidade e latência.
• Regras de alerta por burn rate prontas para adaptar.
• Modelo de documento de SLO e política de error budget.
• Runbook de exemplo com comandos de diagnóstico e rollback.
• Modelo de postmortem sem culpa.

Plano de 90 dias e checklist de maturidade em SRE.

Para quem é este e-book?

Para quem trabalha com infraestrutura, cloud, DevOps ou desenvolvimento e participa da operação em produção. E também para quem está entrando na área e quer entender, com exemplos concretos, como os times modernos mantêm sistemas confiáveis.

E-book gratuito · PDF

SRE na Prática

33 páginas com conceitos, exemplos e modelos prontos para aplicar no seu ambiente.

Baixar o e-book grátis PDF · 33 páginas · sem cadastro

Menos incêndio. Mais engenharia. Sistemas em que o usuário pode confiar.

Se o material te ajudar, compartilha com alguém do seu time ou com quem está começando na área. E se tiver dúvidas, sugestões de tema ou quiser contar como está aplicando SRE aí, me escreve: icenex.adm@gmail.com.

Abs e até a próxima.

Sua landing page profissional em minutos!

Fala pessoal, tudo bem?

João aqui!

Ainda hoje, muitos se perguntam se ainda vale a pena ter um site, se é necessário ou até mesmo pq meu negócio precisa de um?

Ou até no formato "mais moderno", pq preciso de uma landing page?

Transformar visitas em clientes potenciais

#conversão

Uma pessoa pode visitar seu perfil, gostar do que vê e ir embora sem entrar em contato. Uma Landing Page direciona essa pessoa para uma ação clara: solicitar orçamento, agendar atendimento, baixar um material ou comprar.

Como vender:

“Não basta atrair pessoas para o seu negócio. Você precisa facilitar o próximo passo.”

Não depender exclusivamente das redes sociais

#controle

O Instagram é excelente para descoberta, relacionamento e conteúdo, mas o formato e as regras da plataforma não estão sob o controle da empresa. Uma Landing Page oferece um destino próprio para campanhas, contatos e ofertas.

Como vender:

“Use as redes sociais para atrair. Tenha uma página preparada para converter esse interesse.”

Receber contatos mais qualificados

#produtividade

Uma página pode explicar o serviço, informar a região atendida, apresentar diferenciais e coletar dados importantes antes do primeiro contato. Isso ajuda a reduzir dúvidas repetitivas e a filtrar solicitações inadequadas.

Como vender:

“Faça o cliente chegar até você entendendo o que oferece e o que precisa informar.”

Transmitir confiança antes da primeira conversa

#credibilidade

Uma apresentação organizada, com serviços, portfólio, depoimentos verdadeiros, informações de contato e perguntas frequentes, ajuda o potencial cliente a avaliar a empresa.

Como vender:

“Antes de contratar você, o cliente precisa entender por que deveria confiar no seu trabalho.”

Descobrir se o investimento em divulgação compensa

#mensuração

Com ferramentas de medição adequadas, é possível acompanhar visitas, cliques, formulários enviados e outras ações. Isso permite avaliar campanhas e testar melhorias.

Como vender:

“Você não precisa apenas divulgar sua empresa. Precisa entender o que está trazendo oportunidades.”

Colocar uma oferta no ar rapidamente

#agilidade

Para testar um novo serviço, uma promoção ou uma campanha, nem sempre é necessário desenvolver um site completo. Uma Landing Page bem planejada pode ser uma alternativa mais simples e rápida.

Como vender:

“Teste sua próxima oferta sem precisar esperar pelo desenvolvimento de um site inteiro.”

Não perder oportunidades por falta de informação

#clareza

Se o visitante não encontra rapidamente o preço inicial, os serviços, a área de atendimento ou a maneira de contratar, pode desistir e procurar outra empresa. Uma página bem organizada reduz esse atrito.

Como vender:

“Cada dúvida que você deixa sem resposta pode se tornar uma barreira para a contratação.”

Mas...

Foi pensando nisso que a IceNex desenvolveu a Landora. Um gerados de landing pages, prático, rápido e simples.

Em minutos vc constrói sua landing page, pagando uma única vez, podendo escolher entre 3 modelos e várias opções de paleta de cores... e o melhor de tudo... vc pode escolher como quer hospedar e em qual domínio quer vincular.

Muitos lugares amarram a criação do seu site com uma hospedagem mensal + o valor do domínio. A Landora gera seu site e permite que vc escolha como quer fazer a publicação, podendo até escolher hospedagens gratuitas uma vez que sua landing page não precisa de recursos miraculosos para funcionar.

Faça o teste e gere sua landing page para ver como fica!

https://landora.icenex.io

Dùvidas?

Entre em contato com a gente...

Abs

Imutabilidade em infraestrutura: conceito, limites e o preço da previsibilidade

Uma reflexão sobre o fim do "entrar no servidor e ajustar", e o que ganhamos — e perdemos — ao abandonar esse hábito.

O hábito que quase todo sysadmin já teve

Se você já administrou servidores por algum tempo, provavelmente já fez isto: entra por SSH em uma máquina em produção, abre o arquivo de configuração, muda uma linha, reinicia o serviço, e vai embora. Funcionou. O problema foi resolvido. Ninguém mais toca naquele arquivo. Meses depois, a máquina é substituída, o arquivo se perde, e ninguém sabe por que aquela configuração específica estava lá — ou pior, ninguém sabia que ela precisava estar lá até a máquina nova apresentar o mesmo problema que a antiga tinha resolvido.

Esse padrão tem nome: configuração por acumulação. Cada servidor é o resultado de anos de pequenos ajustes manuais, cada um justificado no momento em que foi feito, nenhum deles documentado, todos eles essenciais para o funcionamento atual. É um conhecimento tácito, distribuído pela memória de quem estava lá naquele dia. Quando essa pessoa sai da equipe, o conhecimento vai embora com ela.

Infraestrutura imutável é uma tentativa de resolver esse problema — mas a discussão em torno dela costuma ser confusa, porque a palavra "imutável" carrega mais peso do que deveria, e porque o conceito frequentemente se mistura com outras ideias próximas (infraestrutura como código, containers, GitOps), gerando uma sopa de termos que ninguém sabe mais separar.

Vale desmontar isso com calma.

O que infraestrutura imutável realmente significa

A ideia central é simples: um servidor (ou container, ou máquina virtual) nunca é modificado depois de criado. Se algo precisa mudar — uma configuração, uma versão de pacote, uma variável de ambiente — a instância atual é descartada e uma nova é criada a partir de uma definição versionada. Não se entra na máquina para consertar. Não se aplica patch in-place. Não se "ajusta rapidinho".

O ciclo de vida de um recurso, nesse modelo, tem três estados possíveis: criado a partir de uma imagem ou definição, em execução, destruído. Nunca "modificado em execução". Essa restrição aparentemente pequena tem consequências profundas.

A primeira consequência é que a definição se torna a fonte da verdade. Se o servidor está de pé e funcionando, é porque alguma definição versionada assim o determinou. Se alguém precisa entender por que o serviço X está configurado daquela forma, a resposta está no repositório, não na memória de ninguém. Isso transforma configuração em código — inspecionável, revisável, testável, revertível.

A segunda consequência é que o ambiente se torna descartável. Se um servidor apresenta comportamento estranho, a resposta não é investigar por horas o que mudou nele. É destruí-lo e criar outro. O tempo médio de recuperação cai drasticamente, porque recuperar deixa de ser um processo artesanal e passa a ser uma operação mecânica.

A terceira consequência é que os ambientes convergem. Desenvolvimento, homologação e produção passam a ser instâncias diferentes da mesma definição, parametrizadas. O clássico "funciona na minha máquina" perde força, porque "minha máquina" e "produção" são construídas do mesmo jeito.

O que infraestrutura imutável não é

Aqui é onde a conversa costuma descarrilhar. Vale separar o conceito de três coisas com as quais ele é frequentemente confundido.

Não é a mesma coisa que infraestrutura como código. IaC é uma prática de descrever infraestrutura em arquivos versionados — Terraform, Ansible, CloudFormation, Pulumi. Você pode ter IaC sem imutabilidade: o Ansible, por exemplo, é tipicamente usado para configurar servidores existentes, aplicando mudanças in-place de forma idempotente. Também pode ter imutabilidade sem IaC formal: um script shell que cria uma AMI e a lança já é uma forma rudimentar de imutabilidade. As duas práticas se reforçam, mas são independentes.

Não é a mesma coisa que containers. Containers tornam a imutabilidade mais fácil e mais natural — a imagem é literalmente imutável, e o container é uma instância descartável dela. Mas imutabilidade é uma propriedade desejável, não uma característica exclusiva de containers. Você pode construir máquinas virtuais imutáveis (AMIs, imagens de VM, snapshots versionados) sem tocar em Docker ou Kubernetes. E pode usar containers de forma completamente mutável — entrar no pod, instalar pacote, alterar arquivo, esquecer que aquilo vai sumir no próximo restart. Já vi isso acontecer mais vezes do que gostaria.

Não é a mesma coisa que GitOps. GitOps é um modelo operacional em que o estado desejado da infraestrutura vive em um repositório Git, e um agente (ArgoCD, Flux) reconcilia continuamente o estado real com o estado declarado. GitOps pressupõe imutabilidade em muitos contextos, mas é uma camada adicional — sobre como as mudanças chegam ao ambiente — não a definição do conceito.

💡 Em uma frase: infraestrutura imutável é sobre como os recursos evoluem no tempo (por substituição, não por modificação). As outras práticas — IaC, containers, GitOps — são ferramentas que tornam essa evolução viável em escala.

Por que isso importa na prática

A defesa mais honesta da imutabilidade não é estética, é operacional. Ela resolve — ou pelo menos mitiga — quatro problemas recorrentes em ambientes tradicionais.

Drift de configuração. Servidores que começaram idênticos vão divergindo lentamente, à medida que cada um recebe ajustes manuais diferentes. Meses depois, ninguém mais sabe se dois servidores deveriam ser iguais, ou se as diferenças são intencionais. Imutabilidade elimina o drift por construção: se você quer dois servidores iguais, você cria duas instâncias da mesma imagem. Se quer diferentes, você cria duas imagens. A divergência deixa de ser acidente e passa a ser decisão explícita.

Reprodutibilidade de incidentes. Um bug aparece em produção, mas não em homologação. Em ambientes mutáveis, entender o que difere entre os dois pode levar dias. Em ambientes imutáveis, os dois são instâncias de definições versionadas — a diferença está no diff entre as definições, não perdida em algum arquivo alterado em 2019.

Rollback real. Em ambientes mutáveis, "rollback" costuma significar reverter manualmente cada mudança aplicada, na ordem inversa, torcendo para não ter esquecido nada. Em ambientes imutáveis, rollback significa apontar para a versão anterior da imagem. Um comando. Segundos. E o ambiente volta exatamente ao estado anterior — não a uma aproximação dele.

Escala horizontal. Adicionar a décima instância de um serviço é uma operação mecânica quando a definição já existe. Em ambientes mutáveis, a décima instância começa como uma cópia da primeira e vai recebendo os mesmos ajustes manuais que as outras receberam — ou não recebe, e vira a instância problemática que ninguém entende por que se comporta diferente.

O preço da imutabilidade

Seria desonesto apresentar imutabilidade como ganho puro. Ela tem custos reais, e ignorá-los é a razão pela qual muitas tentativas de adoção fracassam.

Estado persistente é o calcanhar de Aquiles. Serviços stateless são triviais de tornar imutáveis — você destrói e recria sem consequências. Bancos de dados, filas persistentes, armazenamento de arquivos, sessões de usuário: tudo isso exige estado que sobrevive ao ciclo de vida da instância. A solução usual é separar o estado do recurso computacional — banco gerenciado, volumes persistentes, object storage — mas essa separação nem sempre é trivial, e cada exceção mina parcialmente o modelo. A regra do "nunca modifique" passa a ter asteriscos: exceto para os bancos, exceto para os volumes, exceto para os backups.

Debug se torna mais difícil. Em ambientes mutáveis, quando algo dá errado, você entra na máquina e explora. Em ambientes imutáveis, a máquina vai desaparecer — então você precisa ter aprendido a coletar evidências antes que isso aconteça. Logs centralizados, métricas com contexto, tracing distribuído, snapshots no momento do erro. Sem esse investimento em observabilidade, imutabilidade vira uma caixa-preta que ninguém consegue investigar.

Tempo de build é tempo de feedback. Se a única forma de testar uma mudança é construir uma nova imagem e lançá-la, e esse processo leva vinte minutos, o ciclo de desenvolvimento fica dolorosamente lento. Ambientes imutáveis exigem investimento em CI/CD rápido, cache de camadas, builds incrementais. Sem isso, a equipe vai começar a contornar o processo — e o primeiro contorno é sempre "vou entrar no servidor só para testar isso rapidinho".

Cultura é o obstáculo maior. Times acostumados a resolver problemas com SSH e um editor de texto vão resistir, porque a nova forma parece mais lenta e mais burocrática. E eles têm razão, no curto prazo. O ganho vem no médio e longo prazo, em incidentes que não acontecem, em rollbacks que funcionam, em ambientes que convergem. Vender isso para uma equipe sob pressão é um desafio de gestão antes de ser um desafio técnico.

Imutabilidade é um espectro, não um interruptor

Outro erro comum é tratar imutabilidade como decisão binária: ou você adota completamente, ou não adota. Na prática, quase todo ambiente real é parcialmente imutável, e isso não é problema — é realismo.

Talvez seus servidores de aplicação sejam imutáveis, mas o banco de dados ainda receba ajustes manuais ocasionais. Talvez os containers sigam o modelo imutável, mas a rede seja configurada imperativamente. Talvez você tenha conseguido imutabilidade em desenvolvimento e homologação, mas produção ainda seja um território sagrado onde ninguém ousa mexer no modelo.

O caminho de adoção que funciona costuma ser por camadas: comece pelo que é mais fácil (serviços stateless, ambientes de teste), aprenda com os atritos, invista nas ferramentas que faltam (CI/CD, observabilidade, gestão de segredos), e só depois avance para o que é mais difícil (bancos, sistemas legados, componentes com estado). Cada camada imutável reduz a superfície de drift do ambiente como um todo, mesmo que as outras permaneçam mutáveis.

⚠️ Aviso comum: Adotar imutabilidade sem investir em observabilidade é trocar um problema por outro. Você deixa de ter servidores que acumulam configuração, mas passa a ter sistemas que você não consegue investigar quando falham, porque a evidência some junto com a instância. As duas práticas andam juntas.

O que a imutabilidade revela sobre a operação

Há uma leitura mais profunda desse tema, que vale explicitar. A imutabilidade não é só uma técnica de gestão de servidores — ela é uma declaração sobre o que a operação deve ser.

Em ambientes tradicionais, a operação é artesanal: cada servidor é uma peça única, cada ajuste é uma intervenção, cada administrador tem seu estilo. O trabalho é valorizado pela capacidade de resolver problemas — "fulano é bom porque conserta rápido".

Em ambientes imutáveis, a operação é industrial: os recursos são produzidos em série a partir de moldes, as variações são deliberadas, o trabalho é valorizado pela capacidade de evitar problemas — "fulano é bom porque nada quebra sob sua responsabilidade".

A mudança é sutil mas profunda. Ela desloca o foco do herói que apaga incêndios para o processo que impede o incêndio. E isso incomoda, porque heróis são reconhecidos e processos são invisíveis. Times que não fazem essa transição cultural acabam sabotando a adoção técnica sem perceber — a ferramenta está lá, mas ninguém a usa direito, porque o modelo mental continua sendo artesanal.

Infraestrutura imutável, no fundo, é uma aposta: a de que previsibilidade vale mais que flexibilidade, a de que reconstruir é mais confiável que consertar, a de que a fonte da verdade deve estar em um repositório, não na cabeça de alguém. É uma aposta que nem todo mundo precisa fazer, mas que quem faz costuma não voltar atrás.

Quando imutabilidade não vale a pena

Como no texto anterior sobre observabilidade, seria desonesto terminar sem reconhecer os limites. Imutabilidade não é para todo mundo — e defender o contrário é vender solução única para problemas diferentes.

Ambientes com poucos servidores, mudanças raras e equipe pequena podem viver confortavelmente com gestão tradicional. Um homelab de três máquinas não ganha nada com AMIs versionadas e pipelines de build. Uma empresa cujo produto é um ERP instalado on-premise no cliente não controla o ambiente de execução. Um sistema legado com duas décadas de configuração acumulada não vai ser refatorado para imutabilidade sem um custo que provavelmente não se justifica.

O critério prático: imutabilidade compensa quando o custo da divergência entre ambientes é maior que o custo da disciplina necessária para evitá-la. Se você tem dez ambientes idênticos que precisam se comportar igualmente, a disciplina vale. Se você tem um servidor único que quase não muda, ela é overhead.

A pergunta certa não é "imutabilidade é boa?". É "o meu ambiente, hoje, sofre com drift, com rollback frágil, com reprodutibilidade ruim?". Se a resposta for sim, vale olhar para o modelo. Se for não, talvez o problema esteja em outro lugar.

Considerações Finais

Infraestrutura imutável não é uma revolução técnica. É uma disciplina operacional que ganha sentido quando combinada com outras práticas — IaC, CI/CD, observabilidade, gestão de segredos — e que perde sentido quando adotada isoladamente como moda.

O que ela oferece é previsibilidade. O que ela cobra é investimento em ferramentas e, principalmente, em cultura. O que ela revela, no fim, é uma escolha sobre o tipo de operação que se quer ter: uma em que cada servidor é uma história contada por quem estava lá, ou uma em que cada servidor é uma instância de uma decisão documentada e reversível.

Nenhuma das duas é objetivamente melhor. Mas só uma delas escala sem depender de pessoas específicas continuarem na equipe para sempre.

E isso, para a maioria dos ambientes que crescem, acaba sendo decisivo.

Abs e até a próxima!!!

Backup simples com rsync

Como copiar apenas o que mudou, simular antes de executar e deixar o backup rodando sozinho todos os dias.

Fala pessoal, tudo bem?

Hoje o post é rápido e muito útil. Seja no laboratório ou em um servidor de verdade, mais cedo ou mais tarde vamos precisar copiar arquivos de um lugar para outro — ou simplesmente garantir que temos uma cópia de segurança. Para isso, existe uma ferramenta simples e poderosa que já vem na maioria das distribuições Linux: o rsync.

A grande vantagem dele sobre um simples cp é que ele copia apenas o que mudou. Na primeira execução ele copia tudo, nas próximas só envia as diferenças. Isso economiza tempo e banda — e, em backups recorrentes, faz uma diferença enorme.

1. O comando básico

Se por algum motivo ele não estiver instalado:

sudo apt install rsync -y

Agora, o comando que você mais vai usar:

rsync -avh --progress /home/usuario/projetos/ /backup/projetos/

• -a (archive) — copia tudo de forma recursiva e preserva permissões, donos, datas e links simbólicos. É o modo ideal para backup.
• -v (verbose) — mostra o que está sendo copiado.
• -h (human-readable) — exibe os tamanhos em formato legível (KB, MB, GB).
• --progress — mostra o andamento de cada arquivo.

2. Cuidado com a barra no final

Este é o detalhe que mais confunde quem está começando. A barra (/) no final do caminho de origem muda o resultado:

# COM barra: copia o CONTEÚDO da pasta

rsync -avh /home/usuario/projetos/ /backup/

# SEM barra: copia a PASTA inteira (cria /backup/projetos)

rsync -avh /home/usuario/projetos /backup/

Na dúvida, use o teste do próximo passo antes de executar de verdade.

3. Simular antes de executar

Antes de rodar um backup importante, podemos pedir ao rsync para apenas simular, mostrando o que ele faria sem alterar nada:

rsync -avh --dry-run /home/usuario/projetos/ /backup/projetos/

O --dry-run (ou apenas -n) é o seu seguro de vida. Fica a dica de sempre usá-lo quando estiver testando um comando novo.

💡 Dica: crie o hábito de rodar --dry-run antes de qualquer rsync com --delete. É a diferença entre um backup tranquilo e um susto.

4. Enviando para outro servidor

O rsync funciona por cima do SSH, então copiar para outra máquina é tão simples quanto copiar localmente. Se você já tem as chaves e os atalhos do SSH configurados, tudo fica ainda mais fácil.

Primeiro, vamos garantir que a pasta de destino existe no servidor (o rsync cria apenas o último nível da pasta):

ssh kub-node1 "mkdir -p ~/backup"

E agora o envio:

rsync -avh --progress /home/usuario/projetos/ kub-node1:~/backup/projetos/

O formato é servidor:caminho. Para restaurar, basta inverter origem e destino:

rsync -avh kub-node1:~/backup/projetos/ /home/usuario/projetos/

5. Espelhando e ignorando arquivos

Duas opções muito usadas em backup:

• --delete — apaga no destino o que foi apagado na origem, deixando as duas pastas idênticas (espelho). Sem ele, arquivos removidos na origem continuam no backup.
• --exclude — ignora arquivos ou pastas que você não quer copiar.

rsync -avh --delete --exclude='*.log' --exclude='node_modules' /home/usuario/projetos/ kub-node1:~/backup/projetos/

⚠️ Atenção: o --delete é perigoso se você inverter origem e destino ou errar o caminho, porque ele apaga arquivos de verdade. Teste sempre com --dry-run antes.

6. Automatizando com script e cron

Backup só é útil se for feito sempre. Vamos criar um script simples chamado backup.sh:

#!/bin/bash

ORIGEM="/home/usuario/projetos/"

DESTINO="kub-node1:~/backup/projetos/"

LOG="/home/usuario/backup-rsync.log"

echo "=== Backup iniciado em $(date) ===" >> "$LOG"

rsync -avh --delete --exclude='*.log' "$ORIGEM" "$DESTINO" >> "$LOG" 2>&1

echo "=== Finalizado em $(date) ===" >> "$LOG"

Dê permissão de execução e teste manualmente:

chmod +x /home/usuario/backup.sh

/home/usuario/backup.sh

Funcionou? Agora vamos agendar com o cron:

crontab -e

Adicione a linha abaixo no final do arquivo:

0 2 * * * /home/usuario/backup.sh

Isso executa o backup todos os dias às 2h da manhã. Os cinco campos são, nesta ordem: minuto, hora, dia do mês, mês e dia da semana.

⚠️ Importante: o cron roda sem você estar logado, então ele não consegue digitar senha. Para o backup remoto funcionar, o acesso SSH precisa estar sem senha, usando a chave que configuramos no post anterior. Como o cron também não tem acesso ao ssh-agent, a chave usada aqui precisa ser uma sem passphrase. Neste caso, vale criar uma chave exclusiva para o backup e restringir o acesso dela.

Para conferir se está rodando, é só olhar o log:

tail -f /home/usuario/backup-rsync.log

Um lembrete sobre backup

Copiar para outra pasta no mesmo disco não é backup de verdade. Se o disco morrer, você perde tudo junto. O ideal é sempre ter uma cópia em outra máquina ou, melhor ainda, em outro local. Uma regra clássica é a 3-2-1: 3 cópias dos dados, em 2 tipos de mídia diferentes, com 1 delas fora do local principal.

💡 Regra 3-2-1: três cópias, duas mídias, um local externo. Se você só tem a cópia local, ainda não tem backup — tem uma esperança.

Considerações Finais

Hoje vimos como usar o rsync para copiar só o que mudou, simular antes de executar, enviar e restaurar arquivos por SSH e automatizar tudo com um script e o cron. Com poucos comandos você já tem um backup funcional e fácil de manter.

O rsync é uma daquelas ferramentas que parecem simples na superfície e vão ficando cada vez mais úteis conforme você aprofunda. Vale ler a man rsync com calma — tem opções para coisas que você nem imaginava que precisava.

Abs e até a próxima.

SSH sem dor de cabeça: pare de digitar IP, usuário e senha

Fala pessoal, tudo bem?

Hoje o post é rápido, mas vale muito a pena. Quem trabalha com laboratório, VMs ou servidores acaba digitando ssh usuario@192.168.0.62 e a senha dezenas de vezes por dia. Vamos resolver isso em 3 passos.

1. Criar uma chave SSH

A chave substitui a senha. Ela é composta por duas partes: a privada (fica só com você) e a pública (vai para os servidores).

No terminal do seu computador, execute:

ssh-keygen -t ed25519 -C "meu-laboratorio"

Aceite o caminho padrão apertando Enter. Se quiser, defina uma senha para proteger a chave (recomendado em máquinas compartilhadas).

• ed25519 – algoritmo moderno, rápido e seguro.
• -C – apenas um comentário para identificar a chave.

2. Copiar a chave para o servidor

No Linux ou macOS:

ssh-copy-id usuario@192.168.0.62

No Windows (PowerShell), que não tem o ssh-copy-id:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh usuario@192.168.0.62 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Depois disso, ao rodar ssh usuario@192.168.0.62, você entra direto, sem pedir senha.

3. Criar atalhos com o arquivo config

Aqui está a melhor parte. Crie (ou edite) o arquivo ~/.ssh/config. No Windows fica em C:\Users\seu-usuario\.ssh\config.

Host kub-node1

    HostName 192.168.0.62

    User usuario

Host kub-node2

    HostName 192.168.0.63

    User usuario

Host kub-node3

    HostName 192.168.0.64

    User usuario

Host kub-*

    IdentityFile ~/.ssh/id_ed25519

    ServerAliveInterval 60

Obs.: os IPs dos nodes 2 e 3 são só exemplo. Use os IPs das suas VMs.

Agora, em vez do comando gigante, basta:

ssh kub-node1

E o atalho vale também para copiar arquivos:

scp meu-arquivo.yaml kub-node1:~/

Sobre o bloco Host kub-*:

• kub-* – aplica as configurações a todos os hosts que começam com "kub-".
• IdentityFile – diz qual chave usar.
• ServerAliveInterval 60 – manda um sinal a cada 60 segundos para a conexão não cair por inatividade.

Dica de segurança

Nunca compartilhe a chave privada (o arquivo sem .pub). A pública pode ir para qualquer servidor, mas a privada é a sua identidade.

Finalizando

Com 3 passos você troca o ssh usuario@IP + senha por um simples ssh kub-node1. Parece pouco, mas na rotina de laboratório isso economiza muito tempo e paciência.

Abs e até a próxima.

Simplificando a Navegação entre Clusters Kubernetes com Shell Script

E aí pessoal, tudo bem?

Para administrarmos um ou mais clusters kubernetes, usamos o kubectl ... 

Mas, e quando precisamos administrar por exemplo um cluster de Dev, um de Hml, talvez 3 de Prod ou todos eles?

As vezes dedicar estações exclusivas para isso pode ser um caminho, mas ao mesmo tempo nem tanto.

Veja ...

Eu preciso alternar entre os contextos para selecionar o cluster que quero mexer.

Por exemplo:

Eu tenho 3 clusters k8s conforme print abaixo:

O que me garante que ao rodar um comando, estou rodando para o cluster que desejo naquele momento?

E se eu estiver por exemplo no cluster k8s-kind e precisar mudar para o k8s-local-share?

Por isso o kubectl trabalha com contextos.

Contexto - conjunto de padrões que agrupam informações de cluster, usuário e namespaces.

Pois bem, dito isso ...

Para vermos em qual contexto estamos conectados no momento, devemos executar o seguinte comando:

kubectl config get-contexts

Na coluna CURRENT, aquele asterisco informa que ao rodarmos os comandos com o kubectl, estaremos rodando os comandos no cluster kind-k8s-local-sites.

Mas como eu faço para trocar de cluster?

kubectl config use-context NOME_DO_CLUSTER

Exemplo

Rodando novamente o get no contexts

Podemos ver agora que o CURRENT está com o asterisco no cluster que informamos no comando use-context. Agora todo comando executado será neste cluster.

Veja que sempre vamos precisar ficar rodando esses comandos todos para alternar entre os clusters.

Pensando nisso...

Vou compartilhar com vcs um script shell bem básico que eu fiz aqui pra mim, pensando na necessidade de gerenciar vários ambientes kubernetes. Ele vai se basear sempre nos contextos que estiverem no kubeconfig para poder gerar a lista de opções.

Se por ventura, algum contexto que vc tinha usado por último não existir mais o script não vai conseguir trazer ele como atual, mas dará uma mensagem falando que vc não tem um contexto válido e também não irá aparecer o que não existe mais na listagem.

E não menos importante, o script pode ser baixado no meu GitHub - https://github.com/jguandalini/Shell-Scripts

Para executá-lo, dê permissão de execução com o comando chmod +x select-k8s.sh e para executá-lo no terminal ./select-k8s.sh

Bora!!!

Abs e até a próxima.

Laboratório DevOps - CI/CD com GitHub Actions

Fala pessoal, tudo bem?

Eu particularmente gosto bastante de compartilhar laboratórios, pq assim além de vermos a teoria, já vemos também a prática de algo funcionando.

Mas afinal, o que é CI/CD em uma cultura DevOps?

CI/CD é o conjunto de práticas que automatiza o caminho do código, desde o commit até estar rodando em produção. Na cultura DevOps, ele é o “motor” que permite entregar mudanças pequenas, rápidas e com segurança.

O que significa cada parte

CI (Integração Contínua): cada vez que alguém envia código ao repositório, um pipeline automático faz o build e roda os testes. O objetivo é descobrir erros em minutos, e não dias depois, quando várias mudanças já se misturaram. Isso incentiva commits pequenos e frequentes na branch principal.

CD tem dois significados:

• Entrega Contínua (Continuous Delivery): todo código que passa nos testes fica pronto para ir a produção, mas o deploy final depende de uma aprovação manual (um clique).
• Implantação Contínua (Continuous Deployment): vai além, e o deploy em produção acontece automaticamente, sem aprovação humana, desde que todos os testes passem.

Qual o papel na cultura DevOps

DevOps não é uma ferramenta, é uma cultura que une desenvolvimento (Dev) e operações (Ops) em torno de responsabilidade compartilhada pelo ciclo completo do software. O CI/CD é a materialização técnica dessa cultura:

• Automação no lugar de processos manuais: deploys deixam de ser eventos arriscados, feitos “na mão” e só por quem sabe o passo a passo.
• Feedback rápido: o time sabe logo se uma mudança quebrou algo.
• Mudanças pequenas e frequentes: quanto menor a mudança, menor o risco e mais fácil o rollback.
• Responsabilidade compartilhada: quem escreve o código também acompanha o que acontece quando ele chega a produção.
• Tudo como código: pipeline, infraestrutura e manifests ficam versionados no Git (pipeline as code, IaC, GitOps), o que dá rastreabilidade e reprodutibilidade.
• Qualidade e segurança embutidas: testes, análise de código e scan de vulnerabilidades rodam em todo commit (o chamado shift left, ou DevSecOps).

Benefícios medidos

Times de alta performance costumam acompanhar as métricas DORA:

Para esse lab, eu pensei no seguinte:

Então, nosso primeiro passo, será preparar algumas coisas. 

Isso mesmo...

Mesmo sendo um processo automatizado, em algum momento existem partes disso que precisam ser configuradas inicialmente para que na sequência tudo possa ocorrer de forma automática, rápida e em escala.

Primeiro passo - Criar nosso cluster kubernetes usando o kind

Alguns passos eu vou resumir um pouco para que o post não fique muito extenso.

Kind = Kubernetes in Docker

É uma solução que executa um cluster k8s localmente em nosso computador, através do Docker. Então para isso, vc precisará ter instalado o Docker e também o app do kind.

Sempre que possível para esses procedimentos, consultem a documentação oficial.

Instalação do Docker - https://docs.docker.com/desktop/setup/install/windows-install/

Instalação do Kind - https://kind.sigs.k8s.io/docs/user/quick-start/

Perfeito!!!

Tudo instalado, vamos criar o cluster no kind e conforme nossa arquitetura proposta:

• 1 control-plane
• 2 workers

Nesse passo, nós vamos usar o seguinte arquivo com as premissas:

kind: Cluster

apiVersion: kind.x-k8s.io/v1alpha4

name: k8s-local

nodes:

- role: control-plane

- role: worker

- role: worker

Na hora de salvar, o nome que dei para o arquivo foi: k8s-cluster.yaml

O nome, vc pode escolher o que achar melhor dentro da sua organização, mas a extensão .yaml é obrigatória.

Só lembrando, que para o próximo passo funcionar, o Docker precisa estar rodando no seu computador.

Para criar o cluster, vamos abrir a linha de comando.

kind create cluster --config k8s-cluster.yaml

Enquanto ele vai criando o cluster, vamos fazer um resumo do que foi adicionado neste arquivo:

- O tipo para informar que é um Cluster;

- apiVersion é a API que o kind irá usar para poder criar o Cluster;

- name é o nome que queremos dar para nosso Cluster;

- nodes/role, são as informações pertinentes ao control-plane e workers que vamos criar. No nosso caso, não estamos criando nenhuma role;

Voltando ao terminal, dando tudo certo devemos ter algo assim:

Agora, para que possamos administrar nosso cluster k8s, precisamos ter instalado o kubectl através do kubeadm - https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

Com as ferramentas administrativas instaladas, vamos ver como está nosso cluster com o comando:

kubectl get nodes

Tudo funcionando. Os nossos 2 workers (Ready), nosso control-plane (Ready), todos na versão 1.37.0.

Já temos a base da infraestrutura onde nossa aplicação ou aplicações irão rodar.

Segundo passo - Criar repositório no GitHub

Para isso, vamos acessar a URL - https://github.com, autenticar com a nossa conta (caso não tenha, vc precisará criar uma).

Aparecendo a nossa home, no canto superior direito - New repository

Na tela seguinte, precisaremos informar o nome do repositório e se ele será público ou privado.

Aqui vale destacar que cada cenário pode ser de um jeito, tanto quanto a organização de nomes quanto a ser público ou privado.

Eu vou seguir uma lógica da seguinte forma:

• Será um repositório por site/empresa, então a convenção do nome será "site-nome_da_empresa"
• Por padrão e segurança, repositório privado

Assim que criarmos, recebemos algumas informações do próprio GitHub para iniciarmos o uso do nosso repositório.

Por enquanto, vamos salvar essas informações que estão aparecendo ao criar o repositório. Iremos usá-las mais pra frente.

Terceiro passo - Preparando o GitHub Actions

Agora vem um detalhe importante.

Como nosso lab, o nosso cluster do kubernetes está rodando localmente, temos limitações de comunicação a ele.

Deste modo, ao invés de usarmos o GitHub Actions direto no site do GitHub iremos usar o modelo Self-hosted runner.

O self-hostes runner consiste em disponibilizarmos o runner do actions em nosso próprio ambiente. Ele será a ponte de comunicação entre nosso repositório, o workflow do CI/CD e por fim, com nosso cluster kubernetes.

Para configurar o runner, vamos no nosso repositório, clicar em Settings - Actions - Runners

Depois vamos clicar em "New self-hosted ruuner

Agora o GitHub irá fornecer os próximos passos de configuração, por que irá depender do ambiente que estamos utilizando.

Deste modo, essa parte eu vou fazer de acordo com meu ambiente que é linux.

Mas basta cada um seguir exatamente como está no procedimento que dará certo.

Assim que o processo de start do runner finalizar, ele está pronto em listening para esperar as actions que terá que executar.

Quarto passo - Preparando nossa aplicação e workflow de deploy

Agora, vamos preparar em um diretório do nosso computador os arquivos do site, os arquivos do workflow que o actions irá usar e os arquivos de deploy no kubernetes.

Crie uma pasta chamada site-engenharia e dentro dela, vamos criar a seguinte estrutura

Uma pasta chamada k8s;

Um arquivo chamado Dockerfile;

Um arquivo chamado index.html;

Dentro da pasta k8s

Vamos criar um arquivo chamado deployment.yaml com o seguinte conteúdo:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: site-engenharia

spec:

  replicas: 2

  selector:

    matchLabels:

      app: site-engenharia

  template:

    metadata:

      labels:

        app: site-engenharia

    spec:

      containers:

        - name: nginx

          image: IMAGE_PLACEHOLDER

          imagePullPolicy: IfNotPresent

          ports:

            - containerPort: 80

Esse será o arquivo utilizado no kubernetes para subir nosso Pod com as labels de identificação para "site-engenharia" com um container nginx e a imagem que iremos fornece futuramente no Dockerfile, respondendo na porta 80.

Agora na mesma pasta do k8s, vamos criar o arquivo de deploy do service. Vamos chamá-lo de service.yaml com o seguinte conteúdo:

apiVersion: v1

kind: Service

metadata:

  name: site-engenharia

spec:

  selector:

    app: site-engenharia

  ports:

    - port: 80

      targetPort: 80

Isso fará com que nosso serviço do site-engenharia esteja "exposto" pelo kubernetes.

Agora, vamos voltar para a pasta raiz site-engenharia e criar o arquivo Dockerfile com o seguinte conteúdo:

FROM nginx:alpine

COPY index.html /usr/share/nginx/html/

Isso instruirá nosso deploy a usar a imagem do nginx:alpine e copiar o nosso arquivo index.html para o path que o nginx irá ler dentro do Pod.

Neste momento, vamos utilizar uma imagem pública do nginx mesmo, mas é possível futuramente começar a usar nossas próprias imagens.

Agora, vamos criar o arquivo do nosso site, o index.html com o seguinte conteúdo:

<!DOCTYPE html>

<html lang="pt-BR">

<head>

    <meta charset="UTF-8">

    <title>Meu Site</title>

</head>

<body>

    <h1>Meu site está rodando no Kubernetes!</h1>

</body>

</html>

Neste primeiro momento, será bem simples mesmo.

E por fim, vamos criar um diretório oculto e dentro dele o arquivo do workflow que o runner irá consumir.

Diterório .github/workflows/

Dentro dele o arquivo deploy-site-engenharia.yml (isso mesmo, aqui é yml)

O conteúdo dele será:

name: deploy-site-engenharia

on:

  push:

    branches: [main]

    paths:

      - "site-engenharia/**"

      - "Dockerfile"

      - "k8s/**"

  workflow_dispatch:

jobs:

  deploy:

    runs-on: self-hosted

    env:

      IMAGE: site:${{ github.sha }}

    steps:

      - uses: actions/checkout@v4

      - name: Build da imagem

        run: docker build -t $IMAGE .

      - name: Carregar imagem no kind

        run: kind load docker-image $IMAGE --name k8s-local

      - name: Deploy

        run: |

          sed "s|IMAGE_PLACEHOLDER|$IMAGE|" k8s/deployment.yaml | kubectl apply -f -

          kubectl apply -f k8s/service.yaml

          kubectl rollout status deployment/site-engenharia --timeout=60s

Quinto passo - Mandando nossa aplicação para o GitHub

Ao enviarmos tudo para o GitHub, iremos enviar também o arquivo do actions, e ele fará com que o deploy se inicie.

Isso vai acontecer por que foi a condição que criamos no nosso actions. Na maioria do ambientes, ainda mais em larga escala e com várias dependências, possa ser necessário mudar isso para que seja feito o start manualmente e através de fluxo de mudança.

Para enviar os arquivos, vamos entrar na pasta site-engenharia e vamos rodar os comandos que salvamos quando criamos o repositório no GitHub... lembra?

Mas antes disso, precisamos autenticar nosso repo local a nossa conta do GitHub, para isso, basta vc instalar o utiitário gh e rodar o comando

gh auth login

Esse comando fará com que seja aberto seu navegador, e dê permissão para acessar seu repo, informando o número que ele vai gerar na linha de comando e uma confirmação por e-mail (tudo pela segurança).

Rodar os comandos

git config --global user.email "seu email"

git config --global user.name "seu nome"

Agora sim, pode rodar os comandos que o seu repo te passou.

Isso vai fazer com que seja enviado o seu primeiro commit para lá, enviando apenas o arquivo REAME.md.

Agora, vamos enviar realmente todos os arquivos.

Para isso

git add .

git commit -m "Enviando site e actions"

git push

Volte no seu repo no site do GitHub e clique em Actions

Você verá que o actions começou a trabalhar no deploy.

Clicando no nome do action (que adota o nome do comentário do commit), e deploy, vc verá toda sequência do que está sendo feito.

E se vai dar certo ou não rsrs

Na minha primeira tentativa, deu erro, eu acabei digitando uma informação errada no arquivo de yml do workflow que o actions usa...efetuei a correção e rodei o workflow manualmente.

Feito tudo isso, com eu faço o teste para ver se o site foi publicado?

No kubernetes, vamos expor a porta do service site-engenharia da seguinte forma

kubectl port-forward services/site-engenharia 9999:80

 

O retorno na linha de comando, deve ser assim: 

Forwarding from 127.0.0.1:9999 -> 80
Forwarding from [::1]:9999 -> 80

Agora faça acesso ao site no seu navegador digitando o endereço http://localhost:9999

 

 

Por enquanto é isso.

Lembra que no deploy estamos pedindo 2 réplicas?

Será que o kubernetes fez isso?

Rode o comando

kubectl get pods

Temos o seguinte fluxo funcionando com o conceito DevOps de CI/CD - Integração Contínua e Entrega Contínua.

Fazendo uma nova alteração no site ou mesmo no deploymento da aplicação para aumentar o número de réplicas, isso ativará o gatilho para a automação iniciar e aplicar o que mudou.

O lab de hoje é isso.

Espero que tenham gostado e que este pequeno how-to seja útil e inspire vcs a testarem e fazerem ajustes para suas necessidades.

Por que não testar mudando as réplicas? Ou colocar um site mais "maneiro" no ar ... ou até mesmo uma aplicação diferente que necessite de alguma outra imagem que não a do nginx ...

Testem sempre...

E para não ser muito raso, esse conceito vai ainda muito além disso na prática. 

Existem mais coisas a serem implementadas como validações, questões de segurança que precisam estar sempre juntas tanto no Dev quanto no Ops... o que chamamos de DevSecOps.

Integração com mais ferramentas, segregações de ambientes e por aí vai ...

Abs e até mais!!!