O que é Docker e para que serve

"Na minha máquina funciona" é uma das frases mais antigas do desenvolvimento. No servidor, a versão do Node era outra, faltava uma biblioteca do sistema ou a variável de ambiente tinha outro nome. O Docker resolve isso mudando o que você entrega: em vez de só o código, você entrega o código junto com o ambiente em que ele roda.

O que é Docker?#

O Docker empacota a aplicação e tudo de que ela depende em um container, um ambiente isolado que não depende do que está instalado no host. Você pode rodar muitos containers ao mesmo tempo na mesma máquina, e cada um se comporta igual onde quer que rode.

A documentação oficial define o container como um processo isolado com todos os arquivos de que ele precisa para rodar. Não existe um segundo sistema operacional: os containers compartilham o kernel do host. Essa é a diferença central em relação a uma máquina virtual, explicada em container vs máquina virtual.

Quais são as peças do Docker?#

Cinco conceitos cobrem quase tudo:

• Imagem: um modelo somente leitura com as instruções para criar um container. Ela é feita de camadas, e cada camada representa um conjunto de mudanças no sistema de arquivos. Depois de criada, uma imagem não muda: para alterá-la você constrói outra.
• Container: uma instância executável de uma imagem. Você cria, inicia, para e remove containers. Por padrão, cada um fica isolado dos outros e do host.
• Dockerfile: o arquivo de texto com as instruções para construir a imagem.
• Registry: o lugar onde as imagens ficam guardadas. O Docker Hub é o registry público que o Docker consulta por padrão, e você também pode rodar um registry privado.
• Docker Engine: o programa que faz o trabalho, num modelo cliente-servidor. O cliente (docker) manda comandos como docker run para o daemon (dockerd), que cria e gerencia imagens, containers, redes e volumes. Os dois conversam por uma API REST.

Em Linux você instala o Docker Engine direto no sistema. No Windows e no macOS, o caminho é o Docker Desktop, que reúne o daemon, o cliente e o Compose numa aplicação só.

Como rodar um container em um minuto?#

Com o Docker instalado, o primeiro teste é este:

docker run --rm hello-world

O Docker procura a imagem hello-world localmente, não encontra, baixa do Docker Hub, cria um container, imprime uma mensagem e sai. A opção --rm remove o container ao terminar. Para ver os containers em execução, use docker ps; docker ps -a mostra também os parados.

Como colocar uma aplicação em um container?#

Você descreve a imagem em um Dockerfile na raiz do projeto. O exemplo abaixo empacota uma aplicação Node.js que escuta na porta 3000:

FROM node:lts-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "index.js"]

Instrução por instrução:

• FROM define a imagem base. Todo Dockerfile começa por ela. Se você não informa a tag, o Docker assume latest, então informe sempre uma. lts-slim acompanha a versão LTS ativa do Node.js; para builds totalmente reproduzíveis, fixe também a versão maior.
• WORKDIR define a pasta de trabalho das instruções seguintes e a cria se não existir.
• COPY e RUN criam camadas. Copiar o package*.json e instalar as dependências antes de copiar o resto do código faz o Docker reaproveitar essa camada nos builds seguintes, desde que as dependências não mudem.
• EXPOSE só documenta a porta. Não publica nada.
• CMD é o comando padrão do container. Prefira a forma exec, em lista JSON com aspas duplas, que não passa por um shell.

Crie também um arquivo .dockerignore com node_modules e .env, para não copiar dependências locais nem segredos para dentro da imagem. Depois construa e rode:

docker build -t meu-app .
docker run --rm -p 3000:3000 meu-app

O -p 3000:3000 publica a porta 3000 do container na porta 3000 da sua máquina. Abra http://localhost:3000 e a aplicação deve responder. Se não responder, confira se o código escuta em 0.0.0.0 e não só em 127.0.0.1: dentro do container, 127.0.0.1 é o próprio container. Para o passo a passo completo, veja como containerizar uma aplicação.

O que acontece com os dados de um container?#

As mudanças que um container faz nos próprios arquivos são apagadas quando ele é removido. Para guardar dados, como os arquivos de um banco, use um volume, que existe independente do ciclo de vida de qualquer container:

docker volume create dados
docker run -d -v dados:/var/lib/data minha-imagem

A sintaxe é -v nome-do-volume:caminho-no-container. Um volume pode ser compartilhado por vários containers e só é removido se você pedir, com docker volume rm.

Para que o Docker serve na prática?#

• Ambiente igual em todo lugar: o container que passou no seu computador é o mesmo que roda no servidor.
• Onboarding rápido: quem entra no time sobe a aplicação e o banco com um comando, sem instalar nada à mão. Para vários containers juntos, o Docker Compose descreve tudo em um arquivo.
• Isolamento: duas aplicações que precisam de versões diferentes da mesma linguagem convivem na mesma máquina sem conflito.
• Entrega previsível: a imagem é um artefato versionado. Para voltar à versão anterior, basta subir a imagem anterior.

Quando o Docker não é necessário?#

O Docker acrescenta uma camada que você precisa aprender e manter: Dockerfile, imagens, volumes, redes e atualização da imagem base. Se você hospeda um bot ou uma API em uma plataforma que recebe o código e entrega o ambiente de execução pronto, não precisa escrever nada disso. Pense no Docker quando precisar controlar o sistema operacional, instalar pacotes que o ambiente padrão não traz ou repetir exatamente o mesmo ambiente em vários servidores.

Vale lembrar duas coisas. Um container não é uma fronteira de segurança tão forte quanto uma VM, porque compartilha o kernel. E o Docker Desktop tem licença própria: é gratuito para uso pessoal, educação e projetos open source não comerciais, mas empresas acima de um certo porte, medido em funcionários ou receita anual, precisam de assinatura paga. Confira os limites atuais na página de licença do Docker Desktop.

Como fazer isso na Square Cloud#

A Square Cloud é um exemplo de plataforma que entrega o ambiente pronto. As aplicações rodam em containers isolados num datacenter Tier 3 em Nova York, mas você não envia Dockerfile nem imagem própria: escolhe um dos diversos runtimes, como Node.js, Python e Go, ou o de sites estáticos, e envia o código. Veja os runtimes disponíveis hoje em Runtimes.

O deploy pode ser por upload de ZIP no painel, pela CLI, pelo GitHub (um push faz o deploy, via GitHub Action oficial ou webhook) ou pela extensão do VS Code. O arquivo de configuração squarecloud.app é opcional: o painel o gera no deploy, com runtime, memória e arquivo principal, ou você mesmo o escreve na raiz do projeto.

Os containers ficam sempre ligados, sem cold start, com reinício automático (ligado por padrão no deploy pelo painel) quando o processo encerra com erro. A escala vertical fica com você: você muda a RAM de cada aplicação nas configurações ou pela API. Veja o que está incluído em recursos da Square Cloud.