Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describe cuándo y por qué se deben crear plantillas de instancias deterministas. Las plantillas de instancias deterministas aclaran de forma explícita el tipo de servicios o apps de terceros que se deben instalar en las instancias cuando se implementa la plantilla de instancias. La creación de plantillas de instancias deterministas ayuda a minimizar la ambigüedad y el comportamiento inesperado de tus plantillas de instancia.
¿Por qué deberías crear plantillas de instancias deterministas?
En general, recomendamos que las propiedades de la plantilla de instancias sean lo más explícitas y deterministas posible. Si usas secuencias de comandos de inicio en las plantillas de instancias que instalan o usan servicios de terceros, asegúrate de que estas secuencias de comandos proporcionen información explícita, como la versión de la app que se instalará. Compute Engine solo puede confiar en la información definida en la plantilla y no tiene control sobre los servicios de terceros a los que se hace referencia. Si tu plantilla es poco precisa, tu plantilla de instancias podría comportarse de forma inesperada.
Por ejemplo, considera el comando siguiente para crear una plantilla de instancias con una secuencia de comandos de inicio que instale apache2 y use un archivo alojado en un servidor externo:
Hay dos problemas potenciales con esta secuencia de comandos de inicio:
La secuencia de comandos no define de forma explícita qué versión de apache2 se debe instalar y depende de la versión actual disponible en el repositorio de apt.
La secuencia de comandos depende de un archivo alojado en un tercero que no tiene versiones y se podría haber modificado desde la última vez que se usó la plantilla de instancias.
Si usas un escalador automático, puede que una plantilla de instancias no determinista haga que tu escalador automático agregue instancias nuevas a un grupo de instancias administrado con una configuración diferente, como una versión diferente de apache2.
De manera similar, si aplicaste esta plantilla a un grupo de instancias administrado, actualizaste el grupo a una plantilla diferente mediante el servicio del actualizador de grupos de instancias y, luego, decidiste revertir a la plantilla anterior, podrías acabar con instancias que usen una versión de apache2 o del archivo index.php distinta a la que tenías antes de la actualización, porque las instancias siempre buscarían la versión más reciente durante el inicio.
Evita el comportamiento ambiguo o inesperado de la plantilla de instancias
Para evitar un comportamiento inesperado de la plantilla, usa uno de los métodos siguientes:
Usa imágenes optimizadas de contenedor o Docker, con etiquetas Docker. Por ejemplo, te recomendamos que asignes etiquetas nuevas para cada compilación nueva de la imagen de Docker y las uses en las plantillas de instancias, en lugar de usar la última etiqueta predeterminada. En cuanto a una imagen optimizada de contenedor, puedes hacer referencia de forma explícita a una compilación particular de tu imagen en el archivo de manifiesto. En el ejemplo siguiente, se usa la imagen de Docker “myimage” en la versión con la etiqueta “version_2_1_3”:
Crea una imagen personalizada para usar como imagen de la plantilla. Esto es preferible a las secuencias de comandos de inicio porque garantiza que cada instancia sea la misma. Las secuencias de comandos de inicio pueden tener resultados diferentes después de las actualizaciones del paquete de distribución. Usa secuencias de comandos de inicio en tus plantillas de instancias para el prototipado y un desarrollo rápido. Usa imágenes personalizadas cuando estés listo y quieras implementar servicios con calidad de producción.
Si usas secuencias de comandos de inicio, considera actualizar tus secuencias de comandos para que sean deterministas. Por ejemplo, crea una versión nueva de la plantilla anterior y especifica una secuencia de comandos de inicio determinista de la manera siguiente:
En el ejemplo anterior, se ilustra lo siguiente: “version_2_1_3” es un subdirectorio que contiene secuencias de comandos PHP para la versión 2.1.3 del servicio.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-06-16 (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)."]]