Introduction

Reading time: 2-3 minutes

Scalr IaCP is a tool that enables users and teams to collaborate on developing and managing infrastructure with Terraform. It provides centralized run time environments for Terraform and includes the following features to enable collaboration and use of Terraform at scale.

• Centralized storage of state files with automatic locking and easy state sharing

  • No need to build a state locking mechanism

• VCS integration to provide automated PR checks and deployments

• Enhanced remote backend for the Terraform CLI and API

• Automated policies applied to terraform run output to implement governance

• Role based access control for Scalr and Terraform functionality

• Built in secrets storage

• Module registry

• Template registry for a self service capability

How to use Scalr

This section briefly describes the 2 main ways to use Scalr. It also explains how to migrate to Scalr and how to navigate the Scalr UI. Please read the UI section before using Scalr.

CLI Remote Backend

• Add a remote backend to a Terraform configuration

• Workspace created in Scalr by terraform init

• All runs executed inside Scalr workspace with policy and RBAC applied

terraform {
  backend "remote" {
    hostname = "my-account.scalr.io"
    organization = "<organization-name of environment>"
    workspaces {
      name = "<workspace-name>"
    }
  }
}

VCS Integration

• Link workspaces to a VCS based repository containing a Terraform configuration

• PR checks will automatically include a dry run (plan and policy check)

• Commits/merges automatically trigger a full run

  

Create a VCS provider.

Migrating to Scalr

Existing state can easily migrated to Scalr using the terraform CLI. All that is required is to set the backend configuration to point to Scalr and terraform init will automatically migrate the state. This works for state stored locally and for state stored in other backends such as Terraform Cloud/Enterprise, S3, Consul.

• To migrate from locally stored state add a backend config similar to the one shown below.

• To migrate from an existing remote backed just change the backend configuration to point to Scalr.

terraform {
  backend "remote" {
    hostname = "my-account.scalr.io"
    organization = "<organization-name of environment>"
    workspaces {
      name = "<workspace-name>"
    }
  }
}

• Run terraform init

For a detailed description of migration please see Migrating to Scalr.

Workspaces

Scalr workspaces can be configured for VCS integration or CLI driven runs. Within a workspace the following features are available.

• Configure Terraform version, auto apply and workspace tags. (VCS Example)

• Lock the workspace state to prevent runs.

• Configure Terraform and shell variables. (CLI Example)

• View current and historical state files. (Example state after migration)

• Queue new runs.

• Configure webhooks.

Runs (Container Image Info)

Terraform runs occur within a Docker container that is running on the Scalr infrastructure. The container is based on standard Alpine Linux and has the tools below installed already. If you need to execute runs outside of the Scalr infrastructure, you can do this through Self Hosted Agent Pools.

• AWS CLI

• Azure CLI

• Google Cloud CLI

Follow these instructions to authenticate with each tool:

AWS:

Nothing is needed as the AWS CLI can read the $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY shell variables that Scalr passes.

Azure:

az login --service-principal -u $ARM_CLIENT_ID -p $ARM_CLIENT_SECRET --tenant $ARM_TENANT_ID
az account set --subscription=$ARM_SUBSCRIPTION_ID

Google:

echo $GOOGLE_CREDENTIALS > key.json
gcloud auth activate-service-account --key-file=key.json > /dev/null 2>&1
rm -f key.json
gcloud config set project $GOOGLE_PROJECT > /dev/null 2>&1

The Scalr UI

Scalr has up to three functional areas denoted by the color of the menu bar.

• Global (Orange) - Only available to self-hosted customers. Scalr operational admins manage Scalr here. Most users wont have access. Only one of these.

  

• Account (Green) - Admin of users, teams, policy, IAM, cloud credentials (secrets) and environments. There can be as many “Accounts” as required by an organization.

  

• Environment (Blue) - Each account can have multiple environments. This is where the work gets done. Environments are analogous to Terraform Organizations. Each environment typically contains a logically grouped set of workspaces.

  

Menu Button

This button gives access to all functionality in the area.

Switching Accounts/Environments

Top right of the menu bar is the “Switcher”. Click on this to switch to an environment or navigate to the account. There is also a “Manage Account” option on the environment menu.