Programação · DevOps · contentores

O que é o Docker?

«Funciona na minha máquina» é uma das piadas mais antigas do software – e o problema que o Docker foi concebido para eliminar. O Docker empacota uma aplicação com tudo de que precisa para correr, para que se comporte da mesma forma num portátil, na máquina de um colega e num servidor de produção. Este guia explica o que é o Docker, em que os contentores diferem das máquinas virtuais, os conceitos que importam e onde se situa o Docker ao lado de ferramentas como o Kubernetes.

A definição curta

O Docker é uma plataforma para construir, partilhar e executar aplicações em contentores. Um contentor agrupa o seu código e as suas dependências – bibliotecas, runtime, configuração – numa unidade isolada e portátil. Como o contentor transporta o seu próprio ambiente, corre da mesma forma em todo o lado onde o Docker esteja instalado, eliminando a categoria de bugs «funciona aqui mas não ali».

Contentores vs máquinas virtuais

Ambos isolam o software, mas em níveis diferentes. Uma máquina virtual emula um computador inteiro, com o seu próprio sistema operativo completo, sobre um hipervisor – poderosa, mas pesada: cada VM pesa gigabytes e arranca lentamente. Um contentor partilha o núcleo (kernel) do sistema operativo da máquina anfitriã e empacota apenas a app e as suas dependências. O resultado é muito mais leve: os contentores pesam tipicamente megabytes, arrancam em segundos, e pode-se correr muitos mais no mesmo hardware.

O compromisso é o isolamento. As VM oferecem uma separação mais forte porque cada uma tem o seu próprio OS; os contentores são mais eficientes mas partilham o kernel, pelo que o isolamento é bom em vez de absoluto. Muitos sistemas reais usam ambos – contentores a correr em VM na cloud.

Os conceitos-chave

• Imagem – um modelo só de leitura que define o que há num contentor: as camadas de OS, a sua app e as suas dependências. Constrói-se uma imagem uma vez e lançam-se vários contentores a partir dela.
• Contentor – uma instância em execução de uma imagem. É o processo vivo e isolado; pode-se iniciar, parar e eliminar sem tocar na imagem.
• Dockerfile – uma receita em texto simples que lista os passos para construir uma imagem (partir de uma base, copiar o código, instalar as dependências, definir o comando de arranque). Torna as builds reproduzíveis.
• Registo (registry) – um repositório de imagens. O Docker Hub é o registo público mais conhecido; as equipas também exploram registos privados. Faz-se push das imagens para as partilhar e pull para as executar.
• Volume – um armazenamento que vive fora do ciclo de vida do contentor, para que os dados sobrevivam à substituição de um contentor. Os contentores são descartáveis; os volumes conservam o que tem de persistir.

Como é um fluxo de trabalho típico

Escreve um Dockerfile, constrói-o numa imagem, e executa essa imagem como contentor. Em local, talvez lance um único contentor; em produção, faz push da imagem para um registo e executa-a em servidores. Como a imagem é o mesmo artefacto em todo o lado, a app que os seus colegas e os seus servidores executam é, byte a byte, a que testou – é esse todo o objetivo.

Por que o Docker importa

Tornou fáceis os ambientes coerentes, e isso desbloqueou muita coisa: deployments de serviço para serviço fiáveis, um onboarding rápido (um comando em vez de uma página de passos de configuração) e a base das pipelines de CI/CD e dos microsserviços. Os contentores são hoje a unidade de deployment por defeito na infraestrutura moderna, o que explica por que todo o ecossistema – registos, orquestração, runtimes cloud – fala «contentor».

Docker vs Kubernetes

São muitas vezes citados juntos, mas resolvem problemas diferentes. O Docker constrói e executa contentores individuais. O Kubernetes é um orquestrador: executa e coordena muitos contentores em muitas máquinas – planeia-os, reinicia os que falham, sobe e desce a escala, e liga-os em rede. Em resumo, o Docker empacota e executa um contentor; o Kubernetes gere uma frota. Pode-se usar o Docker sem o Kubernetes; o Kubernetes executa contentores construídos segundo o mesmo padrão que o Docker popularizou. Veja o nosso guia completo sobre Kubernetes – e, em qualquer caso, os seus contentores precisam de um lugar onde correr, geralmente um VPS.

Os compromissos honestos

O Docker não é sem custo. Os contentores partilham o kernel anfitrião: não é, portanto, uma fronteira de segurança rígida como o é uma VM – as cargas sensíveis podem querer um isolamento ao nível de VM. As aplicações com estado (bases de dados, tudo o que tem dados locais importantes) exigem uma conceção cuidada de volumes e backups, dado que os contentores são pensados para ser descartáveis. E há uma curva de aprendizagem: imagens, rede e volumes demoram a assimilar. Para a maioria das equipas, a coerência e a rapidez compensam, ainda assim.

FAQ

O Docker é uma máquina virtual? Não. Uma VM emula um computador inteiro com o seu próprio sistema operativo; um contentor Docker partilha o kernel do OS anfitrião e empacota apenas a app e as suas dependências, o que o torna muito mais leve e rápido a arrancar.

O Docker é gratuito? O Docker Engine, a tecnologia de base, é open source e gratuito. O Docker propõe também ofertas pagas para a sua aplicação Desktop e os seus serviços nas grandes organizações, mas pode-se construir e executar contentores sem pagar.

É preciso Docker para usar o Kubernetes? Não o Docker, o produto em particular, mas são precisos contentores. O Kubernetes orquestra contentores construídos segundo padrões abertos que o Docker ajudou a estabelecer, por isso as competências transferem-se diretamente.

O que é um Dockerfile? Um ficheiro em texto simples com os passos para construir uma imagem – que base usar, que código copiar, que dependências instalar, e o comando a executar. Torna as builds de imagem reproduzíveis e legíveis.

Os contentores são a unidade sobre a qual assentam os deployments; as apps que contêm expõem muitas vezes uma API e escrevem-se num IDE. Explore outras explicações claras no nosso índice de guias.

Perguntas frequentes