Amazon CodeCatalyst는 더 이상 신규 고객에게 공개되지 않습니다. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 마이그레이션하는 방법](migration.md) 단원을 참조하십시오.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 컴퓨팅 및 런타임 이미지 구성
CodeCatalyst 워크플로에서 CodeCatalyst가 워크플로 작업을 실행하는 데 사용하는 컴퓨팅 및 런타임 환경 이미지를 지정할 수 있습니다.
*컴퓨팅*은 워크플로 작업을 실행하기 위해 CodeCatalyst에서 관리 및 유지 관리하는 컴퓨팅 엔진(CPU, 메모리 및 운영 체제)을 의미합니다.
**참고**
컴퓨팅이 워크플로의 속성으로 정의된 경우 해당 워크플로의 작업 속성으로 정의할 수 없습니다. 마찬가지로 컴퓨팅이 작업의 속성으로 정의된 경우 워크플로에서 정의할 수 없습니다.
*런타임 환경 이미지*는 CodeCatalyst가 워크플로 작업을 실행하는 Docker 컨테이너입니다. Docker 컨테이너는 선택한 컴퓨팅 플랫폼 위에서 실행되며, 운영 체제와 AWS CLI, Node.js 및 .tar와 같은 워크플로 작업에 필요할 수 있는 추가 도구를 포함합니다.
**Topics**
+ [컴퓨팅 유형](#compute.types)
+ [컴퓨팅 플릿](#compute.fleets)
+ [온디맨드 플릿 속성](#compute.on-demand)
+ [프로비저닝된 플릿 속성](#compute.provisioned-fleets)
+ [프로비저닝된 플릿 생성](projects-create-compute-resource.md)
+ [프로비저닝된 플릿 편집](edit-compute-resource.md)
+ [프로비저닝된 플릿 삭제](delete-compute-resource.md)
+ [작업에 플릿 또는 컴퓨팅 할당](workflows-assign-compute-resource.md)
+ [작업 간에 컴퓨팅 공유](compute-sharing.md)
+ [런타임 환경 이미지 지정](build-images.md)
## 컴퓨팅 유형
CodeCatalyst는 다음과 같은 컴퓨팅 유형을 제공합니다.
+ Amazon EC2
+ AWS Lambda
Amazon EC2는 작업 실행 중에 최적화된 유연성을 제공하고 Lambda는 최적화된 작업 시작 속도를 제공합니다. Lambda는 시작 지연 시간이 짧아 워크플로 작업 실행 속도가 빨라집니다. Lambda를 사용하면 일반적인 런타임으로 서버리스 애플리케이션을 빌드, 테스트 및 배포할 수 있는 기본 워크플로를 실행할 수 있습니다. 이러한 런타임에는 Node.js, Python, Java, .NET 및 Go가 포함됩니다. 그러나 Lambda가 지원하지 않는 일부 사용 사례가 있으며, 이러한 사용 사례가 영향을 미치는 경우 Amazon EC2 컴퓨팅 유형을 사용하세요.
+ Lambda는 지정된 레지스트리의 런타임 환경 이미지를 지원하지 않습니다.
+ Lamda에서 루트 권한이 필요한 도구는 지원하지 않습니다. `yum` 또는 `rpm` 등의 도구에는 Amazon EC2 컴퓨팅 유형이나 루트 권한이 필요하지 않은 기타 도구를 사용하세요.
+ Lamda에서는 Docker 빌드 또는 실행을 지원하지 않습니다. Docker 이미지를 사용하는 다음 작업은 지원되지 않습니다. AWS CloudFormation 스택 배포, Amazon ECS에 배포, Amazon S3 게시, AWS CDK 부트스트랩, AWS CDK 배포, AWS Lambda 간접 호출 및 GitHub 작업. CodeCatalyst GitHub Actions 작업 내에서 실행되는 Docker 기반 GitHub Actions도 Lambda 컴퓨팅에서 지원되지 않습니다. Podman과 같이 루트 권한이 필요하지 않은 대안을 사용할 수 있습니다.
+ Lamda에서는 `/tmp` 이외 파일에 쓰는 것을 지원하지 않습니다. 워크플로 작업을 구성할 때 설치하거나 `/tmp`에 쓸 수 있는 도구를 재구성합니다. `npm`을 설치하는 빌드 작업이 있는 경우 `/tmp`에 설치하도록 구성해야 합니다.
+ Lambda는 15분보다 긴 런타임을 지원하지 않습니다.
## 컴퓨팅 플릿
CodeCatalyst는 다음과 같은 컴퓨팅 플릿을 제공합니다.
+ 온디맨드 플릿
+ 프로비저닝된 플릿
온디맨드 플릿의 경우 워크플로 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝합니다. 작업이 완료되면 머신이 파괴됩니다. 작업을 실행하는 분 수에 대해서만 비용을 지불합니다. 온디맨드 플릿은 완전 관리형이며, 수요 급증을 처리할 수 있는 자동 규모 조정 기능이 포함되어 있습니다.
또한 CodeCatalyst는 CodeCatalyst에서 관리하는 Amazon EC2 기반 시스템을 포함하는 프로비저닝된 플릿을 제공합니다. 프로비저닝된 플릿을 사용하면 워크플로 작업을 실행하도록 전용 시스템 세트를 구성할 수 있습니다. 이러한 시스템은 유휴 상태로 유지되므로 작업을 즉시 처리할 수 있습니다. 프로비저닝된 플릿을 사용하면 머신이 상시 가동되므로 프로비저닝하는 비용이 발생합니다.
플릿을 생성하거나 업데이트 또는 삭제하려면 **스페이스 관리자** 역할 또는 **프로젝트 관리자** 역할이 있어야 합니다.
## 온디맨드 플릿 속성
CodeCatalyst는 다음과 같은 온디맨드 플릿을 제공합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/workflows-working-compute.html)
**참고**
온디맨드 플릿의 사양은 청구 계층에 따라 달라집니다. 자세한 내용은 [요금](https://codecatalyst.aws/explore/pricing)을 참조하세요.
플릿을 선택하지 않으면 CodeCatalyst는 `Linux.x86-64.Large`를 사용합니다.
## 프로비저닝된 플릿 속성
프로비저닝된 플릿에는 다음 속성이 포함됩니다.
**운영 체제**
운영 체제입니다. 사용할 수 있는 운영 체제는 다음과 같습니다.
+ Amazon Linux 2
+ Windows Server 2022
**참고**
Windows 플릿은 빌드 작업에서만 지원됩니다. 다른 작업은 현재 Windows를 지원하지 않습니다.
**아키텍처**
프로세서 아키텍처. 사용할 수 있는 아키텍처는 다음과 같습니다.
+ x86\$164
+ Arm64
**시스템 유형**
각 인스턴스의 머신 유형. 사용할 수 있는 유형의 로그는 다음과 같습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/workflows-working-compute.html)
**Capacity**
플릿에 할당된 초기 머신 수로, 병렬로 실행할 수 있는 작업 수를 정의합니다.
**규모 조정 모드**
작업 수가 플릿 용량을 초과할 때의 동작을 정의합니다.
**온디맨드 방식으로 추가 용량 프로비저닝**
온디맨드 방식으로 추가 머신이 설치되어 새 작업이 실행되면 자동으로 스케일 업이 실시되고 작업이 완료되면 기본 용량으로 스케일 다운이 실시됩니다. 실행 중인 각 머신에 대해 분 단위로 비용을 지불해야 하므로 추가 비용이 발생할 수 있습니다.
**추가 플릿 용량을 사용할 수 있을 때까지 대기**
머신을 사용할 수 있을 때까지 작업 실행이 대기열에 배치됩니다. 이렇게 하면 추가 머신이 할당되지 않으므로 추가 비용이 제한됩니다.
# 프로비저닝된 플릿 생성
다음 지침에 따라 프로비저닝된 플릿을 생성합니다.
**참고**
프로비저닝된 플릿은 2주 동안 사용하지 않으면 비활성화됩니다. 다시 사용하면 자동으로 다시 활성화되지만, 다시 활성화하면 지연 시간이 발생할 수 있습니다.
**프로비저닝된 플릿을 생성하려면**
1. 탐색 창에서 **CI/CD**를 선택한 후, **컴퓨팅**을 선택합니다.
1. **프로비저닝된 플릿 생성**을 선택합니다.
1. **프로비저닝된 플릿 이름** 텍스트 필드에 플릿의 이름을 입력합니다.
1. **운영 체제** 드롭다운 메뉴에서 운영 체제를 선택합니다.
1. **머신 유형** 드롭다운 메뉴에서 해당 머신 유형을 선택합니다.
1. **용량** 텍스트 필드에 플릿의 최대 머신 수를 입력합니다.
1. **규모 조정 모드** 드롭다운 메뉴에서 원하는 오버플로 동작을 선택합니다. 필드에 대한 자세한 내용은 [프로비저닝된 플릿 속성](workflows-working-compute.md#compute.provisioned-fleets) 섹션을 참조하세요.
1. **생성(Create)**을 선택합니다.
프로비저닝된 플릿을 생성하고 해당 플릿을 작업에 할당할 준비가 되었습니다. 자세한 내용은 [작업에 플릿 또는 컴퓨팅 할당](workflows-assign-compute-resource.md) 단원을 참조하십시오.
# 프로비저닝된 플릿 편집
다음 지침에 따라 프로비저닝된 플릿을 편집합니다.
**참고**
프로비저닝된 플릿은 2주 동안 사용하지 않으면 비활성화됩니다. 다시 사용하면 자동으로 다시 활성화되지만, 다시 활성화하면 지연 시간이 발생할 수 있습니다.
**프로비저닝된 플릿을 편집하려면**
1. 탐색 창에서 **CI/CD**를 선택한 후, **컴퓨팅**을 선택합니다.
1. **프로비저닝된 플릿** 목록에서 편집할 플릿을 선택합니다.
1. **편집**을 선택합니다.
1. **용량** 텍스트 필드에 플릿의 최대 머신 수를 입력합니다.
1. **규모 조정 모드** 드롭다운 메뉴에서 원하는 오버플로 동작을 선택합니다. 필드에 대한 자세한 내용은 [프로비저닝된 플릿 속성](workflows-working-compute.md#compute.provisioned-fleets) 섹션을 참조하세요.
1. **저장**을 선택합니다.
# 프로비저닝된 플릿 삭제
다음 지침에 따라 프로비저닝된 플릿을 삭제합니다.
**프로비저닝된 플릿을 삭제하려면**
**주의**
프로비저닝된 플릿을 삭제하기 전에 작업의 YAML 코드에서 `Fleet` 속성을 삭제하여 모든 작업에서 제거합니다. 프로비저닝된 플릿을 삭제한 후에도 계속 참조하는 작업은 다음 번에 작업이 실행될 때 실패합니다.
1. 탐색 창에서 **CI/CD**를 선택한 후, **컴퓨팅**을 선택합니다.
1. **프로비저닝된 플릿** 목록에서 삭제할 플릿을 선택합니다.
1. **삭제**를 선택합니다.
1. **delete**를 입력하여 삭제를 확인합니다.
1. **삭제**를 선택합니다.
# 작업에 플릿 또는 컴퓨팅 할당
기본적으로 워크플로 작업은 Amazon EC2 컴퓨팅 유형의 `Linux.x86-64.Large` 온디맨드 플릿을 사용합니다. 대신 프로비저닝된 플릿을 사용하거나 `Linux.x86-64.2XLarge`와 같은 다른 온디맨드 플릿을 사용하려면 다음 지침을 사용합니다.
------
#### [ Visual ]
**시작하기 전 준비 사항**
+ 프로비저닝된 플릿을 할당하려면 먼저 프로비저닝된 플릿을 생성해야 합니다. 자세한 내용은 [프로비저닝된 플릿 생성](projects-create-compute-resource.md) 섹션을 참조하세요.
**프로비저닝된 플릿 또는 다른 플릿 유형 작업 할당**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 프로비저닝된 플릿 또는 새 플릿 유형을 할당할 작업을 선택합니다.
1. **구성** 탭을 선택합니다.
1. **컴퓨팅 플릿**에서 다음을 수행합니다.
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. 온디맨드 플릿에 대한 자세한 내용은 [온디맨드 플릿 속성](workflows-working-compute.md#compute.on-demand) 섹션을 참조하세요.
프로비저닝된 플릿을 사용하면 워크플로 작업을 실행하도록 전용 시스템 세트를 구성할 수 있습니다. 이러한 시스템은 유휴 상태로 유지되므로 작업을 즉시 처리할 수 있습니다. 프로비저닝된 플릿에 대한 자세한 내용은 [프로비저닝된 플릿 속성](workflows-working-compute.md#compute.provisioned-fleets) 섹션을 참조하세요.
`Fleet` 생략 시 기본값은 `Linux.x86-64.Large`입니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**시작하기 전 준비 사항**
+ 프로비저닝된 플릿을 할당하려면 먼저 프로비저닝된 플릿을 생성해야 합니다. 자세한 내용은 [프로비저닝된 플릿 생성](projects-create-compute-resource.md) 섹션을 참조하세요.
**프로비저닝된 플릿 또는 다른 플릿 유형 작업 할당**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 프로비저닝된 플릿 또는 새 플릿 유형을 할당할 작업을 찾습니다.
1. 작업에서 `Compute` 속성을 추가하고 플릿 이름 또는 온디맨드 플릿 유형으로 `Fleet`을 설정합니다. 자세한 내용은 작업에 대한 [빌드 및 테스트 작업 YAML](build-action-ref.md)의 `Fleet` 속성 설명을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 작업 간에 컴퓨팅 공유
기본적으로 워크플로의 작업은 [플릿](workflows-working-compute.md#compute.fleets)의 개별 인스턴스에서 실행됩니다. 이 동작은 입력 상태에 대한 격리 및 예측 가능성을 갖춘 작업을 제공합니다. 기본 동작에는 작업 간에 파일 및 변수와 같은 컨텍스트를 공유하기 위한 명시적 구성이 필요합니다.
컴퓨팅 공유는 동일한 인스턴스의 워크플로에서 모든 작업을 실행할 수 있는 기능입니다. 컴퓨팅 공유를 사용하면 인스턴스 프로비저닝에 소요되는 시간이 줄어들기 때문에 워크플로 런타임이 빨라질 수 있습니다. 추가 워크플로 구성 없이 작업 간에 파일(아티팩트)을 공유할 수도 있습니다.
컴퓨팅 공유를 사용하여 워크플로를 실행할 때 기본 또는 지정된 플릿의 인스턴스는 해당 워크플로의 모든 작업 기간 동안 예약됩니다. 워크플로 실행이 완료되면 인스턴스 예약이 해제됩니다.
**Topics**
+ [공유 컴퓨팅에서 여러 작업 실행](#how-to-compute-share)
+ [컴퓨팅 공유 고려 사항](#compare-compute-sharing)
+ [컴퓨팅 공유 켜기](#compute-sharing-steps)
+ [예시](#compute-sharing-examples)
## 공유 컴퓨팅에서 여러 작업 실행
워크플로 수준에서 정의 YAML의 `Compute` 속성을 사용하여 작업의 플릿 및 컴퓨팅 공유 속성을 모두 지정할 수 있습니다. CodeCatalyst 의 시각적 편집기를 사용하여 컴퓨팅 속성을 구성할 수도 있습니다. 플릿을 지정하려면 기존 플릿의 이름을 설정하고 컴퓨팅 유형을 **EC2**로 설정하고 컴퓨팅 공유를 켭니다.
**참고**
컴퓨팅 공유는 컴퓨팅 유형이 **EC2**로 설정되어 있고 Windows Server 2022 운영 체제에서는 지원되지 않는 경우에만 지원됩니다. 컴퓨팅 플릿, 컴퓨팅 유형 및 속성에 대한 자세한 내용은 섹션을 참조하세요[컴퓨팅 및 런타임 이미지 구성](workflows-working-compute.md).
**참고**
프리 티어에 있고 워크플로 정의 YAML에서 `Linux.x86-64.XLarge` 또는 `Linux.x86-64.2XLarge` 플릿을 수동으로 지정하는 경우에도 작업은 기본 플릿(`Linux.x86-64.Large`)에서 계속 실행됩니다. 컴퓨팅 가용성 및 요금에 대한 자세한 내용은 [계층 옵션 의 표](https://codecatalyst.aws/explore/pricing)를 참조하세요.
컴퓨팅 공유가 켜져 있으면 워크플로 소스가 포함된 폴더가 작업 간에 자동으로 복사됩니다. 워크플로 정의(YAML 파일) 전체에서 출력 아티팩트를 구성하고 입력 아티팩트로 참조할 필요가 없습니다. 워크플로 작성자는 컴퓨팅 공유를 사용하지 않는 것처럼 입력과 출력을 사용하여 환경 변수를 연결해야 합니다. 워크플로 소스 외부의 작업 간에 폴더를 공유하려면 파일 캐싱을 고려하세요. 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 및 [워크플로 실행 간 파일 캐싱](workflows-caching.md) 섹션을 참조하세요.
워크플로 정의 파일이 있는 소스 리포지토리는 `WorkflowSource` 레이블로 식별됩니다. 컴퓨팅 공유를 사용하는 동안 워크플로 소스는 이를 참조하는 첫 번째 작업에서 다운로드되고 워크플로 실행에서 사용할 후속 작업에 자동으로 사용할 수 있습니다. 파일 추가, 수정 또는 제거와 같은 작업에 의해 워크플로 소스가 포함된 폴더에 대한 모든 변경 사항은 워크플로의 후속 작업에도 표시됩니다. 컴퓨팅 공유를 사용하지 않고도 워크플로 작업에서 워크플로 소스 폴더에 있는 파일을 최대한 참조할 수 있습니다. 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 섹션을 참조하세요.
**참고**
컴퓨팅 공유 워크플로는 엄격한 작업 시퀀스를 지정해야 하므로 병렬 작업을 설정할 수 없습니다. 출력 아티팩트는 시퀀스의 모든 작업에서 구성할 수 있지만 입력 아티팩트는 지원되지 않습니다.
## 컴퓨팅 공유 고려 사항
컴퓨팅 공유를 사용하여 워크플로를 실행하여 워크플로 실행을 가속화하고 동일한 인스턴스를 사용하는 워크플로의 작업 간에 컨텍스트를 공유할 수 있습니다. 컴퓨팅 공유 사용이 시나리오에 적합한지 확인하려면 다음을 고려하세요.
| | 컴퓨팅 공유 | 컴퓨팅 공유 없음 |
| --- | --- | --- |
| 컴퓨팅 유형 | Amazon EC2 | Amazon EC2, AWS Lambda |
| DB 인스턴스 프로비저닝 | 동일한 인스턴스에서 실행되는 작업 | 별도의 인스턴스에서 실행되는 작업 |
| 운영 체제 | Amazon Linux 2 | Amazon Linux 2, Windows Server 2022(빌드 작업만 해당) |
| 파일 참조 | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` |
| 워크플루 구조 | 작업은 순차적으로만 실행할 수 있습니다. | 작업을 병렬로 실행할 수 있습니다. |
| 워크플로 작업 전반의 데이터 액세스 | 캐시된 워크플로 소스 액세스(`WorkflowSource`) | 공유 아티팩트의 출력에 액세스(추가 구성 필요) |
## 컴퓨팅 공유 켜기
다음 지침에 따라 워크플로에 대한 컴퓨팅 공유를 켭니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 컴퓨팅 공유를 켜려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. **워크플로 속성**을 선택합니다.
1. **컴퓨팅 유형** 드롭다운 메뉴에서 **EC2**를 선택합니다.
1. (선택 사항) **컴퓨팅 플릿 - 선택 사항** 드롭다운 메뉴에서 워크플로 작업을 실행하는 데 사용할 플릿을 선택합니다. 온디맨드 플릿을 선택하거나 프로비저닝된 플릿을 생성하고 선택할 수 있습니다. 자세한 내용은 [프로비저닝된 플릿 생성](projects-create-compute-resource.md) 및 [작업에 플릿 또는 컴퓨팅 할당](workflows-assign-compute-resource.md) 섹션을 참조하세요.
1. 토글을 전환하여 컴퓨팅 공유를 켜고 워크플로에서 동일한 플릿에서 작업을 실행합니다.
1. (선택 사항) 워크플로의 실행 모드를 선택합니다. 자세한 내용은 [실행의 대기열 동작 구성](workflows-configure-runs.md) 섹션을 참조하세요.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 컴퓨팅 공유를 켜려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 컴퓨팅 공유를 켜서 `SharedInstance` 필드를 `TRUE`로 설정하고 `Type`을 `EC2`로 설정합니다. 워크플로 작업을 실행하는 데 사용할 컴퓨팅 플릿을 `Fleet`으로 설정합니다. 온디맨드 플릿을 선택하거나 프로비저닝된 플릿을 생성하고 선택할 수 있습니다. 자세한 내용은 [프로비저닝된 플릿 생성](projects-create-compute-resource.md) 및 [작업에 플릿 또는 컴퓨팅 할당](workflows-assign-compute-resource.md) 섹션을 참조하세요.
워크플로 YAML에서 다음과 유사한 코드를 추가합니다.
```
Name: MyWorkflow
SchemaVersion: "1.0"
Compute: # Define compute configuration.
Type: EC2
Fleet: MyFleet # Optionally, choose an on-demand or provisioned fleet.
SharedInstance: true # Turn on compute sharing. Default is False.
Actions:
BuildFirst:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: ...
...
```
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
## 예시
**Topics**
+ [예시: Amazon S3 게시](#compute-share-s3)
### 예시: Amazon S3 게시
다음 워크플로 예시는 Amazon S3 게시 작업을 두 가지 방식으로 수행하는 방법을 보여줍니다. 먼저 입력 아티팩트를 사용한 다음 컴퓨팅 공유를 사용합니다. 컴퓨팅 공유를 사용하면 캐시된 `WorkflowSource`에 액세스할 수 있으므로 입력 아티팩트가 필요하지 않습니다. 또한 빌드 작업의 출력 아티팩트는 더 이상 필요하지 않습니다. S3 게시 작업은 명시적 `DependsOn` 속성을 사용하여 순차적 작업을 유지하도록 구성됩니다. 빌드 작업은 S3 게시 작업이 실행되려면 성공적으로 실행되어야 합니다.
+ 컴퓨팅 공유가 없으면 입력 아티팩트를 사용하고 출력을 후속 작업과 공유해야 합니다.
```
Name: S3PublishUsingInputArtifact
SchemaVersion: "1.0"
Actions:
Build:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ArtifactToPublish
Files: [output.zip]
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: ./build.sh # Build script that generates output.zip
PublishToS3:
Identifier: aws/s3-publish@v1
Inputs:
Artifacts:
- ArtifactToPublish
Environment:
Connections:
- Role: codecatalyst-deployment-role
Name: dev-deployment-role
Name: dev-connection
Configuration:
SourcePath: output.zip
DestinationBucketName: amzn-s3-demo-bucket
```
+ `SharedInstance`를 `TRUE`로 설정하여 컴퓨팅 공유를 사용하는 경우 동일한 인스턴스에서 여러 작업을 실행하고 단일 워크플로 소스를 지정하여 아티팩트를 공유할 수 있습니다. 입력 아티팩트는 필요하지 않으며 지정할 수 없습니다.
```
Name: S3PublishUsingComputeSharing
SchemaVersion: "1.0"
Compute:
Type: EC2
Fleet: dev-fleet
SharedInstance: TRUE
Actions:
Build:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: ./build.sh # Build script that generates output.zip
PublishToS3:
Identifier: aws/s3-publish@v1
DependsOn:
- Build
Environment:
Connections:
- Role: codecatalyst-deployment-role
Name: dev-deployment-role
Name: dev-connection
Configuration:
SourcePath: output.zip
DestinationBucketName: amzn-s3-demo-bucket
```
# 런타임 환경 이미지 지정
*런타임 환경 이미지*는 CodeCatalyst가 워크플로 작업을 실행하는 Docker 컨테이너입니다. Docker 컨테이너는 선택한 컴퓨팅 플랫폼을 기반으로 실행되며, 운영 체제와 AWS CLI, Node.js, .tar 등 워크플로 작업에 필요할 수 있는 추가 도구를 포함합니다.
기본적으로 워크플로 작업은 CodeCatalyst에서 제공하고 유지 관리하는 [활성 이미지](#build-curated-images) 중 하나에서 실행됩니다. 빌드 및 테스트 작업만 사용자 지정 이미지를 지원합니다. 자세한 내용은 [작업에 사용자 지정 런타임 환경 Docker 이미지 할당](#build-images-specify) 단원을 참조하십시오.
**Topics**
+ [활성 이미지](#build-curated-images)
+ [활성 이미지에 필요한 도구가 포함되지 않은 경우 어떻게 해야 하나요?](#build-images-more-tools)
+ [작업에 사용자 지정 런타임 환경 Docker 이미지 할당](#build-images-specify)
+ [예제](#workflows-working-custom-image-ex)
## 활성 이미지
*활성 이미지*는 CodeCatalyst에서 완전히 지원되며 사전 설치된 도구를 포함하는 런타임 환경 이미지입니다. 현재 두 가지 활성 이미지 세트가 있습니다. 하나는 2024년 3월에, 다른 하나는 2022년 11월에 릴리스되었습니다.
작업이 2024년 3월 또는 2022년 11월 이미지 중 사용할 이미지는 작업에 따라 달라집니다.
+ 2024년 3월 26일 또는 그 이후에 워크플로에 추가된 빌드 및 테스트 작업은 [2024년 3월 이미지](#build.default-image)를 명시적으로 지정하는 `Container` 섹션을 YAML 정의에 포함합니다. 선택적으로 `Container` 섹션을 제거하여 [2022년 11월 이미지](#build.previous-image)로 되돌릴 수 있습니다.
+ 2024년 3월 26일 이전에 워크플로에 추가된 빌드 및 테스트 작업은 YAML 정의에 `Container` 섹션을 포함하지 *않으므로* [2022년 11월 이미지](#build.previous-image)를 사용합니다. 2022년 11월 이미지를 유지하거나 업그레이드할 수 있습니다. 이미지를 업그레이드하려면 시각적 편집기에서 작업을 열고 **구성** 탭을 선택한 다음 **런타임 환경 Docker 이미지** 드롭다운 목록에서 2024년 3월 이미지를 선택합니다. 이 항목을 선택하면 작업의 YAML 정의에 `Container` 섹션이 추가되며, 이 섹션은 적절한 2024년 3월 이미지로 채워집니다.
+ 다른 모든 작업은 [2022년 11월 이미지](#build.previous-image) 또는 [2024년 3월 이미지](#build.default-image)를 사용합니다. 자세한 내용은 작업 문서를 참조하세요.
**Topics**
+ [2024년 3월 이미지](#build.default-image)
+ [2022년 11월 이미지](#build.previous-image)
### 2024년 3월 이미지
2024년 3월 이미지는 CodeCatalyst에서 제공하는 최신 이미지입니다. 컴퓨팅 유형/플릿 조합당 2024년 3월 이미지가 하나 있습니다.
다음 표는 각 2024년 3월 이미지에 설치된 도구를 보여줍니다.
**2024년 3월 이미지 도구**
| 도구 | Linux x86\$164용 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_x86_64:2024_03` | Linux x86\$164용 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_x86_64:2024_03` | Linux Arm64용 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_Arm64:2024_03` | Linux Arm64용 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_Arm64:2024_03` |
| --- | --- | --- | --- | --- |
| AWS CLI | 2.15.17 | 2.15.17 | 2.15.17 | 2.15.17 |
| AWS Copilot CLI | 1.32.1 | 1.32.1 | 1.32.1 | 1.32.1 |
| Docker | 24.0.9 | 해당 사항 없음 | 24.0.9 | 해당 사항 없음 |
| Docker Compose | 2.23.3 | 해당 사항 없음 | 2.23.3 | 해당 사항 없음 |
| Git | 2.43.0 | 2.43.0 | 2.43.0 | 2.43.0 |
| Go | 1.21.5 | 1.21.5 | 1.21.5 | 1.21.5 |
| Gradle | 8.5 | 8.5 | 8.5 | 8.5 |
| Java | Corretto17 | Corretto17 | Corretto17 | Corretto17 |
| Maven | 3.9.6 | 3.9.6 | 3.9.6 | 3.9.6 |
| Node.js | 18.19.0 | 18.19.0 | 18.19.0 | 18.19.0 |
| npm | 10.2.3 | 10.2.3 | 10.2.3 | 10.2.3 |
| Python | 3.9.18 | 3.9.18 | 3.9.18 | 3.9.18 |
| Python3 | 3.11.6 | 3.11.6 | 3.11.6 | 3.11.6 |
| pip | 22.3.1 | 22.3.1 | 22.3.1 | 22.3.1 |
| .NET | 8.0.100 | 8.0.100 | 8.0.100 | 8.0.100 |
### 2022년 11월 이미지
컴퓨팅 유형/플릿 조합당 2022년 11월 이미지가 하나 있습니다. [프로비저닝된 플릿](workflows-working-compute.md#compute.fleets)을 구성한 경우 빌드 작업과 함께 사용할 수 있는 2022년 11월 Windows 이미지도 있습니다.
다음 표는 각 2022년 11월 이미지에 설치된 도구를 보여줍니다.
**2022년 11월 이미지 도구**
| 도구 | Linux x86\$164용 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_x86_64:2022_11` | Linux x86\$164용 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_x86_64:2022_11` | Linux Arm64용 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_Arm64:2022_11` | Linux Arm64용 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_Arm64:2022_11` | Windows x86\$164용 CodeCatalyst Amazon EC2 - `CodeCatalystWindows_x86_64:2022_11` |
| --- | --- | --- | --- | --- | --- |
| AWS CLI | 2.15.17 | 2.15.17 | 2.15.17 | 2.15.17 | 2.13.19 |
| AWS Copilot CLI | 0.6.0 | 0.6.0 | 해당 사항 없음 | 해당 사항 없음 | 1.30.1 |
| Docker | 23.01 | 해당 사항 없음 | 23.0.1 | 해당 사항 없음 | 해당 사항 없음 |
| Docker Compose | 2.16.0 | 해당 사항 없음 | 2.16.0 | 해당 사항 없음 | 해당 사항 없음 |
| Git | 2.40.0 | 2.40.0 | 2.39.2 | 2.39.2 | 2.42.0 |
| Go | 1.20.2 | 1.20.2 | 1.20.1 | 1.20.1 | 1.19 |
| Gradle | 8.0.2 | 8.0.2 | 8.0.1 | 8.0.1 | 8.3 |
| Java | Corretto17 | Corretto17 | Corretto17 | Corretto17 | Corretto17 |
| Maven | 3.9.4 | 3.9.4 | 3.9.0 | 3.9.0 | 3.9.4 |
| Node.js | 16.20.2 | 16.20.2 | 16.19.1 | 16.14.2 | 16.20.0 |
| npm | 8.19.4 | 8.19.4 | 8.19.3 | 8.5.0 | 8.19.4 |
| Python | 3.9.15 | 2.7.18 | 3.11.2 | 2.7.18 | 3.9.13 |
| Python3 | 해당 사항 없음 | 3.9.15 | 해당 사항 없음 | 3.11.2 | 해당 사항 없음 |
| pip | 22.2.2 | 22.2.2 | 23.0.1 | 23.0.1 | 22.0.4 |
| .NET | 6.0.407 | 6.0.407 | 6.0.406 | 6.0.406 | 6.0.414 |
## 활성 이미지에 필요한 도구가 포함되지 않은 경우 어떻게 해야 하나요?
CodeCatalyst에서 제공하는 [활성 이미지](#build-curated-images)에 필요한 도구가 포함되어 있지 않은 경우 몇 가지 옵션이 있습니다.
+ 필요한 도구가 포함된 사용자 지정 런타임 환경 Docker 이미지를 제공할 수 있습니다. 자세한 내용은 [작업에 사용자 지정 런타임 환경 Docker 이미지 할당](#build-images-specify) 단원을 참조하십시오.
**참고**
사용자 지정 런타임 환경 Docker 이미지를 제공하려면 사용자 지정 이미지에 Git이 설치되어 있는지 확인합니다.
+ 워크플로의 빌드 또는 테스트 작업을 통해 필요한 도구를 설치할 수 있습니다.
예를 들어 빌드 또는 테스트 작업의 YAML 코드 `Steps` 섹션에 다음 지침을 포함할 수 있습니다.
```
Configuration:
Steps:
- Run: ./setup-script
```
그런 다음 *setup-script* 명령은 다음 스크립트를 실행하여 노드 패키지 관리자(npm)를 설치합니다.
```
#!/usr/bin/env bash
echo "Setting up environment"
touch ~/.bashrc
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash
source ~/.bashrc
nvm install v16.1.0
source ~/.bashrc
```
빌드 작업 YAML에 대한 자세한 내용은 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요.
## 작업에 사용자 지정 런타임 환경 Docker 이미지 할당
CodeCatalyst에서 제공하는 [활성 이미지](#build-curated-images)를 사용하지 않으려면 사용자 지정 런타임 환경 Docker 이미지를 제공할 수 있습니다. 사용자 지정 이미지를 제공하려는 경우 Git이 설치되어 있는지 확인합니다. 이미지는 Docker Hub, Amazon Elastic Container Registry 또는 모든 퍼블릭 리포지토리에 저장될 수 있습니다.
사용자 지정 Docker 이미지를 생성하는 방법을 알아보려면 Docker 설명서의 [애플리케이션 컨테이너화](https://docs.docker.com/get-started/02_our_app/)를 참조하세요.
다음 지침을 사용하여 사용자 지정 런타임 환경 Docker 이미지를 작업에 할당합니다. 이미지를 지정하면 작업이 시작될 때 CodeCatalyst가 해당 이미지를 컴퓨팅 플랫폼에 배포합니다.
**참고**
** CloudFormation 스택 배포**, **ECS에 배포**, **GitHub 작업** 등의 작업은 사용자 지정 런타임 환경 Docker 이미지를 지원하지 않습니다. 사용자 지정 런타임 환경 Docker 이미지도 **Lambda** 컴퓨팅 유형을 지원하지 않습니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 사용자 지정 런타임 환경 Docker 이미지를 할당하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 사용자 지정 런타임 환경 Docker 이미지를 사용할 작업을 선택합니다.
1. **구성** 탭을 선택합니다.
1. 하단 근처에 다음 필드를 입력합니다.
**런타임 환경 Docker 이미지 - 선택 사항**
이미지가 저장되는 레지스트리를 지정합니다. 유효한 값으로는 다음이 포함됩니다.
+ `CODECATALYST` (YAML 편집기)
이미지는 CodeCatalyst 레지스트리에 저장됩니다.
+ **Docker Hub**(시각 편집기) 또는 `DockerHub`(YAML 편집기)
이미지는 Docker Hub 이미지 레지스트리에 저장됩니다.
+ **기타 레지스트리**(시각 편집기) 또는 `Other`(YAML 편집기)
이미지는 사용자 지정 이미지 레지스트리에 저장됩니다. 공개적으로 사용 가능한 레지스트리를 사용할 수 있습니다.
+ **Amazon Elastic Container Registry**(시각 편집기) 또는 `ECR`(YAML 편집기)
이미지는 Amazon Elastic Container Registry 이미지 리포지토리에 저장됩니다. Amazon ECR 리포지토리에서 이미지를 사용하려면 이 작업에서 Amazon ECR에 대한 액세스 권한이 필요합니다. 이 액세스를 활성화하려면 다음 권한과 사용자 지정 신뢰 정책을 포함하는 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)을 생성해야 합니다. (원하는 경우 권한 및 정책을 포함하도록 기존 역할을 수정할 수 있습니다.)
IAM 역할에는 역할 정책의 다음 권한이 포함되어야 합니다.
+ `ecr:BatchCheckLayerAvailability`
+ `ecr:BatchGetImage`
+ `ecr:GetAuthorizationToken`
+ `ecr:GetDownloadUrlForLayer`
IAM 역할에는 다음과 같은 사용자 지정 신뢰 정책이 포함되어야 합니다.
IAM 역할 생성에 대한 자세한 정보는 *IAM 사용자 설명서*의 [사용자 지정 신뢰 정책을 사용하여 역할 생성(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)을 참조하세요.
역할을 생성한 후에는 환경을 통해 작업에 할당해야 합니다. 자세한 내용은 [작업과 환경 연결](deploy-environments-add-app-to-environment.md) 단원을 참조하십시오.
**ECR 이미지 URL,** **Docker Hub 이미지** 또는 **이미지 URL**
다음 중 하나를 지정하세요.
+ `CODECATALYST` 레지스트리를 사용하는 경우 이미지를 다음 [활성 이미지](#build-curated-images) 중 하나로 설정합니다.
+ `CodeCatalystLinux_x86_64:2024_03`
+ `CodeCatalystLinux_x86_64:2022_11`
+ `CodeCatalystLinux_Arm64:2024_03`
+ `CodeCatalystLinux_Arm64:2022_11`
+ `CodeCatalystLinuxLambda_x86_64:2024_03`
+ `CodeCatalystLinuxLambda_x86_64:2022_11`
+ `CodeCatalystLinuxLambda_Arm64:2024_03`
+ `CodeCatalystLinuxLambda_Arm64:2022_11`
+ `CodeCatalystWindows_x86_64:2022_11`
+ Docker Hub 레지스트리를 사용하는 경우 이미지를 Docker Hub 이미지 이름과 선택적 태그로 설정합니다.
예시: `postgres:latest`
+ Amazon ECR 레지스트리를 사용하는 경우 이미지를 Amazon ECR 레지스트리 URI로 설정합니다.
예시: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`
+ 사용자 지정 레지스트리를 사용하는 경우 이미지를 사용자 지정 레지스트리에서 예상되는 값으로 설정합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 사용자 지정 런타임 환경 Docker 이미지를 할당하려면**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 런타임 환경 Docker 이미지를 할당하려는 작업을 찾습니다.
1. 작업에 `Container` 섹션과 기본 `Registry` 및 `Image` 속성을 추가합니다. 자세한 내용은 작업에 대한 [작업](workflow-reference.md#actions-reference)의 `Container`, `Registry`, `Image` 속성에 대한 설명을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
## 예제
다음 예시에서는 워크플로 정의 파일의 작업에 사용자 지정 런타임 환경 Docker 이미지를 할당하는 방법을 보여줍니다.
**Topics**
+ [예시: 사용자 지정 런타임 환경 Docker 이미지를 사용하여 Amazon ECR에서 Node.js 18에 대한 지원 추가](#workflows-working-custom-image-ex-ecr-node18)
+ [예시: 사용자 지정 런타임 환경 Docker 이미지를 사용하여 Docker Hub에서 Node.js 18에 대한 지원 추가](#workflows-working-custom-image-ex-docker-node18)
### 예시: 사용자 지정 런타임 환경 Docker 이미지를 사용하여 Amazon ECR에서 Node.js 18에 대한 지원 추가
다음 예시에서는 사용자 지정 런타임 환경 Docker 이미지를 사용하여 [Amazon ECR](https://gallery.ecr.aws/amazonlinux/amazonlinux)에서 Node.js 18에 대한 지원을 추가하는 방법을 보여줍니다.
```
Configuration:
Container:
Registry: ECR
Image: public.ecr.aws/amazonlinux/amazonlinux:2023
```
### 예시: 사용자 지정 런타임 환경 Docker 이미지를 사용하여 Docker Hub에서 Node.js 18에 대한 지원 추가
다음 예시에서는 사용자 지정 런타임 환경 Docker 이미지를 사용하여 [Docker Hub](https://hub.docker.com/_/node)에서 Node.js 18에 대한 지원을 추가하는 방법을 보여줍니다.
```
Configuration:
Container:
Registry: DockerHub
Image: node:18.18.2
```