Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina descrive quando e perché creare template di istanza
deterministici. I template di istanza deterministici chiariscono esplicitamente
il tipo di app o servizi di terze parti da installare sulle
istanze al momento del deployment del template di istanza. Creando template di istanza deterministici,
riduci al minimo l'ambiguità e i comportamenti imprevisti dei
template di istanza.
Perché creare template di istanza deterministici
In generale, consigliamo che le proprietà del template di istanza siano
il più esplicite e deterministiche possibile. Se utilizzi script
di avvio nei template di istanza che installano o utilizzano servizi di terze parti,
assicurati che questi script forniscano informazioni esplicite, ad esempio la
versione dell'app da installare. Compute Engine può fare affidamento solo sulle
informazioni definite nel template e non ha alcun controllo sui servizi di terze parti
a cui si fa riferimento. Se il template è troppo vago, il template di istanza
potrebbe comportarsi in modo imprevisto.
Ad esempio, considera il seguente comando per creare un template di istanza con
uno script di avvio che installa apache2 e utilizza un file ospitato su un
server esterno:
Esistono due potenziali problemi con questo script di avvio:
Lo script non definisce esplicitamente quale versione di apache2 installare
e si basa sulla versione corrente disponibile nel repository apt.
Lo script si basa su un file ospitato su una terza parte che non è sottoposto a controllo delle versioni e
potrebbe essere stato modificato dall'ultima volta che è stato utilizzato il template di istanza.
Se utilizzi un gestore della scalabilità automatica, un template di istanza
non deterministico può causare l'aggiunta da parte del gestore della scalabilità automatica di nuove istanze a un
gruppo di istanze gestite con una configurazione
diversa, ad esempio una versione diversa di apache2.
Analogamente, se hai applicato questo template a un gruppo di istanze gestite, hai aggiornato
il gruppo con un servizio di template diverso
e poi hai deciso di eseguire il rollback al template precedente, potresti ritrovarti
con istanze che utilizzano una versione diversa di apache2 o del file index.php
rispetto a prima dell'aggiornamento perché le istanze recupereranno sempre la versione
più recente all'avvio.
Evitare comportamenti ambigui o imprevisti dei template di istanza
Per evitare comportamenti imprevisti del template, utilizza uno dei seguenti metodi:
Utilizza immagini ottimizzate per i container o Docker
con i tag Docker. Ad esempio, ti consigliamo di assegnare nuovi tag
per ogni nuova build dell'immagine Docker e di utilizzarli nei template
di istanza al posto del tag più recente predefinito. Per un'immagine ottimizzata per i container,
puoi fare riferimento esplicitamente a una determinata build dell'immagine nel file
manifest. L'esempio seguente utilizza l'immagine Docker "myimage" nella versione con tag
"version_2_1_3":
Crea un'immagine personalizzata
da utilizzare come immagine per il template. Questa soluzione è preferibile agli script di avvio
perché garantisce che ogni istanza sia uguale. Gli script di avvio potrebbero
avere risultati diversi dopo gli aggiornamenti del pacchetto di distribuzione. Utilizza gli script di avvio
nei template di istanza per la prototipazione e lo sviluppo rapido e utilizza
le immagini personalizzate quando è tutto pronto per eseguire il deployment di servizi di qualità elevata.
Se utilizzi script di avvio, valuta la possibilità di aggiornarli in modo che siano
deterministici. Ad esempio, crea una nuova versione del template precedente e
specifica uno script di avvio deterministico come segue:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-08-08 UTC."],[[["\u003cp\u003eDeterministic instance templates ensure clarity on the third-party services or apps installed on instances during deployment, minimizing ambiguity.\u003c/p\u003e\n"],["\u003cp\u003eUsing explicit versioning in startup scripts, such as specifying the exact version of Apache2 to install, helps avoid unexpected behavior due to changes in third-party services.\u003c/p\u003e\n"],["\u003cp\u003eNon-deterministic templates can cause autoscalers to deploy instances with varying configurations, such as different software versions, potentially leading to inconsistencies.\u003c/p\u003e\n"],["\u003cp\u003eTo maintain consistency and predictability, use container-optimized images with specific Docker tags, or create custom images instead of relying heavily on startup scripts.\u003c/p\u003e\n"],["\u003cp\u003eWhen using startup scripts, make them deterministic by specifying exact versions of software and files, like \u003ccode\u003eapache2=2.2.20-1ubuntu1\u003c/code\u003e, and versioned directories for hosted files.\u003c/p\u003e\n"]]],[],null,["# Deterministic instance templates\n\n*** ** * ** ***\n\nThis page describes when and why to create deterministic instance\ntemplates. Deterministic instance templates make explicitly clear\nthe type of third-party services or apps to install on\nyour instances when the instance template is deployed. By creating deterministic\ninstance templates, you minimize ambiguity and unexpected behavior from your\ninstance templates.\n\nWhy create deterministic instance templates\n-------------------------------------------\n\nIn general, we recommend that the properties of your instance template be as\nexplicit and deterministic as possible. If you employ startup\nscripts in your instance templates that install or use third-party services,\nmake sure that these scripts provide explicit information, such as the\nversion of app to install. Compute Engine can only rely on\ninformation defined in the template and has no control over referenced\nthird-party services. If your template is too vague, your instance template\nmight behave unexpectedly.\n\nFor example, consider the following command to create an instance template with\na startup script that installs apache2 and uses a file that is hosted on an\nexternal server:\n**Note:** This is just an example snippet pointing to a non-existent server at 108.59.87.185. Copying this example directly fails when the script attempts to connect to 108.59.87.185. Instead, replace the last line with your own server information, if applicable. \n\n gcloud compute instance-templates create example-template-with-startup \\\n --image-family debian-9 \\\n --image-project debian-cloud \\\n --metadata startup-script='#! /bin/bash\n sudo apt install -y apache2\n scp myuser@108.59.87.185:index.php /var/www/'\n\nThere are two potential issues with this startup script:\n\n- The script does not explicitly define which version of apache2 to install, and relies on the current version available in the `apt` repository.\n- The script relies on a file hosted on a third-party that isn't versioned and could have been changed since the last time the instance template was used.\n\nIf you use an [autoscaler](/compute/docs/autoscaler), a non-deterministic\ninstance template can cause your autoscaler to add new instances to a\n[managed instance group](/compute/docs/instance-groups) with a different\nconfiguration, such as a different version of apache2.\n\nSimilarly, if you applied this template to a managed instance group, [updated\nthe group to a different template](/compute/docs/instance-groups/updating-migs)\nservice, and then decided to roll back to the previous template, you might end\nup with instances that use a different version of apache2 or index.php file\nthan before the update because your instances would always fetch the most recent\nversion at startup.\n\nAvoiding ambiguous or unexpected instance template behavior\n-----------------------------------------------------------\n\nTo avoid unexpected template behavior, use the following methods:\n\n- Use [container-optimized images](/compute/docs/containers/container_vms) or\n Docker, with Docker tags. For example, we recommend that you assign new tags\n for every new build of your Docker image, and use these tags in your instance\n templates instead of the default latest tag. For a container-optimized image,\n you can explicitly reference a particular build of your image in your manifest\n file. The example below uses Docker image \"myimage\" at version tagged with\n \"version_2_1_3\":\n\n version: v1beta2\n containers:\n - name: simple-echo\n image: myimage:version_2_1_3\n [ rest of your manifest file ]\n\n- [Create a custom image](/compute/docs/images/create-delete-deprecate-private-images)\n to use as the image for the template. This is preferable to startup scripts\n because it guarantees that every instance is the same. Startup scripts might\n have different results after distribution package updates. Use startup scripts\n in your instance templates for prototyping and rapid development, and use\n custom images when you are ready to deploy production-quality services.\n\n- If you do use startup scripts, consider updating your scripts to be\n deterministic. For example, create a new version of the previous template, and\n specify a deterministic startup script as follows:\n\n gcloud compute instance-templates create example-template-with-startup-2-1-3 \\\n --image-family debian-9 \\\n --image-project debian-cloud \\\n --metadata startup-script='#! /bin/bash\n sudo apt install -y apache2=2.2.20-1ubuntu1\n scp myuser@108.59.87.185:version_2_1_3/index.php /var/www/'\n\n where \"version_2_1_3\" is a subdirectory containing PHP scripts for the\n version 2.1.3 of your service.\n- When specifying an instance template---for example when you are creating or\n updating a managed instance group---Google recommends that you specify the\n template's ID value instead of its name value. Although both values are valid,\n the ID is unique, which means that the instance template that you specify is\n the one that is used when creating VMs from that instance template. Using an\n ID instead of a name helps to mitigate potential security vulnerabilities---for\n example,\n [TOCTOU](https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use_vulnerability)\n vulnerabilities, where an attacker can delete a template and recreate it with\n the same name prior to its use.\n\n To view the ID of an instance template, see\n [Get information about an instance template](/compute/docs/instance-templates/get-list-delete-instance-templates#get_information_about_an_instance_template).\n\nWhat's next\n-----------\n\n- [Create an instance template](/compute/docs/instance-templates/create-instance-templates).\n- [Manage your instance templates](/compute/docs/instance-templates/get-list-delete-instance-templates)."]]