One of the key components of Replica Pools is the template. It contains the declaration of the pool along with a set of attributes. You could think of the template as the metadata of the Replica Pool. This template is actually based on a standard format defined by another related feature of Google Cloud Platform called the Deployment Manager. Let’s explore Google Cloud Deployment Manager and its use cases.
For those of you familiar with AWS CloudFormation, Deployment Manager concept wouldn’t be new. It allows you to declare, deploy and manage GCE resources. Like CloudFormation, Deployment Manager relies on JSON for describing the deployment. It also supports YAML as an alternative markup.
Deployment Manager is extremely useful when you need to create a repeatable configuration that needs to be provisioned and de-provisioned multiple times. For example, product teams need to manage development, test and staging environments for multiple versions of the same product. They may no keep the resources running but need to bring up the environments selectively during the development process. By defining each environment as a deployment template, DevOps teams can easily create a deployment in a short notice. Since it is based on the same template, it is guaranteed to be consistent.
With each minor change in the deployment, templates can be modified and versioned. This makes it efficient to manage the infrastructure configuration per each environment per version. Developers can treat it as an artifact by integrating the template with the source control system. The other use case of Deployment Manager is declaring a disaster recovery deployment template that is identical to the production environment. The template can be used in any region to quickly set up a DR site. Operations team should start with Deployment Manager templates instead of directly creating resources on Google Cloud. It makes the deployment efficient and less error-prone.
Let’s take a close look at Deployment Manager. It has two building blocks -Template and Deployment.
A Template contains the declaration of the deployment. For example, when launching a VM, it will have the machine type, the image, firewall rules, zone, and other settings. Templates can be defined either in JSON or YAML. JSON is preferred when using the API since it can be directly embedded in the HTTP payload. When using the command line tools, Deployment Manager expects a YAML configuration file. You can either create a new template from the scratch or modify an existing template. Google has provided two sample templates for PHP + Nginx and Node.js. Exploring them will give you an idea of the template structure.
Deployments are a concrete instantiation of a template. They turn the declaration of the resources into actual deployment. It is possible to selectively override the settings defined in the template during the deployment. This feature can be used to leverage one template with minor changes that get applied during the deployment.
A Template can contain all the parameters that are used through the API or the command line tool. It can also contain commands that can be executed after launching the resources. For example, a template can contain “sudo apt-get update” command followed by the installation of required packages on a LAMP server running Debian. The following template declares a replica pool of 4 VMs in US-Central1-a zone. The actions section has the commands to install Apache web server on these VMs and creating index.html.
Like Replica Pools, Deployment Manager is in technical preview. To gain access to it, send a request to be whitelisted.
In the upcoming post, we will explore using the combination of Deployment Manager and Replica Pools feature to deploy a load balanced, self-healing, auto-scaled deployment on the Google Cloud Platform.
