Containers Four Ways
At one of the local meetups I attend containers and containerization is a relatively common topic of discussion. Google is a big advocate of containers so it probably isn’t a surprise that there are four different ways to run a container on Google Cloud Platform.
Kubernetes and Google Container Engine
The most obvious way to run a container on Google Cloud is using Kubernetes with Google Container Engine. Kubernetes is an open source container orchestration tool that started at Google. I like that when using Kubernetes you describe what a healthy running system should look like. You write out files describing what sets of containers you want (pods), how many of each set you need, and how they should communicate with each other. Kubernetes schedules the containers on VMs and takes care of the networking.
Kubernetes and Container Engine are a good choice when your system has multiple components with different scaling characteristics. For example, you might have an authentication service and a data processing service. With Kubernetes, you can easily accommodate the different scaling characteristics of each of these services. You can put the containers that run each service in different pods and create different auto-scaling rules for each type of pod. Kubernetes gives you the advantage of auto-scaling logic and a degree of auto-healing. If a VM hosting your containers goes down Kubernetes will reschedule the containers that were running on that VM automatically on one of the remaining hosts. And finally, Kubernetes supports rolling updates which are great if you practice continuous deployment on your application.
App Engine Flex
If you only have one container and that container runs a web app then App Engine Flex is a great way to run it. App Engine Flex gives you many of the advantages of App Engine (auto-scaling, auto-healing, integrated diagnostics, and simple deployment) but you aren’t limited to the restricted runtimes App Engine used to use. Instead, there are base Dockerfile based images for each supported language. And if the existing container images don’t work for you then you can use your own container image by using custom runtimes.
App Engine Flex is still in beta but it is worth a look if your application runs a website or web backend and you want to run it in a fully managed platform. With App Engine Flex you get all the advantages of a container based platform (fast startup time and portability) but you don’t have to write the Dockerfile yourself if you don’t want to. Also, Flex has great support for updating your app seamlessly.
Container Image for Managed Instance Groups
If you only have one container you need to run you can also use a container image running on Managed Instance Groups. This feature is currently in Alpha so you must ask to be added to the white list to use it.
To use this method for running containers on GCP you have to write your own Dockerfile, build it, and push it to Google Container Registry. You can also use a publicly available image from Docker Hub. This way to run containers is a good match for container workloads that aren’t for websites, such as data processing. It is also a good choice when you want full control over how containers are distributed over your VMs. It supports both running a single container on each VM and running multiple containers. It does not currently support rolling updates, which is another reason it isn’t ideal for websites.
Google Compute Engine
The final way to run containers on Google Cloud Platform is by running your containers on plain old Compute Engine VMs. Running your containers this way gives you the most control over how they are run. But you have to install all the infrastructure for running the containers yourself. If you need very tight control over exactly how your containers run or you aren’t ready to move to a more managed tool this is another option for running containers on GCP.
Conclusion
That is four different ways to run containers on Google Cloud Platform. Hopefully, there’s one that will work for you.