Restoring packages and running locally

Simply do the usual thing

npm i

and start with

npm start


The docker file is all that’s needed to create a container.
It exposes port 3000 which needs to be specified later on when mapping the port to the instance.

FROM node
# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
# Install app dependencies
COPY package.json /usr/src/app/
RUN npm install
# Bundle app source
COPY . /usr/src/app
CMD npm start

Build the image

For example:

Docker build -t orbifold/propensity .

Note the dot at the end!

Rename a container

Use the unique identifier or the first few characters, say ’24drf’:

docker rename 24drf propensity

You can see the image via

Docker images

Run the container

Run it via

Docker run -p 44330:3000 –name propensity -d orbifold/propensity

Browse the container

The docker host has most likely not the localhost address, you can find out by using

docker-machine ip default

Which gives on the Mac usually

Hence, the container with port 44330 can be accessed via

Create an SSH tunnel

You need to have an X509 pair with the public uploaded to Azure. The SSH tunnel is create by specifying the private part in the following command

sudo ssh -i /Users/Swa/Projects/DEC/Microservices/ACS/AzureKey -L 80:localhost:80 -f -N -p 2200

Clash with Marathon

To communicate with Azure you need to set up an SSH tunnel. Usually it persists and you can kill the tunnel explicitly via:

ps -ef |grep ssh
Kill -9 51139

See this article for instance.

Give name or rename a docker image

Docker tag b47e4 orbifold/wsdocker

Note that all names have to be lowercase.

Remove all docker images and containers

docker rm $(docker ps -a -q)
docker rmi $(docker images -q)

Removing the dangling ‘none:none’ images

docker rmi $(docker images -f “dangling=true” -q)

See this article for instance.

Talk to the container

Enter the container via

Docker exec -ti propensity bach

To exit it do CTR+P + CTRL+Q.

Publish container on DockerHub

Docker login
Docker push orbifold/propensity

DCOS dashboards

One you have an SSH tunnel the following dashboard can be accessed:

Instance definition

You can define instance via a form-UI but things are actually easier with JSON:

  "id": "/propensity",
  "cmd": null,
  "cpus": 0.2,
  "mem": 128,
  "disk": 0,
  "instances": 1,
  "portDefinitions": [
      "port": 10000,
      "protocol": "tcp",
      "labels": {}
  "container": {
    "type": "DOCKER",
    "volumes": [],
    "docker": {
      "image": "orbifold/propensity",
      "network": "BRIDGE",
      "portMappings": [
          "containerPort": 3000,
          "hostPort": 80,
          "servicePort": 10000,
          "protocol": "tcp",
          "labels": {}
      "privileged": false,
      "parameters": [],
      "forcePullImage": false
  "acceptedResourceRoles": [

Azure Container Service

The creation of a separate resource group is adviced ‘ cause ACS creates quite a bit of infrastructure


The Marathon UI is similar to the Azure Service Fabric Explorer and manages all apps and scaling:


It also offers a clic-and-go UI to install integrations and is in this respect more ‘open’ than ASF:


Finally Mesos is quite full of info about the health and going of apps:


Personal findings

  • easy learning curve
  • apps are very lightweight. A NodeJS service literally takes a dozen of lines.
  • containers can be simply taken to another cloud without the slightest change.
  • continuous integration with Jenkins or any other continuous service works hand-in-hand with github and docker hub.
  • still in a state of flux. Here and there things fail but it could be because of my lack of expertise as well.
  • docker containers have become universal boxes. Not sure that ignoring this would be a good thing onward.