S3 1 To
S3 1 To
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

Docker : Compose a maintenant des spécifications officielles

Docker : Compose a maintenant des spécifications officielles

L’outil, permettant le déploiement de conteneurs dans le cloud sur plusieurs plateformes, n’avait jusqu’à présent pas de spécifications, s’en tenant à l’implémentation des développeurs. Il en a désormais.

Leur arrivée devrait permettre une normalisation de l’utilisation de Compose un peu partout.

L’outil a également une gouvernance ouverte, via une nouvelle communauté dont font partie Amazon AWS, Microsoft et d’autres acteurs du cloud.

Commentaires (8)

votre avatar

Alors, on fait dans les buzz word ? <img data-src=" />



Rien à voir avec le cloud ou les plateformes, Compose c’est un outil qui permet de monter un ou plusieurs containers (avec les volumes et réseaux qui vont bien) à l’aide d’un fichier yaml déclaratif. Au lieu de devoir lancer 1 ligne de commande pour chaque container, on lance le docker-compose qui va poper tout le nécessaire.



Du coup j’avoue j’ai un peu de mal à comprendre cette histoire de “spécifications officielles” <img data-src=" /> Même en allant sur la source je ne comprends pas bien ce qui change.



En plus les plateformes de Cloud privé ou public privilégient très fortement Kubernetes.

votre avatar







Obidoub a écrit :



Rien à voir avec le cloud ou les plateformes







Bien au contraire cela a tout avoir avec le cloud et les plateformes. Compose fonctionne avec Swarm qui a précédé k8s et meme si ce dernier a le vent en poupe et a quasi tué Swarm il reste encore plein de systèmes en production qui utilisent Compose.



C’est notamment très pratique pour déployer du multi container simple sans la complexité de k8s. De toute facon le format Compose fonctionne avec k8s donc l’évolution/upgrade vers k8s est facilité (cf la doc de “docker stack deploy” avec k8s).



Ce qui change avec la spécification officielle c’est que maintenant n’importe peut peut proposer une implémentation ou des outils (comme kompose par exemple) sans être a la merci d’un changement de specs. Enfin c’est expliqué dans l’annonce.



C’est aussi un moyen pour la société Docker de déléguer ce projet a d’autres …notamment Microsoft.


votre avatar

@Obidoub

Oui on sent que le/la rédacteur/rice de cette news ne maitrise pas le sujet.

&nbsp;

L’objet de cette spécification c’est d’établir un standard autour de Compose qui ne dépend plus seulement de l’entreprise Docker mais d’une communauté, dont quelques très grosses entreprises. Jusqu’à présent seule Docker maintenait l’ensemble des règles autour de Compose.&nbsp;

Quelque part, ça assoie un peu plus Compose dans le monde des containers.



Toutes les explications ici (en anglais) :&nbsp;https://github.com/compose-spec/compose-spec&nbsp;

votre avatar







kgersen a écrit :



Bien au contraire cela a tout avoir avec le cloud et les plateformes. Compose fonctionne avec Swarm qui a précédé k8s et meme si ce dernier a le vent en poupe et a quasi tué Swarm il reste encore plein de systèmes en production qui utilisent Compose.







Compose n’est pas lié à Swarm ! Il peut fonctionner en standalone et c’est ce qu’on lui demande de faire la plupart du temps.



Ensuite je ne vois pas le rapport avec le Cloud, Docker, Swarm et Compose fonctionnent sur n’importe quel serveur.







kgersen a écrit :



C’est notamment très pratique pour déployer du multi container simple sans la complexité de k8s. De toute facon le format Compose fonctionne avec k8s donc l’évolution/upgrade vers k8s est facilité (cf la doc de “docker stack deploy” avec k8s).







Là tu mélanges Swarm et Compose.







kgersen a écrit :



Ce qui change avec la spécification officielle c’est que maintenant n’importe peut peut proposer une implémentation ou des outils (comme kompose par exemple) sans être a la merci d’un changement de specs. Enfin c’est expliqué dans l’annonce.



C’est aussi un moyen pour la société Docker de déléguer ce projet a d’autres …notamment Microsoft.







Si ça peut permettre d’utiliser AKS ou ECS avec des fichiers Compose, c’est une bonne nouvelle. Je confirme que Kubernetes est beaucoup trop complexe pour la plupart des usages. D’un autre côté Swarm n’est pas utilisable en contexte multi clients…


votre avatar

Je crois comprendre que ça pourrait permettre d’utiliser des fichiers Compose pour d’autres plateformes que Docker et Swarm, par exemple directement sur un service dans le Cloud. Je trouve que c’est une bonne nouvelle.

votre avatar

on utilise k8s hors du cloud aussi…



c’est ton “Rien à voir avec le cloud ou les plateformes” qui fait réagir c’est tout.

votre avatar

Je me permet de répondre ici vu que je suis mainteneur de cette toute récente compose-spec :P



L’idée est de ne plus lier le format yaml des fichiers compose à l’outil docker-compose, qui en effet est dédié au développement sur une seule machine. Ca ne se réduit pas à simplifier de longues lignes de commandes comme tu le dis @Obidoub (chouette avatar :P), mais c’est un raccourci de langage acceptable.&nbsp;



Il y a en effet Swarm qui utilise aussi ce format dans la commande docker stack deploy, mais le format compose est aussi utilisé par Amazon ECS (avec qui on travaille sur cette spec) et permet de cibler Helm et Kubernetes, via l’outil Kompose (https://github.com/kubernetes/kompose) ou bien compose-on-kubernetes qui est distribué avec Docker Desktop.&nbsp;



&nbsp;On peut aussi évoquer des utilisations du format pour d’autres scénarios, comme CloudBees CodeShip qui s’en sert pour définir les environnements de CI.



Bref, on parle bien du format de fichier, et de ses diverses utilisation, et de comment le faire évoluer pour couvrir plus/mieux les cas d’utilisation. docker-compose (l’outil) devient alors “juste” une implémentation parmi les autres. Le pitch de la compose-spec parle bien de “Cloud Providers”, j’avoue que c’est un peu du marketing, même si on bosse en effet avec Amazon et Microsoft Azure, mais pour moi tous les usages se valent :P

votre avatar







ndeloof a écrit :



Je me permet de répondre ici vu que je suis mainteneur de cette toute récente compose-spec :P



L’idée est de ne plus lier le format yaml des fichiers compose à l’outil docker-compose, qui en effet est dédié au développement sur une seule machine. Ca ne se réduit pas à simplifier de longues lignes de commandes comme tu le dis @Obidoub (chouette avatar :P), mais c’est un raccourci de langage acceptable. 



Il y a en effet Swarm qui utilise aussi ce format dans la commande docker stack deploy, mais le format compose est aussi utilisé par Amazon ECS (avec qui on travaille sur cette spec) et permet de cibler Helm et Kubernetes, via l’outil Kompose (https://github.com/kubernetes/kompose) ou bien compose-on-kubernetes qui est distribué avec Docker Desktop. 



 On peut aussi évoquer des utilisations du format pour d’autres scénarios, comme CloudBees CodeShip qui s’en sert pour définir les environnements de CI.



Bref, on parle bien du format de fichier, et de ses diverses utilisation, et de comment le faire évoluer pour couvrir plus/mieux les cas d’utilisation. docker-compose (l’outil) devient alors “juste” une implémentation parmi les autres. Le pitch de la compose-spec parle bien de “Cloud Providers”, j’avoue que c’est un peu du marketing, même si on bosse en effet avec Amazon et Microsoft Azure, mais pour moi tous les usages se valent :P







Merci pour l’explication officiel ;)