I have a docker-compose.yml file as below (a piece of it):
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
what I got is:
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
As you can see the name is weird, it supposes to be "callback_framwork_1", why there is a random number at the end?
BTW, I'm using:
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
Thanks.
EDIT.
This change is reverted in v1.23.2
So there is an important change in the compose v1.23, https://github.com/docker/compose/releases/tag/1.23.0
Therefore if you want to have a deterministic container name, use
I cannot hardcode container name and I want to be able to run from any directory. So I ended up grepping part of the name:
Note, the other answers/troubleshooting are valid/correct, but I'd like to give some food for thought on working with docker-compose, despite how docker-compose reverted the slug change. There is a good practice that can be highlighted in in making use of docker-compose services.
My personal thoughts are docker-compose was attempting to pursue a shift in how their tool was being used. I read somethings on github that hinted at that, but that's my opinion after reading some of their developers feedback, specifically from the following github issue on the slugs.
Making use of docker-compose's internal service mechanisms
I'm attempting to generalize, since the following examples may not be fully applicable to your setup, but they should be helpful none the less. Since you're already using docker-compose, there is a benefit to using service discovery provided via docker networks and docker-compose over hard-coding access via container names.
When using docker-compose, services are created that are composed of 1..* containers. In your example, the service
framework
is created with 1 containercallback_framework_1_df361f67842c
.Accessing a service from within another docker container/code in a docker container
A service can be used for DNS/networking instead of container names, that is everywhere
<protocol>://<host>:<port>/<endpoint>
where thecontainer name
was used as the<host>
, theservice name
can also be used as the<host>
(eg executing ping inside of another container on the docker network):vs
Both the above pings work. Docker takes care of the networking to the appropriate container, farther when there are multiple containers that compose a service, it takes care of load balancing requests to the containers.
Accessing your containers via service from the host machine, ie running docker commands from scripts
Addressing if you have scripts executing from the host machine, you can also make use of docker-compose instead of docker commands as well:
vs
docker-exec defaults to the first container, but when there are multiple containers that compose a docker service, a target container can be addressed using the
--index=<index>
flag. See docker-compose exec documentation for more details.