« Tuto pour le déploiement des sites Django » : différence entre les versions

De WikiBR
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 1 : Ligne 1 :
==Comment déployer un site Django sur le serveur kevarzh ? ==
== Connexion ==


Tout d'abord il faut se munir de ces identifiants frankiz. Ensuite vous ouvrez votre terminal et vous vous connectez sur le serveur avec la commande ssh.
Assurez vous tout d'abord d'être administrateur de votre binet. Il faut attendre au moins une heure pour que les modifications soient prises en compte.
*Il faut donc taper : ssh prenom.nom@129.104.201.52
Une fois que vous avez tapé votre code, vous arrivez sur le serveur dans un dossier à votre nom. Il y a un fichier README.txt qui devrait donner un certain nombre d'informations sur le fonctionnement de kevarzh ou encore sur certaines modifs à faire sur le code de votre site. Vous pouvez vous diriger sur le serveur par les commandes habituelles. Votre dossier personnel se trouve dans /hosting/user/prenom.nom. Pour accéder aux sites binets il faut aller dans hosting/www/nom_binet. (Tout cela est indiqué dans README).


Une fois dans ce dossier il y a peut-être plusieurs dossiers qui correspondent aux différentes versions du site de votre binet. Vous créez un dossier au nom de votre version de site. C'est donc dans ce dossier que vous allez pouvoir copier le code de votre site.
Ensuite vous ouvrez votre terminal et vous vous connectez sur le serveur avec la commande ssh.
* Pour copier le code : scp -r /code_site prenom.nom@129.104.201.52:/hosting/wwww/nom_binet/version_site
ssh prenom.nom@129.104.201.52


Attention ! L'espace réservé à chaque binet est limité dans il faut se méfier quand on fait une copie, notamment a l'environnement virtuel. D'abord il pèse lourd, en plus il faudra que vous le remplaciez de toute façon. Autant ne pas le copier dès le départ...
Une fois que vous avez tapé votre mot de passe frankiz, vous arrivez sur le serveur dans un dossier à votre nom. Il y a un fichier {{c|README.txt}} qui devrait donner un certain nombre d'informations sur le fonctionnement de kevarzh ou encore sur certaines modifs à faire sur le code de votre site. Vous pouvez vous diriger sur le serveur par les commandes habituelles. Votre dossier personnel se trouve dans {{c|/hosting/user/prenom.nom}}.  


Une fois que vous avez fait ça, vous pouvez essayer de recréer l'environnement virtuel.
Si jamais vous voulez lancer une commande ayant besoin d'internet (par exemple des commandes git) n'oubliez pas de mettre {{c|proxychains}} devant votre commande.
* Pour cela : virtualenv -p /usr/bin/python3 venv
Il est important que vous nommiez le dossier venv.


Ensuite vous allez pouvoir passer aux modifications du code pour déployer le site. Il y a une bonne checklist à vérifier qui nous est proposée par le site django : [https://docs.djangoproject.com/fr/1.10/howto/deployment/checklist/]. La, 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 : DEBUG, SECRET_KEY, ALLOWED_HOST, STATIC_ROOT,STATIC_URL, MEDIA_ROOT et MEDIA_URL. C'est à chaque fois des modifications dans le fichier settings.py.
== Copie des fichiers ==


Pour la partie media et static, les codes à indiquer sont dans le README.txt. Si vous avez compris ces codes vous voyez qu'il faut créer un dossier assets dans lequel on mettre les fichiers static et les media. Pour les fichiers static on utilise la commande collectstatic.
Le dossier {{c|/hosting/www/nom_binet}} contient (au moins) un dossier par site. Si vous n'avez qu'un site, le dossier par défaut est {{c|htdocs}}. C'est dans un de ces dossiers que vous allez devoir copier le code de votre site.
Dans le README il est aussi fait mention de lignes à ajouter pour recevoir des emails quand il y a de erreurs.  
scp -r /code_site prenom.nom@129.104.201.52:/hosting/wwww/nom_binet/version_site


A chaque fois pour tester vos changements sur le code il faut enregistrer la modification.
*Avec le code : touch /var/run/please/restart
Il faut attendre 1 ou deux minutes que le système enregistre la modification, quand c'est fait il affiche un message dans le terminale.
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.


Une fois que vous avez tout fait et que votre site fonctionne c'est que tout est bien dans le meilleur des mondes.
== Quotas ==


Si jamais vous voulez lancer une commande depuis le serveur (par exemple des commandes git) n'oubliez pas de mettre proxychains devant votre commande.
Attention ! L'espace réservé à chaque binet est limité. Il faut se méfier quand on fait une copie, notamment a l'environnement virtuel. D'abord il pèse lourd, en plus il faudra que vous le remplaciez de toute façon. Autant ne pas le copier dès le départ...
Pour savoir si vous avez dépassé votre quota :
quota -sg
Cette commande affiche, pour chaque binet, l'espace utilisé, une «soft limit» et la vraie («hard») limit.
 
== Virtual environment ==
 
Une fois que le code du site est en place, il faut recréer l'environnement virtuel.
virtualenv -p /usr/bin/python3 venv
Il est important que vous nommiez le dossier {{c|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
 
Une fois dans le venv, vous pouvez installer les dépendances nécessaires :
proxychains pip install -r requirements.txt
 
== Adaptations ==
Certaines adaptations sont nécessaires pour faire fonctionner le site. La documentation officielle de Django fournit une bonne [https://docs.djangoproject.com/fr/1.10/howto/deployment/checklist/ 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 {{c|DEBUG}} à {{False}}
* {{c|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 {{c|secret.key}} (généré automatiquement s'il n'existe pas) qu'il suffit de mettre dans le {{c|.gitignore}}.
 
* Mettre {{c|ALLOWED_HOST}} à {{c|["*"]}}, 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 {{c|my.cnf}}:
[client]
database = NAME
user = USER
password = PASSWORD
default-character-set = utf8
 
Bien sûr il faut ajouter ce fichier dans le gitignore.
 
== À chaque modifications... ==
* du schéma SQL:
python manage.py migrate
* des fichiers statiques:
python manage.py collectstatic
* du code python quel qu'il soit :
touch /var/run/please/restart
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'{{c|ImportError}} ou autres.
=== 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 : {{c|/var/log/uwsgi/nom_binet}} ou {{c|/hosting/log/nom_binet}}.

Version du 19 octobre 2016 à 18:13

Connexion

Assurez vous tout d'abord d'être administrateur de votre binet. Il faut attendre au moins une heure pour que les modifications soient prises en compte.

Ensuite vous ouvrez votre terminal et vous vous connectez sur le serveur avec la commande ssh.

ssh prenom.nom@129.104.201.52

Une fois que vous avez tapé votre mot de passe frankiz, vous arrivez sur le serveur dans un dossier à votre nom. Il y a un fichier README.txt qui devrait donner un certain nombre d'informations sur le fonctionnement de kevarzh ou encore sur certaines modifs à faire sur le code de votre site. Vous pouvez vous diriger sur le serveur par les commandes habituelles. Votre dossier personnel se trouve dans /hosting/user/prenom.nom.

Si jamais vous voulez lancer une commande ayant besoin d'internet (par exemple des commandes git) n'oubliez pas de mettre proxychains devant votre commande.

Copie des fichiers

Le dossier /hosting/www/nom_binet contient (au moins) un dossier par site. Si vous n'avez qu'un site, le dossier par défaut est htdocs. C'est dans un de ces dossiers que vous allez devoir copier le code de votre site.

scp -r /code_site prenom.nom@129.104.201.52:/hosting/wwww/nom_binet/version_site


Quotas

Attention ! L'espace réservé à chaque binet est limité. Il faut se méfier quand on fait une copie, notamment a l'environnement virtuel. D'abord il pèse lourd, en plus il faudra que vous le remplaciez de toute façon. Autant ne pas le copier dès le départ... Pour savoir si vous avez dépassé votre quota :

quota -sg

Cette commande affiche, pour chaque binet, l'espace utilisé, une «soft limit» et la vraie («hard») limit.

Virtual environment

Une fois que le code du site est en place, il faut recréer l'environnement virtuel.

virtualenv -p /usr/bin/python3 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

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

proxychains 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 :

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.

À chaque modifications...

  • du schéma SQL:
python manage.py migrate
  • des fichiers statiques:
python manage.py collectstatic
  • du code python quel qu'il soit :
touch /var/run/please/restart

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.

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.