Reputation: 6741
Long story short: fig up
doesn't link 2 containers properly when docker run
does.
Scenario:
There are 2 containers: one with Cassandra, another with client service. When containers start Client expects to have cassandra
hostname in hosts file and be able to reach it's 9042 port.
I use docker's links to tight containers together. Here is a fig.yml
:
cassandra:
image: "myrepo/cassandra"
ports:
- "7199:7199"
- "9042:9042"
- "9160:9160"
- "61621:61621"
- "2222:22"
hostname: cassandra
client:
image: myrepo/client
links:
- cassandra
ports:
- "8098:8098"
- "8099:8099"
hostname: client
When I do fig up client
, fig starts cassandra, then client but client cannot reach the cassandra container (it can ping it, but cannot reach the 9042 port).
However, if I start cassandra with fig up cassandra
and then run:
docker run --link tramm_cassandra_1:cassandra --link tramm_cassandra_1:cassandra_1 --link tramm_cassandra_1:tramm_cassandra_1 -p 8098:8098 -p 8099:8099 myrepo/client
then client can communicate with cassandra without a problem.
I've inspected containers and here are the output:
- cassandra inspect
- fig up client inspect
- docker run client inspect
The only difference I can find is in HostConfig -> Devices
and HostConfig -> LxcConf
. In fig-up version they are equal to null
, in docker-run version - to []
.
Can somebody explain a difference between fig up
and docker run
and why it works in 'native' docker scenario and doesn't in fig.
Upvotes: 0
Views: 339
Reputation: 3917
It's probably because cassandra takes a lot of time to actually start listening on the port. Try fig up cassandra
, wait for a while, and then fig up --no-recreate client
.
See also:
Proposal: Containers should not be considered started until the TCP ports they expose are open
Is there a way to delay container startup to support dependant services with a longer startup time
Upvotes: 2