Hacker News Reader

Comment by daxorid | Hacker News Reader

How do you solve your #2?

We push our docker images to quay.io but pull+deploy is still manual. How does the target platform detect a new container on the registry in order to kick off a pull+deploy?

View on HN

Take a look at Drone (http://readme.drone.io, not to be confused with the hosted Drone app). It allows you to execute arbitrary commands after publishing the Docker image. You can tell it to run kubectl to perform a deploy, for example.

Drone can also run CI tests and build stuff in temporary containers, which avoids the need to compilers etc taking up space in the final image, and negates the need for squashing (which busts your cache).

Much faster than Quay. Quay starts a new VM in AWS every time it builds, which is super slow. Drone just starts containers.

(You have to self-host Drone, though. Since it requires running Docker in privileged mode it's not a good fit for running under Kubernetes, unfortunately.)

(Kubernetes on GKE always runs in privileged mode, but that doesn't mean it's a good idea!)

Quay.io has been beta testing a new build system (based on Kubernetes under the hood) that should make builds a bit faster. If you're interested in testing it out, your organization can be whitelisted. Tweet at @quayio and we can get you set up.

Disclaimer: I work for Red Hat on OpenShift v3, an open-source enterprise-ready distribution of Kubernetes.

We have solved #2 by deploying an internal docker registry [1], push to it once a build succeeds, and automatically (or not) trigger deployments once an expected image lands in it [2].

In the future we will support webhooks so you can trigger deployments from external registries such as quay.io or DockerHub.

You can have a look at the all-in-one VM we have:

git clone https://github.com/openshift/origin

cd origin

vagrant up

vagrant ssh

oc cluster up

The last command will spin up a cluster with a docker registry, a HTTP router, and a bunch of images for you to play around with.

https://asciinema.org/a/49402

[1] The same underlying registry thay powers DockerHub: https://github.com/docker/distribution

[2] A Kubernetes controller loop that watches for new images and triggers new deployments.

There are a number of ways to do this. You could have your CI system create the new object manifest (say nodeapp1.yaml) completely with the image: nodeapp:$version. You could have your CI system do a simple sed, like;

  sed -i -e 's^:latest^:'$VERSION'^' kube/myapp-deployment.yaml

Regardless of how you do that, then your CI/CD can run simple kubectl commands to deploy the new container;

  kubectl apply -f kube/nodeapp-deployment.yaml --record

One of the problems here I've yet to tackle is if the deployment fails and you're doing rolling updates you won't get an exit for the build to fail in CI/CD. I need to do a call to the kubernetes api to see which revision of the container/deployment is now running and compare it to the previously running version to fully automate CI/CD. Haven't had time to set this up but I will soon unless I discover a better method.

Edit: Also I just realized my numbers are 1, 1, 2, 3. Woops.

One of the engineers at CoreOS has a WIP demo that spins up a staging instance of each GitHub PR on Kuberenetes[0]. Here's an example PR [1]. I imagine the scope of this tool could be extended to a staging cluster after merge.

[0]: https://github.com/alekssaul/webhook/tree/github-support [1]: https://github.com/alekssaul/simplewebapp/pull/40

The CI/CD system should do that.

Reply on news.ycombinator.com