Publishing ports

[matiasdecarli]

Hi guys!

Maybe this is a silly question, but... is there is any option to publish a port?
The idea is to obtain something similar to this

docker run -t -i -p 8080 matiasdecarli/release-chef /bin/bash

CONTAINER ID        IMAGE                               COMMAND                CREATED              STATUS                      PORTS                     NAMES
56ac6548abae        matiasdecarli/release-chef:latest   "/bin/bash"            19 minutes ago       Up 19 minutes               0.0.0.0:49154->8080/tcp   web02

[johnewart]

Just fixed this in 26c6091

[johnewart]

Also, you'll need to use the master branch as I haven't packaged it yet

[matiasdecarli]

Great stuff @johnewart. Thanks again!

[matiasdecarli]

@johnewart I've updated my gem using the master branch, but the results are the same, using this

  machine_options :docker_options => {
      :base_image => {
          :name => 'matiasdecarli/release-chef',
          :repository => 'matiasdecarli',
          :tag => 'latest'
      },
      :ports => 8080
  }

Am I doing something wrong? Thanks in advance

[johnewart]

If you don't use the :command option, then nothing will be running, so it won't execute the final docker run with -p. What recipe are you running, etc?

[matiasdecarli]

Im using a recipe created by me to provision the created container with a node.js app, and on the command option im trying to init my app like this

      :command => 'node app.js'

The recipe works, it installs everything inside the container, and runs the desired command, but still no ports
Is this the right approach? Thanks!

[johnewart]

Yeah you want something that does not daemonize; what's your complete recipe look like now?

[matiasdecarli]

Currently, its looking like this:

require 'chef_metal'
include_recipe 'docker'

machine "container" do
  recipe 'matiasdecarli::provision_container'

  machine_options :docker_options => {
      :base_image => {
          :name => 'matiasdecarli/release-chef',
          :repository => 'matiasdecarli',
          :tag => 'latest'
      },
      :command => 'node app.js',
      :ports => 8080
  }
end

[johnewart]

Try including the full paths when running -- like /usr/local/bin/node /path/to/app.js

[matiasdecarli]

Even though I use only "node", the process ends, and thats why (I think) I don't see the published ports

CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                      PORTS               NAMES
9163031ce598        chef:web09          "node"                 4 seconds ago       Exited (0) 3 seconds ago                        web09        

When I manually create a container with the same "node" command, it remains open

CONTAINER ID        IMAGE                         COMMAND                CREATED             STATUS                      PORTS               NAMES
677f2a40c4f9        matiasdecarli/release-chef:latest   "node"                 3 seconds ago        Up 2 seconds                0.0.0.0:49153->8080/tcp   hopeful_mcclintock   
9163031ce598        chef:web09                    "node"                 5 minutes ago       Exited (0) 5 minutes ago                        web09

Is this the expected behaviour?

[johnewart]

Yes, if the process ends then the container stops, what is the output from your chef run with -l debug? (can you make a gist of it?)

[matiasdecarli]

https://gist.github.com/matiasdecarli/5a34c9cd0ab5f592aec7

Just for speed purposes I commented the recipe thats done inside the container

[matiasdecarli]

I can see that it runs

docker run --name web22 --detach -p 8080:8080 301e9a73b74099a992d51f5ee4277469011210488452896809604c32d85c6c98 node

When it should run

docker run -i --name web22 --detach -p 8080:8080 301e9a73b74099a992d51f5ee4277469011210488452896809604c32d85c6c98 node

Is this correct? Tested this on bash it works like charm.

[johnewart]

Interesting, -i attaches STDIN, right? Why would node care if there's STDIN attached?

[matiasdecarli]

Right, the help says

  -i, --interactive=false    Keep STDIN open even if not attached

Don't know why, but seems as the right way to do it. Either way, It will be great to have the opportunity to have this as a parameter, don't you think? I don't have much Ruby experience, but think I can make a pull request regarding this

[johnewart]

I'll just make a flag :keep_stdin_open => true since it seems like others may need this

[johnewart]

Added in 5a4ccd7

[matiasdecarli]

Great! Worked as expected. Thanks!

[matiasdecarli]

Ok ,Im going to comment again on this issue.

Using this

args << "#{portnum}:#{portnum}"

We are forcing to have the same port on both host and client. Docker gives us the possibility to pass 1 or 2 ports to have host_port:container_port, which will be a very useful feature. Also will enforce the Docker syntax compatibility.

I actually made a pull request for this