Entenda Docker, containers, imagens, redes, volumes, segurança, observabilidade e critérios técnicos para adoção em ambientes corporativos.
Confira!
Docker é uma plataforma de conteinerização usada para empacotar, distribuir e executar aplicações em ambientes isolados e reproduzíveis. Seu valor não está apenas em “rodar containers”, mas em padronizar a relação entre aplicação, dependências e infraestrutura, reduzindo diferenças entre desenvolvimento, teste e produção.
Um container não é uma máquina virtual completa. Ele compartilha o kernel do sistema operacional do host e isola processos, rede, filesystem e outros recursos por mecanismos do próprio sistema operacional. Essa arquitetura reduz overhead e acelera inicialização, mas também cria responsabilidades específicas de segurança, persistência, observabilidade, rede e operação que precisam ser entendidas antes de levar Docker para ambientes corporativos ou críticos.
Este artigo apresenta o Docker do ponto de vista de arquitetura e infraestrutura: como imagens e containers se relacionam, como redes e volumes funcionam, quais riscos precisam ser controlados, quando a tecnologia faz sentido e quais evidências devem existir para uma implantação confiável.
Docker, containers e virtualização
Em planejamento de capacidade, a densidade maior de containers exige atenção ao compartilhamento de CPU, memória, cache, I/O e interfaces de rede. A soma das reservas não deve consumir toda a capacidade do host, porque falhas, picos e processos de manutenção precisam de margem. Overcommit pode ser aceitável em workloads previsíveis, mas precisa ser acompanhado por métricas e limites claros para evitar que uma aplicação cause degradação generalizada.
A escolha entre container e máquina virtual também envolve governança. VMs oferecem uma fronteira de sistema operacional mais forte e podem acomodar aplicações legadas sem alteração; containers favorecem padronização e automação quando a aplicação foi preparada para esse modelo. Em muitos ambientes, a arquitetura mais robusta combina ambos: hosts virtualizados fornecem isolamento e mobilidade de infraestrutura, enquanto Docker organiza serviços dentro dessas VMs.
A conteinerização é uma forma de virtualização em nível de sistema operacional. Em um host Linux, processos de containers utilizam o mesmo kernel, mas operam em namespaces e grupos de controle que limitam visibilidade e consumo de recursos. Isso é diferente de um hypervisor, que apresenta hardware virtualizado para sistemas operacionais convidados independentes.
Na prática, uma máquina virtual normalmente carrega seu próprio kernel, serviços de sistema e conjunto completo de bibliotecas. Um container carrega apenas a aplicação e o que ela precisa no espaço de usuário. Essa diferença explica por que containers tendem a ter menor footprint, inicialização mais rápida e maior densidade por host.
Isso não significa que containers substituam máquinas virtuais. As duas tecnologias frequentemente coexistem. É comum executar Docker dentro de VMs para combinar isolamento de infraestrutura, mobilidade entre hosts e padronização da camada de aplicação. A decisão depende do nível de isolamento exigido, modelo operacional, suporte, licenciamento, dependências de kernel e desenho de alta disponibilidade.
O isolamento de container também não deve ser confundido com uma fronteira de segurança equivalente à de hardware dedicado. Vulnerabilidades no runtime, no kernel ou em configurações privilegiadas podem ampliar o impacto de uma falha. Por isso, a arquitetura deve combinar hardening do host, princípio de menor privilégio, atualização contínua e segmentação de rede.
Imagens, containers e registries
A imagem é o artefato imutável que descreve o filesystem e os metadados necessários para criar containers. Ela é construída em camadas, permitindo reutilização de componentes entre versões. Um container é uma instância executável dessa imagem, acrescida de uma camada gravável temporária e das configurações definidas no momento da execução.
Essa separação entre imagem e instância é central para a operação. A aplicação deve ser reconstruída em nova imagem quando código ou dependências mudam, em vez de receber alterações manuais dentro de containers em produção. Essa disciplina reduz configuration drift e melhora rastreabilidade entre versão, teste e implantação.
Registries armazenam e distribuem imagens. Docker Hub é um exemplo público, mas ambientes corporativos podem utilizar registries privados ou serviços equivalentes em nuvem. O registry passa a integrar a cadeia de suprimentos de software: permissões, assinatura, origem das imagens, retenção, vulnerabilidades e disponibilidade tornam-se requisitos de infraestrutura.
Tags facilitam identificação humana, porém uma tag pode apontar para conteúdos diferentes ao longo do tempo. Em ambientes controlados, digests e políticas de versionamento ajudam a fixar exatamente o artefato aprovado. A organização também precisa definir quem pode publicar imagens, quais bases são permitidas e como imagens antigas ou vulneráveis serão retiradas de circulação.
Dockerfile e construção de imagens
Builds reproduzíveis também dependem de controlar versões de pacotes e dependências. Usar referências genéricas como “latest” pode fazer o mesmo Dockerfile gerar imagens diferentes em datas distintas. Em pipelines controlados, versões, digests e lockfiles reduzem variação e facilitam investigação quando uma atualização introduz regressão. A estratégia precisa equilibrar reprodutibilidade com necessidade de incorporar correções de segurança.
Outro ponto é a geração de SBOM e o inventário de componentes. Conhecer bibliotecas e pacotes presentes na imagem acelera análise quando uma vulnerabilidade relevante é divulgada. Sem esse inventário, equipes precisam descobrir manualmente quais aplicações utilizam determinado componente, aumentando tempo de resposta e risco de deixar instâncias vulneráveis em produção.
O Dockerfile descreve etapas de construção de uma imagem. Ele pode definir imagem-base, pacotes, cópia de arquivos, variáveis, usuário de execução, portas documentadas e comando de inicialização. A qualidade desse arquivo influencia tamanho da imagem, superfície de ataque, tempo de build e previsibilidade do deployment.
Imagens menores não são um objetivo apenas estético. Menos pacotes significam menos componentes para atualizar e menor superfície potencial de vulnerabilidades. Multi-stage builds permitem usar ferramentas de compilação em etapas intermediárias sem carregá-las para a imagem final de execução.
A imagem-base precisa ser tratada como dependência. Uma aplicação pode continuar funcionando enquanto a base acumula CVEs ou deixa de receber suporte. Por isso, pipelines devem reconstruir imagens periodicamente mesmo quando o código da aplicação não mudou, permitindo incorporar correções do sistema operacional e bibliotecas.
Também é importante evitar secrets embutidos no Dockerfile, nas camadas ou no histórico da imagem. Credenciais, tokens, chaves privadas e certificados devem ser fornecidos por mecanismos próprios de secret management. Remover um segredo em uma camada posterior não garante que ele tenha desaparecido das camadas anteriores.
Redes Docker e integração com a infraestrutura
A rede dos containers precisa coexistir com endereçamento, VLANs, firewalls, DNS, MTU e rotas da infraestrutura corporativa. Projetar essa interface reduz conflitos de sub-rede, exposições indevidas e falhas de comunicação difíceis de diagnosticar.
Containers precisam se comunicar com outros containers, hosts, bancos de dados, serviços externos e usuários. Docker oferece diferentes drivers de rede, sendo bridge um dos modelos mais comuns em um único host. A rede cria interfaces virtuais, endereçamento e regras que permitem conectividade entre containers e com o host.
Publicar uma porta cria uma exposição entre a rede do host e o serviço dentro do container. Isso deve ser tratado como decisão de arquitetura, não como conveniência de desenvolvimento. Cada porta publicada aumenta a superfície acessível e precisa estar associada a uma necessidade, regra de firewall, autenticação e caminho de tráfego conhecido.
Em ambientes corporativos, Docker não elimina a necessidade de desenho de rede. DNS, balanceamento, NAT, proxies, segmentação, observabilidade, firewalls, certificados e políticas de acesso continuam existindo. A diferença é que endpoints podem surgir e desaparecer com maior frequência, exigindo automação e descoberta de serviços.
Quando aplicações conteinerizadas acessam bancos de dados ou sistemas críticos, a segmentação deve impedir comunicação lateral desnecessária. Redes distintas podem separar front-end, back-end, banco de dados e gerenciamento. O host também precisa ter interfaces e rotas coerentes com a arquitetura física e lógica da rede corporativa.
Problemas de MTU, NAT sobre NAT, regras de firewall, conflitos de sub-redes e DNS são causas frequentes de falhas em ambientes conteinerizados. O troubleshooting deve observar tanto a rede do container quanto a do host e a infraestrutura externa. Tratar Docker como uma “rede paralela” independente da rede corporativa costuma criar pontos cegos.
Volumes, persistência e dados
Persistência também precisa considerar consistência durante backup. Copiar arquivos de um volume enquanto uma aplicação grava dados pode produzir restauração inconsistente. Bancos de dados e serviços stateful normalmente exigem mecanismos próprios de snapshot, quiesce, dump ou replicação. O plano de backup deve declarar se a recuperação ocorre por restauração do volume inteiro, reconstrução da aplicação ou combinação das duas estratégias.
Em ambientes com múltiplos hosts, volumes locais podem criar dependência física indesejada. Se o serviço for reiniciado em outro servidor, os dados precisam acompanhá-lo ou estar disponíveis por storage compartilhado. Essa decisão influencia HA, manutenção e recuperação de desastre. Por isso, localização e ownership dos dados devem ser explícitos no desenho, incluindo permissões, criptografia, retenção e capacidade de expansão.
A camada gravável de um container é efêmera e não deve ser tratada como armazenamento persistente de dados importantes. Se o container for removido, alterações que não estejam em volumes ou armazenamento externo podem ser perdidas. Esse comportamento é adequado para aplicações stateless, mas exige desenho explícito para bancos de dados, uploads, logs e arquivos gerados.
Volumes fornecem persistência gerenciada pelo Docker e podem permanecer mesmo quando containers são recriados. Bind mounts, por outro lado, conectam caminhos específicos do host ao container. A escolha afeta portabilidade, permissões, backup, segurança e operação.
Persistência precisa ser planejada junto com backup e recuperação. Ter dados em volume não significa possuir backup. É necessário definir RPO, RTO, política de snapshots, consistência da aplicação e restauração testada. Bancos de dados conteinerizados exigem os mesmos cuidados de qualquer banco: integridade, flush, replicação, backup consistente e capacidade de recuperação.
O storage também influencia desempenho. Latência, IOPS, throughput, filesystem e driver de armazenamento podem se tornar gargalos. Em ambientes de produção, métricas do host e do volume precisam ser correlacionadas com métricas da aplicação para diferenciar problema de código de saturação da infraestrutura.
Docker Compose e aplicações com múltiplos serviços
Docker Compose permite declarar uma aplicação composta por múltiplos serviços, redes, volumes e variáveis em arquivo estruturado. É particularmente útil para ambientes de desenvolvimento, laboratórios, testes integrados e implantações de menor complexidade.
O arquivo Compose cria uma descrição repetível da aplicação. Em vez de executar uma sequência manual de comandos, a equipe passa a controlar versões de serviços, dependências, redes e volumes como configuração. Isso melhora reprodutibilidade e facilita revisão.
Compose não deve ser confundido com uma plataforma completa de orquestração. Quando existem múltiplos hosts, requisitos sofisticados de scheduling, autoscaling, políticas, service mesh ou recuperação automática distribuída, outras plataformas podem ser necessárias. Kubernetes é um exemplo, mas sua adoção acrescenta uma camada operacional substancial e não deve ser feita apenas porque a aplicação usa containers.
A maturidade operacional deve orientar a escolha. Muitas aplicações funcionam adequadamente em poucos hosts com Compose, monitoramento e procedimentos claros. Introduzir orquestração complexa sem escala ou necessidade correspondentes pode aumentar risco, custo e dependência de especialistas.
Segurança de containers
A superfície de ataque inclui não apenas containers em execução, mas também registry, pipeline, runners de CI, credenciais de automação e estações que constroem imagens. Uma imagem legítima comprometida na origem pode ser distribuída para muitos ambientes sem disparar controles tradicionais de perímetro. Por isso, segregação de funções, revisão de mudanças, scanning, assinatura e trilha de auditoria precisam fazer parte da cadeia de build.
Outra preocupação é a administração do daemon. Usuários ou processos capazes de controlar o Docker Engine podem obter acesso amplo ao host por meio de mounts privilegiados, devices ou criação de containers com permissões elevadas. O acesso ao socket precisa ser restrito e monitorado. Ambientes que exigem menor privilégio podem avaliar rootless mode ou arquiteturas que reduzam dependência de privilégios administrativos permanentes.
A segurança começa pelo host. Kernel, Docker Engine, plugins, sistema operacional e mecanismos de acesso administrativo precisam ser atualizados e protegidos. A exposição do socket Docker, por exemplo, merece controle rigoroso porque acesso privilegiado ao daemon pode permitir controle amplo do host.
Containers devem executar com o menor conjunto de privilégios possível. Rodar processos como usuário não root, remover capabilities desnecessárias, evitar modo privileged, limitar acesso a devices e usar filesystem somente leitura quando aplicável reduzem a superfície de ataque.
Imagens precisam ser inspecionadas quanto a vulnerabilidades e origem. O fato de uma imagem estar disponível publicamente não significa que seja apropriada para produção. Bases oficiais, políticas de aprovação, scans automatizados e inventário de componentes ajudam a administrar risco da cadeia de suprimentos.
Secrets não devem ser incluídos em imagens, variáveis expostas em logs ou arquivos versionados. Também é importante proteger registries, pipelines e credenciais de automação. Comprometer a cadeia de build pode ser tão grave quanto comprometer um host de produção, porque uma imagem maliciosa pode ser distribuída de forma legítima para muitos ambientes.
Limites de CPU e memória reduzem o risco de um container consumir todos os recursos do host. Sem limites, uma falha ou carga anormal pode afetar aplicações vizinhas. Quotas, reservations e monitoramento devem refletir criticidade e comportamento esperado de cada serviço.
Observabilidade, logs e operação
Alertas precisam distinguir sintoma de causa. Reinicializações frequentes podem indicar crash da aplicação, falta de memória, health check inadequado ou dependência externa indisponível. Correlacionar eventos do Docker com logs do kernel, métricas do host, storage e rede evita respostas superficiais que apenas reiniciam containers sem tratar o problema.
Também é útil estabelecer baseline após implantação. Consumo típico de CPU, memória, latência de disco, tráfego e tempo de resposta servem de referência para mudanças futuras. Quando uma nova versão aumenta recursos ou altera padrão de rede, essa comparação ajuda a identificar regressões antes que a capacidade do host seja comprometida.
Containers são efêmeros, portanto observabilidade não pode depender de inspeção manual da instância atual. Logs, métricas e eventos precisam ser enviados para plataformas ou destinos persistentes. Quando um container é recriado, o histórico operacional deve permanecer disponível.
Métricas relevantes incluem CPU, memória, I/O, rede, reinicializações, saúde da aplicação e consumo de filesystem. Para serviços críticos, essas métricas devem ser correlacionadas com indicadores de negócio e dependências externas. Um container “running” não significa necessariamente uma aplicação saudável.
Health checks ajudam a distinguir processo ativo de serviço funcional. Eles podem verificar endpoints, comandos ou dependências essenciais e servir de base para automação de recuperação. Porém, health checks mal definidos geram falsos positivos ou loops de reinicialização, por isso precisam representar a condição real de serviço.
Logs também exigem política de retenção. Containers com logging local sem rotação podem consumir todo o disco do host. A arquitetura deve definir driver de log, retenção, centralização, proteção contra perda e acesso por equipes de operação e segurança.
Docker na arquitetura de infraestrutura
O domínio de falha deve ser desenhado conscientemente. Concentrar dezenas de serviços em um único servidor reduz quantidade de hardware, mas aumenta o impacto de manutenção, pane de energia, kernel panic ou falha de storage. Distribuir workloads entre hosts, separar serviços críticos e prever capacidade para absorver a perda de um nó são decisões de engenharia que precisam existir antes de discutir autoscaling ou orquestração.
Dependências externas também precisam aparecer no diagrama de arquitetura. DNS, NTP, autenticação, banco de dados, proxy, storage, registry e sistemas de observabilidade podem ser mais críticos para a aplicação do que o próprio runtime. Um container pode reiniciar automaticamente e continuar indisponível porque um desses serviços está inacessível. Mapear essas relações melhora análise de risco e definição de testes de recuperação.
Containers não eliminam os requisitos da infraestrutura que os sustenta. Capacidade de hosts, storage, rede, redundância, backup e monitoramento precisam ser dimensionados como uma arquitetura única, principalmente quando aplicações críticas são concentradas em poucos servidores.
A adoção de Docker precisa considerar capacidade dos hosts, disponibilidade, rede, storage e ciclo de vida. CPU e memória não devem ser calculadas apenas pela soma nominal das aplicações; picos, overhead, margem de crescimento e comportamento durante falhas precisam ser considerados.
Concentrar muitos serviços em um único host aumenta eficiência, mas também amplia o domínio de falha. Se esse host parar, todos os containers ali executados ficam indisponíveis. Alta disponibilidade exige múltiplos hosts, balanceamento, dados replicados ou externos e procedimento de reconstrução das aplicações.
O desenho precisa distinguir estado de configuração. Imagens, arquivos Compose, manifests e parâmetros devem estar versionados e recuperáveis. O objetivo é permitir reconstruir o ambiente em novo host sem depender de alterações manuais invisíveis.
Em Data Centers e CPDs, Docker passa a depender da mesma infraestrutura crítica que suporta VMs e aplicações convencionais: energia, climatização, rede, storage, backup e monitoramento. A conteinerização melhora portabilidade da aplicação, mas não elimina os requisitos físicos e lógicos da plataforma onde ela roda.
Implantação, atualização e rollback
Gestão de mudanças deve registrar não apenas a imagem nova, mas também alterações de configuração, secrets, volumes, regras de rede e dependências externas. Muitas falhas atribuídas ao container são causadas por mudanças simultâneas fora dele. Separar escopo e manter evidência do antes e depois melhora diagnóstico e torna rollback mais confiável.
Em produção, a estratégia de atualização também precisa considerar capacidade temporária. Rolling update e blue-green podem exigir recursos adicionais enquanto versões antiga e nova coexistem. Se o cluster ou host opera próximo do limite, a própria atualização pode provocar saturação. Planejamento deve reservar margem para manutenção, testes e falha de uma instância durante a transição.
Uma implantação controlada começa com imagem identificada, testes concluídos e configuração versionada. O mesmo artefato deve percorrer os ambientes sempre que possível. Reconstruir uma imagem diferente para produção rompe a evidência de que aquilo que foi testado é aquilo que será executado.
Atualizações precisam prever rollback. Se uma nova versão falhar, a equipe deve saber retornar à imagem anterior e restaurar compatibilidade de banco de dados, configurações e integrações. Nem todo rollback é simples: migrations destrutivas ou mudanças de schema podem impedir retorno rápido.
Blue-green, rolling updates e canary são estratégias possíveis, mas dependem da arquitetura e do orquestrador. Em ambientes menores, parar e recriar containers durante janela controlada pode ser suficiente. O importante é alinhar método à criticidade e à tolerância de indisponibilidade.
A documentação operacional deve incluir versão das imagens, origem, portas, volumes, variáveis, dependências, health checks, procedimento de backup, restauração, atualização e rollback. Sem essa baseline, a facilidade inicial do Docker pode se transformar em ambiente difícil de manter.
Quando Docker faz sentido
Outro critério é a previsibilidade da operação. Se a equipe já possui monitoramento, pipelines, registry, backup e procedimentos de atualização maduros, Docker tende a simplificar o deployment. Quando esses elementos ainda não existem, a tecnologia pode deslocar complexidade para uma camada nova sem resolver governança, disponibilidade ou segurança. A avaliação precisa considerar capacidade da equipe de sustentar o ambiente durante incidentes e mudanças.
Também deve ser considerada a dependência de fornecedores e plataformas externas. Imagens-base, registries e serviços de CI podem se tornar componentes críticos. Estratégias de cache, espelhamento, retenção e contingência reduzem o risco de indisponibilidade externa impedir uma reconstrução urgente. O benefício de portabilidade só existe quando os artefatos necessários continuam acessíveis no momento da recuperação.
Docker é especialmente útil quando a aplicação precisa ser empacotada de forma consistente, possui dependências bem definidas e se beneficia de implantação repetível. Ambientes de desenvolvimento, CI/CD, microserviços, serviços internos, laboratórios e aplicações self-hosted são casos comuns.
A tecnologia também é útil para isolar versões conflitantes de bibliotecas e reduzir dependência do software instalado diretamente no host. Isso simplifica migrações e reconstruções, desde que os dados persistentes e integrações tenham sido corretamente externalizados.
Por outro lado, Docker pode acrescentar complexidade desnecessária a aplicações estáveis e simples que já possuem bom processo de deployment. Workloads que exigem acesso específico a hardware, licenciamento particular, forte isolamento por kernel ou suporte oficial restrito podem demandar outra abordagem.
A decisão deve comparar benefícios de portabilidade e automação com custos de operação, segurança, monitoramento, capacitação e suporte. Conteinerizar por moda, sem resolver um problema concreto de ciclo de vida, tende a criar mais uma camada para a equipe administrar.
Critérios de projeto e Design Review
Antes de levar uma aplicação conteinerizada para produção, arquitetura, segurança, persistência, backup, capacidade, observabilidade e rollback devem ser revisados em conjunto. O objetivo é verificar se o desenho é operável e recuperável, não apenas se o container inicia.
Uma implantação corporativa deve registrar requisitos de disponibilidade, capacidade, segurança, rede, persistência, backup e observabilidade. Para cada serviço, convém identificar imagem, versão, portas, volumes, dependências, recursos, health check, owner e criticidade.
O Design Review precisa verificar coerência entre aplicação e infraestrutura. Uma arquitetura pode estar correta do ponto de vista do Dockerfile e ainda falhar por storage insuficiente, MTU incompatível, ausência de backup, regras de firewall incorretas ou concentração excessiva de serviços em um único host.
A revisão também deve examinar cadeia de suprimentos: origem das imagens, atualização, scans, assinatura quando aplicável, secrets e pipelines. Quanto maior a automação, maior a importância de proteger os mecanismos que constroem e distribuem artefatos.
Critérios de aceite devem ser mensuráveis. Inicialização, comunicação entre serviços, persistência, recuperação, backup, restauração, uso de recursos, health checks, atualização e rollback podem ser testados antes da entrada em produção.
Operação e ciclo de vida
A desativação também faz parte do ciclo de vida. Imagens antigas, volumes órfãos, credenciais, registros de DNS e regras de firewall precisam ser removidos de forma controlada quando um serviço deixa de existir. Sem esse encerramento, ambientes Docker acumulam recursos abandonados que consomem espaço, confundem inventário e podem manter exposições desnecessárias.
Gestão de vulnerabilidades precisa distinguir imagem armazenada, imagem aprovada e instância em execução. Corrigir uma Dockerfile não atualiza automaticamente containers já implantados. A operação deve saber quais versões estão ativas, reconstruir imagens, validar mudanças e promover novas instâncias. Essa rastreabilidade evita que ambientes antigos permaneçam vulneráveis mesmo depois de a equipe considerar o problema “corrigido” no repositório.
Outro controle importante é testar disaster recovery sem depender do host original. O exercício deve reconstruir runtime, redes, volumes, secrets e configurações em ambiente limpo, restaurando dados dentro do RTO previsto. Essa prova identifica dependências manuais, artefatos ausentes e documentação incompleta. Quando a reconstrução depende de comandos não versionados ou conhecimento de uma única pessoa, a conteinerização ainda não atingiu maturidade operacional suficiente.
Docker não elimina manutenção; desloca parte dela para imagens, hosts e automação. O sistema operacional do host continua precisando de patching, e as imagens precisam ser reconstruídas à medida que dependências recebem atualizações de segurança.
Inventário é essencial. A equipe deve saber quais imagens estão em execução, em quais hosts, quais versões estão aprovadas e quais aplicações dependem delas. Registries e pipelines podem fornecer parte dessa rastreabilidade, mas precisam estar integrados ao processo de gestão de mudanças.
Capacidade deve ser acompanhada continuamente. Crescimento de logs, volumes, imagens não utilizadas e caches pode consumir storage de forma silenciosa. Políticas de limpeza precisam ser controladas para não remover artefatos necessários à recuperação.
Por fim, a organização deve testar reconstrução. A prova de que o ambiente é realmente reproduzível é conseguir instalar um novo host, obter os artefatos aprovados, recuperar dados e restabelecer a aplicação sem depender de conhecimento informal. Essa capacidade transforma Docker de ferramenta de conveniência em componente governável da infraestrutura.
Referências técnicas
[1] Docker. What is Docker?. Disponível em: https://docs.docker.com/get-started/docker-overview/.
[2] Docker. Volumes. Disponível em: https://docs.docker.com/engine/storage/volumes/.
[3] Docker. Networking overview. Disponível em: https://docs.docker.com/engine/network/.
[4] Docker. Docker security. Disponível em: https://docs.docker.com/engine/security/.
Perguntas frequentes
Não. Containers compartilham o kernel do host e isolam processos e recursos, enquanto máquinas virtuais executam sistemas operacionais convidados completos sobre um hypervisor.
Não necessariamente. Containers e máquinas virtuais frequentemente coexistem e atendem a níveis diferentes da arquitetura.
A camada gravável do container é efêmera. Dados persistentes devem utilizar volumes, bind mounts ou serviços externos de armazenamento.
Docker fornece mecanismos de isolamento, mas segurança depende de hardening do host, privilégios, imagens confiáveis, atualização, secrets, rede e monitoramento.
Compose descreve e executa aplicações com múltiplos serviços, mas não substitui plataformas distribuídas de orquestração para todos os cenários.
Quando a aplicação não se beneficia de portabilidade e automação, exige isolamento de kernel, hardware específico ou suporte incompatível com conteinerização, outra arquitetura pode ser mais adequada.
