Déploiement Django sur CentOS

a marqué ce sujet comme résolu.
Auteur du sujet

Salut à tous,

Il y a quelques temps j’avais demandé l’avis du forum sur comment déployer simplement une application Django (j’ai appris ici et j’ai donc finalement un projet concret et fini pour ma boîte) et j’ai eu pas mal de réponses qui m’ont beaucoup aidés surtout sur la solution Heroku.

J’ai tout déployé sur Heroku mais ma boîte, pour des raisons de sécurité des données et de RGPD souhaite que le site soit hebergé sur un serveur interne (pour la recette il n’y a pas encore de production envisagée).

C’est là que demarre mon problème :o

On m’a donc fourni une machine CentOS avec PostgreSQL installé dessus.

J’ai donc voulu suivre le tutoriel de Zds sur le déploiement (https://zestedesavoir.com/tutoriels/2213/deployer-une-application-django-en-production/) qui me semblait bien et clair et j’ai donc rencontré quelques souci

Tout d’abord j’ai remarqué que le Python par défaut de CentOS semblait être une version 2.X de Python j’ai donc installé une version 3.6 et modifié la commande python par défaut avec la commande suivante (trouvé sur un tutoriel en ligne sur le sujet :

sudo ln -fs /usr/bin/python3.6 /usr/bin/python

Cependant j’ai ensuite recontré des problèmes avec PIP et avec Yum et plusieurs personnes semblent expliquer sur Stackoverflow qu’il ne faut pas modifier l’alias "python" de CentOS au risque de rendre YUm et autre instable car ils utilisent Python 2

Pour revenir en arrière pas de souci on peut me remettre un snapshot du serveur antérieur

Ce qui m’amène a ma question Sachant que je ne connais que trop mal Linux, que je ne connait RIEN a CentOS et que je n’ai pas le choix que de déployer sur ce serveur : Comment procéderiez-vous, pour aller au plus simple, sachant que de toute façon je vais avoir besoin de Python 3 ?

  • Dois-je passer par un environnement virtuel ?
  • Dois-je changer un truc dans mon code de site Django pour pallier au problème du python par défaut ?
  • Est-ce dans la configuration de GUNICORN / WSGi(celle du tuto ZDS) que je devrais changer quelque chose pour que cela tourne comme un charme sur CentOS ?

Ma question est peut-être un peu bête et je m’en excuse mais la je suis complètement paumé et malheureusement je suis laissé en solo sur ce sujet par ma boîte.

Merci à tous par avance ;)

Édité par alliocha1805

+0 -0

Cette réponse a aidé l’auteur du sujet

Salut,

En effet, modifier la version Python par défaut du système est une très mauvaise idée ! Ce qu’on fait pour Zeste de Savoir (qui est codé avec Python 3 et Django 2.2) c’est simplement d’installer Python 3, créer un environnement virtuel avec Python 3, installer les dépendances dans cet environnement virtuel et enfin lancer Gunicorn depuis l’environnement virtuel ({{ virtualenv }}/bin/gunicorn, voir le fichier). Normalement si ton projet est développé en Python 3, il n’y a rien d’autres à faire. :)

Édité par Situphen

Corruptible avec des crêpes au sirop d’érable

+4 -0

Cette réponse a aidé l’auteur du sujet

Salut,

Utiliser un environnement virtuel est de loin la solution la plus propre.

Pour être complet cependant, de manière générale pour tes propres applications tu t’en fous en fait de quelle version est celle par défaut (et effectivement, il ne faut pas la changer puisque d’autres paquets dépendent de ce comportement). Si tu veux explicitement utiliser Python 3, tu peux utiliser la commande python3 qui vient avec n’importe paquet Python 3 correctement fichu. Et bien sûr, dans les scripts exécutables tu peux dire au shell d’utiliser Python 3 avec le shebang #!/usr/bin/env python3.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+4 -0
Auteur du sujet

Je reviens vers vous déjà pour vous remercier pour l’idée de l’environnement virtuel ca fonctionne nickel en mode gunicorn simple

Par contre en suivant le guide Zds que j’avais deja linké je me retrouve bloqué à l’etape supervisord

J’ai installé supervisord pour centOs7 en suivant cette procédure : https://cloudwafer.com/blog/how-to-install-and-configure-supervisor-on-centos-7/

J’ai ensuite configuré le fichier de conf de mon appli comme dans le tuto en le déposant bien dans /etc/supervisor/conf.d/ :

[program:collabio] environment=DJANGO_SETTINGS_MODULE=’settings’ directory=/root/DCTHEMIS/DCThemis/collabio/ command=/root/DCTHEMIS/DCThemis/collabio/bin/gunicorn —bind unix:/tmp/gunicorn.hello.sock —bind [Ip de mon serveur que je cache]:8001 —workers 4 —log-file /var/log/gunicorn.hello.log collabio.wsgi:application autostart=true autorestart=true stdout_logfile=/var/log/hello.log stderr_logfile=/var/log/hello.err.log

Cependant je ne peux pas utiliser les commandes suivantes :


sudo supervisorctl reread
sudo supervisorctl update

Car cela me retourne une erreur Python 2 :

error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib64/python2.7/socket.py line: 224

Je me suis donc dit que sur centos il fallait que je passe par systemctl comme indiqué dans le tuto de cloudwafer

Je peux lancer sans probleme mon supervisor en suivant leur procédure:

sudo systemctl start supervisord
sudo systemctl enable supervisord

Si je fais un status je vois :


● supervisord.service - Process Monitoring and Control Daemon
   Loaded: loaded (/usr/lib/systemd/system/supervisord.service; enabled; vendor preset: disabled)
   Active: active (running) since mer. 2020-06-03 11:07:17 CEST; 4min 20s ago
 Main PID: 13820 (supervisord)
   CGroup: /system.slice/supervisord.service
           └─13820 /usr/bin/python /usr/bin/supervisord -c /etc/supervisord.conf

Par contre quand je veux start mon appli avec la commande :

sudo systemctl start supervisord collabio

J’ai l’erreur suivante :

Failed to start collabio.service: Unit not found.

J’ai tenté de reload les deamons de systemctl dans le doute : sudo systemctl daemon-reload

Mais ca n’a rien changé.

Pourtant je ne vois pas d’erreur dans mon fichier de conf (pris dans le tutoriel Zds et modifié pour mon appli)

+0 -0

Cette réponse a aidé l’auteur du sujet

Alors je ne connais pas Supervisor donc je ne pourrais pas t’aider à résoudre ce soucis, mais je me demande pourquoi tu n’utilises pas systemctl directement ? C’est ce qu’on fait pour ZDS (voir le fichier). Bien sûr tu n’es pas obligé de faire pareil, mais je ne vois pas l’utilité de rajouter une couche. :)

Corruptible avec des crêpes au sirop d’érable

+0 -0
Auteur du sujet

J’ai juste voulu suivre le tuto qui semble utiliser supervisord vu que j’ai absolument aucune idée de ce que je fait xD

Tu saurai ou je pourrai apprendre a m’en servir sans me fader toute la doc ou je risque de rien comprendre ? (vu que le tuto officiel sur Zds semble pas s’en servir :( )

+0 -0

Cette réponse a aidé l’auteur du sujet

C’est assez simple :

  • Tu copies zds.service (lien) et zds.socket (lien) dans /etc/systemd/system
  • Tu remplaces les renomme comme tu veux et remplace {{ variable }} dans le fichier avec tes valeurs à toi
  • Tu actives le service avec sudo systemctl enable mon-fichier.service
  • Tu le lances avec sudo systemctl start mon-fichier.service
  • Tu peux voir son status (quelques lignes de logs) avec sudo systemctl status mon-fichier.service
  • Tu peux l’arrêter avec sudo systemctl stop mon-fichier.service
  • Tu peux le redémarrer avec sudo systemctl restart mon-fichier.service
  • Tu peux voir les logs complets à partir de la fin avec sudo journalctl -e -u mon-fichier.service

Je n’ai personnellement jamais eu besoin de plus pour Zeste de Savoir :)

Pour information, dans notre configuration nginx (lien) on a ceci :

upstream zdsappserver {
    server unix:{{ rundir }}/gunicorn.sock fail_timeout=0;
}

puis plus loin :

proxy_pass http://zdsappserver;

Édité par Situphen

Corruptible avec des crêpes au sirop d’érable

+1 -0
Auteur du sujet

C’etait la bonne piste Merci beaucoup j’ai presque tout bouclé :)

Je reste juste bloqué sur Nginx :

J’ai tout configuré mais j’ai une erreur "[crit] 1830#0: *1 connect() to unix:/root/DCTHEMIS/run/collabio.sock failed (13: Permission denied) while connecting to upstream" dans les logs Nginx (et une belle 502 sur mon serveur)

Voila mon fichier de conf Nginx :

server {
    listen 80;
    server_name [url du serveur cachée pour le forum] fail_timeout=0;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /root/DCTHEMIS/DCThemis;
    }
    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://unix:/root/DCTHEMIS/run/collabio.sock;
    }
}

Voila ma config gunicorn :

[Unit]
Description=gunicorn daemon
After=network.target

[Service]
User=root
Group=root
Environment=SECRET_KEY=[cle secrete cachée pour ZDS]
WorkingDirectory=/root/DCTHEMIS/DCThemis
ExecStart=/root/DCTHEMIS/bin/gunicorn --access-logfile - --log-level debug --workers 4 --bind unix:/root/DCTHEMIS/run/collabio.sock collabio.wsgi:application --bind [ulr serveur cachée]:8001

[Install]
WantedBy=multi-user.target

Ce que je ne comprend pas c’est que mon service gunicorn fonctionne bien donc je peux accéder a mon site http://urlserveur:8001 (le port que j’ai choisi pour gunicorn pour ne pas prendre le 8000 de dev) Mais nginx semble ne pas pouvoir accéder au fichier de socket ce qui me semble bizarre sachant que le seul user du serveur est l’user root.

J’ai vu des solutions demandant de mettre les droits 775 sur le socket ce que j’ai fait mais pas de changement :o

J’ai aussi testé en mettant des droits 666 au fichier de socket

Édité par alliocha1805

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte