Manoeuvring IBM Cloud with Terraform

5 min readOct 27, 2017

The Problem

So you have been provisioning your infrastructure on IBM Cloud ranging from IaaS layer resources like bare metals, load balancers , VLANs to the PaaS layer resources like Watson services, container cluster service and the like. You are up-to-date with latest patterns and best practices around DevOps and already know the importance of IaC. Hence you built your own customized solutions which probably use some scripting and makes use of the rich APIs that IBM Cloud offers to make a highly flexible workflow.

You have codified your infrastructure and put it on github. Well done !!. You probably have a smug look on your face too. There are few issues however which are continuously nagging you about your custom probably bash-ish solution. Maintenance of such solutions becomes a pain in the ass. You have deadlines to meet owing to ever growing customer base and these issues are put aside; slips down the priority list only to surface back as a technical debt. Your solution can’t scale well. Managing and extending the solution is a nightmare. Sure you like IBM Cloud but you foresee yourself talking to different cloud providers to best satisfy your customers needs. You write more customized solution each targeting different clouds. You have little to no idea how your infrastructure looks at a particular time and why it looks the way it does. You are not confident about the changes you make to your script while you roll out those to the production. You are lost in this dystopia and working hard to find a solution. Luckily the problem you have is not uncommon. It plagues most of us. Hashicorp started the open-source Terraform project to target this specific problem of creating and managing the life cycle of your infrastructure in a more innovative way that would solve the aforementioned problems. You would probably enjoy the cloud better riding on this solution as opposed to the one which you built yourself.

The Solution

I know there are more than one solution but I like to call it “the solution” as it was designed to solve the specific problem from the outset and does it remarkably well. It has its own share of problems and limitations but that is the topic of another article.

You can find many good tutorials on Terraform. My focus here is on its usage for IBM Cloud, so I will briefly explain what it is and assume you already know basics of Terraform. Exhaustive documentation can be found here. The Terraform provider to interact with IBM Cloud is open sourced here with a documentation of the latest release.
Put simply, Terraform is a binary that you invoke from command line to create and manage your infrastructure. If I want to create a virtual server on IBM Cloud, I would create a file say vm.tf. You can call it anything, just end with .tf with the following content.

Let us say you put in a directory called ibmcloud-config. I will refer to this directory later.
Terraform can understand HCL (Hashicorp language) or JSON configuration files. Above is an example of HCL which is DSL-like. One of the end goals of a DSL is to keep it easy on your brain and eyes. One can easily guess from above configuration what it might be do. It will create a VSI with OS Debian 7 64 bit, assign host name my-vm-on-ibm-cloud, domain mycompany.com in Washington data center. You can read more about the fields in the provider documentation.

The Manoeuvring

Using the free manoeuvring service

IBM Cloud Schematics is IBM’s Terraform as a Service offering.

Put simply, it will take care of running plan and apply on IBM containers and manage the ever so important state file for you. You only need to put your code in github.com or GHE.
You can use the intuitive UI to navigate through it. You can also use IBM Bluemix CLI plugin called schematics if you want to automate the solution via command line tooling. Of course there is API too. You might get alarmed at using API again and creating your custom solution. There is no need to as this custom solution would mean that you are delegating all the burden to the battle-tested Terraform provider to do the job and not write your own lower level APIs.

So use this free service. You get charged only for the actual resources you create on IBM Cloud.

Building solution from the source

Preparation

Download the Terraform binary zip. Unzip it and keep the binary in path ex- /usr/local/bin.
Download the IBM Cloud provider binary zip. Unzip it and keep the binary in path in the same directory where you placed Terraform binary in previous step. You can also build the binary yourself. Please look into documentation.
Go to ibmcloud-config, the directory where you have vm.tf and issue the following commands (assuming a *nix). Give proper values for sl_username and sl_api_key

$ cd ibmcloud-config
$ export SL_USERNAME=sl_username
$ export SL_API_KEY=sl_api_key

Time to roll

Issue terraform plan to see what will happen to your current infrastructure.

$ terraform plan

Output is self explanatory. You should read to see what will happen to your infrastructure. If there are any invalid syntax or invalid input they will likely be reported here.

Issue terraform apply to carry out the execution and create the VSI

$ terraform apply

It takes roughly 3–4 minutes for the VSI to provision. Once it is complete
issue terraform show.

$ terraform show

It will list all the details about the VSI like ip address, vlan ids etc. Recall that you never specified this in the configuration. These attributes are computed and read from the IBM Cloud and are made available by the provider for you to use them. For example - you may use the ip address to configure the firewall etc. Not surprisingly the provider supports creating firewall policies as well.

Let’s bump up the memory to 2048. Edit the vm.tf file and replace 1024 with 2048 in the config file like so, memory = 2048.

Issue terraform plan. It should give a diff like output telling memory will be changed from 1024 to 2048. Issue terraform apply. The update operation kicks off and memory is updated to 2048 MB. Verify it using any means you want. Just for fun try changing memory to 2058 and see what happens.

You might have spun this VSI to do some testing. Now you don’t want it anymore and want to cancel it to stop incurring any costs on keeping it alive. Issue terraform destroy and you are done.

$ terraform destroy

If someone makes changes to your infrastructure outside Terraform say using using SoftLayer portal or otherwise, Terraform will detect that
and tell you so. That is why it is imperative that you don’t skip the output of terraform plan and read it carefully to know how your resource will change on terraform apply.

Conclusion

Terraform provides a better way to interact with IBM Cloud. If you want to quickly see what it is capable of then try IBM Cloud Schematics. I would be more than happy to answer your queries and guide you through its usage. Although I focused on the IBM Cloud, as of today the Schematics service can help you provision resources across different cloud providers (essentially all the providers that Terraform supports)so you can mix and match and use the best.