3 ms·

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 regi

by daxorid 10y ago

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?

renaudg 10y ago
The CI/CD system should do that.
jzelinskie 10y ago
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 https://github.com/alekssaul/webhook/tree/github-support [1]: https://github.com/alekssaul/simplewebapp/pull/40 https://github.com/alekssaul/simplewebapp/pull/40
swozey 10y ago
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.
lobster_johnson 10y ago
Take a look at Drone (http://readme.drone.io 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!)
- robszumski 10y ago
  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.
xkarga00 10y ago
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 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 https://asciinema.org/a/49402 [1] The same underlying registry thay powers DockerHub: https://github.com/docker/distribution https://github.com/docker/distribution [2] A Kubernetes controller loop that watches for new images and triggers new deployments.

by daxorid 10y ago

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?

renaudg 10y ago

The CI/CD system should do that.

jzelinskie 10y ago

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 https://github.com/alekssaul/webhook/tree/github-support [1]: https://github.com/alekssaul/simplewebapp/pull/40 https://github.com/alekssaul/simplewebapp/pull/40

swozey 10y ago

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.

lobster_johnson 10y ago

Take a look at Drone (http://readme.drone.io 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!)

robszumski 10y ago
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.

xkarga00 10y ago

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 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 https://asciinema.org/a/49402 [1] The same underlying registry thay powers DockerHub: https://github.com/docker/distribution https://github.com/docker/distribution [2] A Kubernetes controller loop that watches for new images and triggers new deployments.