Puppet Blog

Back to Index

Module of the Week: puppetlabs/node_gce – Google Compute Engine Plugin

Posted on
By
teyo
in
Blog, Cloud, Community, DevOps, How to, Module of the Week, Modules, Open Source, Provisioning, Tips
Responses
0 Comments
Purpose Adds support for Google Compute Engine to Cloud Provisioner
Module puppetlabs/node_gce
Puppet Version 2.7.14+
Platforms RHEL5, RHEL6, Debian6

Google Compute Engine (GCE) was announced at Google I/O 2012. Google Compute offers high performance Ubuntu and CentOS systems backed by KVM at Google scale. As part of the announcement we extended Puppet Cloud Provisioner to provide support for deploying compute resource into GCE. This module delivers those Puppet Face extensions as a plugin to Cloud Provisioner.

Installing the module

Complexity Easy
Installation Time 2 minutes

On a machine where you have Puppet and Puppet Cloud Provisioner installed use the Puppet module tool to install the node_gce module from the Puppet Forge. The Learning Puppet VM is a great environment start using the node_gce module. You will also need to sign up for a Preview account to for Google Compute Engine.

From the command line issue the following command to install the module:

puppet module install puppetlabs-node_gce

This will download and install the module and the dependencies from the Puppet Forge to the appropriate module path.

Preparing to install into /etc/puppet/modules ...
Downloading from http://forge.puppetlabs.com ...
Installing -- do not interrupt ...
/etc/puppet/modules
└─┬ puppetlabs-node_gce (v0.0.1)
  ├── puppetlabs-lib_puppet (v0.0.1)
  └── puppetlabs-pe_gem (v0.0.1)

The Google Compute Engine module includes a Puppet manifest that install the Puppet Face in the proper place, and generates a script for building a credentials file. We will use Puppet to apply to the manifest locally.

puppet apply /etc/puppet/modules/node_gce/tests/init.pp

By default, init.pp manifests only install the minimal components. The optional manifest below resolves the following warning messages, but it has additional build dependencies to compile JSON.

Faraday: you may want to install system_timer for reliable timeouts
[WARNING] MultiJson is using the default adapter (ok_json). We recommend loading a different JSON library to improve performance.
 
puppet apply /etc/puppet/modules/node_gce/tests/optional.pp

Next we need to setup our GCE credentials. Once you have received confirmation of your GCE preview account you will need to enable Google Compute Engine under Google API Services. Once you have enabled GCE and created a project, go to API access menu and create a new Client ID for installed applications:

Next, execute the generated credentials script:

/tmp/build_gce_credentials

Copy the generated link into your browser and use the authorization code to complete the credentials file. The script will ask for a file to store your credentials. The node_gce Face expects to find those credentials in ~/.fog.

Enter file for storing OAuth2 credentials [/tmp/oauth2_credentials.yml]: ~/.fog
Storing credentials information in [~/.fog]...

Example ~/.fog:

:gce:
  :client_id: "52313212-idasf921.apps.googleusercontent.com"
  :client_secret: "ida8214kdasfsd93"
  :authorization_code: "sfas1/daf9123123kjfasfojdjsfk213213"
  :refresh_token: "dsfas9123kdsfaj892sadkfa"

Using the node_gce Face

Before creating any Google Compute Nodes, we need to upload SSH keys in order to have access to any new systems created by cloud provisioner. SSH keys can be added to the project via add_metadata action, along with the project id, username, and path to the SSH public key file.

$ puppet node_gce add_metadata --project=puppetlabs.com:gce --user='paul' --sshkey=~/.ssh/paul.rsa.pub

This process can be repeated for multiple users to grant them SSH access to systems under multiple projects. New keys will also distribute to existing systems in the same project, but the process will take time to propagate through the environment (about 60 seconds). In Google Compute, SSH keys are associated with a non-root user account with sudo access, and they are stored in per project metadata ‘sshKeys’ value. The SSH key for each user is separated by newlines, and can be listed by executing metadata action and providing the appropriate project:

$ puppet node_gce metadata --project=puppetlabs.com:gce
{
 "kind": "compute#project",
…
 "commonInstanceMetadata": {
  "kind": "compute#metadata",
  "items": [
   {
    "key": "sshKeys",
    "value": "paul:ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAg...",
   }
  ]
 },

At this point, we can create new compute instances via the create action. Google compute allows users to specify unique hostnames as long they are unique per project. The machine-type indicates the size of system which defaults to n1-standard-1. (For the public preview, Google only made *-d type system available, so specify n1-standard-1d). Zone indicates the preference for the region where the system should be created, which defaults to us-central1-a. See the Google Compute documentation for more information about machine-type and zone.

$ puppet node_gce create --name=demo1 --project=puppetlabs.com:gce --machine-type=n1-standard-2 --zone=us-east1-a
{
 "kind": "compute#instance",
 "id": "12920446812432197392",
 "selfLink": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/instances/demo1",
 "image": "https://www.googleapis.com/compute/v1beta12/projects/google/images/ubuntu-12-04-v20120621",
 "machineType": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/machine-types/n1-standard-2",
 "status": "PROVISIONING",
 "zone": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/zones/us-east1-a",
 "networkInterfaces": [
  {
   "kind": "compute#networkInterface",
   "name": "nic0",
   "network": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/networks/default",
   "networkIP": "10.240.20.171",
   "accessConfigs": [
    {
     "kind": "compute#accessConfig",
     "name": "External NAT",
     "type": "ONE_TO_ONE_NAT",
     "natIP": "173.255.112.192"
    }
   ]
…

The new node status will be “provisioning” initially, and we can use the list action to check when the system transitions to “running”:

$ puppet node_gce list --project=puppetlabs.com:gce

Once the new node is in the running state, we can connect to the system via ssh to its external NAT IP.

$ ssh -i ~/.ssh/private.rsa paul@173.255.112.192

When we are done with the instance simply destroy it via the terminate action:

$ puppet node_gce terminate --project=puppetlabs.com:raiden --name=demo1   
{
 "kind": "compute#operation",
 "id": "12920446812432197392",
 "selfLink": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/operations/operation-1341328670190-4c3ee6ae99b90-444a5700",
 "name": "operation-1341328670190-4c3ee6ae99b90-444a5700",
 "targetLink": "https://www.googleapis.com/compute/v1beta12/projects/puppetlabs.com:gce/instances/demo1",
 "targetId": "12920446812432197392",
 "status": "DONE",
 "user": "paul@puppetlabs.com",
 "progress": 100,
 "insertTime": "2012-07-03T15:17:50.190",
 "startTime": "2012-07-03T15:17:50.356",
 "endTime": "2012-07-03T15:17:58.248",
 "operationType": "delete"
}

Conclusion

Our initial Cloud Provisioner enables you to quickly get started deploying workloads into Google Compute Engine Environments. Next up, we’ll demonstrate bootstrapping a QA environment in Google Compute Engine using Puppet Enterprise.

Learn More

Leave a Response