Open CpuID opened 8 years ago
Doing some extra debug now to drop in here to try help find a solution. There are 5 containers in my docker-compose.yml
. It looks like there are some calls to add_dependency
that contain empty objects.
Dropped the following debug into here:
links.each do |service, label|
puts "Link: #{service}. Label: #{label}"
dependency_container = @containers[service]
puts "dependency_container: #{dependency_container}"
container.add_dependency(dependency_container)
end
Got the below result:
Link: redis. Label: redis
dependency_container: #<ComposeContainer:0x000000024f54a0>
Link: elasticsearch. Label: elasticsearch
dependency_container: #<ComposeContainer:0x000000024f6aa8>
Link: redis. Label: redis
dependency_container: #<ComposeContainer:0x000000024f54a0>
Link: /logstash_elasticsearch_41. Label: /logstash_logstash_40/elasticsearch
dependency_container:
Link: /logstash_redis_38. Label: /logstash_logstash_40/redis
dependency_container:
Link: /logstash_redis_38. Label: /logstash_filebeat_37/redis
dependency_container:
It looks like it's trying to find the dependency containers for 2 different formats of links...?
Docker version 1.10.2
The docker-compose.yml in use - minimal redaction, and all unrelated to the issue at hand (all links are there).
One potential solution, requires peer review:
https://github.com/mauricioklein/docker-compose-api/blob/master/lib/docker-compose/models/compose.rb#L57 becomes container.add_dependency(dependency_container) unless dependency_container.nil?
It looks as though when it loads the running containers + the config'ed containers, its attempting to add dependencies twice, in 2 different formats. The config'ed container format seems sufficient?
Hmm one downside to the above, I end up with 2 of one of my containers, specifically logstash
:(
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c22b3a575c41 1fa6a3979958 "/docker-entrypoint.s" 3 minutes ago Up 3 minutes logstash_logstash_44
f6e53546f8a7 2f4591bdf8e44c7482cbae66969849a1 "/docker-entrypoint.s" 3 minutes ago Up 3 minutes logstash_logstash_48
Hello @CpuID
Thanks for submitting this issue and related details.
I'll be checking the problem soon and will work on a fix as soon as possible.
Thanks again and sorry about the bug.
@CpuID I think I found the problem:
After deleted, containers should no longer exist in compose entry, since they don't exist anymore. A call to start was causing the reported error, because dependencies were deleted and, then, the system was trying to restart a nil container.
I've opened the PR #32 with the necessary fix.
Could you please review it?
Since it's approved, I'll merge and release a new version with the bugfix.
Thanks in advance and sorry about the bug.
Bug fixed by PR#32.
Version 1.1.2 generated with related bugfix.
Thanks for the bug submission!
@mauricioklein I think this may need to be reopened, as PR#32 has some slightly adverse effects (when used in my current use case).
With 1.1.2, if I perform the below:
compose = DockerCompose.load("./docker-compose.yml", true)
compose.kill
compose.delete
sleep 1
compose.start
No containers will start at all. If I try this instead:
compose = DockerCompose.load("./docker-compose.yml")
sleep 1
compose.start
Containers start fine as expected. The purpose of the first codeblock is to allow idempotency and cleanup if there were stale containers left behind from a previous run.
I tried another iteration just as a test:
compose1 = DockerCompose.load("./docker-compose.yml", true)
compose2 = DockerCompose.load("./docker-compose.yml")
compose1.kill
compose1.delete
sleep 1
compose2.start
This works as expected, but is obviously not ideal.
@CpuID I think this was a missunderstood from my part, and I apologize about that.
The first behavior is working exactly I expected, despite of this is not in conformity with original Docker Compose.
After some research, the correct fix would be to recreate the deleted containers before starting them again.
I'm reopening this bug and, as soon I have a fix, I'll let you know.
Thanks in advance!
@mauricioklein great thanks :)
Description
When starting the stack with docker-compose-api, and containers from a previous execution are still running, an error occurs after attempting a clean restart.
How to reproduce
What do you expect
The containers to be killed off, and fresh ones started respectively.
What happened instead
An exception was raised,
undefined method 'running?' for nil:NilClass (NoMethodError)
Software:
Full backtrace