Hacker News Reader

Comment by daxorid | Hacker News Reader

We've experimented with docker in a few places, and the deployment workflow is just painful:

  1. sudo docker build -t quay.io/foo/bar
  2. sudo docker push quay.io/foo/bar
  3. <login to production>
  4. sudo docker pull quay.io/foo/bar
  5. sudo docker kill foobar
  6. sudo docker rm foobar
  7. sudo docker run -p 80:80 -p 443:443 -e FOO=bar --name foobar --net=host -d quay.io/foo/bar

I can never understand how people talk about docker making deployments somehow easier.

View on HN

How is that painful?

I run a service using docker and have your steps 4 through 7 as part of a systemd unit file. Updating the application requires a single systemd restart command.

could you talk about your deployment scripts ? i am trying to deploy a single flask app which uses redis. I'm not sure how to set up logging, etc. and whether redis and flask will go in the same VM.

Not much in the way of scripts, but the systemd file I use is something like this:

  [Unit]
  Description=App
  After=docker.service
  Requires=docker.service

  [Service]
  TimeoutStartSec=0
  ExecStartPre=/usr/bin/docker pull app
  ExecStartPre=-/usr/bin/docker kill app
  ExecStartPre=-/usr/bin/docker rm app
  ExecStart=/usr/bin/docker run --name app --rm=true -p 80:80 app

  [Install]
  WantedBy=multi-user.target

With something like dokku I could just push the git repo containing the Dockerfile and it would accomplish the same thing

You probably also want to add: PartOf=Docker.service

This will ensure that a restart of the docker service will trigger this service to be restarted.

ElasticBeanstalk streamlines things greatly, and when it works everything is pretty nice. When it fails, though... for instance, just a few days ago, one of the containers failed with an OOM error. For some reason--still unclear--the ECS and/or Docker daemons weren't able to start new containers to replace them, leaving the instance broken for hours. Auto-scaling groups will mitigate this, but it's still unnerving.

Still, I'm liking many aspects our tools. Using Docker with Rocker (https://github.com/grammarly/rocker/) has greatly sped-up CI builds by caching results when the source hasn't changed (especially important in multi-language shops; the Python guys don't want to wait on the Java code to build every time.) Just upload a tagged image to ECR, generate an "application version" referencing those images, and deploy via the Slack bot ("@bula deploy develop develop-XXX-e83fc3bd").

If you're using Kubernetes, steps 3-7 and replaced with a single "kubectl" line, and you can even eliminate that by baking it into your Quay setup. (Why would you ever do step 1-2, though? Quay supports Github hooks.)

We've started using a self-hosted Drone [1] install (not to be confused with the hosted drone.io service, which is not good) to build containers. Unlike Quay, it doesn't launch build VMs, but rather uses Docker containers, so it's very fast. It also supports the notion of build containers, so you can do things like compile C code or run NPM without ending up with any compilers or build tools in any of your image layers; it completely removes the need for a custom "base image" shared among apps. It also lets us add the Kubernetes deploy as a final step after publishing.

[1] http://readme.drone.io/

Bring back the 10,000 line bash scripts, Puppet, configuration drift, inconsistent environments. All is forgiven!

For us: Jenkins do steps 1 and 2. Steps 3-7 is simply "push button" via ansible.

Replace 4 to 7 with a single "kubectl rolling-update".

If your Unix user is in the docker group, no need to sudo.

Reply on news.ycombinator.com