Comment gérer une infrastructure cloud avec Terraform

Dans cet article, nous examinerons la composition de Terraform, ainsi que les étapes pour lancer notre propre infrastructure. dans le cloud avec VMware. — nous préparerons trois VM pour différents objectifs : un proxy, un stockage de fichiers et un CMS.

Tout cela en détail et en trois étapes :

• Terraform — description, avantages et composants.

• Création d'infrastructure.

• Initialisation de l'infrastructure.

  • Travail de Terraform avec une infrastructure existante.

1. Terraform — description, avantages et composants.

Terraform est un outil IaC (Infrastructure-as-Code) pour construire et gérer une infrastructure virtuelle à l'aide de code.

Lors de l'utilisation de cet outil, nous avons noté plusieurs avantages :

• Vitesse de déploiement de nouveaux locataires (environnements virtuels utilisateurs). En général, plus il y a de nouveaux clients, plus le personnel du support technique doit effectuer de « clics » pour publier de nouvelles ressources. Avec Terraform, les utilisateurs peuvent modifier les paramètres des machines virtuelles (par exemple, éteindre automatiquement le système d'exploitation et augmenter la taille de la partition du disque virtuel) sans l'aide du support technique et sans éteindre la machine elle-même.

• Vérification instantanée du plan d'activation du nouveau locataire. Grâce à la description du code de l'infrastructure, nous pouvons immédiatement vérifier ce qui sera ajouté et dans quel ordre, ainsi que l'état final d'une machine virtuelle ou d'un réseau virtuel avec des connexions aux machines virtuelles.

• Possibilité de décrire la plupart des plateformes cloud populaires. Vous pouvez utiliser l'outil d'Amazon et Google Cloud, jusqu'à des plateformes privées basées sur VMware vCloud Director, offrant des services dans le cadre des solutions IaaS, SaaS et PaaS.

• Gérer plusieurs fournisseurs cloud et répartir l'infrastructure entre eux pour améliorer la résilience, en utilisant une seule configuration pour créer, diagnostiquer et gérer les ressources cloud.

• Utilisation pratique pour créer des environnements de démonstration pour tester et débugger des logiciels. Vous pouvez créer et fournir des environnements pour le département de test, vérifier simultanément le logiciel dans différents environnements, ainsi que modifier et supprimer instantanément des ressources en ne créant qu'un seul plan de construction de ressources.

Le « Terrarium » de Terraform.

Nous avons brièvement présenté les avantages de l'outil, maintenant examinons ses composants.

Providers (fournisseurs). 

Dans Terraform, presque tout type d'infrastructure peut être représenté comme une ressource. La connexion entre les ressources et la plateforme API est assurée par des modules providers, qui permettent de créer des ressources dans le cadre d'une plateforme spécifique, par exemple, Azure ou VMware vCloud Director.

Dans le cadre du projet, vous pouvez interagir avec différents providers sur différentes plateformes.

Ressources (description des ressources).

La description des ressources permet de gérer les composants de la plateforme, comme les machines virtuelles ou les réseaux. 

Vous pouvez créer votre propre description des ressources pour le provider VMware vCloud Director et utiliser cette description pour créer des ressources auprès de tout hébergeur utilisant vCloud Director. Vous n'aurez qu'à remplacer les paramètres d'authentification et d'accès réseau du provider d'hébergement souhaité.

Provisioners.

Cet élément permet d'effectuer des opérations d'installation initiale et de maintenance du système d'exploitation après la création des machines virtuelles. Une fois que vous avez créé la ressource de la machine virtuelle, grâce aux provisioners, vous pouvez configurer et vous connecter via SSH, mettre à jour le système d'exploitation, ainsi que télécharger et exécuter un script. 

Variables Input et Output.

Les variables Input sont des variables d'entrée pour tous types de blocs. 

Les variables Output permettent de conserver des valeurs après la création des ressources et peuvent être utilisées comme variables d'entrée dans d'autres modules, par exemple dans le bloc Provisioners.

States (états).

Les fichiers States conservent des informations sur la configuration des ressources de la plateforme provider. Lors de la première création de la plateforme, aucune information sur les ressources n'est disponible, et avant toute opération, Terraform met à jour l'état avec l'infrastructure réelle des ressources déjà décrites.

L'objectif principal des états est de conserver le lien des objets des ressources déjà créées afin de comparer la configuration des ressources ajoutées et des objets, pour éviter la recréation et les modifications de la plateforme.

Les informations d'état sont par défaut stockées dans un fichier local terraform.tfstate, mais il est possible d'utiliser un stockage distant si nécessaire pour travailler en équipe.

Vous pouvez également importer les ressources actuelles de la plateforme dans l'état afin d'interagir avec d'autres ressources qui, en retour, ont été créées sans l'aide de Terraform.  

2. Création de l'infrastructure

Les composants étant analysés, nous allons maintenant créer l'infrastructure étape par étape avec Terraform en utilisant trois machines virtuelles. La première comporte un serveur proxy nginx installé, la seconde dispose d'un stockage de fichiers basé sur Nextcloud, et la troisième utilise le CMS Bitrix.

Nous allons écrire le code et l'exécuter à l'aide de notre cloud sur VMware vCloud Director. Les utilisateurs reçoivent un compte avec des droits d'Administrateur d'Organisation. Si vous utilisez un compte avec les mêmes droits dans un autre cloud VMware, vous pourrez reproduire le code de nos exemples. Allons-y !

Commençons par créer un répertoire pour notre nouveau projet, où seront stockés les fichiers décrivant l'infrastructure.

mkdir project01

Nous allons ensuite décrire les composants de l'infrastructure. Terraform crée des liaisons et traite les fichiers selon les descriptions contenues dans ces fichiers. Les fichiers peuvent être nommés en fonction de l'objectif des blocs décrits, par exemple, network.tf — décrit les paramètres réseau de l'infrastructure.

Pour décrire les composants de notre infrastructure, nous avons créé les fichiers suivants :

Liste des fichiers.

main.tf — description des paramètres pour l'environnement virtuel — machines virtuelles, conteneurs virtuels ;

network.tf — description des paramètres du réseau virtuel et des règles NAT, Firewall ;

variables.tf — liste des variables que nous utilisons ;

vcd.tfvars — valeurs des variables du projet pour le module VMware vCloud Director.

Le langage de configuration dans Terraform est déclaratif et l'ordre des blocs n'a pas d'importance, à l'exception des blocs provisioner, car dans ce bloc, nous décrivons les commandes à exécuter lors de la préparation de l'infrastructure et elles seront exécutées dans l'ordre.

Structure des blocs.

"" "" {

# Block body

= # Argument

}

Pour décrire les blocs, un langage de programmation propre, HCL (HashiCorp Configuration Language), est utilisé ; il est également possible de décrire l'infrastructure en utilisant JSON. Pour en savoir plus sur la syntaxe, vous pouvez lire sur le site du développeur.

Configuration des variables d'environnement, variables.tf et vcd.tfvars

Commençons par créer deux fichiers qui décrivent la liste de toutes les variables utilisées et leurs valeurs pour le module VMware vCloud Director. Nous allons d'abord créer le fichier variables.tf.

Contenu du fichier variables.tf.

variable "vcd_org_user" {

  description = "Utilisateur de vCD Tenant"

}

variable "vcd_org_password" {

  description = "Mot de passe de vCD Tenant"

}

variable "vcd_org" {

  description = "Organisation de vCD Tenant"

}

variable "vcd_org_vdc" {

  description = "VDC de vCD Tenant"

}

variable "vcd_org_url" {

  description = "URL de vCD Tenant"

}

variable "vcd_org_max_retry_timeout" {

  default = "60"

}

variable "vcd_org_allow_unverified_ssl" {

  default = "true"

}

variable "vcd_org_edge_name" {

  description = "Nom de l'edge vCD"

}

variable "vcd_org_catalog" {

  description = "Catalogue public de vCD"

}

variable "vcd_template_os_centos7" {

  description = "OS CentOS 7"

  default = "CentOS7"

}

variable "vcd_org_ssd_sp" {

  description = "Politiques de stockage"

  default = "Politique de stockage Or"

}

variable "vcd_org_hdd_sp" {

  description = "Politiques de stockage"

  default = "Politique de stockage Bronze"

}

variable "vcd_edge_local_subnet" {

  description = "Sous-réseau du réseau de l'organisation"

}

variable "vcd_edge_external_ip" {

  description = "IP publique externe"

}

variable "vcd_edge_local_ip_nginx" {}

variable "vcd_edge_local_ip_bitrix" {}

variable "vcd_edge_local_ip_nextcloud" {}

variable "vcd_edge_external_network" {}

Valeurs des variables que nous recevons du fournisseur.

• vcd_org_user — nom d'utilisateur avec les droits d'Administrateur d'organisation,

• vcd_org_password — mot de passe de l'utilisateur,

• vcd_org — nom de l'organisation,

• vcd_org_vdc — nom du centre de données virtuel,

• vcd_org_url — URL de l'API,

• vcd_org_edge_name — nom du routeur virtuel,

• vcd_org_catalog — nom du catalogue de modèles de machines virtuelles,

• vcd_edge_external_ip — adresse IP publique,

• vcd_edge_external_network — nom du réseau externe,

• vcd_org_hdd_sp — nom de la politique de stockage HDD,

• vcd_org_ssd_sp — nom de la politique de stockage SSD.

Et nous introduisons nos variables :

• vcd_edge_local_ip_nginx — adresse IP de la machine virtuelle avec NGINX,

• vcd_edge_local_ip_bitrix — adresse IP de la machine virtuelle avec 1C: Bitrix,

• vcd_edge_local_ip_nextcloud — adresse IP de la machine virtuelle avec Nextcloud.

Dans le second fichier, nous créons et indiquons les variables pour le module VMware vCloud Director dans le fichier vcd.tfvars : Rappelons que dans notre exemple, nous utilisons notre propre cloud mClouds, si vous travaillez avec un autre fournisseur, vérifiez les valeurs avec lui. 

Contenu du fichier vcd.tfvars.

vcd_org_url = "https://vcloud.mclouds.ru/api"

vcd_org_user = "orgadmin"

vcd_org_password = "*"

vcd = "org"

vcd_org_vdc = "orgvdc"

vcd_org_maxretry_timeout = 60

vcd_org_allow_unverified_ssl = true

vcd_org_catalog = "Templates"

vcd_templateos_centos7 = "CentOS7"

vcd_org_ssd_sp = "Gold Storage Policy"

vcd_org_hdd_sp = "Bronze Storage Policy"

vcd_org_edge_name = "MCLOUDS-EDGE"

vcd_edge_external_ip = "185.17.66.1"

vcd_edge_local_subnet = "192.168.110.0/24"

vcd_edge_local_ip_nginx = "192.168.110.1"

vcd_edge_local_ip_bitrix = "192.168.110.10"

vcd_edge_local_ip_nextcloud = "192.168.110.11"

vcd_edge_external_network = "NET-185-17-66-0"

Configuration réseau, network.tf.

Les variables d'environnement sont définies, maintenant nous allons configurer le schéma de connexion des machines virtuelles — nous allons attribuer une adresse IP privée à chaque machine virtuelle et, grâce au NAT de destination, nous « ouvrirons » les ports vers le réseau externe. Pour limiter l'accès aux ports de gestion, nous autoriserons uniquement notre adresse IP.

Schéma de réseau pour la plateforme Terraform à créer

Créons un réseau organisationnel virtuel nommé net_lan01, avec une passerelle par défaut : 192.168.110.254, ainsi qu'un espace d'adresses : 192.168.110.0/24.

Décrivons le réseau virtuel.

resource "vcd_network_routed" "net" {

  name = "net_lan01"

  edge_gateway = var.vcd_org_edge_name

  gateway = "192.168.110.254"

  dns1 = "1.1.1.1"

  dns2 = "8.8.8.8"

 static_ip_pool {

start_address = "192.168.110.1"

end_address = "192.168.110.253"

  }

}

Nous allons créer des règles pour le pare-feu permettant aux machines virtuelles d'accéder à Internet. Dans ce bloc, toutes les ressources virtuelles dans le cloud auront accès à Internet :

Décrivons les règles d'accès des VM à Internet.

resource "vcd_nsxv_firewall_rule" "fw_internet_access" {

  edge_gateway = var.vcdorgedgename

  name = "Accès Internet"

  source {

gateway_interfaces = ["internal"]

  }

  destination {

gateway_interfaces = ["external"]

  }

  service {

protocol = "any"

  }

  depends_on = [vcdnetworkrouted.net]

}

En établissant une dépendance, nous indiquons qu'après le bloc vcdnetworkrouted.net, nous procéderons à la configuration du bloc vcdnsxvfirewallrule., à l'aide de dependson. Utilisons cette option, car certaines dépendances peuvent être reconnues implicitement dans la configuration.

Ensuite, nous allons créer des règles autorisant l'accès aux ports depuis le réseau externe et nous précisons notre adresse IP pour nous connecter par SSH aux serveurs. Tout utilisateur d'Internet a accès aux ports 80 et 443 sur le serveur web et l'utilisateur ayant l'adresse IP 90.1.15.1 a accès aux ports SSH des serveurs virtuels.

Nous autorisons l'accès aux ports depuis le réseau externe.

resource "vcd_nsxv_firewall_rule" "fwnatports" {

  edge_gateway = var.vcd_org_edge_name

  name = "Accès HTTPs"

  source {

gateway_interfaces = ["external"]

  }

  destination {

  gateway_interfaces = ["internal"]

  }

  service {

protocol = "tcp"

port = "80"

  }

  service {

protocol = "tcp"

port = "443"

  }

  depends_on = [vcd_network_routed.net]

}

resource "vcd_nsxv_firewall_rule" "fw_nat_admin_ports" {

  edge_gateway = var.vcd_org_edge_name

  name = "Accès Administratif"

  source {

  ip_addresses = [ "90.1.15.1" ]

  }

  destination {

  gateway_interfaces = ["internal"]

  }

  service {

protocol = "tcp"

port = "58301"

  }

  service {

protocol = "tcp"

port = "58302"

  }

  service {

protocol = "tcp"

port = "58303"

  }

  depends_on = [vcd_network_routed.net]

}

Nous créons des règles de Source NAT pour donner accès à Internet depuis le réseau local cloud :

Décrivons les règles de Source NAT.

resource "vcd_nsxv_snat" "snat_local" {

edge_gateway = var.vcd_org_edge_name

  network_type = "ext"

  network_name = var.vcdedgeexternalnetwork

  original_address = var.vcd_edge_local_subnet

translated_address = var.vcd_edge_external_ip

  depends_on = [vcd_network_routed.net]

}

Et en fin de configuration du bloc réseau, nous ajoutons des règles de Destination NAT pour accéder aux services depuis le réseau externe :

Ajoutons des règles de Destination NAT.

resource "vcd_nsxv_dnat" "dnat_tcp_nginx_https" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"


  description = "NGINX HTTPs"

adresse_originale = var.vcd_edge_external_ip
port_original = 443

adresse_traduite = var.vcd_edge_local_ip_nginx
port_traduit = 443
protocole = "tcp"

depends_on = [vcd_network_routed.net]
}
ressource "vcd_nsxv_dnat" "dnat_tcp_nginx_http" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"

description = "NGINX HTTP"

adresse_originale = var.vcd_edge_external_ip
port_original = 80

adresse_traduite = var.vcd_edge_local_ip_nginx
port_traduit = 80
protocole = "tcp"

depends_on = [vcd_network_routed.net]

}

Ajout d'une règle NAT pour la redirection des ports vers le serveur SSH sous Nginx.

ressource "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"

description = "SSH NGINX"

adresse_originale = var.vcd_edge_external_ip
port_original = 58301

adresse_traduite = var.vcd_edge_local_ip_nginx
port_traduit = 22
protocole = "tcp"

depends_on = [vcd_network_routed.net]

}

Ajout d'une règle NAT pour la redirection des ports vers le serveur SSH avec 1C-Bitrix.

ressource "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"

description = "SSH Bitrix"

adresse_originale = var.vcd_edge_external_ip
port_original = 58302

adresse_traduite = var.vcd_edge_local_ip_bitrix
port_traduit = 22
protocole = "tcp"

depends_on = [vcd_network_routed.net]

}

Ajout d'une règle NAT pour la redirection des ports vers le serveur SSH avec Nextcloud.

ressource "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"

description = "SSH Nextcloud"

adresse_originale = var.vcd_edge_external_ip
port_original = 58303 adresse_traduite = var.vcd_edge_local_ip_nextcloud
port_traduit = 22
protocole = "tcp"

depends_on = [vcd_network_routed.net]

}

Configuration de l'environnement virtuel main.tf

Comme prévu au début de l'article, nous allons créer trois machines virtuelles. Elles seront préparées à l'aide de la « personnalisation de l'invité ». Les paramètres réseau seront configurés selon nos spécifications, et le mot de passe de l'utilisateur sera généré automatiquement.

Nous allons décrire le vApp qui contiendra les machines virtuelles et leurs configurations.

Configuration des machines virtuelles

Créons un conteneur vApp. Pour que nous puissions immédiatement connecter le vApp et les VM au réseau virtuel, nous ajoutons également le paramètre depends_on :

Créons un conteneur

ressource "vcd_vapp" "vapp" {
nom = "web"
mettre_en_route = "true" depends_on = [vcd_network_routed.net]

}

Créons une machine virtuelle avec description

ressource "vcd_vapp_vm" "nginx" {

nom_vapp = vcd_vapp.vapp.nom

nom = "nginx"

nom_catalogue = var.vcd_org_catalog

nom_template = var.vcd_template_os_centos7

profil_stockage = var.vcd_org_ssd_sp

mémoire = 8192

cpus = 1

cœurs_cpu = 1

réseau {

type = "org"

nom = vcd_network_routed.net.nom

est_primaire = true

type_adaptateur = "VMXNET3"

mode_allocation_ip = "MANUEL"

ip = var.vcd_edge_local_ip_nginx

}

override_template_disk {

type_bus = "paravirtual"

taille_en_mb = "32768"

numéro_bus = 0

numéro_unité = 0

profil_stockage = var.vcd_org_ssd_sp

}

}

Paramètres principaux dans la description de la VM :

• nom — nom de la machine virtuelle,

• nom_vapp — nom du vApp dans lequel ajouter la nouvelle VM,

• nom_catalogue / nom_template — nom du catalogue et nom du modèle de machine virtuelle,

• profil_stockage — politique de stockage par défaut.

Paramètres du bloc réseau :

• type — type de réseau connecté,

• nom — à quel réseau virtuel connecter la VM,

• est_primaire — adaptateur réseau principal,

• mode_allocation_ip — mode d'allocation d'adresse MANUEL / DHCP / POOL,

• ip — adresse IP de la machine virtuelle, spécifions-la manuellement.

Bloc override_template_disk :

• tailleenmb — taille du disque de démarrage pour la machine virtuelle

• profil_stockage — politique de stockage pour le disque

Créons une deuxième VM avec la description du stockage de fichiers Nextcloud

ressource "vcd_vapp_vm" "nextcloud" {

nom_vapp = vcd_vapp.vapp.nom

nom = "nextcloud"

nom_catalogue = var.vcd_org_catalog

nom_template = var.vcd_template_os_centos7

profil_stockage = var.vcd_org_ssd_sp

mémoire = 8192

cpus = 1

cœurs_cpu = 1

réseau {

type = "org"

nom = vcd_network_routed.net.nom

est_primaire = true

type_adaptateur = "VMXNET3"

mode_allocation_ip = "MANUEL"

ip = var.vcd_edge_local_ip_nextcloud

}

override_template_disk {

type_bus = "paravirtual"

taille_en_mb = "32768"

numéro_bus = 0

numéro_unité = 0

profil_stockage = var.vcd_org_ssd_sp

}

}

resource "vcd_vm_internal_disk" "disk1" {

vapp_name = vcd_vapp.vapp.name

vm_name = "nextcloud"

bus_type = "paravirtual"

size_in_mb = "102400"

bus_number = 0

unit_number = 1

storage_profile = var.vcd_org_hdd_sp

allow_vm_reboot = true

depends_on = [ vcd_vapp_vm.nextcloud ]

}

Dans la section vcdvminternal_disk, nous allons décrire un nouveau disque virtuel qui se connecte à la machine virtuelle.

Explications concernant le bloc vcdvminternaldisk :

• bustype — type de contrôleur de disque

• sizeinmb — taille du disque

• busnumber / unitnumber — emplacement de connexion sur l'adaptateur

• profil_stockage — politique de stockage pour le disque

Nous allons décrire la dernière VM sur Bitrix

resource "vcd_vapp_vm" "bitrix" {

nom_vapp = vcd_vapp.vapp.nom

name = "bitrix"

nom_catalogue = var.vcd_org_catalog

nom_template = var.vcd_template_os_centos7

profil_stockage = var.vcd_org_ssd_sp

mémoire = 8192

cpus = 1

cœurs_cpu = 1

réseau {

type = "org"

nom = vcd_network_routed.net.nom

est_primaire = true

type_adaptateur = "VMXNET3"

mode_allocation_ip = "MANUEL"

ip = var.vcd_edge_local_ip_bitrix

}

override_template_disk {

type_bus = "paravirtual"

size_in_mb = "81920"

numéro_bus = 0

numéro_unité = 0

profil_stockage = var.vcd_org_ssd_sp

}

}

Mise à jour du système d'exploitation et installation de scripts supplémentaires

Le réseau est prêt, les machines virtuelles sont décrites. Avant d'importer notre infrastructure, nous pouvons effectuer un provisionnement initial à l'avance à l'aide des blocs provisioners, sans utiliser Ansible.

Voyons comment mettre à jour le système d'exploitation et lancer le script d'installation de CMS Bitrix à l'aide du bloc provisioner.

Tout d'abord, nous allons installer les paquets de mise à jour de CentOS.

resource "null_resource" "nginx_update_install" {

provisioner "remote-exec" {

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.nginx.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58301"

timeout = "30s"

}

inline = [

"yum -y update && yum -y upgrade",

"yum -y install wget nano epel-release net-tools unzip zip" ]

}

}

}

Désignation des composants :

• provisioner «remote-exec» — connexion au bloc de "provisioning" distant

• Dans le bloc connection, nous décrivons le type et les paramètres de connexion :

• type — le protocole, dans notre cas SSH ;

• user — le nom d'utilisateur ;

• password — le mot de passe de l'utilisateur. Dans notre cas, nous faisons référence au paramètre vcdvappvm.nginx.customization[0].admin_password, qui contient le mot de passe généré pour l'utilisateur du système.

• host — l'adresse IP externe pour la connexion ;

• port — le port de connexion que nous avons précédemment spécifié dans les paramètres DNAT ;

• inline — énumérer la liste des commandes qui seront exécutées. Les commandes seront exécutées dans l'ordre spécifié dans cette section.

À titre d'exemple, nous allons également exécuter le script d'installation de 1C-Bitrix. Le résultat de l'exécution du script sera disponible pendant l'exécution du plan. Pour installer le script, nous allons d'abord décrire le bloc :

Nous allons décrire l'installation de 1C-Bitrix.

provisioner "file" {

source = "prepare.sh"

destination = "\tmp\prepare.sh"

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.nginx.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58301"

timeout = "30s"

}

}

provisioner "remote-exec" {

inline = [

"chmod +x \tmp\prepare.sh", "\tmp\prepare.sh"

]

}

Et immédiatement décrire la mise à jour de Bitrix.

Exemple de provisioning 1C-Bitrix.

resource "null_resource" "install_update_bitrix" {

provisioner "remote-exec" {

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.bitrix.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58302"

timeout = "60s"

}

inline = [

"yum -y update && yum -y upgrade",

"yum -y install wget nano epel-release net-tools unzip zip",

"wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh -O /tmp/bitrix-env.sh",

"chmod +x /tmp/bitrix-env.sh",

"/tmp/bitrix-env.sh"

]

}

}

Important! The script may not work if SELinux is not disabled in advance! If you need a detailed article on installing and configuring the CMS 1C-Bitrix using bitrix-env.sh, you can use our article in the blog on the website.

3. Initializing infrastructure

Initializing modules and plugins

For this, we use a simple 'gentleman’s set': a laptop with Windows 10 and a distribution from the official site terraform.io. We will unpack and initialize it using the command: terraform.exe init

After describing the computing and network infrastructure, we launch planning to check our configuration, where we can see what will be created and how it is interconnected.

1. Execute the command - terraform plan -var-file=vcd.tfvars.

2. We get the result - Plan: 16 to add, 0 to change, 0 to destroy. This means that 16 resources will be created according to this plan.

3. We start the plan with the command - terraform.exe apply -var-file=vcd.tfvars.

Virtual machines will be created, and then the packages we listed in the provisioner section will be executed — the OS will be updated and the CMS Bitrix will be installed.

Getting connection data

After executing the plan, we want to get the connection data for the servers in text format, for this we will arrange the output section as follows:

output "nginxpassword" {

 value = vcdvappvm.nginx.customization[0].adminpassword

}

And the following output informs us of the password for the created virtual machine:

Outputs: nginx_password = F#4u8!!N

As a result, we gain access to virtual machines with the updated operating system and pre-installed packages for our further work. Everything is ready!

But what if you already have an existing infrastructure?

3.1. Working with Terraform on existing infrastructure

It's simple, you can import the current virtual machines and their vApp containers using the import command.

We will describe the vAPP resource and virtual machine.

resource "vcd_vapp" "Monitoring" {

name = "Monitoring"

org = "mClouds"

vdc = "mClouds"

}

resource "vcd_vapp_vm" "Zabbix" {

name = "Zabbix"

org = "mClouds"

vdc = "mClouds"

vapp = "Monitoring"

}

The next step is to import the properties of the vApp resources in the format vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, où :

• vApp — the name of vApp;

• org — the name of the organization;

• org_vdc — the name of the virtual data center.

Importing vAPP resource properties

We will import the properties of VM resources in the format: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, where:

• VM — the name of the VM;

• vApp — the name of vApp;

• org — the name of the organization;

• orgvdc — the name of the virtual data center.

L'importation a été réussie

C:UsersMikhailDesktopterraform>terraform import vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix

vcd_vapp_vm.Zabbix : Importation depuis l'ID "mClouds.mClouds.Monitoring.Zabbix"...

vcd_vapp_vm.Zabbix : Import préparé !

vcd_vapp_vm préparé pour l'importation

vcd_vapp_vm.Zabbix : Actualisation de l'état... [id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]

Importation réussie !

Les ressources qui ont été importées sont affichées ci-dessus. Ces ressources sont désormais dans
votre état Terraform et seront désormais gérées par Terraform.

Nous pouvons maintenant examiner la nouvelle ressource importée :

Ressource importée

> terraform show

...

# vcd_vapp.Monitoring:

resource "vcd_vapp" "Monitoring" {

guest_properties = {}

href = "https://vcloud.mclouds.ru/api/vApp/vapp-fe5db285-a4af-47c4-93e8-55df92f006ec"

id = "urn:vcloud:vapp:fe5db285-a4af-47c4-93e8-55df92f006ec"

ip = "alloué"

metadata = {}

name = "Monitoring"

org = "mClouds"

status = 4

status_text = "ALLUMÉ"

vdc = "mClouds"

}

…

# vcd_vapp_vm.Zabbix:

resource "vcd_vapp_vm" "Zabbix" {

computer_name = "Zabbix"

cpu_cores = 1

cpus = 2

expose_hardware_virtualization = false

guest_properties = {}

hardware_version = "vmx-14"

href = "https://vcloud.mclouds.ru/api/vApp/vm-778f4a89-1c8d-45b9-9d94-0472a71c4d1f"

id = "urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f"

internal_disk = [

{

numéro_bus = 0

type_bus = "paravirtual"

disk_id = "2000"

iops = 0

size_in_mb = 122880

storage_profile = "Politique de Stockage Or"

thin_provisioned = true

numéro_unité = 0

},

]

memory = 8192

metadata = {}

name = "Zabbix"

org = "mClouds"

os_type = "centos8_64Guest"

storage_profile = "Politique de Stockage Or"

vapp_name = "Monitoring"

vdc = "mClouds"


customization {

allow_local_admin_password = true

auto_generate_password = true

change_sid = false

enabled = false

force = false

join_domain = false

join_org_domain = false

must_change_password_on_first_login = false

number_of_auto_logons = 0

}

réseau {

adapter_type = "VMXNET3"

ip_allocation_mode = "DHCP"

is_primary = true

mac = "00:50:56:07:01:b1"

name = "MCLOUDS-LAN01"

type = "org"

}

}


C'est maintenant prêt — nous avons terminé avec le dernier point (import dans une infrastructure existante) et avons examiné tous les aspects principaux du travail avec Terraform. 

L'outil s'est révélé très pratique et permet de décrire votre infrastructure comme du code, allant des machines virtuelles d'un seul fournisseur de cloud à la description des ressources des composants réseau.

De plus, l'indépendance par rapport à l'environnement permet de travailler avec des ressources locales, cloud, et même de gérer une plateforme. En l'absence d'une plateforme prise en charge et si vous souhaitez en ajouter une nouvelle, vous pouvez écrire votre propre fournisseur et l'utiliser.

Source : habr.com