google.cloud.gcp_compute_node_template module – Creates a GCP NodeTemplate
Note
This module is part of the google.cloud collection (version 1.4.1).
You might already have this collection installed if you are using the ansible
package.
It is not included in ansible-core
.
To check whether it is installed, run ansible-galaxy collection list
.
To install it, use: ansible-galaxy collection install google.cloud
.
You need further requirements to be able to use this module,
see Requirements for details.
To use it in a playbook, specify: google.cloud.gcp_compute_node_template
.
Synopsis
Represents a NodeTemplate resource. Node templates specify properties for creating sole-tenant nodes, such as node type, vCPU and memory requirements, node affinity labels, and region.
Requirements
The below requirements are needed on the host that executes this module.
python >= 2.6
requests >= 2.18.4
google-auth >= 1.3.0
Parameters
Parameter |
Comments |
---|---|
An OAuth2 access token if credential type is accesstoken. |
|
The type of credential used. Choices:
|
|
CPU overcommit. Some valid choices include: “ENABLED”, “NONE” Default: |
|
An optional textual description of the resource. |
|
Specifies which Ansible environment you’re running this module within. This should not be set unless you know what you’re doing. This only alters the User Agent string for any API requests. |
|
Name of the resource. |
|
Labels to use for node affinity, which will be used in instance scheduling. |
|
Node type to use for nodes group that are created from this template. Only one of nodeTypeFlexibility and nodeType can be specified. |
|
Flexible properties for the desired node type. Node groups that use this node template will create nodes of a type that matches these properties. Only one of nodeTypeFlexibility and nodeType can be specified. |
|
Number of virtual CPUs to use. |
|
Physical memory available to the node, defined in MB. |
|
The Google Cloud Platform project to use. |
|
Region where nodes using the node template will be created . |
|
Array of scopes to be used |
|
The server binding policy for nodes using this template. Determines where the nodes should restart following a maintenance event. |
|
Type of server binding policy. If `RESTART_NODE_ON_ANY_SERVER`, nodes using this template will restart on any physical server following a maintenance event. If `RESTART_NODE_ON_MINIMAL_SERVER`, nodes using this template will restart on the same physical server following a maintenance event, instead of being live migrated to or restarted on a new physical server. This option may be useful if you are using software licenses tied to the underlying server characteristics such as physical sockets or cores, to avoid the need for additional licenses when maintenance occurs. However, VMs on such nodes will experience outages while maintenance is applied. Some valid choices include: “RESTART_NODE_ON_ANY_SERVER”, “RESTART_NODE_ON_MINIMAL_SERVERS” |
|
The contents of a Service Account JSON file, either in a dictionary or as a JSON string that represents it. |
|
An optional service account email address if machineaccount is selected and the user does not wish to use the default email. |
|
The path of a Service Account JSON file if serviceaccount is selected as type. |
|
Whether the given object should exist in GCP Choices:
|
Notes
Note
API Reference: https://cloud.google.com/compute/docs/reference/rest/v1/nodeTemplates
Sole-Tenant Nodes: https://cloud.google.com/compute/docs/nodes/
for authentication, you can set service_account_file using the
GCP_SERVICE_ACCOUNT_FILE
env variable.for authentication, you can set service_account_contents using the
GCP_SERVICE_ACCOUNT_CONTENTS
env variable.For authentication, you can set service_account_email using the
GCP_SERVICE_ACCOUNT_EMAIL
env variable.For authentication, you can set access_token using the
GCP_ACCESS_TOKEN
env variable.For authentication, you can set auth_kind using the
GCP_AUTH_KIND
env variable.For authentication, you can set scopes using the
GCP_SCOPES
env variable.Environment variables values will only be used if the playbook values are not set.
The service_account_email and service_account_file options are mutually exclusive.
Examples
- name: create a node template
google.cloud.gcp_compute_node_template:
name: test_object
region: us-central1
node_type: n1-node-96-624
project: test_project
auth_kind: serviceaccount
service_account_file: "/tmp/auth.pem"
state: present
Return Values
Common return values are documented here, the following are the fields unique to this module:
Key |
Description |
---|---|
CPU overcommit. Returned: success |
|
Creation timestamp in RFC3339 text format. Returned: success |
|
An optional textual description of the resource. Returned: success |
|
Name of the resource. Returned: success |
|
Labels to use for node affinity, which will be used in instance scheduling. Returned: success |
|
Node type to use for nodes group that are created from this template. Only one of nodeTypeFlexibility and nodeType can be specified. Returned: success |
|
Flexible properties for the desired node type. Node groups that use this node template will create nodes of a type that matches these properties. Only one of nodeTypeFlexibility and nodeType can be specified. Returned: success |
|
Number of virtual CPUs to use. Returned: success |
|
Use local SSD . Returned: success |
|
Physical memory available to the node, defined in MB. Returned: success |
|
Region where nodes using the node template will be created . Returned: success |
|
The server binding policy for nodes using this template. Determines where the nodes should restart following a maintenance event. Returned: success |
|
Type of server binding policy. If `RESTART_NODE_ON_ANY_SERVER`, nodes using this template will restart on any physical server following a maintenance event. If `RESTART_NODE_ON_MINIMAL_SERVER`, nodes using this template will restart on the same physical server following a maintenance event, instead of being live migrated to or restarted on a new physical server. This option may be useful if you are using software licenses tied to the underlying server characteristics such as physical sockets or cores, to avoid the need for additional licenses when maintenance occurs. However, VMs on such nodes will experience outages while maintenance is applied. Returned: success |