Cet article est le troisième d’une série. Si tu as manqué les deux premiers, les voici:
Créer une infrastructure en tant que code dans GCP avec Consul et Terraform : Les premières étapes vers l’automatisation DevOps
Créer une infrastructure en tant que code dans GCP avec Packer et Terraform : la deuxième étape vers l’automatisation DevOps

Cette semaine en Californie, j’ai libéré le geek en moi au Google Next 18, je me suis emparé d’un Chromebook de la part de l’équipe Grab-and-Go (formidable initiative) et j’ai décidé de terminer la trilogie sur l’Infrastructure en tant que Code (IaC).

Les deux articles précédents étaient axés sur l’Infrastructure en tant que code, où Terraform était perçu comme un couteau suisse aux capacités multinuages. Mais que faire si l’on veut tirer profit d’un service de déploiement d’infrastructure infonuagique précis ?

La Plateforme Infonuagique Google Google Cloud Platform (GCP) possède un tel outil appelé gestionnaire de déploiement (Deployment Manager). Le gestionnaire de déploiement s’exécute sur les bases de fichiers de configuration (YAML) et de modèles (JINJA2 ou PYTHON), vous permettant de définir vos ressources. Ce gestionnaire de déploiement est un outil qui ne se trouve que sur la plateforme GCP, cela vous permet d’accéder aux fonctionnalités tant Beta qu’alpha.

Pour le présent article, comme pour le premier, je vais présenter un petit modèle de gestionnaire de déploiement ; aussi, je vais réviser la version de gestionnaire de déploiement du modèle Terraform plus grand contenu dans mon deuxième article. Tout ceci est conçu pour fonctionner dans la région NorthAmerica-NorthEast-1.

Condition préalable :

AUCUNE !!!!  Simplement, utilisez GCP Cloud Shell sur la plateforme Google pour exécuter tous ces exemples dans le nuage Google Cloud.

Simple, mais efficace

Créer une seule instance dans la région NorthAmerica-NorthEast1-a basée sur la dernière image Ubuntu-1804-LTS, une adresse IP externe.

resources:


name: my-first-vm
type: compute.v1.instance
properties:
zone: northamerica-northeast1-a
machineType: https://www.googleapis.com/compute/v1/projects/your_project_name/zones/northamerica-northeast1-a/machineTypes/f1-micro
disks:

deviceName: boot
type: PERSISTENT
boot: true
autoDelete: true
initializeParams:
sourceImage: https://www.googleapis.com/compute/v1/projects/ubuntu-os-cloud/global/images/family/ubuntu-1804-lts
networkInterfaces:
network: https://www.googleapis.com/compute/v1/projects/your_project_name/global/networks/default
accessConfigs:

name: External NAT
type: ONE_TO_ONE_NAT

Une fois votre modèle crée, vous n’avez qu’à l’exécuter de l’endroit où vous avez installé le Google Cloud SDK ou alors, de mon endroit préféré, la plateforme GCP Cloud Shell.

gcloud deployment-manager deployments create my-first-dm –config my_first_vm.yaml

Vous pouvez visualiser votre déploiement dans la console GCloud Console sous Deployment Manager et l’instance, sous Compute Engine/VM instances. Vous pouvez aussi voir les détails de votre nouveau déploiement avec :

gcloud deployment-manager deployments describe my-first-dm

C’est un exemple simple qui peut vous sembler familier si vous utilisez Terraform. Maintenant, nettoyons le tout et voyons plus grand.

gcloud deployment-manager deployments delete my-first-dm

Allons-y à fond ou restons à la maison

Prenons mon deuxième article comme base, nous allons recréer le même concept, mais dans le gestionnaire de déploiement (sauf pour l’image figée avec Packer).

Figeons notre image dorée

1. Saisissez l’information de votre « service account » en suivant les étapes présentées dans mon premier article (Étapes 2 et 3)
   1. Assurez-vous d’avoir les rôles suivants : (Compute Admin, Service Account User, Storage Admin).
2. Saisissez le code de mon dépôt https ://github.com/sveronneau/gcp-dm
3. Saisissez l’information de votre comte GCP pour mettre à jour le fichier apache.json.
4. Installez Packer
5. Figez

packer validate gcp-dm/apache.jon
packer build gcp-dm/apache.json

Créons notre infrastructure immuable

Étape 1 : Créer notre modèle d’instance, notre groupe d’instances géré et notre politique de mise à l’échelle automatique.

Nous créons un modèle d’instance appelé « apache-template » avec une étiquette appelée « webserver », ce modèle est lié à une micro machine de type f1 utilisant l’image d’Apache family que nous avons figée avec Packer. Nous avons aussi injecté des métadonnées pour un script de démarrage ; cela préparera une page Web d’Apache vers votre serveur. Vous trouverez mon dépôt GitHub ici.

IMPORTANT : Assurez-vous de changer la valeur de you_project pour SourceImage et network pour qu’il reflète votre ID de projet avant d’exécuter celui-ci.
https://github.com/sveronneau/gcp-dm/blob/master/instance-template-mig.yaml

gcloud deployment-manager deployments create apache –config instance-template-mig.yaml

Étape 2 : Créer une règle pare-feu et un bilan de santé

Créer des règles pare-feu soutenant HTTP, HTTPS, SSH et Ping, seulement pour les instances ayant l’étiquette « webserver » ; créer un bilan de santé pour l’équilibreur de charge qui suit.

https://github.com/sveronneau/gcp-dm/blob/master/firewall-rules.yaml

https://github.com/sveronneau/gcp-dm/blob/master/hc.yaml

gcloud deployment-manager deployments create firewall –config firewall-rules.yaml
gcloud deployment-manager deployments create healthcheck –config hc.yaml

Étape 3 : Créer l’équilibreur de charge

La dernière étape est de créer les éléments nécessaires afin d’exposer notre groupe d’instances à l’Internet par une adresse IP publique liée à un équilibreur de charge et des règles de transmission.

1. Service dorsal
   1. Carte montrant l’emplacement de mon groupe d’instances géré pour le trafic HTTP sur le port 80.
2. Mandataire et carte de l’URL
   1. Régler à la valeur par défaut, rien de compliqué, afin que tout le trafic de l’URL/se rende au service dorsal que nous venons de créer.
   2. Acheminer un nouveau mandataire vers cette carte URL.
3. Adresse IP publique
   1. Réservons une adresse IP publique pour notre équilibreur de charge
4. Règles de transmission
   1. Définir une règle générale qui acheminera tout le trafic vers le port 80.

https://github.com/sveronneau/gcp-dm/blob/master/LoadBalancer.yaml

gcloud deployment-manager deployments create load-balancer –config LoadBalancer.yaml

Étape 4 : Régler le Named Port dans le groupe d’instance géré, mais avec une commande GCLOUD

*= Afin de permettre à ce groupe d’instances de recevoir le trafic provenant de l’équilibreur de charge apache-url-map, tracez le nom de port http vers un numéro de port.

Vous allez peut-être recevoir un avertissement, dans votre groupe d’instances géré, concernant le nom et le numéro du port. Afin de régler le problème, simplement exécutez la commande suivante dans votre Cloud Shell :

gcloud compute instance-groups set-named-ports apache-mig –named-ports http:80 –zone northamerica-northeast1-a

Étape 5 : Visualiser les déploiements

Une fois que tous les déploiements sont effectués, vous pouvez voir les instances, le groupe d’instances géré, les adresses IP publiques, les services dorsaux et frontaux, l’équilibreur de charge et les déploiements, le tout sur la console GCP.

Voici ce à quoi ressemble le gestionnaire de déploiement de la console GCP, une fois que nous avons terminé :

Si vous cliquez sur l’un des déploiements, comme l’équilibreur de charge, vous verrez tous ses détails et configurations.

Étape 6 : Essayons-le

Maintenant que tout est déployé, procurez-vous une adresse IP publique sous : Network services / Load Balancing. Lorsque vous êtes dans cette section de la console GCP, cliquez sur apache-url-map et sur FRONTEND à côté de HTTP. Vous verrez l’adresse IP publique que nous avons demandée auparavant.

Pointez votre navigateur sur http://public_ip et vous devriez voir un petit site Internet vous indiquant vers quel serveur de votre groupe d’instances géré se dirige votre requête. Cela peut prendre quelques minutes puisque nous devons nous assurer que l’équilibreur de charge est approvisionné et fonctionne adéquatement dans la plateforme GCP.

Lorsque le site répond, allez-y et actualisez comme bon vous semble ; vous verrez votre requête en plein équilibrage de charge entre les nœuds.

C’est terminé !

Voilà, vous avez maintenant un déploiement de notre site Internet complètement prédéfini, avec capacités de mise à l’échelle et d’équilibrage de charge automatiques (saturez votre groupe d’instances géré et regardez-le croître) et tout cela, crée avec le gestionnaire de déploiement.

N’oubliez pas de tout nettoyer !

Maintenant, allez de l’avant et automatisez tous les objets !

Grâce à ces trois articles de blogue, vous voyez les fondements de ce que peut être une infrastructure immuable. Vous faciliterez grandement votre vie en mettant en œuvre ces principes et méthodologies dans la gestion du cycle de vie de votre application. J’espère que vous avez trouvé utiles ces articles sur la mise en œuvre de l’infrastructure en tant que code et qu’ils vous aideront à atteindre le nirvana DevOps.
CloudOps offre des solutions DevOps et détient un large éventail d’expertises. Jetez un coup d’œil à nos ateliers pratiques sur l’Infrastructure en tant que Code, et contactez-nous pour en apprendre plus sur notre expertise et sur ce que nous pouvons faire pour votre organisation.

Créer une infrastructure en tant que code dans GCP avec Consul et Terraform : Les premières étapes vers l’automatisation DevOps

Créer une infrastructure en tant que code dans GCP avec Packer et Terraform : la deuxième étape vers l’automatisation DevOps

Stacy Véronneau

Stacy Véronneau est un éminent architecte de solutions chez CloudOps, il travaille de près avec la plateforme infonuagique de Google : Google Cloud Platform (GCP). Il collabore actuellement avec Google afin d’aider les clients à migrer vers GCP et tirer pleinement avantage de sa force. De plus, il est ambassadeur officiel OpenStack, il a donné des conférences lors de Sommets OpenStack et a organisé des meetups à travers le Canada.

Photo credits: Emma De Angelis et memegenerator.net