Modèles d'instances déterministes

Cette page décrit quand et pourquoi créer des modèles d'instances déterministes. Les modèles d'instances déterministes décrivent clairement le type de services ou d'applications tiers à installer sur vos instances, lorsque le modèle d'instance est déployé. En créant des modèles d'instances déterministes, vous réduisez le comportement ambigu ou inattendu de vos modèles d'instances.

Pourquoi créer des modèles d'instances déterministes ?

En général, il vaut mieux que les propriétés de votre modèle d'instance soient aussi explicites et déterministes que possible. Si vous utilisez des scripts de démarrage dans vos modèles d'instances, qui installent ou utilisent des services tiers, assurez-vous que ces scripts fournissent des informations explicites, comme la version de l'application à installer. Compute Engine ne peut s'appuyer que sur les informations définies dans le modèle et n'a aucun contrôle sur les services tiers référencés. Si votre modèle est trop vague, votre modèle d'instance peut se comporter de manière inattendue.

Prenons comme exemple la commande suivante, qui permet de créer un modèle d'instance avec un script de démarrage, qui installe apache2 et utilise un fichier hébergé sur un serveur externe :

gcloud compute instance-templates create example-template-with-startup \
    --image-family debian-9 \
    --image-project debian-cloud \
    --metadata startup-script='#! /bin/bash
    sudo apt install -y apache2
    scp myuser@108.59.87.185:index.php /var/www/'

Ce script de démarrage présente deux problèmes potentiels :

  • Le script ne définit pas explicitement la version d'Apache2 à installer et s'appuie sur la version actuelle disponible dans le dépôt apt.
  • Le script repose sur un fichier hébergé sur une ressource tierce, qui ne gère pas les versions et qui a pu être modifié depuis la dernière utilisation du modèle d'instance.

Si vous utilisez un autoscaler, un modèle d'instance non déterministe peut conduire votre autoscaler à ajouter de nouvelles instances à un groupe d'instances géré, avec une configuration différente, comme une version différente d'Apache2.

De même, si vous avez appliqué ce modèle à un groupe d'instances géré, mis à jour le groupe avec un autre service de modèle, puis décidé de revenir au modèle précédent, vous risquez de vous retrouver avec des versions d'apache2 ou du fichier index.php différentes de celles précédant la mise à jour, car vos instances récupéreront toujours la version la plus récente au démarrage.

Éviter un comportement ambigu ou inattendu du modèle d'instance

Pour éviter un comportement inattendu du modèle, utilisez les méthodes suivantes:

  • Utilisez des images optimisées pour les conteneurs ou des images Docker, avec des tags Docker. Par exemple, nous vous recommandons d'attribuer de nouveaux tags à chaque nouvelle version de votre image Docker et d'utiliser ces tags dans vos modèles d'instances, plutôt que le dernier tag par défaut. Pour une image optimisée pour les conteneurs, vous pouvez explicitement référencer une version particulière de votre image dans votre fichier manifeste. L'exemple ci-dessous utilise l'image Docker "myimage", avec le tag de version "version_2_1_3" :

    version: v1beta2
containers:
  - name: simple-echo
    image: myimage:version_2_1_3
       [ rest of your manifest file ]

  • Créez une image personnalisée qui servira d'image pour le modèle. Cette méthode est préférable aux scripts de démarrage, car elle garantit la constance des instances. Les scripts de démarrage peuvent engendrer des résultats différents après les mises à jour du paquet de distribution. Utilisez des scripts de démarrage dans vos modèles d'instances pour le prototypage et le développement rapide, et utilisez des images personnalisées lorsque vous êtes prêt à déployer des services de production professionnels.

  • Si vous utilisez des scripts de démarrage, envisagez de les mettre à jour pour qu'ils soient déterministes. Par exemple, créez une autre version du modèle précédent et spécifiez un script de démarrage déterministe comme suit :

    gcloud compute instance-templates create example-template-with-startup-2-1-3 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --metadata startup-script='#! /bin/bash
    sudo apt install -y apache2=2.2.20-1ubuntu1
    scp myuser@108.59.87.185:version_2_1_3/index.php /var/www/'

    Où "version_2_1_3" correspond à un sous-répertoire contenant des scripts PHP pour la version 2.1.3 de votre service.

  • Lorsque vous spécifiez un modèle d'instance (par exemple, lorsque vous créez ou mettez à jour un groupe d'instances géré), Google vous recommande de spécifier la valeur d'ID du modèle plutôt que sa valeur de nom. Bien que les deux valeurs soient valides, l'ID est unique, ce qui signifie que le modèle d'instance que vous spécifiez est celui qui est utilisé lors de la création de VM à partir de ce modèle d'instance. L'utilisation d'un ID au lieu d'un nom permet de limiter les failles de sécurité potentielles, par exemple les failles TOCTOU, dans lesquelles un pirate informatique peut supprimer un modèle et le recréer avec le même nom avant son utilisation.

    Pour afficher l'ID d'un modèle d'instance, consultez la section Obtenir des informations sur un modèle d'instance.

Étapes suivantes