how to link container in docker?

Question

Here\'s the result when I type docker ps :

in docker,

Answer 1

In my experience working with declaratives such as docker-compose.yml is okay, but simply you can use

docker run -d -P  -link  nimmis/apache-php7  rabbitmq redis 

Answer 2

You can define your services to use a user-defined network in your docker-compose.yml

version: "3"

services:

  webapps:
    image: nimmis/apache-php7
    ports:
      - "80:8080"
    networks:
      - my-network

  rabbitmq:
    image: rabbitmq
    networks:
      - my-network

  redis:
    image: redis
    networks:
      - my-network

networks:
  my-network:
    driver: overlay

Then do:

docker swarm init
docker stack deploy -c docker-compose.yml my-stack

Check out the full example at https://docs.docker.com/get-started/part3/

Answer 3

You need to link rabbitmq and redis to your webapps container and not the other way arround.

    #run redis container
    docker run --name some-redis -d redis

    #run rabbitmq container
    docker run -d --hostname my-rabbit --name some-rabbit rabbitmq

    #run webapps container
    docker run --name webapps -p 8080:80 --link some-redis:redis --link some-rabbit:rabbitmq nimmis/apache-php7

First run redis and rabbitmq containers. Then run webapps container with links to the 2 containers.

Now, to configure redis host in the webapps - its easy. You can simply use env variable 'REDIS_PORT_6379_TCP_ADDR'. Because once a container is linked you get its env variables. and redis exports that variable.

Regarding the rabbitmq host - you can get the ip after the rabbit container is up by:

    RABBITMQ_IP=$(docker inspect --format '{{ .NetworkSettings.IPAddress }}' some-rabbit)

and then pass it in --env when you run the webapps container.

Answer 4

For inter-container dependencies and links, you'll want to use docker-compose where you can define the links between containers.

In your root directory where you store your Docker files, just make a new file called docker-compose.yml and here you can define your containers as services which rely on each other like this:

version: '2'
services:
  webapps:
    build: .
    links:
      - "rabbitmq:rabmq"
      - "redis"

  rabbitmq:
    image: rabbitmq

  redis:
    image: redis

so here in the definition of the webapps service, you see it links the other two services rabbitmq and redis. What this means is that when the webapps container is build, an entry to it's hosts file is made such that the domain name redis is translated to the IP and port number of the actual container.

You have the option to change the name of how this container is address by using the service:alias notation, like how I defined the rabbitmq to use the alias rabmq inside the container webapps.

To now build and start your containers using docker-compose just type:

docker-compose up -d

So connecting to another container is as simple as using this alias as the name of the host.

Since you are using docker-compose in this case, it creates a docker network automatically to connect all the containers so you shouldn't have to worry about that. But for more information have a look at the docs: https://docs.docker.com/compose/networking/#/specifying-custom-networks

Answer 5

Linking is a legacy feature. Please use "user defined networks":

sudo docker network create mynetwork

Then rerun your containers using this network:

sudo docker run --name rabbitmq -p 8080:80 -d --network mynetwork rabbitmq

Do the same for other containers that you want connected with each other.

Using "user defined networks", you have an "internal name resolution" at your disposal (somewhat like domain name resolution when visiting websites). You can use the names of the container that you want to refer to, in order to resolve the IP addresses of containers, as long as they are running on the same "user defined network". With this, you can resolve the IP address of the rabbitmq container with its name, within other containers, on the same network.

All containters on the same "user defined network" will have network connectivity. There is no need for "legacy linking".