기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
소스 코드를 기반으로 하는 App Runner 서비스
AWS App Runner 를 사용하여 기본적으로 서로 다른 두 가지 유형의 서비스 소스, 즉 소스 코드와 소스 이미지를 기반으로 서비스를 생성하고 관리할 수 있습니다. 소스 유형에 관계없이 App Runner는 서비스 시작, 실행, 조정 및 로드 밸런싱을 처리합니다. App Runner의 CI/CD 기능을 사용하여 소스 이미지 또는 코드의 변경 사항을 추적할 수 있습니다. App Runner는 변경 사항을 발견하면 자동으로 빌드(소스 코드용)하고 새 버전을 App Runner 서비스에 배포합니다.
이 장에서는 소스 코드를 기반으로 하는 서비스에 대해 설명합니다. 소스 이미지를 기반으로 하는 서비스에 대한 자세한 내용은 섹션을 참조하세요소스 이미지를 기반으로 하는 App Runner 서비스.
소스 코드는 App Runner가 빌드하고 배포하는 애플리케이션 코드입니다. App Runner를 코드 리포지토리의 소스 디렉터리로 가리키고 프로그래밍 플랫폼 버전에 해당하는 적절한 런타임을 선택합니다. App Runner는 런타임의 기본 이미지와 애플리케이션 코드를 기반으로 이미지를 빌드합니다. 그런 다음이 이미지를 기반으로 컨테이너를 실행하는 서비스를 시작합니다.
App Runner는 편리한 플랫폼별 관리형 런타임을 제공합니다. 이러한 각 런타임은 소스 코드에서 컨테이너 이미지를 빌드하고 이미지에 언어 런타임 종속성을 추가합니다. Dockerfile과 같은 컨테이너 구성 및 빌드 지침을 제공할 필요가 없습니다.
이 장의 하위 주제에서는 App Runner가 지원하는 다양한 플랫폼, 즉 다양한 프로그래밍 환경 및 버전에 대한 관리형 런타임을 제공하는 관리형 플랫폼에 대해 설명합니다.
주제
소스 코드 리포지토리 공급자
App Runner는 소스 코드 리포지토리에서 소스 코드를 읽어 배포합니다. App Runner는 GitHub
소스 코드 리포지토리 공급자에서 배포
소스 코드 리포지토리에서 App Runner 서비스에 소스 코드를 배포하기 위해 App Runner는 소스 코드에 대한 연결을 설정합니다. App Runner 콘솔을 사용하여 서비스를 생성할 때 App Runner가 소스 코드를 배포할 수 있도록 연결 세부 정보와 소스 디렉터리를 제공합니다.
연결
서비스 생성 절차의 일부로 연결 세부 정보를 제공합니다. App Runner API 또는를 사용하는 경우 AWS CLI연결은 별도의 리소스입니다. 먼저 CreateConnection API 작업을 사용하여 연결을 생성합니다. 그런 다음 CreateService API 작업을 사용하여 서비스 생성 중에 연결의 ARN을 제공합니다.
소스 디렉터리
서비스를 생성할 때 소스 디렉터리도 제공합니다. 기본적으로 App Runner는 리포지토리의 루트 디렉터리를 소스 디렉터리로 사용합니다. 소스 디렉터리는 애플리케이션의 소스 코드 및 구성 파일을 저장하는 소스 코드 리포지토리의 위치입니다. 빌드 및 시작 명령은 소스 디렉터리에서도 실행됩니다. App Runner API 또는 AWS CLI 를 사용하여 서비스를 생성하거나 업데이트할 때 CreateService 및 UpdateService API 작업에 소스 디렉터리를 제공합니다. 자세한 내용은 이어지는 소스 디렉터리 단원을 참조하십시오.
App Runner 서비스 생성에 대한 자세한 내용은 섹션을 참조하세요App Runner 서비스 생성. App Runner 연결에 대한 자세한 내용은 섹션을 참조하세요App Runner 연결 관리.
소스 디렉터리
App Runner 서비스를 생성할 때 리포지토리 및 브랜치와 함께 소스 디렉터리를 제공할 수 있습니다. 소스 디렉터리 필드의 값을 애플리케이션의 소스 코드 및 구성 파일을 저장하는 리포지토리 디렉터리 경로로 설정합니다. App Runner는 사용자가 제공한 소스 디렉터리 경로에서 빌드 및 시작 명령을 실행합니다.
루트 리포지토리 디렉터리에서 소스 디렉터리 경로 값을 절대값으로 입력합니다. 값을 지정하지 않으면 기본적으로 리포지토리 루트 디렉터리라고도 하는 리포지토리 최상위 디렉터리로 설정됩니다.
또한 최상위 리포지토리 디렉터리 외에 다른 소스 디렉터리 경로를 제공할 수 있습니다. 이는 모노리포지토리 아키텍처를 지원합니다. 즉, 여러 애플리케이션의 소스 코드가 하나의 리포지토리에 저장됩니다. 단일 모노리포지토리에서 여러 App Runner 서비스를 생성하고 지원하려면 각 서비스를 생성할 때 서로 다른 소스 디렉터리를 지정합니다.
참고
여러 App Runner 서비스에 대해 동일한 소스 디렉터리를 지정하면 두 서비스가 개별적으로 배포되고 작동합니다.
apprunner.yaml 구성 파일을 사용하여 서비스 파라미터를 정의하도록 선택한 경우 리포지토리의 소스 디렉터리 폴더에 배치합니다.
배포 트리거 옵션이 자동으로 설정된 경우 소스 디렉터리에서 커밋한 변경 사항으로 인해 자동 배포가 트리거됩니다. 소스 디렉터리 경로의 변경 사항만 자동 배포를 트리거합니다. 소스 디렉터리의 위치가 자동 배포 범위에 미치는 영향을 이해하는 것이 중요합니다. 자세한 내용은의 자동 배포를 참조하세요배포 방법.
참고
App Runner 서비스가 PHP 관리형 런타임을 사용하고 기본 루트 리포지토리 이외의 소스 디렉터리를 지정하려는 경우 올바른 PHP 런타임 버전을 사용하는 것이 중요합니다. 자세한 내용은 PHP 플랫폼 사용 단원을 참조하십시오.
App Runner 관리형 플랫폼
App Runner 관리형 플랫폼은 다양한 프로그래밍 환경을 위한 관리형 런타임을 제공합니다. 각 관리형 런타임을 사용하면 프로그래밍 언어 또는 런타임 환경의 버전을 기반으로 컨테이너를 쉽게 빌드하고 실행할 수 있습니다. 관리형 런타임을 사용하는 경우 App Runner는 관리형 런타임 이미지로 시작합니다. 이 이미지는 Amazon Linux Docker 이미지를
App Runner 콘솔 또는 CreateService API 작업을 사용하여 서비스를 생성할 때 App Runner 서비스의 런타임을 지정합니다. 소스 코드의 일부로 런타임을 지정할 수도 있습니다. 코드 리포지토리에 포함하는 App Runner 구성 파일의 runtime 키워드를 사용합니다. 관리형 런타임의 이름 지정 규칙은 <language-name><major-version>입니다.
App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 App Runner 구성 파일의 runtime-version 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로를 잠글 수 있습니다. App Runner는 서비스의 런타임만 하위 수준으로 업데이트합니다.
관리형 런타임 버전 및 App Runner 빌드
이제 App Runner에서 애플리케이션에 대한 업데이트된 빌드 프로세스를 제공합니다. 현재 2023년 12월 29일에 마지막으로 릴리스된 관리형 런타임 Python 3.11 및 Node.js 18에서 실행되는 서비스에 대한 새 빌드를 호출합니다. 이 수정된 빌드 프로세스는 더 빠르고 효율적입니다. 또한 애플리케이션을 실행하는 데 필요한 소스 코드, 빌드 아티팩트 및 런타임만 포함하는 더 작은 공간으로 최종 이미지를 생성합니다.
최신 빌드 프로세스를 수정된 App Runner 빌드라고 하고 원래 빌드 프로세스를 원래 App Runner 빌드라고 합니다. 이전 버전의 런타임 플랫폼에 대한 변경 사항을 방지하기 위해 App Runner는 일반적으로 새로 릴리스된 주요 릴리스인 특정 런타임 버전에만 수정된 빌드를 적용합니다.
매우 구체적인 사용 사례에 맞게 수정된 빌드를 이전 버전과 호환하고 애플리케이션 빌드를 구성할 수 있는 유연성을 높이기 위해 apprunner.yaml 구성 파일에 새로운 구성 요소를 도입했습니다. 이는 선택적 pre-run 파라미터입니다. 다음 단원에서 빌드에 대한 다른 유용한 정보와 함께이 파라미터를 사용해야 하는 경우를 설명합니다.
다음 표에는 특정 관리형 런타임 버전에 적용되는 App Runner 빌드 버전이 나와 있습니다. 현재 런타임에 대한 최신 정보를 제공하기 위해이 문서를 계속 업데이트할 예정입니다.
중요
Python 3.11 - Python 3.11 관리형 런타임을 사용하는 서비스의 빌드 구성에 대한 특정 권장 사항이 있습니다. 자세한 내용은 Python 플랫폼 주제특정 런타임 버전에 대한 호출의 섹션을 참조하세요.
App Runner 빌드 및 마이그레이션에 대해 자세히 알아보기
수정된 빌드를 사용하는 최신 런타임으로 애플리케이션을 마이그레이션할 때 빌드 구성을 약간 수정해야 할 수 있습니다.
마이그레이션 고려 사항에 대한 컨텍스트를 제공하기 위해 먼저 원래 App Runner 빌드와 수정된 빌드 모두에 대한 상위 수준 프로세스를 설명합니다. 다음은 일부 구성 업데이트가 필요할 수 있는 서비스에 대한 특정 속성을 설명하는 섹션입니다.
원래 App Runner 빌드
원래 App Runner 애플리케이션 빌드 프로세스는 AWS CodeBuild 서비스를 활용합니다. 초기 단계는 CodeBuild 서비스에서 큐레이션한 이미지를 기반으로 합니다. 해당하는 App Runner 관리형 런타임 이미지를 기본 이미지로 사용하는 Docker 빌드 프로세스가 이어집니다.
일반적인 단계는 다음과 같습니다.
-
CodeBuild에서 선별한 이미지에서
pre-build명령을 실행합니다.pre-build명령은 선택 사항입니다.apprunner.yaml구성 파일에서만 지정할 수 있습니다. -
이전 단계의 동일한 이미지에서 CodeBuild를 사용하여
build명령을 실행합니다.build명령은 필수입니다. App Runner 콘솔, App Runner API 또는apprunner.yaml구성 파일에서 지정할 수 있습니다. -
Docker 빌드를 실행하여 특정 플랫폼 및 런타임 버전에 대한 App Runner 관리형 런타임 이미지를 기반으로 이미지를 생성합니다.
-
2단계에서 생성한 이미지에서
/app디렉터리를 복사합니다. 대상은 3단계에서 생성한 App Runner 관리형 런타임 이미지를 기반으로 하는 이미지입니다. -
생성된 App Runner 관리형 런타임 이미지에서
build명령을 다시 실행합니다. 빌드 명령을 다시 실행하여 4단계에서 복사한/app디렉터리의 소스 코드에서 빌드 아티팩트를 생성합니다. 이 이미지는 나중에 App Runner에서 배포하여 컨테이너에서 웹 서비스를 실행합니다.build명령은 필수입니다. App Runner 콘솔, App Runner API 또는apprunner.yaml구성 파일에서 지정할 수 있습니다. -
2단계의 CodeBuild 이미지에서
post-build명령을 실행합니다.post-build명령은 선택 사항입니다.apprunner.yaml구성 파일에서만 지정할 수 있습니다.
빌드가 완료되면 App Runner는 5단계에서 생성된 App Runner 관리형 런타임 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
수정된 App Runner 빌드
수정된 빌드 프로세스는 이전 섹션에 설명된 원래 빌드 프로세스보다 빠르고 효율적입니다. 이전 버전 빌드에서 발생하는 빌드 명령의 중복을 제거합니다. 또한 애플리케이션을 실행하는 데 필요한 소스 코드, 빌드 아티팩트 및 런타임만 포함하는 더 작은 공간으로 최종 이미지를 생성합니다.
이 빌드 프로세스는 Docker 다단계 빌드를 사용합니다. 일반적인 프로세스 단계는 다음과 같습니다.
-
빌드 단계 - App Runner 빌드 이미지 위에
pre-build및build명령을 실행하는 도커 빌드 프로세스를 시작합니다.-
애플리케이션 소스 코드를
/app디렉터리에 복사합니다.참고
이
/app디렉터리는 Docker 빌드의 모든 단계에서 작업 디렉터리로 지정됩니다. -
pre-build명령 실행명령은
pre-build선택 사항입니다.apprunner.yaml구성 파일에서만 지정할 수 있습니다. -
build명령을 실행합니다.build명령은 필수입니다. App Runner 콘솔, App Runner API 또는apprunner.yaml구성 파일에서 지정할 수 있습니다.
-
-
패키징 단계 - App Runner 실행 이미지를 기반으로 하는 최종 고객 컨테이너 이미지를 생성합니다.
-
이전 빌드 단계의
/app디렉터리를 새 실행 이미지로 복사합니다. 여기에는 애플리케이션 소스 코드와 이전 단계의 빌드 아티팩트가 포함됩니다. -
pre-run명령을 실행합니다.build명령을 사용하여/app디렉터리 외부에서 런타임 이미지를 수정해야 하는 경우apprunner.yaml구성 파일의이 세그먼트에 동일하거나 필요한 명령을 추가합니다.이는 수정된 App Runner 빌드를 지원하기 위해 도입된 새로운 파라미터입니다.
pre-run명령은 선택 사항입니다.apprunner.yaml구성 파일에서만 지정할 수 있습니다.Notes
-
pre-run명령은 수정된 빌드에서만 지원됩니다. 서비스에서 원래 빌드를 사용하는 런타임 버전을 사용하는 경우 구성 파일에 추가하지 마십시오. -
build명령을 사용하여/app디렉터리 외부에서 아무것도 수정할 필요가 없는 경우pre-run명령을 지정할 필요가 없습니다.
-
-
-
빌드 후 단계 -이 단계는 빌드 단계에서 재개되고
post-build명령을 실행합니다.-
/app디렉터리 내에서post-build명령을 실행합니다.post-build명령은 선택 사항입니다.apprunner.yaml구성 파일에서만 지정할 수 있습니다.
-
빌드가 완료되면 App Runner는 실행 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.
참고
빌드 프로세스를 구성할 apprunner.yaml 때의 실행 섹션에 있는 env 항목을 오해하지 마세요. 2(b)단계에서 참조된 pre-run 명령 파라미터가 실행 섹션에 있더라도 실행 섹션의 env 파라미터를 사용하여 빌드를 구성하지 마십시오. pre-run 명령은 구성 파일의 빌드 섹션에 정의된 env 변수만 참조합니다. 자세한 내용은 App Runner 구성 파일 실행 섹션 장의 섹션을 참조하세요.
마이그레이션 고려 사항에 대한 서비스 요구 사항
애플리케이션 환경에 이러한 두 요구 사항 중 하나가 있는 경우 pre-run 명령을 추가하여 빌드 구성을 수정해야 합니다.
build명령을 사용하여/app디렉터리 외부의 항목을 수정해야 하는 경우.-
build명령을 두 번 실행하여 필요한 환경을 생성해야 하는 경우. 이는 매우 드문 요구 사항입니다. 대부분의 빌드는이 작업을 수행하지 않습니다.
/app 디렉터리 외부의 수정 사항
-
수정된 App Runner 빌드는 애플리케이션에
/app디렉터리 외부의 종속성이 없다고 가정합니다. -
apprunner.yaml파일, App Runner API 또는 App Runner 콘솔과 함께 제공하는 명령은/app디렉터리에서 빌드 아티팩트를 생성해야 합니다. -
pre-build,build및post-build명령을 수정하여 모든 빌드 아티팩트가/app디렉터리에 있는지 확인할 수 있습니다. -
애플리케이션에 서비스에 대해 생성된 이미지를 추가로 수정하기 위한 빌드가 필요한 경우
/app디렉터리 외부에서의 새pre-run명령을 사용할 수 있습니다apprunner.yaml. 자세한 내용은 구성 파일을 사용하여 App Runner 서비스 옵션 설정 단원을 참조하십시오.
build 명령을 두 번 실행
-
원래 App Runner 빌드는
build명령을 두 번 실행합니다. 먼저 2단계에서 실행한 다음 5단계에서 다시 실행합니다. 수정된 App Runner 빌드는이 중복성을 해결하고build명령을 한 번만 실행합니다. 애플리케이션에build명령이 두 번 실행되기 위한 비정상적인 요구 사항이 있는 경우 수정된 App Runner 빌드는pre-run파라미터를 사용하여 동일한 명령을 다시 지정하고 실행하는 옵션을 제공합니다. 이렇게 하면 동일한 이중 빌드 동작이 유지됩니다.
