Django Web Framework

Django és un framework per a aplicacions web en Python.

És conegut com The framework for perfectionists with deadlines per la seva rapidesa de desenvolupament.

En aquest article tractarem els temes de l'entorn d'execució d'un projecte Django, per tal que es pugui posar en producció de forma segura.

Django té una documentació excel·lent, en particular el Tutorial Django.

Referències:

• Presentació de diapositives Django en aquesta wiki.
• Web oficial: https://www.djangoproject.com
• El magnífic tutorial de la web oficial.
• Exemple app Django per gestió d'una lliga de futbol en aquesta wiki, molt recomanat fer-ho després d'haver completat el Django Tutorial oficial.
• Un altre bon tutorial de MDN Mozilla Web Docs.

Articles sobre Django en aquesta wiki

Introducció per a DevOps

Desenvolupar un projecte (en Django o en molts altres frameworks) és una tasca força diferent a la de construir la infraestructura correcta per a posar el projecte en producció, ja sigui directament en un servidor propi o de forma dockeritzada en contenidors. Això darrer és el què farem en aquest article, que és la feina més pròpia del DevOps.

Prepar un projecte Django per a què sigui segur implica diverses coses:

1. Configurar un virtualenv amb les llibreries adequades (requirements.txt).
2. Crear el projecte amb les versions adequades i actualitzades.
3. Tenir el projecte sota un VCS (sistema de versionat) com Git.
4. Configurar les dades sensibles del projecte (contrasenyes, tokens, etc.) perquè no es publiquin al repositori de codi.
5. Habilitar configuració de l'app mitjançant variables d'entorn, enlloc de fitxers.
6. Fer un README per facilitar la clonació i posta en marxa del projecte.
7. Configurar la BD adequadament.
8. Configurar el servidor d'arxius estàtics.
9. Posar el projecte en producció amb un servidor d'aplicacions (uWSGI) + un servidor web (Nginx) per als arxius estàtics.

Entorn Python Venv

Per treballar en Python ens convé una eina d'entorn que ens aïlli les diferents versions de llibreries que farem servir, i no tenir incompatibilitats entre les diferents aplicacions que puc tenir (ni tampoc amb el sistema operatiu, que té les seves pròpies versions de les llibreries).

A l'article Python venv teniu detalls a fons de com utilitzar aquestes eines.

Resumidament, necessitem crear l'entorn virtual, entrar-hi i instal·lar Django en una versió LTS (x.2):

$ python3 -m venv env
$ source env/bin/activate
(env) $ pip install django==4.2

> python3 -m venv env
> env\Scripts\Activate.bat
(env) > pip install django==4.2

Quickstart: crear projecte mínim

Crearem un projecte Django i provarem si funciona simplement amb:

(env) $ django-admin startproject myproject
(env) $ cd myproject
(env) $ ./manage.py runserver 0.0.0.0:8000

I per comprovar-ho accedeix amb el navegador a http://localhost:8000.

Si volem endinsar-nos a la programació amb Django es recomana seguir l'excel·lent tutorial oficial Django.

Per entrar al admin panel de Django cal fer migració (crea BD) i crear un usuari:

(env) $ ./manage.py migrate
(env) $ ./manage.py createsuperuser

Visita el admin panel a http://localhost:8000/admin/

Per seguir amb la creació de models, caldrà crear al menys una aplicació dins del projecte Django:

(env) $ ./manage.py startapp myapp

Donar d'alta la nova app afegint aquestes línies als arxius:

settings.py

# ...
INSTALLED_APPS = [
    "myapp.apps.MyappConfig",
# ...

I activar els models a l'admin panel a:

admin.py

from django.contrib import admin
from .models import *
 
admin.site.register(MyModel1)
admin.site.register(MyModel2)
# ...

Cada cop que modifiquem el model de dades del projecte caldrà afegir:

(env) $ ./manage.py makemigrations
(env) $ ./manage.py migrate

ORM, models i migracions

Un Object-Relational Mapper és una eina que facilita l'accés a dades mapejant les taules i relacions en objectes (classes) del llenguatge de programació. Això permet una abstracció de la base de dades concreta que s'està emprant i no haver d'utilitzar SQL, sinó crides a mètodes dels objectes instanciats.

Un model, en el context d'un ORM, és una class que està mapejada a una taula de la base de dades. Així, per exemple, es pot crear la següent class a l'arxiu models.py de Django:

from django.db import models
 
class Llibre (models.Model):
    titol = models.CharField(max_length=100)
    autor = models.CharField(max_length=200)
    resum = models.TextField(null=True,blank=True)
    data_edicio = models.DateField()

Per crear un llibre i guardar-lo a la taula, enlloc d'emprar SQL, amb el ORM faríem:

llibre = Llibre()
llibre.titol = "El mag del Kremlin"
llibre.autor = "Giuliano da Empoli"
import datetime
llibre.data_edicio = datetime.datetime(2023, 3, 29)
# per persistir l'objecte a la BD cal cridar el mètode save()
llibre.save()

En el context dels frameworks de desenvolupament, una eina de migració gestiona les versions i evolució dels esquemes de les bases de dades.

Durant el desenvolupament convé planificar amb anterioritat l'esquema de la base de dades per tal que pateixi el mínim de modificacions. Cada cop que es modifica la base de dades hi ha un gran risc de que parts del codi deixin de funcionar o de que perdem dades en el canvi (migració) d'una versió de l'esquema a la següent. Malgrat tot, preveure totes les situacions es fa impossible i aplicar canvis a l'esquema de la base de dades es fa imprescindible, per molt que es vulgui minimitzar. L'ús d'eines de migració milloren aquesta gestió i permeten una transició ordenada i, sobretot, automatitzada, d'un esquema al següent.

El mecanisme és simple: cal un arxiu de migració que realitzi els canvis a la BD a cada evolució. Cada migració pot implicar un canvi simple com afegir o esborrar una columna fins a grans canvis com afegir multitud de taules i relacions.

Tenim dos exemples complementaris i paradigmàtics en la gestió de les migracions: els dels frameworks Django i Laravel:

• En Laravel el desenvolupador ha d'escriure un script de migració per aplicar els canvis explícits a la base de dades, com eliminar una columna o crear noves taules i relacions.
• En Django el desenvolupador modifica directament el model amb l'ORM. Amb la instrucció makemigrations l'arxiu de migració es genera automàticament. El framework analitza el codi del model actual i l'anterior, i genera les ordres adequades dins un script de migració.

En el projecte que estavem desenvolupant, podem crear models i després realitzar les migracions executant:

(env1) $ ./manage.py makemigrations
(env1) $ ./manage.py migrate

Veurem que ara apareix un arxiu db.sqlite3 a l'arrel del projecte on s'hauran creat algunes taules, en particular users i groups, que son objectes builtin de Django (venen predefinits tot i que es poden modificar). SQLite és un SGBD senzill per BD locals en un sol arxiu amb propòsits de desenvolupament (no és apta per a desplegament).

Per visualitzar les taules podem crear un superusuari i entrar a l'admin panel:

(env1) $ ./manage.py createsuperuser
(env1) $ ./manage.py runserver

Entrem a http://localhost:8000/admin/ amb l'usuari i contrasenya creats i podrem veure, crear i modificar usuaris i grups i les diferents característiques d'aquests.

Crear repositori Git

Anem a Github (o a Gitlab, Bitbucket, etc.) i fem crear un nou repositori. Si ho feu a la web, ella mateix ens donarà la «xuleta» de com inicialitzar el nostre projecte i connectar-lo al repo remot.

Teniu articles amb informació extensa sobre el sistema de control de versions i de Git en particular.

Configurar .gitignore

Abans d'entrar tots els arxius ens convé crear un arxiu .gitignore a l'arrel del nostre repositori (si esteu seguint el tutorial Django oficial, seria la carpeta mysite). Aquest li dirà a la instrucció git add que ignori els arxius que compleixi amb determinats patrons.

En particular, NO volem que entrin al repo:

• Arxius que continguin contrasenyes i altra informació sensible que no volem que es publiqui.
• El fitxer de la BD de SQLite (db.sqlite)
• Els arxius transitoris d'execució accelerada de Python (els arxius .pyc)
• Les carpetes de virtualenv. El virtualenv es crearà de nou cada cop que clonem un repositori.

Una versió mínima dels arxius i carpetes que NO volem que es pugin al repo seria aquest:

.gitignore

*.pyc
/env/
/venv/
/static/*
/media/*
.env
db.sqlite3
.coverage
__pycache__

Pujar els arxius

Si tens correctament ajustat el .gitignore, ja pots afegir tots els arxius al repositori local i pujar-los al repo remot:

(env) $ git init
(env) $ git branch -m main
(env) $ git add .
(env) $ git commit -am "primer commit"

Aquí hauries de enllaçar el teu repositori local amb el remot (per ex. de Github):

(env) $ git remote add origin https://github.com/...
(env) $ git push -u origin main

requirements.txt

Podem afegir llibreries que necessitem al nostre entorn. Ens serà convenient, de cara a clonar i/o portar a producció el projecte, que sapiguem exactament les versions que necessitem. Podem saber les versions que tenim a l'actual venv amb:

(env) $ pip freeze

Hi ha un consens en utilitzar l'arxiu requirements.txt per a aquest objectiu. Per tant, cada cop que afegim noves dependències, caldrà afegir-les a aquest arxiu, de forma manual, o bé amb l'anterior instrucció.

Afegim una llibreria (necessitarem django-environ més endavant):

(env) $ pip install django-environ 

Veiem que ara tenim la llibreria afegida amb:

(env) $ pip freeze

I ara volquem tota aquesta info a requirements.txt:

(env) $ pip freeze > requirements.txt

Quan necessitis carregar les llibreries a l'instal·lar un nou repo, ho pots fer així:

(env) $ pip install -r requirements.txt

Versions

L'elecció de versions del projecte és molt important. Si examinem el contingut de requirements.txt (generat amb pip freeze) veurem que ens mostra les versions de tots els paquets que tenim instal·lats en el virtualenv. En el meu cas (Desembre 2021) em surten aquestes:

asgiref==3.4.1
Django==3.2.9
django-environ==0.8.1
mysqlclient==2.1.0
pytz==2021.3
sqlparse==0.4.2

En algun cas es poden trobar problemes per fer funcionar un projecte, si el sistema operatiu és diferent. En aquests casos potser és millor simplificar el requirements.txt posant els packages imprescindibles i deixar que el propi gestor pip trobi les dependències. En aquest cas no ho faríem amb el pip freeze, sinó que crearíem el fitxe a mà:

django==4.2
django-environ
mysqlclient

Hem de tenir en compte el cicle de vida de les versions de Django que fem servir. Les versions LTS són les Long Term Service que ens donaran cobertura durant més temps. Podem veure la política de versions a la web de descàrrega de Django:

A data de juny de 2024 utilitzarem la 4.2 (LTS) però caldrà tenir cura d'actualitzar a la següent LTS (5.2) abans de que el suport de l'actual finalitzi.

Variables d'entorn amb django-environ

És important que les dades sensibles com passwords, keys, tokens, etc. no es pugin al VCS.

Instal·lem django-environ per facilitar que més tard puguem passar aquestes dades sensibles a l'aplicació mitjançant les variables d'entorn, i així no posar-les en arxius. En producció es passaran aquests valors com a variables d'entorn (per exemple, en utilitzar Docker).

En development, per facilitar el treball diari, posarem les dades sensibles a l'arxiu .env. Aquest arxiu carregarà els continguts com a variables d'entorn just abans d'engegar l'aplicació (quan fem ./manage.py runserver).

Si no ho heu fet abans:

(env) $ pip install django-environ

Retirarem les dades sensibles de settings.py i les situarem a l'arxiu .env (que ja em marcat com a exclòs al .gitignore) i que simula la càrrega de variables d'entorn com quan estiguem en mode de producció.

Utilitzant MySQL

Per defecte, Django utilitza la BD SQLite, però ens cal una BD apta per a producció com MySQL o PostgreSQL. A la doc oficial de Django tenim com utilitzar els diversos SGBD més habituals.

Per utilitzar MySQL caldrà instal·lar els binaris necessaris al sistema operatiu. Per a Ubuntu:

$ sudo apt install libmysqlclient-dev python3-dev python3-mysqldb gcc pkgconf

I també els connectors del virtualenv de Python:

(env) $ pip install mysqlclient

DATABASE_URL='mysql://usuari:contrasenya@host:port/nom_db'

Per veure si la configuració de la BD funciona, pots fer (si la BD està buida crearà les taules):

(env) $ ./manage.py migrate

DATABASE_URL=sqlite:///db.sqlite3

Django en producció

Ja hem configurat el nostre projecte adientment, ara ens queda portar-lo a producció amb un servidor d'aplicacions. Molts tutorials posen en marxa Django amb el propi servidor de desenvolupament (el ./manage.py runserver) però això no és una bona pràctica. El servidor de desenvolupament no està pensat per gestionar adequadament el multithreading i altres implicacions en producció.

Necessitem un servidor d'aplicacions específic, com cal, per posar Django en producció de forma segura.

Servidor d'aplicacions uWSGI

uWSGI (doc oficial) funciona en pur Python. Podem seguir el tutorial per Django amb uWSGI i Nginx de la documentació oficial.

Assegura't que tens instal·lades les dependències per compilar packages:

(env) $ sudo apt install gcc build-essential python3-dev

En realitat la seva instal·lació i posta en marxa és molt senzilla:

(env) $ pip install uwsgi
(env) $ uwsgi --http :8000 --module mysite.wsgi

Arxius estàtics

Si has posat en marxa el projecte amb un servidor de producció (no amb el servidor de development) veuràs que si intentes accedir al panell d'administració /admin no es veu correctament. Falten els arxius estàtics, imatges i CSS, que cal servir amb un servidor web com Apache o Nginx, que son molt més eficients que forçar a Django a fer-ho.

Per recopilar tots els arxius estàtics caldrà ajustar la variable STATIC_ROOT i STATIC_URL a settings.py:

STATIC_ROOT = 'static/'
STATIC_URL = '/static/'

I recopilar els arxius estàtics amb la instrucció:

(env) $ ./manage.py collectstatic

Veurem que a l'arrel del projecte s'haurà creat la carpeta static amb els arxius estàtics com imatges i fulles d'estil CSS.

Configurar Nginx per a servir arxius estàtics

Un cop recopilats els arxius estàtics a la carpeta static/ ens caldrà servir aquests arxius amb un Nginx, que és força més lleuger que l'Apache.

Django no ha de servir mai arxius estàtics, ja que és menys eficient que el Web Server, que està pensat per a això específicament. El següent diagrama mostra com es durà a terme la posada en producció final:

(env) $ uwsgi --socket :8001 --module mysite.wsgi

Engegant Django app amb Supervisor

$ sudo supervisorctl reload

$ sudo supervisorctl status

Més Django

Pots continuar a l'article Django Docker per dockeritzar la nostra webapp.

Altres parts de Django interessants:

• Custom commands per afegir funcionalitats des de la shell.
• Python Faker per generar dades de prova.