I'm in the process of attempting to containerize our development environment with docker. This includes a mix of Google Appengine projects as well as services that are being eventually hosted in Google Compute engine within a containerized vm.
Our current development environment bootstrapping scripts bring up elasticsearch and nginx within boot2docker and the other applications run on localhost:{product port} within the dev_appserver appengine sandbox. This process is proving hard to manage and maintain as it takes a lot of insight into how our applications communicate.
I'm getting an error with docker-compose that is detecting a circular dependency between containers.
Circular import between cs and vbc and aa and sr.
As this configuration is only for development environments (mac osx), does anyone have an suggestions or ideas on a different approach to take when linking all of the product suites dependencies together.
A portion of docker-compose.yml:
elasticsearch:
build: ./compute/containers/elasticsearch/elasticsearch
ports:
- "9200:9200"
environment:
- PROJECT_ID=localhost
nginx:
build: ./compute/containers/elasticsearch/nginx
links:
- elasticsearch:localhost
ports:
- "9201:9201"
cs:
build: ./CS
command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8080 --admin_port=9080 --storage_path=/data/
ports:
- "8080:8080"
- "9080:9080"
volumes:
- /Users/source/CS/src:/src
- /Users/source/CS/data:/data
aa:
build: ./AA
command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8081 --admin_port=9081 --storage_path=/data/
links:
- vbc:vbc-local
- st:st-local
- elasticsearch:localhost
ports:
- "8081:8081"
- "9081:9081"
volumes:
- /Users/source/AA/src:/src
- /Users/source/AA/data:/data
vbc:
image: google/cloud-sdk
command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8082 --admin_port=9082 --storage_path=/data/
links:
- cs:cs-local
- sr:sr-local
- sm:sm-local
- ms:ms-local
- st:st-local
- cis:cis-local
- elasticsearch:localhost
ports:
- "8082:8082"
- "9082:9082"
volumes:
- /Users/source/VBC/src:/src
- /Users/source/VBC/data:/data
sr:
build: ./SR
command: dev_appserver.py /src/ --host=0.0.0.0 --admin_host=0.0.0.0 --port=8083 --admin_port=9083 --storage_path=/data/
links:
- cs:cs-local
- aa:aa-local
ports:
- "8083:8083"
- "9083:9083"
volumes:
- /Users/source/SR/src:/src
- /Users/source/SR/data:/data
You should be able to use the following solution soon.
The circular linking is being fixed in PR # 1676
This is how they're addressing the issue. Simply put, they're going to make the containers able to speak to each other without linking. I've added the updates to the Docker Compose documentation below:
By default, Compose sets up a single default network for your app. Each container for a service joins the default network and is discoverable via DNS under the service's name.
Note: Your app's network is given the same name as the "project name", which is based on the name of the directory it lives in. See the CLI docs for how to override it.
For example, suppose your app is in a directory called myapp
, and your docker-compose.yml
looks like this:
web:
build: .
ports:
- "8000:8000"
db:
image: postgres
When you run docker-compose up
, the following happens:
myapp
is created.web
's configuration. It joins the network myapp
under the name web
.db
's configuration. It joins the network myapp
under the name db
.Each container can now look up the hostname web
or db
and get back the appropriate container's IP address. For example, web
's application code could connect to the URL postgres://db:5432
and start using the Postgres database.
Because web
explicitly maps a port, it's also accessible from the outside world via port 8000 on your Docker host's network interface.
Further reading on the experimental Docker networking API: https://github.com/docker/docker/blob/master/experimental/networking_api.md