Docker, un outil permettant de créer des conteneurs logiciels, est maintenant disponible en version 1.12, après plusieurs mois de tests. Il s’agit d’une mouture majeure, qui s’accompagne de nouveaux clients pour OS X et Windows, d’une orchestration intégrée et d’une gestion simplifiée des plugins.
Docker 1.12, malgré une numérotation qui ne le laisse pas vraiment supposer, est une version importante de la technologie. Devenu standard de facto, cette solution de conteneurs logiciels dispose désormais de clients largement remaniés pour OS X et Windows, avec pour principal bénéfice une hausse des performances.
Les versions OS X et Windows abandonnent VirtualBox
Le changement le plus important est la prise en charge, sur chaque plateforme, de l’hyperviseur natif déjà présent, plutôt que d’utiliser VirtualBox. Sous OS X, c’est ainsi l’Hypervisor Framework qui est utilisé, tandis que sous Windows, c’est Hyper-V. Outre un fonctionnement décrit comme plus rapide, l’installation est également plus légère, mais réclame des versions récentes des systèmes pour fonctionner : Yosemite (10.10.3) et Windows 10. Le nouveau client est également disponible pour Linux. Ils permettent tous un débogage live des conteneurs en cours d’utilisation.
Mode Swarm et orchestration intégrée
Pour ce qui est de Docker Engine, la version 1.12 apporte tout d’abord une orchestration intégrée, alors qu’elle n’était jusqu’à présent présente que sous forme de plugin. Ce mode, baptisé Swarm, est un apport majeur puisqu’il permet à Docker de créer par exemple des applications utilisant des conteneurs multiples répartis sur des hôtes multiples, tout en pouvant les gérer sans logiciel supplémentaire. Cette orchestration permet aux administrateurs de définir l’état qu’ils souhaitent, Docker se chargeant alors du reste.
Comme on s’en doute, ce mode Swarm reprend toutes les fonctionnalités de Docker Swarm, utilisé auparavant comme produit séparé pour créer des clusters (groupes de serveurs). L’équilibre de charge est de la partie, et les communications sont chiffrées de bout en bout. Par exemple, le mode Swarm est encore désactivé par défaut, et Docker Swarm reste supporté. Surtout, l’équipe a bien pris soin de laisser le mode pouvoir être supplanté par d’autres outils, notamment à Kubernetes.
Une position renforcée par l'arrivée de Windows Server 2016
Outre de nombreux bugs corrigés, Docker 1.12 compte quelques apports supplémentaires, comme une nouvelle commande permettant de gérer les plugins. Des sous-commandes pourront ainsi s’occuper de l’installation, l’activation/désactivation, set, rm ou encore inspect. La liste complète des nouveautés peut être consultée sur le site officiel.
Notez que Docker devrait à nouveau renforcer sa position avec le lancement de Windows Server 2016. Disponible en Technical Preview 5 (la dernière) depuis environ deux semaines et lancé normalement fin septembre, le système Microsoft gèrera nativement les conteneurs créés par cette solution, en plus de ceux propres à Microsoft, d’ailleurs compatibles eux aussi avec Docker.
Commentaires (88)
#1
Docker & la containerisation, le futur du “.exe”.
Ce qu’ils sont en train de faire est une véritable révolution dans le monde informatique….
#2
@smux,
Pas sur que l’on puisse parler de révolutions dans ce cas. Le but n’est pas de remplacer un exécutable mais bien de lui permettre de s’exécuter dans des environnements contrôlés.
Cette évolution va surtout toucher le monde de l’IT, mais aura un poids bien plus limité sur le grand publique.
Reste que le fait d’être supporté nativement par MS va donner un vrai plus quand à l’utilisation de certains produits issus du monde Linux.
#3
#4
Une révolution ? Je trouve plutôt que c’est une régression. On en revient à la plus basse version du static linking, encore pire que sous les applis win32 et leurs brouettes de DLLs. L’informatique a évolué pendant des années à faire des logiciels dont les différentes dépendances se mettent à jour le plus facilement possible du monde, avec des gestionnaires de paquets, des installeurs automatisés, des signatures numériques des paquets pour la sécurité. L’avenir c’est maintenant de télécharger un OS léger non signé, créé par un type qu’on connaît pas et qu’on peut mettre à jour que si le paquet a été bien conçu.
On est dans le monde du freestyle le plus complet, un cauchemar de sysadmin, à moins d’avoir la structure adéquate au sein de l’entreprise. Quand on est pas chez les GAFA, Docker est une solution à un problème de développeur, pas un problème d’exploitant.
#5
T’en fais pas, je suis dev et j’ai toujours du mal à comprendre le principe aussi (il faudrait que je me penche sérieusement sur la question un de ces jours…)
#6
L’idée de base de Docker, c’est de faire un mini système d’exploitation pour faire tourner un unique logiciel dessus (serveur, généralement). On peut en créer des tas sur un serveur physique, selon les besoins et les relier entre eux assez simplement. Il y a de plus des outils d’orchestration, qui servent simplement à créer à la volée des dizaines, des centaines de ces serveurs en un clic (ou plus souvent, en une ligne de commande), à les démarrer et à les configurer.
C’est aussi pensé pour que les plans de ces mini-serveurs (un fichier texte de description), soient réutilisables et diffusables sur le net facilement.
#7
Comme tout ca dépend de comment on se positionne même en tant que sys-admin.
#8
#9
Même pour les dev, c’est de la merde.
#10
Une simplification assez facile à comprendre est de se dire que c’est comme de la virtualisation mais sans avoir à charger un système d’exploitation.
Le noyau du système hôte est partagé par les conteneurs qui s’exécutent.
Du coup tu as un peu le même principe qu’un .exe effectivement, ton application est “packagé” dans un conteneur docker qui contient tout ce qu’il lui faut en terme de librairie et dépendances.
#11
bémols
" />
" />
Ben dans les entreprises ou on utilise de plus en plus de dev à domicile , le plus gros problème est la taille des package à télécharger avec le temps que ça prend pour certains
Un des plus gros arguments c’est quand même de transférer des ko et des mo au lieu des go et de les mettre à disposition rapidement
Par contre c’est sûr que c’est pas destiné à la petite entreprise
#12
Pour les mauvais fermés à tous changements de leur vieilles habitudes : sans doute.
Pour les autres….c’est une solution avec ses avantages et ses défauts comme d’autres solutions
#13
Tu peux développer ton propos? Parce que normalement c’est le contraire, ça permet aux dev d’avoir un environnement “iso-prod” sur leur machine.
#14
#15
La conteneurisation est une techno qui n’est pas récente. Mais avant Docker c’était compliqué à mettre en oeuvre.
Je me demande où en est LXD par rapport à Docker. Quelqu’un sait ?
#16
Pour ceux qui ont du mal avec Docker, c’est pas bien compliqué ! Ça permet de déployer plus facilement des environnement (dev, prod, ce que l’on veut … ) très facilement et en bénéficiant de la clusterisation des instances de serveurs sur une même instance d’un OS tout en bénéficiant de l’allocation de core(s) et de mémoire au node deployé !
En gros c’est de la VM mais sans duplication d’OS et une légèreté et flexibilité accrue pour le déploiement d’applications.
Très pratique pour les gros serveurs hexacores multithreadé avec 64go de Ram, tu virtualises le tout !
C’est David Gageot qui s’occupe des nouvelles versions Windows et Mac et c’est made in France !
#17
Merci les gars pour vos explications :)
" />
#18
Merci pour l’argumentation pléthorique.
#19
Chaque ressource gérée par le kernel est exposée dans un espace de nom cloisonné. Il ne faut pas voir un conteneur comme une VM mais plutôt comme un processus wrappé par Docker et enfermé dans des namespaces.
#20
De rien j’ai fait des efforts ^^ … Je me serais permis d’argumenter si tu avais avance des éléments intéressants. Mais vu que tu ne connais visiblement pas la techno… Je préfère en rester la ( En toute modestie, je me considère pas comme un master sur Docker non plus).
#21
Je suis pas passé sous Docker, mais j’ai aussi des doutes.
On nous le vend par une facilité de déploiement, mais on déploie facilement des VMs avec Chef.
On est également ISO entre deux VMs.
Et le dev semble plus contraignant, (un service par container, tout ça…).
Au final, j’ai l’impression qu’on ne gagne qu’en RAM.
Mais au prix de la RAM, et du jour-homme, je ne vois pas une entreprise payer du dev pour ça.
Edit : OK, le temps que j’écrive mon message, il y a eu 2 pages de débats dans les commentaires…
#22
J’imagine que tu parles de LXC.
Docker et LXC utilisent tous les deux les mêmes technos dans le kernel de linux, c’est à dire les namespaces de process, de ressources (réseau, utilisateurs, etc). La différence, c’est le but recherché.
Docker vise à instancier un ensemble de minis machines virtuelles, avec un OS assez léger (c’est relatif…) avec un seul soft qui tourne en fond par vm et souvent peu de ports ouverts à l’extérieur ou aux autres machines dockers. On tisse un réseau de machines réutilisables pour un logiciel ou ensemble logiciel donné.
LXC vise plutôt à virtualiser un OS complet (sauf le kernel), et on peut travailler dessus comme si c’était une machine virtuelle à la VM Ware ou VirtualBox. On installe dessus tous les daemons et toutes les applis qu’on veut. Et c’est combiné avec ZFS ou d’autres technos pour dédupliquer les fichiers et éviter de dupliquer les fichiers identiques entre les différentes VMs.
Les deux ont leurs qualités et défauts, avec pour défaut commun, l’isolation des process encore approximative.
#23
Perso je m’en sert parce que c’est le moyen le plus simple que j’ai trouvé pour lancer des projet qui soient scalable, leger à l’execution et à l’envoie, et platform agnostic.
#24
Il y a un intérêt très fort avec Swarm ou Kubernetes, des déploiements massifs ou pour les environnements de dev sans se prendre la tête. En dehors de ces deux cas d’utilisations, je trouve que LXC, VM Ware ou virtual box, avec ansible, chef ou un de leurs copains font mieux le job, avec moins de risques et de coûts.
#25
Je trouve que rien que ça, c’est assez pour dissuader d’utiliser ça sur une petite prod.
#26
Docker m’intéresse, ayant un macbook pro et voulant faire les choses bien j’utilise actuellement Vagrant pour faire mes environnement de dev
Maintenant que Docker est passé en version stable et n’utilise plus virtualbox, j’hésite a lâcher vagrant.
Après je vois pas trop de “tuto” sur comment deployer un environnement pour symfony par exemple. Alors que Vagrant c’est assez simple
#27
Non, Je parlais bien de lex-dee (LXD) (cf:http://www.ubuntu.com/cloud/lxd). Et il me semble que LXD et Docker sont deux concurrent qui se basent tous deux sur la techno LXC pour la conteneurisation.
LXD et Docker sont des gestionnaires de conteneurs de la même façon que des hyperviseurs gèrent des VM.
Je n’ai trouvé que peu d’information sur LXD et donc je ne sais pas où il se positionne par rapport à Docker point de vue fonctionnalités et utilisabilité. Mais il semble que LXD soit exclusif à Ubuntu et donc plus limité que Docker en terme de cas d’utilisation.
#28
#29
#30
Si je comprends bien, c’est une surcouche user friendly à LXC. LXC a pour défaut d’être un peu roots sur la partie branchement au réseau des conteurs. C’est pas très bien documenté, pas clair et des docs sur le net se contredisent.
Les commandes de lxc ressemblent pas mal à celles de Docker et l’intégration OpenStack c’est pas mal non plus. Ça semble beaucoup destiné à aguicher les personnes déçues par Docker.
En tous cas, merci, j’avais vu la niouze pour LXD mais ça m’était sorti de la tête. Je vais creuser.
#31
@zozourban
Attention avec MacOS il y a de gros problème de performance sur les volumes.
https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bo…
Ça se contourne mais c’est galère quand on collabore des utilisateur de MacOS (enfin surtout pour eux ;-p)
@damaki
Docker en soi n’est pas mauvais, j’ai quelques prod qui tourne dessus et ça se passe bien finalement.
Par
contre le souci ça vient plus de la qualité des images disponibles et
le fait qu’elle sont pour la majorité prévu pour un environnement de dev
dont la seule préoccupation est de faire tourner les applications mais sans
considération de performance ou de sécurité, du coups faut passer du
temps pour se tenir des images à jour… (d’ailleurs ils ont senti le
business de ce coté, le Docker Store va certainement servir à fournir
ce type d’image)
#32
Totalement d’accord. Et vu les inconvénients, j’ai trouvé Docker difficile à justifier sur une prod avec peu d’applicatifs, instanciés grand max 4 fois, et une équipe d’exploit de taille réduite, ou pire sur mes projets persos avec un dev/exploit/homme orchestre. Sur une petite prod, les outils légers devops à la Ansible font nettement plus l’affaire.
Tout est question d’environnement cible, à mon sens.
#33
#34
Je trouve qu’il n’a pas tort sur deux points :
Par contre la micro-segmentation et les notions de stateless qui vont avec est une philosophie très très interessante et je pense qu’il est passé à coté de ce point.
#35
L’intéret de Docker ne réside pas que dans son mode de virtualisation (en gros, c’est de la paravirtualisation, ce qui existe depuis des années, notamment chez IBM/AIX mais aussi OpenVZ & cie, c’est à dire qu’on ne virtualise pas une machine avec son bios, mais juste l’OS, du coup il n’y a pas vraiment de “boot”).
L’intérêt de Docker c’est de croiser paravirtualisation avec la configuration descriptive: Une image Docker tient généralement dans une petit fichier texte qui décrit tout ce que contient l’instance. Quand on démarre une instance, Docker va télécharger tout ce qui est décrit dans le fichier texte et démarrer l’ensemble dans un ordre prédéfini.
Avec Swarm, on peut même définir des clusters de plusieurs instances.
Par contre effectivement, Docker est un outil “DevOps”, où le développeur est responsable de son environnement. Ca laisse peu de place à des purs sysadmins (mais qui est encore pur sysadmin ?).
Une image Docker utilisable en prod doit être créée et maintenue conjointement par les devops et les sysops. On est pas censés mettre en prod des images docker publiques (sinon je sais pas quelle est la valeur ajoutée de l’entreprise qui met ça en prod…). Les images publiques sont par contre très pratiques pour tester un logiciel rapidement sans se poser de question, et le désinstaller sans laisser aucune trace (suffit de supprimer l’instance, rien n’aura été modifié sur l’OS hôte).
#36
C’est pas en dev que j’ai rencontré les soucis, avec Docker. J’ai pas les mêmes contraintes avec 12 Go de ram sur ma machine de dev, et je le fais tourner sur une Manjaro, hébergée elle même sur du VM Ware sur un Windows. C’est du côté du transfert des images docker et du débogage des soucis sur ma préprod que c’était horrible. Si t’as pas un débit potable et que tu dois retransférer des images dockers plusieurs fois par jour, voir par heure pour tester, c’est juste pas la peine.
Là où je luttais à transférer mes images docker, en utilisant des paquets debian et des transferts de fichier avec Ansible, ça va mille fois mieux.
Sur alpine, j’ai rencontré des soucis avec des ensembles de paquets pas présents dans les repos officiels, ça allait largement plus vite de prendre une image Debian, avec tous les soucis de transfert des images que ça implique. J’ai rien vu d’insoluble, c’est juste que c’était clairement pas rentable pour mon cas. Et ça m’a donné une certaine vision de l’environnement requis pour que ça soit rentable.
Et au sujet d’Alpine, j’avoue que je reste pantois face à la volonté des créateurs de pas utiliser glibc dedans. Ça a un tel potentiel de merdouillage d’utiliser une lib moins mature, que j’hésite à utiliser ça.
#37
Hello
D’après ce que j’ai compris de Docker, et ce que personne ne souligne, c’est qu’une image docker écrite pour un moteur docker tournant sous windows ne pourra pas fonctionner sur un moteur docker tournant sous linux.
C’est la grosse différence avec les VM, qui, certe, sont grosses et lourdes et nécessitent une administration systeme, mais qui permettent aussi de s’affranchir de l’OS hôte.
Pour moi, un conteneur docker, c’est un peu comme une application portable, avec en plus une gestion des frontières de communication ( gestion des ports en entree/sortie ), ce qui permet un peu de jouer au lego avec les différents conteneurs pour arriver à construire son application.
Mais je peux me gourer, je ne suis pas spécialiste…
#38
Perso le plus gros soucis que je rencontre avec Docker c’est d’avoir quelque chose qui fonctionne comme prévu ^^ . En gros si tu veux du Docker tu t’orientes vers un cluster de servers, il te faut un outil d’orchestration. Et pour faire le bootstrap de la base il va déjà falloir faire un peu de boulot avec des scripts pour les backups, et le redéploiement du cluster si tout part en couille.
" />. Mais des fois on se fait peur a voir le nombre de container nécessaire pour lancer une application.
Une fois que tu as ta base c’est pas fini car il faut trouver un moyen propre de tout faire au niveau cluster et non plus au niveau OS. Par exemple avoir une solution pour pouvoir lire et surveiller tes logs… solution qui en générale dépend d’autres services comme elastic search qui elle même demande pas mal de services. Ou encore avoir des solutions pour partager les infos entre machine comme Etcd, et ensuite mettre en place des solutions pour gerer le DNS, le LB entre les containers, ne pas oublier que les données en container ne sont pas persistantes et qu’il faut créer quelque chose pour les sauvegarder, etc. Une fois que tu as fini tout ça et si ton cluster ne s’effondre pas tu peux commencer a jouer
Bref si tu veux que ton appli soit dockerisee en prod de manière complète comme c’est vendu sur la plaquette publicitaire c’est un sacre boulot.
Au niveau dev c’est plus simple. Tu peux te faire pleins d’images docker “utilitaires” pour réaliser certaines taches, sans pourrir ton OS avec pleins de lib et paquets.
#39
#40
#41
#42
Étonné de ne voir personne parler de scalabilité, partage/économie de ressources et de résilience.
Car ce sont ceux-ci qui font l’intérêt de l’engine par rapport à une banale VM.
Il faut bien comprendre que Docker ce n’est pas fait pour de la petite prod (bien que ça peut l’être).
Et c’est bien pour ça que j’ai évoqué les trois point plus haut, il est tout de même foutrement plus facile de mettre en place une architecture de 100+ nodes via Docker qu’avec des VMs.
Outre l’aspect prod, la techno est vachement utile dans les process de CI également (test u/fonctionnel dans un environnement sain et iso-prod par ex.)
Après le gros downside c’est la gestion de la persistance des données qui est un vrai casse-tête :/
Bref, un an que j’utilise Docker en projet, c’est pas encore parfait mais on y arrive :)
#43
Je viens de terminer la mise en place d’un workflow pour une API node que je développe en perso.
GitLab (sources) -> push/merge -> gitlab-ci-runner (build) -> docker run -d.
Avec un webhook pour delete le container lancé une fois la branche supprimée.
Résultat des courses, chaque changement trigger un nouveau container (+ un mongo tout frais, non pollué) qui host et expose l’API.
Et c’est une révolution. Ça permet de load-balancer ses utilisateurs en quelques secondes si une nouvelle version de prod tourne mal. Ça permet de tester iso-prod le moindre push sur une branche. Ça permet de run chaque UT avec un mongo tout frais (et des datas non corrompus par d’autres tests). Et par dessus tout ça, aucune perte de performances pour le serveur puisqu’on parle pas de VM.
Bref, docker de mon point de vu, c’est du tout bon. Le seul point “noir”, j’ai trouvé difficile de rentrer dans le vif du sujet. C’est peut être moi le problème, ou le fait d’intégrer ça au milieu d’un gitlab je ne sais pas. Dans tous les cas, une fois qu’on a bien compris le fonctionnement et toutes les options disponibles, c’est un régal.
#44
#45
#46
J’utilise des mots-clés. Quand on parle de git, on fait un push, pas un “poussé”. C’est compréhensible comme commentaire, faut pas pinailler pour des petites choses comme ça ^^ c’est un poil ridicule.
#47
Ce sont des mots clés également. Renseigne-toi dans ce cas avant de critiquer pour le plaisir :)
Container -> cf. la documentation de Docker.
triggers/delete -> cf. doc de GitLab et de git.
Merci.
#48
Comment tu peux utiliser en prod un truc qui n’a aucune persistance de données ?
Je comprends le principe de Docker mais me faudrait un exemple concret d’utilisation, parce que jusque là tout ce que j’ai vu c’est des mecs qui lancent une instance en disant “ lol c’est trop bien” (je caricature)
#49
#50
Article sur un produit hyper technique destiné aux personnes dont c’est le métier.
Et devine quoi ? Dans le métier (l’IT) on utilise plein de terme technique anglais !
Ca n’a rien a voir avec “se la péter” c’est juste une déformation pro
#51
oué donc en fait tu externalises ton stockage du container.
#52
#53
Et on a pas attendu les container pour faire ça, c’est une bonne pratique à avoir meme en dehors de ce context.
#54
C’est pas grave laisse.
Je pense que faut laisser tomber avec ce genre de personnes ^^ J’ai essayé de me faire comprendre gentillement en lui répondant 2 fois mais visiblement on est face à un troll (ou un fanatique de la langue française je ne sais pas) :p
#55
évidemment.
Mais j’aimerais qu’on me propose une application concrète de Docker en prod
#56
AU dernier Devoxx, il était installé en France, après peut-être que cela à changé
#57
#58
#59
#60
#61
Essais donc RocketChat ;)
Facile à déployer et à scaler et propose officiellement des bots simple à programmer (pour saturer ton serveur et forcer le scaleup).
#62
c’est pas une application concrète c’est pour jouer dans une sandbox.
Apparemment certains ici utilise Docker en prod, ca m’intéresserais de savoir ce qu’ils font exactement avec en prod, et pourquoi ils ont retenu cette solution.
Ces personnes peuvent me MP si elles ont peur d’en dire trop en public
#63
De ce que j’ai compris, pour ma part, cet outils permet de s’inscrire plus facilement dans une démarche de “Continuous Delivry”https://en.wikipedia.org/wiki/Continuous_delivery .
C’est plus pour répondre à une problématique organisationnelle et donc de réduction du coût de la fabrication de logiciel que pour répondre à un problème technologique ou fonctionnel du logiciel produit.
Je ne sais pas si je suis clair. :-/
#64
Yep complètement. Rancher est pas mal mais leur solutions de convoy aussi même si elle est pas vraiment utilisable avec GlusterFs car ayant des performances anémiques. Le mieux reste du NFS, mais du coup il faut setup un cluster NFS ^^ .
Sinon tu as Scaleway qui est pas mal pour du clustering lowcost avec SiS qui est un S3 (meme API) pas cher (mais pas encore dispo).
#65
#66
#67
#68
#69
Tu utilises quoi comme outil d’orchestration?
#70
#71
Ah enfin ! Merci.
Là c’est clair, et en plus tu montres en quoi Docker devient intéressant.
#72
#73
#74
j’ai juste survolé les possibilités. Par exemple, le container redmine intègre un mini serveur http et une mini bdd (sqlite). c’est suffisant pour le groupe qui veut faire une évaluation.
Pour le projet de dev, j’ai téléchargé le container mySQL et j’ai “relié” le container redmine du projet de dev au container MySQL. Suffit de modifier 2 lignes dans Docker pour que redmine utilise mysql.
Par la suite je pourrais installer un container Postgresql ou un container plus récent de MySQL pour tester une migration: par exemple un clone du container redmine projet + le container Postgresql. Et si ca fonctionne, ca passe en prod.
Je peux aussi télécharger un container de httpd (apache) ou Nginx pour remplacer le serveur http intégré du container redmine. Idem, je peux faire un test en assemblant les containers avant de passer le tout en prod.
Avant Docker, je me débrouillais pour faire des installations “portables”: chaque appli/service installé dans son répertoire dédié, et pas mal d’huile de coude dans les fichiers de configuration pour lier les applis/services entre eux.
Docker simplifie tout ca. Perso, je vois ca comme du “portable-apps” pour serveur.
#75
Très mauvaise idée de mettre plus qu’un process dans un container …
Les best-pratices conseillent d’en lancer qu’un seul et quand on voit ce que peut donner un process zombie sur l’hôte …
En passant par du docker-compose tu pourrais te simplifier un peu plus la vie à niveau là par ailleurs (si jamais ce n’était pas encore fait) ;)
#76
Avec 1 process par container tu te retrouves pas a consommer plus de ressources au final ?
#77
Pas nécessairement, par défaut les conteneurs ont une empreinte mémoire très réduite (mais peut être contrôlé).
Docker a adopté la philosophie du micro-service, un conteneur ne fait qu’une chose mais il le fait bien.
Et c’est grâce à celle-ci que le scalling et la resilience sont possible sans trop d’effort.
Prenons le cas du container redmine de 127.0.0.1, le serveur web à besoin d’être mis à jour. Qu’est-ce que tu fais ? Tu rebuild entièrement l’image pour faire la màj ? Tu as attends une màj de redmine pour faire les deux en même temps ?
Pas très pratique, car tu t’obliges à faire un build inutile et tu devrais par la suite couper ton conteneur puis enfin lancer le nouveau (en admettant que tu n’as pas de reverseproxy et de load-balancing).
Découper au maximum les processus dans leurs propre conteneur permet d’avoir plus d’agilité sur leur maintenance :)
#78
Scaleway ne fait maintenant plus exclusivement du ARM ^^ .
#79
Merci de traduire ton propos en français lisible …
#80
Vous vous passez le mot entre personnes aigris ou pas ? Lis les commentaires plus bas, j’ai déjà expliqué pourquoi mon commentaire contient des mots Anglais. C’est très clair, très compréhensible. Ce sont des mot-clés des différentes technos que je cite.
Ensuite mon commentaire n’a pas vocation à te faire comprendre ce qu’est Docker ou Git si tu ne le sais pas. Il y a de la documentation pour ça. Donc si tu comprends pas, tu lis la doc, ou tu te rends à des meetups.
Merci :) Très constructif.
#81
#82
Une analyse plus compléte et technique des nouveautés de cette version: https://goo.gl/L8YvYS