Tuto pour le déploiement des sites Django

Pour se connecter, accéder aux fichiers du site et d'autres informations générales sur l'administration du site sont disponible sur la page sur l'hébergement des sites des binets.

Environnement virtuel

Une fois que le code du site est en place, il créer un environnement virtuel, c'est-à-dire une copie locale de l'interpréteur Python correspondant à la version que vous utilisez pour votre site :

virtualenv -p /usr/bin/python3.6 venv

Il est important que vous nommiez le dossier venv.

À partir de là, toutes les commandes utilisant python doivent être exécutées dans le virtualenv. Pour rentrer dans le virtualenv, vous devez lancer :

source venv/bin/activate

Si cela a fonctionné, vous aurez (venv) en préfixe dans votre terminal :

(venv) prenom.nom@ostizan:/hosting/www/site_binet/htdocs

Une fois dans le venv, vous pouvez installer les dépendances nécessaires :

pip install -r requirements.txt

Adaptations

Certaines adaptations sont nécessaires pour faire fonctionner le site. La documentation officielle de Django fournit une bonne checklist. Là, pas besoin de se casser la tête il suffit de suivre la liste, des liens sont là pour expliquer en détails ce que l'on fait à chaque fois. Les points essentiels à ne surtout pas sauter sont :

• Mettre DEBUG à Modèle:False
• SECRET_KEY:

Si vous utilisez un repo git, il ne faut pas mettre cette clef dans le code. Un snippet possible est le suivant:

keyfile = os.path.join(BASE_DIR, "secret.key")
if not os.path.exists(keyfile):
    with open(keyfile, "wb") as f:
        f.write(base64.b64_encode(os.urandom(30)))
with open(keyfile, "r") as f:
    SECRET_KEY = f.read().strip()

La clef est contenue dans le fichier secret.key (généré automatiquement s'il n'existe pas) qu'il suffit de mettre dans le .gitignore.

• Mettre ALLOWED_HOST à ["*"], le filtrage a lieu avant Django
• STATIC_ROOT, STATIC_URL, MEDIA_ROOT et MEDIA_URL:

STATIC_URL = '/assets/static/'
STATIC_ROOT = os.path.join(BASE_DIR, "assets/static/")
MEDIA_ROOT = os.path.join(BASE_DIR, "assets/media/")
MEDIA_URL = '/assets/media/'

• emails (indispensable pour être averti des erreurs 500)

DEFAULT_FROM_EMAIL = "nom_du_binet@binets.polytechnique.fr"
# voir https://portail.polytechnique.edu/dsi/eleves/mail-binets
SERVER_EMAIL = DEFAULT_FROM_EMAIL
ADMINS = [("Webmaster", DEFAULT_FROM_EMAIL)]

• base de donnée : n'utilisez pas sqlite ! Nous avons eu des problèmes par le passé, et les bases de données sql sont sauvegardées toutes les semaines.

Un snippet utilisable est :

if DEBUG:
  DATABASES = {
    'default': {
      'ENGINE': 'django.db.backends.sqlite3',
      'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
  }
else:
  DATABASES = {
    'default': {
       'ENGINE': 'django.db.backends.mysql',
       'OPTIONS': {
           'read_default_file': os.path.join(BASE_DIR, 'my.cnf'),
       },
    }
 }

Placer les mots de passe dans le fichier my.cnf:

[client]
database = NAME
user = USER
password = PASSWORD
default-character-set = utf8

Bien sûr il faut ajouter ce fichier dans le gitignore.

Mise en place de l'authentification par CAS sous Django

• Demander sur Panix à utiliser cette authentification. Préciser les éventuels attributs supplémentaires nécessaires (promo, section, ...).
• Installer le paquet django-cas-ng :

 pip install django-cas-ng

• Ajouter ce paquet à la liste des applications :

 INSTALLED_APPS = [
   ...
   'django_cas_ng',
   ...
 ]

• Configurer la connection au serveur CAS du BR :

 AUTHENTICATION_BACKENDS = (
   'django.contrib.auth.backends.ModelBackend',
   'django_cas_ng.backends.CASBackend',
 )
 CAS_SERVER_URL = "https://cas.binets.fr/"

• Renseigner les pages de connexion (dans my_project/urls.py par exemple):

 from django_cas_ng.views import login, logout
 
 urlpatterns = [
   ...
   url(r'^login$', login, name='cas_ng_login'),
   url(r'^logout$', logout, name='cas_ng_logout'),
   ...
 ]

• Ajouter l'URL d'entrée :

 LOGIN_URL = "login"

• Attention à forcer l'authentification pour les pages concernées :

 from django.contrib.auth.decorators import login_required
 
 @login_required
 def my_awesome_view(request):
   ...

À noter :

• le nom de l'utilisateur connecté se trouve dans : request.user.username (accessible dans n'importe quelle vue).
• les attributs du LDAP peuvent être disponibles (demander les attributs nécessaires lors de la mise en place du CAS). Ils sont alors disponibles dans request.session['attributes'] .
• plus d'option de configuration sont présentés ici

À chaque modification...

• du code python quel qu'il soit :

touch /var/run/please/restart

• du schéma SQL (sous Django):

python manage.py migrate

• des fichiers statiques (sous Django):

python manage.py collectstatic

Il faut attendre 1 ou deux minutes que le système enregistre la modification, quand c'est fait il affiche un message dans le terminal.

Tester

Erreurs python

La commande

python manage.py runserver

permet de vérifier qu'il n'y a pas d'ImportError ou autres. Pensez à le faire dans le virtualenv.

Erreurs web

Pour checker les changements il suffit de taper l'url du site pour constater en direct les changements. Si jamais il y a un souci il y a deux emplacements pour les logs : /var/log/uwsgi/nom_binet ou /hosting/log/nom_binet.

Troubleshooting

• Toutes les pages affichent Internal Server Error pas en gras : c'est une erreur de uwsgi qui n'arrive pas à :
  • trouver ton site
  • trouver le virtualenv
  • une exception est levée au démarrage du serveur (ImportError notamment).

Tu peux lire les logs dans /var/log/uwsgi/<ton binet>/<ton site>.log et vérifier où uwsgi va chercher ton site dans /etc/uwsgi.d/<ton site>.json. S'il faut modifier ce dernier fichier, demande-le au BR, tu ne peux pas le faire toi même.

• Toutes les pages affichent Internal Server Error(500) en gras : c'est django. Actives les mails pour avoir des détails, mais tu as probablement oublié de lancer les migrations sur une base sql vide.