Forem: DeividFerraz

Kubernetes RBAC: controlando quem pode fazer o quê dentro do cluster 🔐☸️

DeividFerraz — Fri, 08 May 2026 17:44:41 +0000

Quando falamos de segurança em Kubernetes, um dos recursos mais importantes é o RBAC.

RBAC significa Role-Based Access Control, ou seja, controle de acesso baseado em papéis.

Na prática, ele responde uma pergunta muito simples:

Quem pode fazer o quê dentro do cluster?

E isso é essencial para evitar que qualquer usuário, aplicação ou automação tenha acesso maior do que deveria.

O que o RBAC controla? 🤔

Com RBAC, conseguimos definir limites de acesso para recursos do Kubernetes, como:

✅ Pods
✅ Deployments
✅ Services
✅ ConfigMaps
✅ Secrets
✅ Namespaces
✅ Nodes
✅ Jobs
✅ Ingress
✅ Recursos customizados

Essas permissões podem ser aplicadas para:

👤 Users
👥 Groups
🤖 ServiceAccounts

Ou seja, podemos controlar tanto acessos humanos quanto acessos de aplicações que rodam dentro do cluster.

Os principais recursos do RBAC 🧩

No Kubernetes, trabalhamos principalmente com quatro recursos:

✅ Role
✅ ClusterRole
✅ RoleBinding
✅ ClusterRoleBinding

Cada um tem uma função bem específica.

Role: permissões dentro de um namespace 📦

A Role é usada para criar regras de acesso dentro de um namespace específico.

Ou seja, ela não vale para o cluster inteiro.

Exemplo de uma Role permitindo listar, visualizar, alterar e deletar Pods e Deployments dentro do namespace dev:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: workload-manager
namespace: dev
rules:

apiGroups: [""]
resources:
- pods verbs:
- get
- list
- watch
- update
- patch
- delete
apiGroups: ["apps"]
resources:
- deployments verbs:
- get
- list
- watch
- update
- patch
- delete

Nesse exemplo, estamos dizendo:

👉 Dentro do namespace dev, quem receber essa Role poderá consultar, listar, acompanhar, alterar e deletar Pods e Deployments.

ClusterRole: permissões em nível de cluster 🌎

A ClusterRole é parecida com a Role, mas ela não fica presa a um namespace.

Ela pode ser usada para permissões em nível de cluster ou para criar uma regra reutilizável em vários namespaces.

Exemplo de ClusterRole com a mesma ideia:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: workload-manager-cluster
rules:

apiGroups: [""]
resources:
- pods verbs:
- get
- list
- watch
- update
- patch
- delete
apiGroups: ["apps"]
resources:
- deployments verbs:
- get
- list
- watch
- update
- patch
- delete

Aqui criamos uma regra em contexto de cluster.

Mas atenção: criar uma ClusterRole não significa que alguém já tem esse acesso.

A regra fica criada, mas ainda precisa ser vinculada a alguém.

Binding: ligando a regra a alguém 🔗

Role e ClusterRole definem o que pode ser feito.

RoleBinding e ClusterRoleBinding definem quem pode fazer.

Essa é uma das partes mais importantes do RBAC.

RoleBinding: acesso limitado a um namespace 📦

Agora vamos ligar a Role workload-manager a um usuário chamado john.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: john-workload-manager
namespace: dev
subjects:

kind: User name: john apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: workload-manager apiGroup: rbac.authorization.k8s.io

Nesse caso, o usuário john recebe as permissões da Role workload-manager, mas somente dentro do namespace dev.

Ou seja:

✅ pode atuar no namespace dev
❌ não recebe acesso automático aos outros namespaces

Usando ClusterRole com RoleBinding 🎯

Um ponto muito interessante do RBAC é que podemos usar uma ClusterRole com um RoleBinding.

Isso permite reaproveitar uma regra criada em nível de cluster, mas limitar o acesso a um namespace específico.

Exemplo:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: john-clusterrole-limited-to-dev
namespace: dev
subjects:

kind: User name: john apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: workload-manager-cluster apiGroup: rbac.authorization.k8s.io

Aqui estamos dizendo:

👉 Use a ClusterRole workload-manager-cluster, mas aplique esse acesso somente dentro do namespace dev.

Esse modelo é muito útil quando queremos criar permissões padronizadas e reutilizar em vários namespaces.

Por exemplo:

📌 mesma permissão para times diferentes
📌 mesma regra para ambientes dev, stage e prod
📌 mesmo padrão de acesso para vários namespaces
📌 menos repetição de YAML
📌 mais controle e organização

ClusterRoleBinding: acesso em todo o cluster 🌎

Agora, se quisermos dar acesso em nível de cluster, usamos um ClusterRoleBinding.

Exemplo vinculando a ClusterRole ao usuário john:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: john-workload-manager-cluster
subjects:

kind: User name: john apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: workload-manager-cluster apiGroup: rbac.authorization.k8s.io

Nesse caso, o usuário john recebe as permissões da ClusterRole em todo o cluster.

Ou seja, ele poderá atuar em todos os namespaces onde aqueles recursos existirem.

Aqui o cuidado precisa ser maior.

ClusterRoleBinding pode abrir muito acesso se for usado sem critério.

Importante ⚠️

Podemos fazer isso:

✅ Role + RoleBinding
✅ ClusterRole + RoleBinding
✅ ClusterRole + ClusterRoleBinding

Mas não usamos uma Role comum com ClusterRoleBinding.

Isso não faz sentido porque uma Role é um recurso limitado a namespace, enquanto um ClusterRoleBinding aplica acesso em nível de cluster.

Se a ideia é conceder acesso global, a regra precisa estar em uma ClusterRole.

RBAC com ServiceAccount 🤖

Até agora vimos exemplos com usuário, mas RBAC também é muito usado com ServiceAccount.

ServiceAccount é muito comum quando uma aplicação, controller, pipeline, job ou automação precisa acessar a API do Kubernetes.

Por exemplo:

📌 um controller que lista Pods
📌 um Job que precisa consultar ConfigMaps
📌 uma aplicação que precisa ler Secrets
📌 um operador que gerencia recursos customizados
📌 uma automação de deploy dentro do cluster

Criando uma ServiceAccount 👇
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-manager
namespace: dev

Agora podemos vincular essa ServiceAccount a uma Role ou ClusterRole.

ServiceAccount com RoleBinding 📦

Exemplo usando a Role workload-manager no namespace dev:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-manager-rolebinding
namespace: dev
subjects:

kind: ServiceAccount name: app-manager namespace: dev roleRef: kind: Role name: workload-manager apiGroup: rbac.authorization.k8s.io

Nesse caso, a ServiceAccount app-manager terá acesso somente dentro do namespace dev.

Esse é um padrão bem comum quando queremos limitar uma aplicação ao próprio namespace.

ServiceAccount usando ClusterRole com RoleBinding 🎯

Também podemos usar uma ClusterRole com RoleBinding para limitar o acesso da ServiceAccount a um namespace específico.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-manager-clusterrole-limited-to-dev
namespace: dev
subjects:

kind: ServiceAccount name: app-manager namespace: dev roleRef: kind: ClusterRole name: workload-manager-cluster apiGroup: rbac.authorization.k8s.io

Aqui a regra vem de uma ClusterRole, mas o acesso fica limitado ao namespace dev.

Esse modelo é excelente para padronizar permissões sem liberar acesso ao cluster inteiro.

ServiceAccount com ClusterRoleBinding 🌎

Agora, se essa ServiceAccount realmente precisar atuar em todo o cluster, usamos ClusterRoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: app-manager-clusterrolebinding
subjects:

kind: ServiceAccount name: app-manager namespace: dev roleRef: kind: ClusterRole name: workload-manager-cluster apiGroup: rbac.authorization.k8s.io

Nesse caso, a ServiceAccount app-manager, mesmo estando no namespace dev, recebe permissão em nível de cluster.

Esse tipo de permissão deve ser usado com muito cuidado.

Verbs mais usados no RBAC 🛠️

Os verbs representam as ações que podem ser executadas nos recursos.

Alguns dos mais comuns são:

✅ get
Permite visualizar um recurso específico.

✅ list
Permite listar vários recursos.

✅ watch
Permite acompanhar mudanças nos recursos em tempo real.

✅ create
Permite criar novos recursos.

✅ update
Permite atualizar um recurso existente.

✅ patch
Permite aplicar alterações parciais em um recurso.

✅ delete
Permite deletar recursos.

✅ deletecollection
Permite deletar múltiplos recursos de uma vez.

✅ impersonate
Permite agir como outro usuário, grupo ou ServiceAccount.

✅ bind
Permite vincular roles a usuários ou ServiceAccounts.

✅ escalate
Permite criar ou modificar roles com permissões maiores.

Os verbs bind, escalate e impersonate merecem atenção especial, porque podem abrir caminho para elevação de privilégio.

Resources mais usados 📦

Os resources são os objetos do Kubernetes que queremos controlar.

Alguns exemplos comuns:

resources:

pods
deployments
services
configmaps
secrets
namespaces
nodes
jobs
cronjobs
ingresses
serviceaccounts
roles
rolebindings
clusterroles
clusterrolebindings

Exemplo:

rules:

apiGroups: [""] resources:
- pods
- services
- configmaps verbs:
- get
- list
- watch API Groups mais usados 🧱

No Kubernetes, os recursos são organizados por apiGroups.

Alguns exemplos:

apiGroups: [""]

Usado para recursos core, como:

pods
services
configmaps
secrets
namespaces

Exemplo:

apiGroups: [""]
resources:

pods
services apiGroups: ["apps"]

Usado para recursos como:

deployments
replicasets
statefulsets
daemonsets

Exemplo:

apiGroups: ["apps"]
resources:

deployments
statefulsets apiGroups: ["batch"]

Usado para:

jobs
cronjobs
apiGroups: ["networking.k8s.io"]

Usado para:

ingresses
networkpolicies
apiGroups: ["rbac.authorization.k8s.io"]

Usado para recursos do próprio RBAC:

roles
rolebindings
clusterroles
clusterrolebindings
Como testar permissões com kubectl 🧪

Uma forma muito útil de validar RBAC é usando:

kubectl auth can-i

Exemplo testando se o usuário john pode listar Pods no namespace dev:

kubectl auth can-i list pods -n dev --as=john

Testando se ele pode deletar Deployments no namespace dev:

kubectl auth can-i delete deployments -n dev --as=john

Testando se ele pode listar Pods em outro namespace:

kubectl auth can-i list pods -n prod --as=john

Se o acesso estiver limitado ao namespace dev, esse comando deve retornar:

no
Testando ServiceAccount 🤖

Para testar permissões de uma ServiceAccount, usamos o formato:

system:serviceaccount:namespace:nome-da-serviceaccount

Exemplo:

kubectl auth can-i list pods -n dev --as=system:serviceaccount:dev:app-manager

Testando delete em Deployments:

kubectl auth can-i delete deployments -n dev --as=system:serviceaccount:dev:app-manager

Testando acesso fora do namespace:

kubectl auth can-i list pods -n prod --as=system:serviceaccount:dev:app-manager

Esse tipo de teste ajuda muito a validar se a permissão está realmente funcionando como esperado.

Por que usar RBAC? 🚀

RBAC é essencial para segurança e organização dentro de um cluster Kubernetes.

Com ele, conseguimos aplicar o princípio do menor privilégio.

Ou seja:

cada usuário, aplicação ou automação recebe somente as permissões que realmente precisa.

Isso reduz bastante o risco de problemas.

RBAC ajuda em cenários como:

✅ separar permissões por time
✅ limitar acesso por namespace
✅ proteger recursos sensíveis como Secrets
✅ evitar alterações acidentais em produção
✅ impedir que aplicações tenham acesso excessivo
✅ controlar permissões de pipelines e automações
✅ reduzir impacto em caso de credencial comprometida
✅ melhorar governança e auditoria dentro do cluster

Conclusão 🔐☸️

RBAC é uma das bases de segurança no Kubernetes.

Ele permite controlar de forma clara:

👤 quem acessa
🛠️ o que pode fazer
📦 em qual recurso
🌎 em qual escopo

A ideia principal é simples:

Role e ClusterRole criam as regras.
RoleBinding e ClusterRoleBinding entregam essas regras para alguém.

Quando usamos RBAC bem configurado, o cluster fica mais seguro, organizado e previsível.

No fim, não é só sobre bloquear acesso.

É sobre garantir que cada pessoa, aplicação ou automação tenha exatamente o acesso necessário.

Nem mais.
Nem menos. 🔐

Kubernetes NetworkPolicy: controlando quem fala com quem dentro do cluster 🔐☸️

DeividFerraz — Fri, 08 May 2026 15:35:16 +0000

Quando falamos de segurança em Kubernetes, muita gente lembra de RBAC, Secrets, ServiceAccounts, imagens seguras e scanners.

Mas existe uma camada extremamente importante que muitas vezes passa despercebida:

👉 o controle de tráfego entre Pods.

É aqui que entra a NetworkPolicy.

O que é uma NetworkPolicy? 🤔
De forma simples, uma NetworkPolicy é um recurso do Kubernetes usado para controlar políticas de entrada e saída de tráfego entre:

✅ Pods ✅ Namespaces ✅ Blocos de IP ✅ Portas específicas

Com esse recurso, conseguimos definir exatamente:

🔹 quem pode acessar um Pod 🔹 para onde um Pod pode enviar tráfego 🔹 quais portas podem ser utilizadas 🔹 quais aplicações devem ficar isoladas 🔹 quais namespaces podem se comunicar

Tudo isso é feito principalmente através de labels.

Ou seja, nós marcamos os Pods com labels e depois criamos regras dizendo quais labels podem se comunicar com outras labels.

Um ponto importante: para a NetworkPolicy funcionar, o CNI do cluster precisa dar suporte a esse recurso. Alguns exemplos são Calico, Cilium, Weave Net, entre outros.

Controlando acesso de entrada com Ingress 🚪
Imagine que temos uma aplicação sensível rodando em Pods com a label:

app: api
Agora queremos permitir que essa API seja acessada somente por Pods que tenham a label:

access: granted
A NetworkPolicy ficaria assim:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-from-granted
namespace: default
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
access: granted
Nesse exemplo, estamos dizendo:

👉 Pods com app: api só podem receber tráfego de Pods com access: granted.

Qualquer outro Pod que não tenha essa label não deve conseguir acessar essa API.

Esse tipo de política é muito útil quando temos workloads mais sensíveis, como:

🔐 bancos de dados 🔐 APIs internas 🔐 serviços administrativos 🔐 aplicações com dados financeiros 🔐 serviços de autenticação 🔐 aplicações que não devem estar disponíveis para todo o cluster

Essa é uma camada extra de segurança muito importante.

Mesmo que alguém consiga subir um Pod no cluster, isso não significa que ele conseguirá se comunicar com todos os serviços.

Controlando saída de tráfego com Egress 📤
Além de controlar quem acessa um Pod, também podemos controlar para onde um Pod pode enviar tráfego.

Esse tipo de regra é chamado de Egress.

Imagine agora que os Pods com a label:

app: api
só podem enviar tráfego para Pods com a label:

access: find-api
A NetworkPolicy ficaria assim:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-egress-to-find-api
namespace: default
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
access: find-api
Aqui estamos dizendo:

👉 Pods com app: api só podem enviar tráfego para Pods com access: find-api.

Esse tipo de controle é muito interessante quando um Pod tem um objetivo bem específico.

Por exemplo:

📌 uma API que só deve falar com um banco de dados 📌 um worker que só deve consumir mensagens de uma fila 📌 um serviço que só deve chamar uma API interna 📌 um Pod com permissões críticas que não deve acessar qualquer outro serviço 📌 uma aplicação que só deve se comunicar com um único backend

Isso ajuda bastante a reduzir o impacto caso alguma aplicação seja comprometida.

Controlando acesso por portas 🎯
Além de controlar origem e destino, também conseguimos controlar portas e protocolos.

Os protocolos mais comuns em NetworkPolicy são:

TCP
UDP
SCTP
HTTP normalmente roda sobre TCP, geralmente na porta 80.

HTTPS normalmente roda sobre TCP, geralmente na porta 443.

DNS geralmente usa UDP na porta 53, mas também pode usar TCP na porta 53 em alguns cenários.

Exemplo permitindo acesso apenas nas portas 80/TCP e 53/TCP/UDP:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-specific-ports
namespace: default
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
access: granted
ports:
- protocol: TCP
port: 80
- protocol: TCP
port: 53
- protocol: UDP
port: 53
Nesse exemplo, os Pods com app: api só podem ser acessados por Pods com access: granted, e apenas nas portas configuradas.

Isso é muito útil quando queremos garantir que uma aplicação seja acessada somente pelo caminho esperado.

Por exemplo:

🌐 uma API somente pela porta 80 🔒 uma API HTTPS somente pela porta 443 🐘 um PostgreSQL somente pela porta 5432 ⚡ um Redis somente pela porta 6379 📡 um serviço DNS somente pela porta 53

Testando se as políticas estão funcionando 🧪
Depois de criar as políticas, é importante validar se o comportamento está correto.

Podemos usar kubectl exec para entrar em um Pod e testar a comunicação.

Testando acesso HTTP 🌐
kubectl exec pod-name -n namespace -- wget -qO- http://ip-do-pod
Esse comando pode ser usado para verificar se um Pod consegue acessar outro via HTTP.

Exemplo:

kubectl exec client-pod -n default -- wget -qO- http://10.0.0.20
Aqui podemos testar se o Pod de origem com a label access: granted consegue acessar o Pod de destino com a label app: api.

Também vale testar com um Pod sem a label access: granted.

Nesse caso, o acesso deve falhar.

Testando conexão em uma porta específica 🎯
kubectl exec pod-name -n namespace -- nc -zv ip-do-pod porta
Exemplo:

kubectl exec client-pod -n default -- nc -zv 10.0.0.20 80
Esse comando testa se uma porta está acessível.

Se a política permitir tráfego na porta 80/TCP, a conexão deve funcionar.

Se você testar uma porta não permitida, a conexão deve falhar.

Testando DNS 📡
kubectl exec pod-name -n namespace -- nslookup kubernetes.default
Exemplo:

kubectl exec client-pod -n default -- nslookup kubernetes.default
Esse teste é muito importante principalmente quando criamos regras de Egress.

Quando bloqueamos toda a saída de um Pod, podemos acabar bloqueando também a resolução de DNS.

E aí acontece aquele cenário clássico:

a aplicação até tem permissão para acessar um serviço, mas não consegue resolver o nome dele.

Por isso, em políticas de Egress mais restritivas, normalmente precisamos liberar tráfego para o DNS do cluster.

Exemplo liberando DNS em Egress 📡
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-egress-dns
namespace: default
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
Com isso, os Pods com app: api conseguem consultar o DNS do cluster.

Esse tipo de regra é muito comum quando criamos políticas de saída mais restritivas.

Um ponto de atenção ⚠️
Quando aplicamos uma NetworkPolicy em um Pod, o comportamento de rede muda.

Se criamos uma política do tipo Ingress, o Pod passa a aceitar somente o tráfego de entrada permitido por aquela política.

Se criamos uma política do tipo Egress, o Pod passa a enviar somente o tráfego de saída permitido por aquela política.

Ou seja: é muito fácil bloquear mais do que deveria se a política não for bem planejada.

Por isso, antes de aplicar em produção, sempre vale testar em um ambiente controlado.

Conclusão 🚀
NetworkPolicy é um recurso muito poderoso para aumentar a segurança dentro de um cluster Kubernetes.

Com ela, conseguimos sair daquele modelo onde:

“todo mundo fala com todo mundo”
E passar para um modelo mais controlado, onde:

“cada aplicação só se comunica com o que realmente precisa”
Isso ajuda em vários cenários:

✅ isolamento de banco de dados ✅ proteção de APIs internas ✅ controle de tráfego entre namespaces ✅ redução do impacto em caso de invasão ✅ aplicação do princípio do menor privilégio ✅ maior previsibilidade na comunicação entre serviços

No fim, NetworkPolicy não é só sobre bloquear tráfego.

É sobre desenhar melhor a comunicação entre as aplicações.

E em Kubernetes, isso faz muita diferença. 🔐☸️

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.