기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Elastic Beanstalk .NET Windows 플랫폼 사용
이 주제에서는 Elastic Beanstalk에서 ASP.NET 및 .NET Core Windows 웹 애플리케이션을 구성, 빌드 및 실행하는 방법을 설명합니다.
AWS Elastic Beanstalk 는 .NET 프로그래밍 프레임워크 및 Windows Server의 다양한 버전에 대해 여러 플랫폼을 지원합니다. 전체 목록은 *AWS Elastic Beanstalk 플랫폼* 문서의 [IIS를 사용하는 Windows Server의 .NET](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) 단원을 참조하세요.
Elastic Beanstalk에서는 Elastic Beanstalk 환경의 EC2 인스턴스에서 실행하는 소프트웨어를 사용자 지정하는 데 사용할 수 있는 [구성 옵션](command-options.md)을 제공합니다. 애플리케이션에 필요한 환경 변수를 구성하고, Amazon S3에 대한 로그 교체를 활성화하고, .NET Framework 설정을 지정할 수 있습니다.
Elastic Beanstalk 콘솔에서 [실행 환경의 구성 수정](environment-configuration-methods-after.md)을 위해 구성 옵션을 사용할 수 있습니다. [저장된 구성](environment-configuration-savedconfig.md)을 사용해 설정을 저장하면 환경 종료 시 구성이 훼손되지 않도록 할 수 있으며, 추후 기타 환경에서도 적용할 수 있습니다.
소스 코드에 설정을 저장하려면 [구성 파일](ebextensions.md)을 포함시킬 수 있습니다. 구성 파일 설정은 환경을 생성하거나 애플리케이션을 배포할 때마다 적용됩니다. 구성 파일을 사용하여 패키지를 설치하거나, 스크립트를 실행하거나, 배포 중 기타 인스턴스 사용자 지정 작업을 수행할 수 있습니다.
Elastic Beanstalk 콘솔에 적용된 설정이 구성 파일에 적용된 동일한 설정(있는 경우)을 덮어씁니다. 이렇게 함으로써 구성 파일은 기본 설정을 갖는 동시에 콘솔에서 환경 특정 설정으로 설정을 덮어 쓸 수 있습니다. 우선 적용 및 설정을 변경하는 다른 방법에 대한 자세한 내용은 [구성 옵션](command-options.md) 단원을 참조하십시오.
## Elastic Beanstalk 콘솔에서 .NET 환경 구성
Elastic Beanstalk 콘솔을 사용하여 Amazon S3에 대한 로그 교체를 활성화하고, 애플리케이션에서 읽을 수 있도록 환경 변수를 구성하고, .NET Framework 설정을 변경할 수 있습니다.
**Elastic Beanstalk 콘솔에서 .NET 환경을 구성하려면**
1. [Elastic Beanstalk 콘솔](https://console.aws.amazon.com/elasticbeanstalk)을 열고 **리전** 목록에서를 선택합니다 AWS 리전.
1. 탐색 창에서 **환경**을 선택한 다음 목록에서 환경의 이름을 선택합니다.
1. 탐색 창에서 **구성**을 선택합니다.
1. **업데이트, 모니터링 및 로깅** 구성 범주에서 **편집**을 선택합니다.
### 컨테이너 옵션
+ **대상 .NET 런타임** – CLR v2를 실행하려면 `2.0`으로 설정합니다.
+ **32비트 애플리케이션 활성화** – 32비트 애플리케이션을 실행하려면 `True`로 설정합니다.
### 로그 옵션
로그 옵션 섹션에는 다음 두 가지 설정이 있습니다.
+ **인스턴스 프로파일** – 애플리케이션과 연결된 Amazon S3 버킷에 액세스할 권한이 있는 인스턴스 프로파일을 지정합니다.
+ **Amazon S3에 대한 로그 파일 교체 활성화(Enable log file rotation to Amazon S3)** – 애플리케이션과 연결된 Amazon S3 버킷에 애플리케이션의 Amazon EC2 인스턴스에 대한 로그 파일을 복사하는지 여부를 지정합니다.
### 환경 속성
**환경 속성** 섹션에서는 애플리케이션을 실행하는 Amazon EC2 인스턴스의 환경 속성 설정을 지정할 수 있습니다. 이 설정은 키 값 페어로 애플리케이션에 전달됩니다. `System.GetEnvironmentVariable`을 사용하여 이것을 읽습니다. `web.config`와 환경 속성과 동일한 키가 존재할 수 있습니다. `System.Configuration` 네임스페이스를 사용하여 `web.config`에서 값을 읽습니다.
```
NameValueCollection appConfig = ConfigurationManager.AppSettings;
string endpoint = appConfig["API_ENDPOINT"];
```
자세한 내용은 [환경 변수 및 기타 소프트웨어 설정](environments-cfg-softwaresettings.md)를 참조하십시오.
## aws:elasticbeanstalk:container:dotnet:apppool 네임스페이스
[구성 파일](ebextensions.md)을 사용하여 구성 옵션을 설정하고 배포 중 다른 인스턴스 구성 작업을 수행할 수 있습니다. 구성 옵션은 [플랫폼별](command-options-specific.md)로 다르거나 Elastic Beanstalk 서비스의 [모든 플랫폼](command-options-general.md)에 전체적으로 적용될 수 있습니다. 구성 옵션은 *네임스페이스*로 구성됩니다.
.NET 프레임워크는 `aws:elasticbeanstalk:container:dotnet:apppool` 네임스페이스에 .NET 런타임을 구성하는 데 사용할 수 있는 옵션을 정의합니다.
다음 예제 구성 파일은 이 네임스페이스에서 이용 가능한 각 옵션의 설정을 표시합니다.
**Example .ebextensions/dotnet-settings.config**
```
option_settings:
aws:elasticbeanstalk:container:dotnet:apppool:
Target Runtime: 2.0
Enable 32-bit Applications: True
```
Elastic Beanstalk는 사용자가 환경을 맞춤형으로 지정할 수 있는 다양한 구성 옵션을 제공합니다. 구성 파일 외에 콘솔, 저장된 구성, EB CLI 또는 AWS CLI를 통해 구성 옵션을 설정할 수도 있습니다. 자세한 내용은 [구성 옵션](command-options.md)를 참조하세요.
# Elastic Beanstalk Windows Server 플랫폼의 메이저 버전 간 마이그레이션
AWS Elastic Beanstalk 에는 Windows Server 플랫폼의 여러 주요 버전이 있습니다. 이 페이지에서는 각 메이저 버전에 대한 주요 개선 사항과 최신 버전으로 마이그레이션하기 전에 고려할 사항에 대해 설명합니다.
Windows Server 플랫폼은 현재 버전 2(v2)에 있습니다. 애플리케이션에서 v2 이전의 Windows Server 플랫폼 버전을 사용하는 경우, v2로 마이그레이션하는 것이 좋습니다.
## Windows Server 플랫폼의 메이저 버전의 새 기능
### Windows Server 플랫폼 V2
Elastic Beanstalk Windows Server 플랫폼의 버전 2(v2)는 [2019년 2월에 릴리스](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-02-21-windows-v2.html)되었습니다. V2는 Windows Server 플랫폼의 동작을 몇 가지 중요한 방식으로 Elastic Beanstalk의 Linux 기반 플랫폼의 동작과 일치시킵니다. V2는 이전의 v1과 완전히 호환되므로, v1으로부터 쉽게 마이그레이션할 수 있습니다.
Windows Server 플랫폼은 현재 다음 사항을 지원합니다.
+ *버전 관리* - 각 릴리스에 새 버전 번호가 할당되며, 사용자가 환경을 생성하여 관리할 때 이전 버전(아직 사용 가능한)을 참조할 수 있습니다.
+ *확장 상태* – 자세한 내용은 [Elastic Beanstalk의 향상된 상태 보고 및 모니터링](health-enhanced.md) 단원을 참조하십시오.
+ *변경 불가능* 및 *추가 배포를 사용한 롤링* 배포 – 배포 정책에 대한 자세한 내용은 [Elastic Beanstalk 환경에 애플리케이션 배포](using-features.deploy-existing-version.md) 단원을 참조하십시오.
+ *변경 불가능한 업데이트* – 업데이트 유형에 대한 자세한 내용은 [구성 변경](environments-updating.md) 단원을 참조하십시오.
+ *관리형 플랫폼 업데이트* – 자세한 내용은 [관리형 플랫폼 업데이트](environment-platform-update-managed.md) 단원을 참조하십시오.
**참고**
새 배포 및 업데이트 기능은 확장 상태에 따라 달라집니다. 확장 상태를 활성화하여 사용합니다. 자세한 내용은 [Elastic Beanstalk 확장 상태 보고 활성화](health-enhanced-enable.md) 단원을 참조하십시오.
### Windows Server 플랫폼 V1
Elastic Beanstalk Windows Server 플랫폼의 버전 1.0.0(v1)은 2015년 10월에 릴리스되었습니다. 이 버전은 환경 생성 및 업데이트 중에 Elastic Beanstalk가 [구성 파일](ebextensions.md)에서 명령을 처리하는 순서를 변경합니다.
이전 플랫폼 버전에는 솔루션 스택 이름에 버전 번호가 없습니다.
+ IIS 8.5를 실행하는 64비트 Windows Server 2012 R2
+ IIS 8.5를 실행하는 64비트 Windows Server Core 2012 R2
+ IIS 8을 실행하는 64비트 Windows Server 2012
+ IIS 7.5를 실행하는 64비트 Windows Server 2008 R2
이전 버전에서는 구성 파일의 처리 순서가 일관되지 않습니다. 환경 생성 중에 애플리케이션 원본이 IIS에 배포된 후 `Container Commands`가 실행됩니다. 실행 중인 환경에 배포하는 동안 새 버전이 배포되기 전에 컨테이너 명령이 실행됩니다. 확장 중에는 구성 파일이 처리되지 않습니다.
이 외에도 컨테이너 명령이 실행되기 전에 IIS가 시작됩니다. 이 동작으로 인해 일부 고객은 컨테이너 명령에서 해결 방법을 실시하여 명령을 실행하기 전에 IIS 서버를 일시 중지했다가 완료된 후 다시 시작해야 했습니다.
버전 1은 불일치를 수정하고 Windows Server 플랫폼의 동작을 Elastic Beanstalk의 Linux 기반 플랫폼의 동작과 일치시킵니다. v1 플랫폼에서 Elastic Beanstalk는 항상 IIS 서버가 시작되기 전에 컨테이너 명령을 실행합니다.
v1 플랫폼 솔루션 스택에는 Windows Server 버전 뒤에 `v1`이 있습니다.
+ IIS 8.5를 실행하는 64비트 Windows Server 2012 R2 v1.1.0
+ IIS 8.5를 실행하는 64비트 Windows Server Core 2012 R2 v1.1.0
+ IIS 8을 실행하는 64비트 Windows Server 2012 v1.1.0
+ IIS 7.5를 실행하는 64비트 Windows Server 2008 R2 v1.1.0
또한 v1 플랫폼은 컨테이너 명령을 실행하기 전에 애플리케이션 소스 번들의 내용을 `C:\staging\`으로 추출합니다. 컨테이너 명령이 완료되면 이 폴더의 내용이 .zip 파일로 압축되어 IIS에 배포됩니다. 이 워크플로를 통해 배포 전에 명령 또는 스크립트를 사용하여 애플리케이션 소스 번들의 내용을 수정할 수 있습니다.
## Windows Server 플랫폼의 이전 메이저 버전에서 마이그레이션
환경을 업데이트하기 전에 이 단원의 마이그레이션 고려 사항을 읽습니다. 환경의 플랫폼을 최신 버전으로 업데이트하려면 [Elastic Beanstalk 환경의 플랫폼 버전 업데이트](using-features.platform.upgrade.md) 단원을 참조하십시오.
### V1에서 V2로
Windows Server 플랫폼 v2는 .NET Core 1.x 및 2.0.을 지원하지 않습니다. 애플리케이션을 Windows Server v1에서 v2로 마이그레이션하고 애플리케이션이 이러한 .NET Core 버전 중 하나를 사용하는 경우, 애플리케이션을 v2에서 지원하는 .NET Core 버전으로 업데이트합니다. 지원되는 버전의 목록은 *AWS Elastic Beanstalk * 플랫폼에서 [IIS를 사용하는 Windows Server의 .NET](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) 단원을 참조하세요.
애플리케이션에서 사용자 지정 Amazon Machine Image(AMI)를 사용하는 경우 Windows Server 플랫폼 v2 AMI를 기반으로 새 사용자 지정 AMI를 생성합니다. 자세한 내용은 [Elastic Beanstalk 환경에서 사용자 지정 Amazon Machine Image(AMI) 사용](using-features.customenv.md) 단원을 참조하십시오.
**참고**
Windows Server v2에 새로 추가되는 배포 및 업데이트 기능은 확장 상태에 따라 달라집니다. 환경을 v2로 마이그레이션하는 경우, 확장 상태는 비활성화됩니다. 확장 상태를 활성화하여 이러한 기능을 사용하시겠습니까? 자세한 내용은 [Elastic Beanstalk 확장 상태 보고 활성화](health-enhanced-enable.md) 단원을 참조하십시오.
### 이전의 V1에서
v1으로부터의 마이그레이션에 대한 고려 사항 이외에도, 애플리케이션을 v1 이전의 Windows Server 솔루션 스택으로부터 마이그레이션하고 현재 컨테이너 명령을 사용 중인 경우, 최신 버전으로 마이그레이션하면서 불일치를 처리할 당시에 작업에 추가했던 모든 명령을 제거합니다. 배포된 애플리케이션 소스가 배포되고 IIS가 시작되기 전에, v1을 시작으로 컨테이너 명령이 완전히 실행되도록 보장됩니다. 따라서 `C:\staging`의 소스를 변경할 수 있으며, 이 단계를 수행하는 동안 문제없이 IIS 구성 파일을 수정할 수 있습니다.
예를 들어 AWS CLI 를 사용하여 Amazon S3에서 애플리케이션 소스로 DLL 파일을 다운로드할 수 있습니다.
`.ebextensions\copy-dll.config`
```
container_commands:
copy-dll:
command: aws s3 cp s3://amzn-s3-demo-bucket/dlls/large-dll.dll .\lib\
```
구성 파일 사용에 대한 자세한 내용은 [구성 파일(`.ebextensions`)을 사용하여 고급 환경 사용자 지정](ebextensions.md) 단원을 참조하십시오.
# 배포 매니페스트를 사용하여 여러 애플리케이션 및 ASP.NET Core 애플리케이션 실행
배포 매니페스트를 사용하여 Elastic Beanstalk에 애플리케이션을 배포하는 방법을 알릴 수 있습니다. 이 방법을 사용하면 `MSDeploy`를 사용하여 웹 사이트의 루트 경로에서 실행되는 단일 ASP.NET 애플리케이션의 소스 번들을 생성할 필요가 없습니다. 대신 매니페스트 파일을 사용하여 서로 다른 경로에서 여러 애플리케이션을 실행할 수 있습니다. 또는 ASP.NET Core를 사용하여 앱을 배포하고 실행하도록 Elastic Beanstalk에 지시할 수도 있습니다. 또한 배포 매니페스트를 사용하여 애플리케이션을 실행할 애플리케이션 풀을 구성할 수도 있습니다.
배포 매니페스트는 Elastic Beanstalk에 [.NET Core 애플리케이션](#dotnet-manifest-dotnetcore)에 대한 지원을 추가합니다. 배포 매니페스트를 사용하지 않고 .NET Framework 애플리케이션을 배포할 수 있습니다. 하지만 .NET Core 애플리케이션을 Elastic Beanstalk에서 실행하려면 배포 매니페스트가 필요합니다. 배포 매니페스트를 사용할 때는 각 애플리케이션의 사이트 아카이브를 만든 후 배포 매니페스트가 들어 있는 두 번째 ZIP 아카이브에 그 사이트 아카이브를 번들링합니다.
배포 매니페스트는 [여러 경로에서 여러 애플리케이션을 실행](#dotnet-manifest-multiapp)하는 기능도 추가합니다. 배포 매니페스트는 배포 대상 배열을 정의하는데, 각 배포 대상에는 사이트 아카이브 및 IIS가 이를 실행해야 하는 경로가 들어 있습니다. 예를 들어 `/api` 경로에서 웹 API를 실행하여 비동기 요청을 처리하고, API를 사용하는 루트 경로에서 웹 앱을 실행할 수 있습니다.
배포 매니페스트를 사용하여 [사용자 지정 바인딩 및 물리적 경로로 IIS 웹 사이트를 구성](#dotnet-manifest-websites)할 수 있습니다. 이를 통해 애플리케이션을 배포하기 전에 특정 포트 또는 호스트 이름에서 수신 대기하는 웹 사이트를 설정할 수 있습니다.
배포 매니페스트를 사용하여 [IIS 또는 Kestrel의 애플리케이션 풀을 사용하여 여러 애플리케이션을 실행](#dotnet-manifest-apppool)할 수도 있습니다. 애플리케이션을 주기적으로 다시 시작하거나, 32비트 애플리케이션을 실행하거나, .NET Framework 실행 시간의 특정 버전을 사용하도록 애플리케이션 풀을 구성할 수 있습니다.
완전한 사용자 지정을 하려면 Windows PowerShell에 [자체 배포 스크립트를 작성](#dotnet-manifest-custom)하고 Elastic Beanstalk에 애플리케이션을 설치, 제거 및 다시 시작하기 위해 실행할 스크립트를 알리면 됩니다.
배포 매니페스트와 관련 기능에는 Windows Server 플랫폼 [버전 1.2.0 이상](dotnet-v2migration.md)이 필요합니다.
사용 가능한 모든 구성 옵션, 속성, IIS 재설정 건너뛰기와 같은 고급 기능에 대한 자세한 내용은 [배포 매니페스트 스키마 참조](dotnet-manifest-schema.md)를 참조하세요.
**Topics**
+ [.NET Core 앱](#dotnet-manifest-dotnetcore)
+ [여러 애플리케이션 실행](#dotnet-manifest-multiapp)
+ [IIS 웹 사이트 구성](#dotnet-manifest-websites)
+ [Application Request Routing(ARR) 사용](#dotnet-manifest-arr)
+ [애플리케이션 풀 구성](#dotnet-manifest-apppool)
+ [사용자 지정 배포 정의](#dotnet-manifest-custom)
+ [배포 매니페스트 스키마 참조](dotnet-manifest-schema.md)
## .NET Core 앱
배포 매니페스트를 사용하여 Elastic Beanstalk 에서 .NET Core 애플리케이션을 실행할 수 있습니다. .NET Core는 .NET의 교차 플랫폼 버전으로, 명령 줄 도구(`dotnet`)와 함께 제공됩니다. 이 도구를 사용하여 애플리케이션을 생성하고 로컬로 실행하고 게시하도록 준비할 수 있습니다.
Elastic Beanstalk에서 .NET Core 애플리케이션을 실행하려면 `dotnet publish`를 실행하고 포함된 모든 디렉터리를 제외한 출력을 ZIP 아카이브로 패키징하면 됩니다. 배포 대상 유형이 `aspNetCoreWeb`인 배포 매니페스트를 사용하여 사이트 아카이브를 소스 번들에 배치합니다.
다음 배포 매니페스트는 루트 경로에서 `dotnet-core-app.zip`이라는 사이트 아카이브의 .NET Core 애플리케이션을 실행합니다.
**Example aws-windows-deployment-manifest.json - .NET Core**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
매니페스트와 사이트 아카이브를 ZIP 아카이브로 번들링하여 소스 번들을 만듭니다.
**Example dotnet-core-bundle.zip**
```
.
|-- aws-windows-deployment-manifest.json
`-- dotnet-core-app.zip
```
사이트 아카이브에는 컴파일된 애플리케이션 코드, 종속 항목, `web.config` 파일이 들어 있습니다.
**Example dotnet-core-app.zip**
```
.
|-- Microsoft.AspNetCore.Hosting.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.dll
|-- Microsoft.AspNetCore.Http.Abstractions.dll
|-- Microsoft.AspNetCore.Http.Extensions.dll
|-- Microsoft.AspNetCore.Http.Features.dll
|-- Microsoft.AspNetCore.Http.dll
|-- Microsoft.AspNetCore.HttpOverrides.dll
|-- Microsoft.AspNetCore.Server.IISIntegration.dll
|-- Microsoft.AspNetCore.Server.Kestrel.dll
|-- Microsoft.AspNetCore.WebUtilities.dll
|-- Microsoft.Extensions.Configuration.Abstractions.dll
|-- Microsoft.Extensions.Configuration.EnvironmentVariables.dll
|-- Microsoft.Extensions.Configuration.dll
|-- Microsoft.Extensions.DependencyInjection.Abstractions.dll
|-- Microsoft.Extensions.DependencyInjection.dll
|-- Microsoft.Extensions.FileProviders.Abstractions.dll
|-- Microsoft.Extensions.FileProviders.Physical.dll
|-- Microsoft.Extensions.FileSystemGlobbing.dll
|-- Microsoft.Extensions.Logging.Abstractions.dll
|-- Microsoft.Extensions.Logging.dll
|-- Microsoft.Extensions.ObjectPool.dll
|-- Microsoft.Extensions.Options.dll
|-- Microsoft.Extensions.PlatformAbstractions.dll
|-- Microsoft.Extensions.Primitives.dll
|-- Microsoft.Net.Http.Headers.dll
|-- System.Diagnostics.Contracts.dll
|-- System.Net.WebSockets.dll
|-- System.Text.Encodings.Web.dll
|-- dotnet-core-app.deps.json
|-- dotnet-core-app.dll
|-- dotnet-core-app.pdb
|-- dotnet-core-app.runtimeconfig.json
`-- web.config
```
## 여러 애플리케이션 실행
여러 배포 대상을 정의하여 배포 매니페스트로 여러 애플리케이션을 실행할 수 있습니다.
다음 배포 매니페스트는 .NET Core 애플리케이션 두 개를 구성합니다. `WebApiSampleApp` 애플리케이션은 단순한 웹 API를 구현하며, `/api` 경로에서 비동기 요청을 수행합니다. `DotNetSampleApp` 애플리케이션은 루트 경로에서 요청을 수행하는 웹 애플리케이션입니다.
**Example aws-windows-deployment-manifest.json - 여러 앱**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "WebAPISample",
"parameters": {
"appBundle": "WebApiSampleApp.zip",
"iisPath": "/api"
}
},
{
"name": "DotNetSample",
"parameters": {
"appBundle": "DotNetSampleApp.zip",
"iisPath": "/"
}
}
]
}
}
```
다음을 통해 여러 애플리케이션으로 구성된 샘플 애플리케이션을 사용할 수 있습니다.
+ **배포 가능한 소스 번들** - [dotnet-multiapp-sample-bundle-v2.zip](samples/dotnet-multiapp-sample-bundle-v2.zip)
+ **소스 코드** - [dotnet-multiapp-sample-source-v2.zip](samples/dotnet-multiapp-sample-source-v2.zip)
## IIS 웹 사이트 구성
배포 매니페스트를 사용하여 사용자 지정 바인딩 및 실제 경로로 IIS 웹 사이트를 구성할 수 있습니다. 이는 특정 포트에서 수신 대기하거나, 사용자 지정 호스트 이름을 사용하거나, 특정 디렉터리의 콘텐츠를 제공하는 웹 사이트를 설정해야 할 때 유용합니다.
다음 배포 매니페스트는 특정 포트 번호와 사용자 지정 실제 경로를 사용하여 HTTP에서 수신 대기하는 사용자 지정 IIS 웹 사이트를 구성합니다.
**Example aws-windows-deployment-manifest.json - IIS 웹 사이트 구성**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"appBundle": "dotnet-core-app.zip",
"iisWebSite": "MyCustomSite",
"iisPath": "/"
}
}
]
}
}
```
이 예시는 다음과 같이 설정되어 있습니다.
+ "MyCustomSite"라는 웹 사이트가 사용자 지정 물리적 경로로 생성됩니다.
+ 웹 사이트는 특정 호스트 이름으로 포트 8080에 HTTP 바인딩을 갖습니다.
+ ASP.NET Core 애플리케이션은 `iisWebSite` 파라미터를 사용하여 이 사용자 지정 웹 사이트에 배포됩니다.
## Application Request Routing(ARR) 사용
Application Request Routing(ARR) 및 URL Rewrite 모듈은 Elastic Beanstalk Windows AMI에 사전 설치되어 사용할 수 있습니다. 이러한 모듈을 사용하면 ebextensions 또는 애플리케이션 구성을 사용하는 IIS 구성을 통해 고급 라우팅 시나리오 및 URL 조작이 가능합니다.
다음 예제는 사용자 지정 포트로 웹 사이트를 구성하는 간단한 배포 매니페스트와 기본 ARR 라우팅을 설정하는 ebextensions 구성을 결합한 것을 보여줍니다.
**Example aws-windows-deployment-manifest.json - 간단한 ARR 설정**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "ARRSite",
"physicalPath": "C:\\inetpub\\wwwroot\\arrsite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "localhost"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "BackendApp",
"parameters": {
"appBundle": "backend-app.zip",
"iisWebSite": "ARRSite",
"iisPath": "/backend"
}
}
]
}
}
```
ARR 구성은 ebextensions를 통해 수행됩니다. 다음 구성은 기본 ARR 라우팅 규칙을 설정합니다.
**Example .ebextensions/arr-config.config - 기본 ARR 구성**
```
files:
"C:\\temp\\configure-arr.ps1":
content: |
# Enable ARR proxy at server level
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/proxy' -Name 'enabled' -Value 'True'
# Clear any existing global rules to avoid conflicts
Clear-WebConfiguration -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/rewrite/globalRules'
# Add global rule to route all requests to backend
Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
-Filter 'system.webServer/rewrite/globalRules' `
-Name '.' `
-Value @{
name = 'Route_to_Backend'
stopProcessing = 'True'
match = @{ url = '^(?!backend/)(.*)' }
action = @{
type = 'Rewrite'
url = 'http://localhost:8080/backend/{R:1}'
}
}
container_commands:
01_configure_arr:
command: powershell -ExecutionPolicy Bypass -File "C:\\temp\\configure-arr.ps1"
waitAfterCompletion: 0
```
이 구성은 포트 8080에 웹 사이트를 생성하고 모든 수신 요청을 해당 사이트에서 실행되는 백엔드 애플리케이션으로 라우팅하도록 ARR을 설정합니다.
## 애플리케이션 풀 구성
Windows 환경에서 여러 애플리케이션을 지원할 수 있습니다. 다음 두 가지 방법을 사용할 수 있습니다.
+ Kestrel 웹 서버를 통해 프로세스 외 호스팅 모델을 사용할 수 있습니다. 이 모델을 사용하기 위해 여러 애플리케이션이 하나의 애플리케이션 풀에서 실행되도록 구성할 수 있습니다.
+ 프로세스 내 호스팅 모델을 사용할 수 있습니다. 이 모델에서는 여러 애플리케이션 풀을 사용하여 각 풀마다 하나씩 여러 애플리케이션을 실행할 수 있습니다. IIS 서버를 사용하고 있고 여러 애플리케이션을 실행해야 하는 경우 이 방법을 사용해야 합니다.
하나의 애플리케이션 풀에서 여러 애플리케이션을 실행하도록 Kestrel을 구성하려면 `hostingModel="OutofProcess"` 파일에 `web.config`를 추가합니다. 다음 예제를 살펴보세요.
**Example web.config - Kestrel의 프로세스 외 호스팅 모델**
```
```
**Example aws-windows-deployment-manifest.json - 여러 애플리케이션**
```
{
"manifestVersion": 1,
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {"archive": "site1.zip",
"iisPath": "/"
}
},
{"name": "Web-app2",
"parameters": {"archive": "site2.zip",
"iisPath": "/app2"
}
}
]
}
}
```
IIS는 프로세스 내 호스팅 모델을 사용하므로 하나의 애플리케이션 풀에서 여러 애플리케이션을 지원하지 않습니다. 따라서 각 애플리케이션을 하나의 애플리케이션 풀에 할당하여 여러 애플리케이션을 구성해야 합니다. 즉, 하나의 애플리케이션 풀에 하나의 애플리케이션만 할당합니다.
`aws-windows-deployment-manifest.json` 파일에서 여러 애플리케이션 풀을 사용하도록 IIS를 구성할 수 있습니다. 다음 예제 파일을 참조하여 다음과 같이 업데이트합니다.
+ `iisConfig`라는 하위 섹션이 포함된 `appPools` 섹션을 추가합니다.
+ `appPools` 블록에서 애플리케이션 풀을 나열합니다.
+ `deployments` 섹션에서 각 애플리케이션에 대한 `parameters` 섹션을 정의합니다.
+ `parameters` 섹션은 각 애플리케이션에 대해 아카이브, 실행 경로 및 실행할 `appPool`을 지정합니다.
다음 배포 매니페스트는 10분마다 애플리케이션을 다시 시작하는 2개의 애플리케이션 풀을 구성합니다. 또한 지정된 경로에서 실행되는 .NET Framework 웹 애플리케이션에 애플리케이션을 연결합니다.
**Example aws-windows-deployment-manifest.json - 애플리케이션 풀당 하나의 애플리케이션**
```
{
"manifestVersion": 1,
"iisConfig": {"appPools": [
{"name": "MyFirstPool",
"recycling": {"regularTimeInterval": 10}
},
{"name": "MySecondPool",
"recycling": {"regularTimeInterval": 10}
}
]
},
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {
"archive": "site1.zip",
"iisPath": "/",
"appPool": "MyFirstPool"
}
},
{"name": "Web-app2",
"parameters": {
"archive": "site2.zip",
"iisPath": "/app2",
"appPool": "MySecondPool"
}
}
]
}
}
```
## 사용자 지정 배포 정의
더욱 세부적인 제어를 위해 *사용자 지정 배포*를 정의하여 애플리케이션 배포를 완전히 사용자 지정할 수 있습니다.
이 배포 매니페스트는 Elastic Beanstalk에 32비트 모드에서 PowerShell 스크립트를 실행하도록 지시합니다. 인스턴스 시작 및 배포 중에 실행되는 스크립트`install`(`siteInstall.ps1`), 배포 중에 새 버전을 설치하기 전에 실행되는 `uninstall` 스크립트(`siteUninstall.ps1`), AWS 관리 콘솔에서 [앱 서버 재시작](environments-dashboard-actions.md)을 선택할 때 실행되는 `restart` 스크립트(`siteRestart.ps1`) 등 세 가지 스크립트를 지정합니다.
**Example aws-windows-deployment-manifest.json - 사용자 지정 배포**
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "Custom site",
"architecture" : 32,
"scripts": {
"install": {
"file": "siteInstall.ps1"
},
"restart": {
"file": "siteRestart.ps1"
},
"uninstall": {
"file": "siteUninstall.ps1"
}
}
}
]
}
}
```
매니페스트와 스크립트를 사용하여 소스 번들에 애플리케이션을 실행하는 데 필요한 모든 결과물을 포함시킵니다.
**Example Custom-site-bundle.zip**
```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```
# 배포 매니페스트 스키마 참조
배포 매니페스트는 Elastic Beanstalk이 Windows 애플리케이션을 어떻게 배포하고 구성해야 하는지를 정의하는 JSON 파일입니다. 이 섹션은 매니페스트 스키마에서 지원되는 모든 속성과 구성 옵션에 대한 종합적인 참조를 제공합니다.
## 매니페스트 구조
배포 매니페스트는 다음과 같은 최상위 구조를 가진 특정 JSON 스키마를 따릅니다.
**Example 기본 매니페스트 구조**
```
{
"manifestVersion": 1,
"skipIISReset": false,
"iisConfig": {
"websites": [...],
"appPools": [...]
},
"deployments": {
"msDeploy": [...],
"aspNetCoreWeb": [...],
"custom": [...]
}
}
```
### 최상위 속성
`manifestVersion`(필수)
*형식*: 숫자
*기본값*: 1
*유효한 값:* 1
매니페스트 스키마 버전을 지정합니다. 현재는 버전 1만 지원됩니다.
`skipIISReset` (선택 사항)
*유형*: 부울
*기본값:* false
애플리케이션 배포 중 IIS를 재설정할지 여부를 제어합니다. 이 플래그는 `msDeploy` 및 `aspNetCoreWeb` 배포 유형 모두에 영향을 미칩니다.
*동작:*
+ *지정되지 않음 또는 `false`(기본값):* 설치, 제거, 업데이트 작업 중 IIS 재설정이 수행됩니다. 이는 기존의 동작입니다.
+ *`true`:* 배포 작업 중에는 IIS 재설정을 건너뜁니다.
*이점:*
+ *가동 중지 시간 단축* - 배포 과정에서 애플리케이션의 서비스 중단 시간이 단축됩니다.
+ *더 빠른 배포* - IIS가 완전히 다시 시작되고 재초기화되는 데 필요한 시간을 제거합니다.
`skipIISReset`를 사용할 때 [RestartAppServer](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RestartAppServer.html) 작업은 이 플래그 설정과 관계없이 IIS 재설정을 수행합니다.
*예:*
```
{
"manifestVersion": 1,
"skipIISReset": true,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
`deployments`(필수)
*유형:* 객체
애플리케이션의 배포 구성이 포함되어 있습니다. 이 객체는 `msDeploy`, `aspNetCoreWeb` 및 `custom` 배포 유형을 포함할 수 있습니다.
`iisConfig` (선택 사항)
*유형:* 객체
애플리케이션을 배포하기 전에 적용할 IIS 구성 설정을 정의합니다. 웹 사이트 및 애플리케이션 풀 구성을 모두 지원합니다.
## IIS 구성
`iisConfig` 섹션에서는 애플리케이션을 배포하기 전에 IIS 설정을 구성할 수 있습니다. 여기에는 특정 구성으로 애플리케이션 풀을 설정하고, 사용자 지정 바인딩으로 IIS 웹 사이트를 구성하는 작업이 포함됩니다.
### IIS 웹 사이트
IIS 웹 사이트에서는 애플리케이션을 배포하기 전에 물리적 경로 및 네트워크 바인딩을 포함한 사용자 지정 웹 사이트 설정을 구성할 수 있습니다.
**서로 다른 IIS 웹 사이트를 생성할 때 고려해야 할 주요 사항입니다.**
*웹 사이트 설정 순서:* `websites` 배열에 나열된 순서대로 웹 사이트가 순차적으로 구성됩니다. 플랫폼은 각 웹 사이트 구성을 순차적으로 처리하므로, 웹사이트 간 종속성이 있는 경우 올바른 순서를 설정해야 합니다.
*방화벽 및 포트 액세스:* 기본 Elastic Beanstalk Windows 방화벽 구성에서는 포트 80만 자동으로 노출됩니다. 웹 사이트를 비표준 포트를 사용하도록 구성하는 경우, 이러한 포트에 대한 외부 액세스를 허용하기 위해 ebextensions 또는 사용자 지정 배포 스크립트를 통해 사용자 지정 방화벽 규칙을 정의해야 합니다.
**Example 웹 사이트 구성**
```
{
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
},
{
"protocol": "https",
"port": 8443
}
]
}
]
}
}
```웹 사이트 속성
`name`(필수)
*유형*: 문자열
IIS 웹 사이트의 이름입니다. 이 이름은 IIS Manager에서 웹 사이트를 식별하는 데 사용되며, IIS 구성 내에서 고유해야 합니다.
`physicalPath`(필수)
*유형*: 문자열
웹 사이트 파일이 저장되는 서버의 물리적 경로입니다. 이 경로는 IIS 작업자 프로세스에서 액세스할 수 있어야 합니다.
`bindings`(필수)
*유형*: 배열
*최소 항목:* 1
웹 사이트가 네트워크 요청에 어떻게 응답할지 정의하는 바인딩 구성 배열입니다. 각 바인딩은 프로토콜, 포트, 선택적 호스트 이름을 지정합니다.
#### 웹 사이트 바인딩
웹 사이트 바인딩은 IIS 웹 사이트가 수신 요청을 수신하는 네트워크 엔드포인트를 정의합니다.
`protocol`(필수)
*유형*: 문자열
*유효한 값:* "http", "https"
바인딩에 사용되는 프로토콜입니다.
`port`(필수)
*유형*: 정수
*유효 범위:* 1-65535
웹 사이트가 요청을 수신하는 포트 번호입니다.
`hostName` (선택 사항)
*유형*: 문자열
바인딩의 호스트 이름(도메인 이름)입니다.
### 애플리케이션 풀
애플리케이션 풀은 애플리케이션 간 격리를 제공하며, 애플리케이션 그룹에 대한 런타임 설정을 구성할 수 있도록 합니다.
**Example 애플리케이션 풀 구성**
```
{
"iisConfig": {
"appPools": [
{
"name": "MyAppPool",
"enable32Bit": false,
"managedPipelineMode": "Integrated",
"managedRuntimeVersion": "v4.0",
"queueLength": 1000,
"cpu": {
"limitPercentage": 80,
"limitAction": "Throttle",
"limitMonitoringInterval": 5
},
"recycling": {
"regularTimeInterval": 1440,
"requestLimit": 10000,
"memory": 1048576,
"privateMemory": 524288
}
}
]
}
}
```애플리케이션 풀 속성
`name`(필수)
*유형*: 문자열
애플리케이션 풀의 이름입니다. 이 이름은 배포 구성에서 풀을 참조하는 데 사용됩니다.
`enable32Bit` (선택 사항)
*유형*: 부울
32비트 애플리케이션이 64비트 Windows에서 실행되도록 활성화합니다. 32비트 호환성이 필요한 레거시 애플리케이션의 경우 `true`로 설정합니다.
`managedPipelineMode` (선택 사항)
*유형*: 문자열
*유효한 값:* "Integrated", "Classic"
애플리케이션 풀의 요청 처리 모드를 지정합니다.
`managedRuntimeVersion` (선택 사항)
*유형*: 문자열
*유효한 값:* "관리형 코드 없음", "v2.0", "v4.0"
애플리케이션 풀에 사용할 .NET Framework 버전을 지정합니다.
`queueLength` (선택 사항)
*유형*: 정수
HTTP.sys가 추가 요청을 거부하기 전에 애플리케이션 풀을 위해 대기열에 넣을 수 있는 최대 요청 수입니다.
#### CPU 구성
`cpu` 객체는 애플리케이션 풀의 CPU 사용 한도 및 모니터링을 구성합니다.
`limitPercentage` (선택 사항)
*형식*: 숫자
애플리케이션 풀의 작업자 프로세스가 사용할 수 있는 CPU 시간의 최대 비율입니다.
`limitAction` (선택 사항)
*유형*: 문자열
*유효한 값:* "NoAction", "KillW3wp", "Throttle", "ThrottleUnderLoad"
CPU 한도에 도달했을 때 수행할 조치입니다.
`limitMonitoringInterval` (선택 사항)
*형식*: 숫자
CPU 모니터링 및 스로틀링 조정을 위한 재설정 주기(분 단위)입니다.
#### 재활용 구성
`recycling` 객체는 애플리케이션 풀 작업자 프로세스를 언제, 어떤 방식으로 재활용할지 구성합니다.
`regularTimeInterval` (선택 사항)
*유형*: 정수
애플리케이션 풀이 재활용되는 시간 간격(분 단위)입니다. 시간 기반 재활용을 비활성화하려면 0으로 설정합니다.
`requestLimit` (선택 사항)
*유형*: 정수
애플리케이션 풀이 재활용되기 전에 처리하는 최대 요청 수입니다.
`memory` (선택 사항)
*유형*: 정수
작업자 프로세스 재활용을 트리거하는 가상 메모리 용량(킬로바이트 기준)입니다.
`privateMemory` (선택 사항)
*유형*: 정수
작업자 프로세스 재활용을 트리거하는 프라이빗 메모리 용량(킬로바이트 기준)입니다.
## 배포 유형
`deployments` 객체에는 서로 다른 애플리케이션 유형에 대한 배포 구성 배열이 포함됩니다. 각 배포 유형에는 고유한 속성과 사용 사례가 있습니다.
### MSDeploy 배포
MSDeploy 배포는 Web Deploy(MSDeploy)를 사용해 배포할 수 있는 기존 .NET Framework 애플리케이션에 사용됩니다.
**Example MSDeploy 배포 구성**
```
{
"deployments": {
"msDeploy": [
{
"name": "WebApp",
"description": "Main web application",
"parameters": {
"appBundle": "webapp.zip",
"iisPath": "/",
"appPool": "DefaultAppPool"
}
}
]
}
}
```MSDeploy 배포 속성
`name`(필수)
*유형*: 문자열
배포의 고유 이름입니다. 이 이름은 매니페스트의 모든 배포에서 고유해야 합니다.
`description` (선택 사항)
*유형*: 문자열
사람이 읽을 수 있는 배포 설명
`parameters`(필수)
*유형:* 객체
MSDeploy 작업에 대한 구성 파라미터입니다.
`scripts` (선택 사항)
*유형:* 객체
배포 수명 주기의 다양한 단계에서 실행되는 PowerShell 스크립트입니다.
#### MSDeploy 파라미터
`appBundle`(필수)
*유형*: 문자열
매니페스트 파일을 기준으로 한 애플리케이션 번들(ZIP 파일)의 경로입니다. 이 번들은 배포할 애플리케이션 파일을 포함합니다.
`iisWebSite` (선택 사항)
*유형*: 문자열
*기본값:* "기본 웹 사이트"
애플리케이션을 배포할 IIS 웹 사이트입니다. 기본적으로 애플리케이션은 "기본 웹 사이트"에 배포됩니다. 또는 `iisConfig.websites` 섹션에 구성된 웹 사이트 이름과 같이 다른 웹 사이트 이름을 지정할 수 있습니다.
`iisPath` (선택 사항)
*유형*: 문자열
*기본값:* "/"
애플리케이션이 배포될 IIS의 가상 디렉터리 경로입니다. 루트 경로에는 "/"를 사용하고 하위 디렉터리에는 "/api"를 사용하세요.
`appPool` (선택 사항)
*유형*: 문자열
이 애플리케이션을 실행할 애플리케이션 풀의 이름입니다.
### ASP.NET Core 배포
ASP.NET Core 배포는 .NET Core 및 .NET 5\$1 애플리케이션을 위해 특별히 설계되었습니다.
**Example ASP.NET Core 배포 구성**
```
{
"deployments": {
"aspNetCoreWeb": [
{
"name": "CoreAPI",
"description": "ASP.NET Core Web API",
"parameters": {
"appBundle": "coreapi.zip",
"iisPath": "/api",
"appPool": "CoreAppPool"
}
}
]
}
}
```
ASP.NET Core 배포는 MSDeploy 배포와 동일한 속성 구조를 사용하며, 핵심 차이점은 애플리케이션에 사용되는 런타임 환경과 호스팅 모델입니다.ASP.NET Core 배포 파라미터
`appBundle`(필수)
*유형*: 문자열
매니페스트 파일을 기준으로 한 애플리케이션 번들의 경로입니다. 이는 ZIP 아카이브이거나, 게시된 ASP.NET Core 애플리케이션이 포함된 디렉터리 경로일 수 있습니다.
`iisWebSite` (선택 사항)
*유형*: 문자열
*기본값:* "기본 웹 사이트"
ASP.NET Core 애플리케이션을 배포할 IIS 웹 사이트입니다. 기본적으로 애플리케이션은 "기본 웹 사이트"에 배포됩니다. 또는 `iisConfig.websites` 섹션에 구성된 웹 사이트 이름과 같이 다른 웹 사이트 이름을 지정할 수 있습니다.
`iisPath` (선택 사항)
*유형*: 문자열
*기본값:* "/"
ASP.NET Core 애플리케이션용 IIS 가상 디렉터리 경로입니다.
`appPool` (선택 사항)
*유형*: 문자열
ASP.NET Core 애플리케이션의 애플리케이션 풀입니다. 이 풀은 ASP.NET Core 호스팅에 적합하도록 구성됩니다.
### 사용자 지정 배포
사용자 지정 배포에서는 PowerShell 스크립트를 통해 배포 프로세스를 완전히 제어할 수 있습니다. 이 배포 유형은 사용자 지정 설치, 구성 또는 배포 로직이 필요한 복잡한 시나리오에 유용합니다.
**Example 사용자 지정 배포 구성**
```
{
"deployments": {
"custom": [
{
"name": "CustomService",
"description": "Custom Windows service deployment",
"architecture": 32,
"scripts": {
"install": {
"file": "install-service.ps1"
},
"restart": {
"file": "restart-service.ps1"
},
"uninstall": {
"file": "uninstall-service.ps1",
"ignoreErrors": true
}
}
}
]
}
}
```사용자 지정 배포 속성
`name`(필수)
*유형*: 문자열
사용자 지정 배포의 고유 이름입니다.
`description` (선택 사항)
*유형*: 문자열
사용자 지정 배포에 대한 설명입니다.
`architecture` (선택 사항)
*유형*: 정수
*기본값:* 32
*유효한 값:* 32, 64
PowerShell 스크립트 실행 모드에 대한 아키텍처 사양
`scripts`(필수)
*유형:* 객체
배포 동작을 정의하는 PowerShell 스크립트입니다. 사용자 지정 배포는 다른 배포 유형과 달리 추가적인 스크립트 유형을 지원합니다.
## 배포 스크립트
배포 스크립트는 배포 수명 주기의 특정 시점에 실행되는 PowerShell 스크립트입니다. 배포 유형에 따라 지원되는 스크립트 이벤트가 다릅니다.
### 스크립트 이벤트
배포 유형에 따라 다음 스크립트 이벤트를 사용할 수 있습니다.표준 배포 스크립트(msDeploy 및 aspNetCoreWeb)
`preInstall`
애플리케이션을 설치하거나 업데이트하기 전에 실행됩니다.
`postInstall`
애플리케이션을 설치하거나 업데이트한 후에 실행됩니다.
`preRestart`
애플리케이션을 다시 시작하기 전에 실행됩니다.
`postRestart`
애플리케이션을 다시 시작한 후 실행됩니다.
`preUninstall`
애플리케이션을 제거하기 전에 실행됩니다.
`postUninstall`
애플리케이션을 제거한 후 실행됩니다.사용자 지정 배포 스크립트(사용자 지정 배포만 해당)
`install`
사용자 지정 배포를 위한 기본 설치 스크립트입니다. 이 스크립트는 애플리케이션 또는 서비스를 설치하는 역할을 합니다.
`restart`
애플리케이션 또는 서비스를 다시 시작하는 스크립트입니다. 환경이 재시작될 때 직접적으로 호출됩니다.
`uninstall`
애플리케이션 또는 서비스를 제거하는 스크립트입니다. 환경 종료 또는 애플리케이션 제거 시 직접적으로 호출됩니다.
### 스크립트 속성
각 스크립트는 다음 속성을 가진 객체로 정의됩니다.
`file`(필수)
*유형*: 문자열
매니페스트 파일 기준 PowerShell 스크립트 파일의 상대 경로입니다. 스크립트에는 `.ps1` 확장자가 있어야 합니다.
`ignoreErrors` (선택 사항)
*유형*: 부울
*기본값:* false
`true`로 설정하면 스크립트가 실패하더라도 배포가 계속 진행됩니다. 중요하지 않은 스크립트나 정리 작업에 이 옵션을 사용하세요.
**Example 스크립트 구성 예제**
```
{
"scripts": {
"preInstall": {
"file": "backup-config.ps1",
"ignoreErrors": true
},
"postInstall": {
"file": "configure-app.ps1"
}
}
}
```
# Windows 플랫폼 브랜치에서 EC2 Fast Launch 사용
EC2 Fast Launch 기능은 Elastic Beanstalk 환경에서 Windows 인스턴스 시작 시간을 줄입니다. 이 주제의 목적은 Elastic Beanstalk 환경에서이 기능을 사용하는 방법을 안내하는 것입니다. [2025년 1월 22일](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-01-22-windows.html)에 릴리스된 Windows 플랫폼 버전 2.16.2부터 Elastic Beanstalk 플랫폼 릴리스에는 EC2 Fast Launch가 활성화된 기본 AMI가 포함되어 있습니다.
## 기본 EC2 Fast Launch 가용성
최신 Elastic Beanstalk Windows 플랫폼 버전에는 추가 비용 없이 EC2 Fast Launch가 자동으로 활성화된 기본 AMI 포함되어 있습니다. 그러나 최신 플랫폼 버전이 릴리스되면 이전 플랫폼 버전의 기본 AMI에서는 EC2 Fast Launch가 자동으로 활성화된 상태로 유지되지 않을 수 있습니다.
EC2 Fast Launch가 자동으로 활성화된 기본 AMI를 사용하려면 최신 Windows 플랫폼 버전으로 업그레이드하는 것이 좋습니다. 그러나 기존 플랫폼 버전을 계속 사용해야 하는 경우 환경의 기본 AMI에서 EC2 Fast Launch를 수동으로 활성화할 수 있습니다. 지침은 [수동으로 EC2 Fast Launch 구성](#dotnet-ec2fastlaunch-manual) 섹션을 참조하세요.
## 수동으로 EC2 Fast Launch 구성
**참고**
EC2 Fast Launch를 수동으로 활성화하면 EC2 Fast Launch가 자동으로 활성화된 플랫폼 버전을 사용하는 것보다 추가 비용이 발생할 수 있습니다. EC2 Fast Launch 비용에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [EC2 Fast Launch 기본 리소스에 대한 비용 관리](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-manage-costs.html) 페이지를 참조하세요.
다음 단계에 따라 Elastic Beanstalk 환경에서 사용하는 Windows 기본 AMI에서 EC2 Fast Launch를 활성화합니다.
**Elastic Beanstalk 환경에서 EC2 Fast Launch를 수동으로 활성화하려면**
1. 환경의 기본 AMI를 식별합니다.
[사용자 지정 AMI 생성](using-features.customenv.md)의 단계에 따라 환경의 기본 AMI ID를 식별합니다. 사용자 지정 AMI를 생성할 필요가 없습니다. 현재 기본 AMI ID를 찾는 단계만 수행하면 됩니다.
1. AMI에서 EC2 Fast Launch를 활성화합니다.
*Amazon EC2 사용 설명서*의 [EC2 Fast Launch 활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-configure.html) 지침을 사용하여 AMI에 대한 EC2 Fast Launch를 구성합니다.