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

The default naming scheme for containers created by Compose in this
version has changed from project_service_index to
project_service_index_slug, where slug is a
randomly-generated hexadecimal string. Please make sure to update
scripts relying on the old naming scheme accordingly before upgrading.

Therefore if you want to have a deterministic container name, use

services:

    framework:

        container_name: framework

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:

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

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 container callback_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 the container name was used as the <host>, the service name can also be used as the <host> (eg executing ping inside of another container on the docker network):

ping <service>

ping framework

vs

ping <container-name>

ping callback_framework_1_df361f67842c

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:

docker-compose exec <service> sh

docker-compose exec framework sh

vs

docker exec -it <container-name> sh

docker exec -it callback_framework_1_df361f67842c sh

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.