Forem: DeividFerraz

Kubernetes local na prática: como eu estruturei ReplicaSet, Service, HPA e Ingress para subir minha aplicação no Minikube ☸️

DeividFerraz — Wed, 08 Apr 2026 22:46:24 +0000

Descrição

Eu quis aprender Kubernetes entendendo a responsabilidade de cada recurso, em vez de apenas copiar manifestos prontos. Nesse processo, subi minha aplicação localmente no Minikube e conectei ReplicaSet, Service, HPA e Ingress até o fluxo fazer sentido de ponta a ponta. 🚀

Tem uma forma muito comum de começar em Kubernetes:
copiar alguns YAMLs, aplicar tudo e comemorar quando a aplicação responde.

Só que eu quis fazer diferente.

Em vez de focar apenas em “subir a app”, eu quis entender o que cada recurso faz de verdade dentro do cluster.

Então montei minha estrutura localmente no Minikube, usando:

ReplicaSet
Service
HPA
Ingress
namespace dedicado
domínio local via hosts

E isso me ajudou muito a visualizar o fluxo real da aplicação. 👇

Primeiro eu organizei o cluster 🧭

Antes de aplicar qualquer recurso, eu preferi deixar meu ambiente mais organizado.

Criei um namespace próprio para a aplicação e já apontei meu contexto atual para ele:

kubectl config use-context multinode
kubectl create namespace meusite
kubectl config set-context --current --namespace=meusite

Isso foi importante por dois motivos:

Tudo ficou isolado no mesmo namespace
Ficou muito mais fácil de navegar no kubectl e no k9s

Inclusive, para abrir o K9s já no lugar certo:

k9s --context multinode -n meusite

Meu primeiro recurso foi o ReplicaSet 🧱

Aqui eu fiz uma escolha intencional.

Eu sei que, no mundo real, aplicações geralmente sobem com Deployment.
Mas como meu foco era estudar a base, usei ReplicaSet.

Queria ver mais de perto como o Kubernetes mantém a quantidade desejada de Pods.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: site-soren-rs
spec:
replicas: 1
selector:
matchLabels:
app: site-soren
template:
metadata:
labels:
app: site-soren
spec:
containers:
- name: site-soren
image: deivid/nova-soren:latest
ports:
- containerPort: 8080

Ele ficou com uma réplica só, justamente porque meu objetivo não era fazer escala fixa manual ali, e sim conectar isso depois com HPA.

Também defini recursos do container 💻

Dentro do ReplicaSet, eu já aproveitei para declarar CPU e memória.

resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "256Mi"

Esses números parecem estranhos no começo, mas depois fazem sentido:

100m = 0.1 core
500m = 0.5 core
128Mi = 128 mebibytes

Na prática:

requests = o mínimo reservado
limits = o teto

Isso ajuda tanto no agendamento quanto no comportamento da aplicação dentro do cluster.

O Service entrou para estabilizar a comunicação 🔄

Depois criei o Service.

Esse recurso foi um divisor de águas no meu entendimento.

Porque o Pod não é fixo.
Ele pode cair, subir de novo, mudar IP.

Então o Service entra como um endereço estável e encontra os Pods pela label.

apiVersion: v1
kind: Service
metadata:
name: site-soren-service
spec:
selector:
app: site-soren
ports:
- protocol: TCP
port: 4500
targetPort: 8080

No meu caso:

o Service expõe a porta 4500
o container recebe na 8080

Foi aqui que comecei a entender a relação:

Ingress → Service → Pods

Escala automática com HPA 📊

Para não deixar minha aplicação “engessada”, adicionei um HPA.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: site-soren-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: ReplicaSet
name: site-soren-rs
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80

Uma dúvida que eu tinha e que muita gente tem:

o HPA precisa que CPU e memória batam juntas?

Não.

Ele olha as métricas separadamente.
Se a CPU pedir mais escala antes, ele sobe.
Se a memória pedir antes, ele sobe também.

Então ele considera o cenário que está mais pressionando a aplicação naquele momento.

O Ingress foi a camada de entrada 🌍

Depois veio o Ingress, que foi quem amarrou o domínio à aplicação.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: site-soren-ingress
spec:
ingressClassName: nginx
rules:
- host: devid.ferraz.test
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: site-soren-service
port:
number: 4500

Aqui eu aprendi um detalhe importante:

O objeto Ingress sozinho não faz milagre.
Ele precisa de um Ingress Controller rodando no cluster.

No Minikube, eu habilitei isso assim:

minikube addons enable ingress -p multinode

E dependendo do ambiente local, também usei:

minikube tunnel -p multinode

Então eu passei a explicar assim para mim mesmo:

o Ingress define a regra
o controller executa a regra
o tunnel ajuda a expor isso localmente, quando necessário

Como resolvi o domínio local 🏡

Como eu estava rodando tudo localmente, precisava que o meu domínio resolvesse para a máquina local.

Então usei o arquivo hosts:

127.0.0.1 devid.ferraz.test

Isso fez com que minha máquina entendesse que devid.ferraz.test deveria apontar para o IP local.

Esse detalhe também explica uma dúvida comum:

por que localhost não funciona igual?

Porque o Ingress estava esperando o host devid.ferraz.test.
Então não bastava só chegar no IP certo — a requisição precisava chegar com o host certo também.

Build da imagem e erro antes do image load 🐳

Outro ponto que achei legal mostrar foi a diferença entre:

a imagem existir na minha máquina
a imagem existir dentro do cluster

Eu buildava localmente:

docker build -t deivid/nova-soren:latest .

Mas antes de fazer o load, eu fazia questão de mostrar o erro.
Porque, se a imagem não estiver disponível no cluster, o Pod não sobe do jeito esperado.

Depois disso eu carregava a imagem no Minikube:

minikube image load deivid/nova-soren:latest -p multinode

E aí sim o cluster conseguia usar a imagem local.

Aplicando os manifests ✅

Depois de organizar contexto, namespace, ingress e imagem, o apply ficou limpo:

kubectl apply -f site-soren.yaml
kubectl apply -f site-soren-service.yaml
kubectl apply -f site-soren-hpa.yaml
kubectl apply -f site-soren-ingress.yaml

E depois era só conferir:

kubectl get pods
kubectl get svc
kubectl get ingress
kubectl get hpa

Esse foi um ponto que eu gostei bastante de ajustar:
em vez de repetir --context multinode -n meusite em todo comando, eu defini isso antes uma vez e deixei o terminal preparado.

O que eu realmente aprendi com esse processo 💡

O maior ganho não foi só ver minha aplicação abrir no navegador.

Foi entender a responsabilidade de cada peça.

ReplicaSet mantém os Pods
Service estabiliza a comunicação
HPA escala quando a carga sobe
Ingress recebe o tráfego HTTP
hosts resolve o domínio local
image load leva a imagem para dentro do cluster local

Depois que enxerguei isso, Kubernetes deixou de parecer só um monte de YAML.

Passou a parecer uma arquitetura que conversa entre si.

E, honestamente, esse tipo de estudo na prática me ensinou muito mais do que só assistir explicação isolada.

Services no Kubernetes

DeividFerraz — Mon, 06 Apr 2026 02:07:57 +0000

🚀 O que eu aprendi sobre Kubernetes Service (e por que isso finalmente fez sentido pra mim)

Depois de apanhar um pouco tentando entender como minha API realmente “se comunica” dentro do cluster, finalmente caiu a ficha sobre o papel do Service no Kubernetes.

Se você também já ficou confuso com Pods mudando de IP, balanceamento e tipos de Service… esse resumo pode te ajudar 👇

🧠 Primeiro insight (o mais importante)
👉 Pods são efêmeros

Eles sobem e caem

O IP muda o tempo todo

👉 Service resolve isso

Dá um IP fixo + DNS estável

E ainda faz load balancing automaticamente

⚙️ Como o Service realmente funciona
O Service não “conhece” ReplicaSet, Deployment nem nada disso.

Ele só faz:

selector:
app: minha-api
E pensa:

“Vou mandar tráfego pra qualquer Pod com essa label”

💥 Pronto. É assim que ele encontra os Pods.

⚖️ Load Balancing
Se você tem 3 Pods:

Pod A (IP 10.0.0.1)
Pod B (IP 10.0.0.2)
Pod C (IP 10.0.0.3)
O Service faz:

Cliente → Service → distribui entre A, B, C
👉 Você não precisa saber os IPs 👉 Você não precisa atualizar nada manualmente

🔌 Sobre portas
ports:

port: 80 targetPort: 3000 port → porta do Service

targetPort → porta do container

💡 Dica: use named ports pra deixar mais claro:

ports:

port: 80 targetPort: http Um ponto importante. Esse (http) é apenas o nome dado para a porta na sessão de containers.ports dentro do yaml do POD, ou no meu caso do ReplicaSet.

🌐 Os 2 tipos mais usados na prática
🔵 1. ClusterIP (padrão)
👉 Usado para comunicação interna

type: ClusterIP
✔️ Só funciona dentro do cluster ✔️ Ideal para microservices ✔️ Mais seguro

Exemplo real:

backend falando com banco

API interna chamando outro serviço

🟢 2. LoadBalancer
👉 Usado para expor para fora

type: LoadBalancer
✔️ Cria um IP externo ✔️ Acessível via internet ✔️ Ideal para APIs públicas

Exemplo:

sua API que será consumida por frontend ou terceiros

🧠 Boas práticas que aprendi
✅ Use labels consistentes (app, tier, etc.) ✅ Prefira ClusterIP por padrão (segurança) ✅ Só use LoadBalancer quando precisar expor ✅ Use named ports pra facilitar manutenção ✅ Sempre confira os endpoints se algo não funcionar.

🔥 Resumo mental
Pod = efêmero

Service = estável

Labels = conexão 🔗

Service = load balancer automático ⚖️

💬 Conclusão
O Service não é só “um detalhe” do Kubernetes.

Ele é o que transforma:

👉 containers isolados em 👉 um sistema distribuído que funciona de verdade

🚨 CrashLoopBackOff no Kubernetes: o que é e por que acontece?

DeividFerraz — Mon, 30 Mar 2026 04:14:55 +0000

Quem trabalha com Kubernetes cedo ou tarde encontra esse status no terminal:

CrashLoopBackOff

Ele aparece quando um container dentro do Pod falha repetidamente e o Kubernetes passa a reiniciá-lo com um tempo de espera progressivo entre as tentativas. Esse status é mostrado pelo kubectl para indicar exatamente esse ciclo de falha + reinício + espera.

🔁 Como funciona na prática

Quando a aplicação quebra, o Kubernetes não reinicia o container infinitamente sem pausa.

Ele aplica um backoff exponencial, com atrasos como:

10s → 20s → 40s → 80s...

Esse tempo cresce até um limite máximo de 5 minutos entre as tentativas de reinício. Se a aplicação continuar falhando, o Kubernetes continua tentando, mas respeitando esse teto.

🛡️ Qual é a finalidade do CrashLoopBackOff?

A ideia não é “travar” o Pod por acaso. O objetivo é:

evitar reinícios inúteis sem parar
reduzir consumo desnecessário de recursos no node e no cluster
dar tempo para diagnóstico
deixar claro que a aplicação está falhando repetidamente

Ou seja: o CrashLoopBackOff é uma forma de proteger a infraestrutura e, ao mesmo tempo, evidenciar que algo está errado na aplicação.

⏱️ E os 10 minutos?

Existe um ponto importante aqui: se o container conseguir ficar 10 minutos rodando sem falhar, o Kubernetes zera o contador do backoff. Então, se ele voltar a quebrar depois disso, a próxima espera volta a começar do início, em vez de continuar num intervalo alto.

⚙️ O papel do restartPolicy

O comportamento também depende da política de reinício do Pod:

Always: sempre tenta reiniciar
OnFailure: reinicia apenas se houver erro
Never: não reinicia automaticamente

O valor padrão em Pods é Always.

✅ E quando o Pod termina com sucesso?

Isso também pode gerar reinício, dependendo da política usada.

Se um container termina com sucesso, mas o Pod está com restartPolicy: Always, ele pode ser iniciado novamente. Só que esse não costuma ser o modelo ideal para tarefas que têm começo, meio e fim.

🧩 Quando usar Job em vez de Pod?

Para tarefas que executam e terminam, o recurso mais adequado normalmente é um Job.

O Job existe justamente para workloads finitas e aceita apenas restartPolicy: Never ou OnFailure no template do Pod. Quando a tarefa termina com sucesso, o Job considera a execução concluída.

🎯 Resumindo

O CrashLoopBackOff não é só um erro visual no terminal.
Ele é um mecanismo do Kubernetes para:

desacelerar reinícios de uma aplicação quebrada
evitar desperdício de recursos
facilitar diagnóstico
proteger o node e o cluster

Em resumo: se o Pod falha repetidamente, o Kubernetes não reinicia “na marra” para sempre ele controla esse comportamento de forma inteligente.

etcd: a camada de armazenamento do Kubernetes

DeividFerraz — Mon, 23 Mar 2026 17:55:05 +0000

Boa tarde, Pessoal. 👋

etcd: a camada de armazenamento do Kubernetes

Estudando Kubernetes, comecei a olhar com mais atenção para alguns componentes que quase não aparecem no uso do dia a dia, mas são fundamentais para o funcionamento do cluster. Um deles é o etcd.

Quando estamos em ambientes gerenciados, principalmente em nuvem, é muito fácil focar só em Deployment, Service, Ingress, escalabilidade e esquecer da base que sustenta o estado do cluster. Mas entender isso ajuda bastante a enxergar melhor o funcionamento do Kubernetes por trás dos panos.

━━━━━━━━━━━━━━━━━━

📌 O que é o etcd?

━━━━━━━━━━━━━━━━━━

O etcd é um banco de dados distribuído do tipo chave-valor que o Kubernetes usa para armazenar o estado do cluster.

É nele que ficam registradas informações como:

• Pods

• Services

• Deployments

• ConfigMaps

• Secrets

• Namespaces

• entre outros objetos do plano de controle

Ou seja, boa parte do que existe no cluster, em algum momento, depende do etcd para ter esse estado armazenado.

━━━━━━━━━━━━━━━━━━

⚙️ Como ele participa da arquitetura do Kubernetes

━━━━━━━━━━━━━━━━━━

Na prática, a comunicação acontece principalmente por meio do kube-apiserver. É ele que recebe as requisições, faz a validação, processa as informações e consulta ou grava esses dados no etcd.

Isso ajuda a entender melhor o papel do etcd: mesmo sem aparecer tanto no uso diário, ele é uma peça central da arquitetura.

Em ambientes com alta disponibilidade, o etcd pode rodar em múltiplos nós, formando um cluster distribuído. Isso aumenta a resiliência e reduz o risco de indisponibilidade em caso de falha de uma instância.

Por isso, a saúde do etcd impacta diretamente a saúde do cluster.

━━━━━━━━━━━━━━━━━━

💾 E o backup, como funciona?

━━━━━━━━━━━━━━━━━━

Como o etcd armazena o estado do cluster, manter backups regulares é essencial para recuperação em cenários de desastre, como perda de nós do plano de controle ou corrupção de dados.

A forma mais comum de fazer isso é por meio de snapshot.

Esse snapshot registra o conteúdo do banco naquele momento e pode ser usado depois em uma restauração.

Um detalhe importante: não é necessário parar o kube-apiserver para gerar esse backup.

O etcd permite criar snapshot a partir de um membro em execução usando o comando etcdctl snapshot save. Ou seja, esse processo pode ser feito com o serviço ativo.

━━━━━━━━━━━━━━━━━━

🧩 Exemplo de comando: doc: Operando clusters etcd para Kubernetes | Kubernetes

━━━━━━━━━━━━━━━━━━

🔎 O que esse comando faz: Leia a doc: https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

━━━━━━━━━━━━━━━━━━

🛠️ Exemplo prático: Leia a doc também: https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

━━━━━━━━━━━━━━━━━━

Depois de gerar o backup, ainda é possível validar o snapshot com:

etcdutl --write-out=table snapshot status /backup/etcd-snapshot.db

Kubernetes #DevOps #Cloud #SRE #Containers

Deploy aplicação no cluster do aks 🚀

DeividFerraz — Tue, 17 Mar 2026 19:25:04 +0000

Eae pessoal! 👋

Hoje vou compartilhar com vocês uma forma simples e eficiente de criar um pipeline em YAML no Azure DevOps para publicar uma aplicação no AKS (Azure Kubernetes Service).🚀

Contexto:

Aqui na empresa, já temos um repositório central com templates prontos de pipeline + Helm, o que acelera muito o processo de criação de novas APIs e jobs.

Neste post, vou mostrar como usamos esse template.

👉 Em um próximo, posso mostrar como fazer tudo do zero.

🧩 Estrutura do pipeline

A ideia é bem simples:

Criamos um repositório do projeto

Adicionamos um azure-pipelines.yml mínimo

Referenciamos um template centralizado

Ou seja:

👉 O projeto praticamente não precisa de configuração — a inteligência já está no template.

📦 Pipeline do projeto

No YAML do projeto, definimos apenas o essencial:

branch

dockerFilePath

dockerBuildContext

Todo o restante vem do template e de arquivos como o values.yaml.

💡 Isso reduz drasticamente erros e padroniza deploys.

⚙️ O papel do template (Helm + Pipeline)

O template é o coração da solução.

Ele é responsável por:

Build da imagem Docker

Push para o container registry

Deploy no AKS via Helm

Configuração de ambiente (Dev/Prod)

Integração com variáveis e secrets

👉 Ou seja: ao rodar o pipeline, toda a infraestrutura é provisionada automaticamente e a aplicação já sobe no cluster do AKS.

🧠 Por que usar Helm + Templates?

A principal vantagem é abstrair a infraestrutura do desenvolvedor.

O dev:

Não precisa acessar o portal do Azure

Não precisa configurar Kubernetes manualmente

Só precisa garantir que o projeto está correto

⚠️ Boas práticas ao criar templates Helm

Aqui vai um ponto importante 👇

O poder do template depende de como você o constrói. Algumas boas práticas:

🔹 Padronize nomes e labels (facilita observabilidade)

🔹 Separe configs por ambiente (dev, staging, prod)

🔹 Use values.yaml bem estruturado

🔹 Evite hardcode de credenciais (use secrets/Key Vault)

🔹 Permita override de variáveis importantes

🔹 Versione o chart Helm

🔹 Adicione health checks (liveness/readiness probes)

🔹 Defina requests/limits de CPU e memória

Um bom template evita retrabalho e reduz incidentes em produção.

--- 🧪 Resultado

Com esse modelo, precisamos basicamente informar:

Caminho do Dockerfile

Contexto de build

Branch

E pronto 🚀

O pipeline cuida de todo o resto e a aplicação já sobe no cluster do AKS.

Imagem de exemplo prático no meu linkedin: https://www.linkedin.com/feed/update/urn:li:activity:7439753064225366016/?originTrackingId=WQDMTOfIYxXFTM3qmKO3KA%3D%3D

🚀 Pods no Kubernetes (com 2 containers no mesmo Pod):

DeividFerraz — Tue, 23 Sep 2025 22:21:53 +0000

Continuação...

2) Services (um para cada porta do mesmo Pod):
apiVersion: v1
kind: Service
metadata:
name: api3a-svc
namespace: prod
spec:
selector: { app: api3, svc-api3a: "true" }

ports: [{ port: 80, targetPort: 8080 }]

apiVersion: v1
kind: Service
metadata:
name: api3b-svc
namespace: prod
spec:
selector: { app: api3, svc-api3b: "true" }
ports: [{ port: 80, targetPort: 8081 }]

⁉️Service não “aponta para container”; ele seleciona Pods por label. O que diferencia é o targetPort. exemplo: 10.224.0.31(PodIP):(targetPort)8080. _________________________________________________________________________________ 3) Ingress (um host, vários paths → Services): apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: prod-paths namespace: prod annotations: https://lnkd.in/du23U4PY: / spec: ingressClassName: nginx rules:
host: 20-246-240-254.sslip.io # ou api.seu-dominio.com http: paths:
path: /api3a //necessario para encaminhar ao backend abaixo(service) pathType: Prefix backend: { service: { name: api3a-svc, port: { number: 80 } } }
path: /api3b pathType: Prefix backend: { service: { name: api3b-svc, port: { number: 80 } } }

🚀 Pods no Kubernetes (com 2 containers no mesmo Pod):

DeividFerraz — Tue, 23 Sep 2025 22:14:50 +0000

☝️ Resumo do artigo:

Cliente → DNS/Host → IP público (LB do ingress-nginx) -> Pod do ingress-nginx (Nginx) → Ingress (host + path).
Ingress decide quem recebe (host + path) e fala com Service. -> Service (ClusterIP:port, L4) → Endpoints (PodIP:targetPort).
Service seleciona Pods por labels e encaminha para PodIP:targetPort. -> Pod (containers compartilham o mesmo IP, portas diferentes).
Pod = mesmo IP para todos os containers; o que muda é a porta.

🚢 O que é um Pod:
Menor unidade implantável, pode ter 1 ou mais containers.

Containers do mesmo Pod compartilham:
Network namespace → mesmo IP (o Pod IP), localhost comum
Volumes (se montados).

IMPORTANTE: Você não cria Pod “puro” na produção: cria um Deployment, que cria ReplicaSet, que cria Pods.

🧭 Por que usar Namespaces?

Isolam nomes: api1 em dev e api1 em prod.
Controlam acesso (RBAC), quotas, políticas de rede.
Ciclo de vida: deletar o namespace remove tudo.

🧪 Exemplo prático: duas APIs no mesmo Pod (api3a + api3b):
1) Deployment (um Pod com 2 containers, portas 8080 e 8081):
apiVersion: apps/v1
kind: Deployment
metadata:
name: api3
namespace: prod
spec:
replicas: 1
selector:
matchLabels: { app: api3 }
template:
metadata:
labels:
app: api3
svc-api3a: "true" # ajuda os Services a “enxergar” este Pod
svc-api3b: "true"
spec:
containers:

name: api3a image: https://suaiamgem ports: [{ name: http-api3a, containerPort: 8080 }] env: [{ name: ASPNETCORE_URLS, value: http://+:8080 }] readinessProbe: { httpGet: { path: "/", port: 8080 }, initialDelaySeconds: 5, periodSeconds: 10 } livenessProbe: { httpGet: { path: "/", port: 8080 }, initialDelaySeconds: 10, periodSeconds: 20 }
name: api3b image: https://suaimagem ports: [{ name: http-api3b, containerPort: 8081 }] env: [{ name: ASPNETCORE_URLS, value: http://+:8081 }] readinessProbe: { httpGet: { path: "/", port: 8081 }, initialDelaySeconds: 5, periodSeconds: 10 } livenessProbe: { httpGet: { path: "/", port: 8081 }, initialDelaySeconds: 10, periodSeconds: 20 } ⁉️ - Por quê duas portas?
Containers do mesmo Pod compartilham IP, então precisam portas diferentes.

CONTINUAÇÂO NO PRÒXIMO POST...

Redes virtuais do Azure.

DeividFerraz — Sat, 13 Sep 2025 04:08:25 +0000

🌐 Redes Virtuais no Azure: conectividade segura e de alta disponibilidade para sua empresa

No mundo digital de hoje, conectar ambientes locais à nuvem com segurança, baixa latência e resiliência deixou de ser um diferencial e passou a ser uma necessidade. O Azure oferece uma variedade de opções de redes virtuais que permitem interligar datacenters, filiais e usuários remotos ao poder da nuvem, garantindo escalabilidade e proteção contra falhas.

🔹 Tipos de conexões de rede virtual

Ponto-a-Site (P2S):

Ideal para usuários individuais, como colaboradores remotos.
O próprio computador do usuário inicia uma VPN criptografada até a VNet no Azure.
Ótima opção para home office ou acessos ocasionais.

Site-a-Site (S2S):

Perfeito para integração contínua de datacenters locais ou filiais.
Um appliance VPN local se conecta ao Azure VPN Gateway.
A rede local é estendida para a nuvem como se fosse uma única infraestrutura.

ExpressRoute:

Para quem precisa de segurança e desempenho máximos.
Conexão privada e dedicada ao backbone da Microsoft, sem passar pela Internet pública.
Ideal para workloads críticos, replicações de dados em larga escala e cenários regulatórios.

🔹 Conectando redes virtuais no Azure:

Além de conectar sua empresa à nuvem, o Azure também permite interligar VNets entre si por meio de:

Emparelhamento de VNets (VNet Peering): conecta redes virtuais de forma transparente e privada, usando o backbone da Microsoft.
Service Endpoints e Private Endpoints: formas de expor serviços como Storage e SQL de maneira segura, evitando exposição pública.

🔹 Alta disponibilidade e proteção contra falhas:

Quando falamos em continuidade de negócios, a arquitetura de rede também precisa ser resiliente:

Gateways ativo/ativo: dois IPs públicos para reduzir downtime.
Gateways redundantes em zonas de disponibilidade: proteção contra falhas físicas em datacenters.
Failover com ExpressRoute + VPN: se a conexão dedicada falhar, uma VPN site-a-site pode assumir como backup.
Esses recursos garantem que sua empresa continue operando mesmo em cenários de falha ou manutenção.

🔹 Segurança e roteamento de tráfego:

NSGs (Network Security Groups): filtros em nível de rede (L3/L4) para controlar tráfego entre sub-redes.
Tabelas de rotas (UDRs): regras personalizadas de encaminhamento.
BGP (Border Gateway Protocol): troca dinâmica de rotas entre sua rede e o Azure.
Com isso, é possível controlar fluxos, segmentar ambientes e proteger dados sensíveis.

🚀 Conclusão

As redes virtuais do Azure oferecem flexibilidade para diferentes cenários: de um desenvolvedor acessando remotamente recursos de teste até grandes corporações que demandam links dedicados, redundância e alta segurança.

Docker Compose: Simplificando o Gerenciamento de Containers

DeividFerraz — Sat, 23 Aug 2025 05:09:06 +0000

O Docker revolucionou a forma como desenvolvemos e entregamos aplicações, mas gerenciar vários containers manualmente pode ser confuso e trabalhoso. Para não haver esse tipo de problema que entra o Docker Compose. Docker compose é uma ferramenta poderosa que permite definir e orquestrar múltiplos containers de forma simples e organizada, usando um único arquivo YAML (nome de arquivo padrão: docker-compose.yml).

✅ Em que momento usar o Docker compose?
Quando vc tiver aplicações que conversam entre si, é ideal usar o Docker Compose, Pq ele permite agrupar esses serviços. Por exemplo: uma aplicação web pode depender de um banco de dados e de um cache, e todos esses containers podem ser definidos e gerenciados juntos.

Beneficios:

Serviços como, imagens, porta, rede entre outros ficam descritos no mesmo arquivo, assim, ficam mais facil de serem manipulados.
Com apenas um simples comando, conseguimos subir, para reconstruir toda a stack de serviços, só isso já elimina a necessidade de escrever varios comandos para instanciar apenas um container.
O mesmo arquivo pode ser usado em diferentes máquinas e ambientes (local, staging, produção), garantindo consistência e evitando o famoso “na minha máquina funciona”. Isso é possível porque toda a aplicação é encapsulada em containers, que incluem suas dependências e configuram um ambiente padronizado.
Independentemente se você estiver rodando em Linux, Windows ou macOS, o Docker garante essa compatibilidade.

Código usado:

docker-compose -f docker-compose-local.yml -p dev-store up -d Explicação dos termos: -f: especifica qual arquivo YAML usar (ex.: docker-compose-local.yml). -p: define o nome do projeto (usado para nomear containers, rede e volumes). up: sobe todos os serviços definidos no YAML. -d: executa em modo “detached” (em segundo plano).
É importante usar para n ficar preso no terminal.

Imagens e Containers: pensando como classe e instância

DeividFerraz — Fri, 22 Aug 2025 03:45:43 +0000

Quando eu comecei a mexer com Docker, acabava confundindo bastante imagens com containers, e creio que muita gente também. Eles são muito relacionados, mas não são a mesma coisa. Uma imagem é um pacote encapsulado com tudo que a aplicação precisa para rodar, já um container é a imagem em execução, com seu próprio processo e configurações de rede.

Vi uma análogia no treinamento que estou fazendo atualmente que deixou tudo isso ainda mais claro.
--(Em termos de programação orientada a objetos: imagem é como a classe, e container é como a instância da classe. EX: var car = new Carro();)

-Através dele, você pode expor na rede por meio de portas, dar um nome e fazer algumas alterações. Só não podemos esquecer que toda alteração feita em um container fica salva apenas na memória daquele container.

Para resumir, o container acaba se tornando a sua imagem gerenciada.

Redes no Docker, Bridge e Outras Possibilidades

DeividFerraz — Wed, 20 Aug 2025 03:30:21 +0000

-Quando trabalhamos com containers, um dos pontos mais importantes é como eles se comunicam entre si e com o mundo externo. É aqui que entram as redes do Docker, que garantem conectividade, isolamento e flexibilidade.

-Existem alguns tipos de rede no docker, o principal entre eles é; Bridge.
Os containers conectados a uma rede bridge podem se comunicar entre si usando o nome do container como hostname.
Também permite comunicação com o host e com a internet, quando configurada.

Comando exemplo para criar uma rede e já indicar o driver (O tipo de rede) que aquele container vai ser exposto;

docker network create --driver bridge/TipoDeRede minha-rede/nomeDaMinhaRede

Conhecimento em redes é a base para começar a entender como os containers se relacionam entre si.
hashtag#docker hashtag#rede #8080 hashtag#port

[Boost]

DeividFerraz — Wed, 20 Aug 2025 03:28:46 +0000