The Google GCE cloud and Juju

This document describes details specific to using your existing Google GCE cloud with Juju.

See more: Google GCE

When using this cloud with Juju, it is important to keep in mind that it is a (1) machine cloud and (2) not some other cloud.

See more: Cloud differences

As the differences related to (1) are already documented generically in the rest of the docs, here we record just those that follow from (2).

Requirements:

Permissions: Service Account Key Admin, Compute Instance Admin, and Compute Security Admin.
See more: Google | Compute Engine IAM roles and permissions .

Notes on juju add-cloud

Type in Juju: gce

Name in Juju: google

Notes on juju add-credential

Authentication types

oauth2

Attributes:

  • client-id: client ID (required)

  • client-email: client e-mail address (required)

  • private-key: client secret (required)

  • project-id: project ID (required)

jsonfile

Attributes:

  • file: path to the .json file containing a service account key for your project Path (required)

See more:

If you want to use environment variables:

CLOUDSDK_COMPUTE_REGION

- GOOGLE_APPLICATION_CREDENTIALS=<link to JSON credentials file>

service-account

Requirements:

  • Juju 3.6+.

  • A service account with sufficient privileges. See more: Appendix: Service account requirements

  • The add-credential steps must be run from a jump host running in Google Cloud in order to allow the cloud metadata endpoint to be reached.

See more: Workflow 1 – Service account only (recommended)

Cloud-specific model configuration keys

base-image-path

Base path to look for machine disk images.

type

string

default value

schema.omit{}

immutable

false

mandatory

false

vpc-id-force

Force Juju to use the GCE VPC ID specified with vpc-id, when it fails the minimum validation criteria.

type

bool

default value

false

immutable

true

mandatory

false

vpc-id

Use a specific VPC network (optional). When not specified, Juju requires a default VPC to be available for the account.

Example: vpc-a1b2c3d4

type

string

default value

“”

immutable

true

mandatory

false

Supported constraints

CONSTRAINT

conflicting:

instance-type vs. [arch, cores, cpu-power, mem]

supported?

- allocate-public-ip

✓

- arch

✓

- container

✓

- cores

✓

- cpu-power

✓

- image-id

✕

- instance-role

✕

- instance-type

✓

- mem

✓

- root-disk

✓

- root-disk-source

✕

- spaces

✓

- tags

✕

- virt-type

✕

- zones

✓

Supported placement directives

PLACEMENT DIRECTIVE

<machine>

TBA

subnet=<subnet>

✓

system-id=<system ID>

✕

zone=<zone>

✓

Cloud-specific storage providers

See first: Storage provider

gce

Configuration options:

  • disk-type. Value is pd-ssd. Warning: bug .

Appendix: Example authentication workflows

Workflow 2 – Bootstrap using normal credential; use service account thereafter

Requirements:

  1. Bootstrap with the arg --bootstrap-constraints="instance-role=auto"

  2. The controller machines will be created and attached to the project’s default service account.

  3. Alternatively you can specify a different service account instead of auto.

Tip

To configure workload machines to use a different (less privileged) service account, use the instance-role constraint. This can be set on the model to apply to all (non controller) machines in the model.

Appendix: Service account requirements

To enlist a service account to provide the privileges required by Juju, the following scopes must be assigned:

  • https://www.googleapis.com/auth/compute

  • https://www.googleapis.com/auth/devstorage.full_control