Reprise du message précédent :

 
note bien que nous on peut brancher des serveurs....  

 
La première diapo est un peu ironique je pense.
Ils refont des itérations ce qui est justement possible avec Docker.
Ensuite tu vois l'infra avec Chef et Docker pour mettre à jour l'image (   )

Oui, c'est tout le point à intégrer : patching = refaire l'image, modification = refaire l'image, évolution = refaire l'image.
 
Maintenant, c'est fait pour porter du micro-service et donc ça signifie releases courtes (agile/sprint/CI/chef-ansible-whatever).
 
Mais c'est surtout vu comme une possibilité de réduire les coûts, avant même de faire plus de qualité, un meilleur travail plus intelligent, ...
 
Bon, après, le point intéressant est que, globalement, le paradigme de toutes ces boites, c'est que Docker = réorganisation complète.
 
Par contre, et je le vois chez nous, les clients nous demandent de faire pareil ... mais sans changer l'organisation, c'est juste un levier "faire plus vite/moins cher".
 
hfrfc, tu me payes combien pour avoir plus d'infos sur Docker ?

Nous aussi

Oui s'il te plaît.

T'aurais pu faire un mp, parce que là, vu les quelques mots génériques, j'ai pas vraiment compris si tu étais sérieux ou non

Cette déprime que ça m'a foutu là, d'un coup...

 
Des bières si t'es dans l'est
 
Niveau organisation, ca devrait aller. On a des équipes de dev avec un bon lien vers l'exploit & prod et de l'infra pure (les autistes )

Euh, pas de redface, majuscule, c'était pas compliqué
 
Z'auriez une référence de carte/dongle wifi (c'est pour un PC fixe) correct et pas hors de prix?
 
J'ai une vieille trendnet mais pas de driver win 10 à remplacer.

 
Dommage, je suis dans l'ouest    
 
Après, je trouve que la forme énorme de Docker est côté exploitation :
certes le boulot de construction de la plateforme clusterisée est important, mais au moins on évacue côté exploitation la problématique de la TMA qui retombe côté dev.
 
Paradigme : un container contient des données volatiles
-> il faut stocker en persistant toute donnée nécessaire au bon fonctionnement (données de bdd, configuration, ...)
-> nécessité de réfléchir à l'usage des données statiques stockées sur un volume séparé
-> au démarrage d'une image docker, on gère l'intégration de ces données statiques
-> un container est stateless
 
Traduction en bon français : un container docker doit porter nécessaire l'intégration des données, il ne contient pas de données lui-même.
Les containers doivent s'auto-gérer pour les données, les logs, la configuration, ...
 
Donc si un container déconne en prod, on le détruit et on le recrée, peu importe ce qu'il contient
La recréation d'un container Docker va réintégrer toutes les données à partir du volume existant.
 
L'exploitation (alertes, astreintes, ...) en devient bcp plus simple : si ça merde, on arrête/relance.
si ça merde toujours, c'est lié aux données donc applicatif
-> responsabilité dev.
 
Donc, on se fait plus chier avec les patches, les alertes disques, ... et on se concentre sur le coeur de métier : la construction des plateformes avec la robustesse, la haute dispo, la scalabilité, ...
 
Par contre, côté dev, faut avoir le cul MEGA propre  

Moi je trouve le principe a chier

c'est l’évolution (assez) logique apres les VMs

Vous avez quoi comme "orchestrateur" pour l'automatisation de vos déploiements de machines/vms (sans pour autant aller jusqu'au portail self service) ?
On mene une reflexion en interne la dessus, on a pas mal de trucs automatisés, mais c'est des briques unitaires à chaque fois (genre un webservice pour le dns, un autre pour le dhcp, du puppet, un référentiel interne, etc ...).
Environnement full linux centos sur serveurs physiques et VMs.
A première vue il y aurait foreman ou puppet enterprise.
Du coté de chez Openstack, ya "Heat" qui pourrait peut-etre faire l'affaire ?
Ya aussi la solution de faire le machin completement à la mano mais on voudrait vraiment éviter.    
D'autres idées ?  

 
Je trouve qu'ya au moins autant d'avantage que d'inconvenients
sauf besoin specifique je vois pas l'intérêt pour la majorité d'entre nous

puppet / chef / ansible
pour aws, CloudFormation

dans un autre axe, plutôt ordonnanceur mais qui pourrait aider, rundesk.

Pour Docker, il y a clairement avantages et inconvénients ...
C'est un autre état d'esprit et de réflexion.

Comme j'ai une vue assez haute de ces sujets, je trouve que c'est assez pertinent dans c'est inscrit dans une urbanisation du SI adaptée.
Vouloir faire du Docker "parce que c'est à la mode", c'est complètement con.

 
Ok mais puppet / chef c'est la gestion de conf, on a déja ca.
C'est pas le machin qui fait que quand un serveur doit etre livré, il y a des étapes à dérouler avant même de faire un run de puppet (par exemple entrées DNS, configuration du port du switch, installation de l'OS, etc ...). C'est toute la partie autour qu'on cherche à automatiser, enfin surtout à relier les briques entre elles.
 
J'avais déja entendu parler de rundeck (et pratiqué, version 1.4.x il me semble), mais ca m'était completement sorti de la tête, ca pourrai convenir en effet !

 
C'est à peu près ce que l'on fait depuis 1995
 

 
Ca y'est, t'es vieux

powershell DSC

Mes deux cents concernant docker.  
C'est une re utilisation  des zones/containers avec une prise en main plus oriente dev avec le workflow de version du dockerfile/image.
Ca permet au dev de livrer non seulement l'application mais aussi les dependances de celle-ci avec bien moins de limites que les libs systems ( je pense python, ruby , node and so on ....)
 
Par contre cote reseau et secu il reste encore du boulot a faire  pour mieux empaqueter tout cela.  
 
Un bon moyens de jouer avec est de faire un tour du cote de Rancher (http://rancher.com/)  
 
Cote data le principe est que meme l'hote de doit rien contenir et pour tout ce qui doit etre persistant, cela va plutot etre sur du service type glusterfs/nosql/mongo/mysql et autres.
 
Cote reseau la mode est aussi a avoir des "overlay" network dans lequel tout les hotes se font un mega vlan et les container ont seulement leur ip prive. la jonction reseau public/container se fait via du nginx en mode proxy ou haproxy.
Par defaut un container ne peut pas chatter avec un autre, un lien doit etre creer ( bon c'est des rules iptables sur l'hote)
 
Cote secu ya des petite chose pas glop entre les uid dans le container et celle du systeme hote. la grosse recommandation reste de ne pas faire tourner un docker en mode privilegie (ie root) et de ne pas monter les fichiers/repertoire sensible de l'hote, qui de toute facon ne devrait pas avoir autre chose que le daemon docker ( cf coreos/rancheros ..)
 
 

T'as un retour sur coreos/rocket ? (apparemment rkt maintenant)

XaT

Le contenu de ce message a été effacé par son auteur

Je suis dans une petite boite mais on travaille pour une grosse boîte et on fonctionne 100% docker.
 
En gros :
- on dev, on push sur git
- à chaque push sur git, jenkins rebuild une image docker et la pousse dans le registry (tag: master)
- kubernetes détecte la nouvelle image et la déploie
-> on dev/test/corrige comme ça
 
- une fois que le dev est terminé, on merge sur une branch "recette", qui du coup build une nouvelle image docker avec un tag:recette
- en même temps, ça push sur le registry "client" pour qu'ils la déploient sur leur preprod (avec un dossier d'archi technique qui explique ce dont on a besoin, volume, accès IP, etc)
- ils font leur recette, ça fait des A/R bug/correctifs (notre image en tag recette est automatiquement push sur leur registryà).
- une fois la recette validé, ils déploient l'image sur la prod et c'est parti.
 
En prod ils n'utilisent pas kubernetes uniquement systemd (on fourni les .service qui démarre les dockers)
La prod n'a pas forcément d'idée de ce qui tourne dans les dockers et on a de tout (jetty, go, samza, node, ruby, etc).  
 
Je n'ai pas d'info particulière sur la manière dont ils gèrent le réseau chez eux.
Et là on va sûrement dégager Jenkins pour build directement sur gitlab.
 
Globalement ça marche très bien, pas eu de problème particulier. Ca tourne en prod.

 
ça, on sait que cette partie-là tourne "bien"    
 
Questions :
- Comment vous gérez le patching des images ?
Genre notamment, entre 2 devs, les évolutions des briques logicielles ? (versions mineures des haproxy, go, samza, node, ruby, jetty, ...)
 
- Comment vous gérez la surveillance applicative ? être sûr que les services soient bien rendus 24h/7j ?
 
- Comment vous gérez la partie "sources de données" (mysql, mongodb, nosql, glusterfr, cassandra, whatever, ...) ?

Bon je m'incruste aussi sur cette discussion au lieu de lurker comme un batard, je peux donner quelques réponses partielles.

- Comment vous gérez le patching des images ?
Genre notamment, entre 2 devs, les évolutions des briques logicielles ? (versions mineures des haproxy, go, samza, node, ruby, jetty, ...)
> Si c'est pas backward-compatible, c'est de la merde, pour le reste, on aligne nos dependances et on les fait évoluer de facon concertée
 
- Comment vous gérez la surveillance applicative ? être sûr que les services soient bien rendus 24h/7j ?
> Chaque service utilise une librairie de logging et d'instrumentation qui publie ses données sur un topic Kafka. Pour ce qui est 3PP, on transit par logstash
 
- Comment vous gérez la partie "sources de données" (mysql, mongodb, nosql, glusterfr, cassandra, whatever, ...) ?
> On monte des volumes, comme pour une VM classique en fait

   
 
C'est super intéressant mais ca parait quand même chaud à implémenter.
 
Sylver--- comment as tu fait pour implémenter cette architecture ? Vous avez fait appel à un prestataire ? Suivi une formation etc ?
C'est un fonctionnement comme tu décris qui m'intéresse, même sans aller à un tel degré d'optimisation.
 
Y'a un topic unique Docker au juste ?

Ça c'est nous qui le faisons et à notre convenance. Si y'a une version qui sort (genre go1.6) qui nous intéresse, on maj l'image de base et c'est tout. On a une image de base pour du jetty/nginx/go/samza/etc. Les dev ne savent même pas sur quelle version exacte ils devs.
 

C'est toujours un point un peu tricky ça. Kubernetes/systemd gère le fait que le docker tourne. Ensuite pour vérifier soit bien fonctionnel ça dépend. Sur nos docker jetty, on expose une API _ping qui peut être testé par un watchdog. Sur d'autres, on a parfois rien car on réfléchi à une "bonne solution" et c'est parfois pas simple. On sait qu'on a clairement de l’amélioration là-dessus mais depuis 18mois que des services tournent en PROD on a pas eu de retour critique là-dessus.
Si le docker n'arrive pas à démarrer (typiquement par que nginx n'arrive pas à résoudre un dns ), systemd essaye de le relancer constamment. J'imagine qu'à l'exploit ils ont des infos là-dessus et nous préviendraient si ils avaient des soucis
 

On a des elasticsearch/kafka dockerisés qui ont des volumes mappés où sont stockés les data. A la prod de faire les sauvegardes/duplications/etc.
Un volume ce n'est pas grand chose de plus qu'un chemin unix donc ça pointe vers ce qu'on veut.

Ah c'est sûr que c'est pas simple
Alors moi j'ai rien implémenté du tout. Le responsable technique de la boîte (qui est un des dirigeant) est une très très grosse tête et il a globalement mis en place tout ça tout seul
Je suis "leadtech" donc c'est mon boss direct et on discute pas mal du future/évolutions mais c'est lui qui a tout mis en place. Ce n'est pas mon taff de concevoir cette partie.
Et formation non, j'apprend tout sur le tas Y'a beaucoup de doc là-dessus un peu partout. J'ai accès à son cerveau dés que j'ai des questions aussi

 
Si tu as des liens sur la mise en place d'une telle infra, même simplifiée je suis preneur.
 
Je trouve beaucoup de doc sur Docker mais beaucoup moins sur l'intégration.

Je bosse dans une boite ou on à du workflow de build dasn tout les sens, et ça m'interesse beaucoup également si y'a tu aurait une doc sur ton infra ect
En ce moment je bosse sur le déploiement automatique de chroot de compilation, avec le paquet Icecc (qui permet de distribuer les compilations en temps réel) patché par mes soins pour pouvoir le faire tourner sur plusieurs ports (c'était hardcodé   ). Je viens de voir dans ton post que Gitlab permettrait de faire ce pourquoi je me casse les couilles depuis 2 mois  

moi, j'ai de la doc mais c'est interne à la boite, pas le droit de diffuser
 
par contre, si vous voulez mettre en place, vous pouvez venir chez nous/nous payer

 
j'adore quand ça m'arrive :
 
- j'ai galéré à faire ce truc ça m'a pris une semaine
- mais pourquoi t'as pas utilisé trucmuche pour le faire  ? c'est en standard  
-

 
Je sais pas à quoi carbure qemu, mais ça doit être de la bonne
En gros, il est super lent jusqu'à 15% et tout d'un coup, fusée

aigritude du matin :  
une demande pour remplacer un poste en panne  
symptôme : il plante 3 fois par heure en moyenne, écran noir et il faut le rebooter au bouton  
le client en mode "vous comprenez c'est chiant, on peu pas bosser comme ça, c'est une perte de temps toussa "  
 
après analyse le plantage c'est ........

Et la réaction du mec quand tu lui annonces le "problème" ?    
Sinon, y'a une veille/veille prolongée de programmée après 15 min ? Pas seulement l'extinction de l'écran ?    
Un peu con si c'est ça.

 
La stack « metal/VM pets/container cattle » est plutôt pas mal et c'est en fait la plus utilisée.
 
Le « chemin » habituel que j'ai constaté chez les boîtes que je croise :
 
* infra monolithique et app monolithiques -> si ça devient problématique, étape suivante
* infra plus souple (VM) et app monolithiques -> pareil, si ça devient merdique, étape suivante
* avoir des applis bien modularisées dans des VM -> si l'infra gonfle encore, étape suivante <------- la majorité des boîtes
* applis avec découvertes auto des services -> et là c'est soit cloud (privé/public/whatever), soit containers (soit les deux)
* à la fin, mirageOS
 
Au final, les containers c'est surtout pour rendre plus propre le process de dev, les VM vont servir à limiter les ressources des dits containers.
 
Les « gros » vont partir sur des trucs plus hardcore dès le départ, mais l'existant est lent à bouger. Le plus long c'est de modifier des applis existantes, ce qui n'est jamais fait IRL (ou modularisé morceau par morceau).
 
Et puis faut pas perdre de vue : faut que ça réponde à un besoin, et ça doit être pesé en terme de coûts

 
la coexistante c'est relou    entre le legacy ou les évolutions sont déjà planifiés jusqu'en 2019 et le web ou l'on sait pas ce qui sera fait la semaine prochaine c'est un peu chaud à gérer  

 
Justement, je me pose la question dans mon cas :
 
Actuellement, nos dev développent en local + git.
 
Quand c'est opérationnel, je crée un env. de test dans une ferme tomcat. Enfin ferme, c'est un peu exagéré. On a 2 Apache haproxy qui revoit sur la VM "pet" tomcat en question (pas de HA pour le tomcat).
Chaque application a son instance tomcat (catalina home identique, mais catalina base propre à l'appli).
 
Quand c'est validé & testé, je duplique l'env. de test en prod. (une autre VM tomcat pet) et on lance. Les 2 env. perdurent par la suite.
 
On arrive à avoir une certaine homogénéité mais je pense que les containers pourraient vraiment fluidifier le process. Je me trompe ?

Ça dépend la granularité que tu souhaites.
 
Dans ton cas, l'avantage que je vois c'est :
 
* d'avoir moins de surprise entre le poste local et la prod (puisque le local sera un container aussi).
* de plus avoir une VM tomcat "pet" mais une VM "docker" pet, peut être avoir moins de conf (m'enfin quand on a un template sous git..)
 
Si ça n'a jamais posé problème (ces deux points), je suis pas sûr que ça soit l'urgence absolue à passer sur Docker. Il y a peut être d'autres choses plus urgentes (CI ? CI couplée avec la virtu ? Meilleur workflow Git ? automatisation du process de duplication de l'environnement via des call sur l'API de ton système de virtu ?)

Attention si vous utilisez WSUS, n'installez pas le patch kb3148812! Même si on suit les infos de MS plus aucun client n'arrive à checker les updates une fois qu'elle est installé, et suivre la 1er étape donnée par MS empêche de revenir en arrière en désinstallant simplement le patch.

 
Valable uniquement sur 2012 ?