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”:
Click on “New Template” and enter the information for the VCS provider, branch and directory where the template is stored
Set “Track” as required
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”:

Select an item, click “Request” and enter values for all required inputs and click “Deploy”.
You will now be redirected to the workspace page where you can track the progress of the deployment.

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:
Create the above policies “New Policy” and save.
Policy group must be linked to the environment. Click on “Environments”, “Policies”, then click on the green link on the right and save:

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.

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.

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.

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]	string
cloud.instance.types (Restricts instance types that can be used)	cloud.location	No	Cloud location identifier	string
	os.type	No	One of: [linux, windows]	string
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]	map

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
aws.iam.roles (Restricts IAM Roles that can be used)	cloud.service	Yes	One of: [emr, lambda, applicationAutoScaling]	string, list
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]	string, list
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]	string, list
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	string
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]	string, list
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	string
vmware.host_systems (Restricts Hosts that can be used)	cloud.location	Yes	Datacenter identifier	string
	cloud.compute_resource	Yes	Compute resource identifier	string
vmware.resource_pools (Restricts Resources pools that can be used)	cloud.location	Yes	Datacenter identifier	string
	cloud.compute_resource	Yes	Compute resource identifier	string
vmware.storage.placements (Restricts datastores and storage pods can be used)	cloud.location	Yes	Datacenter identifier	string