Você já pensou em como seria entregar seu projeto Django sempre rodando igual, não importando se você está no seu computador, no notebook do colega ou em uma nuvem? Essa ideia é possível com Docker, uma ferramenta capaz de encapsular todas sua aplicação em um container. Mas, afinal, o que significa colocar um aplicativo Django dentro de um container? Como juntar banco de dados, arquivos estáticos, servidores de produção e ainda garantir que tudo está seguro?
Por que pensar em containers e Docker?
Muitas pessoas começam a estudar Django e logo esbarram no seguinte problema: "No meu computador funciona, mas não funciona na máquina do colega." É aquele famoso drama de desenvolvedor. Você sobe o Django, configura o PostgreSQL e, de repente, no ambiente do cliente, nada mais dá certo.
É aqui que o Docker brilha. Ele empacota todo o ambiente necessário para rodar seu app Django, dependências, configurações, variáveis de ambiente, tudo, dentro de containers isolados. Assim, o que roda em um lugar, roda igualzinho em outro.
O isolamento proporcionado pelos containers aumenta a segurança, facilita manter vários apps diferentes lado a lado e ainda reforça a escalabilidade. Isso só ganha ainda mais valor quando colocado em prática junto a frameworks como Django.
Entendendo a relação entre Docker e Django
Antes de mais nada, é bom saber: Docker não roda seu código diretamente. Ele cria uma espécie de caixa mágica, chamada container, que contém tudo o que o Django precisa para funcionar. O código, as bibliotecas, o banco de dados, as configurações do sistema... tudo fica ali dentro. Você pode até criar um exército de containers, cada um para uma parte diferente do seu sistema.
Começando do zero: o que você precisa saber
Você precisará aprender para que serve e como usar os dois principais arquivos para se dockerizar um app Django o Dockerfile e o docker-compose.yml.
- O Dockerfile define como um container será construído (qual Python usar, como instalar as dependências, rodar migrações, etc).
- O docker-compose.yml orquestra vários containers (banco, Django, servidor estático, entre outros) e define como eles se comunicam.
Preparando seu projeto Django para ser containerizado
Primeiro, tenha seu projeto Django rodando normalmente em sua máquina. O ideal é já usar o PostgreSQL (que é o banco de dados muito comum em deploys na nuvem) e um servidor de aplicação como o Gunicorn para simular cenários de produção.
Vamos assumir que você tenha o seguinte cenário:
- Seu projeto em pasta meuprojeto/
- Um arquivo requirements.txt com as dependências do Django, Gunicorn e psycopg2
- O arquivo manage.py na raiz
Seu projeto deve ficar com a seguinte estrutura de pastas.
Construindo o Dockerfile: passo a passo
O Dockerfile é quem diz "Docker, pega o Python, instala as libs e configura tudo do jeito certo".
- Escolha a imagem base Normalmente, para projetos Django, usa-se o Python oficial:
FROM python:3.12-slim
O -slim indica uma imagem enxuta, menos coisa para baixar e rodar.
- Defina o diretório de trabalho Assim, tudo que for rodado acontecerá dentro do /app:
WORKDIR /app
- Copie as dependências e instale-as
COPY requirements.txt
RUN pip install --no-cache-dir -r requirements.txt
O --no-cache-dir evita ocupar espaço à toa.
- Copie o código do projeto
COPY . ./
- Exponha o projeto na porta 8000
EXPOSE 8000
- Rode o servidor
CMD ["python3", "manage.py", "runserver"]
Arquivo completo
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt
RUN pip install --no-cache-dir -r requirements.txt
COPY . ./
EXPOSE 8000
CMD ["python3", "manage.py", "runserver"]
Esse seria o Dockerfile base para projetos Django. Dá para melhorar com variáveis de ambiente e outros ajustes.
Buildando o Dockerfile
Build o container.
docker build -t="django" .
Inicie o container.
docker run django
Para listar os container em execução.
docker ps
Docker compose: Orquestrando containers.
A maioria dos projetos Django não vive sozinho: precisa de um banco de dados, como o MySQl ou outros serviços. E ninguém quer configurar isso tudo na mão.
Com o Docker Compose, a gente descreve todos os containers que vão trabalhar juntos. Por exemplo: Django, MySQl, e até servidores de arquivos estáticos.
- Primeiro instale o docker-compose.
DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}
mkdir -p $DOCKER_CONFIG/cli-plugins
curl -SL https://github.com/docker/compose/releases/download/v2.7.0/docker-compose-linux-x86_64 -o $DOCKER_CONFIG/cli-plugins/docker-compose
chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose
- Crie o arquivo docker-compose.yml
version: '3.8'
services:
db:
image: mysql:8.0
command: >
sh -c "mysqld --default_authentication_plugin=mysql_native_password &
sleep 10 &&
mysql -uroot -1234 -e \"GRANT ALL PRIVILEGES ON *.* TO 'caio'@'%' IDENTIFIED BY '1234'; FLUSH PRIVILEGES;\" &&
mysqladmin shutdown"
restart: always
environment:
MYSQL_ROOT_PASSWORD: rootpassword
MYSQL_DATABASE: mydatabase
MYSQL_USER: myuser
MYSQL_PASSWORD: mypassword
ports:
- "3301:3306"
volumes:
- db_data:/var/lib/mysql
web:
build: .
command: python manage.py runserver 0.0.0.0:8000
volumes:
- .:/app
ports:
- "8000:8000"
depends_on:
- db
environment:
DB_HOST: db
DB_NAME: mydatabase
DB_USER: myuser
DB_PASSWORD: mypassword
volumes:
db_data:
Montando pipelines automáticos: CI/CD com Docker
Fazer build de containers manualmente, instalar dependências, rodar testes, aplicar migrações... depois de fazer dez vezes, você começa a buscar automação. É aí que entram pipelines de CI/CD.
- CI (Integração Contínua): Testa o código a cada commit.
- CD (Deploy Contínuo): Entrega o que passou nos testes direto para produção (ou staging).
Esses pipelines puxam o código, constroem a imagem Docker, executam os testes (pytest, Django test runner etc), aplicam migrações e, se tudo der certo, publicam na infraestrutura do cliente, ou na nuvem.
Usar Docker nesse contexto padroniza e acelera tudo.
Não raro, times inteiros reduzem erros só por padronizar builds e deploys com Docker, algo que pode ser tema de um próximo artigo.
Ou também pode ser encontrado em nosso curso, Python Full.
Problemas mais comuns: dúvidas e possíveis tropeços
Errar faz parte do processo. Algumas dores você vai sentir:
- Permissões erradas nos arquivos gerados dentro do container (resolve-se ajustando UID e GID no Dockerfile ou docker-compose).
- Migrar banco com dados sensíveis: atenção para não perder persistência ao criar containers novos.
- Nomes de variáveis de ambiente diferentes em produção e local podem causar falhas difíceis de rastrear.
- Builds lentos quando tudo é copiado a cada alteração, use .dockerignore igual ao .gitignore!
Melhores práticas para um deploy saudável
- Use .dockerignore para evitar copiar arquivos desnecessários para a imagem.
- Separe ambientes de dev, staging e produção em arquivos diferentes do docker-compose.
- Sempre rode testes automatizados no container antes do deploy.
- Mantenha as variáveis de ambiente completas, mas nunca exponha secrets publicamente.
- Faça versionamento das imagens Docker para facilitar rollback.
- Atualize suas imagens base com frequência (por segurança).
Perguntas frequentes sobre Docker e Django
O que é o Docker e para que serve?
Docker é uma ferramenta que permite empacotar aplicações e suas dependências em containers, criando ambientes isolados e consistentes. Ele faz com que seu app rode igualzinho em qualquer lugar, seja no seu computador, em um servidor ou na nuvem, sem aquelas dores de cabeça com diferenças de configuração. Os containers ajudam a manter segurança, facilitam a colaboração em equipe e permitem implantar sistemas complexos mais rapidamente.
Como dockerizar um projeto Django?
Para dockerizar um projeto Django, você precisa criar um Dockerfile descrevendo o passo a passo para instalar Python, dependências e rodar o servidor (normalmente com Gunicorn). Depois, com um docker-compose.yml, você gerencia múltiplos containers (Django, banco de dados, proxy reverso, etc.), sendo possível definir variáveis de ambiente e volumes compartilhados para arquivos estáticos. Seguindo essa receita, você consegue reproduzir qualquer ambiente e simplificar muito o deploy.
Quais são os benefícios de usar Docker?
Docker oferece ambiente padronizado e fácil de reproduzir, reduzindo falhas de "funciona na minha máquina". Isola aplicações, protegendo uma da outra, facilita escalar projetos (subindo mais containers conforme o necessário), e simplifica testes e deploys (já que tudo pode ser automatizado em pipelines de CI/CD). Também traz uma camada extra de segurança, já que aplicações diferentes rodam em ambientes separados.
