Seems like the docker ecosystem has improved a lot since I used it :) I have no idea about docker machine. Let's see if the suggestions that come in can help you. CC: Sébastien Portebois

Ok Siddarthan Sarumathi Pandian .. thanks.

I ask because I think that this should be commum..

1. Build an image with app
2. Publish the image on registry (any can be hub)
3. In some point (this is my question where/when) the server should pull this image and run.

And this should be scale.. I don't like to create scripts on server because if I create a new Droplet, I need to install this script again and this not scale.

Hey there, thanks Siddarthan Sarumathi Pandian for inviting me (unforntunately I was away, came back a few days ago with a ton to catch-up)

To sum-up the issue, if I read it correctly,

• the building is ok
• pushing the new image to some registry is ok
• telling updating the DO droplet to run the new image is the last piece, am I right?

To be honest, I only used Docker-machine for local dev work, not for anything prod-related.

The question is: how is you DO droplet Docker container managed? (ie how does it start, how is it configured, ...)

Since I know little about DO I'll try to avoid saying bullshit, and will rather describe the usual way I do this in other contexts. Hopefully you'll be able to fill the gaps to find the equivalent solution in your stack:

• With ECS, a service is composed of tasks. A task is an instance of a task definition. A given version of a Docker image, its settings (ports, env vars, ...) are a task-definition (in short, some declarative Json with these configs). In order to update a service from an image with a abctag to a newer one with a def tag, you'll create a new task definition, with this new tag (if only the tag changes, it's really the same json, except the docker image tag). Then you'll update the service to run the new task definition (likewise, a rollback is setting the task to run the previous task definition). ECS will do the update for you (even the rolling update, via min healthy percent and max percent to know how much less/more of the desired number of tasks he could have during the update)
• With Kubernetes, a Deployment controls replicaSet. Each replicaSet is a descriptive document of a pod, ie a set of containers and their config, and the resources requests (how much cpu, memory), and the config (env vars, volumes, ...) In order to change a docker image, you apply a template change on the deployment. That template will instanciate a new replicaSet (ie the declaration using the new container), then Kubernetes will orchestrate the update to transition in a rolling-update fashion from the previous replicaSet to the new one (ie, it will decrease the desired count of the previous RS from n to 0, while increasing the desired count of the new replicaset from 0 to 1, so that the sum stay in the rolling update setting you defined for this deployment. The rate of this will be controlled by the minReadyThreshold, the liveness and readyness checks, if you define them). This might sounds complicated if you're new to Kubernetes' Lingo, but it's well thought and really well done (and even easier if you use a template/package manager like Helm). You can have a very quick overview of the deployment mechanisms in KubernetesByExample: kubernetesbyexample.com/deployments

To come back to the docker machine scope, I never thought of using it for such things, so it might be possible or not... I'm not sure (maybe a case of RTFM... or maybe not ^^) . Then, either you use a tool that manage it for you, or you might have to script it if you don't want to add yet another new tool in your stack.