소스 코드 기반 앱 러너 서비스 - AWS 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는 Bitbucket이라는 두 개의 소스 코드 저장소 제공자를 지원합니다. GitHub

소스 코드 리포지토리 공급자를 통해 배포

소스 코드 리포지토리에서 App Runner 서비스에 소스 코드를 배포하기 위해 App Runner는 해당 서비스에 대한 연결을 설정합니다. App Runner 콘솔을 사용하여 서비스를 만들 때는 App Runner에서 소스 코드를 배포할 수 있도록 연결 세부 정보와 소스 디렉터리를 제공합니다.

연결

서비스 생성 절차의 일부로 연결 세부 정보를 제공합니다. App Runner API 또는 를 사용하는 경우 연결은 별도의 리소스입니다. AWS CLI먼저 CreateConnectionAPI 작업을 사용하여 연결을 생성합니다. 그런 다음 CreateServiceAPI 작업을 사용하여 서비스를 생성하는 동안 연결의 ARN을 제공합니다.

소스 디렉터리

서비스를 생성할 때 소스 디렉토리도 제공합니다. 기본적으로 App Runner는 저장소의 루트 디렉터리를 소스 디렉터리로 사용합니다. 소스 디렉터리는 애플리케이션의 소스 코드 및 구성 파일을 저장하는 소스 코드 리포지토리 내 위치입니다. 빌드 및 시작 명령은 소스 디렉터리에서도 실행됩니다. App Runner API 또는 AWS CLI 를 사용하여 서비스를 만들거나 업데이트할 때는 CreateServiceUpdateServiceAPI 작업에 소스 디렉터리를 제공합니다. 자세한 내용은 이어지는 소스 디렉터리 단원을 참조하십시오.

App Runner 서비스 생성에 대한 자세한 내용은 을 참조하십시오. 앱 러너 서비스 만들기 App Runner 연결에 대한 자세한 내용은 을 참조하십시오. 앱 러너 연결 관리

소스 디렉터리

App Runner 서비스를 생성할 때 리포지토리 및 브랜치와 함께 소스 디렉터리를 제공할 수 있습니다. 소스 디렉터리 필드의 값을 애플리케이션의 소스 코드 및 구성 파일을 저장하는 리포지토리 디렉터리 경로로 설정합니다. App Runner는 사용자가 제공한 소스 디렉터리 경로에서 빌드 및 시작 명령을 실행합니다.

루트 리포지토리 디렉토리의 소스 디렉토리 경로 값을 절대값으로 입력합니다. 값을 지정하지 않으면 리포지토리 최상위 디렉터리 (리포지토리 루트 디렉터리라고도 함) 가 기본값으로 사용됩니다.

최상위 저장소 디렉터리 외에 다른 소스 디렉터리 경로를 제공할 수도 있습니다. 이는 모노레포 리포지토리 아키텍처를 지원합니다. 즉, 여러 애플리케이션의 소스 코드가 하나의 리포지토리에 저장됩니다. 단일 저장소에서 여러 App Runner 서비스를 만들고 지원하려면 각 서비스를 생성할 때 다른 소스 디렉토리를 지정하십시오.

참고

여러 App Runner 서비스에 동일한 소스 디렉터리를 지정하는 경우 두 서비스 모두 개별적으로 배포되고 운영됩니다.

apprunner.yaml구성 파일을 사용하여 서비스 매개변수를 정의하기로 선택한 경우 해당 파일을 저장소의 소스 디렉토리 폴더에 배치하십시오.

배포 트리거 옵션이 자동으로 설정된 경우 원본 디렉터리에서 변경 내용을 적용하면 자동 배포가 트리거됩니다. 원본 디렉터리 경로의 변경 사항만 자동 배포를 트리거합니다. 소스 디렉터리의 위치가 자동 배포의 범위에 어떤 영향을 미치는지 이해하는 것이 중요합니다. 자세한 내용은 의 자동 배포를 참조하십시오. 배포 방법

참고

App Runner 서비스에서 PHP 관리 런타임을 사용하고 기본 루트 리포지토리가 아닌 다른 소스 디렉터리를 지정하려는 경우 올바른 PHP 런타임 버전을 사용하는 것이 중요합니다. 자세한 정보는 PHP 플랫폼 사용을 참조하세요.

앱 러너 관리형 플랫폼

App Runner 관리형 플랫폼은 다양한 프로그래밍 환경에 대한 관리형 런타임을 제공합니다. 각 관리형 런타임을 통해 프로그래밍 언어 또는 런타임 환경 버전을 기반으로 컨테이너를 쉽게 빌드하고 실행할 수 있습니다. 관리형 런타임을 사용하는 경우 App Runner는 관리형 런타임 이미지로 시작합니다. 이 이미지는 Amazon Linux Docker 이미지를 기반으로 하며, 언어 런타임 패키지는 물론 몇 가지 도구 및 널리 사용되는 종속성 패키지를 포함합니다. App Runner는 이 관리형 런타임 이미지를 기본 이미지로 사용하고 애플리케이션 코드를 추가하여 Docker 이미지를 구축합니다. 그런 다음 이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.

App Runner 콘솔 또는 API 작업을 사용하여 서비스를 만들 때 App Runner 서비스의 런타임을 지정합니다. CreateService 런타임을 소스 코드의 일부로 지정할 수도 있습니다. 코드 리포지토리에 포함하는 App Runner 구성 파일에서 runtime 키워드를 사용하십시오. 관리형 런타임의 명명 규칙은 다음과 같습니다. <language-name><major-version>

App Runner는 모든 배포 또는 서비스 업데이트 시 서비스의 런타임을 최신 버전으로 업데이트합니다. 애플리케이션에 특정 버전의 관리형 런타임이 필요한 경우 App Runner 구성 파일의 runtime-version 키워드를 사용하여 지정할 수 있습니다. 메이저 또는 마이너 버전을 포함하여 모든 수준의 버전으로 잠글 수 있습니다. 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 – 출시 정보

  • Python 3.8

  • Python 3.7

  • 파이썬 3.11 (!)

Node.js – 출시 정보

  • Node.js 16

  • Node.js 14

  • Node.js 12

  • Node.js 18

Corretto — 릴리스 정보

  • Corretto 11

  • Corretto 8

.NET – 릴리스 정보

  • .NET 6

PHP – 릴리스 정보

  • PHP 8.1

Ruby – 출시 정보

  • 루비 3.1

Go – 출시 정보

  • Go 1

중요

Python 3.11 — Python 3.11 관리 런타임을 사용하는 서비스의 빌드 구성에 대한 구체적인 권장 사항이 있습니다. 자세한 내용은 Python 플랫폼 주제를 참조하십시오특정 런타임 버전에 대한 콜아웃.

App Runner 빌드 및 마이그레이션에 대해 자세히 알아보기

수정된 빌드를 사용하는 최신 런타임으로 애플리케이션을 마이그레이션할 때 빌드 구성을 약간 수정해야 할 수 있습니다.

마이그레이션 고려 사항에 대한 컨텍스트를 제공하기 위해 먼저 원본 App Runner 빌드와 수정된 빌드의 상위 수준 프로세스를 설명하겠습니다. 이어서 일부 구성 업데이트가 필요할 수 있는 서비스의 특정 속성을 설명하는 섹션을 살펴보겠습니다.

오리지널 App Runner 빌드

오리지널 App Runner 애플리케이션 빌드 프로세스는 서비스를 활용합니다. AWS CodeBuild 초기 단계는 서비스에서 큐레이션한 이미지를 기반으로 합니다. CodeBuild 해당하는 App Runner 관리 런타임 이미지를 기본 이미지로 사용하는 Docker 빌드 프로세스가 이어집니다.

일반적인 단계는 다음과 같습니다.

  1. CodeBuild큐레이션된 이미지에서 pre-build 명령을 실행합니다.

    pre-build명령은 선택 사항입니다. apprunner.yaml구성 파일에서만 지정할 수 있습니다.

  2. 이전 단계의 동일한 CodeBuild 이미지에서 를 사용하여 build 명령을 실행합니다.

    build명령이 필요합니다. 앱 러너 콘솔, 앱 러너 API 또는 apprunner.yaml 구성 파일에서 지정할 수 있습니다.

  3. Docker 빌드를 실행하여 특정 플랫폼 및 런타임 버전에 대한 App Runner 관리형 런타임 이미지를 기반으로 이미지를 생성합니다.

  4. 2단계에서 생성한 이미지에서 /app 디렉토리를 복사합니다. 대상은 3단계에서 생성한 App Runner 관리 런타임 이미지를 기반으로 하는 이미지입니다.

  5. 생성된 App Runner 관리 런타임 이미지에서 build 명령을 다시 실행합니다. 빌드 명령을 다시 실행하여 4단계에서 복사한 /app 디렉터리의 소스 코드로부터 빌드 아티팩트를 생성합니다. 나중에 App Runner에서 이 이미지를 배포하여 컨테이너에서 웹 서비스를 실행할 것입니다.

    build명령은 필수입니다. 앱 러너 콘솔, 앱 러너 API 또는 apprunner.yaml 구성 파일에서 지정할 수 있습니다.

  6. 2단계의 CodeBuild 이미지에서 post-build 명령을 실행합니다.

    post-build명령은 선택 사항입니다. apprunner.yaml구성 파일에서만 지정할 수 있습니다.

빌드가 완료되면 App Runner는 5단계에서 생성된 App Runner 관리 런타임 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.

수정된 앱 러너 빌드

수정된 빌드 프로세스는 이전 섹션에서 설명한 원래 빌드 프로세스보다 더 빠르고 효율적입니다. 이전 버전 빌드에서 발생하는 빌드 명령의 중복을 제거합니다. 또한 애플리케이션을 실행하는 데 필요한 소스 코드, 빌드 아티팩트 및 런타임만 포함하는 더 작은 크기로 최종 이미지를 생성합니다.

이 빌드 프로세스는 Docker 다단계 빌드를 사용합니다. 일반적인 프로세스 단계는 다음과 같습니다.

  1. 빌드 단계 - App Runner 빌드 이미지를 기반으로 pre-build 실행하고 build 명령을 실행하는 docker 빌드 프로세스를 시작합니다.

    1. 애플리케이션 소스 코드를 디렉터리에 복사합니다. /app

      참고

      /app 디렉토리는 Docker 빌드의 모든 단계에서 작업 디렉토리로 지정됩니다.

    2. pre-build 명령 실행

      pre-build명령은 선택 사항입니다. apprunner.yaml구성 파일에서만 지정할 수 있습니다.

    3. build명령을 실행합니다.

      build명령이 필요합니다. 앱 러너 콘솔, 앱 러너 API 또는 apprunner.yaml 구성 파일에서 지정할 수 있습니다.

  2. 패키징 단계 — App Runner 실행 이미지를 기반으로 최종 고객 컨테이너 이미지를 생성합니다.

    1. 이전 빌드 단계의 /app 디렉터리를 새 Run 이미지로 복사합니다. 여기에는 애플리케이션 소스 코드와 이전 단계의 빌드 아티팩트가 포함됩니다.

    2. pre-run명령을 실행합니다. build명령을 사용하여 /app 디렉터리 외부에서 런타임 이미지를 수정해야 하는 경우 apprunner.yaml 구성 파일의 이 세그먼트에 동일하거나 필요한 명령을 추가하십시오.

      이는 수정된 App Runner 빌드를 지원하기 위해 도입된 새 매개변수입니다.

      pre-run명령은 선택 사항입니다. apprunner.yaml구성 파일에서만 지정할 수 있습니다.

      참고
      • pre-run명령은 수정된 빌드에서만 지원됩니다. 서비스에서 원본 빌드를 사용하는 런타임 버전을 사용하는 경우에는 구성 파일에 추가하지 마세요.

      • 명령을 사용하여 /app 디렉터리 외부의 내용을 수정할 필요가 없는 경우에는 build pre-run 명령을 지정할 필요가 없습니다.

  3. 빌드 후 단계 — 이 단계는 빌드 단계부터 다시 시작되어 명령을 실행합니다post-build.

    1. 디렉터리 내에서 post-build 명령을 /app 실행합니다.

      post-build명령은 선택 사항입니다. apprunner.yaml구성 파일에서만 지정할 수 있습니다.

빌드가 완료되면 App Runner는 Run 이미지를 배포하여 컨테이너에서 웹 서비스를 실행합니다.

참고

빌드 프로세스를 구성할 apprunner.yaml 때 Run 섹션의 env 항목에 현혹되지 마세요. 2단계 (b) 에서 참조한 pre-run 명령 매개변수가 Run 섹션에 있더라도 Run 섹션의 env 매개변수를 사용하여 빌드를 구성하지 마세요. pre-run명령은 구성 파일의 Build 섹션에 정의된 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 이렇게 하면 동일한 이중 빌드 동작이 유지됩니다.