Docker Community Forums

Share and learn in the Docker community.

How to identify the number of scaled container


(Guenther) #1

Hi,

I wonder if it is somehow possible, when scaling up a container with compose, to distinct the containers (inside each container) by e.g. a sequence number like the one, docker-compose add to the end of the name.
This would be very useful, because in my case i have to register the service inside the container on a external component, and the registration needs to have a “unique” number.

thanks in advance
Guenther


(Dvohra) #2

The containers do have distinct container id or name.


(Guenther) #3

But does docker-compose pass into the container (e.g. as Environment-Variable)? Or how can I get this information within the container?


(Dvohra) #4

Does the following command output container info?
cat /proc/self/cgroup | grep -o -e “docker-..scope" | head -n 1 | sed "s/docker-(.).scope/\1/”


(Richardpayne) #5

The hostname is set to the container id.

echo ${HOSTNAME}


(Guenther) #6

The output of the command is empty.
The output of ${HOSTNAME} give me a more or less unique id, but my usecase is different. I’m really more interested in the sequence number of the container-name.

The reason for that is the following: Outside the container I have configuration and work folders
config_1
config_2
config_3
work_1
work_2
work_3

When the container is scaling up, each container must take a different config and work. In that example, I can scale up util i have three containers of that kind.

Or do you have another id, how the container can access the corresponding folders?


(Richardpayne) #7

How are those sequence numbers generated in the first place?


(Guenther) #8

If you mean how the sequence number of the folders are created: Manually.


(Richardpayne) #9

So when you spool up a new container just map the correct work and config folders to the container volumes.

Maybe it would be helpful if you posted your yml file.


(Guenther) #10

Here is the YAML

version: '2' services: agent: build: agent_image image: teamcity_agent:1.4 environment: AGENT_NUMBER: "${AGENT_NUMBER}" restart: always

I have a shell script, which just exports that number for me:
#!/bin/bash export AGENT_NUMBER=$2 docker-compose "$@"


(Richardpayne) #11

You don’t have any volume statements in your compose file. Also, you environment statement is wrong. Maybe something like this:

version: '2'

services:
    agent:
        build: agent_image
        image: teamcity_agent:1.4
        environment:
        - AGENT_NUMBER
        volumes:
          - ./config_${AGENT_NUMBER}:/teamcity/config
          - ./work_${AGENT_NUMBER}:/teamcity/work
        restart: always

Where the you have the config_1, config_2, work_1, work_2, etc. folders in the same place as the yml file. Adjust the paths on the left side of the volume statements if this is not the case. Adjust the right side of the volume statements to put them in the right place inside the container.

one extra thing though, does the work folder really need to be outside the container? Do it need to be persisted across container runs?


(Guenther) #12

The environment variable works that way, I do it, so it can’t be completely wrong.
Yes, you are right, I didn’t add the volume to this sample.
No, the work folder isn’t needed as volume. I already changed that one. Just the config folder is depending on some variable.

But the problem still remains: I can’t use docker-compose scale 2 because the environment variable always has the same value, but I need the concrete values of the scaling container (agent_1 == 1, agent_2 == 2, agent_3 == 3).
In my point of view, this has to be provided by docker-compose, else there is no way to use the scale feature.


(Richardpayne) #13

Ah ok, I wasn’t aware of the scale parameter. Interesting.

The way I’d see this is that you shouldn’t be using different configs with scale. It seems to me that scale is supposed to be used to allow you handle larger loads. If your containers need different configs then they should be run separately.

In your case, I would suggest that you should break out the interaction with the external service into it’s own containerised app to act as a proxy. You scaled app containers then talk to your proxy which talks to the external service using the same registration.


(Guenther) #14

Hi,

thanks for the suggestion. That seams reasonable.