@jmmills Ne pouvez-vous pas démarrer vos conteneurs tels que : "docker-compose scale worker=5" et ce service commencerait par 5 ?

@aanm Oui, mais je pense que cette fonctionnalité devrait être reflétée par défaut dans la définition du service. Peut-être que j'ai un ensemble minimal de travailleurs qui devraient toujours être en cours d'exécution et je veux que cela soit clairement déclaré par défaut.

@ @aanm Vous attendez-vous à ce qu'un docker-compose up prenne en compte le paramètre scale ? Le seul problème que je vois avec cela est que nous introduisons des paramètres dans la configuration déclarative qui ne sont PAS compatibles avec les concepts sous-jacents de l'API Docker / Docker mais très spécifiques à Docker Compose.

Si nous devions faire cela à l'avenir ; Je suggérerais quelque chose comme :

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

Où $<parameter> désigne une chose spécifique à Docker Compose.

Nous avons fait des allers-retours pour savoir si scale appartient au YAML ; il y a eu un PR pour l'ajouter avant (#630). Je suis toujours d'avis que la plupart des gens ne devraient pas mettre de numéros d'échelle dans leur configuration, car cela la rend moins portable, mais je comprends les cas d'utilisation pour le faire.

Maintenant que nous avons un moyen rudimentaire d'augmenter les fichiers Compose avec extends (et, espérons-le, bientôt de meilleurs - #1380, #758), les préoccupations que j'ai soulevées dans https://github.com/docker/compose /pull/630#issuecomment -69210279 sont peut-être moins un problème.

J'aimerais définir scale=0 dans mon yml pour les services liés aux tests que je ne veux normalement pas démarrer. Je veux seulement créer ces services explicitement avec docker-compose run ou un scale explicite.

@jamshid J'ai souvent voulu ça, une définition qui configure un environnement mais ne s'exécute pas par défaut. J'ai été relégué à la création d'une image de base (avec laquelle une échelle zéro/sans opération aiderait également) dans laquelle j'exécute mes tests unitaires (via docker run ), puis ma composition de conteneur consomme le image de base.

Quelque chose comme ça semble assez utile pour les configurations de développement

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

@jamshid @jmmills Qu'en est-il d'un paramètre/clé enabled dans le fichier YAML par service ? De telle sorte que vous puissiez désactiver/activer un service ?

@prologic Pourquoi faire cela alors que le paramètre a "scale" résoudrait les deux besoins ?
Si vous voulez imaginer un processus/conteneur en cours d'exécution comme une instance d'une classe, on pourrait même le nommer instances

@jmmills J'essaie juste de trouver une _solution_ à votre cas d'utilisation qui n'implique pas de casser le docker-compose actuel en tant que tel. J'ai tendance à penser que scale=0 ne semble pas si approprié et je me demande si scale=X devrait même faire partie de Compose lui-même.

À mon avis, l'échelle (ou le nombre d'exemplaires) fait partie de la composition d'un service, elle devrait donc être incluse dans composer.

Eh bien, je pense que nous avons soit une clé scale=0 ou disabled .

:+1 : sur la possibilité de définir une taille par défaut scale pour une instance. Et je suis d'accord, une fois que l'échelle est insérée, il n'est pas nécessaire d'avoir une clé disabled , car vous définiriez simplement l'échelle sur 0.

+1

En outre, un autre cas d'utilisation : que se passe-t-il si je veux mettre à l'échelle le nombre de conteneurs mais ne veux pas mettre en arrière-plan tous les services, ou dois passer à un autre terminal (ou processus) et définir mes numéros d'échelle...
par exemple:

$ docker-compose up && docker scale thing=4

Ne fonctionne pas car up ne sort pas.
Mais si mon fichier de composition fixe l'échelle de mes conteneurs...

$ docker-compose up

Devient DWIM.

Je ne suis pas sûr d'aimer vraiment ça; tout d'un coup, up prend deux capacités :

• Affichez tous les conteneurs qui n'ont pas scale paramètre
• Apportez tous les conteneurs qui ont scale=0 .

Nous abusons maintenant vraiment de la commande "up". « Scale » prend également un nouveau sens dans la mesure où il fait maintenant deux choses :

• mettre à l'échelle les conteneurs vers le haut/bas
• Désactiver les conteneurs/services via ` scale=0

Pourquoi afficher des conteneurs avec un scale=0 ?
Build construirait des images avec un scale=0 , facilitant ainsi un besoin d'image de base.

Je _pourrais me tromper_ mais en lisant votre dernier commentaire, cela impliquait en quelque sorte que :)

Permettez-moi d'élaborer :

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

Maintenant, comportement attendu : docker-compose build construit tous les conteneurs avec « build » (la composition extrait-elle des images externes lors de la construction ? Je ne m'en souviens pas), docker-compose up exécuterait n'importe quoi avec une échelle positive (la valeur par défaut est 1), docker-compose run test_harness construirait "base_thing" si nécessaire et exécuterait ma seule commande. Avisé ? :)

Edit : docker-compose up exécuterait 1 "thing" et 4 "workers_for_thing"

D'accord merci; votre exemple est un peu plus logique et un peu plus clair quant à l'intention de scale=0

Je pense que docker-compose "tire" des images sur up / run .

J'ai besoin de créer une recette, d'indiquer le nombre de dé-intances (échelle), pour le test, la production, le contrôle qualité, etc.

+1 pour scale=X . Ce serait très utile.
Et +1 pour le commentaire @jmmills avec la description de la configuration et les résultats attendus.

Yay! pour scale=x . L'initialisation d'un ensemble de conteneurs aiderait certainement à identifier les conditions de concurrence potentielles lors de la configuration des configurations de cluster.

+1 pour scale=x (y compris scale=0 pour désactiver les services pour le docker-compose up initial)

+1 pour scale=x .

x est NaN, je proposerais -1 place.

+1 pour échelle=x.

+1

+1

Et si on s'arrêtait avec les +1, s'il vous plait ?

+1 est utile pour voir le niveau d'intérêt pour une fonctionnalité.

@shofetim Je connais une meilleure façon de le faire : implémenter la fonctionnalité en question et envoyer une pull request...

+1ing est également un bon moyen de voir les gens s'entendre sur une solution proposée. Son comportement assez courant sur github. Cliquer sur le bouton de désabonnement des notifications les désactivera en cas de problème.

Eh bien, on dirait des gens comme ça. Il y a un élément similaire dans le backlog de composition (resté de Fig), je suis presque sûr d'avoir fait un commentaire à ce sujet à un moment donné. J'essaierai de faire un suivi plus tard ce soir.
Je suis à PuppetCon la majeure partie de cette semaine, donc j'espère que cela me donnera du temps de hack - je vais voir si je peux écrire ceci.

Voici une solution de contournement pour le cas d'utilisation "scale=0":

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

@wkonkel ouais, j'ai fait des choses similaires dans le passé.

Je travaille actuellement à me familiariser avec la base de code de composition, une fois que je sais où sont toutes les choses pour composer, je vais pirater un PR pour un paramètre de configuration d'échelle.
Il ne semble pas que cela va être trop difficile, il existe une méthode scale pour un projet qui est le backend de l'interface cli, donc tout ce que je devrais vraiment faire est d'ajouter "scale" au schéma de champ, assurez-vous que s'il est présent pour l'appeler après la création du conteneur... alors assurez-vous qu'il n'exécute pas un conteneur s'il est défini sur zéro.

Il y a en fait un très vieux PR ouvert pour cela : #630.

Le problème est que l'échelle est une préoccupation opérationnelle, elle ne fait pas partie de la définition de l'application, elle ne correspond donc pas vraiment au fichier de composition.

Ce serait bien de prendre en charge une configuration pour un niveau d'échelle par défaut, mais je ne pense pas que le fichier de composition soit le bon endroit pour cela.

Le cas de scale: 0 devrait déjà être traité par #1754. Un conteneur "no-op" peut simplement avoir une commande qui se termine immédiatement (echo, true, etc.). Les cas pour lesquels scale: 0 sont généralement l'un des deux suivants : des conteneurs de volume de données ou des « tâches adhoc/admin ».

Très bientôt, nous ne devrions plus avoir besoin de conteneurs de volumes de données, car les volumes reçoivent de nouveaux points de terminaison d'API et nous pourrons définir des volumes sans avoir besoin d'un conteneur.

Les tâches administratives sont mieux gérées avec #2051. Vous pouvez définir admin.yml qui étend le noyau docker-compose.yml et vous permet de lier vos tâches administratives à la « composition du noyau » sans brouiller la définition de chacune.

Ces deux changements sont maintenant dans le master et seront disponibles dans la version 1.5.0 (qui approche à grands pas).

Cela ne laisse donc que le cas de vouloir mettre à l'échelle un service à > 1 par défaut. C'est déjà assez facile de scripter quelque chose comme ça, mais pouvoir le mettre dans un fichier de configuration serait toujours agréable. Je pense que nous allons explorer l'idée d'une configuration séparée dans #745. À mon avis, cette nouvelle configuration serait un bon endroit pour des choses qui ne font pas partie de la définition de l'application (nom du projet, nom du réseau par défaut, échelle par défaut, etc.).

Je ne suis pas d'accord avec le fait que l'échelle ne soit qu'une préoccupation opérationnelle. Les applications peuvent se soucier du nombre minimum de services en cours d'exécution.
En ce qui concerne le conteneur sans opération, il semble difficile d'exécuter un conteneur lorsque le but de ce conteneur est de déclencher une image de base à construire dans laquelle d'autres conteneurs utilisent pour leur champ image .

Les applications peuvent se soucier du nombre minimum de services en cours d'exécution.

Pouvez-vous donner un exemple de ce cas ?

En ce qui concerne le conteneur sans opération, il semble difficile d'exécuter un conteneur lorsque le but de ce conteneur est de déclencher une image de base à construire dans laquelle d'autres conteneurs utilisent pour leur champ d'image

Y a-t-il une raison pour laquelle l'image de base doit faire partie de la même version ? Comme je l'appelle dans #1455, composer n'est pas principalement un outil de "création docker". Son objectif est de fournir une composition de conteneurs au moment de l'exécution. Essayer de prendre en charge tous les scénarios de génération possibles augmente considérablement la portée de la composition et détourne l'attention de la composition de conteneurs. Il serait difficile, même pour un outil conçu autour de la création d'images, de prendre en charge chacune de ces demandes. Je pense qu'une meilleure direction est de garder autant de complexité de construction hors de la composition, et de laisser les utilisateurs échanger dans l'outil de construction approprié à la place de docker-compose build .

Le cas d'utilisation qui m'intéresse est scale=0 (peut-être que abstract=true serait un meilleur descripteur). Je souhaite partager des images et des variables d'environnement entre différentes commandes. Plus précisément, je veux un serveur Web en cours d'exécution et un serveur de tâches en arrière-plan en cours d'exécution, tous deux avec le même code et les mêmes variables d'environnement.

@wkonkel en utilisant votre exemple, je suppose que cela fonctionnerait également ?

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

Vous échangez avoir un service abstrait avec un remplacement sans opération command pour aucun résumé avec un remplacement sans opération sur ports . Cela sonne-t-il juste ?

1988 est lié aux services abstraits.

@dnephin Oui, cela fonctionne dans mon cas.

En fait, je retire cela... Je viens de l'essayer avec docker-compose-1.4.2 et il semble que "ports: []" ne remplace pas le parent, donc l'app_worker ne démarre pas avec "le port est déjà alloué ".

@dnephin Le fil a peut-être une meilleure explication, mais je vais essayer de l'articuler ici.

Le premier qui vient à l'esprit est celui des systèmes de travail où des conteneurs séparés exécutant le même code pourraient être modélisés comme un type de service parent->fork()->child pool dans lequel la configuration d'application par défaut veut un nombre minimum de travailleurs pour la simultanéité.

Mon inspiration pour cela est venue d'une application qui utilise des travailleurs RQ attachés à différentes files d'attente qui partageaient une image de base qui contenait mes packages python (code de travailleur), mais avait plusieurs instances en cours d'exécution pour chaque file d'attente. La disponibilité minimale de la simultanéité était une exigence de l'application en raison des travaux de longue durée.

Je pense juste qu'avoir une commande no-op semble être un gaspillage de ressources juste pour obtenir une image de base partagée construite de la même manière que le reste de la pile d'applications. Vous vous retrouvez avec une boucle while/sleep juste pour une image de base, ce qui est une solution de contournement intéressante, mais ne semble pas être un moyen intuitif d'y parvenir. Sans oublier de laisser un élément dans notre arbre de processus sans fonction d'exécution.

Si docker-compose ne doit vraiment pas passer au domaine de la codification des relations de construction d'images, alors peut-être que l'option de construction devrait disparaître, et d'autres systèmes de définition de construction devraient être créés afin que je puisse définir une cible de construction pour construire une image de base , puis d'autres images qui consomment cette base avec quelques-uns des artefacts/configurations modifiés, et dans le bon ordre ?

Ou peut-être que je suis juste trop opiniâtre et que je devrais envelopper mes commandes de composition docker dans des scripts shell pour démarrer mes services avec scale et définir toutes mes images comme des cibles de make avec des dépendances.

Je pense juste qu'avoir une commande no-op semble être un gaspillage de ressources juste pour obtenir une image de base partagée construite de la même manière que le reste de la pile d'applications.

Avec #1754 (dans la prochaine version) ce n'est plus nécessaire. Un service peut sortir et il n'arrêtera pas le reste des services. Ainsi, vous pouvez simplement sortir la base sans vous en soucier.

@dnephin Cool, alors link à ce conteneur de base/intermédiaire afin de vous assurer qu'il est construit en premier ?

@dnephin : J'ai un coureur CI qui fait l'équivalent de docker compose up . Je veux que mon environnement de test s'exécute avec plusieurs versions d'un service (c'est-à-dire, à l'échelle). Je pourrais copier tout le bloc de configuration mais cela impliquerait de me répéter. Dans ce cas, ce n'est pas "juste une préoccupation opérationnelle", c'est quelque chose dont j'ai besoin dans mon environnement de développement pendant que je développe une application en cluster, qui est actuellement entièrement décrite comme un fichier de composition. Pour le moment, je devrais avoir une configuration d'échelle hors bande, puis invoquer d'une manière ou d'une autre docker-compose scale , je suppose, mais cela ne semble pas idéal et introduit de nouvelles opportunités d'échec et de course.

Dans les cas de production, vous souhaiterez peut-être commencer vos services avec une échelle minimale. Disons par exemple que vous migrez d'un cluster à un autre, et gardons certaines parties difficiles de la migration en tant que données de copie pour la simplicité de l'exemple ; et vous devez vraiment commencer à gérer du trafic dès le début, vous devez donc déployer avec docker-composer au moins (n) instances de certains services, disons web.

Avoir une échelle sous le service sur le fichier de configuration gérera vraiment cela. C'est également un cas d'utilisation de convivialité, car si le cas d'utilisation expose en fait l'exigence d'avoir au moins (n) instances d'un service en cours d'exécution et pas seulement une au point de départ.

De mon point de vue, l'échelle est en fait un paramètre déterminant d'une topologie et d'une composition.

@dnephin

Pouvez-vous donner un exemple de ce cas ?

Consul, MariaDB Master-Master ou toute autre application distribuée sur Swarm doit vraiment avoir au moins 3 nœuds en cluster pour être fiable. Il existe certainement des cas d'utilisation pour le nombre de services disponibles dans le fichier de configuration, je ne comprends pas pourquoi vous êtes si contre. Gros :+1: de moi ici.

Je ne suis pas contre un moyen de configurer l'échelle, je ne pense tout simplement pas qu'il appartient au fichier de composition car c'est l'état qui change indépendamment du fichier de composition.

Prenons cet exemple qui suppose que nous ajoutons une configuration d'échelle au fichier de composition :

1. Je fixe une échelle initiale de 3 pour un service
2. Je lance docker-compose up -d , mon service passe à 3
3. Je cours docker-compose scale service=4
4. J'apporte quelques modifications et je redéploye avec docker-compose up -d .. Que se passe-t-il ? Est-ce que l'échelle est à nouveau réduite à 3 ? Ignore-t-il complètement l'échelle maintenant ?

Aucun de ces scénarios ne semble bon ou approprié, et ce n'est qu'un exemple trivial qui ignore les échecs d'instance (ce qui le rend encore plus compliqué).

S'il devait être ajouté au fichier de composition, je pense que nous voudrions supprimer la commande scale , afin qu'ils ne puissent pas entrer en conflit.

L'exemple que vous donnez est un exemple d'exigence opérationnelle. Vous n'avez pas besoin de plusieurs maîtres pour exécuter l'application, vous en avez besoin pour la fiabilité (le fonctionnement) du service. Et vous pouvez toujours accomplir cela avec scale db=x .

En utilisant l'exemple donné ci-dessus par @dnephin :

Tout d'abord, je pense que la commande scale est également naïve, car vous ne pouvez pas dire si vous allez augmenter ou réduire un service, avoir deux commandes diff pour expliquer l'intention d'augmenter ou de réduire en disant simplement combien de services font que vous souhaitez créer ou supprimer respectivement, sera bien mieux.

La réponse à la question posée par @dnephin est que je m'attends à ce qu'il y ait autant de services/conteneurs en cours d'exécution qu'avant la modification.

Compose est un outil sans état, il ne connaît pas ou ne surveille pas les services/conteneurs, il utilise l'API Docker pour aider Ops à orchestrer un là où je pense que le problème réside, composer a été conçu pour être un outil d'aide et non un service d'orchestration complet, et maintenant nous avons besoin de celui-là, nous avons un moteur qui fonctionne très bien, nous avons une machine à provisionner et nous avons un essaim pour les joindre tous dans un cluster mais nous avons un véritable service/outil d'orchestration qui nous a donné la flexibilité de configurer et pour gérer les services/conteneurs déployés comme le fait k8s. À l'heure actuelle, composer est la chose qui ressemble beaucoup à cela, mais si ce n'est pas dans le futur de ce projet d'évoluer vers quelque chose de plus grand, la meilleure idée sera de la part des développeurs et des mainteneurs officiels d'en parler afin que nous puissions en trouver un autre outil qui peut le faire.

Personnellement, je pense qu'il vaudra mieux faire évoluer la composition car c'est un outil formidable et bien connu de nous tous.

Je serai heureux de voir ceci : docker-compose > docker compose .
Je ne suis pas sûr du reste des outils, mais pour cela, ce serait vraiment bien d'avoir une intégration avec état avec le moteur. Désolé pour un commentaire un peu hors sujet.

J'ai créé #2496 pour ma proposition de supprimer la commande d'échelle et de la remplacer par l'option d'échelle (à partir du message ci-dessus). Des commentaires sur cette proposition seraient formidables.

@dnephin avec le #2496 compose perd la possibilité d'augmenter ou de réduire facilement, nous devrons reconfigurer le fichier de composition, puis exécuter à nouveau composer juste au moment où nous avons juste besoin de réduire ou d'augmenter une instance, je pense que c'est assez compliqué.

Encore une fois, nous perdons le point que tous ces scénarios viennent du point que composer est un outil sans état et à partir duquel il ne peut pas contrôler l'état des services et combien d'entre eux sont à un moment donné.

Le scénario que vous mentionnez dans la nouvelle proposition sera facilement résolu par un service/outil new-compose complet.

+1

+1

+1

@dnephin Le comportement ne serait-il pas le même si vous le faites :

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

N'est-ce pas plus un problème avec la façon dont la composition persiste à l'échelle interne.

C'est la chose, "Composer l'application" est sans état. Le seul état est dans 1) le fichier de composition et 2) les étiquettes de conteneur Docker gérées par le moteur.

Le fichier de composition n'est édité que par un humain, pas par Compose. Ce serait un gâchis d'essayer d'écrire yaml avec les mêmes commentaires, ordre et structure. Ce n'est pas pris en charge par pyyaml, et ce n'est pas quelque chose que nous voudrions vraiment faire de toute façon.

Le moteur Docker n'est pas conscient de l'échelle, il ne peut donc pas stocker cet état. C'est possible avec des changements architecturaux beaucoup plus importants, mais cela sort un peu du cadre de ce problème.

Pour l'instant, nos options consistent essentiellement soit à conserver l'échelle en tant qu'options de ligne de commande, soit à la déplacer dans le fichier de composition, mais comme je le décris dans #2496, je pense que les deux sont déroutants et conduisent à un comportement incorrect.

up && scale && up fait ce qu'il faut maintenant. up recréera tous les conteneurs, et comme il n'y a pas de valeur d'échelle dans la configuration, il n'y a pas de confusion quant à l'échelle souhaitée. Il était déjà défini par la commande de mise à l'échelle et suivi par les étiquettes des conteneurs.

@dnephin Je pense que je suis d'accord avec ce que vous dites, [je me trompe peut-être dans cette hypothèse] que ce que vous remettez en question, c'est que _si_ le nombre d'instances d'un composant est en fait la préoccupation de la composition d'un service exécutant différents conteneurs de composants). Je dirais qu'il répond actuellement à cette préoccupation, juste avec la mise en garde du manque de parité entre le cli et la définition de la composition (yaml).

Si l'étendue de la responsabilité est déterminée que l'échelle n'est pas la préoccupation de la composition, l'échelle doit être supprimée en tant qu'option cli (probablement la colère de nombreux utilisateurs), ou s'il est déterminé que l'échelle est la préoccupation de la composition d'un service qu'il devrait y avoir une parité entre le cli et yaml avec la prise en charge supplémentaire d'un nombre minimum d'instances pour tenir compte des instances en cluster qui nécessitent N+1.

D'accord avec @jmmills Surtout lors de l'exécution de clusters de conteneurs de données, lorsque disponibilité et réplication vont de pair, un minimum de scale fait partie de l'application : sans une échelle appropriée, cela peut même ne pas fonctionner

+1

+1

+1

Actuellement, je dois déclarer des choses comme ça:

sélénium-chrome1 :
...
sélénium-chrome2 :
...

Ce serait bien:
sélénium-chrome :
échelle : 2

+1

exactement ce que @caioquirino a dit. +1

docker-compose up devrait créer un environnement de travail sans nécessiter d'autres travaux. La seule façon de faire apparaître des services qui nécessitent plusieurs nœuds est d'utiliser le modèle mentionné par @caioquirino . En ignorant les violations DRY ici, le modèle sent mauvais lorsque vous essayez ensuite d'utiliser la commande scale pour ajouter un autre nœud car il n'est pas clair quel «service» doit être mis à l'échelle.

L'échelle dans le fichier yml résout ce problème.

Big +1, j'aimerais également l'utiliser pour définir des services dont l'échelle est initialement définie sur 0.

Le long des lignes de...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

L'idée est que vous puissiez utiliser le même docker-compose.yml et passer en toute transparence d'un environnement de développement à la production. Les instances consul_master rejoindraient automatiquement le radeau et établiraient un quorum en faisant docker-compose scale consul_master=3 . Ce serait plutôt cool.

Pour répondre à @dnephin...

Prenons cet exemple qui suppose que nous ajoutons une configuration d'échelle au fichier de composition :

1. Je fixe une échelle initiale de 3 pour un service
2. Je lance docker-compose up -d, mon service passe à 3
3. J'exécute le service d'échelle docker-compose = 4
4. J'apporte quelques modifications et je redéploye avec docker-compose up -d.. Que se passe-t-il ? Est-ce que l'échelle est à nouveau réduite à 3 ? Ignore-t-il complètement l'échelle maintenant ?
5. Aimer
6. Bien
7. je suis toujours avec toi
8. Je pense qu'il devrait y avoir une certaine différenciation entre un déploiement existant et un nouveau déploiement afin que la continuité d'échelle puisse être maintenue pour les déploiements existants qui reçoivent des mises à jour continues. Un déploiement individuel comprendrait l'environnement DOCKER_HOST, etc., ainsi que l'échelle de chaque composant, les ID d'image et un historique des redéploiements. Cela pourrait être un bon endroit pour se connecter à des mécanismes upstack comme le déploiement continu ou les déploiements bleu-vert ? J'imagine un flux de travail un peu plus prêt pour la production, vous pouvez donc simplement vous connecter à un autre DOCKER_HOST et faire un docker-compose up -d , puis fournir des crochets pour que les outils upstack puissent gérer des choses comme CI et les déploiements bleu/vert. Peut-être ajouter quelque chose comme DOCKER_COMPOSE_ENV={"testing " || "fabrication" || "dev"} ?

À mon humble avis, ayant "codé en dur" scale , disons à 3, il devrait commencer par 3 conteneurs

Je pense qu'une grande partie de la confusion entre un paramètre "scale" et la commande "scale" serait atténuée en nommant le paramètre YAML "initial_scale" ou "default_scale". Cela montre assez clairement que c'est juste une valeur qui sera utilisée s'il n'y a pas une sorte de substitution. Il semble également (à mon humble avis) raisonnable que ce paramètre "initial_scale" ne soit référencé que lorsque docker-compose lance le service pour la première fois, et non lors de la réexécution de docker-compose avec certaines instances du service déjà en cours d'exécution.

+1 pour "initial_scale", il décrira également explicitement ce paramètre comme spécifique à la composition, car docker lui-même n'a pas un tel paramètre.

Il se passe une chose intéressante, dans l'article de blog https://blog.docker.com/2016/02/video-containers-as-a-service-caas/ à la vidéo "48.56 montre que sur le nouveau centre de données docker publié vous peut, au point de création de la pile, configurer le nombre d'instances d'un conteneur que vous souhaitez exécuter. Cette idée n'est donc pas nouvelle pour l'équipe Docker, j'espère qu'elle sera incluse dans les prochaines versions de composition

+1

+1

Des millions de problèmes et de demandes scale/initial_count et ainsi de suite .. et toujours pas planifiés.

Triste de voir sinon un bon projet, mais les gens ne trouvent que des excuses et créent des problèmes nouveaux et en double, ferment des problèmes et "font" du travail.

+1

+1

+1

+1

S'IL TE PLAÎT, ARRÊTE!
N'AJOUTEZ PAS +1 !
ABONNEZ-VOUS AU NUMÉRO !

+1 ( @pierrre désolé)

+1 c'est très important ( @pierrre , désolé)

Je suis d'accord, mais je ne veux pas recevoir 100000 notifications pour votre "+1" !

/me forks docker compose et commence à apprendre la base de code.

De nombreux points valides ci-dessus, il semble qu'un paramètre default/inital scale dans le fichier de configuration + une commande scale cli traiteront les deux. Pour ajouter des cas d'utilisation à l'appui d'une option d'échelle initiale, envisagez des services en cluster où un quorum consiste en un nombre X de nœuds et qui ne devraient pas être opérationnels autrement (par exemple pas moins de 3). Le but de docker-compose est d'avoir un descripteur complet d'un tel système.

Mon cas d'utilisation est :

J'ai étendu un service avec certains paramètres communs pour permettre moins de duplication. Le service de base est cependant créé (lorsqu'il est exécuté sans spécifier explicitement les noms de service), puis je l'arrête manuellement. Je souhaite que le service de base ait une échelle initiale de 0.

Je suis d'accord en général. Bien qu'à mon avis, ce problème et les problèmes liés/connexes se résument à un problème légèrement différent : up et scale veulent finalement être la même commande.

Ils sont parfois déjà :

• docker-compose up service
• docker-compose scale service=1 .

Et, si scale exposait toutes les options cli (par exemple --force-recreate ) que up , ou si up savait compter, alors elles le seraient.

Si, comme le propose ce numéro, une directive "initial scale" est ajoutée au docker-compose.yml , alors up devra apprendre à compter. À quel point, up ne devrait-il pas simplement prendre en charge la syntaxe de comptage docker-compose up service=10 (qui pourrait écraser n'importe quelle échelle définie dans le yaml) ?

Il y a une distinction entre "échelle initiale" et "échelle", qui pourrait être le domaine de différentes commandes. Mais parce que up est idempotent et conçu pour être exécuté à plusieurs reprises sans nécessairement changer d'état, je ne pense pas que cette distinction soit stricte. Je pense que nous devrions plutôt envisager d' avoir up cannibaliser scale pure et simple.

@mattgiles Je suis d'accord, c'est là que j'allais avec #2496, cependant je n'avais pas pensé que le service=count pouvait être ajouté à up . Je pense que cela pourrait gérer la situation. Le seul problème que je vois est qu'actuellement up web signifie uniquement afficher le service Web et ses dépendances. Essayer de faire up web=3 devrait continuer à signifier la même chose. Ce qui signifie qu'il n'y a aucun moyen de tout up et de remplacer le décompte d'échelle en même temps, mais c'est probablement ok.

Je mettrai à jour la proposition au #2496

@dnephin J'ai raté la proposition la plus récente. Impressionnant!

fwiw, je pense qu'il est totalement intuitif pour docker-compose up web=3 d'afficher trois conteneurs pour le service "web", ainsi que toutes les dépendances... dans les ratios définis dans le yaml (par quelque chose comme un scale directive). De cette façon, le fichier de composition continue de gouverner à moins qu'il ne soit remplacé par la ligne de commande.

Les appels ultérieurs de up pourraient continuer, comme ils le font maintenant, pour laisser les conteneurs existants seuls. Ce n'est que si l'échelle actuelle est plus petite que celle définie dans le yaml que cela changera alors les comptes pour être conforme à l'échelle proscrite. Aucune échelle définie ne continuerait à impliquer une échelle de 1.

Des choses comme --force-recreate devraient aussi probablement laisser les comptes seuls s'ils sont supérieurs à ceux définis dans le yaml, mais toujours recréer tous les conteneurs pour qu'ils soient conformes aux autres attributs.

Il serait également logique pour moi de pouvoir tuer des conteneurs, comme on le peut actuellement avec scale , en appelant quelque chose comme docker-compose up web=2 etc etc.

+1

+1 (juste pour embêter @pierrre ;) )

+1

+1 pour échelle=x.

En rapport avec cela, j'aimerais une façon de décrire les singletons. scale=1

Tout succès ici avec l'option échelle

+1

Je n'ai rien vu de nouveau à ce sujet en amont, personnellement, je n'ai pas eu l'occasion de voir si je peux pirater un correctif pour cela.

Merci,
Jason Mills

• envoyé depuis un mobile.

Le 8 août 2016, à 17h19, lavvy [email protected] a écrit :

Tout succès ici avec l'option échelle

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

+1

+1

+1

+1

+1 (pour embêter encore @pierrre )

+1

je voudrais réitérer le cas

échelle=0
Utile pour le test, le débogage. probe etc. services que vous ne voulez normalement pas afficher, mais que vous voulez définir - car ils sont généralement utilisés dans le contexte des autres services du fichier.

échelle=1
Parce que je veux un et un seul d'entre eux - _ever_. Dans un cluster MariaDB, il existe des cas où je ne souhaite peut-être qu'un seul nœud configuré avec un moteur de stockage spécifique (par exemple, Spider, ColumnStore, etc.).

échelle=n
Parce qu'il y a des moments où je sais que j'ai besoin de 'n' services en cours d'exécution, par exemple, un cluster MariaDB où j'aurai toujours un primaire (avec sa configuration) et deux secondaires (avec leur configuration différente, de primaire).

C'est parfaitement logique pour moi @alvinr. La valeur par défaut devrait être 1.

AVIS DE NON-RESPONSABILITÉ : je ne suis pas un représentant de Marathon ou de Mesosphere

Ceci est encore un autre exemple d'une demande de fonctionnalité assez simple qui a été abandonnée / repoussée par l'équipe de support Docker pendant plus d'un an. https://github.com/docker/docker/pull/12749 est un autre exemple. Kubernetes et Marathon disposent de ces options depuis un certain temps déjà ("instances": 3 dans le fichier marathon.json) et implémentent même la mise à l'échelle automatique. C'est la réticence du groupe de support Docker qui m'a éloigné du centre de données Docker et de l'essaim depuis un certain temps maintenant.

Kontena l'a également sous la forme instances: 3 (https://www.kontena.io/docs/references/kontena-yml)

Une autre façon de procéder consiste à ajouter une section scale sur le fichier de composition version 2.

Cela ne se mélangerait pas avec les options uniquement docker utilisées dans les services.

Un exemple serait :

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2    

Ceci avec la possibilité de spécifier scale: 0 ferait potentiellement d'une pierre deux coups, l'autre étant https://github.com/docker/compose/issues/1896

Cela semble être une évidence.

Je souhaite déployer nginx+nodejs+mongodb avec 3 ou 4 instances nodejs. Chaque fois que je lance l'application.

Si vous avez une option de ligne de commande pour le faire, pourquoi pas dans le fichier yml ?

docker-compose up scale nodejs=4

Ferait.

C'est simple. Ils veulent emprunter la voie de « quelqu'un d'autre le construit et nous
va essayer de le prendre en charge". À part le docker de base, ils n'ont pas créé
n'importe quoi. Compose était un produit différent qu'ils consommaient et maintenant ils ont
aucune idée de comment le soutenir/l'étendre, c'est pourquoi des produits comme le marathon et
les kubernetes sont plus populaires que les essaims.

Le 16 octobre 2016, 21:36, notifications "Michael Schwartz"
a écrit:

Cela semble être une évidence.

Je souhaite déployer nginx+nodejs+mongodb avec 3 ou 4 instances nodejs. Tous
fois que je démarre l'application.

Si vous avez une option de ligne de commande pour le faire, pourquoi pas dans le fichier yml ?

docker-compose up scale nodejs=4

Ferait.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/compose/issues/1661#issuecomment -254093296,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AES98nZt1uIejnIU9iajVt54QbzdlVK1ks5q0tETgaJpZM4FS8ZQ
.

Honnêtement, je suis un peu étonné qu'il y ait _tout_ un recul à ce sujet car il semble si évident d'avoir...

@westlakem Espérons que Docker pour MacOS ne subira pas le même sort, espérons que les gars d'Unikernel resteront dans les parages.

Ce serait bien de faire apparaître une pile complète à sa taille fonctionnelle en une seule fois. Dans notre cas d'utilisation actuel, la pile de services doit avoir "workers=16" pour fonctionner correctement.

C'est juste horrible :

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

qui pourrait clairement être remplacé par quelque chose comme :

docker-compose up --abort-on-container-exit --scale workers=16

Edit : je vois que "Rancher" a une syntaxe de type docker-compose et prend en charge un paramètre d'échelle initial : https://paypertrail.com/blog/tech/docker-rancher-and-laravel-easy-and-safe-scalability

Une solution de contournement consiste à utiliser les capacités d'ancrage et de fusion YAML et à dupliquer le service dans le fichier docker-compose.

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

etc ...

Ce serait super utile !

C'est super bizarre ça n'existe pas...

Je pourrais finir par devoir créer des services en double parce que je suis paresseux.

C'est déjà sur le travail sur le fichier composer v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json qui sera et c'est déjà pris en charge sur docker-compose v1. 10.0-rc1

Leurs offres "Services" ont le paramètre intégré. Très triste qu'en tant que
abonné à ce numéro personne de l'équipe de développement ne nous a informés que
il arrivait dans le produit Services, et quelqu'un devait lire les notes RC
pour 1,10 pour tout aperçu. Où sont les représentants des dockers ?

Le ven. 6 janv. 2017 à 6h30, Yasmany Cubela Medina <
[email protected]> a écrit :

C'est déjà sur le travail sur le fichier composer v3 https://github.com/aanand/
compose-file/blob/master/schema/data/config_schema_v3.0.json qui sera
et il est déjà pris en charge sur docker-compose v1.10.0-rc1

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/compose/issues/1661#issuecomment-270886347 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AES98nOAW-h0BVaR8D9uQfLpMCQRfdyfks5rPiXEgaJpZM4FS8ZQ
.

+1

+1

Salut, j'ai une question connexe.
Je me demandais toujours si docker-compose up pouvait se souvenir de l'échelle que j'avais définie.

Par exemple, je lance docker-compose scale nodejs_web=4 puis docker-compose down ,
puis je recommence docker-compose up , ça va démarrer 4 nodejs_web.

Je veux savoir où la commande scale enregistre le numéro 4 ?

Le fichier docker-compose.yml peut être :

version: '2'
services:
  nodejs_web:
    image: node
    command: node

Je soutiens la proposition de @dnephin sur #2496
Veuillez nous donner cette fonctionnalité de base.

Les services de la nouvelle version de Docker offrent une fonctionnalité de « répliques ».

Le lundi 20 mars 2017 à 15h28, alwaysastudent [email protected]
a écrit:

Je soutiens la proposition de @dnephin https://github.com/dnephin sur #2496
https://github.com/docker/compose/issues/2496
Veuillez nous donner cette fonctionnalité de base.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/compose/issues/1661#issuecomment-287870998 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AES98uWGEnbyCFyxNSSlv7QkXy5oBek1ks5rntNBgaJpZM4FS8ZQ
.

@westlakem - cette fonctionnalité est pour l'essaim. Ce n'est pas pour la mise à l'échelle du service régulier.

Tant d'avantages, peu d'inconvénients. Quel est le problème avec ce problème?

Il existe une proposition plus récente concernant la suppression complète de la commande scale dans https://github.com/docker/compose/issues/2496

Je ne comprends vraiment pas pourquoi ou pourquoi il n'y a pas d'option initial_scale: 3 dans le fichier de composition (je comprends pourquoi cela ne peut pas être juste scale: 3 )

Implémenté en 1.13.0. Merci à tous pour vos retours et votre patience.

@shin- Pourquoi est-ce considéré comme fermé ? Dans la gestion d'applications à grande échelle où TOUT est automatisé et dans le contrôle de version, je dois maintenant modifier mon Ansible qui exécute Docker pour définir le nombre d'instances d'un service qui seront exécutées.

Ansible devrait tout configurer pour que Docker puisse s'exécuter. Docker doit définir le nombre d'instances d'un service dont l'application a besoin. Maintenant, c'est la responsabilité de Docker de connaître l'inventaire des services mais la responsabilité d'Ansible d'appeler Docker pour qu'il sache combien de conteneurs tourner ?

@greenscar Désolé, je ne sais pas exactement quel est le problème - êtes-vous mécontent de la façon dont la fonctionnalité a été implémentée ? Si oui, de quelle manière pouvons-nous l'améliorer?

Pourquoi n'est-ce pas présent dans la version 3 ? Extrêmement déroutant puisque "deploy.replicas" et "up" ne sont pas équivalents, on pourrait dire que cette fonctionnalité est manquante dans la v3.

@cgarciae deploy.replicas le même objectif que scale . Pourquoi ne sont-ils pas équivalents à votre avis ?

@shin- Si je ne veux pas créer d'essaim et n'utilise que docker-compose up -d , docker compose me dit qu'il ignorera les paramètres de "déploiement".

@cgarciae Pourquoi utilisez-vous un fichier v3 si vous ne voulez pas créer un essaim ?

Je pense que tous ceux qui utilisent docker s'attendent à ce que le paramètre d'échelle fonctionne pour les fichiers docker 2 ou 3. Il n'y a aucune raison pour qu'il ne le fasse pas et il pourrait même définir la valeur par défaut pour deploy.replicas. Si deploy.replicas est défini, il remplace donc scale dans swarm. Qu'est-ce qui ne va pas avec cette image à part que tout le monde s'attend à ce qu'elle se produise (et bien sûr, si vous ne l'aimez pas, inutile de l'utiliser dans votre docker-compose.yml) ?

Le paramètre d'échelle manquant a fait échouer un service, car j'ai oublié de le mettre à l'échelle comme avant depuis le dernier redéploiement - pourquoi n'est-ce pas une chose qui sauverait le service et peut-être même des vies en fonction de ce qu'il fonctionne

Frappez juste ce problème aussi. Il semble qu'il n'y ait aucun moyen de spécifier le nombre de services à démarrer à partir de la configuration de composition de docker ? Il est encore plus déroutant que la documentation de docker compose a beaucoup de documentation pour des choses qui ne fonctionnent pas avec docker-compose...

Oh, attendez, donc si je change ma configuration de composition de docker en version: "2.2" je peux utiliser scale: 2 mais si l'on veut passer à une version ultérieure, il n'y a plus d'option pour le faire ?

Ok, je vois que ce problème de "version" ne signifie pas vraiment que les versions ont déjà été évoquées, https://github.com/docker/compose/issues/4693

J'utilise la v3.6 car j'ai besoin de certaines configurations qui n'existent pas dans 2.2. Pour le développement local, je n'utilise pas d'essaim, mais je veux définir scale=0 pour certains conteneurs dans mon docker-compose.overrides.yml. Parce que certains d'entre eux sont uniquement destinés aux processus de construction comme le conteneur frontendbuild. Ce conteneur partage certains volumes avec d'autres conteneurs en cours d'exécution, mais ne doit pas démarrer avec ces autres conteneurs sur docker-compose up. Ainsi, le buildcontainer s'exécute simplement avec la commande run. Oui, je peux définir le paramètre --scale lors de l'appel de docker-compose, mais je pense qu'il est préférable de l'écrire directement dans la configuration. :)

Merci pour le paramètre d'échelle. J'ai pu l'utiliser dans un docker-compose.yml hors production afin que n'importe qui puisse utiliser une configuration HA de Consul et Vault. Le paramètre d'échelle a facilité le provisionnement d'une configuration HA locale. https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

Dans ce cas, uniquement destiné à quelqu'un pour essayer Consul et Vault dans une configuration HA et utiliser Consul DNS.

Sur quelle version de docker compose utilisez-vous ? Depuis la v3, cette fonctionnalité a été abandonnée (par abandon, je veux dire, jamais implémentée), elle est donc ignorée. Voir https://docs.docker.com/compose/reference/scale/

Je n'utilise jamais le format v3 en raison de fonctionnalités manquantes. J'ai tendance à utiliser le format 2.1 ou 2.2 le plus bas en fonction des fonctionnalités que j'utilise.

Edit : pour ne pas dire que j'évite le format v3. Juste que lorsque je vais écrire un fichier de composition, il manque généralement ce que je veux utiliser.

Ok, j'ai deviné que vous parliez de docker compose avec swarm stack, c'est pourquoi. Je n'ai jamais essayé, mais c'est bizarre de parler de HA avec docker compose sans orchestrateur et mutli node. Est-ce à des fins de "poc" ou de test ? De toute façon, je n'ai jamais essayé dans ce contexte

Dans ce cas, la haute disponibilité fait simplement référence à un cluster de consul et à un cluster de coffre-fort. Il est destiné à servir de preuve de concept disponible pour l'expérimentation et la facilité d'amorçage. Le HA ne fait pas référence au docker HA ou même au HA multi-machine. C'est seulement HA dans la mesure où la personne expérimentant peut tuer l'un des conteneurs de cluster et voir que le service de consul et/ou de coffre-fort n'est pas affecté.