Request access to Scalr IaCP

Workspace Management

Overview

A Scalr workspace is the object in which you can manage your Terraform deployments whether it originated from the service catalog, API, CLI, or VCS provider. Within a workspace you can do the following:

  • View the history and details of runs
  • View resources
  • Manage variables
  • Queue new runs
  • Destroy infrastructure
  • Edit existing workspace configuration

Each workspace will store the Terraform state and act as what would normally be a directory if you were running Terraform locally.

Creating a Workspace

A workspace can only be created through the UI for now, there are plans to make this available via the API/CLI. Workspaces only need to be created manually if you wish to use devops automation.

Workspaces for Devops automation are created through the workspace page by clicking new workspace:

../_images/new_workspace.png

Then link it to your VCS provider:

../_images/new_workspace2.png

Runs

Runs occur when you queue a new plan or execute changes on existing workspaces. Each time a run is executed it will create history about the run, which can be found by clicking on the name of the workspace, then the “runs” tab.

../_images/runs_main.png

To find out more information about each run, click on the “run id”. Each tab within the run can be clicked on to see more detail about the Terraform plan, cost estimate, policy, and apply:

Plan - Displays the Terraform plan that will be executed:

../_images/runs_detail.png

Cost Estimate - Displays the cost that will be incurred or the proposed cost difference if it is a change to existing state:

../_images/runs_cost.png

Policy Check - Displays the results of the OPA policy checks:

../_images/runs_policy.png

Apply - Displays the results and output of the apply:

../_images/runs_apply.png

Clicking on the “commit” ID will redirect you to the VCS provider to show the last change the occurred in the Terraform template.

Variables

If you are creating a workspace and integrating it with your existing CI/CD pipeline, you may prefer to store the variables directly in Scalr rather than the Terraform template to make the template more dynamic. To do this, reference the variables in your template:

variable "region" {}
variable "bucket_name" {}

Then add them to your workspace in the UI:

../_images/workspace_variables.png

Find out more about variables here.

Automated Deployment

Scalr workspaces can be bound to a VCS based repo branch [+ directory] so that the template that is being executed by Scalr is always from the latest commit. This binding is defined when a workspace is created and cannot be changed.

Under workspaces click new workspaces

../_images/new_ws_vcs.png

The effect of this binding is that every commit or merge to the linked repo and branch will trigger a full run. This run may deploy or re-deploy resources depending on the changes in the commit and the current state of the resources.

This automated run is achieved as follows.

When the workspace is created Scalr will create a webhook in the VCS to be fired back to Scalr whenever there is a commit in that repo. There is only one webhook per repo and Scalr will process each webhook request and determine if the commit applies to a branch that is linked to a workspace. If so the full run, i.e. terraform apply is triggered. If the plan, cost estimation and policy checks are successful the run will need to be approved in the UI, unless the “auto apply” toggle is set.

VCS Dry Runs

Linking a VCS branch to a workspace can also cause automated testing of a pull request to take place. These automated tests are known as “dry runs” and in the context of Scalr they include the plan, cost estimation and policy phases of a run. They never include the apply phase. The purpose of these tests is to provide some validation that the pull request can be merged into the target branch. These tests are triggered by the webhook and occur under the following circumstances.

  • When a pull request is made to a branch that is linked to a workspace
  • When a commit is done in a branch that is the source of an open pull request to a branch that is linked to a workspace.

Example:

  • I have a branch called “Dev” linked to a workspace
  • I create a new branch “New_feature” and commit a change
  • I make a pull request request from New_feature to Dev. A speculative run will be triggered.
  • I make another commit to “New_feauture” while the pull request is still open. Another speculative run will be triggered.

The dry runs can be observed in the VCS

../_images/vcs_dry_1.png

../_images/vcs_dry_2.png

The “details” link is a link to the run details inside Scalr. The run will be associated with the workspace that is linked to the target of the pull request but is only accessible from the VCS link. Dry runs do not appear on the run list for a workspace.