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 l'une des 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.