Neste post, vou mostrar como criar um container Docker para um projeto Django já existente. Como exemplo, resolvi buscar por uma issue aberta no github que estivesse pedindo para ser dockerizada. Criei um PR para a Issue e usei como exemplo aqui.
Por quê você vai querer dockerizar uma aplicação web django que já existe? Bom, existem muitas razões, se você acha que não tem uma, faça pela diversão!
Eu decidi usar o docker em uma das minhas aplicações porque ela estava ficando muito difícil de instalar. Muitos requisitos do sistema, vários bancos de dados, celery, rabbitmq e por aí vai. Sem dockerizar cada vez que uma nova pessoa entra no time é um inferno pra setar tudo porque levava tempo demais.
O mundo ideal é que o programador tenha em seu ambiente de desenvolvimento o mais próximo que puder do ambiente de produção. Se você usa SQLite na sua máquina mas Postgres no servidor pode ser que tenha problemas de dados que são simplesmente truncados localmente mas que vão levantar erros na base de produção. Só para ter ideia de um exemplo.
Se você não sabe o que é o docker, imagine que é um imenso virtualenv que no lugar de ter apenas pacotes python tem o sistema operacional “inteiro”. Isso consegue isolar seu app de tudo que está no seu SO, bancos de dados, workers, etc.
Mão na massa
Ok, falar é fácil, vamos codar um pouco.
Primeiro de tudo, instale o Docker. Fiz isso no Ubuntu e no Mac sem nenhum problema. Já no Windows Home não consegui fazer funcionar.
Para dizer ao docker que sua aplicação é um container você precisa criar um arquivo Dockerfile:
FROM python:3.6
ENV PYTHONUNBUFFERED 1
RUN mkdir /webapps
WORKDIR /webapps
# Installing OS Dependencies
RUN apt-get update && apt-get upgrade -y && apt-get install -y \
libsqlite3-dev
RUN pip install -U pip setuptools
COPY requirements.txt /webapps/
COPY requirements-opt.txt /webapps/
RUN pip install -r /webapps/requirements.txt
RUN pip install -r /webapps/requirements-opt.txt
ADD . /webapps/
# Django service
EXPOSE 8000Vamos lá, linha a linha:
Docker Images
FROM python:3.6
Aqui estamos usando uma imagem do docker hub. Isto, é um container pré-formatado do docker que permite que você monte sua máquina a partir daquela configuração inicial. Nesse caso, Python 3.6 é um container de um Ubuntu que tem o Python 3.6 instalado nele. Você pode procurar por containers no docker hub.
Environment Variables (Variáveis de ambiente)
Você pode criar todas as variáveis de ambiente que quiser com o ENV.
ENV PYTHONUNBUFFERED 1 # Here we can create all Environment variables for our container
Por exemplo, se você usa variáveis de ambiente para guardar sua secret key do Django é só fazer assim:
ENV DJANGO_SECRET_KEY abcde0s&&$uyc)hf_3rv@!a95nasd22e-dxt^9k^7!f+$jxkk+$k-
E usar no seu settings, desse jeito:
import os SECRET_KEY = os.environ['DJANGO_SECRET_KEY']
Run Commands
Docker Run Commands tem um nome meio óbvio. Você pode rodar um comando “dentro” do seu container. Estou colocando dentro entre aspas porque o docker na verdade cria algo como sub containers para que não precise rodar os mesmos comandos novamente no caso de precisar dar um rebuild do container.
RUN mkdir /webapps WORKDIR /webapps # Installing OS Dependencies RUN apt-get update && apt-get upgrade -y && apt-get install -y \ libsqlite3-dev RUN pip install -U pip setuptools COPY requirements.txt /webapps/ COPY requirements-opt.txt /webapps/ RUN pip install -r /webapps/requirements.txt RUN pip install -r /webapps/requirements-opt.txt ADD . /webapps/
Aqui estamos criando o diretório que guardará os arquivos do projeto: webapps/.
Workdir é uma instrução para mostrar ao docker em qual diretório ele vai rodar os comandos a partir dali.
Depois disso estou instalando as dependências do sistema operacional. Quando estamos usando requirements.txt no projeto, estamos colocando apenas os requisitos do python e não os do SO. Mais um motivo para querer usar o docker para desenvolver. Quanto maior seu projeto, mais requisitos de sistema operacional vão aparecer.
COPY e ADD
Copy e ADD são basicamente a mesma cosia. Ambos copiam um arquivo do seu computador (o Host) dentro do container (o Guest). No meu exemplo, estou apenas copiando o requirements para dentro do docker, para que eu possa dar pip install nos pacotes.
EXPOSE
Expose é para mapear uma porta do Guest (o Container) para o Host (seu computador)
# Django service EXPOSE 8000
Ok, e agora? Como podemos adicionar mais containers para rodá-los juntos? E se precisarmos colocar um postgresql para rodar em um container também? Não se preocupe, vamos usar o docker-compose.
Docker-Compose
O compose é uma ferramenta para rodar múltiplos containers do docker. Só precisa criar um arquivo yml na pasta do seu projeto com o nome docker-compose.yml:
version: '3.3'
services:
# Postgres
db:
image: postgres
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=postgres
- POSTGRES_DB=postgres
web:
build: .
command: ["./run_web.sh"]
volumes:
- .:/webapps
ports:
- "8000:8000"
links:
- db
depends_on:
- db
Aqui estou usando uma imagem do Postgres que também peguei no Docker Hub.
Agora vamos mudar o settings.py para poder usar o Postgres do container como banco de dados.
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'postgres',
'USER': 'postgres',
'PASSWORD': 'postgres',
'HOST': 'db',
'PORT': '5432',
}
}
Quase lá, deixa eu falar um pouco sobre o arquivo docker-compose.yml,
VOLUMES
Lembra do vagrant?
Era uma vez o Vagrant. Ele era uma forma de rodar um projeto dentro de uma Máquina Virtual que permitia configurar e mapear portas fácilmente, provisionar requisitos do sistema e compartilhar volumes. Seu computador (o Host) podia compartilhar um volume com a máquina virtual (o Guest, ou convidado). No docker, o volume é exatamente a mesma coisa. Quando você escreve um arquivo em um volume que está compartilhado o arquivo também está sendo escrito dentro do container.
volumes: - .:/webapps
Nesse o caso, o diretório em que nos encontramos (.) é o que está sendo compartilhado com o container.
LINKS
links: - db
Você pode se referir a outro container que pertence ao seu arquivo docker-compose utilizando o nome dele. Como criamos um container com o nome db para o Postgres nós podemos criar um link para ele no nosso container chamado web. Pode ver que no settings.py nós colocamos ‘db‘ como host.
DEPENDS_ON
Para rodar sua aplicação, seu banco de dados precisa estar pronto antes do container web, senão vai dar algum pau!
depends_on: - db
Command
Command é o comando padrão que o docker vai rodar logo depois que você subir, ou seja, colocar os containeres para funcionar.
No nosso exemplo, eu criei um run_web.sh que vai rodar as migrações, coletar o static files e iniciar o servidor de desenvolvimento.
#!/usr/bin/env bash cd django-boards/ python manage.py migrate python manage.py collectstatic --noinput python manage.py runserver 0.0.0.0:8000
Alguém pode argumentar que migrar assim automaticamente toda vez que subir o container pode não ser uma boa prática. Eu concordo. Você pode (e deve) rodar o migrate direto na máquina web. Você pode acessar seu container para rodar comandos assim (como no bom e velho vagrant ssh):
docker-compose exec web bash
Se você quiser , você pode rodar o comando sem acessar o container mesmo, apenas mudando o último argumento do comando acima:
docker-compose exec web python manage.py migrate
O mesmo para outros comandos:
docker-compose exec web python manage.py test docker-compose exec web python manage.py shell
Rodando o Docker
Com nosso Dockerfile, docker-compose.yml e o run_web.sh no lugar, vamos rodar tudo junto:
docker-compose up
Você pode ver esse projeto aqui no meu GitHub.
Escrevi esse texto originalmente em inglês.
**EDITADO**
Antes eu estava usando run no lugar de exec. Mas o Bruno FS me mostrou que o exec é melhor pois está acessando exatamente o container que já está rodando e que o run na verdade está criando um novo container.