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 terme de sécurité.
A+
Le 23 septembre 2017 à 08:23, Raphael Mazelier <[email protected]> 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/
