Dockerizing Django for Development

In this post, I’ll show how to containerize an existing project using Docker. I’ve picked a random project from GitHub that had an open issue saying Dockerize to contribute and use as an example here.

Why in the world do you want to Dockerize an existing Django web application? There are plenty of reasons, but if you don’t have one just do it for fun!

I decided to use docker because one of my applications was getting hard to install. Lots of system requirements, multiple databases, celery, and rabbitmq. So every time a new developer joined the team or had to work from a new computer, the system installation took a long time.

Difficult installations lead to time losses and time losses lead to laziness and laziness leads to bad habits and it goes on and on… For instance, one can decide to use SQLite instead of Postgres and not see truncate problems on a table until it hits the Test server.

If you don’t know what docker is, just picture it as a huge virtualenv that instead of containing just some python packages have Containers for isolating everything from the OS to your app, databases, workers, etc.

Getting Things Done

Ok, talk is cheap. Show me some code, dude.

First of all, install Docker. I did it using Ubuntu and Mac OS without any problem, but on Windows Home, I couldn’t have it working.

To tell Docker how to run your application as a container you’ll have to create a Dockerfile

FROM python:3.6

RUN mkdir /webapps
WORKDIR /webapps

# Installing OS Dependencies
RUN apt-get update && apt-get upgrade -y && apt-get install -y \

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

So, let’s go line by line:

Docker Images

FROM python:3.6

Here we’re using an Image from docker hub. e.q. One pre-formated container that helps build on top of it. In this case, Python 3.6 is an Ubuntu container that already has Python3.6 installed on it.

Environment Variables

You can create all sort of Environment Variables using Env.

ENV PYTHONUNBUFFERED 1  # Here we can create all Environment variables for our container

For instance, if you use them for storing your Django’s Secret Key, you could put it here:

ENV DJANGO_SECRET_KEY abcde0s&&$uyc)[email protected]!a95nasd22e-dxt^9k^7!f+$jxkk+$k-

And in your code use it like this:

import os

Run Commands

Docker Run Commands are kinda obvious. You’re running a command “inside” your container. I’m quoting inside because docker creates something as sub-containers, so it doesn’t have to run the same command again in case of rebuilding a container.

RUN mkdir /webapps
WORKDIR /webapps

# Installing OS Dependencies
RUN apt-get update && apt-get upgrade -y && apt-get install -y \

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/

In this case, We are creating the directory that will hold our files webapps/.

Workdir is also kind of self-evident. It just telling docker to run the commands in the indicated directory.

After that, I am including one OS dependency. When we’re just using requirements.txt  we are not including any OS requirement for the project and believe me, for large projects you’ll have lots and lots of OS requirements.


Copy and ADD are similar. Both copy a file from your computer (the Host) into the container (The Guest OS). In my example, I’m just coping python requirements to pip install them.


Expose Instruction is for forwarding a port from Guest to the Host.

# Django service

Ok, so now what? How can we add more containers and make them work together? What if I need a Postgresql inside a container too? Don’t worry, here we go.


Compose is a tool for running multiple Docker containers. It’s a yml file, you just need to create a docker-compose.yml on your project folder.

version: '3.3'

  # Postgres
    image: postgres
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres

    build: .
    command: ["./"]
      - .:/webapps
      - "8000:8000"
      - db
      - db

In this case, I’m using an Image of Postgres from Docker Hub.

Now, let’s change the to use Postgres as Database.

    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'postgres',
        'USER': 'postgres',
        'PASSWORD': 'postgres',
        'HOST': 'db',
        'PORT': '5432',

We’re almost done. Let me talk a little about the docker-compose file.


Remember vagrant?

Once upon a time, there was Vagrant and it was a form to run a project inside a Virtual Machine but easily configuring it, forwarding ports, provisioning requirements and, sharing volumes. Your machine (Host) could share a volume with your Virtual Machine (Guest). In docker, it’s exactly the same. When you’re writing a file on a shared volume this file is being written on your container as well.

  - .:/webapps

In this case, the current directory (.) is being shared as webapps on the container.


  - db

You can refer to another container that belongs to your compose using its name. Since we created a db container for our Postgres we can link it to our web container. You can see in our file that I’ve used ‘db‘ as host.


In order for your application to work, your database has to be ready for use before web container, otherwise, it will raise an exception.

  - db


Command is the default command that your container will run right after it is up.

For our example, I’ve created a, that will run the migrations, collect the static files and start the development server.

#!/usr/bin/env bash

cd django-boards/
python migrate
python collectstatic --noinput
python runserver

One can argue that run the migrate at this point, automatically, every time the container is up is not a good practice. I agree. You can run it directly on the web machine. You can access your container (just like the good’ol vagrant ssh) :

docker-compose exec web bash

If you’d like you can run it without accessing the container itself, just change the last argument from the previous command.

docker-compose exec web python migrate

The same for other commands

docker-compose exec web python test
docker-compose exec web python shell

Running Docker

With our Dockerfile, docker-compose.yml and set in place, just run it all together:

docker-compose up

You can see this project here on my GitHub.


At first, I was using run instead of exec. But Bruno FS convinced me that exec is better because you’re executing a command inside the container you’re already running, instead of creating a new one.


Guia para Deploy Django Python 3

crianças fazendo deploy

Tutorial de Deploy por aí é o que não falta, a maioria em inglês. Esse que estou criando é pra engrossar o caldo de deploys em português. Esse é um Guia Definitivo Rápido, ou não tão rápido, para fazer Deploy Django com Python 3. É um deploy para Kids.

A dificuldade de fazer um deploy reside nos detalhes. No fundo é fácil se você está familiarizado com as partes envolvidas. Você precisa saber fazer uma autenticação ssh, estar acostumado com a linha de comando, conhecer linux, saber configurar o projeto, entender o que é servir arquivos estáticos, gunicorn…. tá, tá… nunca é fácil e muito menos rápido, justamente por isso criaram um monte de ferramentas pra deploy. E hoje com Ansible, Docker e whatever kids are using these days fica fácil fazer o deploy mas muito abstrato entender o funcionamento.

Em alguns anos esse post será obsoleto pra sempre, com serverless e tudo mais acho que pouca gente vai querer saber como fazer um deploy django dessa forma. Mas, mesmo assim, se ajudar uma pessoa já está bom. Será um tutorial Old-Style.

O Servidor

Vou imaginar que você não tem um servidor, não tem uma conta na AWS, nem DigitalOcean, nem Linode, nada… Você pode criar uma conta em um deles, lançar uma máquina com as configurações que quiser (Na AWS é tudo mais complicado pra quem não está acostumado, se for sua primeira vez, prefira outro).

Pra esse tutorial estou falando de Ubuntu 16.04, que é o servidor que você mais vai ver por aí nesse momento nesses serviços. Você pode escolher um Debian qualquer também.

Configuração inicial

Configure o timezone do servidor

sudo locale-gen --no-purge --lang pt_BR
sudo dpkg-reconfigure tzdata

Atualize os pacotes:

sudo apt-get update 
sudo apt-get -y upgrade

Instalando Python 3.6 no lugar do Python 3.5

Agora substitua o Python 3.5 instalado, pelo Python3.6 (O Ubuntu que indiquei, ele vem com Python 3.5.1)

sudo apt-get update
sudo add-apt-repository ppa:jonathonf/python-3.6
sudo apt-get install python3.6
sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.5 1
sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.6 2

Você pode escolher qual versão do Python o SO vai usar ao chamar python3 com:

sudo update-alternatives --config python3

Se você se enrolar, dê uma olhada aqui.

Instale os requisistos do Sistema Operacional

Aqui tem alguns pacotes que eu sempre uso em um deploy.

sudo apt-get install python3-pip nginx supervisor git git-core libpq-dev python-dev 

Seu projeto pode ter outros requirements do SO pra instalar.

VirtualEnvWrapper para o Python3

Eu gosto muito do VirtualEnvWrapper, acho simples de começar um virtualenv, e deixa todos os meus virtualenvs no mesmo lugar, mas isso é escolha pessoal, se você não gosta, faça como está acostumado

Você instala o virtualenvwrapper, depois define a pasta dos seus virtualenvs (WORKON_HOME).

Para usar com múltiplos Pythons você vai precisar definir VIRTUALENVWRAPPER_PYTHON. No caso estou usando sempre o padrão que defini para o comando python3. Isso não é um problema porque você pode criar um virtualenv depois apontando qual python aquele virtualenv vai usar.

sudo pip3 install virtualenvwrapper
echo 'export WORKON_HOME=~/Envs' >> ~/.bashrc
echo ‘export VIRTUALENVWRAPPER_PYTHON=`which python3`’ >> ~/.bashrc
echo 'source /usr/local/bin/' >> ~/.bashrc
source ~/.bashrc

Crie seu VirtualEnv apontando qual python aquele virtualenv irá usar

mkvirtualenv nome_venv --python=python3

O VirtualEnvWrapper é muito fácil, para entrar em um Virtualenv que você criou, você pode usar:

workon nome_venv

Para sair do virtualenv:


Para excluir um virtualenv:

rmvirtualenv nome_venv

Gere as Chaves SSH para autenticar no GitHub

Você não quer (e nem deveria) escrever a senha pra fazer o git pull do seu projeto no servidor.

Gere as chaves SSH

cd ~/.ssh
ssh-keygen -t rsa -b 4096 -C "[email protected]"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

Veja e copie o conteúdo da sua chave pública (

cat ~/.ssh/

Depois entre no seu github, em Settings > SSH and GPG Keys. Clique em New SSH Key, dê um nome pra essa chave, como (“chaves do servidor teste”) e em Key cole o conteúdo da chave pública

Faça o clone do seu projeto Django

Copie o link SSH do Github para fazer o clone, no caso estou usando um projeto que encontrei agora pra exemplo

git clone [email protected]:kirpit/django-sample-app.git

Entre na pasta do projeto e instale os requirements do projeto.

Lembre-se de estar no virtual env correto.

cd django-sample-app/
pip install -r requirements.txt

Agora faça as alterações que forem necessárias para o deploy django, como criar um arquivo de settings_local, banco de dados, ou qualquer outra coisa específica do seu projeto.

Depois de tudo certo, você ainda precisa rodar as migrações e gerar os arquivos estáticos (se estiver usando)

python migrate
python collectstatic

Configurando o NGINX

Nginx, assim como o Apache, tem um mundo inteiro só deles, nesse momento você precisa conhecer o básico.

Existe um diretório /etc/nginx/sites-available/ onde ficão os arquivos de configuração de sites disponíveis para o nginx servir e existe o diretório /etc/nginx/sites-enabled/ que é a mesmíssima coisa, mas o que estiver aqui o Nginx estará servindo mesmo.

Normalmente você cria o arquivo de configuração no sites-available/ e cria um link simbólico para o sites-enabled/

Nós vamos fazer isso. Primeiramente, vou excluir o site default do nginx

sudo rm /etc/nginx/sites-enabled/default

Agora crie o arquivo de configuração para o seu site. (Se você não está acostumado com o VIM, use troque vi por nano)

sudo vi /etc/nginx/sites-available/meusite

No conteúdo do arquivo, coloque isto, mudando os caminhos necessários:

server {
 listen 80;
 access_log /home/usuario/logs/access.log;
 error_log /home/usuario/logs/error.log;


 location / {

 #As proximas linhas passam o IP real para o gunicorn nao achar que sao acessos locais
 proxy_pass_header Server;
 proxy_set_header X-Forwarded-Host $server_name;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Host $http_host;


 location /static {

   alias /home/usuario/caminho_projeto/static/;



Agora crie o link simbólico para o sites-enabled:

sudo ln -s /etc/nginx/sites-available/meusite /etc/nginx/sites-enabled/meusite

Reinicie o Nginx:

sudo service nginx restart

(Se você configurou tudo direitinho até aqui, ao acessar o site você verá uma página com um erro 502 Bad Gateway do próprio nginx)

Isso acontece porque ainda não tem nada aqui

Vamos colocar o site pra rodar nessa porta pelo gunicorn

Configurando o Gunicorn

Alguém vivo até essa parte? Cansa não, falta pouco.

No seu virtualenv (lembra workon nome_env?) instale o gunicorn

pip install gunicorn

Na pasta do seu projeto crie um arquivo chamado gunicorn_conf com:

bind = ""
logfile = "/home/usuario/logs/gunicorn.log"
workers = 3

Agora se você rodar o gunicorn, você vai ver seu site rodando:

/home/usuario/Envs/nome_venv/bin/gunicorn projeto.wsgi:application -c gunicorn_conf

Mas o que você pretende fazer? Rodar esse comando dentro de um screen e ir embora? Não dá né! Então, você vai usar o Supervisor pra controlar o funcionamento do gunicorn.

Configurando o Supervisor

Crie o seguinte arquivo de configuração

sudo vi /etc/supervisor/conf.d/gunicorn.conf

Com o seguinte conteúdo:

command=/home/usuario/Envs/nome_venv/bin/gunicorn projeto.wsgi:application -c /home/usuario/projeto/projeto_django/gunicorn_conf

Depois é só avisar o supervisor que existe um novo processo que ele precisa controlar da seguinte forma:

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl restart gunicorn

E voilá! Um site rodando você terá!


Existem muito mais coisas envolvidas no processo de um deploy. Você precisa configurar um firewall, provavelmente precisará servir mais pastas estáticas, etc, etc, etc… Mas precisa começar por algum lugar.

Gostou? Me segue no insta

Tutorial Virtualenv para iniciantes (windows)

Esse tutorial de Virtualenv para Iniciantes ensina como instalar e utilizar o Virtualenv no windows.

Primeiramente, instale o VirtualEnv usando o pip ou o easy_install:

c:\Python27\Scripts\pip.exe install virtualenv

Depois crie um diretório onde estarão seus ambientes virtuais

C:\Users\Fernando>mkdir virtualenv

Agora crie o seu ambiente virtual:

C:\Users\Fernando>c:\Python27\Scripts\virtualenv.exe virtualenv\virtual_1

Neste caso, você criou um ambiente virtual com python 2.7 e todos os pacotes que você já tem no seu sistema (que tenham sido instalados com pip ou com easy_install)

Se você está criando um novo ambiente virtual pode ser mais inteligente não usar todos os seus pacotes e colocar somente aqueles que você precisa utilizar por algum motivo, como por exemplo utilizar um sistema criado em versões anteriores de pacotes que você já atualizou

Então, vamos remover o virtualenv que criamos e fazer um novo com a opção –no-site-packages:

C:\Users\Fernando>del virtualenv\virtual_1
C:\Users\Fernando\virtualenv\virtual_1\*, Você tem certeza (S/N)? S
C:\Users\Fernando>c:\Python27\Scripts\virtualenv.exe virtualenv\virtual_1 --no-site-packages

OK, agora você tem um virtual env zerado e pronto pra colocar os pacotes que você quer.

Para ativar e usar este virtualenv é bem simples:


Agora, antes da linha de comando, aparecerá um flag (virtual_1) dizendo que você está usando o virtual env “virtual_1”.

(virtual_1) C:\Users\Fernando>

para instalar alguns pacotes você deve usar o pip.

Imagine que você precisa usar o Django1.2 para acessar um projeto antigo e não quer zuar a sua instalação do Django1.6, você pode baixar esta versão dentro de um virtualenv utilizando pip install Django==1.2

Muito simples, né? Agora vou clonar um projeto bem antigo e colocá-lo pra funcionar dentro do virtual_1

(virtual_1) C:\Users\Fernando>git clone
(virtual_1) C:\Users\Fernando\controle-de-ponto-biometrico>pip install -r requirements.txt

Agora eu posso criar minha base com python syncdb e colocar o servidor de desenvolvimento pra funcionar com python runserver e voilá, está funcionando!

Gostou do post? Me segue no Instagram:

VirtualEnv Tutorial for beginners (Windows)

Easy VirtualEnv Tutorial for beginners (Windows)

First of all, pip install VirtualEnv:

c:\Python27\Scripts\pip.exe install virtualenv


Second, create a directory to put your virtual environments.

C:\Users\Fernando>mkdir virtualenv

Then create your virtualenv:

C:\Users\Fernando>c:\Python27\Scripts\virtualenv.exe virtualenv\virtual_1

In this case you are creating a Virtual Environment with python27 and all the packages that you already got. (installed by pip our easy_install).
If you are creating another environment it is smarter not to use all your packages and install just the packages you want to try (or some old packages to bring old systems in old versions to life).

So remove the env that we created and create a new one with –no-site-packages option:

C:\Users\Fernando>del virtualenv\virtual_1
C:\Users\Fernando\virtualenv\virtual_1\*, Are you sure (Y/N)? Y
C:\Users\Fernando>c:\Python27\Scripts\virtualenv.exe virtualenv\virtual_1 --no-site-packages

Ok, now you have an empty virtualenv environment.

So, to use this enviroment you have to activate it. It is simple:


Now, you’ll see a flag(?) before the command line, like this:

(virtual_1) C:\Users\Fernando>

it means you’re using “virtual_1” environment.

To install some package you can use pip.exe that is in Scripts directory.
So let’s say I need to run some old application that needs Django1.2 to run, I will pip install Django1.2 in this enviroment without mess with my django1.6 package that I’m using in my new projects. It is simple:

virtualenv\virtual_1\Scripts\pip.exe install django==1.2

well, Simple, isn´t it? So now I gonna clone some old project of mine and install the requirements using my virtual env:

(virtual_1) C:\Users\Fernando>git clone
(virtual_1) C:\Users\Fernando\controle-de-ponto-biometrico>pip install -r requirements.txt

And now it is ready to use, I created the database using python syncdb and then I’ve the developer Server with python runserver and it worked.