SIGTERM을 처리하면 컨테이너가 종료되기 전에 로그 삭제와 같은 필요한 정리 작업을 수행할 수 있습니다. 컨테이너가 SIGTERM을 포착하지 못하더라도 10초 동안 이러한 태스크를 수행할 수 있으며, 이 10초에 대한 요금이 청구될 수 있습니다.
컨테이너가 SIGTERM을 처리하는지 확인하는 방법
컨테이너에 SIGTERM 핸들러가 설치되어 있는지 확인하려면 다음 안내를 따르세요.
Cloud Shell을 시작합니다. 현재 문서 페이지의 헤더에서 Cloud Shell 활성화를 확인할 수 있습니다. 승인 후 프로비저닝될 때까지 기다려야 할 수도 있습니다.
또는 독립형 세션을 시작합니다.
Cloud Shell에서 로컬로 컨테이너를 실행합니다.
docker run IMAGE_URL
IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
Cloud Shell에서 다른 탭을 열고 현재 Cloud Shell 세션에서 실행 중인 컨테이너 목록을 가져옵니다.
docker container ls
이 명령어에서 반환된 컨테이너 ID를 찾아야 합니다.
컨테이너 ID를 사용하여 컨테이너에 SIGTERM 신호 전송
docker kill -s SIGTERM CONTAINER_ID
docker run을 호출한 탭으로 돌아가서 컨테이너가 종료(중지)되었는지 확인합니다. SIGTERM 신호로 인해 컨테이너가 종료되면 컨테이너가 SIGTERM을 처리하는 것입니다.
SIGTERM 처리 방법
컨테이너가 SIGTERM을 처리하지 않는 경우 SIGTERM 핸들러를 추가하는 가장 간단한 방법은 tini로 서비스를 래핑하는 것입니다. 이렇게 하면 서비스가 컨테이너 init 프로세스의 역할을 하는 tini의 하위 프로세스로 실행됩니다.
자세한 내용은 Docker 안내를 참조하세요.
[[["이해하기 쉬움","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-07-24(UTC)"],[],[],null,["# About service execution environments\n\n*Cloud Run services* by default don't have an execution environment\nspecified, which means Cloud Run selects the execution environment\nbased on the features used. So unless you specify an execution environment for\nyour service, Cloud Run can select either the first\ngeneration or second generation environment.\n\nNote that Cloud Run jobs only use the second generation\nexecution environment, and this cannot be changed for jobs.\n\nThe first generation execution environment features fast [cold start](/run/docs/tips/general#using_minimum_instances_to_reduce_cold_starts) times and emulation of\nmost, but not all operating system calls. Originally, this was the only\nexecution environment available to services in Cloud Run.\n\nThe second generation execution environment provides full\nLinux compatibility rather than system call emulation. This execution environment\nprovides:\n\n- Faster CPU performance\n- Faster network performance, especially in the presence of packet loss\n- Full Linux compatibility, including support for all system calls, namespaces, and cgroups\n- Network file system support\n\n| **Important:** Cloud Run jobs automatically use the second generation execution environment, and this cannot be changed for jobs.\n\nAlthough the second generation execution environment generally performs faster\nunder sustained load, it has longer [cold start times](/run/docs/tips/general#starting_services_quickly)\nthan first generation for most services.\n\nHow to choose an execution environment\n--------------------------------------\n\nYou should use first generation if any of the following apply:\n\n- Your Cloud Run service has bursty traffic, and needs to scale out fast to many instances, or your service is sensitive to cold start times.\n- Your Cloud Run service has infrequent traffic that causes frequent scale out from zero.\n- You want to use less than 512 MiB of memory. The second generation execution environment requires at least 512 MiB of memory.\n\nYou should use second generation if any of the following apply to your\nCloud Run service:\n\n- Your service needs to use NFS, which is only supported by second generation.\n- Your service has fairly steady traffic and is tolerant of somewhat slower cold starts.\n- Your service has CPU-intensive workloads.\n- Your service could benefit from faster network performance.\n- Your service needs to use software that has issues running in first generation due to [unimplemented system calls](/run/docs/troubleshooting#openblas-warning).\n- Your service needs Linux cgroup functionality.\n- Your service makes use of third-party infrastructure for securing containers.\n\nBest practices when using the second generation execution environment\n---------------------------------------------------------------------\n\nWe recommend that your container install a [SIGTERM handler](/run/docs/container-contract#instance-shutdown),\nespecially if you are using\n[request-based billing](/run/docs/configuring/billing-settings).\n\nHandling SIGTERM gives your container a chance to perform any necessary cleanup\ntasks such as flushing logs before exiting. If your container does not catch\nSIGTERM, it will still be given 10 seconds to perform these tasks; those 10\nseconds are billable.\n\n### How to check whether your container handles SIGTERM\n\nTo determine whether your container has a SIGTERM handler installed:\n\n1. Start Cloud Shell. You can find\n\n **Activate Cloud Shell** in the header of the documentation\n page you're on. You may need to authorize it and wait for it to provision.\n Alternatively, [start a standalone session](/shell/docs/launching-cloud-shell#launch_a_standalone_session).\n\n2. Run the container locally in Cloud Shell:\n\n ```\n docker run IMAGE_URL\n ```\n\n Replace \u003cvar translate=\"no\"\u003eIMAGE_URL\u003c/var\u003e with a reference to the container image, for\n example, `us-docker.pkg.dev/cloudrun/container/hello:latest`. If you use Artifact Registry,\n the [repository](/artifact-registry/docs/repositories/create-repos#docker) \u003cvar translate=\"no\"\u003eREPO_NAME\u003c/var\u003e must\n already be created. The URL follows the format of \u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e`-docker.pkg.dev/`\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003eREPO_NAME\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003ePATH\u003c/var\u003e`:`\u003cvar translate=\"no\"\u003eTAG\u003c/var\u003e\n .\n3. Open another tab in Cloud Shell and get a list of the containers running\n in the current Cloud Shell session:\n\n ```\n docker container ls\n ```\n\n You need to locate the container ID returned from the command.\n4. Using the container ID, send your container a SIGTERM signal\n\n ```\n docker kill -s SIGTERM CONTAINER_ID\n ```\n5. Return to the tab where you invoked `docker run` to see whether the container\n has exited (stopped). If the SIGTERM signal caused your container to exit, your\n container is handling SIGTERM.\n\n### How to handle SIGTERM\n\nIf your container does not handle SIGTERM, the simplest way to add a SIGTERM\nhandler is to wrap your service with `tini`. Doing this makes your service run\nas a subprocess of `tini`, which takes on the role of the container init process.\nRefer to the [Docker instructions](https://github.com/docker-library/official-images#init)\nfor instructions.\n\nAlternatively, you can change your application to directly handle SIGTERM.\n\nWhat's next\n-----------\n\n- To specify an execution environment for your Cloud Run services, refer to [Select an execution environment](/run/docs/configuring/execution-environments).\n- To specify memory for your for your Cloud Run services, refer to [Memory limits](/run/docs/configuring/services/memory-limits).\n- To use Filestore with Cloud Run, refer to [Using Filestore with Cloud Run](/run/docs/tutorials/network-filesystems-filestore).\n- To use Cloud Storage FUSE with Cloud Run, refer to [Using Cloud Storage FUSE with Cloud Run](/run/docs/tutorials/network-filesystems-fuse)."]]
Cloud Shell 활성화를 확인할 수 있습니다. 승인 후 프로비저닝될 때까지 기다려야 할 수도 있습니다.
또는 독립형 세션을 시작합니다.