Hacker News Reader

Comment by raarts | Hacker News Reader

It feels downplayed in this article, so I would like to state for the record here, I am a happy user of Docker Swarm.

Swarm has been shown to scale to tens of thousands of hosts, but I found it easy to start with, especially with the Gitlab CI support, which natively brings a Docker container registry.

So I commit, CI builds my containers, stores them in my private registry, and automatically deploys from there to the Swarm in various environments. All this was much easier to setup than the alternatives.

Also, I expect an easy transition should I need to move to Mesos or k8s. If I ever need to. In the mean time I like to keep it simple.

View on HN

I'm also a user of Docker Swarm - and I love it! I have extensively played with k8s and feel it has a lot of upfront complexity (especially ingress).

I feel people who are beginning to scale from one machine to 10 will love Docker Swarm (and stick with it). While those who have about 100 machines will start with Mesos/K8s.

There's no direct migration path from Swarm to Kubernetes, so we chose to start out at a small scale with the latter. It was enough of a leap to fundamentally change how we were building and deploying things. We didn't want to do it twice!

You can dodge much of the operational complexity in standing a cluster up by starting with Google Container Engine or a provisioner like kops. Once you have enough comfort, you can get more fancy and build something more customized to your cases.

actually - i think the other way.

I'm not sure if people who start with Docker Swarm will want to migrate to k8s at all. It works damn well and i have been very happy with it. It has been demonstrated to work at scale.

K8s does have Google behind it though

How do you automate the updating of images on Docker Swarm?

I can't talk for the original poster, but I also deploy containers from Gitlab Registry via Gitlab CI pipelines and just use the standard docker swarm commands. So updating the image digest (version) of a service is as simple as running a shell command in a job in a deploy stage in your gitlab ci pipeline:

docker service update --image <some-image:version> --with-registry-auth <some-service>

Simplest example would be a job definition like this: https://pastebin.com/KsG0cDzR

This job would have to be preceded by building the new docker image you are going to update to of course.

What I've found to work well is to push images to your registry with a different tag for each release. For instance, you have "web:1.0" running in production and want to update? Create a "web:1.1" image, push it to your registry and in Docker Swarm, point your "web" service to the "web:1.1" image instead of "web:1.0".

I define a docker stack .yml file, and have GitLab CI run docker stack deploys.

I do this:

    docker build -t $APPNAME:$timestamp .
    OUTPUT="$(docker service inspect -f '{{.Spec.Name}}' sv-$APPNAME || true)"
    if [ "$OUTPUT" == "" ]; then
      # Service does not exist
      echo "Creating service"
      docker service create --update-delay 5s \
        --publish $PUBPORT:8080 --replicas 2 \
        --mount type=bind,source=$(cd ../images; pwd),target=/images,readonly=true \
        --mount type=bind,source=$(cd ../processed_images; pwd),target=/app/images \
        --mount type=bind,source=$(cd ..; pwd)/config.json,target=/config.json,readonly=true \
        --mount type=bind,source=$(cd ~/.aws; pwd),target=/root/.aws,readonly=true \
        --name sv-$APPNAME $APPNAME:$timestamp
    else
      # Service exists
      echo "Updating service"
      docker service update --image $APPNAME:$timestamp sv-$APPNAME

I haven't looked in a while, but it would be nice if they had some kind of "upstall" (update/install) kinda like upsert (update/insert) in CRUD land.

This is the easiest part, you just call:

  docker service update --image $image_name:$new_sha $service_name

and Swarm handles the rest. You can even pass in rolling update options, so the container updates are staggered. Put this into a simple bash script that only runs when the current branch is master. (Because your CI is building every branch to give you fast feedback, right?) In the case of CircleCI or TravisCI, that can be done with something like:

  if [ "${CIRCLE_BRANCH}" == "master" ]; then

*Marathon on Mesos. :P

Reply on news.ycombinator.com