support dynamic port assignment?

[jchauncey]

In my rake file I would like to not specify the host_port value even if my container exposes a port. Is this possible? When I leave out that line I get the following error -

I, [2014-07-29T11:57:55.717050 #57151]  INFO -- : ----- Connecting to Docker on bld-docker-01 -----
/Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/deploy_dsl.rb:46:in `public_port_for': undefined method `values' for nil:NilClass (NoMethodError)
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/deploy.rb:9:in `stop_containers'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/tasks/deploy.rake:40:in `block (3 levels) in <top (required)>'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/deploy_dsl.rb:7:in `call'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/deploy_dsl.rb:7:in `block (2 levels) in on_each_docker_host'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/docker_server_group.rb:20:in `call'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/docker_server_group.rb:20:in `block in each'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/docker_server_group.rb:18:in `each'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/docker_server_group.rb:18:in `each'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/deploy_dsl.rb:7:in `block in on_each_docker_host'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/deploy_dsl.rb:6:in `tap'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/centurion/deploy_dsl.rb:6:in `on_each_docker_host'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/tasks/deploy.rake:40:in `block (2 levels) in <top (required)>'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:228:in `call'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:228:in `block in execute'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:223:in `each'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:223:in `execute'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:166:in `block in invoke_with_call_chain'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:159:in `invoke_with_call_chain'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:152:in `invoke'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/capistrano_dsl.rb:88:in `invoke'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/tasks/deploy.rake:7:in `block in <top (required)>'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:228:in `call'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:228:in `block in execute'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:223:in `each'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:223:in `execute'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:166:in `block in invoke_with_call_chain'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:159:in `invoke_with_call_chain'
    from /Users/pairing/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/rake/task.rb:152:in `invoke'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/lib/capistrano_dsl.rb:88:in `invoke'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/gems/centurion-1.0.10/bin/centurion:74:in `<top (required)>'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/bin/centurion:23:in `load'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/bin/centurion:23:in `<main>'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/bin/ruby_executable_hooks:15:in `eval'
    from /Users/pairing/.rvm/gems/ruby-2.0.0-p353/bin/ruby_executable_hooks:15:in `<main>'

[tdooner]

+1. This is super important if you want to run multiple of the same Docker image on the same host, which is a pretty common desire I imagine.

[intjonathan]

We've encountered need for this as well, would a convention like

host 'docker-1', host_port: 8080, container_port: 80
host 'docker-1', host_port: 8081, container_port: 80

be a helpful change?

[jchauncey]

I would jsut like to leave out the host port all together and let docker assign a port dynamically.

[relistan]

Currently we can't leave the port out entirely because this is the mechanism that Centurion uses for identifying which container is your container. If you leave it to assign randomly, then it will not be able to find them to restart/stop them later when you need it to. The error message it gives should be much better, however, and this should be something we spell out in the README.

We have talked about other ideas such as custom naming or tagging. So far we have not had a need to do either, but have leaned toward custom container naming. A PR implementing that would be welcome.

[jchauncey]

So im almost done reimplementing centurion to use docker-api and once thats done doing this is next on my list. It would be trivial to convert to use container names instead of host port mapping for stopping the container. On Aug 5, 2014 3:51 PM, "Karl Matthias" [email protected] wrote:

Currently we can't leave the port out entirely because this is the mechanism that Centurion uses for identifying which container is your container. If you leave it to assign randomly, then it will not be able to find them to restart/stop them later when you need it to. The error message it gives should be much better, however, and this should be something we spell out in the README.

We have talked about other ideas such as custom naming or tagging. So far we have not had a need to do either, but have leaned toward custom container naming. A PR implementing that would be welcome.

Reply to this email directly or view it on GitHub https://github.com/newrelic/centurion/issues/18#issuecomment-51265495.

[relistan]

This is pending changes to back Centurion with the API gem.

[relistan]

Problematically for the best implementation, the docker-api gem uses a class variable to control the Docker URL which makes it very hard to use. This issue is now pending a wider scope project.

[relistan]

We're approaching being able to handle dynamic ports. We'll be moving to identifying services by name rather than port. In Centurion 1.5.1 we made naming services the default. I'll be working on this shortly.

[intjonathan]

:100:

[chromerobv]

any news on when this will be rolled out?

[relistan]

The support is all in for using containers solely by name thanks to @kremso and @intjonathan. There is more work needed to do dynamic ports, but it should be pretty small. We don't currently have it planned, but welcome a PR.