web-dev-qa-db-fra.com

Pourquoi le nom du conteneur docker a-t-il un nombre aléatoire à la fin?

J'ai un fichier docker-compose.yml comme ci-dessous (un morceau de celui-ci):

version: '3.5'
services:
    framework:
    image: ${DOCKER_REGISTRY}/gme/fmk:${COMPOSE_PROJECT_NAME}
    build: ./fmk
    ports:
      - "2020:2020"
      - "2025:2025"
      - "4999:4999"
    volumes:
      - ${FOLDER_ENV}/workspace/logs/framework:/var/log/gcti
      - ${FOLDER_ENV}/..:/usr/local/genesys/gsg_qaart

ce que j'ai c'est:

vagrant@docker:/repos/gsg_qaart/docker$ docker-compose ps
]              Name                             Command               State                                             
Ports
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
callback_framework_1_df361f67842c   /bootstrap.sh                    Up      0.0.0.0:2020->2020/tcp, 0.0.0.0:2025->2025/tcp, 0.0.0.0:4999->4999/tcp, 5432/tcp

Comme vous pouvez voir le nom est bizarre, cela suppose "callback_framwork_1", pourquoi il y a un nombre aléatoire à la fin?

BTW, j'utilise:

vagrant@docker:/repos/gsg_qaart/docker$ docker -v
Docker version 18.09.0, build 4d60db4
vagrant@docker:/repos/gsg_qaart/docker$ docker-compose -v
docker-compose version 1.23.1, build b02f1306

Merci.

5
Michael.X

MODIFIER.

Cette modification est annulée dans v1.23.2


Il y a donc un changement important dans la composition v1.23, https://github.com/docker/compose/releases/tag/1.23.0

Le schéma de nommage par défaut pour les conteneurs créés par Compose dans cette version de project_service_index est devenue project_service_index_slug, où slug est un chaîne hexadécimale générée aléatoirement. S'il vous plaît assurez-vous de mettre à jour les scripts s’appuyant sur l’ancien schéma de nommage en conséquence avant la mise à niveau.

Par conséquent, si vous souhaitez avoir un nom de conteneur déterministe, utilisez

services:
    framework:
        container_name: framework
4
Siyu

Je ne peux pas nommer le nom du conteneur en code fixe et je veux pouvoir exécuter n'importe quel répertoire Alors j'ai fini par chercher une partie du nom:

docker exec -it $(docker ps --format='{{.Names}}' | grep server) bash
0
simno

Remarque, les autres réponses/dépannage sont valides/correctes, mais j'aimerais donner matière à réflexion sur le travail avec docker-compose, malgré la manière dont docker-composition a annulé le changement de slug. Il existe une bonne pratique qui peut être mise en évidence lors de l'utilisation des services docker-compos.

Docker-Composer essayait de changer la façon dont leur outil était utilisé. J'ai lu quelque chose sur github qui y faisait allusion, mais c'est mon opinion après avoir lu certaines des réactions des développeurs, en particulier celles du problème suivant sur github sur les slugs .

Utilisation des mécanismes de service internes de docker-compose

J'essaie de généraliser, car les exemples suivants peuvent ne pas être entièrement applicables à votre configuration, mais ils devraient néanmoins être utiles. Étant donné que vous utilisez déjà docker-compose, il est avantageux d'utiliser la découverte de service fournie via des réseaux de docker et l'accès via docker-compose via un codage définitif via des noms de conteneur.

Lors de l'utilisation de docker-compose, des services sont créés, composés de 1 .. * conteneurs. Dans votre exemple, le service framework est créé avec 1 conteneur callback_framework_1_df361f67842c.

Accéder à un service depuis un autre conteneur/code docker dans un conteneur docker

Un service peut être utilisé pour DNS/réseau au lieu de noms de conteneur, c'est-à-dire partout <protocol>://<Host>:<port>/<endpoint> où le container name a été utilisé en tant que <Host>, le service name peut également être utilisé en tant que <Host> (par exemple en exécutant une commande ping à l'intérieur d'un autre conteneur sur le réseau docker):

ping <service>
ping framework

contre

ping <container-name>
ping callback_framework_1_df361f67842c

Les deux pings ci-dessus fonctionnent. Docker prend en charge la mise en réseau du conteneur approprié, plus loin lorsque plusieurs conteneurs composent un service, il prend en charge les demandes d'équilibrage de charge adressées aux conteneurs.

Accéder à vos conteneurs via un service depuis la machine hôte, c.-à-d. En exécutant des commandes de menu à partir de scripts

Si vous exécutez des scripts à partir de la machine hôte, vous pouvez également utiliser docker-compose au lieu de commandes docker:

docker-compose exec <service> sh
docker-compose exec framework sh

contre

docker exec -it <container-name> sh
docker exec -it callback_framework_1_df361f67842c sh

par défaut, docker-exec utilise le premier conteneur, mais lorsqu'il existe plusieurs conteneurs qui composent un service d'ancrage, un conteneur cible peut être adressé à l'aide de l'indicateur --index=<index>. Voir documentation docker-compose exec pour plus de détails.

0
Arthur Weborg