CloudShare supports using custom Terraform scripts to enable tight functional integration with external clouds.
A Terraform script defines each end-user environment upon spin-up, providing a way to configure all of the desired cloud services.
For example, when integrating the Google Cloud Platform (GCP), you can create instances of GCP VMs or Cloud SQL, define a Kubernetes container, and more.
When you use a Terraform script, it is read dynamically whenever the associated environment's snapshot is used. This means that any changes made to the script will be reflected each time the snapshot is used.
Note: The ability to work with Terraform scripts in CloudShare depends on whether a user's assigned role has sufficient permissions.
Viewing the Creation Scripts List
From the External Resources menu, click Creation Scripts. The Creation Scripts page opens with all creation scripts currently defined for the account:
- Search and Filter - Enables you to dynamically search and filter the contents of the Creation Scripts page by Project and External Cloud fields.
- Scripts Details - A high-level matrix of details for each Terraform script.
- Navigation Buttons - Enables you to select the total number of rows displayed per page, as well as the page to display.
- Export Buttons - Enables you to export the contents of the Creation Scripts page as a CSV file.
Viewing and Editing Details for a Selected Script
From the Name column on the Creation Scripts page, click the name of the script that you want to view or edit. The Creation Script editor page opens for the selected Terraform script:
The left column of the editor page provides high-level Script Details for the selected script. The right column of the editor page displays the Script Content. To edit details or change the script, click the Edit icon located at the top of the desired column.
If you make any changes to the script, click Validate Script at the bottom of the editor to perform basic syntax validation. Should the validation fail, the editor will provide some information about the failure.
When you are finished editing, click Submit to update the selected script for the account.
The Terraform script syntax will then be validated. Should validation fail, information about the failure is displayed on its editor page, and the failed script will be marked as Invalid in the Creation Scripts List.
Copying a Selected Script
You can make an identical copy of a specific script and use that as a starting point for a new script.
Open the script you want to copy in the Creation Scripts editor page, and from the top menu, click Copy Script. A pop-up dialog will be displayed. After you confirm the copy request, a duplicate script with the word Copy appended to its name will be created and displayed in the Creation Scripts list. You can then open and edit the new copy as needed.
Alternatively, you can click the Copy icon located at the top of the Script Content column to copy the script to your local clipboard.
Deleting a Selected Script
To delete a specific script, open it in the Creation Scripts editor page and click Delete Script. Upon your confirmation, the selected script will be deleted.
Working with Azure Resource Groups in a Script
When you assign a reference to your resource group name in a script that is intended for Microsoft Azure, you must use the CloudShare data.azurerm_resource_group.main.name variable in order for the script to execute properly:
If you do not use this variable in your assignment, CloudShare will be unable to access the Azure resource group when the external cloud is created, resulting in a script execution error.
An Azure script can only make reference and use a single resource group in a given environment.
Working with Kubernetes
CloudShare fully supports working with Kubernetes frameworks.
When you create a Kubernetes cluster on the Google Cloud Platform (GCP), be aware that certain cluster configurations will limit CloudShare's ability to suspend that cluster in your environment, leaving the resource active. For example, your Google Kubernetes configuration may cause the error “The total number of nodes in this cluster (now 0) must be at least 3”, as it does not allow fewer than three nodes to be available for use at any time.
Using such a minimum configuration requirement prevents CloudShare from suspending the node cluster together with the rest of its environment (either manually or via the auto-suspend feature).
To remedy this, ensure that the number of available Kubernetes nodes can be reduced to 0 on GCP. Doing so will enable CloudShare to suspend the cluster in the related environment.
For more information, refer to the Google Kubernetes documentation at: Cluster Administration Overview.
Working with AWS
CloudShare supports the following Amazon Elastic Compute Cloud (EC2) scripting options:
- Custom Display Name in Viewer. To automatically assign a custom name to an EC2 instance at the time of creation, add a tag with the key Name (or name) together with the desired Display Name as its value. CloudShare will use this for the associated VM Tab in the Viewer. When no custom Display Name is provided, CloudShare displays a unique name that includes both the current EC2 image and instance IDs.
-
Remote Access. To enable the user remote access to the VM (Linux) or password reset privileges (Windows), add a key pair named cs-key to the desired instance. For example:
If you do not use this key pair in your VM, CloudShare will be unable to provide external access from the Viewer to that VM. - Linux User Name. By default, CloudShare assigns ec2-user as the Linux User Name. To automatically define a custom User Name for a Linux VM at the time of creation, add a tag with the key ci-key-username together with the desired User Name as its value (see the example image above.) CloudShare will use this for the associated VM login instead of the default User Name. For more details on connecting with AWS server instances, click here.
CloudShare also supports use of your own AWS account when creating external resources. For additional information, contact CloudShare Support.
Using Metadata Variables
To make it easier to pass runtime information in your scripts, CloudShare supports use of the following special metadata variables:
- CS_Owner_Email - Stores the email of the CloudShare account owner.
- CS_Env_Id - Stores the ID of the current CloudShare Environment.
To include these variables in your script, declare and use them as needed:
For additional information about using metadata variables in scripts, contact CloudShare Support.