L'équipe de cloud.ca a développé pour Terraform, un fournisseur fabriqué sur mesure, rendant possible l'automatisation des déploiements d'infrastructure sur la plateforme de cloud.ca. Terraform est un des nombreux outils de source libre offerts par HashiCorp, pour la gestion d'infrastructure. Il présente une approche vis-à-vis le déploiement d'environnements IaaS complexes compatible aux DevOps, ce qui augmente l'agilité et la flexibilité, particulièrement lorsqu'il s'agit de réutiliser les architectures de déploiement existantes. Vous pouvez télécharger le fournisseur cloud.ca ici : https://github.com/cloud-ca/terraform-provider-cloudca.
Apache CloudStack sert de plateforme d'orchestration sous-jacente à cloud.ca. Elle possède un fournisseur Terraform générique (dont nous parlons ici). Malgré cela, nous savions que nous pouvions ajouter de la valeur en développant notre propre fournisseur. Ce fournisseur sur mesure est plus en harmonie avec le concept de notre plateforme et des options de déploiements spécifiques, cela signifie que les utilisateurs peuvent automatiser des capacités particulières à cloud.ca via leur configuration Terraform. Par exemple, nous simplifions l'utilisation des projets CloudStack, paramètre qui autrement doit être fourni à répétition lors de l'utilisation du fournisseur générique de CloudStack. Comme avantage supplémentaire, avec Terraform, l'utilisateur unique peut accéder à la gestion de multiples environnements dans une organisation, et utiliser les mêmes identifiants, si les autorisations de cloud.ca le permettent.
La capacité de contrôler la couche « gestion » en utilisant la ressource « environnement » est un autre élément couvert par le fournisseur de cloud.ca qui ne peut être accompli par le fournisseur générique de CloudStack. Vous pouvez spécifier les détails du contrôle d'accès basé sur les rôles pour chaque utilisateur dans la configuration Terraform ou encore, créer de nouveaux environnements.
Configuration d'un environnement cloud.ca
Regardons une réelle configuration conçue pour le fournisseur de cloud.ca, disponible dans le répertoire suivant : https://github.com/cloud-ca/blog_post_cloudca_terraform_provider. Cette configuration créera un environnement et un NPV à 3 réseaux. Un réseau sera utilisé pour les processeurs frontaux, un pour les machines base de données et le dernier, pour une machine utilitaire.
Toutes les variables disponibles sont réunies dans un fichier nommé « variables.tf » et représentent toutes les options de personnalisation pouvant être appliquées dans la configuration. Voici un extrait du document :
# Provider credentials
variable "api_key" {}
# General variables
variable "is_production" {}
variable "frontend_count" {}
variable "backend_count" {}
# Environment
variable "service_code" {}
variable "organization_code" {}
variable "environment_name" {}
variable "environment_description" {
default = "Environment for %s workloads"
}
variable "admin" {
type = "list"
}
variable "read_only" {
type = "list"
}
variable "database_ports" {
default = [ 3306 ]
}
variable "web_ports" {
default = [ 80, 443 ]
}Pour commencer à utiliser cette configuration, créez le fichier « terraform.tfvars » avec toutes les variables qui ne peuvent pas être définies par défaut dans « variables.tf » (telles que vos clés d'API, la liste des utilisateurs de votre organisation que vous voulez ajouter à l'environnement, la liste complète des attributs requis est énumérée dans le fichier README) ou toute variable que vous souhaitez surclasser. Par exemple, si vous désirez ouvrir le port 8080 à la place de 80 et de 443, vous n'avez qu'à l'ajouter au fichier « terraform.tfvars ».
web_ports = [ 8080 ]Et pour spécifier les droits d'accès de chacun :
admin_role = [ "clement", "mike" ]
read_only_role = [ ]Regardez maintenant le fichier « main.tf ». Il configure un environnement : « cloudca_environment » avec une liste d'utilisateurs dans les rôles suivants : « admin_role » et « read_only_role ». Ces rôles doivent être spécifiés dans le fichier « terraform.tfvars » (il n'y a pas de rôles par défaut de fournis, vous devez utiliser les utilisateurs de votre propre organisation).
resource "cloudca_environment" "default" {
service_code = "${var.service_code}"
organization_code = "${var.organization_code}"
name = "${var.environment_name}"
description = "${format("${var.environment_description}", "${var.environment_name}")}"
admin_role = ["${var.admin}"]
read_only_role = ["${var.read_only}"]
}Cela signifie aussi que si vous avez plusieurs environnements semblables, par exemple, un environnement de production et un environnement de développement, vous pouvez utiliser la même configuration pour les deux et ne changer que les variables « admin » et « read_only » pour les valeurs appropriées afin de limiter l'accès à l'environnement de production, mais de permettre l'accès intégral à l'environnement de développement.
Une des variables requises dans le fichier « terraform.tfvars » est l'opérateur booléen « is_production ». Lorsqu'elles sont définies comme « true », ses règles de la liste de contrôle d'accès sont plus rigoureuses :
- Le protocole d'accès SSH ne peut être ouvert que de la machine virtuelle utilitaire.
- La partie frontale est mise sur la liste blanche pour accéder au réseau de la base de données, tout le reste est refusé.
Par exemple, l'extrait de configuration suivant traite des règles de création de la liste de contrôle d'accès pour le réseau de la base de données :
resource "cloudca_network_acl_rule" "db_allow_in_ports" {
environment_id = "${cloudca_environment.default.id}"
count = "${var.is_production ? var.frontend_count * length(var.database_ports) : 1}"
rule_number = "${10 + count.index + 1}"
action = "Allow"
protocol = "TCP"
start_port = "${element(var.database_ports, count.index % length(var.database_ports))}"
end_port = "${element(var.database_ports, count.index % length(var.database_ports))}"
cidr = "${var.is_production ?
"${element(cloudca_instance.web_instance.*.private_ip, count.index)}/32" : "0.0.0.0/0" }"
traffic_type = "Ingress"
network_acl_id = "${cloudca_network_acl.db_acl.id}"
}Selon si l'environnement est de production ou non, Le CIDR de la liste de contrôle d'accès sera différent : ouvert à 0.0.0.0/0 pour l'environnement de développement, extrait des instances de réseau web de production. Les ports sont aussi configurables et sont choisis de la liste de variables fournie.
Intégration avec les outils de la plateforme cloud.ca
Le fournisseur Terraform de cloud.ca tire directement profit des fonctionnalités intégrées à la plateforme, comme le journal des activités. Toute action effectuée lors de l'utilisation du fournisseur Terraform de cloud.ca apparaitra dans le journal des activités. Si vous déployez la configuration citée en exemple, vous verrez les différentes actions qui sont effectuées.
Exemple de journal des activités sur cloud.ca
Nous améliorons et développons continuellement le fournisseur Terraform de cloud.ca. Prochainement, un élément à court terme sur la feuille de route donnera la capacité d'exporter une configuration Terraform d'un environnement cloud.ca existant. De cette façon, si l'environnement a été conçu manuellement et que l'utilisateur désire le reproduire facilement (au niveau du plan de l'infrastructure) il serait possible de simplement appuyer sur un bouton, d'obtenir la configuration Terraform et de l'utiliser pour créer un environnement semblable.
Pour conclure, nous sommes convaincus que Terraform est un excellent outil à utiliser avec cloud.ca, car :
- Il utilise un puissant logiciel de source libre permettant l'automatisation.
- Il permet la mise à l'échelle semi-automatique, c'est-à-dire que, lorsque vos besoins changent, il devient très facile de modifier le nombre d'instances du même type grâce à de petits ajustements dans la définition de ressource, rendant la mise à l'échelle horizontale simple et rapide.
- Il permet aux utilisateurs d'automatiser le déploiement de leurs environnements ainsi que les autorisations aux utilisateurs associés.
- Il permet aux utilisateurs d'uniformiser leurs déploiements et de réutiliser des configurations à travers ceux-ci.
- Il peut être utilisé sur cloud.ca pour déployer le même environnement dans différentes zones, par exemple, il aide à la création de scénarios géographiquement variés ou de reprise après sinistre.
- Comme complément, l'application de configuration peut être orchestrée avec des outils tels que Chef ou Docker, ce qui facilite le déploiement de conteneurs et en fait un outil idéal pour le déploiement d'applications issues du nuage.
Cliquez ici pour essayer cloud.ca gratuitement pendant 10 jours.
