docker-compose-api
docker-compose-api copied to clipboard
docker-compose.yml host volumes causing an exception - Docker::Error::ServerError
Description
When defining host volumes, an error occurs. Works fine with docker-compose without error.
How to reproduce
statsd:
image: visity/statsd:0.7.2.1
volumes:
- ./statsd_docker_entrypoint_test.sh:/docker-entrypoint.sh:ro
- ./statsd_config_test.js:/opt/statsd/config.js:ro
Both files can be empty to reproduce the error. Any image can probably be used to simulate the issue also. Using a .start
call to spin up the "stack".
What do you expect
Expected a working set of containers.
What happened instead
Exception fired - Docker::Error::ServerError
Software:
- Ruby version: 2.1.6
- Docker-compose-api gem version: 1.1.2
- Running docker-machine on OSX (virtualbox driver), docker version v1.10.3
Full backtrace
/Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-api-1.28.0/lib/docker/connection.rb:50:in `rescue in request': create ./statsd_docker_entrypoint_test.sh: volume name invalid: "./statsd_docker_entrypoint_test.sh" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed (Docker::Error::ServerError)
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-api-1.28.0/lib/docker/connection.rb:38:in `request'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-api-1.28.0/lib/docker/connection.rb:65:in `block (2 levels) in <class:Connection>'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-api-1.28.0/lib/docker/container.rb:277:in `create'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-compose-api-1.1.2/lib/docker-compose/models/compose_container.rb:92:in `prepare_container'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-compose-api-1.1.2/lib/docker-compose/models/compose_container.rb:206:in `start'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-compose-api-1.1.2/lib/docker-compose/models/compose_container.rb:200:in `block in start'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-compose-api-1.1.2/lib/docker-compose/models/compose_container.rb:199:in `each'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-compose-api-1.1.2/lib/docker-compose/models/compose_container.rb:199:in `start'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-compose-api-1.1.2/lib/docker-compose/models/compose.rb:117:in `block in call_container_method'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-compose-api-1.1.2/lib/docker-compose/models/compose.rb:116:in `each'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-compose-api-1.1.2/lib/docker-compose/models/compose.rb:116:in `call_container_method'
from /Users/nathan/.rvm/gems/ruby-2.1.6@infrastructure/gems/docker-compose-api-1.1.2/lib/docker-compose/models/compose.rb:70:in `start'
Hi,
have the same issue: No errors when running the docker-compose.yml
file with docker-compose
, but errors when using specinfra-backend-docker_compose
which by itself uses docker-compose-api
.
Culprit is this volume definition in the docker-compose.yml
file:
volumes:
- ./service_config:/etc/consul.d
System information:
ruby 2.0.0p384 (2014-01-12) [x86_64-linux-gnu]
docker-compose-api (1.1.2)
Docker version 1.11.1, build 5604cbe
docker-compose version 1.7.1, build 0a9ab35
Ubuntu 14.04.4 LTS
Hello there!
Thanks for submitting the bug!
I'll check it to make sure, but reading the backtrace provided by @CpuID, it seems to be a limitation on Docker client, not compose gem.
Just to clarify: this gem is just a layer running over a Docker client for Ruby. So, all container and image related operations, such as committing an image, starting/stopping containers and managing volumes are performed by this Docker client.
I'll check this issue and, if this is indeed a bug in Docker client, I'll submit a bug to it. In that case, there's nothing I can do to overcome this situation in compose gem.
Thanks in advance!
@mauricioklein thanks - that makes sense actually. Keep us posted :)
Thank you @mauricioklein for your quick response. Looking forward to any updates!