Below is the working docker-compose file in v2 spec:
version: \'2\'
volumes:
webroot:
driver: local
services:
app: # Launch uwsgi application server
Setting hostname:
is equivalent to the hostname(8) command on plain Linux: it changes what the container thinks its own hostname is, but doesn't affect anything outside the container that might try to reach it. On plain Linux running hostname dbr
won't change an external DNS server or other machines' /etc/hosts
files, for example. Setting the hostname might affect a shell prompt, in the unusual case of getting an interactive shell inside a container; it has no effect on networking.
Within a single Docker Compose file, if you have no special configuration for networks:
, any container can reach any other container using the name of its block in the YAML file. In your file, app
, nginx
, test
, dbc
, and agent
are valid hostnames. If you manually specify a container_name:
I believe that will also be reachable; network aliases as suggested in @asolanki's answer give yet another name; and the deprecated links:
option would give still another. All of these are in addition to the standard name Compose gives you.
Networking in Compose has some reasonable explanations of all of this.
In your example, dbr
is not a valid hostname. dbc
is the Compose service name of the container, but nothing from the previous listing causes a hostname dbr
to exist. It happens to be the name you'll see in the prompt if you docker-compose exec dlc sh
but nobody else thinks that container has that name.
As a specific corollary to "links:
is deprecated", the form of links:
you have does absolutely nothing. links: [dbc]
makes the container that would otherwise be visible under the name dbc
visible to that specific container as that same name. You could use it to give an alternate name to a container from the point of view of a client, but I wouldn't.
Your docker-compose.yml
file doesn't have any networks:
blocks, and so Compose will create a default
network and attach all of the containers to it. This is totally fine and I would not recommend changing it. If you do declare multiple networks, the other requirement here is that the client and server need to be on the same network to reach each other. (Containers without a networks:
block implicitly have networks: [default]
.)
If you want to reference the service by another name you can use network alias. Modified compose file to use network alias
version: '2'
volumes:
webroot:
driver: local
services:
app: # Launch uwsgi application server
build:
context: ../../
dockerfile: docker/release/Dockerfile
links:
- dbc
volumes:
- webroot:/var/www/someapp
environment:
DJANGO_SETTINGS_MODULE: someapp.settings.release
MYSQL_HOST: dbc
MYSQL_USER: todo
MYSQL_PASSWORD: passwd
command:
- uwsgi
- "--socket /var/www/someapp/someapp.sock"
- "--chmod-socket=666"
- "--module someapp.wsgi"
- "--master"
- "--die-on-term"
networks:
new:
aliases:
- myapp
test: # Run acceptance test cases
image: shamdockerhub/someapp-specs
links:
- nginx
environment:
URL: http://nginx:8000/todos
JUNIT_REPORT_PATH: /reports/acceptance.xml
JUNIT_REPORT_STACK: 1
command: --reporter mocha-jenkins-reporter
networks:
- new
nginx: # Start nginx web server that forwards https packets to uwsgi server
build:
context: .
dockerfile: Dockerfile.nginx
ports:
- "8000:8000"
links:
- app
volumes:
- webroot:/var/www/someapp
networks:
- new
dbc: # Launch MySQL server
image: mysql:5.6
hostname: dbr
expose:
- "3306"
environment:
MYSQL_DATABASE: someapp
MYSQL_USER: todo
MYSQL_PASSWORD: passwd
MYSQL_ROOT_PASSWORD: passwd
networks:
new:
aliases:
- dbr
agent: # Ensure DB server is runnin
image: shamdockerhub/ansible
links:
- dbc
environment:
PROBE_HOST: "dbc"
PROBE_PORT: "3306"
command: ["probe.yml"]
networks:
- new
networks:
new:
that is how Docker works because the hostname
is not unique and that will lead to a problem if you give two containers the same hostname therefore compose will always use the service name for DNS resolution