Bonjour Cyril, Merci pour le retour d'expérience!
Je n'ai pas encore testé dokku, mais effectivement c'est une piste intéressante je vais aller relire un peu de doc sur le sujet. La question qui me vient tout de suite pour Dokku, vu l'idée que j'ai, je me retrouve dans mon app avec un nombre de remote équivalent à mon nombre de clients/serveur sur lesquels je déploie? Pour le scalling la question ne se pose pas vraiment, car le nombre de connexions par serveur est relativement faible. Pour l'image de base phusion je ferai un essai aussi pour voir ce que cela donne, mais pour le moment j'aime jouer avec Puma. Passenger m'avait donné du fil à retordre à une époque où je jouais avec Scheduler pour faire des tâches récurrentes et passenger avait du mal à rester ... disons éveillé ce qui compliquait la tâche. L'analogie que j'utiliserai pour décrire l'idée sur laquelle je me penche serait Wordpress.com dans sa forme la plus simple. C'est-à-dire une plateforme où chaque client reçoit sa version de l'app, sa base de données et se connecte avec son sous-domaine. Dans tous les cas merci pour les réponses cela me donne d'autres horizons! Le dimanche 7 février 2016 06:59:09 UTC-5, Cyril Mougel a écrit : > > Bonjour, > > J'ai migré une partie de l'infrastructure de Teezily vers du docker. > L'utilisant en développement je me suis dis que le plus simple serait de > l'utiliser pour déployer. Au final, j'ai trouvé que la meilleur infra pour > moi c'est tout simplement dokku ou deis. Ces deux projets savent très bien > déployer des containers docker et pour deis, Il n'y a pas de soucis pour > scaler horizontalement. Le déploiement s'en trouve très simplifié car c'est > un simple git push. Pour provisionner mes serveurs je n'ai plus qu'à setup > les variables d'env de mes projets ce que je fais avec ansible. > > Côté persistance je suis par contre resté sur du classique car on ne peut > pas vraiment scaler plusieurs containers sur le même volume. > > Enfin côté docker, j'ai opté pour la base image phusion de ruby pour avoir > un nginx, mes workers et cron directement dans mon container. Chacun étant > activable par variable d'env pour ainsi déployer des versions limités. > Le 6 févr. 2016 20:12, "Antoine" <antoine...@gmail.com <javascript:>> a > écrit : > >> Bonjour, >> >> Je suis à la recherche de documentation ou de conseils, je n'arrive pas à >> me faire une idée claire seul de mon côté! >> >> Généralement je mets au point des projets Rails disons assez classiques >> et je les déploie avec Mina qui est super léger. >> Je me suis plongé dans docker et maintenant le schéma classique ressemble >> à une série de containers: >> - nginx >> - rails >> - postgres >> - redis >> - ... >> Avec des volumes persistants pour les datas. >> Le tout est assez facile à déployer et à maintenir pour un serveur/client >> pour son projet. >> >> Une demande revient régulièrement chez mes clients et je réfléchis à la >> façon de rendre cette production plus générique. >> >> Voici ce que je cherche à faire/comprendre: >> >> Après le débat multi-tenant vs multi-instances, imaginons une application >> type et pour chaque client un 'micro serveur' qui fait tourner les >> containers. >> Chaque client est isolé, mais a la même copie de l'application. Chaque >> client se connecte par un sous-domaine qui lui est attribué. >> Les questions que je n'arrive pas à clarifier sont celles liées au >> déploiement et à la mise à jour d'une telle infrastructure. Comment >> automatiser ces tâches sachant que le nombre de clients va varier en >> fonction de l'attrait pour l'application et pourrait atteindre un nombre >> trop important pour être déployée "manuellement". >> >> On trouve pas mal de documentation sur la question du multiserveur pour >> des applications de grosse taille avec par exemple une configuration >> décrite dans le fichier docker-composer avec plusieurs serveurs qui vont >> communiquer entre eux. Mais dans le cas décrit ci-dessus avec >> potentiellement un grand nombre de serveurs on ne peut pas se permettre >> d'avoir un fichier yml qui fait des milliers lignes en fonction du nombre >> de clients. >> D'autre part si on automatise la tâche avec mina ou capistrano le temps >> de déploiement d'un tel parc peut être très long et le risque d'erreur est >> à prendre en considération. >> >> Est-ce que ce type d'architecture est une idée viable et maintenable, >> est-ce une mauvaise direction et devrais-je plus réfléchir sur un modèle? >> Bref comment automatiser la mise en place d'une application similaire qu'on >> installe pour un grand nombre de clients? >> >> Je suis preneur d'idées ou de lecture sur ce type de question. >> >> D'avance merci pour les idées! >> >> -- >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >> de Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >> rails...@googlegroups.com <javascript:> >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> railsfrance...@googlegroups.com <javascript:> >> --- >> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes >> "Railsfrance". >> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >> concernant, envoyez un e-mail à l'adresse railsfrance...@googlegroups.com >> <javascript:>. >> Pour obtenir davantage d'options, consultez la page >> https://groups.google.com/d/optout. >> > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
