기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Elastic Beanstalk 환경의 플랫폼 버전 업데이트
Elastic Beanstalk에서는 새 플랫폼 버전을 정기적으로 릴리스하여 모든 Linux 기반 및 Windows Server 기반 [플랫폼](concepts.platforms.md)을 업데이트합니다. 새 플랫폼 버전은 기존 소프트웨어 구성 요소에 대한 업데이트 및 새 기능 및 구성 옵션에 대한 지원을 제공합니다. 플랫폼 및 플랫폼 버전에 대한 자세한 내용은 [Elastic Beanstalk 플랫폼 용어집](platforms-glossary.md) 단원을 참조하세요.
Elastic Beanstalk 콘솔 또는 EB CLI를 사용하여 환경의 플랫폼 버전을 업데이트할 수 있습니다. 업데이트 대상 플랫폼 버전에 따라 Elastic Beanstalk에서는 플랫폼 업데이트를 수행하는 두 방법 중 하나를 권장합니다.
+ [방법 1 – 환경의 플랫폼 버전 업데이트](#using-features.platform.upgrade.config). 런타임, 웹 서버, 애플리케이션 서버 또는 운영 체제가 동일하고 메이저 플랫폼 버전의 변경 없이 플랫폼 브랜치 내 최신 플랫폼 버전으로 업데이트할 때 이 방법을 사용하는 것이 좋습니다. 이는 가장 일반적이며 일상적인 플랫폼 업데이트합니다.
+ [방법 2 – 블루/그린 배포 수행](#using-features.platform.upgrade.bluegreen) 다른 런타임, 웹 서버, 애플리케이션 서버 또는 운영 체제를 포함하는 다른 플랫폼 브랜치의 플랫폼 버전 또는 다른 메이저 플랫폼 버전으로 업데이트할 때 이 방법을 사용하는 것이 좋습니다. 이는 새 런타임 기능 또는 최신 Elastic Beanstalk 기능을 활용하려는 경우나 사용되지 않거나 만료된 플랫폼 브랜치에서 이동하려는 경우에 좋은 접근 방식입니다.
[레거시 플랫폼 버전에서 마이그레이션](using-features.migration.md)하려면 블루/그린 배포가 필요합니다. 이러한 플랫폼 버전이 현재 지원되는 버전과 호환되지 않기 때문입니다.
Amazon Linux 2 플랫폼 버전은 이전 Amazon Linux AMI 플랫폼 버전과 호환되지 않으므로 [Linux 애플리케이션을 Amazon Linux 2로 마이그레이션하려면](using-features.migration-al.md) 파란색/녹색 배포가 필요합니다.
최상의 플랫폼 업데이트 방법을 선택할 때 도움을 받으려면 환경 플랫폼에 대한 섹션을 확장하세요.
## Docker
[방법 1](#using-features.platform.upgrade.config)을 사용하여 플랫폼 업데이트를 수행합니다.
## 멀티컨테이너 도커
[방법 1](#using-features.platform.upgrade.config)을 사용하여 플랫폼 업데이트를 수행합니다.
## 미리 구성된 Docker
다음의 경우를 고려하세요.
+ 애플리케이션을 다른 플랫폼으로 마이그레이션하는 경우(예: *Go 1.4(Docker)*에서 *Go 1.11*로 또는 *Python 3.4(Docker)*에서 *Python 3.6*으로) [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 애플리케이션을 다른 Docker 컨테이너 버전으로 마이그레이션하는 경우(예: *Glassfish 4.1(Docker)*에서 *Glassfish 5.0(Docker)*으로) [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 컨테이너 버전 또는 메이저 버전 변경 없이 최신 플랫폼 버전으로 업데이트하는 경우 [방법 1](#using-features.platform.upgrade.config)을 사용합니다.
## Go
[방법 1](#using-features.platform.upgrade.config)을 사용하여 플랫폼 업데이트를 수행합니다.
## Java SE
다음의 경우를 고려하세요.
+ 애플리케이션을 다른 Java 런타임 버전으로 마이그레이션하는 경우(예: *Java 7*에서 *Java 8*로) [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 런타임 버전 변경 없이 최신 플랫폼 버전으로 업데이트하는 경우 [방법 1](#using-features.platform.upgrade.config)을 사용합니다.
## Java와 Tomcat
다음의 경우를 고려하세요.
+ 애플리케이션을 다른 Java 런타임 버전 또는 Tomcat 애플리케이션 서버 버전으로 마이그레이션하는 경우(예: *Java 7 with Tomcat 7*에서 *Java 8 with Tomcat 8.5*로) [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 메이저 Java with Tomcat 플랫폼 버전(v1.x.x, v2.x.x 및 v3.x.x) 간에 애플리케이션을 마이그레이션하는 경우 [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 런타임 버전, 애플리케이션 서버 버전 또는 메이저 버전 변경 없이 최신 플랫폼 버전으로 업데이트하는 경우 [방법 1](#using-features.platform.upgrade.config)을 사용합니다.
## IIS를 사용하는 Windows Server의 .NET
다음의 경우를 고려하세요.
+ 애플리케이션을 다른 Windows 운영 체제 버전으로 마이그레이션하는 경우(예: *Windows Server 2008 R2*에서 *Windows Server 2016*으로) [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 애플리케이션을 메이저 Windows Server 플랫폼 버전 간에 마이그레이션하는 경우 [Windows Server 플랫폼의 이전 메이저 버전에서 마이그레이션](dotnet-v2migration.md#dotnet-v2migration.migration) 단원을 참조하고 [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 애플리케이션이 현재 Windows Server 플랫폼 V2.x.x에서 실행 중이며 최신 플랫폼 버전으로 업데이트하는 경우 [방법 1](#using-features.platform.upgrade.config)을 사용합니다.
**참고**
[Windows Server 플랫폼 버전](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) v2 이전은 의미상 버전이 지정되지 않았습니다. 이러한 각 Windows Server 주 플랫폼 버전의 최신 버전만 시작할 수 있으며 업그레이드 후에는 롤백할 수 없습니다.
## Node.js
[방법 2](#using-features.platform.upgrade.bluegreen)를 사용하여 플랫폼 업데이트를 수행합니다.
## PHP
다음의 경우를 고려하세요.
+ 애플리케이션을 다른 PHP 런타임 버전으로 마이그레이션하는 경우(예: *PHP 5.6*에서 *PHP 7.2*로) [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 애플리케이션을 메이저 PHP 플랫폼 버전(v1.x.x 및 v2.x.x) 간에 마이그레이션하는 경우 [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 런타임 버전 또는 메이저 버전 변경 없이 최신 플랫폼 버전으로 업데이트하는 경우 [방법 1](#using-features.platform.upgrade.config)을 사용합니다.
## Python
다음의 경우를 고려하세요.
+ 애플리케이션을 다른 Python 런타임 버전으로 마이그레이션하는 경우(예: *Python 2.7*에서 *Python 3.6*으로) [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 애플리케이션을 메이저 Python 플랫폼 버전(v1.x.x 및 v2.x.x) 간에 마이그레이션하는 경우 [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 런타임 버전 또는 메이저 버전 변경 없이 최신 플랫폼 버전으로 업데이트하는 경우 [방법 1](#using-features.platform.upgrade.config)을 사용합니다.
## Ruby
다음의 경우를 고려하세요.
+ 애플리케이션을 다른 Ruby 런타임 버전 또는 애플리케이션 서버 버전으로 마이그레이션하는 경우(예: *Ruby 2.3 with Puma*에서 *Ruby 2.6 with Puma*로) [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 애플리케이션을 메이저 Ruby 플랫폼 버전(v1.x.x 및 v2.x.x) 간에 마이그레이션하는 경우 [방법 2](#using-features.platform.upgrade.bluegreen)를 사용합니다.
+ 런타임 버전, 애플리케이션 서버 버전 또는 메이저 버전 변경 없이 최신 플랫폼 버전으로 업데이트하는 경우 [방법 1](#using-features.platform.upgrade.config)을 사용합니다.
## 방법 1 – 환경의 플랫폼 버전 업데이트
환경 플랫폼 브랜치의 최신 버전으로 업데이트하려면 이 방법을 사용합니다. 이전 플랫폼 버전을 사용하여 이전에 환경을 생성했거나 환경을 이전 버전에서 업그레이드한 경우 이 방법을 사용하여 이전 플랫폼 버전(동일한 플랫폼 브랜치에 있는 경우)으로 되돌릴 수도 있습니다.
**환경의 플랫폼 버전을 업데이트하려면**
1. [Elastic Beanstalk 콘솔](https://console.aws.amazon.com/elasticbeanstalk)을 열고 **리전** 목록에서를 선택합니다 AWS 리전.
1. 탐색 창에서 **환경**을 선택한 다음 목록에서 환경의 이름을 선택합니다.
1. 환경 개요 페이지의 [**플랫폼**]에서 [**변경**]을 선택합니다.
![\[Elastic Beanstalk 최신 플랫폼 사용 가능\]](http://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/images/environment-management-platform-change.png)
1. [**플랫폼 버전 업데이트**] 대화 상자에서 플랫폼 버전을 선택합니다. 브랜치의 최신(권장) 플랫폼 버전이 자동으로 선택됩니다. 이전에 사용한 모든 버전으로 업데이트할 수 있습니다.
![\[Elastic Beanstalk 업데이트 플랫폼 버전 확인\]](http://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/images/environment-management-update-platform-version.png)
1. **저장**을 선택합니다.
플랫폼 업데이트를 더 간단하게 수행할 수 있도록 Elastic Beanstalk에서 해당 업데이트를 관리할 수 있습니다. 구성 가능한 주별 유지 관리 기간에 마이너 및 패치 버전 업데이트를 자동으로 적용하도록 환경을 구성할 수 있습니다. Elastic Beanstalk는 가동 중지나 용량 감소 없이 관리형 업데이트를 적용하고, 새 버전에서 애플리케이션을 실행하는 인스턴스가 상태 확인에 실패하면 즉시 업데이트를 취소합니다. 자세한 내용은 단원을 참조하세요[관리형 플랫폼 업데이트](environment-platform-update-managed.md)
## 방법 2 – 블루/그린 배포 수행
다른 런타임, 웹 서버, 애플리케이션 서버 또는 운영 체제를 포함하는 다른 플랫폼 브랜치로 업데이트하거나 다른 메이저 플랫폼 버전으로 업데이트하려면 이 방법을 사용합니다. 이는 일반적으로 새 런타임 기능 또는 최신 Elastic Beanstalk 기능을 활용하려고 할 때 필요합니다. 사용되지 않거나 만료된 플랫폼 브랜치에서 마이그레이션하는 경우에도 필요합니다.
주 플랫폼 버전 간 또는 주 구성 요소 업데이트가 있는 플랫폼 버전으로 마이그레이션할 때 애플리케이션 또는 일부 측면이 새 플랫폼 버전에서 예상대로 작동하지 않고 변경해야 할 가능성이 더 높습니다.
마이그레이션을 수행하기 전에 로컬 개발 컴퓨터를 마이그레이션 대상으로 계획한 플랫폼의 최신 런타임 버전 및 기타 구성 요소로 업데이트합니다. 애플리케이션이 계속 예상대로 작동하는지 확인하고 필요한 코드 수정 및 변경 작업을 수행합니다. 그리고 나서 다음 모범 사례 절차를 사용하여 환경을 새 플랫폼 버전으로 안전하게 마이그레이션합니다.
**환경을 주 업데이트와 함께 플랫폼 버전으로 마이그레이션하려면**
1. 새 대상 플랫폼 버전을 사용하여 [새 환경을 생성하고](using-features.environments.md) 애플리케이션 코드를 이 환경에 배포합니다. 새 환경은 마이그레이션하는 환경을 포함하는 Elastic Beanstalk 애플리케이션에 있어야 합니다. 기존 환경을 아직 종료하지 마세요.
1. 새 환경을 사용하여 애플리케이션을 마이그레이션합니다. 중요 사항:
+ 개발 단계 동안 발견하지 못한 애플리케이션 호환성 문제를 찾아서 수정합니다.
+ 애플리케이션이 [구성 파일](ebextensions.md)을 사용하여 만든 모든 사용자 지정이 새 환경에서 제대로 작동하는지 확인합니다. 여기에는 환경 인스턴스에 설치된 옵션 설정, 추가로 설치된 패키지, 사용자 지정 보안 정책 및 스크립트 또는 구성 파일이 포함될 수 있습니다.
+ 애플리케이션에서 사용자 지정 Amazon 머신 이미지(AMI)를 사용하는 경우 새 플랫폼 버전의 AMI를 기반으로 새 사용자 지정 AMI를 생성합니다. 자세한 내용은 [Elastic Beanstalk 환경에서 사용자 지정 Amazon Machine Image(AMI) 사용](using-features.customenv.md) 단원을 참조하세요. 특히 이는 애플리케이션이 Windows Server 플랫폼을 사용자 지정 AMI와 함께 사용하고 사용자가 Windows Server V2 플랫폼 버전으로 마이그레이션하는 경우 필요합니다. 이 경우 [Windows Server 플랫폼의 이전 메이저 버전에서 마이그레이션](dotnet-v2migration.md#dotnet-v2migration.migration) 단원을 참조하세요.
새 환경에서 애플리케이션이 만족스러울 때까지 반복하여 수정 사항을 테스트하고 배포하세요.
1. 환경의 CNAME을 기존 프로덕션 환경의 CNAME로 바꿔서 새 환경을 프로덕션 환경으로 전환하세요. 자세한 내용은 단원을 참조하세요[Elastic Beanstalk를 사용한 블루/그린 배포](using-features.CNAMESwap.md)
1. 프로덕션의 새 환경 상태가 만족스러우면 기존 환경을 종료하세요. 자세한 내용은 [Elastic Beanstalk 환경 종료](using-features.terminating.md) 섹션을 참조하십시오.