Re: [FRnOG] [BIZ] Refonte infrastructure

[Raphael Mazelier]

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

[Sébastien FOUTREL]

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  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  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

[Wallace]

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

[Wallace]

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

[Colin J. Brigato]

Hello,


> Le 25 sept. 2017 à 12:24, Wallace  a é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

[Raphael Mazelier]

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

[Gaël Demette]

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

[Wallace]

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 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 ... 

Re: [FRnOG] [BIZ] Refonte infrastructure

[Thomas Yoann]

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 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 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

[Eric Mognat]

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/

Re: [FRnOG] [BIZ] Refonte infrastructure

[Thomas Yoann]

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 Mazelier  a é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

[Raphael Mazelier]

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

[Raphael Mazelier]

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

[Eric Mognat]

Oui.

ça va, à mon sens, changer pas mal la donne.

Le 22 septembre 2017 à 04:42, Jonathan Leroy
 a é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

[Jonathan Leroy]

Le 22 septembre 2017 à 16:52, David Ponzone  a é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

[David Ponzone]

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, 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

[Jonathan Leroy]

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/

Re: [FRnOG] [BIZ] Refonte infrastructure

[Wallace]

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

[Alexandre DERUMIER]

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

[Sébastien Lesimple]

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

[Arnaud GRANAL]

"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

[Eric Mognat]

Le 21 septembre 2017 à 23:22, Wallace  a é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

[Olivier Meyer]

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

[Wallace]

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

[Wallace]

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

[Jean-Yves LENHOF]

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

[Kirth Gersen]

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

[Kirth Gersen]

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

[Wallace]

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

[Stéphane Cottin]

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

[Nicolas Girardi]

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

[Tristan Mahé]

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

[FRnOG] [BIZ] Refonte infrastructure

[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/