Terraform/fr

Terraform est un outil qui permet de définir et d'approvisionner l'infrastructure de centres de données, y compris des machines virtuelles. Terraform est de plus en plus utilisé au sein de l'Alliance. Son modèle d'infrastructure-en-code permet de maintenir les ressources OpenStack comme une collection de définitions qui peuvent être facilement mises à jour à l'aide des éditeurs de texte, partagées entre les membres d'un groupe et stockées dans un système de contrôle de version.

Cette page est écrite comme un tutoriel dans lequel nous présentons Terraform et démontrons son utilisation sur nos nuages OpenStack. Nous configurons notre espace de travail local pour Terraform et créons une machine virtuelle (VM pour virtual machine) avec une IP flottante et un volume attaché.

Préparation

Avant de commencer avec Terraform, vous avez besoin

• d'un accès à un projet OpenStack avec des ressources disponibles,
• d'installer le binaire terraform,
• d'effectuer quelques configurations sur votre poste de travail ou ordinateur portable.

Accéder à OpenStack

Pour accéder au nuage, voir Obtenir un projet dans l'environnement infonuagique. Si vous n'avez jamais utilisé OpenStack auparavant, vous devriez d'abord vous familiariser avec ce système en créant une machine virtuelle, en attachant un volume, en associant une IP flottante et en vous assurant que vous pouvez vous connecter à la machine virtuelle par la suite. Ce tutoriel suppose également que vous avez déjà créé une paire de clés SSH et que la clé publique a été importée dans OpenStack.

Si vous ne savez pas encore comment faire cela, le Guide de démarrage est une bonne introduction. La création de ces ressources à l'aide de l'interface web d'OpenStack vous permettra de comprendre le fonctionnement et l'utilité de Terraform.

Installer Terraform

Consultez la page de téléchargement de Terraform pour obtenir la dernière version du binaire. Nous utilisons ici Terraform 0.12.

S'identifier pour OpenStack

Il y a deux façons de fournir vos identifiants OpenStack dans un environnement de ligne de commande%nbsp;: via des variables d'environnement ou dans un fichier de configuration. Nous utiliserons une des méthodes décrited dans la section suivante. Quelle que soit votre méthode préférée, OpenStack propose un moyen simple de télécharger les identifiants. Une fois la connexion établie, cliquez sur API Access dans la barre de navigation; sur cette page se trouve le menu déroulant intitulé Download OpenStack RC File. À partir de là, vous pouvez télécharger un fichier clouds.yaml ou un fichier RC qui peut être obtenu à partir de votre session de l'interpréteur (shell).

Le fichier RC contient une liste de commandes pour l'interpréteur qui servent à exporter les variables d'environnement dans votre session active. Il ne s'agit pas d'un script indépendant et il doit recevoir de l'information par

$ source openrc.sh

Vous devez alors entrer votre mot de passe OpenStack qui sera enregistré dans une variable d'environnement préfixée par OS_. D'autres variables d'environnement seront créées avec certains renseignements sur vous, votre projet et le nuage auquel vous voulez vous connecter, par exemple

L’autre méthode est de créer une configuration dans $HOME/.config/openstack/clouds.yaml. Si vous n’avez pas déjà un tel fichier, vous pouvez télécharger clouds.yaml comme décrit ci-dessus et le copier à l’emplacement souhaité. Nous vous recommandons de modifier le nom donné au nuage dans le fichier téléchargé en un nom significatif, surtout si vous utilisez plusieurs nuages OpenStack. Ensuite, pour utiliser les outils CLI décrits ci-dessous, créez simplement une variable d’environnement $OS_CLOUD avec le nom du nuage que vous souhaitez utiliser.

$ export OS_CLOUD=arbutus

Peu importe ce que vous choisissez, vous utiliserez ceci pour configurer Terraform.

Session OpenStack

Il est utile d'avoir une fenêtre de terminal ouverte qui exécute l'interface de ligne de commande OpenStack. Cela fournit une référence pratique pour les spécifications que vous allez créer, car vous aurez besoin des identifiants de gabarits (flavors) et d'image pour vérifier les actions effectuées par Terraform. Horizon peut être utilisé pour rechercher des images et pour vérifier en général que Terraform produit les effets escomptés, mais il n'est pas possible de rechercher directement les identifiants des gabarits.

OpenStack CLI (aussi appelé OSC) est un client Python qui peut être installé avec Python Pip et qui ests disponibles pour plusieurs distribuitions et systèmes d'exploitation.

Espace de travail

Créez enfin un répertoire pour vos fichiers de configuration et d'état qui servira de point de départ.

Définir le fournisseur OpenStack

Décrivez d'abord le fournisseur : c'est ici que vous dites à Terraform d'utiliser OpenStack et comment l'utiliser. Lors de l'initialisation, la version la plus récente du plugiciel du fournisseur OpenStack sera installée dans le répertoire de travail et lors des opérations Terraform suivantes, les informations d'identification incluses seront utilisées pour se connecter au nuage spécifié.

Vos informations de connexion et d'identification pour OpenStack peuvent être fournies à Terraform dans la spécification, dans l'environnement ou partiellement dans la spécification avec le reste dans l'environnement.

Voici un exemple de spécification du fournisseur avec des informations de connexion et d'identification :

provider "openstack" {
  tenant_name = "some_tenant"
  tenant_id   = "1a2b3c45678901234d567890fa1b2cd3"
  auth_url    = "https://cloud.example.org:5000/v3"
  user_name   = "joe"
  password    = "sharethiswithyourfriends!"
  user_domain_name = "CentralID"
}

Pour certaines instances OpenStack, ce qui précède spécifierait l'ensemble complet des informations nécessaires pour se connecter à l'instance et gérer les ressources dans le projet locataire donné (tenant). Cependant, Terraform prend en charge les informations d'identification partielles dans lesquelles vous pouvez laisser certaines valeurs en dehors de la configuration Terraform et les fournir d'une autre manière. Cela nous permettrait, par exemple, de laisser le mot de passe en dehors du fichier de configuration, auquel cas il devrait être spécifié dans l'environnement avec $OS_PASSWORD.

Si vous préférez, vous pouvez aussi utiliser clouds.yaml et spécifier cloud.

provider "openstack" {
  cloud = "my_cloud"
}

Il n'est pas nécessaire d'entrer une définition pour provider.

provider "openstack" {
}

Dans ce cas, soit $OS_CLOUD, soit les variables définies par le fichier RC approprié doivent se trouver dans l'environnement d'exécution pour que Terraform puisse continuer.

Les options disponibles sont décrites en détail dans cette page de Terraform.

Ce que vous devriez utiliser

Il peut être tentant de laisser certains détails dans l'environnement afin que la configuration Terraform soit plus portable ou réutilisable, mais comme nous le verrons plus tard, la configuration Terraform contiendra et doit contenir des détails spécifiques à chaque nuage, tels que les UUID de gabarit et d'image, les noms de réseau et les locataires.

Le plus important pour votre configuration est la sécurité. Vous voudrez probablement éviter de stocker vos informations d’identification dans la configuration Terraform, même si vous ne les partagez avec personne, même si elles se trouvent sur votre propre poste de travail et que personne d’autre que vous n’y a accès. Même si vous n’avez pas peur du piratage, ce n’est certainement pas une bonne pratique de stocker des mots de passe et autres dans des fichiers de configuration qui peuvent finir par être copiés et déplacés dans votre système de fichiers lorsque vous essayez des choses. Mais aussi, n’oubliez jamais les bonnes pratiques pour contrer le piratage.

Initialiser Terraform

Pour nous assurer que le fournisseur est correctement configuré, initialisez Terraform et vérifiez la configuration jusqu'à présent. Avec la définition du fournisseur dans un fichier appelé, par exemple, nodes.tf, exécutez terraform init.

$ terraform init
Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "openstack" (terraform-providers/openstack)
  1.19.0...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.openstack: version = "~> 1.19"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Cela montre que l'initialisation de Terraform et le téléchargement du plugiciel du fournisseur ont ​​réussi donc que le code OpenStack est géré correctement. Cela ne teste pas les informations d'identification, car cette opération n'essaie pas réellement de se connecter au fournisseur défini.

Définir une VM

Définissions maintenant une VM de base.

Important : Il est recommandé de toujours spécifier les gabarits et les images à l'aide de leurs identifiants, même lorsque Terraform prend en charge l'utilisation du nom. Bien que le nom soit plus lisible, l'identifiant est ce qui définit réellement l'état de la ressource et l'identifiant d'une image ou d'un gabarit donné ne changera jamais. Il est toutefois possible que name change. Si un gabarit ou une image est retirée, par exemple, et remplacée par une autre du même nom, la prochaine fois que vous exécuterez Terraform, l'identifiant mis à jour sera détecté et Terraform déterminera que vous souhaitez reconstruire ou redimensionner la ressource associée. Il s'agit d'une opération pour détruire (et reconstruire).

Une machine virtuelle OpenStack minimale peut être définie comme suit dans Terraform :

resource "openstack_compute_instance_v2" "myvm" {
  name = "myvm"
  image_id = "80ceebef-f9aa-462e-a793-d3c1cf96123b"
  flavor_id = "0351ddb0-00d0-4269-80d3-913029d1a111"
  key_pair = "Aluminum"
  security_groups = ["default"]
}

Ceci crée une VM ayant le nom, l'image et le gabarit indiqués et associe la VM avec une paire de clés et le groupe de sécurité par défaut.

Remarque : Si vous avez suivi le tutoriel jusqu'ici (ce qu'il serait bon de faire), utilisez vos propres valeurs pour image_id, flavor_id et key_pair, sinon cela échouera probablement.

Les valeurs pour image_id et flavor_id sont l’une des raisons pour lesquelles j’aime avoir une session de terminal ouverte qui exécute l’interface de ligne de commande OpenStack, connectée au nuage que je cible avec Terraform : dans le terminal je peux utiliser flavor list ou image list pour répertorier les noms et les identifiants.

Si vous utilisez Horizon (l'interface Web d'OpenStack), cela est en partie possible; voir UUID des images et gabarits sous Horizon en annexe.

Notez qu'aucun volume n'est fourni. Une instance de calcul sur nos nuages aura déjà un volume qui lui est associé, mais une instance persistante échouera probablement à moins qu'il n'y ait assez d'espace vide dans l'image elle-même. Il est recommandé de créer un volume de démarrage pour les machines virtuelles qui utilisent des versions persistantes.

Tester

La commande terraform plan compile la définition de Terraform, tente de déterminer comment réconcilier l'état résultant avec l'état actuel du nuage et produit un plan des modifications qui s'appliqueraient.

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.


------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # openstack_compute_instance_v2.myvm will be created
  + resource "openstack_compute_instance_v2" "myvm" {
      + access_ip_v4        = (known after apply)
      + access_ip_v6        = (known after apply)
      + all_metadata        = (known after apply)
      + availability_zone   = (known after apply)
      + flavor_id           = "0351ddb0-00d0-4269-80d3-913029d1a111"
      + flavor_name         = (known after apply)
      + force_delete        = false
      + id                  = (known after apply)
      + image_id            = "80ceebef-f9aa-462e-a793-d3c1cf96123b"
      + image_name          = (known after apply)
      + key_pair            = "Aluminum"
      + name                = "myvm"
      + power_state         = "active"
      + region              = (known after apply)
      + security_groups     = [
          + "default",
        ]
      + stop_before_destroy = false

      + network {
          + access_network = (known after apply)
          + fixed_ip_v4    = (known after apply)
          + fixed_ip_v6    = (known after apply)
          + floating_ip    = (known after apply)
          + mac            = (known after apply)
          + name           = (known after apply)
          + port           = (known after apply)
          + uuid           = (known after apply)
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Prenez connaissance du résultat. Même s'il contient beaucoup d'information, il est nécessaire d'en connaître le contenu avant d'accepter les modifications afin d'éviter les mauvaises surprises.

Si vous obtenez une erreur concernant des informations d'identification incomplètes, vous avez peut-être oublié de définir OS_CLOUD ou de sourcer le fichier RC, ou encore, votre fichier clouds.yaml est peut-être absent.

Ces valeurs sont celles des ressources telles qu'elles seraient définies dans OpenStack. Tout ce qui est marqué comme known after apply sera déterminé à partir de l'état des ressources nouvellement créées interrogées à partir d'OpenStack. Les autres valeurs sont définies en fonction de ce que nous avons défini ou déterminé par Terraform et le plugiciel OpenStack comme valeurs calculées ou par défaut.

Si vous n'avez pas le temps et que ce n'est pas grave de détruire accidentellement des ressources ou de les reconstruire, prenez au moins le temps de vérifier la dernière ligne du plan.

Plan: 1 to add, 0 to change, 0 to destroy.

In this case, we know we’re adding a resource so this looks right. If the other values were non-zero then we’d better have another look at our configuration, state and what’s actually defined in OpenStack and make whatever corrections are necessary.

Que se passe-t-il avec les ressources OpenStack déjà existantes?

Si des VM sont déjà définies dans votre projet OpenStack, vous vous demandez peut-être si Terraform affectera ces ressources.

Eh bien non. Terraform ne connait pas les ressources qui sont déjà définies pour le projet et n'essaie pas d'en déterminer l'état. Les actions de Terraform se basent sur la configuration fournie et sur l'état précédemment déterminé dans la configuration. Les ressources existantes ne sont pas représentées dans Terraform et lui sont invisibles.

It is possible to import previously defined OpenStack resources into Terraform but it is not a trivial amount of work and outside the scope of this tutorial. The important thing here is that any existing resources in your OpenStack project are safe from inadvertent mangling from Terraform—but just to be on the safe side, why don’t you make sure you read the output plans carefully? :)

Appliquer la configuration

Utilisez terraform apply pour effectuer le changement décrit dans le plan.

$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

[... repeat of the plan from above ...]

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

openstack_compute_instance_v2.myvm: Creating...

Error: Error creating OpenStack server: Expected HTTP response code [] when
accessing [POST
https://cloud.example.org:8774/v2.1/43b86742c5ee4eaf800a36d7d234d95c/servers],
but got 409 instead
{"conflictingRequest": {"message": "Multiple possible networks found, use a
Network ID to be more specific.", "code": 409}}

  on nodes.tf line 4, in resource "openstack_compute_instance_v2" "myvm":
   4: resource "openstack_compute_instance_v2" "myvm" {

Dans notre exemple, ceci échoue. Il y a au moins deux réseaux qui sont définis pour un projet OpenStack : un privé et un public. Terraform a besoin de savoir lequel utililser.

Ajouter un réseau

The name of the private network differs from project to project and the naming convention can differ from cloud to cloud, but typically they are on a 192.168.X.Y network, and can be found in the CLI using `network list` or on Horizon under Network -> Networks. If your project's private network is my-tenant-net, you will add a network resource sub-block to your VM definition similar to the following:

resource "openstack_compute_instance_v2" "myvm" {
  name = "myvm"
  image_id = "80ceebef-f9aa-462e-a793-d3c1cf96123b"
  flavor_id = "0351ddb0-00d0-4269-80d3-913029d1a111"
  key_pair = "Aluminum"
  security_groups = ["default"]

  network {
    name = "my-tenant-net"
  }
}

Essayez de nouveau.

$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # openstack_compute_instance_v2.myvm will be created
  + resource "openstack_compute_instance_v2" "myvm" {
      + access_ip_v4        = (known after apply)
      + access_ip_v6        = (known after apply)
      + all_metadata        = (known after apply)
      + availability_zone   = (known after apply)
      + flavor_id           = "0351ddb0-00d0-4269-80d3-913029d1a111"
      + flavor_name         = (known after apply)
      + force_delete        = false
      + id                  = (known after apply)
      + image_id            = "80ceebef-f9aa-462e-a793-d3c1cf96123b"
      + image_name          = (known after apply)
      + key_pair            = "Aluminum"
      + name                = "myvm"
      + power_state         = "active"
      + region              = (known after apply)
      + security_groups     = [
          + "default",
        ]
      + stop_before_destroy = false

      + network {
          + access_network = false
          + fixed_ip_v4    = (known after apply)
          + fixed_ip_v6    = (known after apply)
          + floating_ip    = (known after apply)
          + mac            = (known after apply)
          + name           = "my-tenant-net"
          + port           = (known after apply)
          + uuid           = (known after apply)
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

openstack_compute_instance_v2.myvm: Creating...
openstack_compute_instance_v2.myvm: Still creating... [10s elapsed]
openstack_compute_instance_v2.myvm: Still creating... [20s elapsed]
openstack_compute_instance_v2.myvm: Still creating... [30s elapsed]
openstack_compute_instance_v2.myvm: Creation complete after 32s [id=1f7f73ff-b9b5-40ad-9ddf-d848efe13e42]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

You now have a VM created by Terraform. You should see your new VM on Horizon or in the output of server list in your OpenStack terminal window:

(openstack) server list -c ID -c Name -c Status
+--------------------------------------+--------+--------+
| ID                                   | Name   | Status |
+--------------------------------------+--------+--------+
| 1f7f73ff-b9b5-40ad-9ddf-d848efe13e42 | myvm   | ACTIVE |
| c3fa7d11-4122-412a-ad19-32e52cbb8f66 | store  | ACTIVE |
| f778f65f-c9d5-4808-930b-9f50d82a8c9c | puppet | ACTIVE |
| 9b42cbf3-3782-4472-bdd0-9028bbb73460 | lbr    | ACTIVE |
+--------------------------------------+--------+--------+

Dans ce résultat, trois instances précédemment créées ont survécu sans être touchées par Terraform.

Récapitulation

Note there is now a file in your workspace called terraform.tfstate. This was created by Terraform during the application of the new configuration and confirmation of its success. The state file contains details about the managed resources Terraform uses to determine how to arrive at a new state described by configuration updates. In general, you will not need to look at this file, but know that without it, Terraform cannot properly manage resources and if you delete it, you will need to restore it or recreate it, or manage those resources without Terraform.

You now have a working VM which has successfully been initialized and is on the private network. You can’t log in and check it out, however, because you haven’t assigned a floating IP to this host, so it’s not directly accessible from outside the tenant.

If you had another host in that tenant with a floating IP, you could use that host as a jump host (sometimes called a bastion host) to the new VM, as they will both be on the same private network. This is a good strategy to use for nodes that do not need to be directly accessible from the internet, such as a database server, or just to preserve floating IPs, which are a limited resource.

Pour l'instant, ajoutez une IP flottante à votre nouvelle VM.

Ajouter une adresse IP flottante

Une IP flottante n'est pas créée directement sur une VM OpenStack, mais est allouée au projet à partir d'un groupe d'IP et associée à l'iinterface du réseau privé de l'IP.

Assuming you do not already have a floating IP allocated for this use, declare a floating IP resource like the following example. The only thing you need is to know the pool from which to allocate the floating IP; on our clouds, this is the external network (ext_net in this example).

resource "openstack_networking_floatingip_v2" "myvm_fip" {
  pool = "ext_net"
}

Acceptez ce changement maintenant ou utilisez terraform plan pour voir ce qui se produirait.

$ terraform apply
openstack_compute_instance_v2.myvm: Refreshing state...
[id=1f7f73ff-b9b5-40ad-9ddf-d848efe13e42]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # openstack_networking_floatingip_v2.myvm_fip will be created
  + resource "openstack_networking_floatingip_v2" "myvm_fip" {
      + address   = (known after apply)
      + all_tags  = (known after apply)
      + fixed_ip  = (known after apply)
      + id        = (known after apply)
      + pool      = "provider-199-2"
      + port_id   = (known after apply)
      + region    = (known after apply)
      + tenant_id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

openstack_networking_floatingip_v2.myvm_fip: Creating...
openstack_networking_floatingip_v2.myvm_fip: Creation complete after 9s
[id=20190061-c2b6-4740-bbfc-6facbb300dd4]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Cette IP flottante est maintenant allouée, mais pas encore associée à votre instance. Ajoutez la définition suivante :

resource "openstack_compute_floatingip_associate_v2" "myvm_fip" {
  floating_ip = openstack_networking_floatingip_v2.myvm_fip.address
  instance_id = openstack_compute_instance_v2.myvm.id
}

Les attributs de cette nouvelle ressource sont définies par des références à d'autres ressources et leurs attributs.

Note: Current documentation of the OpenStack provider documentation uses syntax which differs from what is presented here as it has not yet been updated for changes to Terraform v.12.

References like this are typically <resource type>.<resource name>.<attribute>. Others you may soon see include var.<variable name>. At any rate, this resource forms an association between the created earlier, and the floating IP allocated in the next step.

$ terraform apply
openstack_networking_floatingip_v2.myvm_fip: Refreshing state...
[id=20190061-c2b6-4740-bbfc-6facbb300dd4]
openstack_compute_instance_v2.myvm: Refreshing state...
[id=1f7f73ff-b9b5-40ad-9ddf-d848efe13e42]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # openstack_compute_floatingip_associate_v2.myvm_fip will be created
  + resource "openstack_compute_floatingip_associate_v2" "myvm_fip" {
      + floating_ip = "X.Y.Z.W"
      + id          = (known after apply)
      + instance_id = "1f7f73ff-b9b5-40ad-9ddf-d848efe13e42"
      + region      = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

openstack_compute_floatingip_associate_v2.myvm_fip: Creating...
openstack_compute_floatingip_associate_v2.myvm_fip: Creation complete after 5s
[id=X.Y.Z.W/1f7f73ff-b9b5-40ad-9ddf-d848efe13e42/]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

S'il y a une IP flottante, vous pouvez probablement vous connecter à l'instance via SSH maintenant.

$ ssh centos@X.Y.Z.W hostname
The authenticity of host 'X.Y.Z.W (X.Y.Z.W)' can't be established.
ECDSA key fingerprint is SHA256:XmN5crnyxvE1sezdpo5tG5Z2nw0Z+2pspvkNSGpB99A.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'X.Y.Z.W' (ECDSA) to the list of known hosts.
myvm.novalocal

Autrement, il est possible que vous deveiz ajpouter l'adresse IP de votre ordinateur au groupe de sécurité par défaut du projet.

Ajouter un volume

Next, add a root volume to the VM. Since this will replace its boot disk, this is a destructive operation. This is something you need to watch out for in Terraform, and one of the chief reasons for reading your plans carefully before applying. It’s unlikely you’re going to accidentally cause critical issues in creating new resources, but it can be deceptively easy to accidentally create configuration changes that require rebuilding existing VMs.

Puisque c'est un volume racine, créez-le dans l'instance de calcul en tant que sous-bloc avec le sous-bloc du réseau.

  block_device {
    uuid = "80ceebef-f9aa-462e-a793-d3c1cf96123b"
    source_type = "image"
    destination_type = "volume"
    volume_size = 10
    boot_index = 0
    delete_on_termination = true
  }

Set the uuid attribute to the UUID of the image you want to use and remove image_id from the outer block definition. The other attributes are self-explanatory, except for destination_type, which is here set to volume to indicate this is to be stored with an OpenStack-provided volume rather than using disk on the hypervisor. delete_on_termination is important—for testing, you will probably want this to be true so you don’t have to remember to constantly clean up leftover volumes, but for real use you should consider setting it to false as a last defence against accidental deletion of resources.

Do not leave the image_id attribute defined in the outer compute instance definition! This will work, but Terraform will see a change from “boot from volume” to “boot directly from image” on every run, and so will always attempt to rebuild your instance. (This is probably a flaw in the OpenStack provider.)

Here’s how the plan looks:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # openstack_compute_floatingip_associate_v2.myvm_fip must be replaced
-/+ resource "openstack_compute_floatingip_associate_v2" "myvm_fip" {
        floating_ip = "199.241.167.122"
      ~ id          = "199.241.167.122/1f7f73ff-b9b5-40ad-9ddf-d848efe13e42/" -> (known after apply)
      ~ instance_id = "1f7f73ff-b9b5-40ad-9ddf-d848efe13e42" -> (known after apply) # forces replacement
      ~ region      = "RegionOne" -> (known after apply)
    }

  # openstack_compute_instance_v2.myvm must be replaced
-/+ resource "openstack_compute_instance_v2" "myvm" {
      ~ access_ip_v4        = "192.168.2.11" -> (known after apply)
      + access_ip_v6        = (known after apply)
      ~ all_metadata        = {} -> (known after apply)
      ~ availability_zone   = "nova" -> (known after apply)
        flavor_id           = "0351ddb0-00d0-4269-80d3-913029d1a111"
      ~ flavor_name         = "p1-3gb" -> (known after apply)
        force_delete        = false
      ~ id                  = "1f7f73ff-b9b5-40ad-9ddf-d848efe13e42" -> (known after apply)
        image_id            = "80ceebef-f9aa-462e-a793-d3c1cf96123b"
      ~ image_name          = "CentOS-7-x64-2018-05" -> (known after apply)
        key_pair            = "Aluminum"
        name                = "myvm"
        power_state         = "active"
      ~ region              = "RegionOne" -> (known after apply)
        security_groups     = [
            "default",
        ]
        stop_before_destroy = false

      + block_device {
          + boot_index            = 0 # forces replacement
          + delete_on_termination = true # forces replacement
          + destination_type      = "volume" # forces replacement
          + source_type           = "image" # forces replacement
          + uuid                  = "80ceebef-f9aa-462e-a793-d3c1cf96123b" # forces replacement
          + volume_size           = 10 # forces replacement
        }

      ~ network {
            access_network = false
          ~ fixed_ip_v4    = "192.168.2.11" -> (known after apply)
          + fixed_ip_v6    = (known after apply)
          + floating_ip    = (known after apply)
          ~ mac            = "fa:16:3e:3b:79:27" -> (known after apply)
            name           = "my-tenant-net"
          + port           = (known after apply)
          ~ uuid           = "5c96bf54-a396-47c5-ab12-574f630bcb80" -> (known
after apply)
        }
    }

Notez qu'il y a plusieurs avertissements qui vous informent de ce qui sera modifié, sans oublier

Plan: 2 to add, 0 to change, 2 to destroy.

Your VM will be created with a new SSH key, so if you connected previously you'll need to remove the SSH key from your known_hosts file (or the equivalent). After this, the first thing to do is log on and apply all available updates.

[centos@myvm ~]$ sudo yum update -y
...
[ goes for ages ]

Vous avez maintenant une VM terraformée fonctionnelle, un moyen d'y accéder, un endroit où enregistrer les données et les dernières mises à jour du système d'exploitation.

Exemple complet

provider "openstack" {
}

resource "openstack_compute_instance_v2" "myvm" {
  name = "myvm"
  flavor_id = "0351ddb0-00d0-4269-80d3-913029d1a111"
  key_pair = "Aluminum"
  security_groups = ["default"]

  network {
    name = "my-tenant-net"
  }

  block_device {
    uuid = "80ceebef-f9aa-462e-a793-d3c1cf96123b"
    source_type = "image"
    destination_type = "volume"
    volume_size = 10
    boot_index = 0
    delete_on_termination = true
  }
}

resource "openstack_networking_floatingip_v2" "myvm_fip" {
  pool = "provider-199-2"
}

resource "openstack_compute_floatingip_associate_v2" "myvm_fip" {
  floating_ip = openstack_networking_floatingip_v2.myvm_fip.address
  instance_id = openstack_compute_instance_v2.myvm.id
}

Annexe

Références

The following might be of interest to those exploring further and building on the work done in this tutorial. Note that as of this writing the OpenStack provider’s documentation conforms to v0.11 syntax, but this should work under v0.12 without trouble.

• What is Terraform?
• OpenStack Provider
• OpenStack compute instance v2 : plusieurs cas d'usage pour la création d'instances dans OpenStack avec Terraform
• La page wiki sur notre service infonuagique et la page Cloud : Guide de démarrage

Exemples

• Projet Magic Castle
• diodonfrost/terraform-openstack-examples sur GitHub

UUID des images et gabarits sous Horizon

For those more comfortable using the web interface to OpenStack, here is a quick cheat sheet on finding flavour and image UUIDs in Horizon. You’ll need to log into the web interface of the cloud for this information.

To find an image’s UUID, find the Images menu item under Compute (1).

Localiser et sélectionner une image

Vous obtiendrez une liste des images disponibles pour votre projet. Cliquez sur celle que vous voulez utiliser. (2)

UUID de l'image

… et vous avez l'ID.

C'est un peu plus compliqué pour les gabarits.

For this you have to fake out launching an instance, but that doesn’t even give you the ID of the flavour. But at least you’ll know the name of the flavour you want.

Lancer une instance

Sur la page de l'instance, sélectionnez Flavor (pour Gabarit).

Option Flavor

Now you should have a list of flavours and it’ll also show you which ones fit within your quotas. All you’ve got here is the name, though.

Sélectionner un gabarit

Pour obtenir l'ID, il y a deux options :

1. Use the name for the first Terraform run, and then get the ID from the output or state file, and finally, switch your configuration to use the ID instead. This should not attempt to recreate the VM, but check before you agree to terraform apply.
2. Switch to using the OpenStack CLI. (Recommended.)