이 페이지에서는 확정 인스턴스 템플릿을 만들어야 하는 경우와 이유를 설명합니다. 확정 인스턴스 템플릿을 사용하면 인스턴스 템플릿을 배포할 때 인스턴스에 설치해야 하는 타사 서비스 또는 앱의 유형을 명확하게 알 수 있습니다. 확정 인스턴스 템플릿을 만들면 인스턴스 템플릿의 모호성과 예기치 않은 동작을 최소화할 수 있습니다.
확정 인스턴스 템플릿을 만드는 이유
일반적으로 인스턴스 템플릿의 속성은 최대한 명시적이고 확정적인 것이 좋습니다. 타사 서비스를 설치하거나 사용하는 시작 스크립트를 인스턴스 템플릿에 사용하는 경우 이러한 스크립트가 설치할 앱의 버전과 같은 명시적인 정보를 제공하는지 확인하세요. Compute Engine은 템플릿에 정의된 정보에만 의존하며 참조된 타사 서비스를 제어할 수 없습니다. 템플릿이 너무 모호하면 인스턴스 템플릿이 예상과 다르게 작동할 수 있습니다.
예를 들어 apache2를 설치하고 외부 서버에서 호스팅되는 파일을 사용하는 시작 스크립트로 인스턴스 템플릿을 만들려면 다음 명령어를 사용할 수 있습니다.
스크립트가 설치할 apache2의 버전을 명시적으로 정의하지 않으며 apt 저장소에서 사용할 수 있는 현재 버전을 사용합니다.
스크립트가 버전이 관리되지 않고 인스턴스 템플릿을 마지막으로 사용한 이후로 변경되었을 수 있으며 타사에서 호스팅하는 파일에 의존합니다.
autoscaler를 사용하는 경우 비확정 인스턴스 템플릿으로 인해 자동 확장 처리가 관리형 인스턴스 그룹에 새 인스턴스를 다른 구성(예: 다른 버전의 apache2)으로 추가할 수 있습니다.
마찬가지로 이 템플릿을 관리형 인스턴스 그룹에 적용하고 그룹을 다른 템플릿 서비스로 업데이트한 후 이전 템플릿으로 롤백하기로 결정할 경우 인스턴스가 업데이트 전과 다른 버전의 apache2 또는 index.php 파일을 사용하게 될 수 있습니다. 이는 인스턴스가 시작 시 항상 최신 버전을 가져오기 때문입니다.
모호하거나 예기치 않은 인스턴스 템플릿 동작 방지
예기치 않은 템플릿 동작을 방지하려면 다음 방법 중 하나를 사용하세요.
컨테이너 최적화 이미지나 Docker(Docker 태그 포함)를 사용합니다. 예를 들어 Docker 이미지의 모든 새 빌드에 새 태그를 할당하고 이 태그를 기본 최신 태그 대신 인스턴스 템플릿에 사용하는 것이 좋습니다. 컨테이너 최적화 이미지의 경우 매니페스트 파일에서 이미지의 특정 빌드를 명시적으로 참조할 수 있습니다. 아래 예에서는 'version_2_1_3' 태그로 지정된 버전의 Docker 이미지 'myimage'를 사용합니다.
템플릿의 이미지로 사용할 커스텀 이미지를 만듭니다. 이 방법을 사용하면 모든 인스턴스가 동일해지므로 시작 스크립트보다 더 좋습니다. 시작 스크립트는 배포 패키지 업데이트 후 결과가 달라질 수 있습니다. 프로토타입 제작 및 신속한 개발을 위한 인스턴스 템플릿에는 시작 스크립트를 사용하고, 프로덕션 품질 서비스를 배포할 준비가 되면 커스텀 이미지를 사용하세요.
시작 스크립트를 사용하는 경우 스크립트를 확정적으로 업데이트하는 것이 좋습니다. 예를 들어 이전 템플릿의 새 버전을 만들고 다음과 같이 확정 시작 스크립트를 지정합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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)."]]
