@hashicorp
The googlecompute plugin can be used with HashiCorp Packer to create custom images on GCE.
- Official
- HCP Ready
Updated 2 years ago
- GitHub(opens in new tab)
Google Cloud Platform
The Google compute Packer plugin lets you create custom images for use within Google Compute Engine (GCE).
Installation
To install this plugin, copy and paste this code into your Packer configuration, then run packer init
.
Alternatively, you can use packer plugins install
to manage installation of this plugin.
Components
Builders
- googlecompute - The googlecompute builder creates images from existing ones, by launching an instance, provisioning it, then exporting it as a reusable image.
Post-Processors
googlecompute-import - The googlecompute-import post-processor imports an existing raw disk image, and imports it as a GCE image that can be used for launching instances from.
googlecompute-export - The googlecompute-export post-processor exports the image built by the googlecompute builder as a .tar.gz archive into Google Cloud Storage (GCS).
Authentication
Authenticating with Google Cloud services requires either a User Application Default Credentials,
a JSON Service Account Key or an Access Token. These are not required if you are
running the googlecompute
Packer builder on Google Cloud with a
properly-configured Google Service
Account.
The following options are available for the googlecompute
builder, the googlecompute-export, and
the
googlecompute-import`:
access_token
(string) - A temporary OAuth 2.0 access token obtained from the Google Authorization server, i.e. theAuthorization: Bearer
token used to authenticate HTTP requests to GCP APIs. This is an alternative toaccount_file
, and ignores thescopes
field. If both are specified,access_token
will be used over theaccount_file
field.These access tokens cannot be renewed by Packer and thus will only work until they expire. If you anticipate Packer needing access for longer than a token's lifetime (default
1 hour
), please use a service account key withaccount_file
instead.account_file
(string) - The JSON file containing your account credentials. Not required if you run Packer on a GCE instance with a service account. Instructions for creating the file or using service accounts are above.credentials_file
(string) - The JSON file containing your account credentials.The file's contents may be anything supported by the Google Go client, i.e.:
- Service account JSON
- OIDC-provided token for federation
- Gcloud user credentials file (refresh-token JSON)
- A Google Developers Console client_credentials.json
credentials_json
(string) - The raw JSON payload for credentials.The accepted data formats are same as those described under credentials_file.
impersonate_service_account
(string) - This allows service account impersonation as per the docs.vault_gcp_oauth_engine
(string) - Can be set instead of account_file. If set, this builder will use HashiCorp Vault to generate an Oauth token for authenticating against Google Cloud. The value should be the path of the token generator within vault. For information on how to configure your Vault + GCP engine to produce Oauth tokens, see https://www.vaultproject.io/docs/auth/gcp You must have the environment variables VAULT_ADDR and VAULT_TOKEN set, along with any other relevant variables for accessing your vault instance. For more information, see the Vault docs: https://www.vaultproject.io/docs/commands/#environment-variables Example:"vault_gcp_oauth_engine": "gcp/token/my-project-editor",
Running locally on your workstation.
If you run the googlecompute
Packer builder locally on your workstation, you will
need to install the Google Cloud SDK and authenticate using User Application Default
Credentials.
You don't need to specify an account file if you are using this method. Your user
must have at least Compute Instance Admin (v1)
& Service Account User
roles
to use Packer succesfully.
Running on Google Cloud
If you run the googlecompute
Packer builder on GCE or GKE, you can
configure that instance or cluster to use a Google Service
Account. This will allow
Packer to authenticate to Google Cloud without having to bake in a separate
credential/authentication file.
It is recommended that you create a custom service account for Packer and assign it
Compute Instance Admin (v1)
& Service Account User
roles.
For gcloud
, you can run the following commands:
The service account will be used automatically by Packer as long as there is no account file specified in the Packer configuration file.
Running outside of Google Cloud
The Google Cloud Console allows
you to create and download a credential file that will let you use the
googlecompute
Packer builder anywhere. To make the process more
straightforwarded, it is documented here.
Log into the Google Cloud Console and select a project.
Click Select a project, choose your project, and click Open.
Click Create Service Account.
Enter a service account name (friendly display name), an optional description, select the
Compute Engine Instance Admin (v1)
andService Account User
roles, and then click Save.Generate a JSON Key and save it in a secure location.
Set the Environment Variable
GOOGLE_APPLICATION_CREDENTIALS
to point to the path of the service account key.
Precedence of Authentication Methods
Packer looks for credentials in the following places, preferring the first location found:
An
access_token
option in your packer file.An
account_file
option in your packer file.A JSON file (Service Account) whose path is specified by the
GOOGLE_APPLICATION_CREDENTIALS
environment variable.A JSON file in a location known to the
gcloud
command-line tool. (gcloud auth application-default login
creates it)On Windows, this is:
On other systems:
On Google Compute Engine and Google App Engine Managed VMs, it fetches credentials from the metadata server. (Needs a correct VM authentication scope configuration, see above.)
Examples
Basic Example
Below is a fully functioning example. It doesn't do anything useful since no provisioners or startup-script metadata are defined, but it will effectively repackage an existing GCE image.
JSON
HCL2
Windows Example
Before you can provision using the winrm communicator, you need to allow traffic through google's firewall on the winrm port (tcp:5986). You can do so using the gcloud command.
Or alternatively by navigating to https://console.cloud.google.com/networking/firewalls/list.
Once this is set up, the following is a complete working packer config after
setting a valid project_id
:
JSON
HCL2
Warning: Please note that if you're setting up WinRM for provisioning, you'll probably want to turn it off or restrict its permissions as part of a shutdown script at the end of Packer's provisioning process. For more details on the why/how, check out this useful blog post and the associated code: https://missionimpossiblecode.io/post/winrm-for-provisioning-close-the-door-on-the-way-out-eh/
This build can take up to 15 min.
Windows over WinSSH Example
The following uses Windows SSH as backend communicator https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse
Windows over WinSSH - Ansible Provisioner
The following uses Windows SSH as backend communicator https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse with a private key.
- The
sysprep-specialize-script-cmd
creates thepacker_user
and adds it to the local administrators group and configures the ssh key, firewall rule and required permissions.
Nested Hypervisor Example
This is an example of using the image_licenses
configuration option to create
a GCE image that has nested virtualization enabled. See Enabling Nested
Virtualization for VM
Instances
for details.
JSON
HCL2
Shared VPC Example
This is an example of using the network_project_id
configuration option to create
a GCE instance in a Shared VPC Network. See Creating a GCE Instance using Shared
VPC
for details. The user/service account running Packer must have Compute Network User
role on
the Shared VPC Host Project to create the instance in addition to the other roles mentioned in the
Running on Google Cloud section.
JSON
HCL2
Separate Image Project Example
This is an example of using the image_project_id
configuration option to create
the generated image in a different GCP project than the one used to create the virtual machine. Make sure that Packer has permission in the target project to manage images, the Compute Storage Admin
role will grant the desired permissions.
JSON
HCL2