_images/login_button.png _images/signup_button.png



Self Service - Template Registry

Reading time: 5 minutes

Terraform configurations held in VCS repositories can be added to the Scalr Template Registry to provide self service deployment.

Users can make requests for infrastructure via dynamically created request forms based on the input variables in the configuration. Scalr automatically creates a workspace for the user and runs the configuration to deploy the infrastructure.

Input controls can be added to the Terraform configuration to constrain the values users can enter and to provide drop down based selections on the request form.

To use the template registry you must create a VCS provider if you have not already done so.

Note

Terraform configurations used in the registry can make use of Cloud Credentials to inject provider credentials into the workspaces.


Registering a Template

Template Registry is accessed at environment (blue) scope.

  • Go to “Template Registry”, and click on “Management”:

    _images/navigate_offering_mgmt.png
  • Click on “New Template” and enter the information for the VCS provider, branch and directory where the template is stored

  • Set “Track” as required

    _images/new_offering1.png
  • Click “Save & Fetch”. Scalr will now fetch the template metadata from the VCS provider and the status will go to “Active” within a few seconds.

  • The Template Registry form will automatically create, any Terraform variables will be presented as inputs in the form.


Template Registry Request

  • Go to “Template Registry”, and click on “Request”:

    _images/request.png

_images/offerings.png
  • Select an item, click “Request” and enter values for all required inputs and click “Deploy”.

    _images/new_sc_request.png
  • You will now be redirected to the workspace page where you can track the progress of the deployment.

    _images/workspace1.png

Input Controls

Input controls restrict the values a user can enter on the request form and provide drop down lists that simplify the request process.

Input controls are implemented using Scalr Policies and/or Global Variables. These are then mapped to the input variables in the configuration by adding an additional HCL file to the repository called scalr-module.hcl

Scalr Policies

Not to be confused with OPA policies, the Scalr policies are a library of pre-defined policies for the major cloud providers. These policies allow you to define custom lists of allowed values from the values offered by the cloud. This can cover things like

  • regions

  • instance_types

  • networks

  • subnets

Scalr policies can also be conditional allowing you to have different settings for different Cloud Credentials, regions etc. A full list, including available conditions, is provided in the Policy Reference.

Policies are created at account (green) scope within the “Policy Engine” section.

Example to create a group of AWS policies that limits the regions, instances types and more.

  • Click on “New Policy Group” and select “AWS” as the type:

    _images/new_policy.png
  • Create the above policies “New Policy” and save.

    _images/policy_created.png
  • Policy group must be linked to the environment. Click on “Environments”, “Policies”, then click on the green link on the right and save:

    _images/link_policy.png

Now “map” the policies to the input variables in the Terraform configuration. This is done in a new file in the repository called scalr-module.hcl.

  • For purposes of illustration we have a config with these input variables.

    variable "region" {}
    
    variable "subnet" {}
    
    variable "vpc_id" {}
    
  • Create or edit scalr-module.hcl and add the mappings with all the required conditions that match the policy

    version = "v1"
    
    # Bind region to a Policy that restricts to specific cloud locations.
    # This acts an automatic look-up. IaCP queries the cloud api to obtain the possible values
    variable "region" {
      policy = "cloud.locations"
      conditions = {
      cloud = "ec2"
      }
    }
    
    # Bind vpc_id to a networks policy. Note the policy is region specific so this works in any region
    variable "vpc_id" {
      policy = "cloud.networks"
      conditions = {
      cloud = "ec2",
      cloud.location = "${var.region}"
      }
    }
    
    variable "subnet" {
      policy = "cloud.subnets"
      conditions = {
      cloud = "ec2",
      cloud.location = "${var.region}",
      cloud.network = "${var.vpc_id}"
      }
    }
    
  • After committing this change to the repository Scalr will automatically re-sync the template registry. The request form will now show drop down fields with the lists defined in each policy.

    _images/tr_request_pol.png

Global Variables

Global variables additional capabilities to control inputs.

  • Manually created lists and maps

  • REGEX

  • printf based formats

Global variables can be create at any scope in Scalr via the Global Variables or GV menu.

This example creates a list and a map using variables called ssh_key and ami and assumes the Terraform config contains at least these two variables.

variable "key" {}

variable "ami" {}
  • Go to “Global Variables”, and “New Variable” of type “list”

  • Click on the gear icon to enter values and labels. For simple lists just enter a value and label as the same. For maps enter the value (passed to the configuration) and the label (what the user sees on the request form) as different values.

    _images/add_gv_ssh.png _images/add_gv_ami.png
  • Add entries to scalr-module.hcl to map the global variables to the input variables.

    variable "key" {
      global_variable = "ssh_key"
    }
    
    variable "ami" {
      global_variable = "ami"
    }
    

After setting up these bindings and committing the changes to the repo you can make a new template registry request and see how the request screen has changed. Note the drop down fields and the icons indicating policy and variable bindings.

_images/new_sc_request2.png

Policy Reference

Below is a list of possible cloud types with their aliases in the Scalr policy Engine.

  • ec2 - Amazon Web Services

  • gce - Google Cloud Platform

  • azure - Microsoft Azure

  • vmare - VMWare

All cloud-dependent policies require “cloud” conditions as seen below or in the example above.

Below is a list of the policy types which are supported by each cloud. The only differences are in conditions, where you have to specify cloud-dependent values (e.g., cloud, cloud.location, etc.).

Common Policies

Policy

Condition

Required

Condition value

Supported TF Variable types

cloud.instance.name.template (Sets a naming convention for instance names)

cloud.location

No

Cloud location identifier

string

os.type

No

One of: [linux, windows]

cloud.instance.types (Restricts instance types that can be used)

cloud.location

No

Cloud location identifier

string

os.type

No

One of: [linux, windows]

cloud.locations (Restricts locations that can be used on a cloud)

string

cloud.networks (Restricts networks (VPCs, VLANs) that can be used)

cloud.location

ec2, openstack, otc, rackspacengus - yes, azure, gce - absent

Cloud location identifier

string, list

cloud.storage.maximum_size (Sets a maximum size for storage in GB)

cloud.location

No

Cloud location identifier

number

cloud.subnets (Restricts subnets that can be used inside networks)

cloud.location

Yes

Cloud location identifier

string, list

cloud.network

Yes

Network identifier

resource.group (for azure only)

Yes

Resource group identifier

cloud.tags (Sets list of tags that will be applied to resources)

cloud.location

No

Cloud location identifier

map

os.type

No

One of: [linux, windows]

scalr-module.hcl example for a common policy type:

version = "v1"

variable "region" {
  policy = "cloud.locations"
  conditions = {
  cloud = "ec2"
  }
}

variable "vpc_id" {
  policy = "cloud.networks"
  conditions = {
    cloud = "ec2"
    cloud.location = "${var.region}"
  }
}

Amazon Web Services

Policy

Condition

Required

Condition value

Supported TF Variable types

aws.iam.instance_profiles (Restricts IAM instance profiles that can be applied to instances)

string, list

aws.iam.roles (Restricts IAM Roles that can be used)

cloud.location

Yes

string, list

cloud.service

Yes

One of: [emr, lambda, applicationAutoScaling]

aws.kms.keys (Restricts KMS keys available for storage encryption)

cloud.location

Yes

AWS cloud location identifier

string, list

cloud.service

No

One of: [ec2, rds, efs, lamda]

aws.rds.instance_types (Restricts Instance Types that can be used by RDS)

cloud.location

No

AWS cloud location identifier

string, list

aws.rds.db_engine

No

One of: [mysql, oracle-se, oracle-se1, oracle-se2, sqlserver-ee, sqlserver-se, sqlserver-ex, sqlserver-web, postgres, aurora, aurora-postgresql, mariadb]

cloud.resource.name.prefix (Sets a prefix for cloud resource names)

cloud.service

Yes

One of: [elb, rds, s3]

string

cloud.location

No

AWS cloud location identifier

cloud.security_groups (Sets or Restricts Security Groups that can be used)

cloud.location

No (Required with cloud.network)

AWS cloud location identifier

string, list

cloud.network

No

VPC identifier

cloud.service

No

One of: [ec2, rds, elb, alb, efs, lamda]

os.type

No

One of: [linux, windows]

cloud.storage.volume_types (Restricts volume types that can be used)

cloud.location

No

AWS cloud location identifier

string, list

scalr-module.hcl example for an AWS policy type:

version = "v1"

variable "region" {
 policy = "cloud.locations"
  conditions = {
   cloud = "ec2"
 }
}

variable "vpc_id" {
 policy = "cloud.networks"
  conditions = {
    cloud = "ec2"
    cloud.location = "${var.region}"
}
}

variable "subnet" {
 policy = "cloud.subnets"
  conditions = {
   cloud = "ec2",
    cloud.location = "${var.region}",
    cloud.network = "${var.vpc_id}"
 }
}

Microsoft Azure

Policy

Condition

Required

Condition value

Supported TF Variable types

azure.availability_sets (Restricts Availability Sets that can be used)

resource.group

Yes

Resource group identifier

string, list

azure.resource_groups (Restricts Resource Groups that can be used)

cloud.location

No

Region identifier

string, list

cloud.service

No

One of: [compute, network]

azure.storage_accounts (Restricts Storage Accounts that can be used)

string, list

cloud.security_groups (Sets or Restricts Security Groups that can be used)

cloud.location

No

Region identifier

string, list

cloud.network

No

Network identifier

resource.group

No (Yes if cloud.network specified)

Resource group identifier

scalr-module.hcl example for Azure:

version = "v1"

variable "region" {
  policy = "cloud.locations"
  conditions = {
  cloud = "azure"
  }
}

variable "resourcegroup" {
  policy = "azure.resource_groups"
  conditions = {
  cloud = "azure"
  }
}

Google Cloud Platform

Policy

Condition

Required

Condition value

Supported TF Variable types

gce.custom_instance_type.maximum_ram (Sets a maximum size for custom instance types in GB)

cloud.location

No

GCP region identifier

number

gce.custom_instance_type.maximum_vcpus (Sets a maximum number of VCPUs for custom instance types)

cloud.location

No

GCP region identifier

number

gce.network_tags (Sets or Restricts Network Tags that can be used)

cloud.location

No

GCP region identifier

list

gce.service_accounts (Restricts service accounts that can be applied to instances)

string, list

VMWare

Policy

Condition

Required

Condition value

Supported TF Variable types

vmware.compute_resources (Restricts Compute Resources that can be used)

cloud.location

Yes

Datacenter identifier

string

vmware.custom_instance_type.maximum_cpu (Sets a maximum number of VCPUs for custom instance types)

cloud.location

No

Datacenter identifier

number

vmware.custom_instance_type.maximum_ram (Sets a maximum size for custom instance types in GB)

cloud.location

No

Datacenter identifier

number

vmware.custom_specs (Restricts customization specs can be used)

cloud.location

No

Datacenter identifier

string

cloud.compute_resource

No

Compute resource identifier

vmware.host_systems (Restricts Hosts that can be used)

cloud.location

Yes

Datacenter identifier

string

cloud.compute_resource

Yes

Compute resource identifier

vmware.resource_pools (Restricts Resources pools that can be used)

cloud.location

Yes

Datacenter identifier

string

cloud.compute_resource

Yes

Compute resource identifier

vmware.storage.placements (Restricts datastores and storage pods can be used)

cloud.location

Yes

Datacenter identifier

string