AnsibleByExample

Ansible google.cloud Collection Example: Automate Compute and Secret Manager

Intermediate
2024-01-013By Luca Berton

Lesson 1 of 25 in AWS Automation

AWS with Ansible — full curriculum
  1. 1. AWS Basics for Ansible
  2. 2. Installing the amazon.aws Collection and boto3
  3. 3. AWS Credentials and Profiles: Safe Configuration
  4. 4. Your First AWS Playbook: Regions, Tags and Idempotency
  5. 5. AWS Dynamic Inventory with the aws_ec2 Plugin
  6. 6. Grouping and Filtering Hosts with keyed_groups and Filters
  7. 7. Provisioning EC2 Instances
  8. 8. AMIs and Launch Templates
  9. 9. Building VPC Networks with Ansible
  10. 10. Security Groups and Network Access Control
  11. 11. Elastic IPs and Load Balancers
  12. 12. S3 Buckets and Object Management
  13. 13. IAM Users, Roles and Policies
  14. 14. RDS Databases with Ansible
  15. 15. Route 53 DNS Automation
  16. 16. CloudWatch Monitoring and Alarms
  17. 17. Managing Secrets: Secrets Manager, SSM Parameter Store and Ansible Vault
  18. 18. Post-Provisioning Configuration with Roles
  19. 19. Bridging Provisioning and Configuration: add_host and wait_for
  20. 20. Auto Scaling Groups and Rolling Updates
  21. 21. Validating Infrastructure with Assertions and Health Checks
  22. 22. Error Handling and Rollback in AWS Playbooks
  23. 23. Structuring a Reusable AWS Automation Project
  24. 24. Cost Control and Teardown Playbooks
  25. 25. Capstone: Provision and Configure a Multi-Tier AWS Application
View path overview →

At Red Hat Tech Day Netherlands 2026 (3 June 2026, Bunnik), the Ansible team announced 12 new content collections landing in AAP 2.7. Among them, google.cloud gets refreshed content spanning Cloud Build 2nd gen, Parameter Manager, Compute, Secret Manager, and Storage. Below is a runnable playbook that provisions a Compute instance and reads a Secret Manager secret to bootstrap it.

Example playbook

---
- name: Provision a GCE instance and inject a secret from Secret Manager
  hosts: localhost
  connection: local
  gather_facts: false
  vars:
    gcp_project: "my-gcp-project"
    gcp_zone: "europe-west4-a"
    gcp_region: "europe-west4"
    gcp_cred_file: "/etc/ansible/secrets/gcp-sa.json"
    instance_name: "web-app-01"
    secret_id: "db-password"

  tasks:
    - name: Fetch the latest version of a Secret Manager secret
      google.cloud.gcp_secret_manager_secret_version_info:
        secret: "{{ secret_id }}"
        project: "{{ gcp_project }}"
        auth_kind: serviceaccount
        service_account_file: "{{ gcp_cred_file }}"
      register: db_secret

    - name: Create a Compute Engine instance
      google.cloud.gcp_compute_instance:
        name: "{{ instance_name }}"
        machine_type: e2-medium
        zone: "{{ gcp_zone }}"
        project: "{{ gcp_project }}"
        auth_kind: serviceaccount
        service_account_file: "{{ gcp_cred_file }}"
        disks:
          - auto_delete: true
            boot: true
            initialize_params:
              source_image: projects/debian-cloud/global/images/family/debian-12
        network_interfaces:
          - network: null
            access_configs:
              - name: External NAT
                type: ONE_TO_ONE_NAT
        metadata:
          db-password: "{{ db_secret.payload }}"
        labels:
          environment: production
          managed_by: ansible
        status: RUNNING
      register: gce_instance

    - name: Show the instance's assigned external IP
      ansible.builtin.debug:
        msg: "{{ gce_instance.networkInterfaces[0].accessConfigs[0].natIP }}"

What it does and why

The first task reads the current version of a Secret Manager secret using gcp_secret_manager_secret_version_info, which is the pattern the refreshed google.cloud collection standardizes on for read-only secret lookups — no need to shell out to gcloud or hardcode credentials in a vars file. The second task uses gcp_compute_instance to create a Debian-based VM, passing the secret's payload into instance metadata so a startup script on the VM can retrieve it locally. This mirrors a common pattern: keep application secrets in Secret Manager, and let the automation layer inject just-in-time values at provisioning time rather than baking them into images or playbooks.

Both modules authenticate with a service account JSON key file via auth_kind: serviceaccount, which is the standard approach for unattended AAP job execution — you'd typically store gcp_cred_file as a machine credential in AAP rather than a plain playbook variable.

Notes

  • Module names shown (gcp_compute_instance, gcp_secret_manager_secret_version_info) follow the collection's existing naming convention; consult the shipped collection docs on your AAP 2.7 instance for the exact parameter set once the refreshed content lands, since Secret Manager and Compute both received expanded module coverage in this release.
  • Never print db_secret.payload with debug in a real playbook — treat it as sensitive and mark it no_log: true on any task that touches it.
  • Passing secrets through instance metadata is convenient for demos; for production, prefer having the instance's own service account pull the secret directly from Secret Manager at boot, so the value never transits the control node.
  • The collection also ships Cloud Build 2nd gen, Parameter Manager, and Storage modules from the same Tech Day Netherlands 2026 announcement — useful for extending this playbook into a full CI/CD-to-provisioning pipeline.

Takeaway

The refreshed google.cloud collection lets a single playbook chain Secret Manager reads directly into Compute provisioning, keeping GCP automation credential-safe and declarative inside AAP 2.7.

References

All Tutorials