docker-compose scale - how to get scale # in YAML file?

[benlei-neustar]

I have something like this:

my_container:
  image: my-image
  ports:
    - "1234:1234"
  environment:
    CONTAINER_PORT: 1234
    COTANINER_ID: 3a53bcd0710

I want to be able to achieve three things:

1. If I scale to 2, how do I get the second container's port to change from 1234:1234 to 1235:1234
2. Similar to the above, how do I get the CONTAINER_PORT env var to be 1235 for the second container?
3. How do I get the first container to use CONTAINER_ID 3a53bcd07101 and the second to use 3a53bcd07102?

To scale further, what if I wanted 10+ of these containers?

Can these only be achieved by copying and pasting my_container 10x times?

[freefood89]

A few thoughts:

1. Assuming you're trying to deploy your app somewhere, I think you should be using docker swarm instead to scale.
2. If you're trying to test something in your dev environment do you need to dynamically scale containers? Assuming that your "scaled" containers are identical and you want to load balance across them, why not link the containers to a load balancer and don't bind their ports to the host machine's ports? example

I'm here to learn too so please correct me if I'm wrong.

[dnephin]

There are some existing issues for this: #1661, #1131

We haven't decided exactly how to support this yet. Could you tell us more about why you need these values in your application? Normally the way this would be supported (as @freefood89 suggested) is by having a separate service that watches for new containers and re-configures the load balancer. https://github.com/jwilder/nginx-proxy is one example of that.

The application itself doesn't need to change the port it listens on, it always binds to the same port in the container.

To get the hostname (the unique id) of the container, you can use $(hostname -i) in the container.

[benlei-neustar]

@freefood89

1. Definitely.
2. At the moment it's for development environment, but would like to see if it can be done for production. I do not want to load balance across them; It's more for running more instances of a process and being able to access them individually externally.

Thanks for the information though; was very interesting!

@dnephin
The application I am running definitely uses the same ports for every container, but I need a way to access them externally. Each application uses the same image but will do + report different things to a master. For example a car A1 may travel to different cities than car A2. They are both the same cars but the stops taken and the roads traveled are fairly different. I want to obtain or gather statistics about each individual application that I am running in a container.

I did not think about using hostname; thanks! It is sufficient in fulfilling my third question.

[dnephin]

Closing as duplicate of #1661, #2496,

[brettdh]

@dnephin

I am using swarm + multi-host networking to scale out services (Druid) that advertise themselves via Zookeeper (separate instance from the swarm discovery service, which is actually Consul). Currently, if I don't set a hostname explicitly, the service advertises $(hostname), which is unique, but cannot be resolved in other containers. (Maybe this is not true in single-host deployments, or is a regression in swarm environments?) If I knew the specific container instance at startup time (e.g. networkname_servicename_1), I could have the container advertise that, as it is resolvable.

I can instead have it advertise the docker host IP (i.e. the result of $(hostname -i | cut -d' ' -f1)), which works for my current use case and will probably be my workaround for now. However, that depends on the service having a port forwarded to the docker host, which is not ideal; no clients outside the docker network really need to access the service, and I would prefer to hide it from the outside world.

[dnephin]

$(hostname) should be resolvable by all other containers on the network for exactly this use case. There was a bug around this in Compose 1.6.0 which was fixed in 1.6.2, maybe that's the problem?

[brettdh]

Yep, I was just looking at the release notes for compose 1.6.1 and saw this:

Fixed a bug with service aliases where the short container id alias was only contained 10 characters, instead of the 12 characters used in previous versions.

Is that what you're referring to?

[dnephin]

yes, that's it