La Hashiconf a eu lieu récemment online, l’occasion d’annoncer plusieurs nouveautés intéressantes, notamment la prochaine version de Terraform version 0.13 ( en attendant le lancement de la version 1.0).

Terraform 0.13

Modules, modules, modules !

Terraform 0.13 est encore en version beta, et n’est pas recommandé pour la production. Quand on voit les bugs remontés, il vaut mieux éviter de monter votre state en version 0.13 ;).

La mise à jour de terraform 0.12 à la version 0.13 devrait être moins douloureuse que la montée depuis la version 0.11.

La version 0.13 va surtout concerner des changements autour des modules. Il va être possible d’utiliser count, for_each et depends_on. Actuellement, il faut utiliser un hack en passant une liste au module comme une variable classique, pour ensuite faire for_each sur chaque ressource ce qui est loin d'être pratique.

module "mig" {
  source            = "GoogleCloudPlatform/managed-instance-group/google"
  version           = "1.1.14"
  zone              = each.value
  name              = each.key
  size              = 2
  service_port      = 80
  service_port_name = "http"
  http_health_check = false
  target_pools      = ["${module.gce-lb-fr.target_pool}"]
  target_tags       = ["allow-service1"]
  ssh_source_ranges = ["0.0.0.0/0"]
  for_each          = {
                        mig1 = "europe-west-1b",
                        mig2 = "europe-west-1c",
                      }
}

Le depends_on arrive également sur les modules, moins attendu que for_each et count, il était déjà possible d'avoir une dépendance implicite à travers les variables. Mais dans certains cas, il pouvait être complexe de déclarer une dépendance entre modules, ce sera maintenant plus simple.

module "vpc" {
    source  = "terraform-google-modules/network/google"
    version = "~> 2.4"

    project_id   = "<PROJECT ID>"
    network_name = "example-vpc"
    routing_mode = "GLOBAL"

    subnets = [
        {
            subnet_name           = "subnet-01"
            subnet_ip             = "10.10.10.0/24"
            subnet_region         = "us-west1"
        },
    ]
    depends_on = [
       aws_iam_role_policy.example,
    ]
}

Support des providers communautaires

Aujourd’hui les providers officiels sont téléchargés automatiquement lors d’un terraform init ou terraform get. En revanche, pour les providers communautaires il faut actuellement faire un curl vers un repo github, que l'on va intégrer dans un script shell ou dans un Makefile.

Aujourd’hui Hashicorp propose (en béta fermée pour l’instant) de pousser un provider communautaire sur la registry officielle hashicorp.

terraform {
  required_providers {
    jetstream = {
      source  = "nats-io/jetstream"
      version = "0.0.5"
    }
  }
}

Mais il sera possible également de spécifier un domaine custom.

Terraform Login

Cette nouvelle fonctionnalité est arrivée en version 0.12.21, il s’agit d’une intégration du service Terraform Cloud dans la CLI via terraform login qui va générer un token sur le service web, et faciliter l'utilisation du service.

Validation de variable

Il va être possible d’ajouter une validation sur les variables (cf l’exemple ci-dessous).

variable "image_id" {
  type        = string
  description = "The id of the machine image (AMI) to use for the server."
  validation {
    condition     = length(var.image_id) > 4 && substr(var.image_id, 0, 4) == "ami-"
    error_message = "The image_id value must be a valid AMI id, starting with \"ami-\"."
  }
}

Ça peut-être intéressant simplement sur la taille des variables. Plus généralement, il arrive fréquemment qu’une variable mal formatée provoque des erreurs tardivement lors d’un terraform apply, surtout à utiliser sur des modules.

Terraform 1.0 !

Pas d’annonces sur les fonctionnalités ni sur un planning, mais plutôt sur l’approche et la philosophie autour de la version 1.0 de Terraform.

Our first requirement for a 1.0 release at HashiCorp is production readiness.

Vous avez bien lu : Terraform 1.0 sortira quand elle sera prête pour la production, si vous utilisez Terraform en prod arrêtez tout 😅.

I and many others trust HashiCorp, and Terraform, with my production infrastructure. We already meet the first requirement. So let’s just move on.

Ok, ce n’est qu’un pré-requis largement atteint.

Next. We require that the major use cases are well-understood and well-supported.

Ce point là est plus complexe : comment supporter tous les usecases dont on a besoin dans Terraform ? On a souvent besoin de tordre la logique de Terraform, pour faire rentrer des ronds dans des carrés, avec l’utilisation de scripts shells par exemple pour lancer Terraform, ou dans le code Terraform (avec local_exec par exemple).

L’intégration d’un framework de test ? Aujourd’hui, il faut utiliser des outils comme Kitchenci ou Terratest pour effectuer des tests d’intégration. C’est évoqué mais rien de précis.

we count those little thumb up responses on issues

C’est dit, n’hésitez pas à ajouter un 👍 sur une issue, ça peut être utile.

Terraform 0.14 ?

Il est probable qu’il y ait une version 0.14 avant la version 1.0 :

That’s our last chance to deprecate features or introduce breaking changes, before 1.0.

Peut-être l’introduction d’un framework de test finalement ?