Déploiement Django sur CentOS

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

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

Ok je vais apprendre a utiliser des virtualenv alors

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)

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 )

Ok merci je vais tester ca demain

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

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