Cannot access bridged docker port

[mixxen]

I've started a cluster using the digitalocean.mesophere.com web ui and I'm trying to run a simple nodejs express application in a docker via marathon. Marathon is able run the docker container on the slaves, but I cannot access the bridged port. If I run the docker from the command line on the slave, I am able to access the port. docker ps on one of the slaves is shown below (05a is run by marathon, c55 is run from command line with docker run -d -p 31001:3000 mixxen/express)

CONTAINER ID        IMAGE                   COMMAND             CREATED             STATUS              PORTS                     NAMES
05a1a1754cba        mixxen/express:latest   "npm start"         17 minutes ago      Up 17 minutes       0.0.0.0:31000->3000/tcp   mesos-e4f05672-8e8c-44ca-a47c-94cebe7170ce   
c55b155d8c89        mixxen/express:latest   "npm start"         19 hours ago        Up 19 hours         0.0.0.0:31001->3000/tcp   sad_morse                                    

Below is the JSON sent to /v2/apps

{
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "mixxen/express",
      "network": "BRIDGE",
      "portMappings": [
        { "containerPort": "3000", "hostPort": "0", "protocol": "tcp" }
      ]
     }
  },
  "id": "express3",
  "instances": "1",
  "cpus": ".1",
  "mem": "64",
  "uris": []
}

I am able to see http://serverip:31001 but not http://serverip:31000

[mixxen]

Figured out the issue.... The container's environment variable PORT is being set by marathon. The value of PORT is set to the value of hostPort.

I suggest renaming the environment variable that marathon sets from PORT to HOST_PORT. Many NodeJS/Express projects by convention use the PORT environment variable to configure which port to listen on.

[tnolet]

• ! @mixxen I've hit this problem many times already. Marathon should namespace the environment variables that are used explicitly by Marathon mechanism, i.e. MAR_HOST_PORT or something. The generic $PORT is probably used by many frameworks, apps and packages already.

[mixxen]

@tnolet good idea!

[saulshanabrook]

yeah this would be huge

[kolloch]

1254 is probably a duplicate of this but a bit more specific. Therefore I close this issue.