Meu Django starter kit

Iniciando um novo projeto com Django e Docker

Ultimamente tenho desenvolvido todos os meus projetos usando Django, e como a cada dia acordo com uma nova super empolgante ideia, criar um projeto do zero não era uma tarefa trivial: levantar uma VM instalar todas as dependências, configurar o projeto, etc etc.

Eu consegui facilitar e agilizar todo esse processo com o Docker (que é uma ferramenta de aprendizagem diária — ainda falta muito pra estudar e usar). Nesse post vou dar uma ideia de como eu consegui otimizar a criação e inicialização dos meus projetos com o meu starter. Como não é um post exclusivo sobre as ferramentas que eu usei, vou tentar ser o mais genérico e breve possível.

O repositório tá aqui: https://github.com/gabrielfgularte/django-starter e eu super aceito contribuições, dicas, críticas, sugestões e qualquer outro tipo de contribuição.

Docker & Docker Compose

O Docker é uma ferramenta sensacional. Basicamente, ela roda containers de aplicação numa camada de alto nível, permitindo que ela seja agnóstica a ambientes. Essa premissa é o que difere o Docker de uma VM comum, que virtualiza todo um OS cada vez que você levanta ela. Se quiser saber mais sobre Docker, recomendo esse site: https://docker-curriculum.com/.

Quando comecei a usar o Docker, pensei que seria ótimo "dockerizar" minhas aplicações pré-existentes. O problema é que um container, por padrão e por conceito, deve rodar somente um serviço, uma aplicação, um comando. Então eu teria que ter um container rodando pro Django, um pro meu banco de dados, um pro meu webserver e um pra cada comando agendado (CRONs). E ainda teria que conectar todos esses serviços usando técnicas de networking entre containers e etc.

Foi aí que o Docker Compose me salvou. Com ele, pude criar uma "rede de serviços" que se comunicam uns com os outros, dentre outras coisas. Vamos ver um exemplo do meu docker-compose.yml, arquivo padrão para configurar os serviços do Docker Compose:

version: ‘3.3’
services:
database:
container_name: database
image: postgres
volumes:
— ./database:/var/lib/postgresql/data
django:
build: .
container_name: django
environment:
— PYTHONUNBUFFERED=1
volumes:
— ./application:/root
links:
— database
restart: unless-stopped
webserver:
image: nginx
links:
— django
volumes:
— ./nginx.conf:/etc/nginx/conf.d/default.conf
restart: unless-stopped

Quando usamos link, dizemos ao Docker que um serviço estará ligado ao outro. Ou seja, dentro do container django nós temos acesso ao container database . Dessa forma podemos acessar o IP desse container usando a string 'database'.

Django feat PostgreSQL

Eu sempre tenho usado Postgre como banco de dados, mas trocar pra outro banco não é difícil. É só você mudar o serviço do PostgreSQL para utilizar outra imagem. Por exemplo, supondo que você prefira utilizar MySQL, o serviço de database ficaria assim:

database:
container_name: database
image: mysql
volumes:
— ./database:/var/lib/mysql

Nginx feat Let's Encrypt SSL (HTTPS)

Toda aplicação que utiliza senha, compra, e/ou quaisquer outros dados sensíveis do usuário deve ser HTTPS. O próprio Google disse que vai começar a avisar aos usuários de forma mais incisiva sobre o site que ele está visitando se o site não for seguro. Como a grande maioria das minhas aplicações possuem dados sensíveis dos usuários, eu optei por colocar HTTPS no meu starter. E mesmo que eu não vá desenvolver uma aplicação com dados sensíveis, a Let's Encrypt emite certificados SSL de graça e não custa nada a gente aparecer verdinho com cadeado ali na barra de endereço. ;)

Pra isso, foi preciso ralar um pouco, e pra ser sincero, não sei e não pesquisei como isso ficaria se eu tivesse que usar Apache ou Lighthttpd. Como em todos os meus projetos, sou eu quem define as tecnologias a serem usadas e desde que migrei pro Python (usava PHP feat Apache) passei a usar Nginx, segui com ele. SUPER ACEITO CONTRIBUIÇÕES para colocar esse starter rodando com Apache e outros webservers também.

Outra coisa interessante e que deixa os seus serviços mais agnósticos a ambientes ainda, é que o Docker Compose aceita que você crie um arquivo chamado docker-compose.override.yml para substituir as configurações utilizadas no docker-compose.yml original. Aí fica fácil da gente escrever configurações de webserver diferentes pros ambientes que a gente precisa, seja local, homologação ou produção. Aqui vai uma dica: eu escrevo arquivos com os nomes dos ambientes, por exemplo, para produção, meu arquivo é docker-compose.prod.yml. Daí, na hora do deploy, eu subo o arquivo relativo ao ambiente e renomeio ele pra docker-compose.override.yml.

Lembrando que eu uso a versão 3.3 do Docker Compose File, e é provável que não funcione bem versões mais antigas.

Baixando, instalando e usando

Pra usar o django-starter, o que você precisa fazer é clonar, forkar ou baixar o repositório que tá no github no link ali em cima. Depois vá para pasta onde baixou e remova a pasta .git do projeto. Daí, basta renomear a pasta pro nome do seu projeto e rodar o arquivo install.sh.

Pra rodar a aplicação, é só rodar o comando updo Docker Compose ( docker-compose-up ).

Sempre que quiser parar, reiniciar ou rodar um dos serviços standalone, é só rodar o comando que deseja seguido do serviço definido no Docker Compose File, por exemplo, docker-compose stop django .

Seu novo projeto estará rodando em qualquer ambiente, usando sempre as ferramentas que você escolheu! Obrigado pela leitura, e até a próxima!