1

What we want to do:

We want to use docker-compose to link one already running container (A) to another container (B) by container name. We use "external-link" as both containers are started from different docker-compose.yml files.

Problem:

Container B fails to start with the error although a container with that name is running.

ERROR: for container_b  Cannot start service container_b: Cannot link to a non running container: /PREVIOUSLY_LINKED_ID_container_a_1 AS /container_b_1/container_a_1

output of "docker ps":

CONTAINER ID        IMAGE                          COMMAND                  CREATED             STATUS              PORTS                         NAMES
RUNNING_ID        container_a       "/docker-entrypoint.s"   15 minutes ago      Up 15 minutes       5432/tcp                      container_a_1

Sample code:

docker-compose.yml of Container B:

container_b:
  external_links:
  - container_a_1

What differs this question from the other "how to fix"-questions:

  • we can't use "sudo service docker restart" (which works) as this is a production environment
  • We don't want to fix this every time manually but find the reason so that we can
    • understand what we are doing wrong
    • understand how to avoid this

Assumptions:

  • It seems like two instances of the container_a exist (RUNNING_ID and PREVIOUSLY_LINKED_ID)
  • This might happen because we
    • rebuilt the container via docker-compose build and
    • changed the forwarded external port of the container (80801:8080)

Comment

  • Do not use docker-compose down as suggested in the comments, this removes volumnes!
hb0
  • 3,350
  • 3
  • 30
  • 48
  • Are you restarting the container in compose? Or are you using `docker-compose down` and `docker-compose up` again? – Tarun Lalwani Oct 11 '17 at 06:31
  • Thanks for the reply. Honestly, I didn't know the command "down". Right now I am using Ctrl+C (when they are in foreground) or "docker stop container_name" when they are in background. Do you thing this should make any difference? Why? I will start trying docker-compose down and report back after a while if there are no other suggestions. – hb0 Oct 11 '17 at 08:47
  • Did it work for you? – Tarun Lalwani Oct 13 '17 at 20:55
  • I didn't really have the chance yet to test it on everydays use as I spawn my docker containers in foreground mode to always see the log output for each container. I could try to shut them down with that command nevertheless instead of Ctrl+C but I still don't really understand why this command should make a difference? Do you have a hint? – hb0 Oct 15 '17 at 17:11
  • 1
    @Tarun Lalwani: Testing `docker-compose down` was a very unpleasant experience :( I got the --help output wrong and it just **deleted our volumnes** after stopping it ... not cool. **Do not use this** `docker-compose down` just to *stop* a container! – hb0 Oct 20 '17 at 11:49

1 Answers1

1

Docker links are deprecated so unless you need some functionality they provide or are on an extremely old version of docker, I'd recommend switching to docker networks.

Since the containers you want to connect appear to be started in separate compose files, you would create that network externally:

docker network create app_net

Then in your docker-compose.yml files, you connect your containers to that network:

version: '3'

networks:
  app_net:
    external:
      name: app_net

services:
  container_a:
    # ...
    networks:
    - app_net

Then in your container_b, you would connect to container_a as "container_a", not "container_a_1".

As an aside, docker-compose down is not documented to remove volumes unless you pass the -v flag. Perhaps you are using anonymous volumes, in which case I'm not sure that docker-compose up would know where to find your data. A named volume is preferred. More than likely, your data was not being stored in a volume, which is dangerous and removes your ability to update your containers:

$ docker-compose down --help

By default, the only things removed are:

- Containers for services defined in the Compose file
- Networks defined in the `networks` section of the Compose file
- The default network, if one is used

Networks and volumes defined as `external` are never removed.

Usage: down [options]

Options:
    --rmi type          Remove images. Type must be one of:
                        'all': Remove all images used by any service.
                        'local': Remove only images that don't have a custom tag
                        set by the `image` field.
    -v, --volumes       Remove named volumes declared in the `volumes` section
                        of the Compose file and anonymous volumes
                        attached to containers.
    --remove-orphans    Remove containers for services not defined in the
                        Compose file
BMitch
  • 231,797
  • 42
  • 475
  • 450
  • First of all: Thanks alot for your reply! I will check the networks out and accept your reply as soon as I find time to test it. @docker-compose-down: I store the db data in a separate storage "busybox" volumne-container which usually keeps the data untouched, as long as we don't use the -v flag. The container accesses the volumn with `volumes_from: - storage`. Thus, I was really shocked, when the storage-volumn-container was removed, too - but I guess the volumne still exists and is just unlinked because the storage-container is gone. – hb0 Oct 20 '17 at 14:19
  • 1
    `volumes_from` is also on the way out, it cannot be used if you transition to swarm mode. Using a named volume is preferred. https://github.com/moby/moby/issues/17798#issuecomment-154815207. The biggest problem with data containers are that they mix data and containers, so you remove a container, you remove your data. – BMitch Oct 20 '17 at 14:23
  • This was good advice, I finally found the time to upgrade to compose file version v3 using networks and removing the volumne_from. Thanks! – hb0 Apr 13 '18 at 22:16