AWS App Runner 는 2026년 4월 30일부터 신규 고객에게 더 이상 공개되지 않습니다. App Runner를 사용하려면 해당 날짜 이전에 가입하세요. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [AWS App Runner 가용성 변경](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html)을 참조하세요.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 소스 코드를 기반으로 하는 App Runner 서비스
AWS App Runner 를 사용하여 기본적으로 서로 다른 두 가지 유형의 서비스 소스, 즉 *소스 코드*와 *소스 이미지를* 기반으로 서비스를 생성하고 관리할 수 있습니다. 소스 유형에 관계없이 App Runner는 서비스 시작, 실행, 조정 및 로드 밸런싱을 처리합니다. App Runner의 CI/CD 기능을 사용하여 소스 이미지 또는 코드의 변경 사항을 추적할 수 있습니다. App Runner는 변경 사항을 발견하면 자동으로 빌드(소스 코드용)하고 새 버전을 App Runner 서비스에 배포합니다.
이 장에서는 소스 코드를 기반으로 하는 서비스에 대해 설명합니다. 소스 이미지를 기반으로 하는 서비스에 대한 자세한 내용은 섹션을 참조하세요[소스 이미지를 기반으로 하는 App Runner 서비스](service-source-image.md).
소스 코드는 App Runner가 빌드하고 배포하는 애플리케이션 코드입니다. App Runner를 코드 리포지토리의 [소스 디렉터리](#service-source-code.source-directory)로 가리키고 프로그래밍 플랫폼 버전에 해당하는 적절한 *런타임*을 선택합니다. App Runner는 런타임의 기본 이미지와 애플리케이션 코드를 기반으로 이미지를 빌드합니다. 그런 다음이 이미지를 기반으로 컨테이너를 실행하는 서비스를 시작합니다.
App Runner는 편리한 플랫폼별 *관리형 런타임을* 제공합니다. 이러한 각 런타임은 소스 코드에서 컨테이너 이미지를 빌드하고 이미지에 언어 런타임 종속성을 추가합니다. Dockerfile과 같은 컨테이너 구성 및 빌드 지침을 제공할 필요가 없습니다.
이 장의 하위 주제에서는 App Runner가 지원하는 다양한 플랫폼, 즉 다양한 프로그래밍 환경 및 버전에 대한 관리형 런타임을 제공하는 관리형 *플랫폼에* 대해 설명합니다.
**Topics**
+ [소스 코드 리포지토리 공급자](#service-source-code.providers)
+ [소스 디렉터리](#service-source-code.source-directory)
+ [App Runner 관리형 플랫폼](#service-source-code.managed-platforms)
+ [관리형 런타임 버전에 대한 지원 종료](#service-source-code.managed-platforms.eos)
+ [관리형 런타임 버전 및 App Runner 빌드](#service-source-code.build-detail)
+ [Python 플랫폼 사용](service-source-code-python.md)
+ [Node.js 플랫폼 사용](service-source-code-nodejs.md)
+ [Java 플랫폼 사용](service-source-code-java.md)
+ [.NET 플랫폼 사용](service-source-code-net6.md)
+ [PHP 플랫폼 사용](service-source-code-php.md)
+ [Ruby 플랫폼 사용](service-source-code-ruby.md)
+ [Go 플랫폼 사용](service-source-code-go1.md)
## 소스 코드 리포지토리 공급자
App Runner는 소스 코드 리포지토리에서 소스 코드를 읽어 배포합니다. App Runner는 [GitHub](https://github.com/)와 [Bitbucket](https://bitbucket.org/)이라는 두 개의 소스 코드 리포지토리 공급자를 지원합니다.
### 소스 코드 리포지토리 공급자에서 배포
소스 코드 리포지토리에서 App Runner 서비스에 소스 코드를 배포하기 위해 App Runner는 소스 코드에 대한 연결을 설정합니다. App Runner 콘솔을 사용하여 [서비스를 생성할](manage-create.md) 때 App Runner가 소스 코드를 배포할 수 있도록 연결 세부 정보와 소스 디렉터리를 제공합니다.
**연결**
서비스 생성 절차의 일부로 연결 세부 정보를 제공합니다. App Runner API 또는를 사용하는 경우 AWS CLI연결은 별도의 리소스입니다. 먼저 [CreateConnection](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateConnection.html) API 작업을 사용하여 연결을 생성합니다. 그런 다음 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) API 작업을 사용하여 서비스 생성 중에 연결의 ARN을 제공합니다.
**소스 디렉터리**
서비스를 생성할 때 소스 디렉터리도 제공합니다. 기본적으로 App Runner는 리포지토리의 루트 디렉터리를 소스 디렉터리로 사용합니다. 소스 디렉터리는 애플리케이션의 소스 코드 및 구성 파일을 저장하는 소스 코드 리포지토리의 위치입니다. 빌드 및 시작 명령은 소스 디렉터리에서도 실행됩니다. App Runner API 또는 AWS CLI 를 사용하여 서비스를 생성하거나 업데이트할 때 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) 및 [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html) API 작업에 소스 디렉터리를 제공합니다. 자세한 내용은 이어지는 [소스 디렉터리](#service-source-code.source-directory) 단원을 참조하십시오.
App Runner 서비스 생성에 대한 자세한 내용은 섹션을 참조하세요[App Runner 서비스 생성](manage-create.md). App Runner 연결에 대한 자세한 내용은 섹션을 참조하세요[App Runner 연결 관리](manage-connections.md).
## 소스 디렉터리
App Runner 서비스를 생성할 때 리포지토리 및 브랜치와 함께 소스 디렉터리를 제공할 수 있습니다. **소스 디렉터리** 필드의 값을 애플리케이션의 소스 코드 및 구성 파일을 저장하는 리포지토리 디렉터리 경로로 설정합니다. App Runner는 사용자가 제공하는 소스 디렉터리 경로에서 빌드 및 시작 명령을 실행합니다.
루트 리포지토리 디렉터리에서 소스 디렉터리 경로 값을 절대값으로 입력합니다. 값을 지정하지 않으면 기본적으로 리포지토리 루트 디렉터리라고도 하는 리포지토리 최상위 디렉터리로 설정됩니다.
또한 최상위 리포지토리 디렉터리 외에 다른 소스 디렉터리 경로를 제공할 수도 있습니다. 이는 모노리포지토리 아키텍처를 지원합니다. 즉, 여러 애플리케이션의 소스 코드가 하나의 리포지토리에 저장됩니다. 단일 모노레포에서 여러 App Runner 서비스를 생성하고 지원하려면 각 서비스를 생성할 때 서로 다른 소스 디렉터리를 지정합니다.
**참고**
여러 App Runner 서비스에 동일한 소스 디렉터리를 지정하는 경우 두 서비스 모두 개별적으로 배포되고 작동합니다.
`apprunner.yaml` 구성 파일을 사용하여 서비스 파라미터를 정의하도록 선택한 경우 리포지토리의 소스 디렉터리 폴더에 배치합니다.
**배포 트리거** 옵션이 **자동**으로 설정된 경우 소스 디렉터리에서 커밋한 변경 사항이 자동 배포를 트리거합니다.* 소스 디렉터리 경로의 변경 사항만* 자동 배포를 트리거합니다. 소스 디렉터리의 위치가 자동 배포 범위에 어떤 영향을 미치는지 이해하는 것이 중요합니다. 자세한 내용은의 *자동 배포를 참조하세요*[배포 방법](manage-deploy.md#manage-deploy.methods).
**참고**
App Runner 서비스가 PHP 관리형 런타임을 사용하고 기본 루트 리포지토리 이외의 소스 디렉터리를 지정하려는 경우 올바른 PHP 런타임 버전을 사용하는 것이 중요합니다. 자세한 내용은 [PHP 플랫폼 사용](service-source-code-php.md) 단원을 참조하십시오.
## App Runner 관리형 플랫폼
App Runner 관리형 플랫폼은 다양한 프로그래밍 환경을 위한 관리형 런타임을 제공합니다. 각 관리형 런타임을 사용하면 프로그래밍 언어 또는 런타임 환경의 버전을 기반으로 컨테이너를 쉽게 빌드하고 실행할 수 있습니다. 관리형 런타임을 사용하는 경우 App Runner는 관리형 런타임 이미지로 시작합니다. 이 이미지는 [Amazon Linux Docker 이미지를](https://hub.docker.com/_/amazonlinux) 기반으로 하며 언어 런타임 패키지와 일부 도구 및 인기 있는 종속성 패키지를 포함합니다. App Runner는이 관리형 런타임 이미지를 기본 이미지로 사용하고 애플리케이션 코드를 추가하여 도커 이미지를 빌드합니다. 그런 다음이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
App Runner 콘솔 또는 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) API 작업을 사용하여 서비스를 [생성할 때 App Runner 서비스에](manage-create.md) 대한 런타임을 지정합니다. 런타임을 소스 코드의 일부로 지정할 수도 있습니다. 코드 리포지토리에 포함하는 [App Runner 구성 파일의](config-file.md) `runtime` 키워드를 사용합니다. 관리형 런타임의 이름 지정 규칙은 **입니다.
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 [App Runner 구성 파일의](config-file.md) `runtime-version` 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로를 잠글 수 있습니다. App Runner는 서비스의 런타임만 하위 수준으로 업데이트합니다.
## 관리형 런타임 버전에 대한 지원 종료
관리형 언어 런타임의 공식 공급자 또는 커뮤니티가 공식적으로 버전을 수명 종료(EOL)로 선언하면 App Runner는 버전 상태를 *지원 종료*로 선언하여 다음 작업을 수행합니다. 서비스가 지원 종료에 도달한 관리형 언어 런타임 버전에서 실행 중인 경우 다음 정책 및 권장 사항이 적용됩니다.
**언어 런타임 버전에 대한 지원 종료:**
+ **기존 서비스는** 지원 종료에 도달한 런타임을 사용하더라도 계속 실행되고 트래픽을 제공합니다. 그러나 더 이상 업데이트, 보안 패치 또는 기술 지원을 받지 않는 지원되지 않는 런타임에서 실행됩니다.
+ 지원 종료 런타임**을 사용하는 기존 서비스에 대한 업데이트**는 여전히 허용되지만 서비스에 지원 종료 런타임을 계속 사용하는 것은 권장하지 않습니다.
+ 지원 종료 날짜에 도달한 런타임을 사용하여 **새 서비스를** 생성할 수 없습니다.
**지원 종료 상태의 언어 런타임 버전에 필요한 작업:**
+ 서비스가 **소스 이미지를 기반으로 하는** 경우 해당 서비스에 대한 추가 작업이 필요하지 않습니다.
+ 서비스가 **소스 코드를 기반으로 하는** 경우 지원되는 런타임 버전을 사용하도록 서비스 구성을 업데이트합니다. 이렇게 하려면 [App Runner 콘솔](https://console.aws.amazon.com/apprunner)에서 지원되는 런타임 버전을 선택하거나, [apprunner.yaml](config-file.md) 구성 파일의 `runtime` 필드를 업데이트하거나, [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)/[UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html) API 작업 또는 IaC 도구를 사용하여 `runtime` 파라미터를 설정합니다. 지원되는 런타임 목록은이 장의 특정 런타임에 대한 *릴리스 정보* 페이지를 참조하세요.
+ 또는 App Runner의 **컨테이너 이미지 소스** 옵션으로 전환할 수 있습니다. 자세한 내용은 [이미지 기반 서비스](service-source-image.md) 섹션을 참조하세요.
**참고**
Node.js 12, 14 또는 16에서 **Node.js 22**로 또는 Python 3.7 또는 3.8에서 **Python 3.11**로 이동하는 경우 Node.js 22 및 Python 3.11은 더 빠르고 효율적인 빌드를 제공하는 수정된 App Runner 빌드 프로세스를 사용한다는 점에 유의하세요. 업그레이드하기 전에 호환성을 보장하려면 다음 섹션의 [빌드 프로세스 지침을](#service-source-code.build-detail) 검토하는 것이 좋습니다.
다음 표에는 지정된 지원 종료 날짜가 있는 App Runner 관리형 런타임 버전이 나열되어 있습니다.
| **런타임 버전** | **App Runner 지원 종료 날짜** |
| --- | --- |
| Python 3.8 [지원 런타임](service-source-code-python-releases.md) | 2025년 12월 1일 |
| Python 3.7 [지원 런타임](service-source-code-python-releases.md) | 2025년 12월 1일 |
| Node.js 18 [지원되는 런타임](service-source-code-nodejs-releases.md) | 2025년 12월 1일 |
| Node.js 16 [지원되는 런타임](service-source-code-nodejs-releases.md) | 2025년 12월 1일 |
| Node.js 14 [지원되는 런타임](service-source-code-nodejs-releases.md) | 2025년 12월 1일 |
| Node.js 12 [지원되는 런타임](service-source-code-nodejs-releases.md) | 2025년 12월 1일 |
| .NET 6\$1 | 2025년 12월 1일 |
| PHP 8.1\$1 | 2025년 12월 31일 |
| Ruby 3.1\$1 | 2025년 12월 1일 |
| Go 1\$1 | 2025년 12월 1일 |
**\$1** App Runner는 별표(\$1)로 표시된 런타임에 대한 새 언어 버전을 릴리스하지 않습니다. 이러한 런타임은 .NET, PHP, Ruby 및 Go입니다. 이러한 런타임에 대해 코드 기반 서비스가 구성된 경우 다음 작업 중 하나를 수행하는 것이 좋습니다.
+ 해당하는 경우 서비스 구성을 지원되는 다른 관리형 런타임으로 전환합니다.
+ 또는 원하는 런타임 버전으로 사용자 지정 컨테이너 이미지를 빌드하고 App Runner의 [이미지 기반 서비스](service-source-image.md) 옵션을 사용하여 배포합니다. Amazon ECR에서 이미지를 호스팅할 수 있습니다.
## 관리형 런타임 버전 및 App Runner 빌드
App Runner는 최신 메이저 버전 런타임에서 실행되는 애플리케이션을 위한 업데이트된 빌드 프로세스를 제공합니다. 이 수정된 빌드 프로세스는 더 빠르고 효율적입니다. 또한 애플리케이션을 실행하는 데 필요한 소스 코드, 빌드 아티팩트 및 런타임만 포함하는 더 작은 공간으로 최종 이미지를 생성합니다.
최신 빌드 프로세스를 *수정된 App Runner 빌드*라고 하고 원래 빌드 프로세스를* 원래 App Runner 빌드*라고 합니다. 이전 버전의 런타임 플랫폼에 대한 변경 사항을 방지하기 위해 App Runner는 일반적으로 새로 릴리스된 주요 릴리스인 특정 런타임 버전에만 수정된 빌드를 적용합니다.
매우 구체적인 사용 사례에 맞게 수정된 빌드를 이전 버전과 호환하고 애플리케이션 빌드를 구성할 수 있는 유연성을 높이기 위해 `apprunner.yaml` 구성 파일에 새 구성 요소를 도입했습니다. 이는 선택적 [`pre-run`](config-file-ref.md#config-file-ref.run) 파라미터입니다. 다음 섹션의 빌드에 대한 다른 유용한 정보와 함께이 파라미터를 사용해야 하는 경우를 설명합니다.
다음 표에는 특정 관리형 런타임 버전에 적용되는 App Runner 빌드 버전이 나와 있습니다. 현재 런타임에 대한 최신 정보를 제공하기 위해이 문서를 계속 업데이트할 예정입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code.html)
**참고**
나열된 런타임 중 일부에는 **지원 종료** 날짜가 포함됩니다. 자세한 내용은 [관리형 런타임 버전에 대한 지원 종료](#service-source-code.managed-platforms.eos) 단원을 참조하십시오.
**중요**
**Python 3.11** - Python 3.11 관리형 런타임을 사용하는 서비스의 빌드 구성에 대한 특정 권장 사항이 있습니다. 자세한 내용은 *Python 플랫폼* 주제[특정 런타임 버전에 대한 콜아웃](service-source-code-python.md#service-source-code-python.callouts)의 섹션을 참조하세요.
### App Runner 빌드 및 마이그레이션에 대해 자세히 알아보기
수정된 빌드를 사용하는 최신 런타임으로 애플리케이션을 마이그레이션할 때 빌드 구성을 약간 수정해야 할 수 있습니다.
마이그레이션 고려 사항에 대한 컨텍스트를 제공하기 위해 먼저 원래 App Runner 빌드와 수정된 빌드 모두에 대한 상위 수준 프로세스를 설명합니다. 다음 단원에서는 일부 구성 업데이트가 필요할 수 있는 서비스에 대한 특정 속성을 설명합니다.
#### 원래 App Runner 빌드
원래 App Runner 애플리케이션 빌드 프로세스는 AWS CodeBuild 서비스를 활용합니다. 초기 단계는 CodeBuild 서비스에서 큐레이션한 이미지를 기반으로 합니다. 해당하는 App Runner 관리형 런타임 이미지를 기본 이미지로 사용하는 Docker 빌드 프로세스가 이어집니다.
일반적인 단계는 다음과 같습니다.
1. CodeBuild에서 선별한 이미지에서 `pre-build` 명령을 실행합니다.
`pre-build` 명령은 선택 사항입니다. `apprunner.yaml` 구성 파일에서만 지정할 수 있습니다.
1. 이전 단계의 동일한 이미지에서 CodeBuild를 사용하여 `build` 명령을 실행합니다.
`build` 명령이 필요합니다. App Runner 콘솔, App Runner API 또는 `apprunner.yaml` 구성 파일에서 지정할 수 있습니다.
1. Docker 빌드를 실행하여 특정 플랫폼 및 런타임 버전에 대한 App Runner 관리형 런타임 이미지를 기반으로 이미지를 생성합니다.
1. **2단계**에서 생성한 이미지에서 `/app` 디렉터리를 복사합니다. 대상은 **3단계**에서 생성한 App Runner 관리형 런타임 이미지를 기반으로 하는 이미지입니다.
1. 생성된 App Runner 관리형 런타임 이미지에서 `build` 명령을 다시 실행합니다. 빌드 명령을 다시 실행하여 **4단계**에서 복사한 `/app` 디렉터리의 소스 코드에서 빌드 아티팩트를 생성합니다. 이 이미지는 나중에 App Runner에서 배포하여 컨테이너에서 웹 서비스를 실행합니다.
`build` 명령이 필요합니다. App Runner 콘솔, App Runner API 또는 `apprunner.yaml` 구성 파일에서 지정할 수 있습니다.
1. **2단계**의 CodeBuild 이미지에서 `post-build` 명령을 실행합니다.
`post-build` 명령은 선택 사항입니다. `apprunner.yaml` 구성 파일에서만 지정할 수 있습니다.
빌드가 완료되면 App Runner는 **5단계**에서 생성된 App Runner 관리형 런타임 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
#### 수정된 App Runner 빌드
수정된 빌드 프로세스는 이전 섹션에 설명된 원래 빌드 프로세스보다 빠르고 효율적입니다. 이전 버전 빌드에서 발생하는 빌드 명령의 중복을 제거합니다. 또한 애플리케이션을 실행하는 데 필요한 소스 코드, 빌드 아티팩트 및 런타임만 포함하는 더 작은 공간으로 최종 이미지를 생성합니다.
이 빌드 프로세스는 Docker 다단계 빌드를 사용합니다. 일반적인 프로세스 단계는 다음과 같습니다.
1. **빌드 단계** - App Runner 빌드 이미지 위에 `pre-build` 및 `build` 명령을 실행하는 Docker 빌드 프로세스를 시작합니다.
1. 애플리케이션 소스 코드를 `/app` 디렉터리에 복사합니다.
**참고**
이 `/app` 디렉터리는 Docker 빌드의 모든 단계에서 작업 디렉터리로 지정됩니다.
1. `pre-build` 명령 실행
명령은`pre-build` 선택 사항입니다. `apprunner.yaml` 구성 파일에서만 지정할 수 있습니다.
1. `build` 명령을 실행합니다.
`build` 명령이 필요합니다. App Runner 콘솔, App Runner API 또는 `apprunner.yaml` 구성 파일에서 지정할 수 있습니다.
1. **패키징 단계** - App Runner 실행 이미지를 기반으로 하는 최종 고객 컨테이너 이미지를 생성합니다.
1. 이전 **빌드 단계에서** 새 실행 이미지로 `/app` 디렉터리를 복사합니다. 여기에는 애플리케이션 소스 코드와 이전 단계의 빌드 아티팩트가 포함됩니다.
1. `pre-run` 명령을 실행합니다. `build` 명령을 사용하여 `/app` 디렉터리 외부에서 런타임 이미지를 수정해야 하는 경우 `apprunner.yaml` 구성 파일의이 세그먼트에 동일하거나 필요한 명령을 추가합니다.
이는 수정된 App Runner 빌드를 지원하기 위해 도입된 새로운 파라미터입니다.
`pre-run` 명령은 선택 사항입니다. `apprunner.yaml` 구성 파일에서만 지정할 수 있습니다.
**참고**
`pre-run` 명령은 수정된 빌드에서만 지원됩니다. 서비스에서 원래 빌드를 사용하는 런타임 버전을 사용하는 경우 구성 파일에 추가하지 마십시오.
`build` 명령을 사용하여 `/app` 디렉터리 외부의 어떤 것도 수정할 필요가 없는 경우 `pre-run` 명령을 지정할 필요가 없습니다.
1. **빌드 후 단계 -**이 단계는 *빌드 단계에서* 재개되고 `post-build` 명령을 실행합니다.
1. `/app` 디렉터리 내에서 `post-build` 명령을 실행합니다.
`post-build` 명령은 선택 사항입니다. `apprunner.yaml` 구성 파일에서만 지정할 수 있습니다.
빌드가 완료되면 App Runner는 실행 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
**참고**
빌드 프로세스를 구성할 `apprunner.yaml` 때의 실행 섹션에 있는 `env` 항목을 오해하지 마세요. **2(b)단계**에서 참조된 `pre-run` 명령 파라미터가 실행 섹션에 있더라도 실행 섹션의 `env` 파라미터를 사용하여 빌드를 구성하지 마십시오. `pre-run` 명령은 구성 파일의 빌드 섹션에 정의된 `env` 변수만 참조합니다. 자세한 내용은 App Runner 구성 파일 [실행 섹션](config-file-ref.md#config-file-ref.run) 장의 섹션을 참조하세요. **
#### 마이그레이션 고려 사항에 대한 서비스 요구 사항
애플리케이션 환경에 이러한 두 요구 사항 중 하나가 있는 경우 `pre-run` 명령을 추가하여 빌드 구성을 수정해야 합니다.
+ `build` 명령을 사용하여 `/app` 디렉터리 외부의 항목을 수정해야 하는 경우.
+ `build` 명령을 두 번 실행하여 필요한 환경을 생성해야 하는 경우. 이는 매우 드문 요구 사항입니다. 대부분의 빌드는이 작업을 수행하지 않습니다.
**`/app` 디렉터리 외부의 수정 사항**
+ [수정된 App Runner 빌드](#service-source-code.build-detail.v2)는 애플리케이션에 `/app` 디렉터리 외부의 종속성이 없다고 가정합니다.
+ `apprunner.yaml` 파일, App Runner API 또는 App Runner 콘솔과 함께 제공하는 명령은 `/app` 디렉터리에서 빌드 아티팩트를 생성해야 합니다.
+ `pre-build`, `build`및 `post-build` 명령을 수정하여 모든 빌드 아티팩트가 `/app` 디렉터리에 있는지 확인할 수 있습니다.
+ 애플리케이션에 서비스에 대해 생성된 이미지를 추가로 수정하기 위한 빌드가 필요한 경우 `/app` 디렉터리 외부에서의 새 `pre-run` 명령을 사용할 수 있습니다`apprunner.yaml`. 자세한 내용은 [구성 파일을 사용하여 App Runner 서비스 옵션 설정](config-file.md) 단원을 참조하십시오.
**`build` 명령을 두 번 실행**
+ [원래 App Runner 빌드](#service-source-code.build-detail.v1)는 `build` 명령을 두 번 실행합니다. 먼저 **2단계**에서 실행한 다음 **5단계**에서 다시 실행합니다. 수정된 App Runner 빌드는 이러한 중복성을 해결하고 `build` 명령을 한 번만 실행합니다. 애플리케이션이 `build` 명령을 두 번 실행해야 하는 비정상적인 요구 사항이 있는 경우 수정된 App Runner 빌드는 `pre-run` 파라미터를 사용하여 동일한 명령을 다시 지정하고 실행할 수 있는 옵션을 제공합니다. 이렇게 하면 동일한 이중 빌드 동작이 유지됩니다.
# Python 플랫폼 사용
**중요**
App Runner는 2025년 12월 1일에 **Python 3.7** 및 **Python 3.8**에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
AWS App Runner Python 플랫폼은 관리형 런타임을 제공합니다. 각 런타임을 사용하면 Python 버전을 기반으로 웹 애플리케이션을 사용하여 컨테이너를 쉽게 빌드하고 실행할 수 있습니다. Python 런타임을 사용하는 경우 App Runner는 관리형 Python 런타임 이미지로 시작합니다. 이 이미지는 [Amazon Linux Docker 이미지를](https://hub.docker.com/_/amazonlinux) 기반으로 하며 Python 버전에 대한 런타임 패키지와 일부 도구 및 인기 있는 종속성 패키지를 포함합니다. App Runner는이 관리형 런타임 이미지를 기본 이미지로 사용하고 애플리케이션 코드를 추가하여 도커 이미지를 빌드합니다. 그런 다음이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
App Runner 콘솔 또는 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) API 작업을 사용하여 서비스를 [생성할 때 App Runner 서비스에](manage-create.md) 대한 런타임을 지정합니다. 런타임을 소스 코드의 일부로 지정할 수도 있습니다. 코드 리포지토리에 포함하는 [App Runner 구성 파일의](config-file.md) `runtime` 키워드를 사용합니다. 관리형 런타임의 이름 지정 규칙은 **입니다.
유효한 Python 런타임 이름 및 버전은 섹션을 참조하세요[Python 런타임 릴리스 정보](service-source-code-python-releases.md).
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 [App Runner 구성 파일의](config-file.md) `runtime-version` 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로를 잠글 수 있습니다. App Runner는 서비스의 런타임만 하위 수준으로 업데이트합니다.
Python 런타임의 버전 구문: `major[.minor[.patch]]`
예: `3.8.5`
다음 예제에서는 버전 잠금을 보여줍니다.
+ `3.8` - 메이저 및 마이너 버전을 잠급니다. App Runner는 패치 버전만 업데이트합니다.
+ `3.8.5` - 특정 패치 버전으로 잠급니다. App Runner는 런타임 버전을 업데이트하지 않습니다.
**Topics**
+ [Python 런타임 구성](#service-source-code-python.config)
+ [특정 런타임 버전에 대한 콜아웃](#service-source-code-python.callouts)
+ [Python 런타임 예제](#service-source-code-python.examples)
+ [Python 런타임 릴리스 정보](service-source-code-python-releases.md)
## Python 런타임 구성
관리형 런타임을 선택할 때는 최소한 빌드 및 실행 명령도 구성해야 합니다. App Runner 서비스를 [생성](manage-create.md)하거나 [업데이트](manage-configure.md)하는 동안 이를 구성합니다. 다음 방법 중 하나를 사용하여이 작업을 수행할 수 있습니다.
+ **App Runner 콘솔 사용** - 생성 프로세스 또는 **구성 탭의 빌드** 구성 섹션에서 명령을 지정합니다.
+ **App Runner API 사용** - [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) 또는 [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html) API 작업을 호출합니다. [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html) 데이터 형식의 `BuildCommand` 및 `StartCommand` 멤버를 사용하여 명령을 지정합니다.
+ **[구성 파일](config-file.md) 사용** - 최대 3개의 빌드 단계에서 하나 이상의 빌드 명령을 지정하고 애플리케이션을 시작하는 데 사용되는 단일 실행 명령을 지정합니다. 추가 선택적 구성 설정이 있습니다.
구성 파일을 제공하는 것은 선택 사항입니다. 콘솔 또는 API를 사용하여 App Runner 서비스를 생성할 때 App Runner가 구성 설정을 생성할 때 직접 가져오거나 구성 파일에서 가져올지 지정합니다.
## 특정 런타임 버전에 대한 콜아웃
**참고**
App Runner는 이제 Python 3.11, Node.js 22 및 Node.js 18 런타임 버전을 기반으로 애플리케이션에 대해 업데이트된 빌드 프로세스를 실행합니다. 애플리케이션이 이러한 런타임 버전 중 하나에서 실행되는 경우 수정된 빌드 프로세스에 대한 자세한 내용은 [관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail) 섹션을 참조하세요. 다른 모든 런타임 버전을 사용하는 애플리케이션은 영향을 받지 않으며 원래 빌드 프로세스를 계속 사용합니다.
### Python 3.11(개정된 App Runner 빌드)
관리형 Python 3*.11 런타임에 대해 apprunner.yaml*에서 다음 설정을 사용합니다.
+ 상단 섹션의 `runtime` 키를 로 설정 `python311`
**Example**
```
runtime: python311
```
+ 대신를 사용하여 종속성을 `pip3` `pip` 설치합니다.
+ 대신 인터`python3`프리터를 사용합니다`python`.
+ `pip3` 설치 관리자를 `pre-run`명령으로 실행합니다. Python은 `/app` 디렉터리 외부에 종속성을 설치합니다. App Runner는 Python 3.11용 수정된 App Runner 빌드를 실행하므로 `apprunner.yaml` 파일의 빌드 섹션에 있는 명령을 통해 `/app` 디렉터리 외부에 설치된 모든 항목이 손실됩니다. 자세한 내용은 [수정된 App Runner 빌드](service-source-code.md#service-source-code.build-detail.v2) 단원을 참조하십시오.
**Example**
```
run:
runtime-version: 3.11
pre-run:
- pip3 install pipenv
- pipenv install
- python3 copy-global-files.py
command: pipenv run gunicorn django_apprunner.wsgi --log-file -
```
자세한 내용은이 주제 뒷부분[의 Python 3.11에 대한 확장 구성 파일의 예제](#service-source-code-python.examples.extended-v2)도 참조하세요.
## Python 런타임 예제
다음 예제에서는 Python 서비스를 빌드하고 실행하기 위한 App Runner 구성 파일을 보여줍니다. 마지막 예제는 Python 런타임 서비스에 배포할 수 있는 전체 Python 애플리케이션의 소스 코드입니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *3.7.7* 및 *3.11*입니다. 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Python 런타임 버전은 섹션을 참조하세요[Python 런타임 릴리스 정보](service-source-code-python-releases.md).
### 미니멀 Python 구성 파일
이 예제는 Python 관리형 런타임과 함께 사용할 수 있는 최소 구성 파일을 보여줍니다. App Runner가 최소 구성 파일로 가정하는 내용은 섹션을 참조하세요[구성 파일 예제](config-file-examples.md#config-file-examples.managed).
Python 3.11은 `pip3` 및 `python3` 명령을 사용합니다. 자세한 내용은이 주제의 뒷부분에서 [Python 3.11용 확장 구성 파일의 예를](#service-source-code-python.examples.extended-v2) 참조하세요.
**Example apprunner.yaml**
```
version: 1.0
runtime: python3
build:
commands:
build:
- pip install pipenv
- pipenv install
run:
command: python app.py
```
### 확장 Python 구성 파일
이 예제에서는 Python 관리형 런타임에서 모든 구성 키를 사용하는 방법을 보여줍니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *3.7.7*입니다. 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Python 런타임 버전은 섹션을 참조하세요[Python 런타임 릴리스 정보](service-source-code-python-releases.md).
Python 3.11은 `pip3` 및 `python3` 명령을 사용합니다. 자세한 내용은이 주제의 뒷부분에서 Python 3.11용 확장 구성 파일의 예를 참조하세요.
**Example apprunner.yaml**
```
version: 1.0
runtime: python3
build:
commands:
pre-build:
- wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz
build:
- pip install pipenv
- pipenv install
post-build:
- python manage.py test
env:
- name: DJANGO_SETTINGS_MODULE
value: "django_apprunner.settings"
- name: MY_VAR_EXAMPLE
value: "example"
run:
runtime-version: 3.7.7
command: pipenv run gunicorn django_apprunner.wsgi --log-file -
network:
port: 8000
env: MY_APP_PORT
env:
- name: MY_VAR_EXAMPLE
value: "example"
secrets:
- name: my-secret
value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::"
- name: my-parameter
value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name"
- name: my-parameter-only-name
value-from: "parameter-name"
```
### 확장 Python 구성 파일 - Python 3.11(개정된 빌드 사용)
이 예제는에서 Python 3.11 관리형 런타임과 함께 모든 구성 키를 사용하는 방법을 보여줍니다`apprunner.yaml`. 이 Python 버전은 수정된 App Runner 빌드를 사용하기 때문에이 예제에는 `pre-run` 섹션이 포함되어 있습니다.
`pre-run` 파라미터는 수정된 App Runner 빌드에서만 지원됩니다. 애플리케이션이 원래 App Runner 빌드에서 지원하는 런타임 버전을 사용하는 경우 구성 파일에이 파라미터를 삽입하지 마십시오. 자세한 내용은 [관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail) 단원을 참조하십시오.
**참고**
이 예제에서 사용되는 런타임 버전은 *3.11*입니다. 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Python 런타임 버전은 섹션을 참조하세요[Python 런타임 릴리스 정보](service-source-code-python-releases.md).
**Example apprunner.yaml**
```
version: 1.0
runtime: python311
build:
commands:
pre-build:
- wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz
build:
- pip3 install pipenv
- pipenv install
post-build:
- python3 manage.py test
env:
- name: DJANGO_SETTINGS_MODULE
value: "django_apprunner.settings"
- name: MY_VAR_EXAMPLE
value: "example"
run:
runtime-version: 3.11
pre-run:
- pip3 install pipenv
- pipenv install
- python3 copy-global-files.py
command: pipenv run gunicorn django_apprunner.wsgi --log-file -
network:
port: 8000
env: MY_APP_PORT
env:
- name: MY_VAR_EXAMPLE
value: "example"
secrets:
- name: my-secret
value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::"
- name: my-parameter
value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name"
- name: my-parameter-only-name
value-from: "parameter-name"
```
### 전체 Python 애플리케이션 소스
이 예제는 Python 런타임 서비스에 배포할 수 있는 전체 Python 애플리케이션의 소스 코드를 보여줍니다.
**Example requirements.txt**
```
pyramid==2.0
```
**Example server.py**
```
from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.response import Response
import os
def hello_world(request):
name = os.environ.get('NAME')
if name == None or len(name) == 0:
name = "world"
message = "Hello, " + name + "!\n"
return Response(message)
if __name__ == '__main__':
port = int(os.environ.get("PORT"))
with Configurator() as config:
config.add_route('hello', '/')
config.add_view(hello_world, route_name='hello')
app = config.make_wsgi_app()
server = make_server('0.0.0.0', port, app)
server.serve_forever()
```
**Example apprunner.yaml**
```
version: 1.0
runtime: python3
build:
commands:
build:
- pip install -r requirements.txt
run:
command: python server.py
```
# Python 런타임 릴리스 정보
**중요**
App Runner는 2025년 12월 1일에 **Python 3.7** 및 **Python 3.8**에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
이 주제에서는 App Runner가 지원하는 Python 런타임 버전에 대한 전체 세부 정보를 나열합니다.
**지원되는 런타임 버전 - 수정된 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-python-releases.html)
**참고**
**Python 3.11** - Python 3.11 관리형 런타임을 사용하는 서비스의 빌드 구성에 대한 특정 권장 사항이 있습니다. 자세한 내용은 *Python 플랫폼* 주제[특정 런타임 버전에 대한 콜아웃](service-source-code-python.md#service-source-code-python.callouts)의 섹션을 참조하세요.
App Runner는 최근에 릴리스된 특정 주요 런타임에 대해 수정된 빌드 프로세스를 제공합니다. 따라서이 문서의 특정 섹션에 *수정된 App Runner 빌드* 및 *원래 App Runner 빌드*에 대한 참조가 표시됩니다. 자세한 내용은 단원을 참조하십시오[관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail).
**지원되는 런타임 버전 - 원래 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-python-releases.html)
**참고**
App Runner는 최근에 릴리스된 특정 주요 런타임에 대해 수정된 빌드 프로세스를 제공합니다. 따라서이 문서의 특정 섹션에 *수정된 App Runner 빌드* 및 *원래 App Runner 빌드*에 대한 참조가 표시됩니다. 자세한 내용은 단원을 참조하십시오[관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail).
# Node.js 플랫폼 사용
**중요**
App Runner는 **2025년 12월 1일에 Node.js** **12, Node.js 14**, **Node.js 16** 및 **Node.js 18**에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
AWS App Runner Node.js 플랫폼은 관리형 런타임을 제공합니다. 각 런타임을 사용하면 Node.js 버전을 기반으로 웹 애플리케이션을 사용하여 컨테이너를 쉽게 빌드하고 실행할 수 있습니다. Node.js 런타임을 사용하는 경우 App Runner는 관리형 Node.js 런타임 이미지로 시작합니다. 이 이미지는 [Amazon Linux Docker 이미지를](https://hub.docker.com/_/amazonlinux) 기반으로 하며 Node.js 버전 및 일부 도구에 대한 런타임 패키지를 포함합니다. App Runner는이 관리형 런타임 이미지를 기본 이미지로 사용하고 애플리케이션 코드를 추가하여 도커 이미지를 빌드합니다. 그런 다음이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
App Runner 콘솔 또는 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) API 작업을 사용하여 서비스를 [생성할 때 App Runner 서비스에](manage-create.md) 대한 런타임을 지정합니다. 런타임을 소스 코드의 일부로 지정할 수도 있습니다. 코드 리포지토리에 포함하는 [App Runner 구성 파일의](config-file.md) `runtime` 키워드를 사용합니다. 관리형 런타임의 이름 지정 규칙은 **입니다.
유효한 Node.js 런타임 이름 및 버전은 섹션을 참조하세요[Node.js 런타임 릴리스 정보](service-source-code-nodejs-releases.md).
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 [App Runner 구성 파일의](config-file.md) `runtime-version` 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로를 잠글 수 있습니다. App Runner는 서비스의 런타임만 하위 수준으로 업데이트합니다.
Node.js 런타임의 버전 구문: `major[.minor[.patch]]`
예: `22.14.0`
다음 예제에서는 버전 잠금을 보여줍니다.
+ `22.14` - 메이저 및 마이너 버전을 잠급니다. App Runner는 패치 버전만 업데이트합니다.
+ `22.14.0` - 특정 패치 버전으로 잠급니다. App Runner는 런타임 버전을 업데이트하지 않습니다.
**Topics**
+ [Node.js 런타임 구성](#service-source-code-nodejs.config)
+ [특정 런타임 버전에 대한 호출](#service-source-code-nodejs.callouts)
+ [Node.js 런타임 예제](#service-source-code-nodejs.examples)
+ [Node.js 런타임 릴리스 정보](service-source-code-nodejs-releases.md)
## Node.js 런타임 구성
관리형 런타임을 선택할 때는 최소한 빌드 및 실행 명령도 구성해야 합니다. App Runner 서비스를 [생성](manage-create.md)하거나 [업데이트](manage-configure.md)하는 동안 이를 구성합니다. 다음 방법 중 하나를 사용하여이 작업을 수행할 수 있습니다.
+ **App Runner 콘솔 사용** - 생성 프로세스 또는 **구성 탭의 빌드** 구성 섹션에서 명령을 지정합니다.
+ **App Runner API 사용** - [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) 또는 [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html) API 작업을 호출합니다. [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html) 데이터 형식의 `BuildCommand` 및 `StartCommand` 멤버를 사용하여 명령을 지정합니다.
+ **[구성 파일](config-file.md) 사용** - 최대 3개의 빌드 단계에서 하나 이상의 빌드 명령을 지정하고 애플리케이션을 시작하는 데 사용되는 단일 실행 명령을 지정합니다. 추가 선택적 구성 설정이 있습니다.
구성 파일을 제공하는 것은 선택 사항입니다. 콘솔 또는 API를 사용하여 App Runner 서비스를 생성할 때 App Runner가 구성 설정을 생성할 때 직접 가져올지 또는 구성 파일에서 가져올지 지정합니다.
특히 Node.js 런타임을 사용하면 소스 리포지토리의 루트`package.json`에 이름이 인 JSON 파일을 사용하여 빌드 및 런타임을 구성할 수도 있습니다. 이 파일을 사용하여 Node.js 엔진 버전, 종속성 패키지 및 다양한 명령(명령줄 애플리케이션)을 구성할 수 있습니다. npm 또는 yarn와 같은 패키지 관리자는이 파일을 명령의 입력으로 해석합니다.
예제:
+ **npm install**는의 `dependencies` 및 `devDependencies` 노드에서 정의한 패키지를 설치합니다`package.json`.
+ **npm start** 또는는의 `scripts/start` 노드에서 정의한 명령을 **npm run start** 실행합니다`package.json`.
다음은 예 `package.json` 파일입니다.
### package.json
```
{
"name": "node-js-getting-started",
"version": "0.3.0",
"description": "A sample Node.js app using Express 4",
"engines": {
"node": "22.14.0"
},
"scripts": {
"start": "node index.js",
"test": "node test.js"
},
"dependencies": {
"cool-ascii-faces": "^1.3.4",
"ejs": "^2.5.6",
"express": "^4.15.2"
},
"devDependencies": {
"got": "^11.3.0",
"tape": "^4.7.0"
}
}
```
에 대한 자세한 내용은 npm Docs 웹 사이트에서 [package.json 파일 생성을](https://docs.npmjs.com/creating-a-package-json-file) `package.json`참조하세요. **
**팁**
`package.json` 파일이 **start** 명령을 정의하는 경우 다음 예제와 같이 App Runner 구성 파일에서 **run** 명령으로 사용할 수 있습니다.
**Example**
package.json
```
{
"scripts": {
"start": "node index.js"
}
}
```
apprunner.yaml
```
run:
command: npm start
```
개발 환경에서 **npm install**를 실행하면 npm이 파일을 생성합니다`package-lock.json`. 이 파일에는 방금 설치된 패키지 버전 npm의 스냅샷이 포함되어 있습니다. 그런 다음 npm이 종속성을 설치할 때 이러한 정확한 버전을 사용합니다. 얀을 설치하면 `yarn.lock` 파일이 생성됩니다. 이러한 파일을 소스 코드 리포지토리에 커밋하여 애플리케이션이 개발 및 테스트한 종속성 버전으로 설치되도록 합니다.
App Runner 구성 파일을 사용하여 Node.js 버전 및 시작 명령을 구성할 수도 있습니다. 이렇게 하면 이러한 정의가의 정의보다 우선합니다`package.json`. 의 `node` 버전`package.json`과 App Runner 구성 파일의 `runtime-version` 값이 충돌하면 App Runner 빌드 단계가 실패합니다.
## 특정 런타임 버전에 대한 호출
### Node.js 22 및 Node.js 18(개정된 App Runner 빌드)
App Runner는 이제 Python 3.11, Node.js 22 및 Node.js 18 런타임 버전을 기반으로 애플리케이션에 대해 업데이트된 빌드 프로세스를 실행합니다. 애플리케이션이 이러한 런타임 버전 중 하나에서 실행되는 경우 수정된 빌드 프로세스에 대한 자세한 내용은 [관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail) 섹션을 참조하세요. 다른 모든 런타임 버전을 사용하는 애플리케이션은 영향을 받지 않으며 원래 빌드 프로세스를 계속 사용합니다.
## Node.js 런타임 예제
다음 예제에서는 Node.js 서비스를 빌드하고 실행하기 위한 App Runner 구성 파일을 보여줍니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *22.14.0*입니다. 이를 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Node.js 런타임 버전은 섹션을 참조하세요[Node.js 런타임 릴리스 정보](service-source-code-nodejs-releases.md).
### 미니멀 Node.js 구성 파일
이 예제는 Node.js 관리형 런타임과 함께 사용할 수 있는 최소 구성 파일을 보여줍니다. App Runner가 최소 구성 파일로 가정하는 내용은 섹션을 참조하세요[구성 파일 예제](config-file-examples.md#config-file-examples.managed).
**Example apprunner.yaml**
```
version: 1.0
runtime: nodejs22
build:
commands:
build:
- npm install --production
run:
command: node app.js
```
### 확장 Node.js 구성 파일
이 예제에서는 Node.js 관리형 런타임에서 모든 구성 키를 사용하는 방법을 보여줍니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *22.14.0*입니다. 이를 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Node.js 런타임 버전은 섹션을 참조하세요[Node.js 런타임 릴리스 정보](service-source-code-nodejs-releases.md).
**Example apprunner.yaml**
```
version: 1.0
runtime: nodejs22
build:
commands:
pre-build:
- npm install --only=dev
- node test.js
build:
- npm install --production
post-build:
- node node_modules/ejs/postinstall.js
env:
- name: MY_VAR_EXAMPLE
value: "example"
run:
runtime-version: 22.14.0
command: node app.js
network:
port: 8000
env: APP_PORT
env:
- name: MY_VAR_EXAMPLE
value: "example"
```
### 확장 Node.js 구성 파일 - Node.js 22(개정된 빌드 사용)
이 예제는에서 Node.js 관리형 런타임과 함께 모든 구성 키를 사용하는 방법을 보여줍니다`apprunner.yaml`. 이 Node.js 버전은 수정된 App Runner 빌드를 사용하기 때문에이 예제에는 `pre-run` 섹션이 포함되어 있습니다.
`pre-run` 파라미터는 수정된 App Runner 빌드에서만 지원됩니다. 애플리케이션이 원래 App Runner 빌드에서 지원하는 런타임 버전을 사용하는 경우 구성 파일에이 파라미터를 삽입하지 마십시오. 자세한 내용은 [관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail) 단원을 참조하십시오.
**참고**
이 예제에서 사용되는 런타임 버전은 *22.14.0*입니다. 이를 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Node.js 런타임 버전은 섹션을 참조하세요[Node.js 런타임 릴리스 정보](service-source-code-nodejs-releases.md).
**Example apprunner.yaml**
```
version: 1.0
runtime: nodejs22
build:
commands:
pre-build:
- npm install --only=dev
- node test.js
build:
- npm install --production
post-build:
- node node_modules/ejs/postinstall.js
env:
- name: MY_VAR_EXAMPLE
value: "example"
run:
runtime-version: 22.14.0
pre-run:
- node copy-global-files.js
command: node app.js
network:
port: 8000
env: APP_PORT
env:
- name: MY_VAR_EXAMPLE
value: "example"
```
### Grunt가 있는 Node.js 앱
이 예제에서는 Grunt로 개발된 Node.js 애플리케이션을 구성하는 방법을 보여줍니다. [Grunt](https://gruntjs.com/)는 명령줄 JavaScript 작업 실행기입니다. 반복 작업을 실행하고 프로세스 자동화를 관리하여 인적 오류를 줄입니다. Grunt 및 Grunt 플러그인은 npm을 사용하여 설치 및 관리됩니다. 소스 리포지토리의 루트에 `Gruntfile.js` 파일을 포함하여 Grunt를 구성합니다.
**Example package.json**
```
{
"scripts": {
"build": "grunt uglify",
"start": "node app.js"
},
"devDependencies": {
"grunt": "~0.4.5",
"grunt-contrib-jshint": "~0.10.0",
"grunt-contrib-nodeunit": "~0.4.1",
"grunt-contrib-uglify": "~0.5.0"
},
"dependencies": {
"express": "^4.15.2"
},
}
```
**Example Gruntfile.js**
```
module.exports = function(grunt) {
// Project configuration.
grunt.initConfig({
pkg: grunt.file.readJSON('package.json'),
uglify: {
options: {
banner: '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n'
},
build: {
src: 'src/<%= pkg.name %>.js',
dest: 'build/<%= pkg.name %>.min.js'
}
}
});
// Load the plugin that provides the "uglify" task.
grunt.loadNpmTasks('grunt-contrib-uglify');
// Default task(s).
grunt.registerTask('default', ['uglify']);
};
```
**Example apprunner.yaml**
이 예제에서 사용되는 런타임 버전은 *22.14.0*입니다. 이를 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Node.js 런타임 버전은 섹션을 참조하세요[Node.js 런타임 릴리스 정보](service-source-code-nodejs-releases.md).
```
version: 1.0
runtime: nodejs22
build:
commands:
pre-build:
- npm install grunt grunt-cli
- npm install --only=dev
- npm run build
build:
- npm install --production
run:
runtime-version: 22.14.0
command: node app.js
network:
port: 8000
env: APP_PORT
```
# Node.js 런타임 릴리스 정보
**중요**
App Runner는 **2025년 12월 1일에 Node.js** **12, Node.js 14**, **Node.js 16** 및 **Node.js 18**에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
**참고**
App Runner의 표준 사용 중단 정책은 런타임의 주요 구성 요소가 커뮤니티 장기 지원(LTS) 종료에 도달하고 보안 업데이트를 더 이상 사용할 수 없는 경우 런타임을 사용 중지하는 것입니다. 경우에 따라 App Runner는 런타임에서 지원하는 언어 버전의 end-of-support 이후 제한된 기간 동안 런타임 사용 중단을 지연시킬 수 있습니다. 이러한 사례의 예로는 고객이 마이그레이션 시간을 확보할 수 있도록 런타임에 대한 지원을 확장하는 것이 있습니다.
이 주제에서는 App Runner가 지원하는 Node.js 런타임 버전의 전체 세부 정보를 나열합니다.
**지원되는 런타임 버전 - 수정된 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-nodejs-releases.html)
**참고**
App Runner는 최근에 릴리스된 특정 주요 런타임에 대해 수정된 빌드 프로세스를 제공합니다. 따라서이 문서의 특정 섹션에 *수정된 App Runner 빌드* 및 *원래 App Runner 빌드*에 대한 참조가 표시됩니다. 자세한 내용은 단원을 참조하십시오[관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail).
**지원되는 런타임 버전 - 수정된 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-nodejs-releases.html)
**지원되는 런타임 버전 - 원래 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-nodejs-releases.html)
# Java 플랫폼 사용
AWS App Runner Java 플랫폼은 관리형 런타임을 제공합니다. 각 런타임을 사용하면 Java 버전을 기반으로 웹 애플리케이션을 사용하여 컨테이너를 쉽게 빌드하고 실행할 수 있습니다. Java 런타임을 사용하는 경우 App Runner는 관리형 Java 런타임 이미지로 시작합니다. 이 이미지는 [Amazon Linux Docker 이미지를](https://hub.docker.com/_/amazonlinux) 기반으로 하며 Java 버전 및 일부 도구에 대한 런타임 패키지를 포함합니다. App Runner는이 관리형 런타임 이미지를 기본 이미지로 사용하고 애플리케이션 코드를 추가하여 도커 이미지를 빌드합니다. 그런 다음이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
App Runner 콘솔 또는 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) API 작업을 사용하여 서비스를 [생성할 때 App Runner 서비스에](manage-create.md) 대한 런타임을 지정합니다. 런타임을 소스 코드의 일부로 지정할 수도 있습니다. 코드 리포지토리에 포함하는 [App Runner 구성 파일의](config-file.md) `runtime` 키워드를 사용합니다. 관리형 런타임의 이름 지정 규칙은 **입니다.
현재 지원되는 모든 Java 런타임은 Amazon Corretto를 기반으로 합니다. 유효한 Java 런타임 이름 및 버전은 섹션을 참조하세요[Java 런타임 릴리스 정보](service-source-code-java-releases.md).
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 [App Runner 구성 파일의](config-file.md) `runtime-version` 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로를 잠글 수 있습니다. App Runner는 서비스의 런타임만 하위 수준으로 업데이트합니다.
Amazon Corretto 런타임의 버전 구문:
| **런타임** | **구문** | **예제** |
| --- | --- | --- |
| corretto11 | `11.0[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]` | `11.0.13.08.1` |
| corretto8 | `8[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]` | `8.312.07.1` |
다음 예제에서는 버전 잠금을 보여줍니다.
+ `11.0.13` - Open JDK 업데이트 버전을 잠급니다. App Runner는 Open JDK 및 Amazon Corretto 하위 수준 빌드만 업데이트합니다.
+ `11.0.13.08.1` - 특정 버전으로 잠급니다. App Runner는 런타임 버전을 업데이트하지 않습니다.
**Topics**
+ [Java 런타임 구성](#service-source-code-java.config)
+ [Java 런타임 예제](#service-source-code-java.examples)
+ [Java 런타임 릴리스 정보](service-source-code-java-releases.md)
## Java 런타임 구성
관리형 런타임을 선택할 때는 최소한 빌드 및 실행 명령도 구성해야 합니다. App Runner 서비스를 [생성](manage-create.md)하거나 [업데이트](manage-configure.md)하는 동안 이를 구성합니다. 다음 방법 중 하나를 사용하여이 작업을 수행할 수 있습니다.
+ **App Runner 콘솔 사용** - 생성 프로세스 또는 **구성 탭의 빌드** 구성 섹션에서 명령을 지정합니다.
+ **App Runner API 사용** - [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) 또는 [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html) API 작업을 호출합니다. [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html) 데이터 형식의 `BuildCommand` 및 `StartCommand` 멤버를 사용하여 명령을 지정합니다.
+ **[구성 파일](config-file.md) 사용** - 최대 3개의 빌드 단계에서 하나 이상의 빌드 명령을 지정하고 애플리케이션을 시작하는 데 사용되는 단일 실행 명령을 지정합니다. 추가 선택적 구성 설정이 있습니다.
구성 파일을 제공하는 것은 선택 사항입니다. 콘솔 또는 API를 사용하여 App Runner 서비스를 생성할 때 App Runner가 구성 설정을 생성할 때 직접 가져오거나 구성 파일에서 가져올지 지정합니다.
## Java 런타임 예제
다음 예제에서는 Java 서비스를 빌드하고 실행하기 위한 App Runner 구성 파일을 보여줍니다. 마지막 예제는 Corretto 11 런타임 서비스에 배포할 수 있는 전체 Java 애플리케이션의 소스 코드입니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *11.0.13.08.1*입니다. 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Java 런타임 버전은 섹션을 참조하세요[Java 런타임 릴리스 정보](service-source-code-java-releases.md).
### 최소 Corretto 11 구성 파일
이 예제는 Corretto 11 관리형 런타임과 함께 사용할 수 있는 최소 구성 파일을 보여줍니다. App Runner가 최소 구성 파일로 가정하는 내용은 섹션을 참조하세요.
**Example apprunner.yaml**
```
version: 1.0
runtime: corretto11
build:
commands:
build:
- mvn clean package
run:
command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar .
```
### 확장 Corretto 11 구성 파일
이 예제에서는 Corretto 11 관리형 런타임에서 모든 구성 키를 사용하는 방법을 보여줍니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *11.0.13.08.1*입니다. 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Java 런타임 버전은 섹션을 참조하세요[Java 런타임 릴리스 정보](service-source-code-java-releases.md).
**Example apprunner.yaml**
```
version: 1.0
runtime: corretto11
build:
commands:
pre-build:
- yum install some-package
- scripts/prebuild.sh
build:
- mvn clean package
post-build:
- mvn clean test
env:
- name: M2
value: "/usr/local/apache-maven/bin"
- name: M2_HOME
value: "/usr/local/apache-maven/bin"
run:
runtime-version: 11.0.13.08.1
command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar .
network:
port: 8000
env: APP_PORT
env:
- name: MY_VAR_EXAMPLE
value: "example"
```
### Corretto 11 애플리케이션 소스 완료
이 예제는 Corretto 11 런타임 서비스에 배포할 수 있는 전체 Java 애플리케이션의 소스 코드를 보여줍니다.
**Example src/main/java/com/HelloWorld/HelloWorld.java**
```
package com.HelloWorld;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class HelloWorld {
@RequestMapping("/")
public String index(){
String s = "Hello World";
return s;
}
}
```
**Example src/main/java/com/HelloWorld/Main.java**
```
package com.HelloWorld;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class Main {
public static void main(String[] args) {
SpringApplication.run(Main.class, args);
}
}
```
**Example apprunner.yaml**
```
version: 1.0
runtime: corretto11
build:
commands:
build:
- mvn clean package
run:
command: java -Xms256m -jar target/HelloWorldJavaApp-1.0-SNAPSHOT.jar .
network:
port: 8080
```
**Example pom.xml**
```
4.0.0
org.springframework.boot
spring-boot-starter-parent
2.3.1.RELEASE
com.HelloWorld
HelloWorldJavaApp
1.0-SNAPSHOT
11
org.springframework.boot
spring-boot-starter-data-rest
org.springframework.boot
spring-boot-starter-test
test
org.junit.vintage
junit-vintage-engine
org.springframework.boot
spring-boot-maven-plugin
org.apache.maven.plugins
maven-compiler-plugin
3.8.0
11
```
# Java 런타임 릴리스 정보
이 주제에서는 App Runner가 지원하는 Java 런타임 버전에 대한 전체 세부 정보를 나열합니다.
**지원되는 런타임 버전 - 원래 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-java-releases.html)
**참고**
App Runner는 최근에 릴리스된 특정 주요 런타임에 대해 수정된 빌드 프로세스를 제공합니다. 따라서이 문서의 특정 섹션에 *수정된 App Runner 빌드* 및 *원래 App Runner 빌드*에 대한 참조가 표시됩니다. 자세한 내용은 단원을 참조하십시오[관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail).
# .NET 플랫폼 사용
**중요**
App Runner는 2025년 12월 1일에 **.NET 6**에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
AWS App Runner .NET 플랫폼은 관리형 런타임을 제공합니다. 각 런타임을 사용하면 .NET 버전을 기반으로 웹 애플리케이션을 사용하여 컨테이너를 쉽게 빌드하고 실행할 수 있습니다. .NET 런타임을 사용하는 경우 App Runner는 관리형 .NET 런타임 이미지로 시작합니다. 이 이미지는 [Amazon Linux Docker 이미지를](https://hub.docker.com/_/amazonlinux) 기반으로 하며 .NET 버전용 런타임 패키지와 일부 도구 및 인기 있는 종속성 패키지를 포함합니다. App Runner는이 관리형 런타임 이미지를 기본 이미지로 사용하고 애플리케이션 코드를 추가하여 도커 이미지를 빌드합니다. 그런 다음이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
App Runner 콘솔 또는 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) API 작업을 사용하여 서비스를 [생성할 때 App Runner 서비스에](manage-create.md) 대한 런타임을 지정합니다. 런타임을 소스 코드의 일부로 지정할 수도 있습니다. 코드 리포지토리에 포함하는 [App Runner 구성 파일의](config-file.md) `runtime` 키워드를 사용합니다. 관리형 런타임의 이름 지정 규칙은 **입니다.
유효한 .NET 런타임 이름 및 버전은 섹션을 참조하세요[.NET 런타임 릴리스 정보](service-source-code-dotnet-releases.md).
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 [App Runner 구성 파일의](config-file.md) `runtime-version` 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로를 잠글 수 있습니다. App Runner는 서비스의 런타임만 하위 수준으로 업데이트합니다.
.NET 런타임용 버전 구문: `major[.minor[.patch]]`
예: `6.0.9`
다음 예제에서는 버전 잠금을 보여줍니다.
+ `6.0` - 메이저 및 마이너 버전을 잠급니다. App Runner는 패치 버전만 업데이트합니다.
+ `6.0.9` - 특정 패치 버전으로 잠급니다. App Runner는 런타임 버전을 업데이트하지 않습니다.
**Topics**
+ [.NET 런타임 구성](#service-source-code-net6.config)
+ [.NET 런타임 예제](#service-source-code-net6.examples)
+ [.NET 런타임 릴리스 정보](service-source-code-dotnet-releases.md)
## .NET 런타임 구성
관리형 런타임을 선택할 때는 최소한 빌드 및 실행 명령도 구성해야 합니다. App Runner 서비스를 [생성](manage-create.md)하거나 [업데이트](manage-configure.md)하는 동안 이를 구성합니다. 다음 방법 중 하나를 사용하여이 작업을 수행할 수 있습니다.
+ **App Runner 콘솔 사용** - 생성 프로세스 또는 **구성 탭의 빌드** 구성 섹션에서 명령을 지정합니다.
+ **App Runner API 사용** - [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) 또는 [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html) API 작업을 호출합니다. [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html) 데이터 형식의 `BuildCommand` 및 `StartCommand` 멤버를 사용하여 명령을 지정합니다.
+ **[구성 파일](config-file.md) 사용** - 최대 3개의 빌드 단계에서 하나 이상의 빌드 명령을 지정하고 애플리케이션을 시작하는 데 사용되는 단일 실행 명령을 지정합니다. 추가 선택적 구성 설정이 있습니다.
구성 파일을 제공하는 것은 선택 사항입니다. 콘솔 또는 API를 사용하여 App Runner 서비스를 생성할 때 App Runner가 구성 설정을 생성할 때 직접 가져올지 또는 구성 파일에서 가져올지 지정합니다.
## .NET 런타임 예제
다음 예제에서는 .NET 서비스를 빌드하고 실행하기 위한 App Runner 구성 파일을 보여줍니다. 마지막 예제는 .NET 런타임 서비스에 배포할 수 있는 전체 .NET 애플리케이션의 소스 코드입니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *6.0.9*입니다. 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 .NET 런타임 버전은 섹션을 참조하세요[.NET 런타임 릴리스 정보](service-source-code-dotnet-releases.md).
### 미니멀 .NET 구성 파일
이 예제는 .NET 관리형 런타임과 함께 사용할 수 있는 최소 구성 파일을 보여줍니다. App Runner가 최소 구성 파일로 가정하는 내용은 섹션을 참조하세요[구성 파일 예제](config-file-examples.md#config-file-examples.managed).
**Example apprunner.yaml**
```
version: 1.0
runtime: dotnet6
build:
commands:
build:
- dotnet publish -c Release -o out
run:
command: dotnet out/HelloWorldDotNetApp.dll
```
### 확장 .NET 구성 파일
이 예제에서는 .NET 관리형 런타임에서 모든 구성 키를 사용하는 방법을 보여줍니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *6.0.9*입니다. 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 .NET 런타임 버전은 섹션을 참조하세요[.NET 런타임 릴리스 정보](service-source-code-dotnet-releases.md).
**Example apprunner.yaml**
```
version: 1.0
runtime: dotnet6
build:
commands:
pre-build:
- scripts/prebuild.sh
build:
- dotnet publish -c Release -o out
post-build:
- scripts/postbuild.sh
env:
- name: MY_VAR_EXAMPLE
value: "example"
run:
runtime-version: 6.0.9
command: dotnet out/HelloWorldDotNetApp.dll
network:
port: 5000
env: APP_PORT
env:
- name: ASPNETCORE_URLS
value: "http://*:5000"
```
### 전체 .NET 애플리케이션 소스
이 예제는 .NET 런타임 서비스에 배포할 수 있는 전체 .NET 애플리케이션의 소스 코드를 보여줍니다.
**참고**
다음 명령을 실행하여 간단한 .NET 6 웹 앱을 생성합니다. ` dotnet new web --name HelloWorldDotNetApp -f net6.0`
생성된 .NET 6 웹 앱`apprunner.yaml`에를 추가합니다.
**Example HelloWorldDotNetApp**
```
version: 1.0
runtime: dotnet6
build:
commands:
build:
- dotnet publish -c Release -o out
run:
command: dotnet out/HelloWorldDotNetApp.dll
network:
port: 5000
env: APP_PORT
env:
- name: ASPNETCORE_URLS
value: "http://*:5000"
```
# .NET 런타임 릴리스 정보
**중요**
App Runner는 2025년 12월 1일에 **.NET 6**에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
이 주제에서는 App Runner가 지원하는 .NET 런타임 버전에 대한 전체 세부 정보를 나열합니다.
**지원되는 런타임 버전 - 원래 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-dotnet-releases.html)
**참고**
App Runner는 최근에 릴리스된 특정 주요 런타임에 대해 수정된 빌드 프로세스를 제공합니다. 따라서이 문서의 특정 섹션에 *수정된 App Runner 빌드* 및 *원래 App Runner 빌드*에 대한 참조가 표시됩니다. 자세한 내용은 단원을 참조하십시오[관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail).
# PHP 플랫폼 사용
**중요**
App Runner는 2025년 **12월 31일에 PHP 8.**1에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
AWS App Runner PHP 플랫폼은 관리형 런타임을 제공합니다. 각 런타임을 사용하여 PHP 버전을 기반으로 웹 애플리케이션으로 컨테이너를 빌드하고 실행할 수 있습니다. PHP 런타임을 사용하는 경우 App Runner는 관리형 PHP 런타임 이미지로 시작합니다. 이 이미지는 [Amazon Linux Docker 이미지를](https://hub.docker.com/_/amazonlinux) 기반으로 하며 PHP 버전 및 일부 도구에 대한 런타임 패키지를 포함합니다. App Runner는이 관리형 런타임 이미지를 기본 이미지로 사용하고 애플리케이션 코드를 추가하여 도커 이미지를 빌드합니다. 그런 다음이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
App Runner 콘솔 또는 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) API 작업을 사용하여 서비스를 [생성할 때 App Runner 서비스에](manage-create.md) 대한 런타임을 지정합니다. 런타임을 소스 코드의 일부로 지정할 수도 있습니다. 코드 리포지토리에 포함하는 [App Runner 구성 파일의](config-file.md) `runtime` 키워드를 사용합니다. 관리형 런타임의 이름 지정 규칙은 **입니다.
유효한 PHP 런타임 이름 및 버전은 섹션을 참조하세요[PHP 런타임 릴리스 정보](service-source-code-php-releases.md).
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 [App Runner 구성 파일의](config-file.md) `runtime-version` 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로를 잠글 수 있습니다. App Runner는 서비스의 런타임만 하위 수준으로 업데이트합니다.
PHP 런타임의 버전 구문: `major[.minor[.patch]]`
예: `8.1.10`
다음은 버전 잠금의 예입니다.
+ `8.1` - 메이저 및 마이너 버전을 잠급니다. App Runner는 패치 버전만 업데이트합니다.
+ `8.1.10` - 특정 패치 버전으로 잠급니다. App Runner는 런타임 버전을 업데이트하지 않습니다.
**중요**
기본 리포지토리 루트 [디렉터리 이외의 위치에서 App Runner 서비스의 코드 리포지토리 소스](service-source-code.md#service-source-code.source-directory) 디렉터리를 지정하려면 PHP 관리형 런타임 버전이 PHP `8.1.22` 이상이어야 합니다. 이전 PHP 런타임 버전은 기본 루트 소스 디렉터리만 사용할 `8.1.22` 수 있습니다.
**Topics**
+ [PHP 런타임 구성](#service-source-code-php.config)
+ [호환성](#service-source-code-php.compatibility)
+ [PHP 런타임 예제](#service-source-code-php.examples)
+ [PHP 런타임 릴리스 정보](service-source-code-php-releases.md)
## PHP 런타임 구성
관리형 런타임을 선택할 때는 최소한 빌드 및 실행 명령도 구성해야 합니다. App Runner 서비스를 [생성](manage-create.md)하거나 [업데이트](manage-configure.md)하는 동안 이를 구성합니다. 다음 방법 중 하나를 사용하여이 작업을 수행할 수 있습니다.
+ **App Runner 콘솔 사용** - 생성 프로세스 또는 **구성 탭의 빌드** 구성 섹션에서 명령을 지정합니다.
+ **App Runner API 사용** - [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) 또는 [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html) API 작업을 호출합니다. [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html) 데이터 형식의 `BuildCommand` 및 `StartCommand` 멤버를 사용하여 명령을 지정합니다.
+ **[구성 파일](config-file.md) 사용** - 최대 3개의 빌드 단계에서 하나 이상의 빌드 명령을 지정하고 애플리케이션을 시작하는 데 사용되는 단일 실행 명령을 지정합니다. 추가 선택적 구성 설정이 있습니다.
구성 파일을 제공하는 것은 선택 사항입니다. 콘솔 또는 API를 사용하여 App Runner 서비스를 생성할 때 App Runner가 구성 설정을 생성할 때 직접 가져올지 또는 구성 파일에서 가져올지 지정합니다.
## 호환성
다음 웹 서버 중 하나를 사용하여 PHP 플랫폼에서 App Runner 서비스를 실행할 수 있습니다.
+ Apache HTTP Server
+ NGINX
Apache HTTP Server 및 NGINX는 PHP-FPM과 호환됩니다. 다음 중 하나를 *NGINX* 사용하여 *Apache HTTP Server* 및를 시작할 수 있습니다.
+ [감독자](http://supervisord.org/introduction.html#supervisor-components/) - 실행에 대한 자세한 내용은 감독자 실행을 *supervisord*참조하세요. [http://supervisord.org/running.html#running-supervisord](http://supervisord.org/running.html#running-supervisord)
+ 시작 스크립트
*Apache HTTP Server* 또는 *NGINX*를 사용하여 PHP 플랫폼으로 App Runner 서비스를 구성하는 방법에 대한 예는 섹션을 참조하세요[전체 PHP 애플리케이션 소스](#service-source-code-php.examples.end2end).
### 파일 구조
는 웹 서버의 `root` 디렉터리 아래에 있는 `public` 폴더에 설치해야 `index.php` 합니다.
**참고**
`startup.sh` 또는 `supervisord.conf` 파일은 웹 서버의 루트 디렉터리에 저장하는 것이 좋습니다. `start` 명령이 `startup.sh` 또는 `supervisord.conf` 파일이 저장된 위치를 가리키는지 확인합니다.
다음은를 사용하는 경우 파일 구조의 예입니다*supervisord*.
```
/
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ supervisord.conf
```
다음은 *시작 스크립트를 사용하는 경우 파일 구조의 *예입니다.
```
/
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```
App Runner 서비스에 지정된 코드 리포지토리 [소스 디렉터리](service-source-code.md#service-source-code.source-directory)에 이러한 파일 구조를 저장하는 것이 좋습니다.
```
//
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```
**중요**
기본 리포지토리 루트 [디렉터리 이외의 위치에서 App Runner 서비스의 코드 리포지토리 소스](service-source-code.md#service-source-code.source-directory) 디렉터리를 지정하려면 PHP 관리형 런타임 버전이 PHP `8.1.22` 이상이어야 합니다. 이전의 PHP 런타임 버전은 기본 루트 소스 디렉터리만 사용할 `8.1.22` 수 있습니다.
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. [App Runner 구성 파일의](config-file.md) `runtime-version` 키워드를 사용하여 버전 잠금을 지정하지 않는 한 서비스는 기본적으로 최신 런타임을 사용합니다.
## PHP 런타임 예제
다음은 PHP 서비스를 빌드하고 실행하는 데 사용되는 App Runner 구성 파일의 예입니다.
### 최소 PHP 구성 파일
다음 예제는 PHP 관리형 런타임과 함께 사용할 수 있는 최소 구성 파일입니다. 최소 구성 파일에 대한 자세한 내용은 섹션을 참조하세요[구성 파일 예제](config-file-examples.md#config-file-examples.managed).
**Example apprunner.yaml**
```
version: 1.0
runtime: php81
build:
commands:
build:
- echo example build command for PHP
run:
command: ./startup.sh
```
### 확장 PHP 구성 파일
다음 예제에서는 PHP 관리형 런타임과 함께 모든 구성 키를 사용합니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *8.1.10*입니다. 이를 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 PHP 런타임 버전은 섹션을 참조하세요[PHP 런타임 릴리스 정보](service-source-code-php-releases.md).
**Example apprunner.yaml**
```
version: 1.0
runtime: php81
build:
commands:
pre-build:
- scripts/prebuild.sh
build:
- echo example build command for PHP
post-build:
- scripts/postbuild.sh
env:
- name: MY_VAR_EXAMPLE
value: "example"
run:
runtime-version: 8.1.10
command: ./startup.sh
network:
port: 5000
env: APP_PORT
env:
- name: MY_VAR_EXAMPLE
value: "example"
```
### 전체 PHP 애플리케이션 소스
다음 예제는 *Apache HTTP Server* 또는를 사용하여 PHP 런타임 서비스에 배포하는 데 사용할 수 있는 PHP 애플리케이션 소스 코드입니다*NGINX*. 이 예제에서는 기본 파일 구조를 사용한다고 가정합니다.
#### 를 Apache HTTP Server 사용하여에서 PHP 플랫폼 실행 supervisord
**Example 파일 구조**
+ `supervisord.conf` 파일은 리포지토리의 어디에나 저장할 수 있습니다. `start` 명령이 `supervisord.conf` 파일이 저장되는 위치를 가리키는지 확인합니다.
+ 는 `root` 디렉터리 아래의 `public` 폴더에 설치해야 `index.php` 합니다.
```
/
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ supervisord.conf
```
**Example supervisord.conf**
```
[supervisord]
nodaemon=true
[program:httpd]
command=httpd -DFOREGROUND
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
[program:php-fpm]
command=php-fpm -F
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
```
**Example apprunner.yaml**
```
version: 1.0
runtime: php81
build:
commands:
build:
- PYTHON=python2 amazon-linux-extras install epel
- yum -y install supervisor
run:
command: supervisord
network:
port: 8080
env: APP_PORT
```
**Example index.php**
```
First PHP App
");
?>
```
#### 를 Apache HTTP Server 사용하여에서 PHP 플랫폼 실행 startup script
**Example 파일 구조**
+ `startup.sh` 파일은 리포지토리의 모든 위치에 저장할 수 있습니다. `start` 명령이 `startup.sh` 파일이 저장되는 위치를 가리키는지 확인합니다.
+ 는 `root` 디렉터리 아래의 `public` 폴더에 설치해야 `index.php` 합니다.
```
/
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```
**Example startup.sh**
```
#!/bin/bash
set -o monitor
trap exit SIGCHLD
# Start apache
httpd -DFOREGROUND &
# Start php-fpm
php-fpm -F &
wait
```
**참고**
`startup.sh` 파일을 Git 리포지토리에 커밋하기 전에 파일을 실행 파일로 저장해야 합니다. `chmod +x startup.sh`를 사용하여 `startup.sh` 파일에 대한 실행 권한을 설정합니다.
`startup.sh` 파일을 실행 파일로 저장하지 않는 경우를 `apprunner.yaml` 파일에 `build` 명령`chmod +x startup.sh`으로 입력합니다.
**Example apprunner.yaml**
```
version: 1.0
runtime: php81
build:
commands:
build:
- echo example build command for PHP
run:
command: ./startup.sh
network:
port: 8080
env: APP_PORT
```
**Example index.php**
```
First PHP App
");
?>
```
#### 를 NGINX 사용하여에서 PHP 플랫폼 실행 supervisord
**Example 파일 구조**
+ `supervisord.conf` 파일은 리포지토리의 어디에나 저장할 수 있습니다. `start` 명령이 `supervisord.conf` 파일이 저장되는 위치를 가리키는지 확인합니다.
+ 는 `root` 디렉터리 아래의 `public` 폴더에 설치해야 `index.php` 합니다.
```
/
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ supervisord.conf
```
**Example supervisord.conf**
```
[supervisord]
nodaemon=true
[program:nginx]
command=nginx -g "daemon off;"
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
[program:php-fpm]
command=php-fpm -F
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
```
**Example apprunner.yaml**
```
version: 1.0
runtime: php81
build:
commands:
build:
- PYTHON=python2 amazon-linux-extras install epel
- yum -y install supervisor
run:
command: supervisord
network:
port: 8080
env: APP_PORT
```
**Example index.php**
```
First PHP App
");
?>
```
#### 를 NGINX 사용하여에서 PHP 플랫폼 실행 startup script
**Example 파일 구조**
+ `startup.sh` 파일은 리포지토리의 모든 위치에 저장할 수 있습니다. `start` 명령이 `startup.sh` 파일이 저장되는 위치를 가리키는지 확인합니다.
+ 는 `root` 디렉터리 아래의 `public` 폴더에 설치해야 `index.php` 합니다.
```
/
├─ public/
│ ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```
**Example startup.sh**
```
#!/bin/bash
set -o monitor
trap exit SIGCHLD
# Start nginx
nginx -g 'daemon off;' &
# Start php-fpm
php-fpm -F &
wait
```
**참고**
`startup.sh` 파일을 Git 리포지토리에 커밋하기 전에 파일을 실행 파일로 저장해야 합니다. `chmod +x startup.sh`를 사용하여 `startup.sh` 파일에 대한 실행 권한을 설정합니다.
`startup.sh` 파일을 실행 파일로 저장하지 않는 경우를 `apprunner.yaml` 파일에 `build` 명령`chmod +x startup.sh`으로 입력합니다.
**Example apprunner.yaml**
```
version: 1.0
runtime: php81
build:
commands:
build:
- echo example build command for PHP
run:
command: ./startup.sh
network:
port: 8080
env: APP_PORT
```
**Example index.php**
```
First PHP App
");
?>
```
# PHP 런타임 릴리스 정보
**중요**
App Runner는 2025년 **12월 31일에 PHP 8.**1에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
이 주제에서는 App Runner가 지원하는 PHP 런타임 버전에 대한 전체 세부 정보를 나열합니다.
**지원되는 런타임 버전 - 원래 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-php-releases.html)
**참고**
App Runner는 최근에 릴리스된 특정 주요 런타임에 대해 수정된 빌드 프로세스를 제공합니다. 따라서이 문서의 특정 섹션에 *수정된 App Runner 빌드* 및 *원래 App Runner 빌드*에 대한 참조가 표시됩니다. 자세한 내용은 단원을 참조하십시오[관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail).
# Ruby 플랫폼 사용
**중요**
App Runner는 2025년 **12월 1일에 Ruby 3.**1에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
AWS App Runner Ruby 플랫폼은 관리형 런타임을 제공합니다. 각 런타임을 사용하면 Ruby 버전을 기반으로 웹 애플리케이션을 사용하여 컨테이너를 쉽게 빌드하고 실행할 수 있습니다. Ruby 런타임을 사용하는 경우 App Runner는 관리형 Ruby 런타임 이미지로 시작합니다. 이 이미지는 [Amazon Linux Docker 이미지를](https://hub.docker.com/_/amazonlinux) 기반으로 하며 Ruby 버전 및 일부 도구에 대한 런타임 패키지를 포함합니다. App Runner는이 관리형 런타임 이미지를 기본 이미지로 사용하고 애플리케이션 코드를 추가하여 도커 이미지를 빌드합니다. 그런 다음이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
App Runner 콘솔 또는 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) API 작업을 사용하여 서비스를 [생성할 때 App Runner 서비스에](manage-create.md) 대한 런타임을 지정합니다. 런타임을 소스 코드의 일부로 지정할 수도 있습니다. 코드 리포지토리에 포함하는 [App Runner 구성 파일의](config-file.md) `runtime` 키워드를 사용합니다. 관리형 런타임의 이름 지정 규칙은 **입니다.
유효한 Ruby 런타임 이름 및 버전은 섹션을 참조하세요[Ruby 런타임 릴리스 정보](service-source-code-ruby-releases.md).
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 [App Runner 구성 파일의](config-file.md) `runtime-version` 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로를 잠글 수 있습니다. App Runner는 서비스의 런타임만 하위 수준으로 업데이트합니다.
Ruby 런타임용 버전 구문: `major[.minor[.patch]]`
예: `3.1.2`
다음 예제에서는 버전 잠금을 보여줍니다.
+ `3.1` - 메이저 및 마이너 버전을 잠급니다. App Runner는 패치 버전만 업데이트합니다.
+ `3.1.2` - 특정 패치 버전으로 잠급니다. App Runner는 런타임 버전을 업데이트하지 않습니다.
**Topics**
+ [Ruby 런타임 구성](#service-source-code-ruby.config)
+ [Ruby 런타임 예제](#service-source-code-ruby.examples)
+ [Ruby 런타임 릴리스 정보](service-source-code-ruby-releases.md)
## Ruby 런타임 구성
관리형 런타임을 선택할 때는 최소한 빌드 및 실행 명령도 구성해야 합니다. App Runner 서비스를 [생성](manage-create.md)하거나 [업데이트](manage-configure.md)하는 동안 이를 구성합니다. 다음 방법 중 하나를 사용하여이 작업을 수행할 수 있습니다.
+ **App Runner 콘솔 사용** - 생성 프로세스 또는 **구성 탭의 빌드** 구성 섹션에서 명령을 지정합니다.
+ **App Runner API 사용** - [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) 또는 [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html) API 작업을 호출합니다. [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html) 데이터 형식의 `BuildCommand` 및 `StartCommand` 멤버를 사용하여 명령을 지정합니다.
+ **[구성 파일](config-file.md) 사용** - 최대 3개의 빌드 단계에서 하나 이상의 빌드 명령을 지정하고 애플리케이션을 시작하는 데 사용되는 단일 실행 명령을 지정합니다. 추가 선택적 구성 설정이 있습니다.
구성 파일을 제공하는 것은 선택 사항입니다. 콘솔 또는 API를 사용하여 App Runner 서비스를 생성할 때 App Runner가 구성 설정을 생성할 때 직접 가져오거나 구성 파일에서 가져올지 지정합니다.
## Ruby 런타임 예제
다음 예제에서는 Ruby 서비스를 빌드하고 실행하기 위한 App Runner 구성 파일을 보여줍니다.
### 최소 Ruby 구성 파일
이 예제는 Ruby 관리형 런타임과 함께 사용할 수 있는 최소 구성 파일을 보여줍니다. App Runner가 최소 구성 파일로 가정하는 내용은 섹션을 참조하세요[구성 파일 예제](config-file-examples.md#config-file-examples.managed).
**Example apprunner.yaml**
```
version: 1.0
runtime: ruby31
build:
commands:
build:
- bundle install
run:
command: bundle exec rackup --host 0.0.0.0 -p 8080
```
### 확장 Ruby 구성 파일
이 예제에서는 Ruby 관리형 런타임에서 모든 구성 키를 사용하는 방법을 보여줍니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *3.1.2*입니다. 이를 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Ruby 런타임 버전은 섹션을 참조하세요[Ruby 런타임 릴리스 정보](service-source-code-ruby-releases.md).
**Example apprunner.yaml**
```
version: 1.0
runtime: ruby31
build:
commands:
pre-build:
- scripts/prebuild.sh
build:
- bundle install
post-build:
- scripts/postbuild.sh
env:
- name: MY_VAR_EXAMPLE
value: "example"
run:
runtime-version: 3.1.2
command: bundle exec rackup --host 0.0.0.0 -p 4567
network:
port: 4567
env: APP_PORT
env:
- name: MY_VAR_EXAMPLE
value: "example"
```
### 전체 Ruby 애플리케이션 소스
이 예제에서는 Ruby 런타임 서비스에 배포할 수 있는 전체 Ruby 애플리케이션의 소스 코드를 보여줍니다.
**Example server.rb**
```
# server.rb
require 'sinatra'
get '/' do
'Hello World!'
end
```
**Example config.ru**
```
# config.ru
require './server'
run Sinatra::Application
```
**Example Gemfile**
```
# Gemfile
source 'https://rubygems.org (https://rubygems.org/)'
gem 'sinatra'
gem 'puma'
```
**Example apprunner.yaml**
```
version: 1.0
runtime: ruby31
build:
commands:
build:
- bundle install
run:
command: bundle exec rackup --host 0.0.0.0 -p 4567
network:
port: 4567
env: APP_PORT
```
# Ruby 런타임 릴리스 정보
**중요**
App Runner는 2025년 **12월 1일에 Ruby 3.**1에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
이 주제에서는 App Runner가 지원하는 Ruby 런타임 버전의 전체 세부 정보를 나열합니다.
**지원되는 런타임 버전 - 원래 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-ruby-releases.html)
**참고**
App Runner는 최근에 릴리스된 특정 주요 런타임에 대해 수정된 빌드 프로세스를 제공합니다. 따라서이 문서의 특정 섹션에 *수정된 App Runner 빌드* 및 *원래 App Runner 빌드*에 대한 참조가 표시됩니다. 자세한 내용은 단원을 참조하십시오[관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail).
# Go 플랫폼 사용
**중요**
App Runner는 **2025년 12월 1일에 Go 1.18**에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
AWS App Runner Go 플랫폼은 관리형 런타임을 제공합니다. 각 런타임을 사용하면 Go 버전을 기반으로 웹 애플리케이션을 사용하여 컨테이너를 쉽게 빌드하고 실행할 수 있습니다. Go 런타임을 사용하는 경우 App Runner는 관리형 Go 런타임 이미지로 시작합니다. 이 이미지는 [Amazon Linux Docker 이미지를](https://hub.docker.com/_/amazonlinux) 기반으로 하며 Go 버전 및 일부 도구에 대한 런타임 패키지를 포함합니다. App Runner는이 관리형 런타임 이미지를 기본 이미지로 사용하고 애플리케이션 코드를 추가하여 도커 이미지를 빌드합니다. 그런 다음이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
App Runner 콘솔 또는 [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) API 작업을 사용하여 서비스를 [생성할 때 App Runner 서비스에](manage-create.md) 대한 런타임을 지정합니다. 런타임을 소스 코드의 일부로 지정할 수도 있습니다. 코드 리포지토리에 포함하는 [App Runner 구성 파일의](config-file.md) `runtime` 키워드를 사용합니다. 관리형 런타임의 이름 지정 규칙은 **입니다.
유효한 Go 런타임 이름 및 버전은 섹션을 참조하세요[Go 런타임 릴리스 정보](service-source-code-go-releases.md).
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 [App Runner 구성 파일의](config-file.md) `runtime-version` 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로를 잠글 수 있습니다. App Runner는 서비스의 런타임만 하위 수준으로 업데이트합니다.
Go 런타임용 버전 구문: `major[.minor[.patch]]`
예: `1.18.7`
다음 예제에서는 버전 잠금을 보여줍니다.
+ `1.18` - 메이저 및 마이너 버전을 잠급니다. App Runner는 패치 버전만 업데이트합니다.
+ `1.18.7` - 특정 패치 버전으로 잠급니다. App Runner는 런타임 버전을 업데이트하지 않습니다.
**Topics**
+ [Go 런타임 구성](#service-source-code-go1.config)
+ [Go 런타임 예제](#service-source-code-go1.examples)
+ [Go 런타임 릴리스 정보](service-source-code-go-releases.md)
## Go 런타임 구성
관리형 런타임을 선택할 때는 최소한 빌드 및 실행 명령도 구성해야 합니다. App Runner 서비스를 [생성](manage-create.md)하거나 [업데이트](manage-configure.md)하는 동안 이를 구성합니다. 다음 방법 중 하나를 사용하여이 작업을 수행할 수 있습니다.
+ **App Runner 콘솔 사용** - 생성 프로세스 또는 **구성 탭의 빌드** 구성 섹션에서 명령을 지정합니다.
+ **App Runner API 사용** - [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html) 또는 [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html) API 작업을 호출합니다. [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html) 데이터 형식의 `BuildCommand` 및 `StartCommand` 멤버를 사용하여 명령을 지정합니다.
+ **[구성 파일](config-file.md) 사용** - 최대 3개의 빌드 단계에서 하나 이상의 빌드 명령을 지정하고 애플리케이션을 시작하는 데 사용되는 단일 실행 명령을 지정합니다. 추가 선택적 구성 설정이 있습니다.
구성 파일을 제공하는 것은 선택 사항입니다. 콘솔 또는 API를 사용하여 App Runner 서비스를 생성할 때 App Runner가 구성 설정을 생성할 때 직접 가져오거나 구성 파일에서 가져올지 지정합니다.
## Go 런타임 예제
다음 예제에서는 Go 서비스를 빌드하고 실행하기 위한 App Runner 구성 파일을 보여줍니다.
### Minimal Go 구성 파일
이 예제는 Go 관리형 런타임과 함께 사용할 수 있는 최소 구성 파일을 보여줍니다. App Runner가 최소 구성 파일로 가정하는 내용은 섹션을 참조하세요[구성 파일 예제](config-file-examples.md#config-file-examples.managed).
**Example apprunner.yaml**
```
version: 1.0
runtime: go1
build:
commands:
build:
- go build main.go
run:
command: ./main
```
### 확장 Go 구성 파일
이 예제에서는 Go 관리형 런타임에서 모든 구성 키를 사용하는 방법을 보여줍니다.
**참고**
이 예제에서 사용되는 런타임 버전은 *1.18.7*입니다. 이를 사용하려는 버전으로 바꿀 수 있습니다. 지원되는 최신 Go 런타임 버전은 섹션을 참조하세요[Go 런타임 릴리스 정보](service-source-code-go-releases.md).
**Example apprunner.yaml**
```
version: 1.0
runtime: go1
build:
commands:
pre-build:
- scripts/prebuild.sh
build:
- go build main.go
post-build:
- scripts/postbuild.sh
env:
- name: MY_VAR_EXAMPLE
value: "example"
run:
runtime-version: 1.18.7
command: ./main
network:
port: 3000
env: APP_PORT
env:
- name: MY_VAR_EXAMPLE
value: "example"
```
### 전체 Go 애플리케이션 소스
이 예제에서는 Go 런타임 서비스에 배포할 수 있는 전체 Go 애플리케이션의 소스 코드를 보여줍니다.
**Example main.go**
```
package main
import (
"fmt"
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Welcome to App Runner
")
})
fmt.Println("Starting the server on :3000...")
http.ListenAndServe(":3000", nil)
}
```
**Example apprunner.yaml**
```
version: 1.0
runtime: go1
build:
commands:
build:
- go build main.go
run:
command: ./main
network:
port: 3000
env: APP_PORT
```
# Go 런타임 릴리스 정보
**중요**
App Runner는 **2025년 12월 1일에 Go 1.18**에 대한 지원을 종료합니다. 권장 사항 및 자세한 내용은 섹션을 참조하세요[관리형 런타임 버전에 대한 지원 종료](service-source-code.md#service-source-code.managed-platforms.eos).
이 주제에서는 App Runner가 지원하는 Go 런타임 버전에 대한 전체 세부 정보를 나열합니다.
**지원되는 런타임 버전 - 원래 App Runner 빌드**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apprunner/latest/dg/service-source-code-go-releases.html)
**참고**
App Runner는 최근에 릴리스된 특정 주요 런타임에 대해 수정된 빌드 프로세스를 제공합니다. 따라서이 문서의 특정 섹션에 *수정된 App Runner 빌드* 및 *원래 App Runner 빌드*에 대한 참조가 표시됩니다. 자세한 내용은 단원을 참조하십시오[관리형 런타임 버전 및 App Runner 빌드](service-source-code.md#service-source-code.build-detail).