Introducing Puppet support for Google Cloud Platform
The ability to control resources programmatically with tools they know and love can make a big difference for developers creating cloud-native applications. That’s why today, we released and open sourced a set of comprehensive modules to improve the ability for Puppet users to manage Google Cloud Platform (GCP) resources using the Puppet domain specific language, or DSL. The new modules follow Puppet’s object convergence model, allowing you to define the desired state of your GCP resources that our providers will enforce directly within the Puppet language.
The new modules support the following products:
- Google Container Engine: install / docs | source
- Google Compute Engine: install / docs | source
- Google Cloud SQL: install / docs | source
- Google Cloud DNS: install / docs | source
- Google Cloud Storage: install / docs | source
We also released a unified authentication module that provides a single authentication mechanism for all the modules.
The modules have been tested on CentOS, Debian, Ubuntu, Windows and other OS’s. Refer to the operating system support matrix for compatibility details. They work with both Puppet Open Source and Puppet Enterprise.
To learn more, and see them in action, register for the webinar with me and Cody Herriges from Puppet on 13 September 2017.
The power of PuppetIt’s important to note that Puppet is not a scripting language. Rather, it follows an object-convergence model, allowing you to define a desired state for your resource, which our providers make so by applying necessary changes.
In other words, with Puppet, you don’t say “run this list of commands to install Apache on my machine,” you say “Apache should be installed and configured.” There is some nuance here, but with the latter, Puppet handles verifying if Apache is installed, checks for the correct dependencies, upgrades it if it’s not at the correct version and — most importantly — does nothing if everything is good. Puppet already understands the implementation differences across operating system and will handle doing the right thing for your chosen distribution.
Following an object-convergence model has various benefits: It makes your resource manifest declarative, abstracting away various details (e.g., OS-specific actions); and it makes definitions simpler to read, modify and audit. The following manifest creates a full Google Container Engine cluster, in just 15 lines of code.
For specific examples of how to use Puppet with the individual GCP modules, visit their respective Forge pages.
Getting started with Puppet on GCPTo hit the ground running with Puppet and GCP, follow these basic steps:
Install the appropriate modules.
- Get a service account with privileges on the GCP resources you want to manage and enable the the APIs for each of the GCP services you intend to use.
- Describe your GCP infrastructure in Puppet.
- Define a gauth_credential resource.
- Define your GCP resources.
1. Install your modulesAll Google modules for Puppet are available on Puppet Forge. We also provide a “bundle” module that installs every GCP module at once, so you can choose the granularity of the code you pull into your infrastructure.
Note: Google modules requires neither administrator privileges nor special privileges/scopes on the machines being executed. It is safe to install the modules either as a regular user or in your Puppet master. Install on the master if you want it distributed to all clients.
The authentication module depends on a few gems released by Google. As with everything related to system configuration, you can install the gems using Puppet itself.
Here’s the command for Installing all the Puppet modules with a single command:
Or, you can install only the modules for select products:
Once installed, verify the modules’ health by running:
You should see an output similar to:
2. Get your service account credentials and enable APIsTo ensure maximum flexibility and portability, all authentication and authorization to your GCP resources must be done via service account credentials. Using service accounts allows you to restrict the privileges to the minimum necessary to perform the job.
Note: Because service accounts are portable, you don’t need to run Puppet inside GCP. Our modules run on any computer with internet access, including on other cloud providers. You might, for example, execute deployments from within a CI/CD system pipeline such as Travis or Jenkins, or from your own development machine.
Also make sure you have enabled the the APIs for each of the GCP services you intend to use.
3a. Define authentication mechanismOnce you have your service account, add this block to your manifest to begin authenticating with it. The resource title, here
'mycred'is referenced in the objects in the
For further details on how to setup or customize authentication visit the Google Authentication documentation.
3b. Define your resourcesYou can manage any resource for which we provide a type. The example below creates a Kubernetes cluster in Google Container Engine. For the full list of resources that you can manage, please refer to the respective module documentation link or to this aggregate summary view.
4. Apply your manifestNext, tell Puppet to enforce and bring your resources into the state described in the manifest. For example:
Please note that you can apply the manifest standalone, one time, or periodically in the background using an agent.