Kubernetes do Zero - Parte 3: Subindo um "mini cluster" com kind

Fala pessoal, tudo bem?

Na postagem da parte 2, nós criamos um cluster do inicio ao fim, semelhante a forma que criaríamos um cluster kubernetes em um ambiente "corporativo" por assim dizer.

Ambiente virtual, mais de uma máquina, IPs para cada node, instalação de CNI, etc ...

Mas e se não tivermos como subir um ambiente desse porte? Um lugar que possamos apenas usar para estudar boa parte, se não todos, os conceitos do kubernetes?

Pensando nisso, vamos fazer a parte 3 com base nessa possibilidade.

Sem necessidade de hardware parrudo, sem a necessidade de várias máquinas, sem uso de cloud.

Apenas  o nosso notebook (pode ser ele Windows, Linux ou Mac).

Existe uma alternativa muito legal que é o Kind - Kubernetes in Docker.

Ele faz uso do Docker para subir containers que vão simular os nodes do kubernetes.

Site do projeto - https://kind.sigs.k8s.io

A parte legal de olhar sempre o site oficial, é que teremos a documentação atualizada.

Clicando em Quick Start - Installation, temos as instruções para cada tipo de sistema operacional.

O meu é um Debian Linux, então vou seguir o passo a passo do "On Linux".

Essa primeira parte, consiste na verdade em baixar o binário do kind mediante ao seu respectivo host.

Dar permissão de execução ao binário.

Mover para o path default de execução e assim todos os usuários deste computador, terão acesso a rodar o kind.

O próximo passo para testar e ver se tudo deu certo, é executar o comando kind com qualquer usuário.

Obs - no meu caso, eu já baixei e movi o arquivo como root, pois no Debian é um pouco diferente do Ubuntu na questão de usuários. Meu usuário convencional não é adicionado por padrão com permissões sudo. Ele libera diretamente o root.

Primeiro teste executando o kind como root e o segundo com meu usuário convencional.

Até aqui, tudo fácil e mais que lindo/maravilhoso.

Agora, o próximo passo é instalar alguns componentes que o kind vai precisar e nós vamos precisar depois para administrar nosso poderoso cluster kubernetes.

Eu vou fazer por etapas, mas saiba que podemos preparar tudo e depois rodar tudo em uma única instalação. Mas vamos com calma.

Instalando o Docker

# apt install docker.io

Assim que a instalação finalizar, vamos validar se o Docker está em execução:

# systemctl status docker

Por estar usando o Debian, eu tive um passo adicional que foi permitir o meu usuário convencional a ter acesso ao Docker. Para isso, eu adicionei o usuário ao grupo do Docker.

Caso vc também esteja no Debian, basta rodar esse comando como root:

# gpasswd -a joao docker

(tem um modo menos elegante que é dar um vim /etc/group e adicionar o usuário ao final da linha onde contém o nome do grupo do Docker =D ).

Para que seu usuário leia as novas configurações, vc precisará fazer logout e login novamente.

Instalando o kubectl

Para podermos administrar o cluster kubernetes, precisamos do kubectl. Para instalar no Debian:

# apt install kubectl

Agora, temos o nosso ambiente preparado para criarmos o cluster com o kind.

Criando nosso cluster com Kind

Existem duas formas de criamos o cluster:

1. Rodando diretamente na linha de comando com o kind
2. Criando um manifesto (arquivo yaml) e pedir ao Kind para ler este arquivo

Vantagem de um para o outro:

• Direto pelo comando, cria o cluster default mais rápido
• Pelo manifesto, podemos otimizar e customizar algumas configurações (como quantidade de control-planes, workers, regras de ingress, etc)

Para o nosso lab, vou criar usando o manifesto para garantir que seja criado como eu quero.

Para isso, no linux vamos criar o arquivo conforme abaixo:

$ vi create-kind-cluster.yaml

Dentro dele, teremos o seguinte conteúdo:

kind: Cluster // o tipo de recurso que estamos querendo criar
apiVersion: kind.x-k8s.io/v1alpha4 // a versão da API que vamos usar para isso
name: kind-k8s // o nome que queremos para nosso cluster
nodes: //o bloco onde iremos informar quantos e o tipo de workers que queremos
- role: control-plane // worker do tipo control-plane
- role: worker
- role: worker // tipo worker

Veja que para nosso ambiente, estamos pedindo um recurso do tipo cluster, de nome kind-k8s, 1 node control-plane e 2 nodes worker.

Salve o arquivo.

Agora para podermos iniciar a criação do cluster:

$ kind create cluster --name=create-kind-cluster.yaml

Prontinho!!!

Nosso cluster kubernetes local foi criado.

Vamos conferir?

Temos duas formas...

Uma é a já sugerida pelo kind quando ele termina de criar o cluster:

$ kubectl cluster-info

Podemos usar o comando até o "cluster-info" se tivermos apenas este cluster criado e rodando.

Caso vc tenha mais de um, informar o contexto para o recurso específico.

A outra forma, é ir direto pelo Docker com o comando docker ps, e ver a saída dos containers rodando:

$ docker ps

Exatamente o que pedimos no nosso arquivo yaml

• 1 control-plane
• 2 workers

Podemos também rodar:

$ kubectl get nodes

Legal!!!

Mas e agora, como posso testar e ver se ele está pronto para receber meus pods, minhas aplicações para testar?

Vamos subir um pod do nginx para teste...

$ kubectl run nginx --image=nginx --port=80

Para irmos acompanhando se o STATUS do pod muda para Running:

$ kubectl get pods

Dando tudo certo, temos a saída abaixo:

E para testarmos se ele está respondendo:

$ kubectl port-forward pod/nginx 8080:80

Mas o que esse comando faz?

Ele faz o com que nosso pod nginx tenha suporta exposta remotamente na porta localhost:8080.

Abrindo o navegador do nosso computador e acessando http://localhost:8080 veremos a página default do nginx.

Sei lá... tá meio estranho isso! Como vou ter certeza que esse conteúdo é mesmo do pod do nginx que acabamos de subir?

Certo, vamos brincar um pouco dentro do pod.

Para acessar o shell do pod, vamos executar a seguinte linha de comando:

obs - abra uma nova aba do seu terminal para não perdermos o port-forward ...

$ kubectl exec nginx -it -- bash

Esse comando é um exec com o parametro it informando que o comando que queremos executar para este pod é um bash.

Isso nos dará acesso bash direto no pod:

Agora, vamos apagar o conteúdo do arquivo index.html default do nginx:

# echo > /usr/share/nginx/html/index.html

Validar que ele está em branco:

# cat /usr/share/nginx/html/index.html

Agora vamos adicionar um novo conteúdo a ele:

# echo "Site testado no kind-k8s" > /usr/share/nginx/html/index.html

Agora, vamos sair do container com o comando exit

Caso vc tenha parado o port-forward, inicie ele novamente. Caso não, retorne ao navegador e dê um refresh na página http://localhost:8080

Agora vc pode de fato acreditar que subimos nosso cluster kubernetes localmente, ele está funcional, pois conseguimos subir um pod com um nginx, conectar nesse pod, trocar o arquivo html e testar o acesso de fora do cluster.

Por agora é isso.

Temos até aqui, duas opções de lab para testar o que será preparado nas próximas postagens.

Seja no seu cluster com as VMs, CNI, mais de 3 nós ... ou mesmo no nosso kind local com 1 control-plane e 2 workers.

Abs e até o próximo post...

:wq!

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.