Github c'est génial, ne serait-ce que pour documenter son code (en commençant par un bon vieux README) avec des fichiers markdown.

Ensuite, tu peux utiliser dploy qui récupère ton repo git tel qu'il est et qui ne déploie sur une machine (de préprod, de prod) que le delta des modifications.

Et si tu décides de faire les choses proprement, tu passes par des VM et Vagrant. Après avoir configuré ton vagrantfile, un petit "vagrant up" et tu as sur ton poste la stack technologique cible, et donc 1/ tu éviteras des bugs qui dépendent de l'os, des librairies, etc.. et 2/ tu peux multiplier sur ton poste de dev les projets dans des technos différentes, en faisant à chaque fois des vm étanches (et 3/ n'importe quel autre développeur peut récupérer exactement le même environnement que toi).

Je crois que Docker va un cran plus loin (et est plus performant puisqu'on évite un superviseur et une installation d'os nécessaire dans le cas des vm) mais j'avoue que ça donne encore plus de liberté (et de migraines) et de choix sur la granularité du container : dois-je faire un méga container ou plein de petits pour simuler toutes les briques de mon serveur de prod?

Vagrant, c'est un peu l’artillerie lourde, je trouve. Je l'avais utilisé brièvement pour tester 2-3 choses avec Django (et plus particulièrement, avec le CMS Wagtail). J'ai l'impression que ça peut être très utile, mais pas "tout le temps", seulement pour des projets nécessitant des composants lourds assez nombreux. Docker a cet avantage : même pour un "petit projet", ça ne semble pas bien complexe (ni lourd) à mettre en place. Cela dit, Vagrant a au moins l'(énorme) avantage d'être simple à manipuler (je trouve) et de garantir une parfaite isolation. D'ailleurs, ça doit sans doute être bien galère pour transformer correctement une application (au sens large) en une série de micro-services.

Je vais regarder du coté de dploy, je ne connaissais pas.

Je n'ai jamais testé Heroku, mais je m'amuse avec Openshift, le «Heroku-de-Red-Hat» qui est également un cloud PaaS, avec la possibilité de faire tourner gracieusement de petites applications.

Ce qui te permet donc de tester la Lexpage sans payer quoi que ce soit et en estimant les volumes de données.

C'est hébergé chez AWS et tu as un principe de «gears» (et 3 gears gratos avec chaque compte) qui te permettent une certaine quantité de ressources (et c'est pas ridicule).

Il y a me semble-t-il tout ce qu'il faut pour pouvoir faire tourner son application, et mettre de la qualité dans son développement : Git bien sûr, Docker je crois, Jenkins, etc…

Pis c'est plein d'Open Source dans tous les sens.

Petit inconvénient tout de même, les serveurs AWS européens ne sont pas accessibles aux comptes gratuits et on est donc aux États-Unis…

OpenShift, c'est pas un peu l'artillerie lourde pour des petits projets ?

Jenkins, j'ai eu l'occasion de chipoter avec dans mon ancien job, et c'est bien que j'avais plein de raisons de quitter ce job, sinon il aurait aussi figuré sur la liste (en bas, tout en bas, mais tout de même)

Tu parlais d'Heroku, c'est un des concurrents...

Après est-ce que c'est l'artillerie lourde, je pense pas que ce soit trop gros pour toi.

Faut juste faire attention sur certaines applications, c'est un huile un peu particulier (du à la connexion à la bdd)

Ok, je suis passé sur leur site, je croyais que c'était une archi à mettre en place soi-même (j'ai juste eu écho de la version "professionnelle", je ne savais pas que ça proposait tout cela directement en ligne aussi).

Une idée des principales différences avec Heroku ?

GuybrushJenkins, j'ai eu l'occasion de chipoter avec dans mon ancien job, et c'est bien que j'avais plein de raisons de quitter ce job, sinon il aurait aussi figuré sur la liste (en bas, tout en bas, mais tout de même)

you are doing it wrong

J'ai pas compris si c'était sur la liste des trucs à tester ou sur la liste des raisons pour lesquelles il s'est barré.

Ah oui, openshift est effectivement installable sur son propre serveur, mais ça n'a aucun intérêt dans ton cas.

Et oui, sur openshift.com tu peux l'utiliser directement.

GuybrushUne idée des principales différences avec Heroku ?

Salesforce ou RedHat déjà... Je n'hésite pas dans un choix pareil.

J'suis passé faire un tour plus en profondeur sur Openshift...

Ok, le plan gratos est sympathique pour héberger 2-3 applications (max 3, de toute façon, je suppose que ça inclut à la fois la webapp et la db, donc il reste de la place pour un seul add-on). Dommage que les tarifs montent vite en flèche après (notamment au niveau des addons). Je me demande dans quelle mesure c'est financièrement plus (ou moins) intéressant qu'un dédié + une infra basée sur Docker (ou même sur OpenShift "local", tiens).

On en avait déjà parlé brièvement, mais est-ce que certains ici ont une expérience avec Docker ?

Je me suis tapé une large partie de leur documentation, et il est probable que je fasse mes premiers pas avec demain (j'ai un hexacore avec 32go de RAM qui me sert de serveur de test à l'unif, et le biologiste avec qui je travaille, qui est aussi un informaticien curieux, s'intéresse à Docker. C'est donc l'occasion de s'y mettre).

En particulier, une idée de la "difficulté" de migrer une infrastructure existante dans des containers ? Si mes essais s'avèrent concluants, je compte migrer Lexpage & co dans des containers... Mais j'ai encore un peu de mal à voir comment "tout doit être idéalement décomposé".

Notamment, sur le VPS, j'ai actuellement un Nginx, et 3 applications (enfin, 3 types d'applications) derrière : du Django (servi via Gunicorn en WSGI, via socket), du PHP (servi via FPM, je pense que c'est du wsgi aussi via socket) et du NodeJS (servi directement, Nginx ne sert que de proxy + fichiers statiques).

Est-ce qu'il vaut mieux :
- Un container par application, avec un Nginx "local" + un container "Nginx frontal" qui fait le dispatch ? Cela me permet d'avoir une application "auto-contenue" dans son container, mais nécessite un Nginx supplémentaire par application...
- Un container par application, avec un Nginx frontal dans un container, qui communique/redirige via socket (ou autre) avec les autres containers. Dans ce cas, le container "frontal" aura une connaissance plus complète des applications derrières (notamment pour servir les fichiers statiques). C'est une sorte de "clone mais sous container" de la configuration actuelle, mais cela signifie que mon frontal ne fait pas que du proxy, et qu'une partie de la "logique" de l'application (les fichiers statiques, typiquement, ainsi que l'upload, etc. etc.) ne se trouve pas dans le container de cette application. Vraiment, les fichiers statiques font un peu chier

Et aussi, est-ce qu'il est préférable de :
- Charger une image, et dans le container, faire la configuration puis sauver tout ça sous forme d'image (en gros, ça devient mon "environnement" que je peux cloner) ou;
- Créer un Dockerfile sur base d'une image existante et scripter la configuration là-dedans, afin d'avoir le "minimum" de modifications dans l'image de base ?

Le premier cas est plus simple (en gros, une sorte de VM). Le deuxième me semble plus propre, car l'image de base est conservée. L'avantage est qu'il est facilement possible de mettre à jour l'image de base sans perdre la configuration. Au final, de toute façon, les deux approches fournissent exactement la même image ...