Re: [FRnOG] [BIZ] Refonte infrastructure
On 26/09/2017 15:30, Sébastien FOUTREL wrote: 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. Oui complètement. 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. On est d'accord. 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. Je crois que l'on dit la même chose. La technologie ne peut et ne dois jamais remplacer la communication. Encore une fois ce ne sont que des outils. Chacun utilise ce qu'il juge le plus opportun. Et pour finir je citerai un philosophe : "YOU BUILD IT, YOU RUN IT" Oula c'est très devops çà :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
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 Gersena é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 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é,
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 25/09/2017 à 21:57, Raphael Mazelier a écrit : > > > On 25/09/2017 12:24, Wallace wrote: >> Bien résumé Eric et pour avoir tenu un discours comme celui de Raphael à >> des boites qui faisaient n'importe quoi en conteneur, la réponse est ha >> oui mais c'est super compliqué et trop abstrait de faire comme cela. En >> gros le côté éphémère leur fait super peur et c'est complètement >> abstrait = risque +++ pour les directions donc ils ne font pas. >> > > OK donc tu critiques la mauvaise mise en place des containers pas les > containers en tant que tel. Mais c'est exactement pareil sinon pire de > multiplier plein de petite vm(s) en terme de sécurité. > Un container ne devrait être vu que comme une instance (dans le vrai > sens instanciation objet) d'une application/service. Je répond sous le paragraphe suivant puisque c'est lié. > >> Après même avec une superbe archi conteneur, si tu fais toutes tes >> images pour être iso27001, pcidss et HDS le côté éphémère complexifie >> grandement le traitement des métriques / logs et le suivi qualité. >> > > Non c'est l'inverse. Évidement il faut prendre cela en compte dès la > création du container. Par exemple chez nous toutes les applications > "dockerisé" ont obligation d'envoyer leurs logs de manière structuré à > un système de log central (graylog en l’occurrence). > > Au final j'ai l'impression que l'on parle de deux choses différentes. > Remplacer des vm(s) par des containers n'a aucun sens en effet. > > Développer une nouvelle stack/SI dans un environnement container est > une grande opportunité. La où je te rejoins c'est qu'il y a une grande > courbe d'apprentissage que ce soit coté dev ou coté ops. Et là on reboucle sur le sujet, les conteneurs c'est super si on les fait soit même, on met ce que l'on veut : la sécurité, le déport de métriques / logs, les mises à jour, ... mais cela implique de faire ses images. Ca ne va clairement pas dans le sens des dirigeants qui y voient le gain financier temps / emmerdement à cours terme. Le pire ce sont les images officielles des applications, c'est officiel donc ça ne peut pas être foncièrement mauvais dixit des DSI et de DT. > >> Faut penser aussi aux audits externes qui peuvent être imposés genre >> suite à une fuite de données, la CNIL / ANSI qui vient auditer. Aucune >> des boites que j'ai vu faire du conteneur n'est apte à répondre à la >> moindre question d'extraction de donnée. Et quand on pense aux données >> que ces boites voient transiter c'est pas du tout rassurant pour nos >> profils persos. >> > > Parce c'est différent dans un environnement classique ? On reboucle sur le souci des images stock ou custom, en stock oui y a une différence parce qu'en VM l'OS peut être modifié facilement (à la main, script, automate) en conteneur c'est trop complexe pour les équipes qu'on croise. Du coup l'option de facilité c'est de dire ces mesures de sécurité, ces conformité c'est pas bien grave on relancera l'instance en cas de soucis ... > >> C'est aussi ça le rôle d'un hébergeur infogéreur, être sûr que son >> client soit apte à répondre à la loi en cas de besoin. >> >> Je trouve qu'une solution Ansible telle qu'on l'a monté chez nous qui >> permet de faire du on demand sur différents hosteurs c'est tout aussi >> souple. L'intégration d'une VM ça prend 5 min max avec le déroulé >> Ansible mettant tout aux normes. Avantage on peut aussi commander des >> baremetal et avoir des ressources bien différentes qui s'intègrent en >> 10/15 min max si le hosteur livre rapidement. >> > > Je ne vois toujours pas en quoi cela serait plus difficile dans un > environnement container. Ne pas oublier qu'un container n'est rien de > plus qu'un ensemble de process un peu isolé. Donc sécuriser n'importe > quelle application ou un container c'est pareil. Ca implique toujours une image conteneur custom. Sinon lancer un outil automate dans un OS conteneur qui est censé se regénérer toutes les x minutes / heures n'a que peu de sens. > >> Et là aussi même constat dans tous les boites et mêmes administrations >> qui utilisent Amazon ou Azur j'ai jamais vu une seule donnée chiffrée. >> C'est complètement irresponsable. J'ai vu des données santé brutes >> (image IRM, doc rapport du médecin, fichier txt avec le mot de passe par >> défaut 12345 pour en faire un mémo, nom des patients dans le nom de >> fichier, ...) aller chez Amazon et Azur pour le PRA. A titre personnel >> ça ne me donne même plus envie d'aller voir des médecins qui ont du >> matériel connecté. Et quand on fait réagir le client sur ce point, ha >> mais les médecins on peut rien leur demander, c'est les maîtres ici, >> 12345 c'est déjà trop compliqué pour eux comme mot de passe ils >> appellent le support quand le verr num n'est pas activé ... Et le cloud >> public c'est pratique on a pas d'infra à mettre en place et à gérer. >> > > Là encore tu critiques des mauvaises pratiques. Je ne penses pas que > les gros encouragent ce genre de choses. D'ailleurs Amazon (pour ne > citer
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 25/09/2017 à 23:26, Colin J. Brigato a écrit : > « Les containers c’est mauvais – la preuve en est : regardez toute la merde > que les gens en font » C'est sans doute pas assez mis en avant mais on fait des conteneurs juste qu'on le fait dans le contexte qui nous parait être le plus approprié pour ne pas négliger la sécurité et les remontées nécessaires aux équipes OPS et à la loi. Par contre oui on refuse de faire du conteneur comme on le voit lors de nos audits. signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [BIZ] Refonte infrastructure
Hello, > Le 25 sept. 2017 à 12:24, Wallacea écrit : > [XXX] Je déteste faire ça, c’est à dire réduire le discours de quelqu’un à un seul point de ce qu’il évoque, Mais je vais me permettre de le faire, parce que finalement en vous lisant, c’est tout ce qu’il semble en ressortir. « Les containers c’est mauvais – la preuve en est : regardez toute la merde que les gens en font » J’exagère probablement, mais il y a dans cette discussion une telle tétrachiée de raisonnement biaisés (volet négatif de l’expérience, je le conçois) que ca parait peine perdue d’essayer d’y déceler autre chose. Limite, le container, c’est un traumatisme assez fort pour certains qui se sont fait « experts » pendant l’âge de bienveillance d’une autre technologie que la simple période de recherche et d’expérimentation d’une nouvelle leur en a laissé une empreinte définitivement inscrite sur bits-fusibles. « La preuve est là » . D’aucun pourraient vous raconter à quel point jusqu’a il y a peu je voyait les « containers » , leur écosystème, leur « hype », et l’état de l’art de leur percée comme quelque chose dont il fallait à minima se méfier, au mieux s’en passer et au sacré la faire limite oublier par l’humanité si ce n’était par sécurité de ne pas la reproduire. Et pourtant à un moment, on tombe sur un endroit où, non pas que tout s’y prête et soit solutionné par telle ou telle techno, bien au contraire, mais on tombe à un endroit ou on lache juste assez de son « expérience » pour se permettre de penser différemment. Statistiquement, il semble qu’on fasse à terme de bien meilleures choses avec des informations ou idées que l’on déprécient à la base (et notamment sous couvert des mêmes raisonnements biaisés que décrits), et réciproquement des choses bien vilaines de bien tristes conséquences avec des idées que le bon sens et la pratique n’assuraient être possiblement autre chose que merveilleuse. Bien Cordialement, Colin --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
On 25/09/2017 12:24, Wallace wrote: Bien résumé Eric et pour avoir tenu un discours comme celui de Raphael à des boites qui faisaient n'importe quoi en conteneur, la réponse est ha oui mais c'est super compliqué et trop abstrait de faire comme cela. En gros le côté éphémère leur fait super peur et c'est complètement abstrait = risque +++ pour les directions donc ils ne font pas. OK donc tu critiques la mauvaise mise en place des containers pas les containers en tant que tel. Mais c'est exactement pareil sinon pire de multiplier plein de petite vm(s) en terme de sécurité. Un container ne devrait être vu que comme une instance (dans le vrai sens instanciation objet) d'une application/service. Après même avec une superbe archi conteneur, si tu fais toutes tes images pour être iso27001, pcidss et HDS le côté éphémère complexifie grandement le traitement des métriques / logs et le suivi qualité. Non c'est l'inverse. Évidement il faut prendre cela en compte dès la création du container. Par exemple chez nous toutes les applications "dockerisé" ont obligation d'envoyer leurs logs de manière structuré à un système de log central (graylog en l’occurrence). Au final j'ai l'impression que l'on parle de deux choses différentes. Remplacer des vm(s) par des containers n'a aucun sens en effet. Développer une nouvelle stack/SI dans un environnement container est une grande opportunité. La où je te rejoins c'est qu'il y a une grande courbe d'apprentissage que ce soit coté dev ou coté ops. Faut penser aussi aux audits externes qui peuvent être imposés genre suite à une fuite de données, la CNIL / ANSI qui vient auditer. Aucune des boites que j'ai vu faire du conteneur n'est apte à répondre à la moindre question d'extraction de donnée. Et quand on pense aux données que ces boites voient transiter c'est pas du tout rassurant pour nos profils persos. Parce c'est différent dans un environnement classique ? C'est aussi ça le rôle d'un hébergeur infogéreur, être sûr que son client soit apte à répondre à la loi en cas de besoin. Je trouve qu'une solution Ansible telle qu'on l'a monté chez nous qui permet de faire du on demand sur différents hosteurs c'est tout aussi souple. L'intégration d'une VM ça prend 5 min max avec le déroulé Ansible mettant tout aux normes. Avantage on peut aussi commander des baremetal et avoir des ressources bien différentes qui s'intègrent en 10/15 min max si le hosteur livre rapidement. Je ne vois toujours pas en quoi cela serait plus difficile dans un environnement container. Ne pas oublier qu'un container n'est rien de plus qu'un ensemble de process un peu isolé. Donc sécuriser n'importe quelle application ou un container c'est pareil. Sinon pour la partie des mega hosteurs, même s'ils débarquent en France ceux qui y mettent leurs données sont exposées aux lois américaines. Je parle même pas de la confidentialité en chiffrant les données, je parle de la réponse de ces boites vis à vis de la France et EU. L'aspect légal. Argument recevable. Et là aussi même constat dans tous les boites et mêmes administrations qui utilisent Amazon ou Azur j'ai jamais vu une seule donnée chiffrée. C'est complètement irresponsable. J'ai vu des données santé brutes (image IRM, doc rapport du médecin, fichier txt avec le mot de passe par défaut 12345 pour en faire un mémo, nom des patients dans le nom de fichier, ...) aller chez Amazon et Azur pour le PRA. A titre personnel ça ne me donne même plus envie d'aller voir des médecins qui ont du matériel connecté. Et quand on fait réagir le client sur ce point, ha mais les médecins on peut rien leur demander, c'est les maîtres ici, 12345 c'est déjà trop compliqué pour eux comme mot de passe ils appellent le support quand le verr num n'est pas activé ... Et le cloud public c'est pratique on a pas d'infra à mettre en place et à gérer. Là encore tu critiques des mauvaises pratiques. Je ne penses pas que les gros encouragent ce genre de choses. D'ailleurs Amazon (pour ne citer qu'eux) fait beaucoup de sensibilisation/formation sur la sécurisation d'une infrastructure hosté chez eux. Et quelle différence entre un truc mal sécurisé chez gafa, d'un truc mal sécurisé chez hébergeur lambda ? je ne peux te citer un certain nombre d'hébergeur qui ne se gênaient pas trop utiliser les données de leur client. Je ne parle même pas de la résilience des données. Dans les DSI je vois une prise de conscience des méfaits du cloud public et de l'adage de ne pas mettre les oeufs dans le même panier, ils ont tous les mots hybridation des clouds à la bouche et certains qui n'ont pas entièrement vidé leurs cloud privés sont content de pouvoir retrouvé des fonds pour les gérer ou les faire gérer. Donc les petits hébergeurs ont encore du travail clairement. Il y a plusieurs aspects qu'un DSI doit pendre en compte quand on choisit un cloud publique en effet. On peut citer le fait de ne pas se retrouver locké à tel ou tel provider (rien de
Re: [FRnOG] [BIZ] Refonte infrastructure
Je ne suis pas restreint à du docker, on utilise un peu de Ansible aujourd'hui pour nos déploiements d'outils de dev (Gitlab, ce genre de choses), mais pas pour la prod. Je cherche aujourd'hui, comme indiqué, plus qu'une prestation, quand je parle de formation, pour moi, ça inclut de l'accompagnement et du conseil, mais là dessus beaucoup me l'ont proposé. Notamment pour cibler le besoin de manière plus macro avant d'avancer. J'avais vu passer Mesos dans mes recherches préliminaires, je pensais à Docker de par le fait que je connais un peu la techno, donc ça me semblait moins effrayant. Sur le fond de votre discussion, oui, ça permet de zapper une partie des équipes infra, est ce une bonne chose ? Probablement pas, car moins de compétence en cas de problème, moins de compréhension de ce qui se passe "sous le capot"... Par contre, de notre coté, ça peut permettre de donner le coup de pouce permettant d'atteindre une rentabilité, sans laquelle on ne pourrait pas recruter une vraie équipe infra. (C'est d'ailleurs parce qu'on a pas d'équipe infra que je cherche aujourd'hui une prestation, pour que j'éviter de faire des conneries dans mon coin qui seraient sûrement plus grave) Merci pour vos réponses à tous, Cdt, Gaël On 9/25/17 12:24 PM, Wallace wrote: Bien résumé Eric et pour avoir tenu un discours comme celui de Raphael à des boites qui faisaient n'importe quoi en conteneur, la réponse est ha oui mais c'est super compliqué et trop abstrait de faire comme cela. En gros le côté éphémère leur fait super peur et c'est complètement abstrait = risque +++ pour les directions donc ils ne font pas. Après même avec une superbe archi conteneur, si tu fais toutes tes images pour être iso27001, pcidss et HDS le côté éphémère complexifie grandement le traitement des métriques / logs et le suivi qualité. Faut penser aussi aux audits externes qui peuvent être imposés genre suite à une fuite de données, la CNIL / ANSI qui vient auditer. Aucune des boites que j'ai vu faire du conteneur n'est apte à répondre à la moindre question d'extraction de donnée. Et quand on pense aux données que ces boites voient transiter c'est pas du tout rassurant pour nos profils persos. C'est aussi ça le rôle d'un hébergeur infogéreur, être sûr que son client soit apte à répondre à la loi en cas de besoin. Je trouve qu'une solution Ansible telle qu'on l'a monté chez nous qui permet de faire du on demand sur différents hosteurs c'est tout aussi souple. L'intégration d'une VM ça prend 5 min max avec le déroulé Ansible mettant tout aux normes. Avantage on peut aussi commander des baremetal et avoir des ressources bien différentes qui s'intègrent en 10/15 min max si le hosteur livre rapidement. Sinon pour la partie des mega hosteurs, même s'ils débarquent en France ceux qui y mettent leurs données sont exposées aux lois américaines. Je parle même pas de la confidentialité en chiffrant les données, je parle de la réponse de ces boites vis à vis de la France et EU. Et là aussi même constat dans tous les boites et mêmes administrations qui utilisent Amazon ou Azur j'ai jamais vu une seule donnée chiffrée. C'est complètement irresponsable. J'ai vu des données santé brutes (image IRM, doc rapport du médecin, fichier txt avec le mot de passe par défaut 12345 pour en faire un mémo, nom des patients dans le nom de fichier, ...) aller chez Amazon et Azur pour le PRA. A titre personnel ça ne me donne même plus envie d'aller voir des médecins qui ont du matériel connecté. Et quand on fait réagir le client sur ce point, ha mais les médecins on peut rien leur demander, c'est les maîtres ici, 12345 c'est déjà trop compliqué pour eux comme mot de passe ils appellent le support quand le verr num n'est pas activé ... Et le cloud public c'est pratique on a pas d'infra à mettre en place et à gérer. Dans les DSI je vois une prise de conscience des méfaits du cloud public et de l'adage de ne pas mettre les oeufs dans le même panier, ils ont tous les mots hybridation des clouds à la bouche et certains qui n'ont pas entièrement vidé leurs cloud privés sont content de pouvoir retrouvé des fonds pour les gérer ou les faire gérer. Donc les petits hébergeurs ont encore du travail clairement. Le 24/09/2017 à 06:37, Eric Mognat a écrit : tout à fait. Je pense que Wallace comme Jean-Yves ou moi ne sommes pas anti conteneur mais anti conteneur tels que pratiqué actuellement (images obsolètes et tout le toutim) dans de très nombreux cas. En corolaire, il me semble qu'une partie de ce problème vient de l'écoute des sirènes marqueting du type "regardez comment c'est trop bien le devops ... Plus besoin d'avoir qqu'un qui comprends ce qui se passe, "time to market" raccourcis (c'est une de mes préférée) et blablabla" et je voulais mettre en exergue une dimension parfois trop facilement oubliée (pas de manière claire à l'évidence :-)). Pour le reste, je suis tout à fait d'accord avec toi sur les apports de la techno à de nombreux niveaux y compris en
Re: [FRnOG] [BIZ] Refonte infrastructure
Bien résumé Eric et pour avoir tenu un discours comme celui de Raphael à des boites qui faisaient n'importe quoi en conteneur, la réponse est ha oui mais c'est super compliqué et trop abstrait de faire comme cela. En gros le côté éphémère leur fait super peur et c'est complètement abstrait = risque +++ pour les directions donc ils ne font pas. Après même avec une superbe archi conteneur, si tu fais toutes tes images pour être iso27001, pcidss et HDS le côté éphémère complexifie grandement le traitement des métriques / logs et le suivi qualité. Faut penser aussi aux audits externes qui peuvent être imposés genre suite à une fuite de données, la CNIL / ANSI qui vient auditer. Aucune des boites que j'ai vu faire du conteneur n'est apte à répondre à la moindre question d'extraction de donnée. Et quand on pense aux données que ces boites voient transiter c'est pas du tout rassurant pour nos profils persos. C'est aussi ça le rôle d'un hébergeur infogéreur, être sûr que son client soit apte à répondre à la loi en cas de besoin. Je trouve qu'une solution Ansible telle qu'on l'a monté chez nous qui permet de faire du on demand sur différents hosteurs c'est tout aussi souple. L'intégration d'une VM ça prend 5 min max avec le déroulé Ansible mettant tout aux normes. Avantage on peut aussi commander des baremetal et avoir des ressources bien différentes qui s'intègrent en 10/15 min max si le hosteur livre rapidement. Sinon pour la partie des mega hosteurs, même s'ils débarquent en France ceux qui y mettent leurs données sont exposées aux lois américaines. Je parle même pas de la confidentialité en chiffrant les données, je parle de la réponse de ces boites vis à vis de la France et EU. Et là aussi même constat dans tous les boites et mêmes administrations qui utilisent Amazon ou Azur j'ai jamais vu une seule donnée chiffrée. C'est complètement irresponsable. J'ai vu des données santé brutes (image IRM, doc rapport du médecin, fichier txt avec le mot de passe par défaut 12345 pour en faire un mémo, nom des patients dans le nom de fichier, ...) aller chez Amazon et Azur pour le PRA. A titre personnel ça ne me donne même plus envie d'aller voir des médecins qui ont du matériel connecté. Et quand on fait réagir le client sur ce point, ha mais les médecins on peut rien leur demander, c'est les maîtres ici, 12345 c'est déjà trop compliqué pour eux comme mot de passe ils appellent le support quand le verr num n'est pas activé ... Et le cloud public c'est pratique on a pas d'infra à mettre en place et à gérer. Dans les DSI je vois une prise de conscience des méfaits du cloud public et de l'adage de ne pas mettre les oeufs dans le même panier, ils ont tous les mots hybridation des clouds à la bouche et certains qui n'ont pas entièrement vidé leurs cloud privés sont content de pouvoir retrouvé des fonds pour les gérer ou les faire gérer. Donc les petits hébergeurs ont encore du travail clairement. Le 24/09/2017 à 06:37, Eric Mognat a écrit : > tout à fait. > > Je pense que Wallace comme Jean-Yves ou moi ne sommes pas anti > conteneur mais anti conteneur tels que pratiqué actuellement (images > obsolètes et tout le toutim) dans de très nombreux cas. En corolaire, > il me semble qu'une partie de ce problème vient de l'écoute des > sirènes marqueting du type "regardez comment c'est trop bien le devops > ... Plus besoin d'avoir qqu'un qui comprends ce qui se passe, "time to > market" raccourcis (c'est une de mes préférée) et blablabla" et je > voulais mettre en exergue une dimension parfois trop facilement > oubliée (pas de manière claire à l'évidence :-)). > > Pour le reste, je suis tout à fait d'accord avec toi sur les apports > de la techno à de nombreux niveaux y compris en terme de sécurité. > > A+ > > Le 23 septembre 2017 à 08:23, Raphael Mazeliera écrit : >> >> On 22/09/2017 10:07, Wallace wrote: >> >>> Ça ne solutionne pas le souci majeur de Docker et toute instance >>> conteneur à savoir que les OS minimalistes dans les images sont >>> - non sécurisées, c'est équivalent à un debootstrap or ceux qui mettent >>> en prod des OS sans faire de hardening devraient changer de métier >>> - rarement mis à jour soit par non mise à jour de l'image par les >>> mainteneurs d'images officielles ou l'équipe de dev interne soit par non >>> destroy / recreate d'une instance parce qu'au final ça marche et on a >>> pas de mise à jour de code à faire dessus... >>> >>> Les conteneurs c'est bien pour faire des instances copies de prod pour >>> du dev / staging / recette / préprod sans mettre les mêmes moyens >>> d'infrastructure que la prod. >>> >>> On a vu plusieurs startup faire du full Docker sur quelques serveurs. Un >>> simple audit de sécu et on passe de l'instance prod à la compta à la dev >>> et au gitlab juste en ayant scanné les ports locaux des hôtes et en >>> ayant mis un petit code de redirection de ports ... >>> Je parle même pas de l'âge des instances qui pour certaines avaient >>> presque 2 ans ...
Re: [FRnOG] [BIZ] Refonte infrastructure
Evidement tu est le bienvenu pour visiter. Je connais les differents arguments que tu cite. C'est d'ailleur pour ca qu'on a etofee nos offres avec du cloud publique. Et notre force est clairement le sur-mesure, un vdc securise par client, mais aussi le conseil. Je suis d'accord que si l'on na pas ca en tant que "petit" on a aucune chance. Yoann Thomas > Le 24 sept. 2017 à 06:37, Eric Mognata écrit : > > tout à fait. > > Je pense que Wallace comme Jean-Yves ou moi ne sommes pas anti > conteneur mais anti conteneur tels que pratiqué actuellement (images > obsolètes et tout le toutim) dans de très nombreux cas. En corolaire, > il me semble qu'une partie de ce problème vient de l'écoute des > sirènes marqueting du type "regardez comment c'est trop bien le devops > ... Plus besoin d'avoir qqu'un qui comprends ce qui se passe, "time to > market" raccourcis (c'est une de mes préférée) et blablabla" et je > voulais mettre en exergue une dimension parfois trop facilement > oubliée (pas de manière claire à l'évidence :-)). > > Pour le reste, je suis tout à fait d'accord avec toi sur les apports > de la techno à de nombreux niveaux y compris en terme de sécurité. > > A+ > >> Le 23 septembre 2017 à 08:23, Raphael Mazelier a écrit : >> >> >>> On 22/09/2017 10:07, Wallace wrote: >>> >>> Ça ne solutionne pas le souci majeur de Docker et toute instance >>> conteneur à savoir que les OS minimalistes dans les images sont >>> - non sécurisées, c'est équivalent à un debootstrap or ceux qui mettent >>> en prod des OS sans faire de hardening devraient changer de métier >>> - rarement mis à jour soit par non mise à jour de l'image par les >>> mainteneurs d'images officielles ou l'équipe de dev interne soit par non >>> destroy / recreate d'une instance parce qu'au final ça marche et on a >>> pas de mise à jour de code à faire dessus... >>> >>> Les conteneurs c'est bien pour faire des instances copies de prod pour >>> du dev / staging / recette / préprod sans mettre les mêmes moyens >>> d'infrastructure que la prod. >>> >>> On a vu plusieurs startup faire du full Docker sur quelques serveurs. Un >>> simple audit de sécu et on passe de l'instance prod à la compta à la dev >>> et au gitlab juste en ayant scanné les ports locaux des hôtes et en >>> ayant mis un petit code de redirection de ports ... >>> Je parle même pas de l'âge des instances qui pour certaines avaient >>> presque 2 ans ... donc l'OS hôte Docker n'avait jamais été mis à jour, >>> forcément faudrait arrêter la prod, la dev, le staging, la compta, le >>> crm, l'erp, le partage de fichier, en gros arrêter la boite. La raison >>> c'est trop compliqué de mettre en cluster sur des hosteurs de serveurs >>> dédiés, sans blague. >>> >>> Non sérieusement en prod Docker ou tout conteneur on le conseil >>> seulement pour faire un groupe d'hôtes qui accueilleraient le même type >>> d'instances dans une DMZ avec un vrai firewall devant, avec une vrai >>> politique de mise à jour et avec que des images custom avec un hardening >>> bien fait mérite d'être en production. Mais rien que maintenir leurs >>> propres images j'ai vu beaucoup de devops ou dev ne pas vouloir se >>> lancer là dedans, du coup faire des VM ou baremetal avec un Ansible ou >>> Puppet permet de concilier l'infrastructure as a code avec les bonnes >>> pratiques systèmes en production. >>> >>> >> >> Je ne comprends vraiment pas cet argumentaire anti conteneur niveau >> sécurité. >> >> Au contraire le l'utilisation de containers dans un environnement type k8s >> me semble une bonne opportunité niveau sécurité. Cela permet de faire du >> rolling-update niveau container et niveau host (ce qui est en effet un >> argument pour ne pas faire d'update). Typiquement tout est éphémère, et tout >> est constamment mis à jour. >> >> Concernant les images en effet je suis d'accord qu'il faut les faire soit >> même (c'est même une évidence). >> >> L'autre immense avantage des architectures type k8s ce que l'on expose que >> ce qui doit être exposé, cela la limite la surface d'attaque externe. >> Concernant le filtrage interne des projets type calico permette un filtrage >> très fin (ala SecurityGroup Aws). >> >> Ce qui tu dis peut être c'est que faire du conteneur n'importe comment est >> dangereux ; oui comme une architecture classique. Bien utilisé cela permet >> une bien meilleure segmentation (c'est bien un des mantra de la sécurité >> hein ?). >> >> -- >> Raphael Mazelier >> >> >> >> >> >> >> --- >> 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/
Re: [FRnOG] [BIZ] Refonte infrastructure
tout à fait. Je pense que Wallace comme Jean-Yves ou moi ne sommes pas anti conteneur mais anti conteneur tels que pratiqué actuellement (images obsolètes et tout le toutim) dans de très nombreux cas. En corolaire, il me semble qu'une partie de ce problème vient de l'écoute des sirènes marqueting du type "regardez comment c'est trop bien le devops ... Plus besoin d'avoir qqu'un qui comprends ce qui se passe, "time to market" raccourcis (c'est une de mes préférée) et blablabla" et je voulais mettre en exergue une dimension parfois trop facilement oubliée (pas de manière claire à l'évidence :-)). Pour le reste, je suis tout à fait d'accord avec toi sur les apports de la techno à de nombreux niveaux y compris en terme de sécurité. A+ Le 23 septembre 2017 à 08:23, Raphael Mazeliera écrit : > > > On 22/09/2017 10:07, Wallace wrote: > >> Ça ne solutionne pas le souci majeur de Docker et toute instance >> conteneur à savoir que les OS minimalistes dans les images sont >> - non sécurisées, c'est équivalent à un debootstrap or ceux qui mettent >> en prod des OS sans faire de hardening devraient changer de métier >> - rarement mis à jour soit par non mise à jour de l'image par les >> mainteneurs d'images officielles ou l'équipe de dev interne soit par non >> destroy / recreate d'une instance parce qu'au final ça marche et on a >> pas de mise à jour de code à faire dessus... >> >> Les conteneurs c'est bien pour faire des instances copies de prod pour >> du dev / staging / recette / préprod sans mettre les mêmes moyens >> d'infrastructure que la prod. >> >> On a vu plusieurs startup faire du full Docker sur quelques serveurs. Un >> simple audit de sécu et on passe de l'instance prod à la compta à la dev >> et au gitlab juste en ayant scanné les ports locaux des hôtes et en >> ayant mis un petit code de redirection de ports ... >> Je parle même pas de l'âge des instances qui pour certaines avaient >> presque 2 ans ... donc l'OS hôte Docker n'avait jamais été mis à jour, >> forcément faudrait arrêter la prod, la dev, le staging, la compta, le >> crm, l'erp, le partage de fichier, en gros arrêter la boite. La raison >> c'est trop compliqué de mettre en cluster sur des hosteurs de serveurs >> dédiés, sans blague. >> >> Non sérieusement en prod Docker ou tout conteneur on le conseil >> seulement pour faire un groupe d'hôtes qui accueilleraient le même type >> d'instances dans une DMZ avec un vrai firewall devant, avec une vrai >> politique de mise à jour et avec que des images custom avec un hardening >> bien fait mérite d'être en production. Mais rien que maintenir leurs >> propres images j'ai vu beaucoup de devops ou dev ne pas vouloir se >> lancer là dedans, du coup faire des VM ou baremetal avec un Ansible ou >> Puppet permet de concilier l'infrastructure as a code avec les bonnes >> pratiques systèmes en production. >> >> > > Je ne comprends vraiment pas cet argumentaire anti conteneur niveau > sécurité. > > Au contraire le l'utilisation de containers dans un environnement type k8s > me semble une bonne opportunité niveau sécurité. Cela permet de faire du > rolling-update niveau container et niveau host (ce qui est en effet un > argument pour ne pas faire d'update). Typiquement tout est éphémère, et tout > est constamment mis à jour. > > Concernant les images en effet je suis d'accord qu'il faut les faire soit > même (c'est même une évidence). > > L'autre immense avantage des architectures type k8s ce que l'on expose que > ce qui doit être exposé, cela la limite la surface d'attaque externe. > Concernant le filtrage interne des projets type calico permette un filtrage > très fin (ala SecurityGroup Aws). > > Ce qui tu dis peut être c'est que faire du conteneur n'importe comment est > dangereux ; oui comme une architecture classique. Bien utilisé cela permet > une bien meilleure segmentation (c'est bien un des mantra de la sécurité > hein ?). > > -- > Raphael Mazelier > > > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
Salut Raph, Je suis desole mais ce genre de discour aws/gce/azure me fait plus que mal. Sans parler que oui je suis un hebergeur qui ne peux concurencer les enormes. Mais quand j'entend des clients qui me disent heberger des donnees de santee FR au US et ben je trouve que c'est un non sens. Il est vrai qu'il est dificile de jouer dans la meme cours mais a qui la faute!! Je pense peux etre a tord que les donnees FR doivent etre heberger en FR avec des societes qui paient leurs impots en FR. Je sais qu'il s'agit d'un pave dans la mare mais bon si personne ne defend le home made je ne sais pas ou l'on va. Si un certain nombre de personne pense comme moi n'hesitez pas a le faire savoir ;) Ps Raph juste un coup de geule perso, rien sur le discour du thread. Et dsl pour les fautes j'ai pas relu ;) Yoann Thomas > Le 23 sept. 2017 à 20:44, Raphael Mazeliera écrit : > > > >> On 22/09/2017 10:53, Jean-Yves LENHOF wrote: >> Ca veut aussi dire avoir sa propre registry docker.. Et les solutions >> commencent tout juste à murir sur le sujet (haute dispo d'une registry ? > > ? une registry docker c'est un pauvre démon backé sur un filesystem / s3 ou > autre. Il suffit d'en lancer plusieurs et de sauvegarder son backend. > Par exemple chez nous on lance un registry par host k8s. > >> Solution proxyfiée pour répartition sur plusieurs datacenter, etc) et je >> ne pense pas avoir vu tous les problèmes inhérents encore >> Après je ne suis pas contre docker... il y a des idées intéressantes >> surtout lorsque l'on va jusqu'au bout de la démarche avec un >> orchestrateur, maintenant si c'est seulement pour zapper les équipes >> infrastructures je suis moins d'accord surtout lorsque cela se fait au >> détriment de la sécurité > > Sans orchestrateur docker n'est qu'un outil qui unifie le paquetage d'une > application (et c'est déjà énorme). Avec un orchestrateur cela commence à > apporter une vrai nouvelle philosophie, aka se re-concentrer sur l'essentiel > : l'applicatif. > > Il y aura toujours besoin de personne qui connaisse l'infrastructure mais > peut être en effet qu'il n'y aura plus d’équipe infrastructure dans chaque > société (devops toussa mais dans le bon sens du terme). > > En revanche on ne va pas se mentir les activités d'hébergeur/infogéreur à la > papa vont souffrir face aux gros acteurs (AWS/GCE/Azure). Et c'est bien > normal ils proposent des meilleurs infrastructures et plus de services. On > peut encore se battre sur le prix mais cela va devenir dur. > > -- > Raphael Mazelier > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
On 22/09/2017 10:53, Jean-Yves LENHOF wrote: Ca veut aussi dire avoir sa propre registry docker.. Et les solutions commencent tout juste à murir sur le sujet (haute dispo d'une registry ? ? une registry docker c'est un pauvre démon backé sur un filesystem / s3 ou autre. Il suffit d'en lancer plusieurs et de sauvegarder son backend. Par exemple chez nous on lance un registry par host k8s. Solution proxyfiée pour répartition sur plusieurs datacenter, etc) et je ne pense pas avoir vu tous les problèmes inhérents encore Après je ne suis pas contre docker... il y a des idées intéressantes surtout lorsque l'on va jusqu'au bout de la démarche avec un orchestrateur, maintenant si c'est seulement pour zapper les équipes infrastructures je suis moins d'accord surtout lorsque cela se fait au détriment de la sécurité Sans orchestrateur docker n'est qu'un outil qui unifie le paquetage d'une application (et c'est déjà énorme). Avec un orchestrateur cela commence à apporter une vrai nouvelle philosophie, aka se re-concentrer sur l'essentiel : l'applicatif. Il y aura toujours besoin de personne qui connaisse l'infrastructure mais peut être en effet qu'il n'y aura plus d’équipe infrastructure dans chaque société (devops toussa mais dans le bon sens du terme). En revanche on ne va pas se mentir les activités d'hébergeur/infogéreur à la papa vont souffrir face aux gros acteurs (AWS/GCE/Azure). Et c'est bien normal ils proposent des meilleurs infrastructures et plus de services. On peut encore se battre sur le prix mais cela va devenir dur. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
On 22/09/2017 10:07, Wallace wrote: Ça ne solutionne pas le souci majeur de Docker et toute instance conteneur à savoir que les OS minimalistes dans les images sont - non sécurisées, c'est équivalent à un debootstrap or ceux qui mettent en prod des OS sans faire de hardening devraient changer de métier - rarement mis à jour soit par non mise à jour de l'image par les mainteneurs d'images officielles ou l'équipe de dev interne soit par non destroy / recreate d'une instance parce qu'au final ça marche et on a pas de mise à jour de code à faire dessus... Les conteneurs c'est bien pour faire des instances copies de prod pour du dev / staging / recette / préprod sans mettre les mêmes moyens d'infrastructure que la prod. On a vu plusieurs startup faire du full Docker sur quelques serveurs. Un simple audit de sécu et on passe de l'instance prod à la compta à la dev et au gitlab juste en ayant scanné les ports locaux des hôtes et en ayant mis un petit code de redirection de ports ... Je parle même pas de l'âge des instances qui pour certaines avaient presque 2 ans ... donc l'OS hôte Docker n'avait jamais été mis à jour, forcément faudrait arrêter la prod, la dev, le staging, la compta, le crm, l'erp, le partage de fichier, en gros arrêter la boite. La raison c'est trop compliqué de mettre en cluster sur des hosteurs de serveurs dédiés, sans blague. Non sérieusement en prod Docker ou tout conteneur on le conseil seulement pour faire un groupe d'hôtes qui accueilleraient le même type d'instances dans une DMZ avec un vrai firewall devant, avec une vrai politique de mise à jour et avec que des images custom avec un hardening bien fait mérite d'être en production. Mais rien que maintenir leurs propres images j'ai vu beaucoup de devops ou dev ne pas vouloir se lancer là dedans, du coup faire des VM ou baremetal avec un Ansible ou Puppet permet de concilier l'infrastructure as a code avec les bonnes pratiques systèmes en production. Je ne comprends vraiment pas cet argumentaire anti conteneur niveau sécurité. Au contraire le l'utilisation de containers dans un environnement type k8s me semble une bonne opportunité niveau sécurité. Cela permet de faire du rolling-update niveau container et niveau host (ce qui est en effet un argument pour ne pas faire d'update). Typiquement tout est éphémère, et tout est constamment mis à jour. Concernant les images en effet je suis d'accord qu'il faut les faire soit même (c'est même une évidence). L'autre immense avantage des architectures type k8s ce que l'on expose que ce qui doit être exposé, cela la limite la surface d'attaque externe. Concernant le filtrage interne des projets type calico permette un filtrage très fin (ala SecurityGroup Aws). Ce qui tu dis peut être c'est que faire du conteneur n'importe comment est dangereux ; oui comme une architecture classique. Bien utilisé cela permet une bien meilleure segmentation (c'est bien un des mantra de la sécurité hein ?). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
Oui. ça va, à mon sens, changer pas mal la donne. Le 22 septembre 2017 à 04:42, Jonathan Leroya écrit : > Le 22 septembre 2017 à 16:00, Wallace a écrit : >> Tu penses à quel élément en particulier, je vois pas bien. > > RGPD ? > > > -- > Jonathan Leroy. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 22 septembre 2017 à 16:52, David Ponzonea écrit : > Ah lala, c'est tellement pointu comme échange, avec des acronymes et des noms > bizarres que je connais pas, j'ai l'impression d'être sur FRsAG. > C'est bon, je sais où est la porte. Pour ta culture : https://fr.wikipedia.org/wiki/R%C3%A8glement_g%C3%A9n%C3%A9ral_sur_la_protection_des_donn%C3%A9es :) (C'est vrai que ce thread aurait plus sa place sur FRSAG, mébon). -- Jonathan Leroy. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
Ah lala, c'est tellement pointu comme échange, avec des acronymes et des noms bizarres que je connais pas, j'ai l'impression d'être sur FRsAG. C'est bon, je sais où est la porte. Le 22 sept. 2017 à 16:42, Jonathan Leroy a écrit : > Le 22 septembre 2017 à 16:00, Wallacea écrit : >> Tu penses à quel élément en particulier, je vois pas bien. > > RGPD ? > > > -- > Jonathan Leroy. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 22 septembre 2017 à 16:00, Wallacea écrit : > Tu penses à quel élément en particulier, je vois pas bien. RGPD ? -- Jonathan Leroy. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 22/09/2017 à 11:35, Eric Mognat a écrit : > > On peut ajouter que certains paradigmes notamment économiques vont > probablement changer radicalement à compter de fin mai 2018 :-) > > ça me fait penser qu'il reste un peu de temps aux sys/net "purs" pour > tenter d'évoluer ie : adapter leur langage pour être compris ? Tu penses à quel élément en particulier, je vois pas bien. signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [BIZ] Refonte infrastructure
Quelqu'un rancher en prod ? j'ai commencer à regarder openshift, mais c'est vraiment l'usine à gaz, surtout pour gérer plusieurs clusters. J'avais vu une demo de rancher au Paris container day, et ca semblait vraiment bien foutu. Rancher permet de deployer du kubernetes,swarm,cattle(l'orchestrateur de rancher), et spawner des instances sur des machines local,google,aws,... (On compte commencer à mettre en prod du docker l'année prochaine, pour du stateless only (pas de bdd ou autre, uniquement des applis php,node,...) - Mail original - De: "Sébastien Lesimple" <sebastien.lesim...@iguanetel.fr> À: "Nicolas Girardi" <n.gira...@gmail.com>, "Tristan Mahé" <g...@remote-shell.net> Cc: frnog@frnog.org Envoyé: Vendredi 22 Septembre 2017 15:12:51 Objet: Re: [FRnOG] [BIZ] Refonte infrastructure Dommage de ne pas avoir pensé à Outscale à la place d'AWS ;) Le 22/09/2017 à 08:15, Nicolas Girardi a écrit : > Bonjour, > > DS2I nous accompagne actuellement sur une migration vers le cloud (AWS) avec > du : > - terraform > - consul/service discovery > - packer > - EC2 : ES, MySQL > - Services Managés (en remplacement de RabbitMQ) > - ELB > - Autoscaling > - route53 > > L’objectif étant de faire du déploiement blue/green > > PS : ils viennent d’être racheté par DevoTeam. > > Cdlt. > > Nicolas Girardi. > >> Le 22 sept. 2017 à 00:25, Tristan Mahé <g...@remote-shell.net> a écrit : >> >> Docker en prod ? ;) >> >> On n'est pas vendredi, grrr... >> >> Tu n'as pas indiqué la techno d'autoprovisionning que vous utilisez au >> fait ( Ansible ? Chef ? Puppet ? ... ), ce qui pourrait te permettre de >> monter baremetal sur differents fournisseurs, ou t'affranchir de ton >> fournisseur de cloud sans pour autant >> >> tomber dans le fossé docker en prod avec publish sur un repo privé de >> tes images ( quid du maintenir l'os a jour etc... il y as suffisament de >> litterature sur le sujet si tu es curieux ;) ). >> >> My 2cents. >> >>> On 09/21/2017 02:04 PM, 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
Re: [FRnOG] [BIZ] Refonte infrastructure
Dommage de ne pas avoir pensé à Outscale à la place d'AWS ;) Le 22/09/2017 à 08:15, Nicolas Girardi a écrit : > Bonjour, > > DS2I nous accompagne actuellement sur une migration vers le cloud (AWS) avec > du : > - terraform > - consul/service discovery > - packer > - EC2 : ES, MySQL > - Services Managés (en remplacement de RabbitMQ) > - ELB > - Autoscaling > - route53 > > L’objectif étant de faire du déploiement blue/green > > PS : ils viennent d’être racheté par DevoTeam. > > Cdlt. > > Nicolas Girardi. > >> Le 22 sept. 2017 à 00:25, Tristan Mahéa écrit : >> >> Docker en prod ? ;) >> >> On n'est pas vendredi, grrr... >> >> Tu n'as pas indiqué la techno d'autoprovisionning que vous utilisez au >> fait ( Ansible ? Chef ? Puppet ? ... ), ce qui pourrait te permettre de >> monter baremetal sur differents fournisseurs, ou t'affranchir de ton >> fournisseur de cloud sans pour autant >> >> tomber dans le fossé docker en prod avec publish sur un repo privé de >> tes images ( quid du maintenir l'os a jour etc... il y as suffisament de >> litterature sur le sujet si tu es curieux ;) ). >> >> My 2cents. >> >>> On 09/21/2017 02:04 PM, 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/
Re: [FRnOG] [BIZ] Refonte infrastructure
"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." Kubernetes ou OpenShift, sans hesitation. 2017-09-22 0:04 GMT+03:00 Gaël Demette: > 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/
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 21 septembre 2017 à 23:22, Wallacea écrit : > > > Le 22/09/2017 à 10:39, Kirth Gersen a écrit : >> 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 :) > Je peux pas divulguer tout mais je compte plus d'infras conteneurs > sauvées ces dernières années dont la cause du piratage était une non > sécurisation élémentaires des OS et services. > > Dans toutes les images docker croisées chez des clients ces dernières > années dès que je lance un script de vérification de conformité > élémentaire de sécurité, ça crépite du rouge à toutes les lignes. Quand > je lance un test PCIDSS on est entre 0 et 10 / 100. > > Un OS qu'il soit baremetal, vm, conteneur doit pouvoir passer les tests > PCI-DSS ou iso27001 sinon c'est de l’artisanat ou de l'amateurisme ou de > l'économie ridicule ou alors du je m'en foutisme qui conduira à une > catastrophe tôt ou tard. > > Bonjour, On peut ajouter que certains paradigmes notamment économiques vont probablement changer radicalement à compter de fin mai 2018 :-) ça me fait penser qu'il reste un peu de temps aux sys/net "purs" pour tenter d'évoluer ie : adapter leur langage pour être compris ? A+ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
Salut,tu as un retour à nous faire partager sur les outils Hashicorp ?Merci.CdltOlivier Meyer |Bonjour, | |DS2I nous accompagne actuellement sur une migration vers le cloud (AWS) avec du : |- terraform |- consul/service discovery |- packer |- EC2 : ES, MySQL |- Services Managés (en remplacement de RabbitMQ) |- ELB |- Autoscaling |- route53 | |L’objectif étant de faire du déploiement blue/green | |PS : ils viennent d’être racheté par DevoTeam. | |Cdlt. | |Nicolas Girardi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 22/09/2017 à 10:39, Kirth Gersen a écrit : > 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 :) Je peux pas divulguer tout mais je compte plus d'infras conteneurs sauvées ces dernières années dont la cause du piratage était une non sécurisation élémentaires des OS et services. Dans toutes les images docker croisées chez des clients ces dernières années dès que je lance un script de vérification de conformité élémentaire de sécurité, ça crépite du rouge à toutes les lignes. Quand je lance un test PCIDSS on est entre 0 et 10 / 100. Un OS qu'il soit baremetal, vm, conteneur doit pouvoir passer les tests PCI-DSS ou iso27001 sinon c'est de l’artisanat ou de l'amateurisme ou de l'économie ridicule ou alors du je m'en foutisme qui conduira à une catastrophe tôt ou tard. signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 22/09/2017 à 10:53, Jean-Yves LENHOF a écrit : > maintenant si c'est seulement pour zapper les équipes > infrastructures je suis moins d'accord surtout lorsque cela se fait au > détriment de la sécurité > C'est très bien résumé, mais je dirais aussi que si d'un côté la direction y voit des économies à très cours terme y a aussi des développeurs qui savent installer des linux pour leurs environnement de dev et qui pensent pouvoir faire pareil en prod et sont donc très content de ne plus avoir les contraintes des ops sys et réseau. Donc ça pousse des deux côtés et après ils se plaignent quand y a des cas comme Equifax ou Ashley Madisson ... signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 22/09/2017 à 10:07, Wallace a écrit : > > Ça ne solutionne pas le souci majeur de Docker et toute instance > conteneur à savoir que les OS minimalistes dans les images sont > - non sécurisées, c'est équivalent à un debootstrap or ceux qui mettent > en prod des OS sans faire de hardening devraient changer de métier > - rarement mis à jour soit par non mise à jour de l'image par les > mainteneurs d'images officielles ou l'équipe de dev interne soit par non > destroy / recreate d'une instance parce qu'au final ça marche et on a > pas de mise à jour de code à faire dessus... > > Les conteneurs c'est bien pour faire des instances copies de prod pour > du dev / staging / recette / préprod sans mettre les mêmes moyens > d'infrastructure que la prod. > > On a vu plusieurs startup faire du full Docker sur quelques serveurs. Un > simple audit de sécu et on passe de l'instance prod à la compta à la dev > et au gitlab juste en ayant scanné les ports locaux des hôtes et en > ayant mis un petit code de redirection de ports ... > Je parle même pas de l'âge des instances qui pour certaines avaient > presque 2 ans ... donc l'OS hôte Docker n'avait jamais été mis à jour, > forcément faudrait arrêter la prod, la dev, le staging, la compta, le > crm, l'erp, le partage de fichier, en gros arrêter la boite. La raison > c'est trop compliqué de mettre en cluster sur des hosteurs de serveurs > dédiés, sans blague. > > Non sérieusement en prod Docker ou tout conteneur on le conseil > seulement pour faire un groupe d'hôtes qui accueilleraient le même type > d'instances dans une DMZ avec un vrai firewall devant, avec une vrai > politique de mise à jour et avec que des images custom avec un hardening > bien fait mérite d'être en production. Mais rien que maintenir leurs > propres images j'ai vu beaucoup de devops ou dev ne pas vouloir se > lancer là dedans, du coup faire des VM ou baremetal avec un Ansible ou > Puppet permet de concilier l'infrastructure as a code avec les bonnes > pratiques systèmes en production. +1 pour tout ça Ca veut dire gérer ses propres images... Ca veut donc dire builder ses images de base depuis son repo de distrib favorite (les images de base sur le hub docker ne sont pas reconstruites suivant un cycle de sécurité déterminé, elles ne sont pas spécifiquement durcies, etc...) Ca veut aussi dire avoir sa propre registry docker.. Et les solutions commencent tout juste à murir sur le sujet (haute dispo d'une registry ? Solution proxyfiée pour répartition sur plusieurs datacenter, etc) et je ne pense pas avoir vu tous les problèmes inhérents encore Après je ne suis pas contre docker... il y a des idées intéressantes surtout lorsque l'on va jusqu'au bout de la démarche avec un orchestrateur, maintenant si c'est seulement pour zapper les équipes infrastructures je suis moins d'accord surtout lorsque cela se fait au détriment de la sécurité JYL --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
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> 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/
Re: [FRnOG] [BIZ] Refonte infrastructure
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> 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/
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 22/09/2017 à 08:35, Stéphane Cottin 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 Ça ne solutionne pas le souci majeur de Docker et toute instance conteneur à savoir que les OS minimalistes dans les images sont - non sécurisées, c'est équivalent à un debootstrap or ceux qui mettent en prod des OS sans faire de hardening devraient changer de métier - rarement mis à jour soit par non mise à jour de l'image par les mainteneurs d'images officielles ou l'équipe de dev interne soit par non destroy / recreate d'une instance parce qu'au final ça marche et on a pas de mise à jour de code à faire dessus... Les conteneurs c'est bien pour faire des instances copies de prod pour du dev / staging / recette / préprod sans mettre les mêmes moyens d'infrastructure que la prod. On a vu plusieurs startup faire du full Docker sur quelques serveurs. Un simple audit de sécu et on passe de l'instance prod à la compta à la dev et au gitlab juste en ayant scanné les ports locaux des hôtes et en ayant mis un petit code de redirection de ports ... Je parle même pas de l'âge des instances qui pour certaines avaient presque 2 ans ... donc l'OS hôte Docker n'avait jamais été mis à jour, forcément faudrait arrêter la prod, la dev, le staging, la compta, le crm, l'erp, le partage de fichier, en gros arrêter la boite. La raison c'est trop compliqué de mettre en cluster sur des hosteurs de serveurs dédiés, sans blague. Non sérieusement en prod Docker ou tout conteneur on le conseil seulement pour faire un groupe d'hôtes qui accueilleraient le même type d'instances dans une DMZ avec un vrai firewall devant, avec une vrai politique de mise à jour et avec que des images custom avec un hardening bien fait mérite d'être en production. Mais rien que maintenir leurs propres images j'ai vu beaucoup de devops ou dev ne pas vouloir se lancer là dedans, du coup faire des VM ou baremetal avec un Ansible ou Puppet permet de concilier l'infrastructure as a code avec les bonnes pratiques systèmes en production. signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [BIZ] Refonte infrastructure
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/
Re: [FRnOG] [BIZ] Refonte infrastructure
Bonjour, DS2I nous accompagne actuellement sur une migration vers le cloud (AWS) avec du : - terraform - consul/service discovery - packer - EC2 : ES, MySQL - Services Managés (en remplacement de RabbitMQ) - ELB - Autoscaling - route53 L’objectif étant de faire du déploiement blue/green PS : ils viennent d’être racheté par DevoTeam. Cdlt. Nicolas Girardi. > Le 22 sept. 2017 à 00:25, Tristan Mahéa écrit : > > Docker en prod ? ;) > > On n'est pas vendredi, grrr... > > Tu n'as pas indiqué la techno d'autoprovisionning que vous utilisez au > fait ( Ansible ? Chef ? Puppet ? ... ), ce qui pourrait te permettre de > monter baremetal sur differents fournisseurs, ou t'affranchir de ton > fournisseur de cloud sans pour autant > > tomber dans le fossé docker en prod avec publish sur un repo privé de > tes images ( quid du maintenir l'os a jour etc... il y as suffisament de > litterature sur le sujet si tu es curieux ;) ). > > My 2cents. > >> On 09/21/2017 02:04 PM, 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/
Re: [FRnOG] [BIZ] Refonte infrastructure
Docker en prod ? ;) On n'est pas vendredi, grrr... Tu n'as pas indiqué la techno d'autoprovisionning que vous utilisez au fait ( Ansible ? Chef ? Puppet ? ... ), ce qui pourrait te permettre de monter baremetal sur differents fournisseurs, ou t'affranchir de ton fournisseur de cloud sans pour autant tomber dans le fossé docker en prod avec publish sur un repo privé de tes images ( quid du maintenir l'os a jour etc... il y as suffisament de litterature sur le sujet si tu es curieux ;) ). My 2cents. On 09/21/2017 02:04 PM, 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/ signature.asc Description: OpenPGP digital signature