Pour relativiser le propos, il faut faire la différence entre les infras que tu opères pour toi et celles que tu opères pour les autres.
Pour moi, dans mon coin faire du Docker/k8s pourquoi pas. Si ça pète c'est moi que ça regarde. Mais quand je dois opérer pour un autre avec des SLA et des avocats et que je lui dit que mes contraintes ne vont pas avec son contrat et ses SLA qu'il veut c'est plus pareil. Et sur l'idée même du conteneur fait par et pour les devs (alors que PXE install, Debian et [Ansible,Chef,Puppet] ça marche tres bien et vite) je dirai que si on en est au point de ne pas savoir faire causer les gens du dev et du systeme on a pas des problèmes de technologies mais des problèmes de communication interne. Et pour finir je citerai un philosophe : "YOU BUILD IT, YOU RUN IT" Cordialement Le 22 septembre 2017 à 10:39, Kirth Gersen <kger...@hotmail.com> a écrit : > Docker c'est relativement 'bas niveau' par rapport au besoin exprimé. > je partirai plutôt sur du Kubernetes (abrégé en k8s) ou au dessus > (OpenShift, Tectonic, etc). > Les 3 gros cloud providers du moment (Google GCP, Amazon AWS , Microsoft > Azure) ont des solutions k8s avec un net avantage a Google pour docker/k8s > (c'est la techno interne utilisé chez Google donc en terme de 'ca marche en > prod' c'est plus rassurant que chez Microsoft par exemple....) > > Mais être 'provider' agnostic ca ne va pas être forcement simple et > introduite une complexité plus grande que de modif le code en cas de > changement de provider. C'est l'avantage de k8s: c'est juste des fichiers > de conf a changer pour passer du stockage Google au stockage AWS par > exemple, le 'driver' de k8s s'occupe du reste. Avec la notion de namespace > (prod, preprod, dev) çà rejoint un peu le 'rêve' exprimé par l'OP. > > Et pour ce qui est des anti-Docker en prod, ils sont soient resté bloqués > quelques années en arrière soit leur job est menacé par ce genre de techno > donc leur propos sont a relativiser fortement :) > > > > Le ven. 22 sept. 2017 à 08:35, Stéphane Cottin <n...@vixns.net<mailto:noc@ > vixns.net>> a écrit : > Bonjour Gaël, > > Je peux te faire un retour d'expérience sur du docker en prod, ça > fonctionne très bien ... si tu n'utilises pas docker ( ça c pour > trolldi ) > > J'ai monté plusieurs archis avec Apache Mesos, qui te permet > d'instancier des containers à partir d'images docker sans avoir a > installer aucun outil docker. > Par rapport à la génération précédente (Mesos < 1.0) qui utilisait > le daemon docker, cela n'a plus rien à voir en terme de stabilité / > fluidité (plus de GC, tout est en c++) / consommation CPU "à vide" / > heures de support. > > ArangoDB dispose d'un framework Mesos, cela peut être une bonne > solution pour ton besoin. > > Stéphane > > On 21 Sep 2017, at 23:04, Gaël Demette wrote: > > > Bonsoir la liste, > > > > Aujourd'hui se pose la question de modifier notre infrastructure, > > actuellement exclusivement chez AWS (Ireland), en effet notre stack à > > la base assez simple commence à se complexifier avec nos évolutions > > à venir. Du coup, Elastic Beanstalk commence à ne plus être > > suffisant. On voudrait surtout en profiter pour abstraire le > > fournisseur de Cloud. Malheureusement, notre petite startup n'a pas le > > temps de faire tout cela, et souhaiterait étudier la possibilité > > d'externaliser ces évolutions. > > > > J'avais en tête de tout passer sur Docker. Il faudrait donc faire > > cette prestation, ainsi que nous former sur le fonctionnement de > > l'infrastructure faite. > > > > Stack actuel : > > > > * S3 pour deux applications EmberJS (SPA) > > * AWS Elastic Beanstalk (Avec nginx + NodeJS) -> Deux environnements, > > le premier l'API (REST et websockets), le second une app NuxtJS (SPA > > avec server-side rendering) > > * AWS ElastiCache (Redis) > > * Simple replicaset MongoDB (sur des EC2) > > > > Stack cible : > > > > * ArangoDB > > * RabbitMQ (non fixé, si vous avez des suggestions sur des > > alternatives, on est ouvert) > > * MongoDB (On ne souhaite pas tout migrer sur ArangoDB d'un coup sans > > plus de feedbacks) > > * Plus de EmberJS > > * Probablement plus de Redis (Pub/Sub couverte par RabbitMQ, key-value > > storage couvert par ArangoDB), ça ne me gène pas de rester sur > > ElastiCache le temps que nos devs fassent le nécessaire ;) > > * Trois environnements "AWS Elastic Beanstalk like", API + Website > > (NuxtJS) + Backoffice (Anciennement les deux apps EmberJS, > > nouvellement NuxtJS avec Server side rendering) > > > > Mon rêve serait d'avoir une infra qu'on puisse utiliser tant pour > > mettre en place des environnements à la volée, identiques à la > > prod, et ce de manière agnostique du fournisseur de serveurs / cloud, > > Docker semblait faire sens ici. "Plus qu'à" ajouter un système > > permettant de scale, monitor, et self heal et on est bon. > > > > Il me faudrait des propositions commerciales pour ce genre de > > prestation, n'hésitez pas à me contacter en privé, avec un ordre de > > prix. Et en me demandant les informations qu'il vous faudrait pour un > > devis. Il me faudra un devis assez détaillé pour que je puisse > > choisir en retirant des choses dedans si le budget ne correspond pas. > > Il va falloir que l'on fasse ces évolutions, mais peut être pas tout > > d'un coup (Si seulement mes budgets étaient illimités...) > > > > En vous souhaitant une bonne soirée, > > > > Gaël > > > > > > --------------------------- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
