Updating docker image on container-vm

[David Grant]

Hi all,

I've read this document here: https://cloud.google.com/compute/docs/containers/container_vms to set up GCE instances using the "container-vm" image. We are now using it in production. If I want to upgrade my docker image, I push a new image of our product to gcr.io and then I reboot the VM (this causes the VM to grab our latest docker image from grc.io). Is there any other way to do this? Is there any functionality within container-vm to hot-swap a newer docker image from gcr.io without rebooting the whole VM?

Should I move away from containers on GCE and move to Container Engine instead?

Thanks,

Dave

[Robert Bailey]

On Fri, Apr 15, 2016 at 8:25 AM, David Grant <david...@poweredbygrow.com> wrote:

Hi all,

I've read this document here: https://cloud.google.com/compute/docs/containers/container_vms to set up GCE instances using the "container-vm" image. We are now using it in production. If I want to upgrade my docker image, I push a new image of our product to gcr.io and then I reboot the VM (this causes the VM to grab our latest docker image from grc.io). Is there any other way to do this? Is there any functionality within container-vm to hot-swap a newer docker image from gcr.io without rebooting the whole VM?

There isn't anything built into the container VM base image that would help you automate this. There are a few ways that you could push a new image (write a new file on disk, update metadata, reboot) but you will have to write your own custom tooling for all of them.

 

Should I move away from containers on GCE and move to Container Engine instead?

If you are deploying containers, then I would highly recommend that you use Google Container Engine (or Kubernetes), as those products have API that allow you to manage your applications, including rolling update to push new application versions. 

 

Thanks,

Dave

--
You received this message because you are subscribed to the Google Groups "Containers at Google" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-contain...@googlegroups.com.
To post to this group, send email to google-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-containers.
For more options, visit https://groups.google.com/d/optout.

[David Grant]

On Fri, Apr 15, 2016 at 11:26 AM, 'Robert Bailey' via Containers at Google <google-c...@googlegroups.com> wrote:

On Fri, Apr 15, 2016 at 8:25 AM, David Grant <david...@poweredbygrow.com> wrote:

Hi all,

I've read this document here: https://cloud.google.com/compute/docs/containers/container_vms to set up GCE instances using the "container-vm" image. We are now using it in production. If I want to upgrade my docker image, I push a new image of our product to gcr.io and then I reboot the VM (this causes the VM to grab our latest docker image from grc.io). Is there any other way to do this? Is there any functionality within container-vm to hot-swap a newer docker image from gcr.io without rebooting the whole VM?

There isn't anything built into the container VM base image that would help you automate this. There are a few ways that you could push a new image (write a new file on disk, update metadata, reboot) but you will have to write your own custom tooling for all of them.

 

Should I move away from containers on GCE and move to Container Engine instead?

If you are deploying containers, then I would highly recommend that you use Google Container Engine (or Kubernetes), as those products have API that allow you to manage your applications, including rolling update to push new application versions. 

Awesome thanks for the advice.

Currently I have a containers.yaml and one or more Dockerfile. Is the containers.yaml re-usable with Container Engine / Kubernetes? What I'm wondering is how much work it is to move from container-vm on GCE to Kubernetes.

David 

[Robert Bailey]

The containers.yaml is close to what you would submit to a GKE/Kubernetes cluster, but not quite the same (it's a subset of the fields). You will need to decide how to deploy your application and pick the appropriate controller (since you really don't want to launch bare pods):

1. Replica Set (legacy name is replication controller): You want N copies of your pod (where N does not need to match the number of nodes in your cluster). Pods will be spread across nodes depending on space, and multiple copies can land on a single node.

2. Deployment: Like a replica set but with versions to enable server-side rolling updates and roll backs (with replica sets, you can only do this via client side commands). 

3. Daemon Set: You want exactly 1 copy of your pod on each node (or each node with a label).

Daemon Set seems to map what you are doing manually today, but that doesn't mean it's the right way to map your application onto a cluster of nodes.