Open ThierryM opened 4 years ago
Bonjour @ThierryM
En effet, bonne idée, ça serait pas mal que Pytition soit plus facile à installer via des initiatives comme YunoHost, Cozy Cloud ou Softaculous. Je garde l'idée, si quelqu'un-e est volontaire pour le faire je suis totalement disponible pour l'aider. Ça n'est pas dans mes priorités ceci-dit donc je ne vais pas m'y lancer moi-même tout de suite. Mais c'est clairement quelque chose qui peut être contribué par quelqu'un-e :)
Docker répond clairement à ce type de besoin, auquel il me paraît effectivement essentiel de répondre pour simplifier le déploiement du logiciel et donc le populariser.
Une partie du travail semble avoir été réalisé avec un Dockerfile, je pense qu'il serait utile de fournir également une image Docker déjà construite, par exemple via Docker Hub.
Salut @johanricher , en effet Docker aide. Mais Docker ça n'aide que les développeurs ou devops. Pour les non-informaticiens l'intégration dans un autre outil est utile je pense. Mais oui, Docker c'est un outil sur lequel je pense qu'il faut investir pour faciliter l'installation. Tu peux créer un ticket pour la création d'une image Docker Hub stp ? Merci :)
Salut, ok oui je vais créer un ticket. :+1:
Docker ça n'aide que les développeurs ou devops.
Pouvoir installer le logiciel sur n'importe quel OS avec une seule commande, ça aide tout le monde.
J'en ai personnellement fait l'expérience en facilitant l'installation d'un logiciel Java sur Windows avec un simple double-clic sur un fichier .bat.
:point_right: http://commons.digitaltransport.io/conveyal-analysis-docker/
Hello !
Je me permets un petit commentaire sur docker en tant qu'outil pour déployer une application web sur un serveur exposé sur les z'Internet, ayant pour ma part eu une très mauvaise expérience avec..
Il faut savoir qu'hoster un truc avec docker, c'est lui permettre de bidouiller iptables pour faire absolument ce qu'il veut (ça parait assez évident quand on considère ce qu'il est capable de faire, mais je ne m'étais jamais posé la question avant d'y être confronté)
Ce qui revient donc à perdre complètement la maitrise sur son firewall, ce qui est un peu problématique
Si je me souviens bien, la manière la plus sure de prévenir ça est lui clouer le bec, mais alors il faut créer soi-même les règles qui vont bien (ce qui fait perdre beaucoup de son coté pratique à Docker, et devient assez compliqué quand on a des containers qui doivent discuter entre eux, par exemple)
Je crois qu'il y a des moyens moins radicaux d'aboutir au même résultat, mais n'étant pas expert iptables
(et n'ayant pas eu envie de le devenir), j'avais rapidement capitulé
... bien sûr, j'ai appris tout cela à mes dépends, le jour où j'ai réalisé que la base PostgreSQL qui tournait dans son petit container (qui communiquait avec un autre container contenant mon appli) avait son port ouvert à toute la planète, qui ne s'était pas privée de venir l'attaquer pour me rançonner :eyes:
Je vois que Pytition a un petit docker-compose avec une image postgres, et j'imagine bien qu'une configuration retenue pourrait être exactement celle que j'avais mise en place moi-même (un container appli avec un Dockerfile "maison" en réseau avec un container database avec une image officielle de postgres, mysql, mariadb ou autre), alors je préfère prévenir ^^
Pour ma part, je n'avais strictement rien à faire des données que j'ai perdues, mais j'imagine que ce ne sera VRAIMENT pas le cas de ceux qui utilisent Pytition
TL;DR Docker c'est cool sur une machine isolée, mais avant de le mettre sur un serveur, il faut VRAIMENT savoir ce que l'ont fait :disappointed:
Je partage un peu l'avis de @theenglishway . J'ai l'impression que Docker c'est bien pour "tester" une application, voir pour développer et itérer (j'utilise docker-compose pour itérer et faire tourner mes tests).
Mais je pense que ça n'est pas une bonne idée d'utiliser Docker en production. Sauf a vraiment vraiment savoir ce qu'on fait, mais du coup Docker a moins d'intérêt. Si l'idée est de permettre à des "novices" d'installer, je pense que ça n'est pas leur faire un cadeau car Docker a pas mal de soucis côté sécurité.
Surtout quand on commence à fournir des images Docker Hub. J'ai lu une étude sur le contenu des images Docker pré-construites. Un grand nombre contiennent un ou plusieurs paquet ayant des CVE connues. Pour info :
PS : tout ça ne veut pas dire que je ne veux pas d'image Docker ou de Dockerfile pour Pytition. Juste que je pense que je ne les mettrai pas en avant dans la future documentation comme les meilleurs moyen pour mettre Pytition en production.
Intéressant.. Cela dit, je ne sais pas quel crédit accorder à un chiffre brut de CVE, vu que la fiabilité des rapports a l'air pour le moins.... aléatoire (en particulier vis-à-vis des projets open source), cf par exemple ce thread récent de l'équipe (^^) Videolan à propos d'une CVE sur VLC qui leur avait valu une grosse exposition médiatique : https://twitter.com/videolan/status/1153963312981389312
Pour revenir sur le sujet du déploiement, est-ce que ça ne faciliterait pas grandement les choses de passer sur du SQLite ?
Suite à notre discussion de l'autre jour, @fallen, j'avais été jeter un œil à la doc' et en fait, bah... c'est beaucoup, beaucoup moins limité que ce que je pensais (je crois qu'on peut meme dire : "pas du tout limité") : https://www.sqlite.org/fullsql.html
Il y a juste quelques petits trucs relous, genre le support incomplet des ALTER TABLE (mais il me semble que ça n'empeche pas Django de faire sa tambouille sur les migrations) ou qqes features désactivées par défault "for legacy reasons", comme les contraints Foreign Key, qui s'activent avec une directive pragma
(l'ensemble de la documentation est hyper impressionnant, leurs méthodes de développement aussi)
Bref, c'est peut-être une voie à considérer, si "être plus facile à déployer" devient un critère important
Hello,
Juste un mot sur docker, en effet le but du Dockerfile actuel est surtout pour faciliter la contribution au développement, pas à des fins de mise en production (en tous cas quand je l'ai fait c'était l'idée, n'étant pas Devops, et donc c'est clairement perfectible :) )
Pour la base de données, je serais plus pour conseiller plutôt PostgreSQL que Sqlite ou MySQL, ou du moins par défaut, car ça me paraît plus sécurisé. À ça s'ajoute la difficulté de maintenir plusieurs systèmes de bases de données : lorsqu'on souhaite utiliser des fonctionnalités particulières de l'une non disponible sur l'autre, ça devient difficile de maintenir la compatibilité. [edit] À propos de plus facile à déployer, les hébergeurs proposent au moins une base MySQL, voire PostgreSQL.
+1 pour faciliter l'installation facile sur des hébergements mutualisés. As tu réussi @ThierryM finalement ? Déjà ce serait bien d'améliorer la doc d'install en donnant plus d'informations sur chacune des étapes.
Est-ce qu'on peut / Quelqu'un a t il installé / pytition sur un mutu OVH pro par exemple ?
Pour le moment, l'offre OVH pro ne semble pas proposer de python, seulement php. Et sinon il y a les offres cloud web qui proposent du python. À voir aussi tout le comparatif.
Sisi sur les mutu pro actuellement proposés, il y a Python (cgi) (il faut cliquer "voir plus"). Là j'ai un mutupro2010 différent de ceux proposés actuellement, mais il y a bien SSH et python. Par contre il n'y a ni pip ni virtualenv ce qui m'empêche de suivre l'install proposé pour pytition.
Par contre il y a git. J'ai donc git cloné pytition et django mais après je bloque. J'ai une longue expérience de dev php notamment, mais juste une mini expérience avec python. Je ne connais pas django et rien de son système de plugins et de l'environnement python. Le récit de ce que j'ai fait pour l'instant : http://pastebin.fr/61706 Sans procédure standard basique accessible ou automatisée je vais galérer à l'aveuglette...
PS : Je vois que c'est python2.7 . Je suis un peu comme http://community.ovh.com/t/installer-un-site-django-python-3-sur-un-herbergement-mutualise/5383/12 Il y est dit qu'on peut activer python3 et effectivement j'ai pu le faire en suivant les indications, mais « OVH indique que Python3 n'est supporté qu'en mode 'ligne de commandes' » ce qui fait qu'une fois installé par SSH, ça pourra pas servir pour http...
En attendant, quel seraient des hébergements standards plutôt minimaux proposés clé en main par des prestataires et permettant de "simplement" suivre les instruction actuellement proposées pour installer pytition ?
Pour créer virtualenv, tu peux essayer d'utiliser maintenant venv:
python3 -m venv venv
Mais si setuptools n'est pas installé, pas sûre que ça fonctionne.
PS : Mince c'est vraiment python2.7 ? Étonnant que python3 ne soit pas installé, on est en 2020 et python2 n'est plus supporté depuis janvier dernier. Mais bon, on sait jamais :)
Pour OVH, il faut attendre un peu, d'après ce que je sais d'une personne qui y travaille, les offres de Webhosting vont évoluer.
Pour les autres hébergements, j'ai regardé suuuper rapidement, à première vue tout le monde est pareil : infomaniak, hertzner ont bien du python, mais seulement en CGI : pas sûre qu'il y ait du WSGI. Sinon il y a les plateformes PAAS comme Heroku ou Clever cloud. Mais je ne suis pas admin sys, quelqu'un aura un avis plus éclairé que moi sur la question :)
As tu réussi @ThierryM finalement ?
@JLuc , désolé mais je ne suis pas allé plus loin (manque de compétences). Pour info, même problème pour déployer un Framaforms même si là ça semble plus abordable (https://framacolibri.org/t/framaforms-probleme-installation/7288)
ok merci @ThierryM @numahell j'ai complété mon post précédent car en fait on peut bien activer python3 mais seulement en ligne de commande semble t il, càd c'est pas accessible depuis le web.
Sur gandi simple hosting ça a l'air possible avec un Simple Hosting python. J'ai ouvert une instance gratuite pendant un mois pour essayer. C'est bien python 3 et il y a bien virtualenv et pip3 donc on se rapproche du scénario proposé. Il y a des différences : pas de répertoire www mais un web/vhosts/default par exemple ... alors j'ai adapté.
Il faut descendre dans default avant de lancer virtualenv car vhosts n'est pas écrivable.
Par contre il y a plein d'erreurs de droits d'écriture lors de l'install : PermissionError: [Errno 13] Permission denied: '/srv/data/var/log/www/pip.log'
Il faudrait paramétrer le logging...
Quelqu'un a-t-il réussi à installer pytition sur un hébergement o2switch ?
J'ai presque réussi à tout installer via le Setup Python App de cPanel et mais impossible d'accéder à static et mediaroot. On ne peut pas accéder à la configuration Apache ... Du coup, c'est mort ?
Bonjour @iomago, si on ne peut pas personnaliser le contenu du fichier de conf Apache/Nginx je pense que ça n'est pas possible. J'ai trouvé cependant un tuto qui a l'air d'expliquer comment déployer une application Django (Pytition est une appli Django) dans cPanel : https://ngangasn.com/deploy-django-on-shared-hosting-ultimate-guide-to-hosting-django-on-cpanel/ Je n'ai pas testé mais ça a l'air d'être une piste à explorer :)
Merci, je vais explorer ça.
@iomago top, n'hésite pas à venir poster ici le résultat de ton test, que ça soit positif ou négatif :) Ca m'intéresse ! Merci !
Bonjour, Je suis gestionnaire de quelques sites Internet pour des associations sur des serveurs mutualisés (où on n'a pas le loisir d'installer ce que l'on veut). Souvent, je rajoute des applications web (Framadate, LimeSurvey, ... par exemple) car les hébergeurs proposent l'outil Softaculous. L'inconvénient avec cette méthode, c'est qu'on est tributaire de Softaculous qui doit rajouter l'application désirée dans son catalogue. J'ai aussi installé des applications comme SACoche (en suivant cette procédure simplifiée) en téléversant les fichiers de l'application dans un dossier du serveur et lors de la première connexion, on indique les paramètres nécessaires à l'installation. C'est vraiment très pratique et accessible. Bref, pour démocratiser Pytition, une installation automatisée serait vraiment un plus. De plus, ça permettrait de tester sur son propre hébergement. En vous remerciant pour votre travail et votre partage, cordialement,
Thierry