fig scale - not creating links

[STOIE]

Hi there,

First, here is my fig.yml:

web:
  image: web:latest
  links:
   - "db"
  ports:
   - "80"
db:
  image: db:latest

I am trying to run the following (hope you can get a simple understanding of my example):

fig scale web=1 db=3

This is how fig starts the containers:

prefix_db_1
prefix_db_2
prefix_db_3
prefix_web_1

However, if I "docker exec -t -i prefix_web_1 /bin/bash" and run "cat /etc/hosts" on the container I can't see any db links.

Where as, if I simply run "fig -d up", I can see the db references in /etc/hosts. But, it only starts up the following:

prefix_db_1
prefix_web_1

...as expected.

Anyone able to help, I think this is a bug?!?

Thanks,
Aaron.

[STOIE]

Temp way around this is:

fig.yml:

web:
  image: web:latest
  links:
   - "db0:db0"
   - "db1:db1"
   - "db2:db2"
  ports:
   - "80"
db0:
  image: db:latest
db1:
  image: db:latest
db2:
  image: db:latest

However, kind of removes the whole point of having a "dynamic" scale cli option.

[hanzheng]

any progress here?

[jmervine]

I was able to use this workaround for my use case, where it's an image I'm building that I want to scale and link in to a proxy server (nginx in this case):

# where directory is "foobar"
app0:
    build: .
app1:
    image: foobar_app0
app2:
    image: foobar_app0
nginx:
    build: .
    links:
    - app0
    - app1
    - app2

[StefanScherer]

@aanand What is needed to get this fixed? Is it just a matter of updating /etc/hosts in the containers? Is there more to do? Is this possible within the docker-compose sources? If yes, I could try a PR for that.

[jmervine]

I think it goes a bit beyond updating /etc/hosts. There's also the various environment variables created by a link.

In my use-case, I was using the link based environment variables to dynamically generate an nginx upstream proxy on startup. So I would also need to re-run my startup script. Additionally, I'm forced in to a 2.6 kernel situation -- as I believe is more often the case than Docker realizes -- therefore docker exec is not an option. I was tinkering with the idea of something that would accept a --relink flag on scale, causing the containers which have links to reload -- stop, rm, restart with the additional links created by scale. However, this isn't really a valid option for HA apps -- those that can't afford down time.

[macobo]

@jmervine
Since the aim of composer would be dev environments, I think the stop and restart approach is the way to go. In addition, we could add a relink: command option that would run command after a instead of simply restarting the container.

[nazar-pc]

@macobo, https://docs.docker.com/compose/production/

While Compose is not yet considered production-ready, if you’d like to experiment and learn more about using it in production deployments, this guide can help. The project is actively working towards becoming production-ready; to learn more about the progress being made, check out the roadmap for details on how it’s coming along and what still needs to be done.

It seems that you are wrong about dev environments, production is planned, just not ready yet.

@jmervine, it is not that simple, because if docker was started with -icc=false then since scaling doesn't really create links, we'll not be able to access new containers. However, updating /etc/hosts and environment variables should be enough when icc=true

@aanand, I found in other issue that you are owner of this repo (at least one of), any plans on implementing this feature? Otherwise scaling doesn't really do its job well, downtime might be a problem here.

As the last resort (since AFAIK docker doesn't allow to update container's config without it recreation) would be good to have some dependency specified, so that when dependencies are scaled - container(s) should be destroyed and created again with proper links.

[aanand]

See #1676 - links and scaling don't combine well, but the new networking stuff should work much better.

[dnephin]

Going to close this issue since it's being worked on in #1676