Hashicorp products are definitely rising in popularity, and with good reason. I recently interviewed Dave McJannet, CEO of Hashcorp, and talked about the overall Hashicorp ecosystem.

I’ve used Vagrant to deploy to Digital Ocean in the past, which is helpful, but my bet is that you’ll love Terraform even more due to its simplicity and portability.

First you need to download Terraform from the website. Choose the version based on your operating system. I’m using OSX in my example, so it will be the same as the Linux version for file locations.

Move the Terraform file into /usr/local/bin or into an area which is specified in your PATH environment variable. For Windows folks, you can create a folder and add it to the path.

Create a Digital Ocean read/write API key for Terraform to use by going to your Digital Ocean web console under the API section:

Create a read/write key so that we can manage the Digital Ocean environment fully using Terraform:

Take note of the key somewhere and store it in a password vault for safety. Once you leave the page, the key will never be shown again:

Set the API key in a local environment variable so that you can access it with Terraform. Terraform variables are prepended by TF_VAR_ which makes them easy to spot. If we refer to a variable called digitalocean_token inside Terraform, we need to name it TF_VAR_digitalocean_token using the EXPORT command:

We use environment variables in order to align more closely to the practices of a 12 Factor app. You’ll see a lot of the content over the next few blogs that show how Terraform and other products we use are enabling this methodology.

Create your provider file for Digital Ocean as a provider.tf file:

variable "digitalocean_token" {}

provider "digitalocean" {
    token = "${var.digitalocean_token}"
}

We want to create a server called webserver in the NYC2 region, so let’s create a Terraform file (ends with the .tf extension) to do that for us. This one will be called web-nyc2.tf:

resource "digitalocean_droplet" "web" {
    image = "ubuntu-14-04-x64"
    name = "webserver"
    region = "nyc2"
    size = "512mb"
}

Check our code using the terraform validate

This is one of those “no news is good news” output results. If you don’t see anything, the validation was successful.

Next, we show the planned results of our Terraform script using the terraform plan command:

You will see some information on the screen about using a -out parameter. This is another feature of the plan directive for capturing a point-in-time view of the environment and keeping a persistent version on disk or in memory. For now, let’s move on to the launch stage.

It’s time to launch our Terraform deployment using the terraform apply command:

We confirm the completion by taking a look at our Digital Ocean console and there is the web server droplet that our Terraform apply command launched:

The terraform show command will give us the status of our environment:

One more thing before we take down the instance is to run the terraform plan command to show

When you’re done, just run terraform destroy from the same folder and the resources will be removed.  You will be asked to type the word “yes” in the command to confirm:

Once confirmed, the removal proceeds based on the current state of the Terraform build:

That is our first and very simple example of using Terraform. Our next blog will feature a more complex build in conjunction with some other configuration using the same Digital Ocean provider. We can use a few more parameters to define things such as SSH keys, and much more. The plan directive will also be used to modify the environment to illustrate managing the state using our Terraform code.

Take note of the files in folder and you will also see there there is a terraform.tfstate file and a terraform.tfstate.backup file. These maintain a copy of the state of our Terraform environment and will also come into play as we dive in further with the Terraform goodness.