Software Deployment Today

Lots of choices: shell scripts, chef, puppet, ansible, salt, mesos...
Indefinitely customizable and configurable, but can take lots of time.
Error handling is not easy.
Configuration is not easy to automate, especially with the growing number of APIs from cloud providers.

Deployment is still a pain for many organizations.

Terraform

My current project has ambitious goals for deployment: fully automated, fast, easily configurable.
We're been testing terraform for a few months. The results are quite positive.
Let's start with an example: I want an nginx on Digital Ocean.

variable "do_token" { default = "12e7ff309c07e9e8aee91e81214d4dfa653182a3e65c21d0df12c27b9b01a07f" }
variable "do_ssh_key" { default = "1200719" }

provider "digitalocean" { token = "${var.do_token}" }
resource "digitalocean_droplet" "meetup_nginx" {
    name = "nginx"
    image = "debian-8-x64"
    region = "fra1"
    size = "1gb"
    private_networking = "true"
    ssh_keys = ["${var.do_ssh_key}"]
    connection { key_file = "id_robot" }

    provisioner "remote-exec" {
        inline = [
            "apt-get update",
            "apt-get install -qy nginx"
        ]
    }
}
output "nginx_ip" { value = "${digitalocean_droplet.meetup_nginx.ipv4_address}" }

Terraform Main Concepts

- Resource: something created by providers. Can be physical (VM, IP address) or logical (generated configuration file).
- Providers: creators of resources. Many providers are supplied by default such as VMWare, Amazon, Google, Azure, DigitalOcean, OpenStack.
- Provisioners: modifiers of resources such as command execution and file upload.

The resource graph

The resources must form a directed acyclic graph, meaning there is a start and end point for every path.
Terraform plans its execution based on this graph. Parallel paths can be executed together.

How does it work?

terraform apply reads all the *.tf files in the current directory. File ordering is not important.
It then constructs the graph of the resources and executes the providers/provisioners following this graph.
In case of error during the execution of a path, the resource is marked as tainted and the path is abandonned for the current run.
Subsequent terraform apply will pick up on the failed path(s) and try them again.
The deployment state is stored in .tfstate files. Don't lose them!

Other commands

terraform plan to get an idea of how terraform will execute your deployment.
terraform graph to get a GraphViz data of the plan.
terraform show to get the current state of the deployment.
terraform destroy to remove all the created resources.

Why we like Terraform

- Deployment script becomes simple (more configuration than scripting) and flexible (cloud deployment is a breeze).
- The language is surprisingly simple but allows good composability.
- Deployment plan becomes obvious.
- Redimensioning your existing infrastructure is easy.
- Terraform is a part of a coherent ecosystem from Hashicorp that goes beyond deployment.

Consul: cluster orchestration

- At its core, Consul is a Chubby type "lock service" (or config store).
- Similar to ZooKeeper, etcd, with some notable additions.
- Built-in cluster orchestration and monitoring.
- Built-in DNS server for service discovery.

Packer: automated VM construction

- Argument the capability of terraform by providing premade VMs ready for deployment.
- Able to build VMs for a large number of cloud providers.

The Hashicorp ecosystem

- Excellent domain model, built by people who understand DevOps.
- Unix philophophy: do one thing and one thing well.
- Still not matured (pre-beta) but already show great promises.
- Give it a try if you can, it might change the way you view DevOps.

Terraform and the Hashicorp ecosystem