By Nelson Araujo, Software Engineer
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 Compute Storage: install / docs | source
These new modules are Puppet Approved, having passed the rigorous quality and review bar from Puppet Engineering team, and are open-source under the Apache-2.0 license, available from GCP’s Github repository.
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.
The power of Puppet
It’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.
gauth_credential { ‘mycred':
provider => serviceaccount,
path => ‘/home/nelsona/my_account.json’,
scopes => [‘https://www.googleapis.com/auth/cloud-platform’],
}
gcontainer_cluster { ‘myapp-netes':
ensure => present,
initial_node_count => 2,
node_config => {
machine_type => ‘n1-standard-4′, # we want a 4-core machine for our cluster
disk_size_gb => 500, # … and a lot of disk space
},
zone => ‘us-central1-f’,
project => ‘google.com:graphite-playground’,
credential => ‘mycred’,
}
For specific examples of how to use Puppet with the individual GCP modules, visit their respective Forge pages.
Getting started with Puppet on GCP
To 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.
Apply your manifest.
Let’s discuss these steps in more detail.
1. Install your modules
All 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.
$ puppet apply <<EOF
package { [
‘googleauth’,
‘google-api-client’,
]:
ensure =< present,
provider =< gem,
}
EOF
Here’s the command for Installing all the Puppet modules with a single command:
puppet module install google/cloud
Or, you can install only the modules for select products:
puppet module install google/gcompute # Google Compute Engine
puppet module install google/gcontainer # Google Container Engine
puppet module install google/gdns # Google Cloud DNS
puppet module install google/gsql # Google Cloud SQL
puppet module install google/gstorage # Google Cloud Storage
Once installed, verify the modules’ health by running:
puppet module list
You should see an output similar to:
$ puppet module list
/home/nelsona/.puppetlabs/etc/code/modules
├── google-cloud (v0.1.0)
├── google-gauth (v0.1.0)
├── google-gcompute (v0.1.0)
├── google-gcontainer (v0.1.0)
├── google-gdns (v0.1.0)
├── google-gsql (v0.1.0)
└── google-gstorage (v0.1.0)
/opt/puppetlabs/puppet/modules (no modules installed)
2. Get your service account credentials and enable APIs
To 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.
Click here to learn more about service accounts, and how to create and enable them.
Also make sure you have enabled the the APIs for each of the GCP services you intend to use.
3a. Define authentication mechanism
Once 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 credential parameter.
gauth_credential { ‘mycred':
provider => serviceaccount,
path => ‘/home/nelsona/my_account.json’,
scopes => [‘https://www.googleapis.com/auth/cloud-platform’],
}
For further details on how to setup or customize authentication visit the Google Authentication documentation.
3b. Define your resources
You 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.
gcontainer_cluster { ‘myapp-netes':
ensure => present,
initial_node_count => 2,
node_config => {
machine_type => ‘n1-standard-4′, # we want a 4-core machine for our cluster
disk_size_gb => 500, # … and a lot of disk space
},
project => ‘google.com:graphite-playground’,
credential => ‘mycred’,
}
4. Apply your manifest
Next, tell Puppet to enforce and bring your resources into the state described in the manifest. For example:
puppet apply <your-file.pp>
Please note that you can apply the manifest standalone, one time, or periodically in the background using an agent.
Next steps
You’re now ready to start managing your GCP resources with Puppet, and start reaping the benefits of cross-cloud configuration management. We will continue to improve the modules and add coverage to more Google products. We are also in the process of preparing the technology used to create these modules for release as open source. If you want have questions about this effort please visit Puppet on GCP Discussions forum, or reach out to us on puppet-on-gcp@google.com.
Further Reading
Mini Puppet Quick Start and Tips
Puppet Learning / Training / Certification
Quelle: Google Cloud Platform
Published by