Actions
Overview¶
The Actions feature enables users to perform specific tasks on their environments once they are provisioned. Admins can configure a set of actions, such as scaling node pools, adding new node pools, or modifying virtual machine settings, directly within the Environment or Resource Template. This feature simplifies the execution of key tasks, allowing users to focus on individual actions without having to navigate complex environment configurations.
This feature is useful as it centralizes essential tasks, making it easier for users to manage and modify their environments. It supports input validation through JSON schema, ensuring that users provide the correct data when triggering actions. Actions can also be audited, capturing details of each task for accountability and tracking. By streamlining these workflows and making them more user-friendly, the Actions feature enhances efficiency and helps maintain control over the environment management process.
This functionality is supported exclusively through RCTL CLI and API, allowing users to leverage automation and integrate with existing systems seamlessly. These interfaces provide flexibility and ensure that actions can be managed for consistent and scalable operations.
Deploy Actions Using the RCTL¶
To create actions using the RCTL, follow the steps outlined below. An example specification for each step is provided to ensure clarity and ease of implementation.
⚠️ Important Note
Actions can only be configured in environment or resource templates, and these actions can be associated with an environment usingrctl, but they cannot be executed directly. For action execution, users must use only the API endpoints.
Step 1: Create Config Context¶
In the context of configuring actions, the ConfigContext specification requires the inclusion of jsonschema and uischema elements. These elements are necessary for validating input data and for customizing the UI interface for users. The jsonschema defines the structure and validation rules for the configuration, while the uischema specifies how the configuration options should be presented to the user. This feature heavily relies on the react-jsonschema library.
✅ Recommendation
Admins can use any open-source playground that utilizes this library to build thejsonschemaanduischemafor configuring actions (e.g., React JSON Schema Form).
apiVersion: eaas.envmgmt.io/v1
kind: ConfigContext
metadata:
name: gcp-node-pool-configuration
project: templates
spec:
envs:
- key: node_pools
value: |-
[
{
"auto_repair": true,
"auto_upgrade": true,
"disk_size_gb": 100,
"machine_type": "e2-medium",
"name": "inception-node-pool"
}
]
options:
override:
type: allowed
schema:
jsonschema:
dependencies: {}
description: A node pool is a template for groups of nodes created in this cluster. The new cluster will be created with at least one node pool. More node pools can be added and removed.
properties:
node_pools:
description: Node Pool Configuration
items:
dependencies: {}
description: These node settings will be used when new nodes are created using this node pool.
properties:
auto_repair:
enum:
- "false"
- "true"
title: Auto Repair
type: string
auto_upgrade:
enum:
- "false"
- "true"
title: Auto Upgrade
type: string
disk_size_gb:
default: 100
title: Disk Size ( GB )
type: integer
machine_type:
enum:
- e2-medium
- n2-standard-4
- n2-standard-8
title: Google Compute Engine machine type
type: string
name:
default: default-nodepool
description: The name of the node pool
title: Name of the node pool
type: string
required:
- name
- disk_size_gb
title: Node Pool Configuration
type: object
title: Node Pools
type: array
required: []
title: Node Pools
type: object
uischema:
node_pools:
items:
auto_repair:
ui:widget: radio
auto_upgrade:
ui:widget: radio
enable_gcfs:
ui:widget: radio
enable_gvnic:
ui:widget: radio
ui:order:
- auto_repair
- auto_upgrade
- disk_size_gb
- machine_type
- name
ui:order:
- node_pools
Use the command ./rctl apply -f <demo-context.yaml> to create a config context.
Step 2: Environment Template¶
Once the Config Context is defined and actions are configured, the next step is to incorporate this context into the Environment Template or Resource Template. The configuration below demonstrates how to include the previously defined gcp-node-pool-configuration context under the actions section of an Environment Template.
apiVersion: eaas.envmgmt.io/v1
kind: EnvironmentTemplate
metadata:
name: gke-cluster-et
description: Environment Template for GKE Cluster Resources
project: templates
spec:
version: v1-rt-et
resources:
- type: dynamic
kind: resourcetemplate
name: gke-cluster-rt
resourceOptions:
version: v1-rctl
versionState: active
actions:
- name: node-pool
description: Add or Remove Node Pools
type: deploy
context:
name: gcp-node-pool-configuration
Use the command ./rctl apply -f <environment-template.yaml> to create an Environment Template.
In-line Configuration¶
The following is an example of an in-line Config Context configuration within a ResourceTemplate. This configuration integrates the necessary context and actions, which can be used directly for managing resources such as adding a node pool to a GKE cluster.
In this template, the action add-node-pool is configured to deploy a new node pool with specific parameters, such as disk size, machine type, and auto-repair settings. The data section of the action contains the node_pools configuration, along with a schema for validation and a UI schema for user-friendly interaction.
apiVersion: eaas.envmgmt.io/v1
kind: ResourceTemplate
metadata:
name: gke-np-template
description: 'GKE with node pool template '
project: defaultproject
spec:
version: v1
provider: terraform
providerOptions:
terraform:
backendType: system
repositoryOptions:
name: demo-terraform
branch: main
directoryPath: "/gcp/examples/standard-gke"
contexts:
- name: demo-gcp-configuration
variables:
- name: var_1
valueType: text
value: default-name
options:
description: Cluster Name
required: true
override:
type: allowed
- name: var_2
valueType: text
value: default-nodepool
options:
description: name of a node pool
required: true
override:
type: allowed
- name: var_3
valueType: text
value: paralus-352615
options:
description: Project ID
required: true
override:
type: notallowed
agents:
- name: envmgr-agent-may
versionState: draft
actions:
- name: add-node-pool
description: this action is used to add node pool to cluster
type: deploy
context:
data:
variables:
- name: node_pools
valueType: json
value: |-
[
{
"auto_repair": true,
"auto_upgrade": true,
"disk_size_gb": 100,
"machine_type": "e2-medium",
"name": "inception-node-pool"
}
]
options:
description: Node Pool Configurations
required: true
override:
type: allowed
schema:
jsonschema:
dependencies: {}
description: A node pool is a template for groups of nodes created
in this cluster. The new cluster will be created with at least one
node pool. More node pools can be added and removed after cluster
creation
properties:
node_pools:
description: Node Pool Configuration
items:
dependencies: {}
description: These node settings will be used when new nodes
are created using this node pool.
properties:
auto_repair:
enum:
- 'false'
- 'true'
title: Auto Repair
type: string
auto_upgrade:
enum:
- 'false'
- 'true'
title: Auto Upgrade
type: string
disk_size_gb:
default: 100
title: Disk Size ( GB )
type: integer
machine_type:
enum:
- e2-medium
- n2-standard-4
- n2-standard-8
title: Google Compute Engine machine type
type: string
name:
default: default-nodepool
description: The name of the node pool
title: Name of the node pool
type: string
required:
- name
- machine_type
title: Node Pool Configuration
type: object
title: Node Pools
type: array
required: []
title: Node Pools
type: object
uischema:
node_pools:
items:
auto_repair:
ui:widget: radio
auto_upgrade:
ui:widget: radio
enable_gcfs:
ui:widget: radio
enable_gvnic:
ui:widget: radio
ui:order:
- name
- auto_repair
- auto_upgrade
- disk_size_gb
- machine_type
ui:order:
- node_pools
Use the command ./rctl apply -f <resource-template.yaml> to create an Environment Template.
Step 3: Environment¶
Once the templates are created with the necessary actions, these actions can be associated with the environment using the Environment configuration. Below is an example of how to specify the environment configuration for deploying a template, such as the gke-cluster-et:
apiVersion: eaas.envmgmt.io/v1
kind: Environment
metadata:
description: This is a production environment for GKE with node pool management
name: gke-cluster-prod-env
project: defaultproject
spec:
template:
name: gke-cluster-et
version: v1
Use the command ./rctl apply -f <environment.yaml> to create an Environment.
Step 4: Execute Actions¶
Once the actions are associated with the environment, users can deploy the actions via APIs. Use the API endpoint below to execute the actions associated with the Environment through the Resource Template or Environment Template.
/apis/eaas.envmgmt.io/v1/projects/{project}/environments/{name}/action/{action}
Limitation: Variable Compatibility Across Configurations¶
When defining variables for deployment, it is essential to ensure that the structure and attributes of variables match across systems or platforms. This includes maintaining consistency in variable names, types, and nested properties to avoid mismatches or errors during configuration or execution.
General Guideline
- Variables defined in the deployment system (e.g., Environment Manager) must align with the variable specifications in underlying modules or templates (e.g., Terraform modules).
- Complex variables, such as objects with nested properties, should replicate the full structure and data type to ensure compatibility and proper execution.
- Ensure naming conventions are consistent across platforms for seamless integration. This approach ensures that configurations work as intended, reducing errors and enhancing reliability in deployments.
Audit Log¶
All actions performed on the Config Context, Environment Template, Resource Template, and Environment for action associations are tracked in the Audit Log page. Below is an example showing the successful environment action.
