Develops Custom DevOps-Friendly Provider For Terraform Develops Custom DevOps-Friendly Provider For Terraform

May 17 2017 Clément Contini

This is a guest post by Clément Contini, Cloud System Administrator for is a HashiCorp technology partner and provides Canadian regional cloud infrastructure for companies who have data sovereignty requirements. works as a standalone IaaS platform, or can be part of a hybrid or multi-cloud solution.

The team has developed a purpose-built provider for HashiCorp Terraform, making it possible to automate infrastructure deployments on the platform. Terraform is one of the numerous open-source tools for infrastructure management available from HashiCorp. It provides a DevOps-friendly approach to deploying complex IaaS environments, enabling increased agility and flexibility, particularly when it involves re-use of existing deployment architectures. You can download the provider here:

Apache CloudStack serves as the underlying orchestration platform for While it has a generic Terraform provider (which we wrote about here), we knew we could provide more value for our users by developing our own. This custom provider is more aligned with the design of our platform and specific deployment options, meaning users can automate capabilities via their Terraform configuration. For example, we simplify the use of CloudStack projects, a parameter that otherwise needs to be provided repeatedly when using the generic CloudStack provider. As an additional benefit, a single user can have access to manage multiple environments in an organization via Terraform, using the same credentials, if permissions allow it.

Another aspect that the provider covers that cannot be done with the generic CloudStack provider is the ability to control the “management” layer using the “environment” resource. You can specify the details of the role-based access control for each user in the Terraform configuration and/or even create new environments.

Configuring a environment

Let’s take a look at a real configuration made for the provider, available in the following repository: This configuration will create an environment and a VPC with 3 networks. One network will be used for the front-end machines, one for the back-end machines and the last one for a utility machine.

All available variables are gathered in a file called “” and represent all the customization that can be applied on the configuration. Here is an excerpt of the file:

# Provider credentials variable "api_key" {}

» General variables

variable "is_production" {} variable "frontend_count" {} variable "backend_count" {}

» Environment

variable "service_code" {} variable "organization_code" {} variable "environment_name" {} variable "environment_description" { default = "Environment for %s workloads" } variable "admin" { type = "list" } variable "read_only" { type = "list" } variable "database_ports" { default = [ 3306 ] } variable "web_ports" { default = [ 80, 443 ] }

To begin to use this configuration, create a file “terraform.tfvars” with all the variables that don’t have a default in “”. This might be things such as API keys, a list of users the organization wants to add to the environment, a list of required attributes specified in a README file, or variables to override. An example of this might be if you want to open port 8080 instead of 80 and 443, just add this to “terraform.tfvars”

web_ports = [ 8080 ]

And to specify role accesses:

admin_role = [ "clement", "mike" ] read_only_role = [ ]

Now take a look at “”. It configures a “cloudca_environment” which takes a list of users in “admin_role” and “read_only_role”. These roles have to be specified in the “terraform.tfvars” file (no default is provided, you need to use the users from your own organization).

rule_number = "${10 + count.index + 1}" action = "Allow" protocol = "TCP" start_port = "${element(var.database_ports, count.index % length(var.database_ports))}"

end_port = "${element(var.database_ports, count.index % length(var.database_ports))}"

cidr = "${var.is_production ? "${element(cloudca_instance.web_instance.*.private_ip, count.index)}/32" : "" }"

traffic_type = "Ingress" network_acl_id = "${}" }

Depending if the environment is for production or not, the CIDR of the ACL will be different: open to for the development environment, extracted from the instances of the web network for production. The ports are also configurable and are selected from the list provided as variables.

Integration with platform tools

The Terraform provider directly leverages built-in features of the platform, such as the activity log. Any action performed while using the Terraform provider will show up in the activity view. If you deploy the example configuration, you will see the different actions as they are performed:

Example of activity log on

We are continuously improving and developing the Terraform provider. An upcoming near-term roadmap item will provide the ability to export a Terraform configuration from an existing environment. This way, if the environment had been built manually but the user wants to reproduce it easily (in terms of infrastructure layout), it would be possible to simply press a button, get the Terraform configuration, and use it to create a similar environment.

In conclusion, we think Terraform is an excellent tool to use with

  • It enables automation using powerful, open source software.

  • It enables semi-automatic scaling, in the sense that it becomes very easy to change the number of instances of the same type when your needs change, through simple adjustments in the resource definition, making horizontal scaling simple and fast.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now