Amazon CodeCatalyst는 더 이상 신규 고객에게 공개되지 않습니다. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 마이그레이션하는 방법](migration.md) 단원을 참조하십시오.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 워크플로를 사용하여 빌드, 테스트 및 배포
[CodeCatalyst 개발 환경](devenvironment.md)에 애플리케이션 코드를 쓰고 이를 [CodeCatalyst 소스 리포지토리 ](source.md)에 푸시하고 나면 배포할 준비가 되었습니다. 이를 자동으로 수행하는 방법은 워크플로를 통하는 것입니다.
*워크플로*는 지속적 통합 및 지속적 전송(CI/CD) 시스템의 일부로 코드를 빌드, 테스트 및 배포하는 방법을 설명하는 자동화된 절차입니다. 워크플로는 워크플로 실행 중에 수행할 일련의 단계 또는 *작업*을 정의합니다. 또한 워크플로는 워크플로를 시작하게 하는 이벤트 또는 *트리거*를 정의합니다. 워크플로를 설정하려면 CodeCatalyst 콘솔의 [시각적 또는 YAML 편집기](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors)를 사용하여 *워크플로 정의 파일*을 생성합니다.
**작은 정보**
프로젝트에서 워크플로를 사용하는 방법을 간략하게 알아보려면 [블루프린트가 있는 프로젝트를 생성](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template)합니다. 각 블루프린트는 검토, 실행 및 실험할 수 있는 기능 워크플로를 배포합니다.
## 워크플로 정의 파일 정보
*워크플로 정의 파일*은 워크플로를 설명하는 YAML 파일입니다. 기본적으로 파일은 [소스 리포지토리](source-repositories.md)의 루트에 있는 `~/.codecatalyst/workflows/` 폴더에 저장됩니다. 파일은 확장자가 .yml 또는 .yaml일 수 있으며 확장자는 소문자여야 합니다.
다음은 간단한 워크플로 정의 파일의 예시입니다. 다음 테이블에서 이 예시의 각 줄에 대해 설명합니다.
```
Name: MyWorkflow
SchemaVersion: 1.0
RunMode: QUEUED
Triggers:
- Type: PUSH
Branches:
- main
Actions:
Build:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: docker build -t MyApp:latest .
```
| 행 | 설명 |
| --- | --- |
| Name: MyWorkflow
| 워크플로의 이름을 지정합니다. `Name` 속성에 대한 자세한 내용은 [최상위 속성](workflow-reference.md#workflow.top.level) 섹션을 참조하세요. |
| SchemaVersion: 1.0
| 워크플로 스키마 버전을 지정합니다. `SchemaVersion` 속성에 대한 자세한 내용은 [최상위 속성](workflow-reference.md#workflow.top.level) 섹션을 참조하세요. |
| RunMode: QUEUED
| CodeCatalyst가 여러 실행을 처리하는 방법을 나타냅니다. 실행 모드에 대한 자세한 내용은 [실행의 대기열 동작 구성](workflows-configure-runs.md) 섹션을 참조하세요. |
| Triggers:
| 워크플로 실행을 시작할 로직을 지정합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요. |
| - Type: PUSH
Branches:
- main
| 기본 소스 리포지토리의 `main` 브랜치에 코드를 푸시할 때마다 워크플로가 시작되어야 함을 나타냅니다. 워크플로 소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요. |
| Actions:
| 워크플로 실행 중에 수행할 작업을 정의합니다. 이 예시에서는 `Actions` 섹션은 `Build`라는 단일 작업을 정의합니다. 작업에 대한 자세한 내용은 [워크플로 작업 구성](workflows-actions.md) 섹션을 참조하세요. |
| Build:
| `Build` 작업의 속성을 정의합니다. 빌드 작업에 대한 자세한 내용은 [워크플로로 빌드하기](build-workflow-actions.md) 섹션을 참조하세요. |
| Identifier: aws/build@v1
| 빌드 작업의 하드 코딩된 고유 식별자를 지정합니다. |
| Inputs:
Sources:
- WorkflowSource
| 빌드 작업이 처리를 완료하는 데 필요한 파일을 찾기 위해 `WorkflowSource` 소스 리포지토리에서 확인되어야 함을 나타냅니다. 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요. |
| Configuration:
| 빌드 작업과 관련된 구성 속성을 포함합니다. |
| Steps:
- Run: docker build -t MyApp:latest .
| 빌드 작업에 `MyApp`이라는 Docker 이미지를 빌드하고 `latest`로 태그를 지정하도록 지시합니다. |
워크플로 정의 파일에서 사용 가능한 모든 속성의 전체 목록은 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
## CodeCatalyst 콘솔의 시각적 및 YAML 편집기 사용
워크플로 정의 파일을 생성하고 편집하려면 원하는 편집기를 사용할 수 있지만 CodeCatalyst 콘솔의 시각적 편집기 또는 YAML 편집기를 사용하는 것이 좋습니다. 이러한 편집기는 YAML 속성 이름, 값, 중첩, 간격, 대문자 표기 등이 올바른지 확인하는 데 도움이 되는 파일 검증을 제공합니다.
다음 이미지는 시각적 편집기의 워크플로를 보여줍니다. 시각적 편집기는 워크플로 정의 파일을 생성하고 구성할 수 있는 완전한 사용자 인터페이스를 제공합니다. 시각적 편집기에는 워크플로의 기본 구성 요소를 보여주는 워크플로 다이어그램(1)과 구성 영역(2)이 포함되어 있습니다.
![\[워크플로 시각적 편집기\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/workflow-visual-editor.png)
또는 다음 이미지에 표시된 YAML 편집기를 사용할 수 있습니다. YAML 편집기를 사용하여 큰 코드 블록(예: 자습서)에 붙여넣거나 시각적 편집기를 통해 제공되지 않는 고급 속성을 추가합니다.
![\[워크플로 YAML 편집기\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/workflow-yaml-editor.png)
시각적 편집기에서 YAML 편집기로 전환하여 구성이 기본 YAML 코드에 미치는 영향을 확인할 수 있습니다.
## 워크플로 검색
워크플로 요약 페이지에서 **워크플로**를 볼 수 있으며, 동일한 프로젝트에 설정한 다른 워크플로도 볼 수 있습니다.
다음 이미지는 **워크플로** 요약 페이지를 보여줍니다. **BuildToProd**와 **UnitTests**라는 두 가지 워크플로로 채워집니다. 둘 다 몇 번 실행되었음을 알 수 있습니다. **최근 실행**을 선택하여 실행 기록을 빠르게 보거나 워크플로 이름을 선택하여 워크플로의 YAML 코드 및 기타 세부 정보를 볼 수 있습니다.
![\[워크플로 로그\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/workflow-list.png)
## 워크플로 실행 세부 정보 보기
**워크플로** 요약 페이지에서 실행을 선택하여 워크플로 실행의 세부 정보를 볼 수 있습니다.
다음 이미지는 소스 커밋 시 자동으로 시작된 **Run-cc11d**라는 워크플로 실행의 세부 정보를 보여줍니다. 워크플로 다이어그램은 작업이 실패했음을 나타냅니다(1). 로그(2)로 이동하여 자세한 로그 메시지를 보고 문제를 해결할 수 있습니다. 워크플로 실행에 대한 자세한 내용은 [워크플로 실행](workflows-working-runs.md) 섹션을 참조하세요.
![\[워크플로 로그\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/workflow-visual-logs.png)
## 다음 단계
워크플로 개념에 대한 자세한 내용은 [워크플로 개념](workflows-concepts.md) 섹션을 참조하세요.
첫 번째 워크플로를 생성하려면 [워크플로 시작하기](workflows-getting-started.md) 섹션을 참조하세요.
# 워크플로 개념
CodeCatalyst에서 워크플로를 사용하여 코드를 빌드, 테스트 또는 배포할 때 알아야 할 몇 가지 개념과 용어는 다음과 같습니다.
## 워크플로
*워크플로*는 지속적 통합 및 지속적 전송(CI/CD) 시스템의 일부로 코드를 빌드, 테스트 및 배포하는 방법을 설명하는 자동화된 절차입니다. 워크플로는 워크플로 실행 중에 수행할 일련의 단계 또는 *작업*을 정의합니다. 또한 워크플로는 워크플로를 시작하게 하는 이벤트 또는 *트리거*를 정의합니다. 워크플로를 설정하려면 CodeCatalyst 콘솔의 [시각적 또는 YAML 편집기](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors)를 사용하여 *워크플로 정의 파일*을 생성합니다.
**작은 정보**
프로젝트에서 워크플로를 사용하는 방법을 간략하게 알아보려면 [블루프린트가 있는 프로젝트를 생성](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template)합니다. 각 블루프린트는 검토, 실행 및 실험할 수 있는 기능 워크플로를 배포합니다.
## 워크플로 정의 파일
*워크플로 정의 파일*은 워크플로를 설명하는 YAML 파일입니다. 기본적으로 파일은 [소스 리포지토리](source-repositories.md)의 루트에 있는 `~/.codecatalyst/workflows/` 폴더에 저장됩니다. 파일은 확장자가 .yml 또는 .yaml일 수 있으며 확장자는 소문자여야 합니다.
워크플로 정의 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
## 작업
*작업*은 워크플로의 기본 구성 요소이며 워크플로 실행 중에 수행할 논리적 작업 단위 또는 태스크를 정의합니다. 일반적으로 워크플로에는 구성 방식에 따라 순차적으로 또는 병렬로 실행되는 여러 작업이 포함됩니다.
작업에 대한 자세한 내용은 [워크플로 작업 구성](workflows-actions.md) 섹션을 참조하세요.
## 작업 그룹
*작업 그룹*에는 하나 이상의 작업이 포함됩니다. 작업을 작업 그룹으로 그룹화하면 워크플로를 체계적으로 관리할 수 있고, 서로 다른 그룹 간의 종속성을 구성할 수도 있습니다.
작업 그룹에 대한 자세한 내용은 [작업을 작업 그룹으로 그룹화](workflows-group-actions.md) 섹션을 참조하세요.
## 아티팩트
*아티팩트*는 워크플로 작업의 출력이며 일반적으로 폴더 또는 파일 아카이브로 구성됩니다. 아티팩트를 사용하면 작업 간에 파일과 정보를 공유할 수 있기 때문에 아티팩트가 중요합니다.
아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
## 컴퓨팅
*컴퓨팅*은 워크플로 작업을 실행하기 위해 CodeCatalyst에서 관리 및 유지 관리하는 컴퓨팅 엔진(CPU, 메모리 및 운영 체제)을 의미합니다.
컴퓨팅에 대한 자세한 내용은 [컴퓨팅 및 런타임 이미지 구성](workflows-working-compute.md) 섹션을 참조하세요.
## 환경
[개발](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html) *환경*과 혼동해서는 안 되는 CodeCatalyst 환경은 CodeCatalyst [워크플로](workflow.md)가 연결되는 대상 AWS 계정 및 선택적 Amazon VPC를 정의합니다. 또한 환경은 워크플로가 대상 계정 내의 AWS 서비스 및 리소스에 액세스하는 데 필요한 [IAM 역할을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 정의합니다.
여러 환경을 설정하고 개발, 테스트, 스테이징 및 프로덕션과 같은 이름을 지정할 수 있습니다. 이러한 환경에 배포하면 배포에 대한 정보가 환경의 CodeCatalyst **배포 활동** 및 **배포 대상** 탭에 표시됩니다.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 섹션을 참조하세요.
## 게이트
*게이트*는 특정 조건이 충족되지 않으면 워크플로 실행이 진행되지 않도록 하는 데 사용할 수 있는 워크플로 구성 요소입니다. 게이트의 예시로는 사용자가 워크플로 실행을 계속하기 전에 CodeCatalyst 콘솔에서 승인을 제출해야 하는 **승인** 게이트를 들 수 있습니다.
워크플로의 일련의 작업 사이에 또는 첫 번째 작업(**소스** 다운로드 직후에 실행되는) 전에 게이트를 추가할 수 있습니다. 필요한 경우 마지막 작업 후 게이트를 추가할 수도 있습니다.
게이트에 대한 자세한 내용은 [워크플로 게이팅](workflows-gates.md) 섹션을 참조하세요.
## Reports
*보고서*에는 워크플로 실행 중에 발생하는 테스트에 대한 세부 정보가 포함되어 있습니다. 테스트 보고서, 코드 적용 범위 보고서, 소프트웨어 구성 분석 보고서 및 정적 분석 보고서와 같은 보고서를 생성할 수 있습니다. 보고서를 사용하여 워크플로 중 문제를 해결하는 데 도움을 받을 수 있습니다. 여러 워크플로의 보고서가 많은 경우 보고서를 사용하여 추세와 실패율을 확인하여 애플리케이션 및 배포 구성을 최적화할 수 있습니다.
보고서에 대한 자세한 내용은 [품질 보고서 유형](test-workflow-actions.md#test-reporting)의 내용을 참조하세요.
## 실행
*실행*은 워크플로의 단일 반복입니다. 실행하는 동안 CodeCatalyst는 워크플로 구성 파일에 정의된 작업을 수행하고 관련 로그, 아티팩트 및 변수를 출력합니다.
실행에 대한 자세한 내용은 [워크플로 실행](workflows-working-runs.md) 섹션을 참조하세요.
## 소스
*입력 소스*라고도 하는 *소스*는 [워크플로 작업](workflows-actions.md)이 작업을 수행하는 데 필요한 파일을 얻기 위해 연결되는 소스 리포지토리입니다. 예를 들어 워크플로 작업은 애플리케이션을 빌드하기 위해 애플리케이션 소스 파일을 얻기 위해 소스 리포지토리에 연결할 수 있습니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
## 변수
*변수*는 Amazon CodeCatalyst 워크플로에서 참조할 수 있는 정보를 포함하는 키-값 페어입니다. 변수의 값 부분은 워크플로가 실행될 때 실제 값으로 대체됩니다.
변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
## 워크플로 트리거
*워크플로 트리거* 또는 간단히 *트리거*를 사용하면 코드 푸시와 같은 특정 이벤트가 발생하면 워크플로 실행을 자동으로 시작할 수 있습니다. 트리거를 구성하여 소프트웨어 개발자가 CodeCatalyst 콘솔을 통해 워크플로 실행을 수동으로 시작하지 않아도 되도록 할 수 있습니다.
세 가지 유형의 트리거를 사용할 수 있습니다.
+ **푸시** - 코드 푸시 트리거는 커밋이 푸시될 때마다 워크플로 실행을 시작하도록 합니다.
+ **풀 요청** - 풀 요청 트리거는 풀 요청이 생성, 수정 또는 종료될 때마다 워크플로 실행을 시작하게 합니다.
+ **일정** - 일정 트리거는 정의한 일정에 따라 워크플로 실행이 시작되도록 합니다. 소프트웨어 개발자가 다음 날 아침에 작업할 수 있도록 최신 빌드를 준비할 수 있도록 일정 트리거를 사용하여 소프트웨어의 야간 빌드를 실행하는 것을 고려하세요.
푸시, 풀 요청 및 예약 트리거를 단독으로 사용하거나 동일한 워크플로에서 조합하여 사용할 수 있습니다.
트리거는 선택 사항입니다. 구성하지 않으면 워크플로를 수동으로만 시작할 수 있습니다.
트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
# 워크플로 시작하기
이 자습서에서는 첫 번째 워크플로를 생성하고 구성하는 방법을 알아봅니다.
**작은 정보**
미리 구성된 워크플로로 시작하시겠습니까? 작동하는 워크플로, 샘플 애플리케이션 및 기타 리소스를 사용하여 프로젝트를 설정하는 지침이 포함된 [블루프린트를 사용하여 프로젝트 생성](projects-create.md#projects-create-console-template) 섹션을 참조하세요.
**Topics**
+ [사전 조건](#get-started-create-workflow-prerequisites)
+ [1단계: 워크플로 생성 및 구성](#get-started-create-workflow-create)
+ [2단계: 커밋을 사용하여 워크플로 저장](#get-started-create-workflow-commit)
+ [3단계: 실행 결과 보기](#get-started-create-workflow-results)
+ [(선택 사항) 4단계: 정리](#get-started-create-workflow-cleanup)
## 사전 조건
시작하기 전:
+ CodeCatalyst **스페이스**가 필요합니다. 자세한 내용은 [스페이스 생성](spaces-create.md) 섹션을 참조하세요.
+ CodeCatalyst 스페이스에는 다음과 같은 빈 프로젝트가 필요합니다.
```
codecatalyst-project
```
자세한 내용은 [Amazon CodeCatalyst에서 빈 프로젝트 생성](projects-create.md#projects-create-empty) 섹션을 참조하세요.
+ 프로젝트에는 다음과 같은 CodeCatalyst **리포지토리**가 필요합니다.
```
codecatalyst-source-repository
```
자세한 내용은 [소스 리포지토리 생성](source-repositories-create.md) 섹션을 참조하세요.
**참고**
기존 프로젝트와 소스 리포지토리가 있는 경우 이를 사용할 수 있지만, 이 자습서 마지막에 새 프로젝트를 만들면 정리가 더 쉬워집니다.
## 1단계: 워크플로 생성 및 구성
이 단계에서는 소스 코드가 변경될 때 자동으로 빌드하고 테스트하는 워크플로를 만들고 구성합니다.
**워크플로 생성**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
워크플로 정의 파일은 CodeCatalyst 콘솔의 YAML 편집기에 나타납니다.
**워크플로 구성**
**시각적** 편집기 또는 **YAML** 편집기에서 워크플로를 구성할 수 있습니다. YAML 편집기로 시작한 다음 시각적 편집기로 전환해 보겠습니다.
1. **\$1 작업**을 선택하면 워크플로에 추가할 수 있는 워크플로 작업 목록을 볼 수 있습니다.
1. **빌드** 작업에서 **\$1**를 선택하여 작업의 YAML을 워크플로 정의 파일에 추가합니다. 이제 워크플로는 다음과 유사하게 보입니다.
```
Name: Workflow_fe47
SchemaVersion: "1.0"
# Optional - Set automatic triggers.
Triggers:
- Type: Push
Branches:
- main
# Required - Define action configurations.
Actions:
Build_f0:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource # This specifies that the action requires this workflow as a source
Outputs:
AutoDiscoverReports:
Enabled: true
# Use as prefix for the report files
ReportNamePrefix: rpt
Configuration:
Steps:
- Run: echo "Hello, World!"
- Run: echo "" >> report.xml
- Run: echo "" >> report.xml
- Run: echo "" >> report.xml
```
워크플로는 `WorkflowSource` 소스 리포지토리의 파일을 `Build_f0` 작업을 실행하는 컴퓨팅 머신에 복사하고, `Hello, World!`를 로그에 인쇄하고, 컴퓨팅 머신에서 테스트 보고서를 검색하고, 이를 CodeCatalyst 콘솔의 **보고서** 페이지에 출력합니다.
1. **시각적** 편집기에서 워크플로 정의 파일을 보려면 시각적을 선택합니다. 시각적 편집기의 필드를 사용하면 YAML 편집기에 표시된 YAML 속성을 구성할 수 있습니다.
## 2단계: 커밋을 사용하여 워크플로 저장
이 단계에서는 변경 사항을 저장합니다. 워크플로는 리포지토리에 `.yaml` 파일로 저장되므로 커밋과 함께 변경 사항을 저장합니다.
**워크플로 변경 사항 커밋**
1. (선택 사항) 워크플로의 YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택합니다.
1. **워크플로 파일 이름**에 **my-first-workflow**과 같은 워크플로 구성 파일의 이름을 입력합니다.
1. **커밋 메시지**에 **create my-first-workflow.yaml**과 같은 커밋을 식별하는 메시지를 입력합니다.
1. **리포지토리**에서 (`codecatalyst-repository`) 워크플로를 저장할 리포지토리를 선택합니다.
1. **브랜치 이름**에서 (`main`) 워크플로를 저장할 브랜치를 선택합니다.
1. **커밋**을 선택합니다.
새 워크플로가 워크플로 목록에 나타납니다. 표시하는 데 몇 초 정도 걸릴 수 있습니다.
워크플로는 커밋과 함께 저장되고 워크플로에 코드 푸시 트리거가 구성되어 있으므로 워크플로를 저장하면 워크플로 실행이 자동으로 시작됩니다.
## 3단계: 실행 결과 보기
이 단계에서는 커밋에서 시작된 실행으로 이동하여 결과를 봅니다.
**실행 결과 보기**
1. 워크플로의 이름을 선택합니다. 예를 들어 `Workflow_fe47`입니다.
소스 리포지토리의 레이블(**WorkflowSource**)과 빌드 작업(예: **Build\$1f0**)을 보여주는 워크플로 다이어그램입니다.
1. 워크플로 실행 다이어그램에서 빌드 작업(예: **Build\$1f0**)을 선택합니다.
1. **로그,** **보고서**, **구성** 및 **변수** 탭의 내용을 검토합니다. 이 탭은 빌드 작업의 결과를 보여줍니다.
자세한 내용은 [빌드 작업 결과 보기](build-view-results.md) 섹션을 참조하세요.
## (선택 사항) 4단계: 정리
이 단계에서는 자습서에서 생성한 리소스를 정리합니다.
**리소스 삭제**
+ 이 자습서를 위해 새 프로젝트를 만들었다면 삭제합니다. 지침은 [프로젝트 삭제](projects-delete.md) 섹션을 참조하세요. 프로젝트를 삭제하면 소스 리포지토리와 워크플로도 삭제됩니다.
# 워크플로로 빌드하기
[CodeCatalyst 워크플로](workflow.md)를 사용하여 애플리케이션 및 기타 리소스를 구축할 수 있습니다.
**Topics**
+ [애플리케이션을 빌드하려면 어떻게 해야 하나요?](#build-how-to)
+ [빌드 작업의 이점](#build-benefits)
+ [빌드 작업의 대안](#build-alternatives)
+ [빌드 작업 추가](build-add-action.md)
+ [빌드 작업 결과 보기](build-view-results.md)
+ [자습서: Amazon S3에 아티팩트 업로드](build-deploy.md)
+ [빌드 및 테스트 작업 YAML](build-action-ref.md)
## 애플리케이션을 빌드하려면 어떻게 해야 하나요?
CodeCatalyst에서 애플리케이션 또는 리소스를 빌드하려면 먼저 워크플로를 생성한 다음 그 안에 빌드 작업을 지정합니다.
*빌드 작업*은 소스 코드를 컴파일하고 단위 테스트를 실행하며 배포할 준비가 완료된 아티팩트를 생성하는 워크플로 기본 요소입니다.
CodeCatalyst 콘솔의 시각적 편집기 또는 YAML 편집기를 사용하여 워크플로에 빌드 작업을 추가합니다.
애플리케이션 또는 리소스를 빌드하는 상위 단계는 다음과 같습니다.
**애플리케이션을 빌드하려면(고급 작업)**
1. CodeCatalyst에서 빌드하려는 애플리케이션의 **소스 코드를 추가**합니다. 자세한 내용은 [CodeCatalyst에서 프로젝트의 리포지토리에 소스 코드 저장](source-repositories.md) 단원을 참조하십시오.
1. CodeCatalyst에서 **워크플로를 생성**합니다. 워크플로에서는 애플리케이션을 빌드, 테스트 및 배포하는 방법을 정의합니다. 자세한 내용은 [워크플로 시작하기](workflows-getting-started.md) 단원을 참조하십시오.
1. (선택 사항) 워크플로에 워크플로를 자동으로 시작하게 하는 이벤트를 나타내는 **트리거를 추가**합니다. 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 섹션을 참조하세요.
1. 워크플로에서 애플리케이션 또는 리소스 소스 코드를 컴파일하고 패키징하는 **빌드 작업**을 추가합니다. 이러한 용도로 테스트를 사용하거나 작업을 배포하지 않으려는 경우 필요에 따라 빌드 작업에서 단위 테스트를 실행하고, 보고서를 생성하고, 애플리케이션을 배포할 수도 있습니다. 테스트 및 배포 작업에 대한 자세한 내용은 [빌드 작업 추가](build-add-action.md) 섹션을 참조하세요.
1. (선택 사항) 워크플로에서 **테스트 작업**과 **배포 작업을 추가**하여 애플리케이션 또는 리소스를 테스트하고 배포합니다. 사전 구성된 여러 작업 중에서 선택하여 Amazon ECS와 같은 다양한 대상에 애플리케이션을 배포할 수 있습니다. 자세한 내용은 [워크플로를 사용한 테스트워크플로를 사용한 테스트](test-workflow-actions.md) 및 [워크플로를 사용하여 배포워크플로를 사용하여 배포](deploy.md) 섹션을 참조하세요.
1. 트리거를 통해 **워크플로를 수동으로 또는 자동으로 시작**합니다. 워크플로는 빌드, 테스트 및 배포 작업을 순서대로 실행하여 애플리케이션 및 리소스를 빌드, 테스트 및 대상에 배포합니다. 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
## 빌드 작업의 이점
워크플로 내에서 빌드 작업을 사용하면 다음과 같은 이점이 있습니다.
+ **완전 관리형** - 빌드 작업에서는 빌드 서버를 직접 설정하고, 패치 및 업데이트를 적용하고, 관리할 필요가 없습니다.
+ **온디맨드** – 빌드 작업은 빌드 요구 사항을 충족하기 위해 요구에 따라 규모가 조정됩니다. 사용한 빌드 시간만큼만 요금을 지불합니다. 자세한 내용은 [컴퓨팅 및 런타임 이미지 구성](workflows-working-compute.md) 섹션을 참조하세요.
+ **기본 제공** - CodeCatalyst에는 빌드 작업을 포함한 모든 워크플로 작업을 실행하는 데 사용되는 사전 패키징된 런타임 환경 Docker 이미지가 포함되어 있습니다. 이러한 이미지는 AWS CLI 및 Node.js와 같은 애플리케이션을 빌드하는 데 유용한 도구로 미리 구성되어 있습니다. 퍼블릭 또는 프라이빗 레지스트리에서 제공하는 빌드 이미지를 사용하도록 CodeCatalyst를 구성할 수 있습니다. 자세한 내용은 [런타임 환경 이미지 지정](build-images.md) 섹션을 참조하세요.
## 빌드 작업의 대안
빌드 작업을 사용하여 애플리케이션을 배포하는 경우 CodeCatalyst *배포 작업*을 대신 사용하는 것이 좋습니다. 배포 작업은 빌드 작업을 사용하는 경우 수동으로 작성해야 하는 백그라운드 구성을 수행합니다. 사용 가능한 배포 작업에 대한 자세한 내용은 [배포 작업 목록](deploy.md#deploy-concepts-action-supported) 섹션을 참조하세요.
를 사용하여 애플리케이션을 빌드 AWS CodeBuild 할 수도 있습니다. 자세한 내용은 [CodeBuild란 무엇입니까?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)를 참조하세요.
# 빌드 작업 추가
다음 절차에 따라 CodeCatalyst 워크플로에 빌드 작업을 추가합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 빌드 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **빌드**를 선택합니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 빌드 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **빌드**를 선택합니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 [빌드 및 테스트 작업 YAML](build-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
## 작업 정의
빌드 작업은 워크플로 정의 파일 내의 YAML 속성 집합으로 정의됩니다. 이러한 속성에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요.
# 빌드 작업 결과 보기
다음 지침을 사용하여 생성된 로그, 보고서 및 변수를 포함한 빌드 작업의 결과를 확인합니다.
**빌드 작업의 결과를 보려면**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 워크플로 다이어그램에서 빌드 작업의 이름, 예를 들어 **Build**를 선택합니다.
1. 빌드 실행에 대한 로그를 보려면 **로그**를 선택합니다. 다양한 빌드 단계의 로그가 표시됩니다. 필요에 따라 로그를 확장하거나 축소할 수 있습니다.
1. 빌드 작업에서 생성된 테스트 보고서를 보려면 **보고서**를 선택하거나 탐색 창에서 **보고서**를 선택합니다. 자세한 내용은 [품질 보고서 유형](test-workflow-actions.md#test-reporting) 단원을 참조하십시오.
1. 빌드 작업에 사용되는 구성을 보려면 **구성**을 선택합니다. 자세한 내용은 [빌드 작업 추가](build-add-action.md) 단원을 참조하십시오.
1. 빌드 작업에 사용되는 변수를 보려면 **변수**를 선택합니다. 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 단원을 참조하십시오.
# 자습서: Amazon S3에 아티팩트 업로드
이 자습서에서는 몇 가지 [빌드 작업이](workflows-concepts.md#workflows-concepts-actions) 포함된 Amazon CodeCatalyst [워크플로](workflows-concepts.md#workflows-concepts-workflows)를 사용하여 Amazon S3 버킷에 아티팩트를 업로드하는 방법을 알아봅니다. 이러한 작업은 워크플로가 시작될 때 직렬로 실행됩니다. 첫 번째 빌드 작업은 두 개의 파일 `Hello.txt` 및 `Goodbye.txt`를 생성하고 이를 빌드 아티팩트에 번들링합니다. 두 번째 빌드 작업은 아티팩트를 Amazon S3에 업로드합니다. 커밋을 소스 리포지토리로 푸시할 때마다 워크플로가 실행되도록 구성합니다.
**Topics**
+ [사전 조건](#build-deploy-tut-prereqs)
+ [1단계: AWS 역할 생성](#build-deploy-tut-role)
+ [2단계: Amazon S3 버킷 생성](#build-deploy-tut-artifact)
+ [3단계: 소스 리포지토리 생성](#deploy-tut-lambda-cfn-source)
+ [4단계: 워크플로 생성](#build-deploy-tut-workflow.title)
+ [5단계: 실험 결과 확인](#build-deploy.s3.verify)
+ [정리](#deploy-tut-lambda-cfn-clean-up)
## 사전 조건
시작하려면 다음이 필요합니다.
+ 연결된 AWS 계정이 있는 CodeCatalyst **스페이스**가 필요합니다. 자세한 내용은 [스페이스 생성](spaces-create.md) 섹션을 참조하세요.
+ 스페이스에는 다음과 같은 빈 프로젝트가 필요합니다.
```
codecatalyst-artifact-project
```
**처음부터 시작** 옵션을 사용하여 이 프로젝트를 생성합니다.
자세한 내용은 [Amazon CodeCatalyst에서 빈 프로젝트 생성](projects-create.md#projects-create-empty) 섹션을 참조하세요.
+ 프로젝트에는 다음과 같은 CodeCatalyst **환경**이 필요합니다.
```
codecatalyst-artifact-environment
```
다음과 같이 이 환경을 구성합니다.
+ **개발** 등 유형을 선택합니다.
+ AWS 계정에 연결합니다.
+ **기본 IAM 역할**의 경우 아무 역할이나 선택합니다. 나중에 다른 역할을 지정합니다.
자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 단원을 참조하십시오.
## 1단계: AWS 역할 생성
이 단계에서는 나중에 워크플로의 빌드 작업에 할당할 AWS IAM 역할을 생성합니다. 이 역할은 CodeCatalyst 빌드 작업에 AWS 계정에 액세스하고 아티팩트가 저장될 Amazon S3에 쓸 수 있는 권한을 부여합니다. 이 역할을 **빌드 역할**이라고 합니다.
**참고**
다른 자습서를 위해 생성한 빌드 역할이 이미 있는 경우 이 자습서에도 사용할 수 있습니다. 다음 절차에 표시된 권한 및 신뢰 정책이 있는지 확인하세요.
IAM 역할에 대한 자세한 내용은 *AWS AWS Identity and Access Management 사용 설명서*의 [IAM 역할을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 참조하세요.
**빌드 역할을 생성하려면**
1. 역할에 대한 정책을 다음과 같이 생성합니다.
1. 에 로그인합니다 AWS.
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **Policies**를 선택합니다.
1. **정책 생성**을 선택합니다.
1. **JSON** 탭을 선택합니다.
1. 기존 코드를 삭제합니다.
1. 다음 코드를 붙여넣습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListBucket"
],
"Resource": "*"
}
]
}
```
------
**참고**
역할을 처음 사용하여 워크플로 작업을 실행할 때 리소스 정책 문에서 와일드카드를 사용한 다음, 사용 가능한 리소스 이름으로 정책 범위를 좁힙니다.
```
"Resource": "*"
```
1. **다음: 태그**를 선택합니다.
1. **다음: 검토**를 선택합니다.
1. **이름**에 다음과 같이 입력합니다.
```
codecatalyst-s3-build-policy
```
1. **정책 생성**을 선택합니다.
이제 권한 정책을 생성했습니다.
1. 다음과 같이 빌드 역할을 생성합니다.
1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. **사용자 지정 신뢰 정책**을 선택합니다.
1. 기존 사용자 지정 신뢰 정책을 삭제합니다.
1. 다음 사용자 지정 신뢰 정책을 추가합니다.
1. **다음**을 선택합니다.
1. **권한 정책**에서 `codecatalyst-s3-build-policy`를 검색하고 해당 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **역할 이름**에 다음과 같이 입력합니다.
```
codecatalyst-s3-build-role
```
1. **역할 설명**에 다음과 같이 입력합니다.
```
CodeCatalyst build role
```
1. **역할 생성**을 선택합니다.
이제 신뢰 정책 및 권한 정책으로 빌드 역할을 생성했습니다.
## 2단계: Amazon S3 버킷 생성
이 단계에서는 `Hello.txt` 및 `Goodbye.txt` 아티팩트가 업로드되는 Amazon S3 버킷을 생성합니다.
**Amazon S3 버킷을 생성하려면**
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 기본 창에서 **버킷 생성**을 선택합니다.
1. **버킷 이름**에 다음과 같이 입력합니다.
```
codecatalyst-artifact-bucket
```
1. **AWS 리전**에서 리전을 선택합니다. 이 자습서에서는 **미국 서부(오리건) us-west-2**를 선택했다고 가정합니다. Amazon S3에서 지원되는 리전에 대한 자세한 내용은 *AWS 일반 참조*의 [Amazon Simple Storage Service 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/s3.html)을 참조하세요.
1. 페이지 맨 아래에 있는 **버킷 생성** 버튼을 선택합니다.
1. 방금 생성한 버킷의 이름을 복사합니다. 예시:
```
codecatalyst-artifact-bucket
```
이제 미국 서부(오리건) us-west-2 리전에 **codecatalyst-artifact-bucket** 버킷을 생성했습니다.
## 3단계: 소스 리포지토리 생성
이 단계에서는 CodeCatalyst에 소스 리포지토리를 생성합니다. 이 리포지토리는 자습서의 워크플로 정의 파일을 저장하는 데 사용됩니다.
소스 리포지토리에 대한 자세한 정보는 [소스 리포지토리 생성](source-repositories-create.md) 섹션을 참조하세요.
**소스 리포지토리를 생성하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-artifact-project` 프로젝트로 이동합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. **리포지토리 추가**를 선택하고 **리포지토리 생성**을 선택합니다.
1. **리포지토리 이름**에 다음과 같이 입력합니다.
```
codecatalyst-artifact-source-repository
```
1. **생성(Create)**을 선택합니다.
이제 `codecatalyst-artifact-source-repository` 리포지토리를 생성했습니다.
## 4단계: 워크플로 생성
이 단계에서는 순차적으로 실행되는 다음 구성 요소로 구성된 워크플로를 생성합니다.
+ 트리거 - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 섹션을 참조하세요.
+ 빌드 작업 `GenerateFiles` - 트리거 시 `GenerateFiles` 작업은 두 개의 파일 `Hello.txt` 및 `Goodbye.txt`를 생성하고 출력 아티팩트 `codecatalystArtifact`에 패키징합니다.
+ 다른 빌드 작업 `Upload` - `GenerateFiles` 작업이 완료되면 `Upload` 작업이 AWS CLI 명령 `aws s3 sync`를 실행하여 소스 리포지토리의 `codecatalystArtifact` 및 소스 리포지토리에 있는 파일을 Amazon S3 버킷에 업로드합니다. 는 CodeCatalyst 컴퓨팅 플랫폼에 사전 설치 및 구성되어 AWS CLI 제공되므로 설치하거나 구성할 필요가 없습니다.
CodeCatalyst 컴퓨팅 플랫폼의 사전 패키징된 소프트웨어에 대한 자세한 내용은 [런타임 환경 이미지 지정](build-images.md) 섹션을 참조하세요. AWS CLI명령에 대한 자세한 내용은 `aws s3 sync` 명령 참조의 [동기화](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html)를 *AWS CLI 참조*하세요.
이러한 빌드 작업에 대한 자세한 내용은 [워크플로로 빌드하기](build-workflow-actions.md) 섹션을 참조하세요.
**워크플로 생성**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
1. YAML 샘플 코드를 삭제합니다.
1. 다음 YAML 코드를 추가합니다.
**참고**
다음 YAML 코드에서 원하는 경우 `Connections:` 섹션을 생략할 수 있습니다. 이 섹션을 생략하는 경우 환경의 **기본 IAM 역할** 필드에 지정된 역할에 [1단계: AWS 역할 생성](#build-deploy-tut-role)에 설명된 권한 및 신뢰 정책이 포함되어 있는지 확인해야 합니다. 기본 IAM 역할이 있는 환경 설정에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
```
Name: codecatalyst-artifact-workflow
SchemaVersion: 1.0
Triggers:
- Type: Push
Branches:
- main
Actions:
GenerateFiles:
Identifier: aws/build@v1
Configuration:
Steps:
# Create the output files.
- Run: echo "Hello, World!" > "Hello.txt"
- Run: echo "Goodbye!" > "Goodbye.txt"
Outputs:
Artifacts:
- Name: codecatalystArtifact
Files:
- "**/*"
Upload:
Identifier: aws/build@v1
DependsOn:
- GenerateFiles
Environment:
Name: codecatalyst-artifact-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-s3-build-role
Inputs:
Artifacts:
- codecatalystArtifact
Configuration:
Steps:
# Upload the output artifact to the S3 bucket.
- Run: aws s3 sync . s3://codecatalyst-artifact-bucket
```
위의 코드를 다음과 같이 변경합니다.
+ *codecatalyst-artifact-environment*를 [사전 조건](#build-deploy-tut-prereqs)에서 생성한 환경 이름으로 변경합니다.
+ *codecatalyst-account-connection*을 [사전 조건](#build-deploy-tut-prereqs)에서 생성한 계정 연결 이름으로 변경합니다.
+ *codecatalyst-s3-build-role*을 [1단계: AWS 역할 생성](#build-deploy-tut-role)에서 생성한 빌드 역할 이름으로 변경합니다.
+ *codecatalyst-artifact-bucket*을 [2단계: Amazon S3 버킷 생성](#build-deploy-tut-artifact)에서 생성한 Amazon S3 이름으로 변경합니다.
이러한 파일의 속성에 대한 자세한 내용은 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택합니다.
1. **워크플로 커밋** 대화 상자에서 다음을 입력합니다.
1. **워크플로 파일 이름**은 기본값인 `codecatalyst-artifact-workflow`를 그대로 사용합니다.
1. **커밋 메시지**에 다음을 입력합니다.
```
add initial workflow file
```
1. **리포지토리**에서 **codecatalyst-artifact-source-repository**를 선택합니다.
1. **브랜치 이름**에서 **기본**을 선택합니다.
1. **커밋**을 선택합니다.
이제 워크플로를 생성했습니다. 워크플로 상단에 정의된 트리거로 인해 워크플로 실행이 자동으로 시작됩니다. 특히 `codecatalyst-artifact-workflow.yaml` 파일을 소스 리포지토리에 커밋(및 푸시)할 때 트리거가 워크플로 실행을 시작했습니다.
**진행 중인 워크플로 실행을 보려면**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 방금 생성한 `codecatalyst-artifact-workflow` 워크플로를 선택합니다.
1. **GenerateFiles**를 선택하여 첫 번째 빌드 작업 진행 상황을 확인합니다.
1. **업로드**를 선택하여 두 번째 빌드 작업 진행 상황을 확인합니다.
1. **업로드** 작업이 완료되면 다음을 수행합니다.
+ 워크플로 실행에 성공한 경우 다음 절차로 이동합니다.
+ 워크플로 실행에 실패한 경우 **로그**를 선택하여 문제를 해결합니다.
## 5단계: 실험 결과 확인
워크플로가 실행된 후 Amazon S3 서비스로 이동하여 *codecatalyst-artifact-bucket* 버킷을 확인합니다. 이제 다음 파일과 폴더가 포함되어야 합니다.
```
.
|— .aws/
|— .git/
|Goodbye.txt
|Hello.txt
|REAME.md
```
`Goodbye.txt` 및 `Hello.txt` 파일은 `codecatalystArtifact` 아티팩트의 일부이므로 업로드되었습니다. `.aws/`, `.git/` 및 `README.md` 파일은 소스 리포지토리에 있었기 때문에 업로드되었습니다.
## 정리
이러한 서비스에 대한 요금이 부과되지 않도록 CodeCatalyst 및 AWS 에서 정리합니다.
**CodeCatalyst에서 정리하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-artifact-source-repository` 소스 리포지토리를 삭제합니다.
1. `codecatalyst-artifact-workflow` 워크플로를 선택합니다.
**에서 정리하려면 AWS**
1. 다음과 같이 Amazon S3에서 정리합니다.
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. `codecatalyst-artifact-bucket` 버킷에서 파일을 삭제합니다.
1. `codecatalyst-artifact-bucket` 버킷을 삭제합니다.
1. 다음과 같이 IAM에서 정리합니다.
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. `codecatalyst-s3-build-policy`를 삭제합니다.
1. `codecatalyst-s3-build-role`를 삭제합니다.
# 빌드 및 테스트 작업 YAML
다음은 빌드 및 테스트 작업의 YAML 정의입니다. YAML 속성이 매우 유사하기 때문에 두 작업에 대한 참조가 하나 있습니다.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
다음 코드에서 YAML 속성을 선택하면 설명이 표시됩니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
action-name:
Identifier: aws/build@v1 | aws/managed-test@v1
DependsOn:
- dependent-action-name-1
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
Timeout: timeout-minutes
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Caching:
FileCaching:
key-name-1:
Path: file1.txt
RestoreKeys:
- restore-key-1
Inputs:
Sources:
- source-name-1
- source-name-2
Artifacts:
- artifact-name
Variables:
- Name: variable-name-1
Value: variable-value-1
- Name: variable-name-2
Value: variable-value-2
Outputs:
Artifacts:
- Name: output-artifact-1
Files:
- build-output/artifact-1.jar
- "build-output/build*"
- Name: output-artifact-2
Files:
- build-output/artifact-2.1.jar
- build-output/artifact-2.2.jar
Variables:
- variable-name-1
- variable-name-2
AutoDiscoverReports:
Enabled: true | false
ReportNamePrefix: AutoDiscovered
IncludePaths:
- "**/*"
ExcludePaths:
- node_modules/cdk/junit.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
StaticAnalysisBug:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
StaticAnalysisSecurity:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
StaticAnalysisQuality:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
StaticAnalysisFinding:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
Reports:
report-name-1:
Format: format
IncludePaths:
- "*.xml"
ExcludePaths:
- report2.xml
- report3.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
StaticAnalysisBug:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
StaticAnalysisSecurity:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
StaticAnalysisQuality:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
StaticAnalysisFinding:
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL
Number: whole-number
Configuration:
Container:
Registry: registry
Image: image
Steps:
- Run: "step 1"
- Run: "step 2"
Packages:
NpmConfiguration:
PackageRegistries:
- PackagesRepository: package-repository
Scopes:
- "@scope"
ExportAuthorizationToken: true | false
```
## action-name
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
해당 UI: 구성 탭/**작업 이름**
## Identifier
(*action-name*/**Identifier**)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
빌드 작업에 `aws/build@v1`를 사용합니다.
테스트 작업에 `aws/managed-test@v1`를 사용합니다.
해당 UI: 워크플로 다이어그램/Action-name/*aws/build@v1\$1aws/managed-test@v1* 레이블
## DependsOn
(*action-name */**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*action-name*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Type
(*action-name*/Compute/**Type**)
([Compute](#build.computename) 포함 시 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 구성 탭/**컴퓨팅 유형**
## Fleet
(*action-name*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/**컴퓨팅 플릿**
## Timeout
(*action-name*/**Timeout**)
(선택 사항)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Environment
(*action-name*/**Environment**)
(선택 사항)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*action-name*/Environment/**Name**)
(선택 사항)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*action-name*/Environment/**Connections**)
(선택 사항)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
## Name
(*action-name*/Environment/Connections/**Name**)
([Connections](#build.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
해당 UI: 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
## Role
(*action-name*/Environment/Connections/**Role**)
([Connections](#build.environment.connections) 포함 시 필수)
Amazon S3 및 Amazon ECR과 같은 AWS 서비스에 액세스하고 운영하기 위해 이 작업이 사용하는 IAM 역할의 이름을 지정합니다. 이 역할이 스페이스의 AWS 계정 연결에 추가되었는지 확인합니다. 계정 연결에 IAM 역할을 추가하려면 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 다음 정책이 있는지 확인합니다.
**참고**
이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
**주의**
빌드 및 테스트 작업에 필요한 권한으로 권한을 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
해당 UI: 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
## Caching
(*action-name*/**Caching**)
(선택 사항)
캐시를 지정하여 디스크 파일을 저장하고 후속 워크플로 실행 시 해당 캐시에서 복원할 수 있는 섹션입니다.
파일 캐싱에 대한 자세한 정보는 [워크플로 실행 간 파일 캐싱](workflows-caching.md)을 참조하세요.
해당 UI: 구성 탭/**파일 캐싱 - 선택 사항**
## FileCaching
(*action-name*/Caching/**FileCaching**)
(선택 사항)
캐시 시퀀스의 구성을 지정하는 섹션입니다.
해당 UI: 구성 탭/파일 캐싱 - 선택적/**캐시 추가**
## key-name-1
(*action-name*/Caching/FileCaching/***key-name-1***)
(선택 사항)
기본 캐시 속성 이름의 이름을 지정합니다. 캐시 속성 이름은 워크플로 내에서 고유해야 합니다. 각 작업은 `FileCaching`에서 최대 5개의 항목을 가질 수 있습니다.
해당 UI: 구성 탭/파일 캐싱 - 선택 사항/캐시 추가/**키**
## Path
(*action-name*/Caching/FileCaching/*key-name-1*/**Path**)
(선택 사항)
캐시의 관련 경로를 지정합니다.
해당 UI: 구성 탭/파일 캐싱 - 선택 사항/캐시 추가/**경로**
## RestoreKeys
(*action-name*/Caching/FileCaching/*key-name-1*/**RestoreKeys**)
(선택 사항)
기본 캐시 속성을 찾을 수 없을 때 대체로 사용할 복원 키를 지정합니다. 복원 키 이름은 워크플로 내에서 고유해야 합니다. 각 캐시는 `RestoreKeys`에서 최대 5개의 항목을 가질 수 있습니다.
해당 UI: 구성 탭/파일 캐싱 - 선택 사항/캐시 추가/**복원 키 - 선택 사항**
## Inputs
(*action-name*/**Inputs**)
(선택 사항)
이 `Inputs` 섹션에서는 워크플로 실행 중에 작업에 필요한 데이터를 정의합니다.
**참고**
빌드 작업 또는 테스트 작업당 최대 4개의 입력(소스 1개 및 아티팩트 3개)이 허용됩니다. 변수는 이 합계에 포함되지 않습니다.
서로 다른 입력(소스 및 아티팩트)에 있는 파일을 참조해야 하는 경우 소스 입력은 기본 입력이고 아티팩트는 보조 입력입니다. 보조 입력의 파일에 대한 참조는 특수 접두사를 사용하여 기본 입력에서 파일을 구분합니다. 자세한 내용은 [예시: 여러 아티팩트에서 파일 참조](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)을 참조하세요.
해당 UI: **입력** 탭
## Sources
(*action-name*/Inputs/**Sources**)
(선택 사항)
작업에 필요한 소스 리포지토리를 나타내는 레이블을 지정합니다. 현재 지원되는 유일한 레이블은 워크플로 정의 파일이 저장되는 소스 리포지토리를 나타내는 `WorkflowSource`입니다.
소스를 생략하는 경우 `action-name/Inputs/Artifacts` 아래에 하나 이상의 입력 아티팩트를 지정해야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: *없음*
## Artifacts - input
(*action-name*/Inputs/**Artifacts**)
(선택 사항)
이 작업에 대한 입력으로 제공하려는 이전 작업의 아티팩트를 지정합니다. 이러한 아티팩트는 이전 작업에서 출력 아티팩트로 이미 정의되어 있어야 합니다.
입력 아티팩트를 지정하지 않으면 `action-name/Inputs/Sources` 아래에 소스 리포지토리를 하나 이상 지정해야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
**아티팩트 - 선택적** 드롭다운 목록을 사용할 수 없거나(시각적 편집기) YAML(YAML 편집기)을 검증할 때 오류가 발생하는 경우 작업이 하나의 입력만 지원하기 때문일 수 있습니다. 이 경우 소스 입력을 제거해 보세요.
해당 UI: 입력 탭/**아티팩트 - 선택 사항**
## Variables - input
(*action-name*/Inputs/**Variables**)
(선택 사항)
작업에 사용할 수 있도록 하려는 입력 변수를 정의하는 이름/값 페어의 시퀀스를 지정합니다. 변수 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 변수 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**변수 - 선택 사항**
## Outputs
(*action-name*/**Outputs**)
(선택 사항)
워크플로 실행 중에 작업에 의해 출력되는 데이터를 정의합니다.
해당 UI: **출력** 탭
## Artifacts - output
(*action-name*/Outputs/**Artifacts**)
(선택 사항)
작업에서 생성된 아티팩트의 이름을 지정합니다. 아티팩트 이름은 워크플로 내에서 고유해야 하며 영숫자 문자(a-z, A-Z, 0-9) 및 밑줄(\$1)로 제한됩니다. 공백, 하이픈(-) 및 특수 문자는 허용되지 않습니다. 출력 아티팩트 이름에서 공백, 하이픈 및 기타 특수 문자를 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/**아티팩트**
## Name
(*action-name*/Outputs/Artifacts/**Name**)
([Artifacts - output](#build.outputs.artifacts) 포함 시 필수)
작업에서 생성된 아티팩트의 이름을 지정합니다. 아티팩트 이름은 워크플로 내에서 고유해야 하며 영숫자 문자(a-z, A-Z, 0-9) 및 밑줄(\$1)로 제한됩니다. 공백, 하이픈(-) 및 특수 문자는 허용되지 않습니다. 출력 아티팩트 이름에서 공백, 하이픈 및 기타 특수 문자를 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/아티팩트/새 출력/**빌드 아티팩트 이름**
## Files
(*action-name*/Outputs/Artifacts/**Files**)
([Artifacts - output](#build.outputs.artifacts) 포함 시 필수)
CodeCatalyst가 작업으로 출력되는 아티팩트에 포함하는 파일을 지정합니다. 이러한 파일은 실행 시 워크플로 작업에 의해 생성되며 소스 리포지토리에서도 사용할 수 있습니다. 파일 경로는 소스 리포지토리 또는 이전 작업의 아티팩트에 상주할 수 있으며 소스 리포지토리 또는 아티팩트 루트와 관련이 있습니다. glob 패턴을 사용하여 경로를 지정할 수 있습니다. 예시:
+ 빌드 위치 또는 소스 리포지토리 위치의 루트에 있는 단일 파일을 지정하려면 `my-file.jar`를 사용합니다..
+ 하위 디렉터리에 단일 파일을 지정하려면 `directory/my-file.jar` 또는 `directory/subdirectory/my-file.jar`를 사용합니다.
+ 모든 파일을 지정하려면 `"**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리에 있는 모든 파일 및 디렉터리를 지정하려면 `"directory/**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리의 모든 파일을 지정하되 해당 하위 디렉터리는 지정하지 않으려면 `"directory/*"`를 사용합니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
파일 경로에 접두사를 추가하여 찾을 아티팩트 또는 소스를 나타내야 할 수 있습니다. 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
해당 UI: 출력 탭/아티팩트/아티팩트 추가/**빌드에서 생성된 파일**
## Variables - output
(*action-name*/Outputs/**Variables**)
(선택 사항)
후속 작업에서 사용할 수 있도록 작업을 내보낼 변수를 지정합니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 출력 탭/변수/**변수 추가**
## variable-name-1
(*action-name*/Outputs/Variables/*variable-name-1*)
(선택 사항)
작업을 내보낼 변수의 이름을 지정합니다. 이 변수는 동일한 작업의 `Inputs` 또는 `Steps` 섹션에 이미 정의되어 있어야 합니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 출력 탭/변수/변수 추가/**이름**
## AutoDiscoverReports
(*action-name*/Outputs/**AutoDiscoverReports**)
(선택 사항)
자동 검색 기능의 구성을 정의합니다.
자동 검색을 활성화하면 CodeCatalyst는 작업에 전달된 모든 `Inputs`와 작업 자체에서 생성된 모든 파일을 검색하여 테스트, 코드 적용 범위 및 소프트웨어 구성 분석(SCA) 보고서를 찾습니다. 발견된 각 보고서에 대해 CodeCatalyst는 이를 CodeCatalyst 보고서로 변환합니다. *CodeCatalyst 보고서*는 CodeCatalyst 서비스에 완전히 통합되고 CodeCatalyst 콘솔을 통해 보고 조작할 수 있는 보고서입니다.
**참고**
기본적으로 자동 검색 기능은 모든 파일을 검사합니다. [IncludePaths](#build.reports.includepaths) 또는 [ExcludePaths](#build.reports.excludepaths) 속성을 사용하여 검사할 파일을 제한할 수 있습니다.
해당 UI: 출력 탭/보고서/**자동 검색 보고서**
## Enabled
(*action-name*/Outputs/AutoDiscoverReports/**Enabled**)
(선택 사항)
자동 검색 기능을 활성화하거나 비활성화합니다.
유효한 값은 `true` 또는 `false`입니다.
`Enabled` 생략 시 기본값은 `true`입니다.
해당 UI: 출력 탭/보고서/**자동 검색 보고서**
## ReportNamePrefix
(*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**)
([AutoDiscoverReports](#build.outputs.autodiscover) 포함 및 활성화 시 필수)
연결된 CodeCatalyst 보고서의 이름을 지정하기 위해 CodeCatalyst가 찾는 모든 보고서에 우선하는 접두사를 지정합니다. 예를 들어 접두사를 `AutoDiscovered`로 지정하고 CodeCatalyst가 두 개의 테스트 보고서, `TestSuiteOne.xml` 및 `TestSuiteTwo.xml`를 자동으로 검색하면 연결된 CodeCatalyst 보고서의 이름이 `AutoDiscoveredTestSuiteOne` 및 `AutoDiscoveredTestSuiteTwo`로 지정됩니다.
해당 UI: 출력 탭/보고서/**접두사 이름**
## IncludePaths
(*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**)
([AutoDiscoverReports](#build.outputs.autodiscover) 포함 및 활성화 시 또는 [Reports](#test.configuration.reports) 포함 시 필수)
원시 보고서를 검색할 때 CodeCatalyst에 포함되는 파일 및 파일 경로를 지정합니다. 예를 들어 `"/test/report/*"` 지정 시 CodeCatalyst는 작업에서 `/test/report/*` 디렉터리를 찾는 데 사용되는 전체 [빌드 이미지](build-images.md)를 검색합니다. 해당 디렉터리를 찾으면 CodeCatalyst는 해당 디렉터리에서 보고서를 찾습니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
이 속성이 생략되면 기본값은 `"**/*"`입니다. 즉, 검색에 모든 경로의 모든 파일이 포함됩니다.
**참고**
수동으로 구성된 보고서의 경우 `IncludePaths`는 단일 파일과 일치하는 글로브 패턴이어야 합니다.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/경로 포함/제외/**경로 포함**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/포함/경로 제외/**경로 포함**
## ExcludePaths
(*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**)
또는
(*action-name*/Outputs/Reports/ *report-name-1*/**ExcludePaths**)
(선택 사항)
원시 보고서를 검색할 때 CodeCatalyst에서 제외하는 파일 및 파일 경로를 지정합니다. 예를 들어 `"/test/my-reports/**/*"` 지정 시 CodeCatalyst는 `/test/my-reports/` 디렉터리의 파일을 검색하지 않습니다. 디렉터리의 모든 파일을 무시하려면 `**/*` glob 패턴을 사용합니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/경로 포함/제외/**경로 제외**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/경로 포함/제외/**경로 제외**
## SuccessCriteria
(*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**)
또는
(*action-name*/Outputs/Reports/ *report-name-1*/**SuccessCriteria**)
(선택 사항)
테스트, 코드 적용 범위, 소프트웨어 구성 분석(SCA) 및 정적 분석(SA) 보고서의 성공 기준을 지정합니다.
자세한 내용은 [보고서의 성공 기준 구성](test-config-action.md#test.success-criteria) 섹션을 참조하세요.
해당 UI: 출력 탭/보고서/**성공 기준**
## PassRate
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**)
(선택 사항)
관련 CodeCatalyst 보고서를 통과로 표시하기 위해 통과해야 하는 테스트 보고서의 테스트 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 통과율 기준은 테스트 보고서에만 적용됩니다. 테스트 보고서에 대한 자세한 내용은 [테스트 보고서](test-workflow-actions.md#test-reports)의 내용을 참조하세요.
해당 UI: 출력 탭/보고서/성공 기준/**통과율**
## LineCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**)
(선택 사항)
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 줄 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 라인 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
해당 UI: 출력 탭/보고서/성공 기준/**라인 적용 범위**
## BranchCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**)
(선택 사항)
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 브랜치 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 브랜치 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
해당 UI: 출력 탭/보고서/성공 기준/**지점 적용 범위**
## Vulnerabilities
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**)
(선택 사항)
SCA 보고서에서 허용되는 취약성의 최대 수와 심각도를 지정하여 관련 CodeCatalyst 보고서를 통과로 표시합니다. 취약성을 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 취약성의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 취약성이 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 취약성 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
취약성 기준은 SCA 보고서에만 적용됩니다. SCA 보고서에 대한 자세한 내용은 [소프트웨어 구성 분석 보고서](test-workflow-actions.md#test-sca-reports)의 내용을 참조하세요.
최소 심각도를 지정하려면 `Severity` 속성을 사용합니다. 최대 취약성 수를 지정하려면 `Number` 속성을 사용합니다.
해당 UI: 출력 탭/보고서/성공 기준/**취약성**
## StaticAnalysisBug
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisBug**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisBug**)
(선택 사항)
관련 CodeCatalyst 보고서에 대해 SA 보고서에 허용되는 최대 버그 수와 심각도를 전달된 것으로 표시합니다. 버그를 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 버그의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 버그가 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 버그 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
버그 기준은 PyLint 및 ESLint SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
최소 심각도를 지정하려면 `Severity` 속성을 사용합니다. 최대 취약성 수를 지정하려면 `Number` 속성을 사용합니다.
해당 UI: 출력 탭/보고서/성공 기준/**버그**
## StaticAnalysisSecurity
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisSecurity**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisSecurity**)
(선택 사항)
관련 CodeCatalyst 보고서에 대해 SA 보고서에서 허용되는 보안 취약성의 최대 수와 심각도를 전달된 것으로 표시합니다. 보안 취약성을 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 보안 취약성의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 취약성이 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 보안 취약성 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
보안 취약성 기준은 PyLint 및 ESLint SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
최소 심각도를 지정하려면 `Severity` 속성을 사용합니다. 최대 취약성 수를 지정하려면 `Number` 속성을 사용합니다.
해당 UI: 출력 탭/보고서/성공 기준/**보안 취약성**
## StaticAnalysisQuality
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisQuality**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisQuality**)
(선택 사항)
관련 CodeCatalyst 보고서에 대해 SA 보고서에서 통과로 표시할 수 있는 품질 문제의 최대 수와 심각도를 지정합니다. 품질 문제를 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 품질 문제의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 품질 문제가 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 품질 문제 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
품질 문제 기준은 PyLint 및 ESLint SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
최소 심각도를 지정하려면 `Severity` 속성을 사용합니다. 최대 취약성 수를 지정하려면 `Number` 속성을 사용합니다.
해당 UI: 출력 탭/보고서/성공 기준/**품질 문제**
## StaticAnalysisFinding
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisFinding**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisFinding**)
(선택 사항)
관련 CodeCatalyst 보고서에 대해 SA 보고서에서 통과로 표시할 수 있는 조사 결과의 최대 수와 심각도를 지정합니다. 조사 결과를 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 조사 결과의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 조사 결과가 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 조사 결과 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
조사 결과는 SARIF SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
최소 심각도를 지정하려면 `Severity` 속성을 사용합니다. 최대 취약성 수를 지정하려면 `Number` 속성을 사용합니다.
해당 UI: 출력 탭/보고서/성공 기준/**조사 결과**
## Reports
(*action-name*/Outputs/**Reports**)
(선택 사항)
테스트 보고서의 구성을 지정하는 섹션입니다.
해당 UI: 출력 탭/**보고서**
## report-name-1
(*action-name*/Outputs/Reports/**report-name-1** )
([Reports](#test.configuration.reports) 포함 시 필수)
원시 보고서에서 생성될 CodeCatalyst 보고서에 부여할 이름입니다.
해당 UI: 출력 탭/보고서 수동 구성/**보고서 이름**
## Format
(*action-name*/Outputs/Reports/*report-name-1*/**Format**)
([Reports](#test.configuration.reports) 포함 시 필수)
보고서에 사용할 파일 형식을 지정합니다. 가능한 값은 다음과 같습니다.
+ 테스트 보고서의 경우:
+ Cucumber JSON에서 **Cucumber**(시각 편집기) 또는 `CUCUMBERJSON`(YAML 편집기)를 지정합니다.
+ JUnit XML에 **JUnit**(시각 편집기) 또는 `JUNITXML`(YAML 편집기)를 지정합니다.
+ NUnit XML에 **NUnit**(시각 편집기) 또는 `NUNITXML`(YAML 편집기)를 지정합니다.
+ NUnit 3 XML에서 **NUnit3**(시각 편집기) 또는 `NUNIT3XML`(YAML 편집기)를 지정합니다.
+ Visual Studio TRX에서 **Visual Studio TRX**(시각 편집기) 또는 `VISUALSTUDIOTRX`(YAML 편집기)를 지정합니다.
+ TestNG XML에서 **TestNG**(시각 편집기) 또는 `TESTNGXML`(YAML 편집기)를 지정합니다.
+ 코드 적용 범위 보고서의 경우:
+ Clover XML에서 **Clover**(시각 편집기) 또는 `CLOVERXML`(YAML 편집기)를 지정합니다.
+ Cobertura XML에서 **Cobertura**(시각 편집기) 또는 `COBERTURAXML`(YAML 편집기)를 지정합니다.
+ JaCoCo XML의 경우 **JaCoCo**(시각 편집기) 또는 `JACOCOXML`(YAML 편집기)를 지정합니다.
+ [simplecov-json](https://github.com/vicentllongo/simplecov-json)이 아닌 [simplecov](https://github.com/simplecov-ruby/simplecov)에서 생성한 SimpleCov JSON의 경우 **Simplecov**(시각 편집기) 또는 `SIMPLECOV`(YAML 편집기)를 지정합니다.
+ 소프트웨어 구성 분석(SCA) 보고서의 경우:
+ SARIF에서 **SARIF**(시각 편집기) 또는 `SARIFSCA`(YAML 편집기)를 지정합니다.
해당 UI: 출력 탭/보고서/보고서 수동 구성/보고서 추가/구성/*report-name-1*/**보고서 유형** 및 **보고서 형식**
## Configuration
(*action-name*/**Configuration**)
(필수) 작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## Container
(*action-name*/Configuration/**Container**)
(선택 사항)
작업이 처리를 완료하는 데 사용하는 Docker 이미지 또는 *컨테이너를* 지정합니다. CodeCatalyst 와 함께 제공되는 [활성 이미지](build-images.md#build-curated-images) 중 하나를 지정하거나 자체 이미지를 사용할 수 있습니다. 자체 이미지를 사용하도록 선택하면 Amazon ECR, Docker Hub 또는 다른 레지스트리에 상주할 수 있습니다. Docker 이미지를 지정하지 않으면 작업이 처리에 활성 이미지 중 하나를 사용합니다. 기본적으로 사용되는 활성 이미지에 대한 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 섹션을 참조하세요.
자체 Docker 이미지 지정에 대한 자세한 내용은 [작업에 사용자 지정 런타임 환경 Docker 이미지 할당](build-images.md#build-images-specify) 섹션을 참조하세요.
해당 UI: **런타임 환경 Docker 이미지 - 선택 사항**
## Registry
(*action-name*/Configuration/Container/**Registry**)
(`Container` 포함 시 필수)
이미지가 저장되는 레지스트리를 지정합니다. 유효한 값으로는 다음이 포함됩니다.
+ `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) 섹션을 참조하세요.
해당 UI: **Amazon Elastic Container Registry**, **Docker Hub** 및 **기타 레지스트리** 옵션
## Image
(*action-name*/Configuration/Container/**Image**)
(`Container` 포함 시 필수)
다음 중 하나를 지정하세요.
+ `CODECATALYST` 레지스트리를 사용하는 경우 이미지를 다음 [활성 이미지](build-images.md#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`
+ 사용자 지정 레지스트리를 사용하는 경우 이미지를 사용자 지정 레지스트리에서 예상되는 값으로 설정합니다.
해당 UI: **런타임 환경 Docker 이미지**(레지스터가 인 경우`CODECATALYST`), **Docker Hub 이미지**(레지스터가 **Docker Hub**인 경우), **ECR 이미지 URL**(레지스터가 **Amazon Elastic Container Registry**인 경우) 및 **이미지 URL**(레지스터가 **기타 레지스트리**인 경우).
## Steps
(*action-name*/Configuration/**Steps**)
(필수)
빌드 도구를 설치, 구성 및 실행하기 위해 작업 중에 실행할 쉘 명령을 지정합니다.
다음은 npm 프로젝트를 구축하는 방법의 예입니다.
```
Steps:
- Run: npm install
- Run: npm run build
```
다음은 파일 경로를 지정하는 방법의 예입니다.
```
Steps:
- Run: cd $ACTION_BUILD_SOURCE_PATH_WorkflowSource/app && cat file2.txt
- Run: cd $ACTION_BUILD_SOURCE_PATH_MyBuildArtifact/build-output/ && cat file.txt
```
파일 경로 지정에 대한 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md)를 참조하세요.
해당 UI: 구성 탭/**쉘 명령**
## Packages
(*action-name*/Configuration/**Packages**)
(선택 사항)
작업이 종속성을 해결하는 데 사용하는 패키지 리포지토리를 지정할 수 있는 섹션입니다. 패키지를 사용하면 애플리케이션 개발에 사용되는 소프트웨어 패키지를 안전하게 저장하고 공유할 수 있습니다.
패키지에 대한 자세한 내용은 [CodeCatalyst에서 소프트웨어 패키지 게시 및 공유](packages.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**패키지**
## NpmConfiguration
(*action-name*/Configuration/Packages/**NpmConfiguration**)
([Packages](#build.configuration.packages) 포함 시 필수)
npm 패키지 형식의 구성을 정의하는 섹션입니다. 이 구성은 워크플로 실행 중 작업에서 사용됩니다.
npm 패키지 구성에 대한 자세한 내용은 [npm 사용](packages-npm.md) 섹션을 참조하세요.
해당 UI: 구성 탭/패키지/구성 추가/**npm**
## PackageRegistries
(*action-name*/Configuration/Packages/NpmConfiguration/**PackageRegistries**)
([Packages](#build.configuration.packages) 포함 시 필수)
일련의 패키지 리포지토리의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: 구성 탭/패키지/구성 추가/npm/**패키지 리포지토리 추가**
## PackagesRepository
(*action-name*/Configuration/Packages/NpmConfiguration/PackageRegistries/**PackagesRepository**)
([Packages](#build.configuration.packages) 포함 시 필수)
작업을 사용할 CodeCatalyst *패키지 리포지토리*의 이름을 지정합니다.
여러 기본 리포지토리를 지정하는 경우 마지막 리포지토리가 우선합니다.
패키지 리포지토리에 대한 자세한 내용은 [패키지 리포지토리](packages-concepts.md#packages-concepts-repository) 섹션을 참조하세요.
해당 UI: 구성 탭/패키지/구성 추가/npm/패키지 리포지토리/**패키지 리포지토리** 추가
## Scopes
(*action-name*/Configuration/Packages/NpmConfiguration/PackageRegistries/**Scopes**)
(선택 사항)
패키지 레지스트리에서 정의할 *범위* 시퀀스를 지정합니다. 범위를 정의할 때 지정된 패키지 리포지토리는 나열된 모든 범위에 대한 레지스트리로 구성됩니다. 해당 범위의 패키지가 npm 클라이언트를 통해 요청되면 기본값 대신 해당 리포지토리를 사용합니다. 각 범위 이름 앞에는 ‘@’ 접두사를 붙여야 합니다.
범위 재정의를 포함하면 마지막 리포지토리가 우선합니다.
`Scopes` 생략 시 지정된 패키지 리포지토리가 작업에 사용되는 모든 패키지의 기본 레지스트리로 구성됩니다.
범위에 대한 자세한 내용은 [패키지 네임스페이스](packages-concepts.md#packages-concepts-package-namespaces) 및 [범위 지정 패키지](https://docs.npmjs.com/cli/v10/using-npm/scope) 섹션을 참조하세요.
해당 UI: 구성 탭/패키지/구성 추가/npm/패키지 리포지토리 추가/**범위 - 선택 사항**
## ExportAuthorizationToken
(*action-name*/Configuration/Packages/**ExportAuthorizationToken**)
(선택 사항)
권한 부여 토큰 내보내기 기능을 활성화 또는 비활성화합니다. 활성화된 경우 내보낸 권한 부여 토큰을 사용하여 CodeCatalyst 패키지 리포지토리로 인증하도록 패키지 관리자를 수동으로 구성할 수 있습니다. 토큰을 작업에서 참조할 수 있는 환경 변수로 사용할 수 있습니다.
유효한 값은 `true` 또는 `false`입니다.
`ExportAuthorizationToken` 생략 시 기본값은 `false`입니다.
권한 토큰 내보내기에 대한 자세한 내용은 [워크플로 작업에서 권한 부여 토큰 사용](workflows-package-export-token.md) 섹션을 참조하세요.
해당 UI: 구성 탭/패키지/**권한 토큰 내보내기**
# 워크플로를 사용한 테스트
CodeCatalyst에서 빌드 및 테스트와 같은 다양한 워크플로 작업의 일부로 테스트를 실행할 수 있습니다. 이러한 워크플로 작업은 모두 품질 보고서를 생성할 수 있습니다. *테스트 작업*은 테스트, 코드 적용 범위, 소프트웨어 구성 분석 및 정적 분석 보고서를 생성하는 워크플로 작업입니다. 이러한 보고서는 CodeCatalyst 콘솔에 표시됩니다.
**Topics**
+ [품질 보고서 유형](#test-reporting)
+ [테스트 작업 추가](test-add-action.md)
+ [테스트 작업 결과 보기](test-view-results.md)
+ [작업에서 실패한 테스트 건너뛰기](test.error-handling.md)
+ [universal-test-runner와 통합](test.universal-test-runner.md)
+ [작업에서 품질 보고서 구성](test-config-action.md)
+ [테스트 모범 사례](test-best-practices.md)
+ [지원되는 SARIF 속성](test.sarif.md)
## 품질 보고서 유형
Amazon CodeCatalyst 테스트 작업은 다음과 같은 유형의 품질 보고서를 지원합니다. YAML에서 이러한 보고서를 포맷하는 방법에 대한 예시는 [품질 보고서 YAML 예시](test-config-action.md#test.success-criteria-example) 섹션을 참조하세요.
**Topics**
+ [테스트 보고서](#test-reports)
+ [코드 적용 범위 보고서](#test-code-coverage-reports)
+ [소프트웨어 구성 분석 보고서](#test-sca-reports)
+ [정적 분석 보고서](#test-static-analysis-reports)
### 테스트 보고서
CodeCatalyst에서 빌드 중에 실행되는 단위 테스트, 통합 테스트 및 시스템 테스트를 구성할 수 있습니다. 그런 다음 CodeCatalyst는 테스트 결과를 포함하는 보고서를 생성할 수 있습니다.
테스트 보고서를 사용하여 테스트 문제를 해결할 수 있습니다. 빌드 프로젝트의 여러 빌드에 많은 테스트 보고서가 있는 경우 테스트 보고서를 사용하여 추세와 테스트 및 실패율을 보고 빌드를 쉽게 최적화할 수 있습니다.
다음 테스트 보고서 파일 형식을 사용할 수 있습니다.
+ Cucumber JSON(.json)
+ JUnit XML(.xml)
+ NUnit XML(.xml)
+ NUnit3 XML(.xml)
+ TestNG XML(.xml)
+ Visual Studio TRX (.trx, .xml)
### 코드 적용 범위 보고서
CodeCatalyst에서는 테스트에 대한 코드 적용 범위 보고서를 생성할 수 있습니다. CodeCatalyst는 다음과 같은 코드 적용 범위 지표를 제공합니다.
행 범위
행 범위는 테스트에서 다루는 명령문 수를 측정합니다. 문은 설명이 포함되지 않은 단일 명령어입니다.
`line coverage = (total lines covered)/(total number of lines)`
브랜치 적용 범위
또는 문과 같은 제어 구조의 가능한 모든 브랜치 중 테스트에서 다루는 분기 수(`if` 또는 `case`)를 측정합니다.
`branch coverage = (total branches covered)/(total number of branches)`
다음 코드 적용 범위 보고서 파일 형식이 지원됩니다.
+ JaCoCo XML(.xml)
+ SimpleCov JSON([simplecov-json](https://github.com/vicentllongo/simplecov-json), .json이 아닌 [simplecov](https://github.com/simplecov-ruby/simplecov)에서 생성됨)
+ Clover XML(버전 3, .xml)
+ Cobertura XML(.xml)
+ LCOV(.info)
### 소프트웨어 구성 분석 보고서
CodeCatalyst에서 소프트웨어 구성 분석(SCA) 도구를 사용하여 애플리케이션의 구성 요소를 분석하고 알려진 보안 취약성을 확인할 수 있습니다. 심각도가 다양한 취약성과 이를 수정하는 방법을 자세히 설명하는 SARIF 보고서를 검색하고 구문 분석할 수 있습니다. 최대부터 최소 심각도까지 유효한 심각도 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, `INFORMATIONAL`입니다.
지원되는 SCA 보고서 파일 형식은 다음과 같습니다.
+ SARIF(.sarif, .json)
### 정적 분석 보고서
정적 분석(SA) 보고서를 사용하여 소스 수준 코드 결함을 식별할 수 있습니다. CodeCatalyst에서 SA 보고서를 생성하여 코드를 배포하기 전에 코드 문제를 해결할 수 있습니다. 이러한 문제에는 버그, 보안 취약성, 품질 문제 및 기타 취약성이 포함됩니다. 최대부터 최소 심각도까지 유효한 심각도 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
CodeCatalyst는 다음과 같은 SA 지표를 제공합니다.
버그
소스 코드에서 발견된 가능한 버그 수를 식별합니다. 이러한 버그에는 메모리 안전성에 관한 문제가 포함될 수 있습니다. 다음은 버그의 예시입니다.
```
// The while loop will inadvertently index into array x out-of-bounds
int x[64];
while (int n = 0; n <= 64; n++) {
x[n] = 0;
}
```
보안 취약성
소스 코드에서 발견된 여러 가지 가능한 보안 취약성을 식별합니다. 이러한 보안 취약성에는 보안 암호 토큰을 일반 텍스트로 저장하는 등의 문제가 포함될 수 있습니다.
품질 문제
소스 코드에서 발견된 여러 가지 가능한 품질 문제를 식별합니다. 이러한 품질 문제에는 스타일 규칙과 관련된 문제가 포함될 수 있습니다. 다음은 품질 문제의 예입니다.
```
// The function name doesn't adhere to the style convention of camelCase
int SUBTRACT(int x, int y) {
return x-y
}
```
기타 취약성
소스 코드에서 발견된 여러 가지 가능한 보안 취약성을 식별합니다.
CodeCatalyst에서 지원되는 코드 적용 범위 보고서 파일 형식은 다음과 같습니다.
+ PyLint(.py)
+ ESLint(.js, .jsx, .ts, .tsx)
+ SARIF(.sarif, .json)
# 테스트 작업 추가
다음 절차에 따라 CodeCatalyst 워크플로에 테스트 작업을 추가합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 테스트 작업 추가**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **테스트**를 선택합니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 빌드 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **테스트**를 선택합니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 [빌드 및 테스트 작업 YAML](build-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
## 작업 정의 테스트
테스트 작업은 워크플로 정의 파일 내의 YAML 속성 집합으로 정의됩니다. 이러한 속성에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요.
# 테스트 작업 결과 보기
다음 지침에 따라 생성된 로그, 보고서 및 변수를 포함한 테스트 작업의 결과를 확인합니다.
**테스트 작업 결과 보기**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 워크플로 다이어그램에서 테스트 작업의 이름(예시: **테스트**)을 선택합니다.
1. 작업에서 생성된 로그를 보려면 **로그**를 선택합니다. 다양한 작업 단계의 로그가 표시됩니다. 필요에 따라 로그를 확장하거나 축소할 수 있습니다.
1. 테스트 작업에서 생성된 테스트 보고서를 보려면 **보고서**를 선택하거나 탐색 창에서 **보고서**를 선택합니다. 자세한 내용은 [품질 보고서 유형](test-workflow-actions.md#test-reporting) 섹션을 참조하세요.
1. 빌드 작업에 사용되는 구성을 보려면 **구성**을 선택합니다. 자세한 내용은 [테스트 작업 추가](test-add-action.md) 섹션을 참조하세요.
1. 테스트 작업에 사용되는 변수를 보려면 **변수**를 선택합니다. 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
# 작업에서 실패한 테스트 건너뛰기
작업에 테스트 명령이 두 개 이상 있는 경우 이전 명령이 실패하더라도 작업의 후속 테스트 명령이 실행되도록 허용할 수 있습니다. 예를 들어, 다음 명령에서는 `test1`이 실패하더라도 `test2`가 항상 실행되도록 할 수 있습니다.
```
Steps:
- Run: npm install
- Run: npm run test1
- Run: npm run test2
```
일반적으로 단계가 오류를 반환하면 Amazon CodeCatalyst는 워크플로 작업을 중지하고 실패로 표시합니다. 오류 출력을 `null`로 리디렉션하여 작업 단계가 계속 실행되도록 허용할 수 있습니다. 명령에 `2>/dev/null`을 추가하면 이 작업을 수행할 수 있습니다. 이렇게 수정하면 앞의 예시는 다음과 같이 표시됩니다.
```
Steps:
- Run: npm install
- Run: npm run test1 2>/dev/null
- Run: npm run test2
```
두 번째 코드 조각에서는 `npm install` 명령의 상태가 그대로 유지되지만 `npm run test1` 명령에서 반환된 오류는 무시됩니다. 결과적으로 `npm run test2` 명령이 실행됩니다. 이렇게 하면 오류 발생 여부에 관계없이 두 보고서를 한 번에 볼 수 있습니다.
# universal-test-runner와 통합
테스트 작업은 오픈 소스 명령줄 도구인 `universal-test-runner`와 통합됩니다. `universal-test-runner`는 [테스트 실행 프로토콜](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md)을 사용하여 주어진 프레임워크에서 모든 언어에 대한 테스트를 실행합니다. `universal-test-runner`는 다음 프레임워크를 지원합니다.
+ [Gradle](https://gradle.org/)
+ [Jest](https://jestjs.io/)
+ [Maven](https://maven.apache.org/)
+ [pytest](https://pytest.org)
+ [.NET](https://learn.microsoft.com/en-us/dotnet/core/tools/)
`universal-test-runner`는 테스트 동작을 위해 큐레이팅된 이미지에만 설치됩니다. 용자 지정 Docker Hub 또는 Amazon ECR을 사용하도록 테스트 동작을 구성하는 경우 고급 테스트 특성을 사용하려면 `universal-test-runner`를 수동으로 설치해야 합니다. 이렇게 하려면 이미지에 Node.js(14 이상)를 설치한 후 다음 쉘 명령 `- Run: npm install -g @aws/universal-test-runner`을 사용하여 `npm`을 통해 `universal-test-runner`를 설치합니다. 쉘 명령을 통해 컨테이너에 Node.js를 설치하는 방법에 대한 자세한 내용은 [Installing and Updating Node Version Manager](https://github.com/nvm-sh/nvm#install--update-script)를 참조하세요.
`universal-test-runner`에 대한 자세한 내용은 [What is universal-test-runner?](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner) 섹션을 참조하세요.
------
#### [ Visual ]
**시각적 편집기에서 universal-test-runner 사용**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **테스트**를 선택합니다.
1. **구성** 탭에서 지원되는 프레임워크를 선택하여 샘플 코드를 업데이트하여 **쉘 명령** 필드를 완료합니다. 예를 들어 지원되는 프레임워크를 사용하려면 다음과 유사한 `Run` 명령을 사용합니다.
```
- Run: run-tests
```
원하는 프레임워크가 지원되지 않는 경우 사용자 지정 어댑터 또는 러너를 제공하는 것이 좋습니다. **쉘 명령** 필드에 대한 설명은 [Steps](build-action-ref.md#build.configuration.steps) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기에서 universal-test-runner 사용**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. **작업**을 선택합니다.
1. **작업**에서 **테스트**를 선택합니다.
1. 필요에 따라 YAML 코드를 수정합니다. 예를 들어 지원되는 프레임워크를 사용하려면 다음과 유사한 `Run` 명령을 사용합니다.
```
Configuration:
Steps:
- Run: run-tests
```
원하는 프레임워크가 지원되지 않는 경우 사용자 지정 어댑터 또는 러너를 제공하는 것이 좋습니다. **Steps** 속성에 대한 설명은 [Steps](build-action-ref.md#build.configuration.steps) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 작업에서 품질 보고서 구성
이 섹션에서는 작업에서 품질 보고서를 구성하는 방법을 설명합니다.
**Topics**
+ [자동 검색 및 수동 보고서](#test.auto-discovery)
+ [보고서의 성공 기준 구성](#test.success-criteria)
+ [품질 보고서 YAML 예시](#test.success-criteria-example)
## 자동 검색 및 수동 보고서
자동 검색이 활성화되면 CodeCatalyst는 작업에 전달된 모든 입력과 작업 자체에서 생성된 모든 파일을 검색하여 테스트, 코드 적용 범위, 소프트웨어 구성 분석(SCA) 및 정적 분석(SA) 보고서를 찾습니다. CodeCatalyst에서 이러한 각 보고서를 보고 조작할 수 있습니다.
생성되는 보고서를 수동으로 구성할 수도 있습니다. 생성하려는 보고서 유형과 파일 형식을 지정할 수 있습니다. 자세한 내용은 [품질 보고서 유형](test-workflow-actions.md#test-reporting) 섹션을 참조하세요.
## 보고서의 성공 기준 구성
테스트, 코드 적용 범위, 소프트웨어 구성 분석(SCA) 또는 정적 분석(SA) 보고서의 성공 기준을 결정하는 값을 설정할 수 있습니다.
성공 기준은 보고서가 통과 또는 실패하는지 여부를 결정하는 임계값입니다. CodeCatalyst는 먼저 테스트, 코드 적용 범위, SCA 또는 SA 보고서일 수 있는 보고서를 생성한 다음 생성된 보고서에 성공 기준을 적용합니다. 그런 다음 성공 기준이 충족되었는지 여부와 어느 정도까지 충족되었는지 보여줍니다. 지정된 성공 기준을 충족하지 않는 보고서가 있으면 성공 기준을 지정한 CodeCatalyst 작업이 실패합니다.
예를 들어 SCA 보고서의 성공 기준을 설정할 때 가장 심각함에서 가장 덜 심각함까지의 유효한 취약성 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, `INFORMATIONAL`입니다. `HIGH` 심각도에서 하나의 취약성을 스캔하도록 기준을 설정하면 `HIGH` 심각도에서 하나 이상의 취약성이 있거나 심각도에서 취약성이 없지만 `HIGH` 심각도에서 하나의 취약성과 같이 `CRITICAL` 심각도가 더 높은 수준에서 하나 이상의 취약성이 있는 경우 보고서가 실패합니다.
성공 기준을 지정하지 않으면 다음을 수행합니다.
+ 원시 보고서를 기반으로 생성된 CodeCatalyst 보고서에는 성공 기준이 표시되지 않습니다.
+ 성공 기준은 연결된 워크플로 작업이 통과 또는 실패하는지 여부를 결정하는 데 사용되지 않습니다.
------
#### [ Visual ]
**성공 기준 구성**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 보고서를 생성하는 작업이 포함된 워크플로를 선택합니다. 성공 기준을 적용하려는 보고서입니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 CodeCatalyst 보고서를 생성하도록 구성한 작업을 선택합니다.
1. **출력** 탭을 선택합니다.
1. **보고서 자동 검색** 또는 **보고서 수동 구성**에서 **성공 기준**을 선택합니다.
성공 기준이 나타납니다. 이전 선택에 따라 다음 옵션 중 일부 또는 전부가 표시될 수 있습니다.
**통과율**
관련 CodeCatalyst 보고서를 통과로 표시하기 위해 통과해야 하는 테스트 보고서의 테스트 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 통과율 기준은 테스트 보고서에만 적용됩니다. 테스트 보고서에 대한 자세한 내용은 [테스트 보고서](test-workflow-actions.md#test-reports)의 내용을 참조하세요.
**행 범위**
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 줄 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 라인 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
**브랜치 적용 범위**
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 브랜치 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 브랜치 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
**취약성(SCA)**
SCA 보고서에서 허용되는 취약성의 최대 수와 심각도를 지정하여 관련 CodeCatalyst 보고서를 통과로 표시합니다. 취약성을 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 취약성의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 취약성이 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 취약성 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
취약성 기준은 SCA 보고서에만 적용됩니다. SCA 보고서에 대한 자세한 내용은 [소프트웨어 구성 분석 보고서](test-workflow-actions.md#test-sca-reports)의 내용을 참조하세요.
**bugs**
관련 CodeCatalyst 보고서에 대해 SA 보고서에 허용되는 최대 버그 수와 심각도를 전달된 것으로 표시합니다. 버그를 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 버그의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 버그가 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 버그 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
버그 기준은 PyLint 및 ESLint SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
**보안 취약성**
관련 CodeCatalyst 보고서에 대해 SA 보고서에서 허용되는 보안 취약성의 최대 수와 심각도를 전달된 것으로 표시합니다. 보안 취약성을 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 보안 취약성의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 취약성이 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 보안 취약성 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
보안 취약성 기준은 PyLint 및 ESLint SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
**품질 문제**
관련 CodeCatalyst 보고서에 대해 SA 보고서에서 통과로 표시할 수 있는 품질 문제의 최대 수와 심각도를 지정합니다. 품질 문제를 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 품질 문제의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 품질 문제가 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 품질 문제 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
품질 문제 기준은 PyLint 및 ESLint SA 보고서에만 적용됩니다. SA 보고서에 대한 자세한 내용은 [정적 분석 보고서](test-workflow-actions.md#test-static-analysis-reports)의 내용을 참조하세요.
1. **커밋**을 선택합니다.
1. 워크플로를 실행하여 CodeCatalyst가 원시 보고서에 성공 기준을 적용하도록 하고, 성공 기준 정보가 포함된 관련 CodeCatalyst 보고서를 다시 생성합니다. 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
------
#### [ YAML ]
**성공 기준 구성**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 보고서를 생성하는 작업이 포함된 워크플로를 선택합니다. 성공 기준을 적용하려는 보고서입니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 워크플로 다이어그램에서 CodeCatalyst 보고서를 생성하도록 구성한 작업을 선택합니다.
1. 세부 정보 창에서 **출력** 탭을 선택합니다.
1. 작업의 `AutoDiscoverReports` 섹션 또는 `Reports` 섹션에서 **SuccessCriteria** 속성을 `PassRate`, `LineCoverage`, `BranchCoverage`, `Vulnerabilities`, `StaticAnalysisBug`, `StaticAnalysisSecurity`, `StaticAnalysisQuality` 속성과 함께 추가합니다.
이러한 각 속성에 대한 설명은 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요.
1. **커밋**을 선택합니다.
1. 워크플로를 실행하여 CodeCatalyst가 원시 보고서에 성공 기준을 적용하도록 하고 성공 기준 정보가 포함된 관련 CodeCatalyst 보고서를 다시 생성합니다. 배치 워크플로우에 대한 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
------
## 품질 보고서 YAML 예시
다음 예시에서는 테스트 보고서, 코드 적용 범위 보고서, 소프트웨어 구성 분석 보고서, 정적 분석 보고서 등 4개의 보고서를 수동으로 구성하는 방법을 보여줍니다.
```
Reports:
MyTestReport:
Format: JUNITXML
IncludePaths:
- "*.xml"
ExcludePaths:
- report1.xml
SuccessCriteria:
PassRate: 90
MyCoverageReport:
Format: CLOVERXML
IncludePaths:
- output/coverage/jest/clover.xml
SuccessCriteria:
LineCoverage: 75
BranchCoverage: 75
MySCAReport:
Format: SARIFSCA
IncludePaths:
- output/sca/reports.xml
SuccessCriteria:
Vulnerabilities:
Number: 5
Severity: HIGH
MySAReport:
Format: ESLINTJSON
IncludePaths:
- output/static/eslint.xml
SuccessCriteria:
StaticAnalysisBug:
Number: 10
Severity: MEDIUM
StaticAnalysisSecurity:
Number: 5
Severity: CRITICAL
StaticAnalysisQuality:
Number: 0
Severity: INFORMATIONAL
```
# 테스트 모범 사례
CodeCatalyst에서 제공하는 테스트 기능을 사용할 때는 다음 모범 사례를 따르는 것이 좋습니다.
**Topics**
+ [자동 검색](#test.best-auto-discovery)
+ [성공 기준](#test.best-success-criteria)
+ [경로 포함/제외](#test.best-include-exclude)
## 자동 검색
CodeCatalyst에서 작업을 구성할 때 자동 검색을 사용하면 JUnit 테스트 보고서와 같은 다양한 도구의 출력을 자동으로 검색하고 해당 도구에서 관련 CodeCatalyst 보고서를 생성할 수 있습니다. 자동 검색은 검색된 출력의 이름이나 경로가 변경되더라도 보고서가 계속 생성되도록 하는 데 도움이 됩니다. 새 파일이 추가되면 CodeCatalyst는 자동으로 파일을 검색하고 관련 보고서를 생성합니다. 그러나 자동 검색을 사용하는 경우 이 기능의 다음 측면 중 일부를 고려해야 합니다.
+ 작업에서 자동 검색을 활성화하면 동일한 유형의 자동으로 검색된 모든 보고서가 동일한 성공 기준을 공유합니다. 예를 들어 최소 통과율과 같은 공유 기준이 모든 자동 검색된 테스트 보고서에 적용됩니다. 동일한 유형의 보고서에 대해 다른 기준이 필요한 경우 이러한 각 보고서를 명시적으로 구성해야 합니다.
+ 자동 검색은 종속성에서 생성된 보고서를 찾을 수도 있으며 성공 기준이 구성된 경우 이러한 보고서에 대한 작업에 실패할 수 있습니다. 이 문제는 제외 경로 구성을 업데이트하여 해결할 수 있습니다.
+ 자동 검색은 런타임에 작업을 스캔하기 때문에 매번 동일한 보고서 목록을 생성하지는 않습니다. 특정 보고서를 항상 생성하려면 보고서를 명시적으로 구성해야 합니다. 예를 들어 빌드의 일부로 테스트 실행을 중지해야 하는 경우 테스트 프레임워크는 출력을 생성하지 않으며, 결과적으로 테스트 보고서가 생성되지 않고 작업이 성공할 수 있습니다. 작업의 성공이 특정 테스트에 따라 달라지도록 하려면 해당 보고서를 명시적으로 구성해야 합니다.
**작은 정보**
새 프로젝트 또는 기존 프로젝트를 시작할 때 전체 프로젝트 디렉터리(`**/*` 포함)에 대해 자동 검색을 사용합니다. 이렇게 하면 하위 디렉터리 내의 파일을 포함하여 프로젝트의 모든 파일에서 보고서 생성이 간접 호출됩니다.
자세한 내용은 [작업에서 품질 보고서 구성](test-config-action.md) 섹션을 참조하세요.
## 성공 기준
성공 기준을 구성하여 보고서에 품질 임계값을 적용할 수 있습니다. 예를 들어 두 개의 코드 적용 범위 보고서가 자동으로 검색된 경우, 하나는 80%의 행 적용 범위이고 다른 하나는 60%의 행 적용 범위인 경우 다음 옵션이 있습니다.
+ 행 적용 범위에 대한 자동 검색 성공 기준을 80%로 설정합니다. 이로 인해 첫 번째 보고서가 통과하고 두 번째 보고서가 실패하여 전체 작업이 실패합니다. 워크플로의 차단을 해제하려면 두 번째 보고서의 행 적용 범위가 80%를 초과할 때까지 프로젝트에 새 테스트를 추가합니다.
+ 행 적용 범위에 대한 자동 검색 성공 기준을 60%로 설정합니다. 이렇게 하면 두 보고서가 모두 전달되어 작업이 성공합니다. 그런 다음 두 번째 보고서에서 코드 적용 범위를 늘리는 작업을 수행할 수 있습니다. 그러나 이 접근 방식을 사용하면 첫 번째 보고서의 적용 범위가 80% 미만으로 떨어지지 않는다고 보장할 수 없습니다.
+ 시각적 편집기를 사용하거나 각 보고서에 대해 명시적 YAML 섹션 및 경로를 추가하여 하나 또는 두 개의 보고서를 명시적으로 구성합니다. 이렇게 하면 각 보고서에 대해 별도의 성공 기준과 사용자 지정 이름을 구성할 수 있습니다. 그러나 이 접근 방식을 사용하면 보고서 경로가 변경되면 작업이 실패할 수 있습니다.
자세한 내용은 [보고서의 성공 기준 구성](test-config-action.md#test.success-criteria) 섹션을 참조하세요.
## 경로 포함/제외
작업 결과를 검토할 때 `IncludePaths` 및 `ExcludePaths`를 구성하여 CodeCatalyst에서 생성한 보고서 목록을 조정할 수 있습니다.
+ `IncludePaths`는 보고서를 검색할 때 CodeCatalyst가 포함할 파일 및 파일 경로를 지정하는 데 사용합니다. 예를 들어 `"/test/report/*"` 지정 시 CodeCatalyst는 작업에서 `/test/report/` 디렉터리를 찾는 데 사용되는 전체 빌드 이미지를 검색합니다. 해당 디렉터리를 찾으면 CodeCatalyst는 해당 디렉터리에서 보고서를 찾습니다.
**참고**
수동으로 구성된 보고서의 경우 `IncludePaths`는 단일 파일과 일치하는 글로브 패턴이어야 합니다.
+ `ExcludePaths`는 보고서를 검색할 때 CodeCatalyst가 제외할 파일 및 파일 경로를 지정하는 데 사용합니다. 예를 들어 `"/test/reports/**/*"` 지정 시 CodeCatalyst는 `/test/reports/` 디렉터리의 파일을 검색하지 않습니다. 디렉터리의 모든 파일을 무시하려면 `**/*` glob 패턴을 사용합니다.
다음은 가능한 glob 패턴의 몇 가지 예입니다.
| 패턴 | 설명 |
| --- | --- |
| `*.*` | 점을 포함한 모든 객체 이름과 해당합니다. |
| `*.xml` | `.xml`로 끝나는 현재 디렉터리의 모든 객체 이름과 일치 |
| `*.{xml,txt}` | `.xml` 또는 `.txt`로 끝나는 현재 디렉터리의 모든 객체 이름과 일치 |
| `**/*.xml` | `.xml`로 끝나는 모든 디렉터리의 객체 이름과 일치 |
| `testFolder` | 파일로 취급하여 `testFolder` 객체와 일치 |
| `testFolder/*` | `testFolder/file.xml`와 같은 `testFolder`에서 하위 폴더의 한 수준의 객체와 일치 |
| `testFolder/*/*` | `testFolder/reportsFolder/file.xml`와 같은 `testFolder`에서 하위 폴더의 두 가지 수준의 객체와 일치 |
| `testFolder/**` | `testFolder` 아래 파일뿐만 아니라 하위 폴더 `testFolder`도 일치시킵니다(예: `testFolder/file.xml`와 `testFolder/otherFolder/file.xml`). |
CodeCatalyst는 다음과 같이 glob 패턴을 해석합니다.
+ 슬래시(`/`) 문자는 파일 경로의 디렉터리를 구분합니다.
+ 별표(`*`) 문자는 폴더의 경계를 넘지 않고 0개 이상의 이름 구성 요소 문자와 해당합니다.
+ 이중 별표(`**`)는 모든 디렉터리에서 이름 구성 요소의 0개 이상 문자와 일치합니다.
**참고**
`ExcludePaths`가 `IncludePaths`보다 우선합니다. `IncludePaths` 및 `ExcludePaths`에 모두 동일한 폴더가 포함된 경우 해당 폴더는 보고서에 대해 스캔되지 않습니다.
# 지원되는 SARIF 속성
정적 분석 결과 교환 형식(SARIF)은 Amazon CodeCatalyst의 소프트웨어 구성 분석(SCA) 및 정적 분석 보고서에서 사용할 수 있는 출력 파일 형식입니다. 다음 예시는 정적 분석 보고서에서 SARIF를 수동으로 구성하는 방법을 보여줍니다.
```
Reports:
MySAReport:
Format: SARIFSA
IncludePaths:
- output/sa_report.json
SuccessCriteria:
StaticAnalysisFinding:
Number: 25
Severity: HIGH
```
CodeCatalyst는 다음과 같은 SARIF 속성을 지원하며, 이를 사용하여 분석 결과가 보고서에 표시되는 방식을 최적화할 수 있습니다.
**Topics**
+ [`sarifLog` 객체](#test.sarif.sarifLog)
+ [`run` 객체](#test.sarif.run)
+ [`toolComponent` 객체](#test.sarif.toolComponent)
+ [`reportingDescriptor` 객체](#test.sarif.reportingDescriptor)
+ [`result` 객체](#test.sarif.result)
+ [`location` 객체](#test.sarif.location)
+ [`physicalLocation` 객체](#test.sarif.physicalLocation)
+ [`logicalLocation` 객체](#test.sarif.logicalLocation)
+ [`fix` 객체](#test.sarif.fix)
## `sarifLog` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `$schema` | 예 | 버전 [2.1.0](https://json.schemastore.org/sarif-2.1.0.json)에 대한 SARIF JSON 스키마의 URI입니다. |
| `version` | 예 | CodeCatalyst는 SARIF 버전 2.1.0만 지원합니다. |
| `runs[]` | 예 | SARIF 파일에는 하나 이상의 실행 배열이 포함되며, 각 실행은 분석 도구의 단일 실행을 나타냅니다. |
## `run` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `tool.driver` | 예 | 분석 도구를 설명하는 `toolComponent` 객체입니다. |
| `tool.name` | 아니요 | 분석을 수행하는 데 사용되는 도구의 이름을 나타내는 속성입니다. |
| `results[]` | 예 | CodeCatalyst에 표시되는 분석 도구의 결과입니다. |
## `toolComponent` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `name` | 예 | 분석 도구의 이름입니다. |
| `properties.artifactScanned` | 아니요 | 도구에서 분석한 총 아티팩트 수입니다. |
| `rules[]` | 예 | 규칙을 나타내는 `reportingDescriptor` 객체의 배열입니다. 이러한 규칙을 기반으로 분석 도구는 분석되는 코드에서 문제를 찾습니다. |
## `reportingDescriptor` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `id` | 예 | 조사 결과를 참조하는 데 사용되는 규칙의 고유 식별자입니다. 최대 길이: 1,024자 |
| `name` | 아니요 | 규칙의 디스플레이 이름입니다. 최대 길이: 1,024자 |
| `shortDescription.text` | 아니요 | 규칙에 대한 짧은 설명입니다. 최대 길이: 3,000자 |
| `fullDescription.text` | 아니요 | 규칙에 대한 전체 설명입니다. 최대 길이: 3,000자 |
| `helpUri` | 아니요 | 규칙에 대한 기본 설명서의 절대 URI를 포함하도록 현지화할 수 있는 문자열입니다. 최대 길이: 3,000자 |
| `properties.unscore` | 아니요 | 스캔 조사 결과의 점수가 매겨졌는지 여부를 나타내는 플래그입니다. |
| `properties.score.severity` | 아니요 | 조사 결과의 심각도 수준을 지정하는 고정된 문자열 세트입니다. 최대 길이: 1,024자 |
| `properties.cvssv3_baseSeverity` | 아니요 | [일반 취약성 점수 체계 v3.1](https://www.first.org/cvss/v3.1/specification-document)의 정성적 심각도 등급입니다. |
| `properties.cvssv3_baseScore` | 아니요 | CVSS v3 기본 점수 범위는 [0.0\$110.0](https://nvd.nist.gov/vuln-metrics/cvss)입니다. |
| `properties.cvssv2_severity` | 아니요 | CVSS v3 값을 사용할 수 없는 경우 CodeCatalyst는 CVSS v2 값을 검색합니다. |
| `properties.cvssv2_score` | 아니요 | CVSS v2 기본 점수 범위는 [0.0\$110.0](https://nvd.nist.gov/vuln-metrics/cvss)입니다. |
| `properties.severity` | 아니요 | 조사 결과의 심각도 수준을 지정하는 고정된 문자열 세트입니다. 최대 길이: 1,024자 |
| `defaultConfiguration.level` | 아니요 | 규칙의 기본 심각도입니다. |
## `result` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `ruleId` | 예 | 조사 결과를 참조하는 데 사용되는 규칙의 고유 식별자입니다. 최대 길이: 1,024자 |
| `ruleIndex` | 예 | 도구 구성 요소 `rules[]`에서 연결된 규칙의 인덱스입니다. |
| `message.text` | 예 | 결과를 설명하고 각 조사 결과에 대한 메시지를 표시하는 메시지입니다. 최대 길이: 3,000자 |
| `rank` | 아니요 | 결과의 우선 순위 또는 중요도를 나타내는 0.0\$1100.0 사이의 값입니다. 이 규모의 값은 0.0이 가장 낮은 우선 순위이고 100.0이 가장 높은 우선 순위입니다. |
| `level` | 아니요 | 결과의 심각도입니다. 최대 길이: 1,024자 |
| `properties.unscore` | 아니요 | 스캔 조사 결과의 점수가 매겨졌는지 여부를 나타내는 플래그입니다. |
| `properties.score.severity` | 아니요 | 조사 결과의 심각도 수준을 지정하는 고정된 문자열 세트입니다. 최대 길이: 1,024자 |
| `properties.cvssv3_baseSeverity` | 아니요 | [일반 취약성 점수 체계 v3.1](https://www.first.org/cvss/v3.1/specification-document)의 정성적 심각도 등급입니다. |
| `properties.cvssv3_baseScore` | 아니요 | CVSS v3 기본 점수 범위는 [0.0\$110.0](https://nvd.nist.gov/vuln-metrics/cvss)입니다. |
| `properties.cvssv2_severity` | 아니요 | CVSS v3 값을 사용할 수 없는 경우 CodeCatalyst는 CVSS v2 값을 검색합니다. |
| `properties.cvssv2_score` | 아니요 | CVSS v2 기본 점수 범위는 [0.0\$110.0](https://nvd.nist.gov/vuln-metrics/cvss)입니다. |
| `properties.severity` | 아니요 | 조사 결과의 심각도 수준을 지정하는 고정된 문자열 세트입니다. 최대 길이: 1,024자 |
| `locations[]` | 예 | 결과가 감지된 위치 집합입니다. 지정된 모든 위치에서 변경해야만 문제를 해결할 수 있는 경우가 아니라면 한 위치만 포함해야 합니다. CodeCatalyst는 위치 배열의 첫 번째 값을 사용하여 결과에 주석을 지정합니다. 최대 `location` 객체 개수: 10 |
| `relatedLocations[]` | 아니요 | 조사 결과에서 참조하는 추가 위치 목록입니다. 최대 `location` 객체 개수: 50 |
| `fixes[]` | 아니요 | 스캔 도구에서 제공하는 권장 사항을 나타내는 `fix` 객체 배열입니다. CodeCatalyst는 `fixes` 배열에서 첫 번째 권장 사항을 사용합니다. |
## `location` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `physicalLocation` | 예 | 아티팩트와 리전을 식별합니다. |
| `logicalLocations[]` | 아니요 | 아티팩트를 참조하지 않고 이름으로 설명하는 위치 집합입니다. |
## `physicalLocation` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `artifactLocation.uri` | 예 | 아티팩트의 위치를 나타내는 URI로, 일반적으로 리포지토리에 있거나 빌드 중에 생성된 파일입니다. |
| `fileLocation.uri` | 아니요 | 파일 위치를 나타내는 대체 URI입니다. `artifactLocation.uri`가 빈 상태를 반환하는 경우 사용됩니다. |
| `region.startLine` | 예 | 리전의 첫 번째 문자의 행 번호입니다. |
| `region.startColumn` | 예 | 리전의 첫 번째 문자의 열 번호입니다. |
| `region.endLine` | 예 | 리전의 마지막 문자의 행 번호입니다. |
| `region.endColumn` | 예 | 리전의 마지막 문자의 열 번호입니다. |
## `logicalLocation` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `fullyQualifiedName` | 아니요 | 결과의 위치를 설명하는 추가 정보입니다. 최대 길이: 1,024자 |
## `fix` 객체
| 이름 | 필수 | 설명 |
| --- | --- | --- |
| `description.text` | 아니요 | 각 조사 결과에 대한 권장 사항을 표시하는 메시지입니다. 최대 길이: 3,000자 |
| `artifactChanges.[0].artifactLocation.uri` | 아니요 | 업데이트해야 하는 아티팩트의 위치를 나타내는 URI입니다. |
# 워크플로를 사용하여 배포
[CodeCatalyst 워크플로](workflow.md)를 사용하면 Amazon ECS 등과 같은 다양한 대상에 애플리케이션 및 기타 리소스를 배포할 수 AWS Lambda있습니다.
## 애플리케이션을 배포하려면 어떻게 해야 하나요?
CodeCatalyst를 통해 애플리케이션 또는 리소스를 배포하려면 먼저 워크플로를 생성한 다음 그 안에 배포 작업을 지정합니다. *배포 작업*은 배포하려는 *대상*, 배포하려는 *위치* 및 배포 *방법*(예: 블루/그린 스키마 사용)을 정의하는 워크플로 구성 요소입니다. CodeCatalyst 콘솔의 시각적 편집기 또는 YAML 편집기를 사용하여 워크플로에 배포 작업을 추가합니다.
애플리케이션 또는 리소스를 배포하는 상위 단계는 다음과 같습니다.
**애플리케이션을 배포하려면(고급 작업)**
1. CodeCatalyst 프로젝트에서 배포하려는 애플리케이션의 **소스 코드를 추가**합니다. 자세한 내용은 [CodeCatalyst에서 프로젝트의 리포지토리에 소스 코드 저장](source-repositories.md) 단원을 참조하십시오.
1. CodeCatalyst 프로젝트에서 배포하려는 대상 AWS 계정 및 선택적 Amazon Virtual Private Cloud(VPC)를 정의하는 **환경을 추가합니다**. 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 단원을 참조하십시오.
1. CodeCatalyst 프로젝트에서 **워크플로를 생성**합니다. 워크플로에서는 애플리케이션을 빌드, 테스트 및 배포하는 방법을 정의합니다. 자세한 내용은 [워크플로 시작하기](workflows-getting-started.md) 섹션을 참조하세요.
1. 워크플로에서 **트리거**, **빌드 작업** 및 선택적으로 **테스트 작업**을 추가합니다. 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md), [빌드 작업 추가](build-add-action.md), [테스트 작업 추가](test-add-action.md) 섹션을 참조하세요.
1. 워크플로에서 **배포 작업을 추가**합니다. 여러 CodeCatalyst 제공 배포 작업을 Amazon ECS와 같은 다양한 대상으로 애플리케이션에 선택할 수 있습니다. (구축 작업 또는 GitHub Actions를 사용하여 애플리케이션을 배포할 수도 있습니다. 빌드 작업 및 GitHub Actions에 대한 자세한 내용은 [작업을 배포하는 대안](#deploy-concepts-alternatives) 섹션을 참조하세요.)
1. 트리거를 통해 **워크플로를 수동으로 또는 자동으로 시작**합니다. 워크플로는 빌드, 테스트 및 배포 작업을 순서대로 실행하여 애플리케이션 및 리소스를 대상에 배포합니다. 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
## 배포 작업 목록
다음 배포 작업을 사용할 수 있습니다.
+ CloudFormation 스택 배포 -이 작업은 [AWS Serverless Application Model](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html) 사용자가 제공하는 [CloudFormation 템플릿](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html) 또는 템플릿을 AWS 기반으로에 CloudFormation 스택을 생성합니다. 자세한 내용은 [CloudFormation 스택 배포](deploy-action-cfn.md) 단원을 참조하십시오.
+ Amazon ECS에 배포 - 이 작업은 사용자가 제공하는 [작업 정의](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) 파일을 등록합니다. 자세한 내용은 [워크플로를 사용하여 Amazon ECS에 배포](deploy-action-ecs.md) 섹션을 참조하세요.
+ Kubernetes 클러스터에 배포 - 이 작업은 Amazon Elastic Kubernetes Service 클러스터에 애플리케이션을 배포합니다. 자세한 내용은 [워크플로를 사용하여 Amazon EKS에 배포](deploy-action-eks.md) 단원을 참조하십시오.
+ AWS CDK 배포 -이 작업은 [AWS CDK 앱을](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_concepts)에 배포합니다 AWS. 자세한 내용은 [워크플로를 사용하여 AWS CDK 앱 배포](cdk-dep-action.md) 단원을 참조하십시오.
**참고**
리소스를 배포할 수 있는 다른 CodeCatalyst 작업이 있지만 *배포* 정보가 **환경** 페이지에 표시되지 않으므로 배포 작업으로 간주되지 않습니다. **환경** 페이지 및 배포 보기에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [배포 정보 보기](deploy-view-deployment-info.md) 섹션을 참조하세요.
## 작업 배포의 이점
워크플로 내에서 배포 작업을 사용하면 다음과 같은 이점이 있습니다.
+ **배포 기록** - 배포 기록을 확인하여 배포된 소프트웨어의 변경 사항을 관리하고 전달할 수 있습니다.
+ **추적성** - CodeCatalyst 콘솔을 통해 배포 상태를 추적하고 각 애플리케이션 개정이 배포된 시기와 위치를 확인합니다.
+ **롤백** - 오류가 있는 경우 배포를 자동으로 롤백합니다. 배포 롤백을 활성화하도록 경보를 구성할 수도 있습니다.
+ **모니터링** - 워크플로의 다양한 단계를 거치면서 배포를 관찰합니다.
+ **다른 CodeCatalyst 기능과의 통합** - 소스 코드를 저장한 다음 빌드, 테스트 및 배포합니다.
## 작업을 배포하는 대안
배포 작업은 이전 섹션에 설명된 이점을 제공하므로 사용할 필요가 없습니다. 대신 다음 [CodeCatalyst 작업](workflows-actions.md#workflows-actions-types-cc)을 사용할 수 있습니다.
+ **빌드** 작업입니다.
일반적으로 해당 배포 작업이 없는 대상에 배포하려는 경우 또는 배포 절차를 더 잘 제어하려는 경우 빌드 작업을 사용합니다. 빌드 작업을 사용하여 리소스를 배포하는 방법에 대한 자세한 내용은 [워크플로로 빌드하기](build-workflow-actions.md)를 참조하세요.
+ **GitHub Action**.
CodeCatalyst 워크플로 내에서 [GitHub 작업](workflows-actions.md#workflows-actions-types-github)을 사용하여 애플리케이션 및 리소스를 배포할 수 있습니다(CodeCatalyst 작업 대신). CodeCatalyst 워크플로 내에서 GitHub Actions를 사용하는 방법에 대한 자세한 내용은 [GitHub Actions와 통합](integrations-github-actions.md) 섹션을 참조하세요.
CodeCatalyst 워크플로를 사용하지 않으려면 다음 AWS 서비스를 사용하여 애플리케이션을 배포할 수도 있습니다.
+ AWS CodeDeploy - [ CodeDeploy란 무엇인가요?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)를 참조하세요.
+ AWS CodeBuild 및 AWS CodePipeline - [란 무엇입니까 AWS CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)를 참조하세요. 및 [란 무엇입니까 AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ CloudFormation - [란 무엇입니까 CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)를 참조하세요.
복잡한 엔터프라이즈 배포에는 CodeDeploy, CodeBuild, CodePipeline 및 CloudFormation 서비스를 사용합니다.
**Topics**
+ [애플리케이션을 배포하려면 어떻게 해야 하나요?](#deploy-concepts)
+ [배포 작업 목록](#deploy-concepts-action-supported)
+ [작업 배포의 이점](#deploy-concepts-why-use)
+ [작업을 배포하는 대안](#deploy-concepts-alternatives)
+ [워크플로를 사용하여 Amazon ECS에 배포](deploy-action-ecs.md)
+ [워크플로를 사용하여 Amazon EKS에 배포](deploy-action-eks.md)
+ [CloudFormation 스택 배포](deploy-action-cfn.md)
+ [워크플로를 사용하여 AWS CDK 앱 배포](cdk-dep-action.md)
+ [워크플로를 사용하여 AWS CDK 앱 부트스트래핑](cdk-boot-action.md)
+ [워크플로를 사용하여 Amazon S3에 파일 게시](s3-pub-action.md)
+ [AWS 계정 및 VPCs에 배포](deploy-environments.md)
+ [워크플로 다이어그램에 앱 URL 표시](deploy-app-url.md)
+ [배포 대상 제거](deploy-remove-target.md)
+ [커밋별 배포 상태 추적](track-changes.md)
+ [배포 로그 보기](deploy-deployment-logs.md)
+ [배포 정보 보기](deploy-view-deployment-info.md)
# 워크플로를 사용하여 Amazon ECS에 배포
이 섹션에서는 CodeCatalyst 워크플로를 사용하여 컨테이너화된 애플리케이션을 Amazon Elastic Container Service 클러스터에 배포하는 방법을 설명합니다. 이렇게 하려면 워크플로에 **Amazon ECS에 배포** 작업을 추가해야 합니다. 이 작업은 사용자가 제공하는 [작업 정의](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) 파일을 등록합니다. 등록 시 작업 정의는 [Amazon ECS 클러스터](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters)에서 실행되는 [Amazon ECS 서비스](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)에 의해 인스턴스화됩니다. "작업 정의 설명"은 Amazon ECS에 애플리케이션을 배포하는 것과 동일합니다.
이 작업을 사용하려면 Amazon ECS 클러스터, 서비스 및 작업 정의 파일이 준비되어 있어야 합니다.
Amazon ECS에 대해 자세히 알아보려면 *Amazon Elastic Container Service 개발자 안내서*를 참조하세요.
**작은 정보**
**Amazon ECS에 배포** 작업을 사용하는 방법을 보여주는 자습서는 [자습서: Amazon ECS에 애플리케이션 배포](deploy-tut-ecs.md) 섹션을 참조하세요.
**작은 정보**
**Amazon ECS에 배포** 작업의 작업 예시를 보려면 **Node.js API with AWS Fargate** 또는 **Java API with AWS Fargate** 블루프린트로 프로젝트를 생성합니다. 자세한 내용은 [블루프린트를 사용하여 프로젝트 생성](projects-create.md#projects-create-console-template) 섹션을 참조하세요.
**Topics**
+ ['Amazon ECS에 배포' 작업에 사용되는 런타임 이미지](#deploy-action-ecs-runtime)
+ [자습서: Amazon ECS에 애플리케이션 배포](deploy-tut-ecs.md)
+ ['Amazon ECS에 배포' 작업 추가](deploy-action-ecs-adding.md)
+ ['Amazon ECS에 배포' 변수](deploy-action-ecs-variables.md)
+ ['Amazon ECS에 배포' 작업 YAML](deploy-action-ref-ecs.md)
## 'Amazon ECS에 배포' 작업에 사용되는 런타임 이미지
**Amazon ECS에 배포** 작업은 [2022년 11월 이미지](build-images.md#build.previous-image)에서 실행됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 섹션을 참조하세요.
# 자습서: Amazon ECS에 애플리케이션 배포
이 자습서에서는 워크플로, Amazon ECS 및 기타 몇 가지 AWS 서비스를 사용하여 Amazon Elastic Container Service(Amazon ECS)에 서버리스 애플리케이션을 배포하는 방법을 알아봅니다. 배포된 애플리케이션은 Apache 웹 서버 Docker 이미지를 기반으로 구축된 간단한 Hello World 웹 사이트입니다. 자습서에서는 클러스터 설정과 같은 필수 준비 작업을 안내한 다음 애플리케이션을 빌드하고 배포하기 위한 워크플로를 생성하는 방법을 설명합니다.
**작은 정보**
이 자습서를 진행하는 대신 전체 Amazon ECS 설정을 수행하는 블루프린트를 사용할 수 있습니다. **Node.js API with AWS Fargate** 또는 **Java API with AWS Fargate** 블루프린트를 사용해야 합니다. 자세한 내용은 [블루프린트를 사용하여 프로젝트 생성](projects-create.md#projects-create-console-template) 섹션을 참조하세요.
**Topics**
+ [사전 조건](#deploy-tut-ecs-prereqs)
+ [1단계: AWS 사용자 설정 및 AWS CloudShell](#deploy-tut-ecs-user-cloudshell)
+ [2단계: Amazon ECS에 자리 표시자 애플리케이션 배포](#deploy-tut-ecs-placeholder)
+ [3단계: Amazon ECR 이미지 리포지토리 생성](#deploy-tut-ecs-ecr)
+ [4단계: AWS 역할 생성](#deploy-tut-ecs-build-deploy-roles)
+ [5단계: CodeCatalyst에 AWS 역할 추가](#deploy-tut-ecs-import-roles)
+ [6단계: 소스 리포지토리 생성](#deploy-tut-ecs-source-repo)
+ [7단계: 소스 파일 추가](#deploy-tut-ecs-source-files)
+ [8단계: 워크플로 생성 및 실행](#deploy-tut-ecs-workflow)
+ [9단계: 소스 파일 변경](#deploy-tut-ecs-change)
+ [정리](#deploy-tut-ecs-cleanup)
## 사전 조건
시작하기 전:
+ 연결된 AWS 계정이 있는 CodeCatalyst **스페이스**가 필요합니다. 자세한 내용은 [스페이스 생성](spaces-create.md) 단원을 참조하십시오.
+ 스페이스에는 다음과 같은 빈 프로젝트가 필요합니다.
```
codecatalyst-ecs-project
```
**처음부터 시작** 옵션을 사용하여 이 프로젝트를 생성합니다.
자세한 내용은 [Amazon CodeCatalyst에서 빈 프로젝트 생성](projects-create.md#projects-create-empty) 섹션을 참조하세요.
+ 프로젝트에는 다음과 같은 CodeCatalyst **환경**이 필요합니다.
```
codecatalyst-ecs-environment
```
다음과 같이 이 환경을 구성합니다.
+ **비프로덕션**과 같은 유형을 선택합니다.
+ AWS 계정에 연결합니다.
+ **기본 IAM 역할**의 경우 아무 역할이나 선택합니다. 나중에 다른 역할을 지정합니다.
자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 단원을 참조하십시오.
## 1단계: AWS 사용자 설정 및 AWS CloudShell
이 자습서의 첫 번째 단계는에서 사용자를 생성하고이 사용자로 인스턴스를 AWS IAM Identity Center AWS CloudShell 시작하는 것입니다. 이 자습서 기간 동안 CloudShell은 개발 컴퓨터이며 AWS 리소스와 서비스를 구성하는 곳입니다. 자습서를 완료한 후 이 사용자를 삭제합니다.
**참고**
이 자습서에는 루트 사용자를 사용하지 마세요. 별도의 사용자를 생성해야 합니다. 그렇지 않으면 나중에 AWS Command Line Interface (CLI)에서 작업을 수행할 때 문제가 발생할 수 있습니다.
IAM Identity Center 사용자 및 CloudShell에 대한 자세한 내용은 *AWS IAM Identity Center 사용 설명서* 및 *AWS CloudShell 사용 설명서*를 참조하세요.
**IAM Identity Center 사용자를 생성하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/) AWS IAM Identity Center 콘솔을 엽니다.
**참고**
CodeCatalyst 스페이스에 AWS 계정 연결된를 사용하여 로그인해야 합니다. 스페이스로 이동하여 **AWS 계정** 탭을 선택하고 연결된 계정을 확인할 수 있습니다. 자세한 내용은 [스페이스 생성](spaces-create.md) 섹션을 참조하세요.
1. 탐색 창에서 **Users**와 **Add user**를 차례대로 선택합니다.
1. **사용자 이름**에 다음을 입력합니다.
```
CodeCatalystECSUser
```
1. **암호**에서 **이 사용자와 공유할 수 있는 일회용 암호 생성**을 선택합니다.
1. **이메일 주소** 및 **이메일 주소 확인**에 IAM Identity Center에 아직 없는 이메일 주소를 입력합니다.
1. **이름** 및 **성**에 다음을 입력합니다.
```
CodeCatalystECSUser
```
1. **표시 이름**에 자동으로 생성된 이름을 유지합니다.
```
CodeCatalystECSUser CodeCatalystECSUser
```
1. **다음**을 선택합니다.
1. **그룹에 사용자 추가** 페이지에서 **다음**을 선택합니다.
1. **검토 및 사용자 추가** 페이지에서 정보를 검토하고 **사용자 추가**를 선택합니다.
**일회용 암호** 대화 상자가 나타납니다.
1. **복사**를 선택한 다음 AWS 액세스 포털 URL 및 일회용 암호를 포함하여 로그인 정보를 붙여넣습니다.
1. **닫기**를 선택하세요.
**권한 집합을 생성하려면**
이 권한 세트를 나중에 `CodeCatalystECSUser`에 할당합니다.
1. 탐색 창에서 **권한 세트**를 선택한 다음 **권한 세트 생성**을 선택합니다.
1. **사전 정의된 권한 세트**를 선택하고 **AdministratorAccess**를 선택합니다. 이 정책은 모든 AWS 서비스에 대한 전체 권한을 제공합니다.
1. **다음**을 선택합니다.
1. **권한 세트 이름**에 다음을 입력합니다.
```
CodeCatalystECSPermissionSet
```
1. **다음**을 선택합니다.
1. **검토 및 생성** 페이지에서 정보를 검토하고 **생성**을 선택합니다.
**이 권한 세트를 CodeCatalystECSUser에게 할당하려면**
1. 탐색 창에서 **AWS 계정**를 선택한 다음 현재 로그인 AWS 계정 한 옆의 확인란을 선택합니다.
1. **사용자 또는 그룹 할당**을 선택합니다.
1. **사용자** 탭을 선택합니다.
1. `CodeCatalystECSUser` 옆의 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. `CodeCatalystECSPermissionSet` 옆의 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. 정보를 검토하고 **제출**을 선택합니다.
이제 `CodeCatalystECSUser` 및를 `CodeCatalystECSPermissionSet`에 할당하여 함께 AWS 계정바인딩했습니다.
**로그아웃했다가 CodeCatalystECSUser로 다시 로그인하려면**
1. 로그아웃하기 전에에 대한 AWS 액세스 포털 URL과 사용자 이름 및 일회용 암호가 있는지 확인합니다`CodeCatalystECSUser`. 이전에 이 정보를 텍스트 편집기에 복사했어야 합니다.
**참고**
이 정보가 없는 경우 IAM Identity Center의 `CodeCatalystECSUser` 세부 정보 페이지로 이동하여 **암호 재설정**, **일회용 암호 생성 [...]**을 선택한 후 **암호 재설정**을 다시 선택하면 화면에 해당 정보가 표시됩니다.
1. 로그아웃합니다 AWS.
1. AWS 액세스 포털 URL을 브라우저의 주소 표시줄에 붙여 넣습니다.
1. `CodeCatalystECSUser`의 사용자 이름과 일회용 암호로 로그인합니다.
1. **새 암호**에서 암호를 입력하고 **새 암호 설정**을 선택합니다.
화면에 **AWS 계정** 상자가 나타납니다.
1. **AWS 계정**를 선택한 다음 `CodeCatalystECSUser` 사용자 및 권한 세트를 할당 AWS 계정 한의 이름을 선택합니다.
1. `CodeCatalystECSPermissionSet` 옆에 있는 **Management Console**을 선택합니다.
가 AWS Management Console 나타납니다. 이제 적절한 권한으로 `CodeCatalystECSUser`에 로그인되었습니다.
**AWS CloudShell 인스턴스를 시작하려면**
1. 의 상단 탐색 모음`CodeCatalystECSUser`에서 AWS 아이콘(![\[AWS icon\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/deploy/aws-logo.png))을 선택합니다.
의 기본 페이지가 AWS Management Console 나타납니다.
1. 상단 탐색 모음에서 AWS CloudShell 아이콘(![\[CloudShell icon\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/deploy/CloudShell.png))을 선택합니다.
CloudShell이 열립니다. CloudShell 환경이 생성되는 동안 기다립니다.
**참고**
CloudShell 아이콘이 보이지 않는 경우 [CloudShell에서 지원하는 리전](https://docs.aws.amazon.com/cloudshell/latest/userguide/faq-list.html#regions-available)에 있는지 확인하세요. 이 자습서에서는 사용자가 미국 서부(오리건) 리전에 있다고 가정합니다.
**AWS CLI 가 설치되었는지 확인하려면**
1. CloudShell 터미널에서 다음을 입력합니다.
```
aws --version
```
1. 버전이 나타나는지 확인합니다.
AWS CLI 는 현재 사용자에 대해 이미 구성되어 `CodeCatalystECSUser`있으므로 일반적으로처럼 AWS CLI 키와 자격 증명을 구성할 필요가 없습니다.
## 2단계: Amazon ECS에 자리 표시자 애플리케이션 배포
이 섹션에서는 자리 표시자 애플리케이션을 Amazon ECS에 수동으로 배포합니다. 이 자리 표시자 애플리케이션은 워크플로에 의해 배포된 Hello World 애플리케이션으로 대체됩니다. 자리 표시자 애플리케이션은 Apache Web Server입니다.
Amazon ECS에 대해 자세히 알아보려면 *Amazon Elastic Container Service 개발자 안내서*를 참조하세요.
자리 표시자 애플리케이션을 배포하려면 다음 일련의 절차를 완료합니다.
**태스크 실행 역할을 생성하는 방법**
이 역할은 Amazon ECS에 사용자를 대신하여 API를 호출할 수 있는 AWS Fargate 권한을 부여합니다.
1. 신뢰 정책 생성:
1. 에 다음 명령을 AWS CloudShell입력합니다.
```
cat > codecatalyst-ecs-trust-policy.json
```
CloudShell 터미널에 깜박이는 프롬프트가 나타납니다.
1. 프롬프트에서 다음 코드를 입력합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ecs-tasks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 커서를 마지막 중괄호(`}`) 뒤에 놓습니다.
1. **Enter**를 누른 다음 **Ctrl\$1d**를 눌러 파일을 저장하고 cat을 종료합니다.
1. 태스크 실행 역할을 생성합니다.
```
aws iam create-role \
--role-name codecatalyst-ecs-task-execution-role \
--assume-role-policy-document file://codecatalyst-ecs-trust-policy.json
```
1. AWS 관리형 `AmazonECSTaskExecutionRolePolicy` 정책을 역할에 연결합니다.
```
aws iam attach-role-policy \
--role-name codecatalyst-ecs-task-execution-role \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
```
1. 역할의 세부 정보를 표시합니다.
```
aws iam get-role \
--role-name codecatalyst-ecs-task-execution-role
```
1. 역할의 `"Arn":` 값을 기록해 둡니다. 예시: `arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role`. 나중에 이 Amazon 리소스 이름(ARN)이 필요합니다.
**Amazon ECS 클러스터를 생성하려면**
이 클러스터에는 Apache 자리 표시자 애플리케이션과 이후 Hello World 애플리케이션이 포함됩니다.
1. 에서 빈 클러스터를 `CodeCatalystECSUser` AWS CloudShell생성합니다.
```
aws ecs create-cluster --cluster-name codecatalyst-ecs-cluster
```
1. (선택 사항) 클러스터가 성공적으로 생성되었는지 확인합니다.
```
aws ecs list-clusters
```
`codecatalyst-ecs-cluster` 클러스터의 ARN이 목록에 나타나 성공적으로 생성되었음을 나타냅니다.
**태스크 정의 파일을 생성하는 방법**
태스크 정의 파일은 DockerHub에서 가져온 [Apache 2.4 웹 서버](https://hub.docker.com/_/httpd) Docker 이미지(`httpd:2.4`)를 실행함을 나타냅니다.
1. 의 `CodeCatalystECSUser`에서 작업 정의 파일을 AWS CloudShell생성합니다.
```
cat > taskdef.json
```
1. 프롬프트에서 다음 코드를 붙여넣습니다.
```
{
"executionRoleArn": "arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role",
"containerDefinitions": [
{
"name": "codecatalyst-ecs-container",
"image": "httpd:2.4",
"essential": true,
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
]
}
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "256",
"family": "codecatalyst-ecs-task-def",
"memory": "512",
"networkMode": "awsvpc"
}
```
앞의 코드에서 *arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role*을
[태스크 실행 역할을 생성하는 방법](#deploy-tut-ecs-create-task-execution-role)에서 기록한 태스크 실행 역할의 ARN으로 바꿉니다.
1. 커서를 마지막 중괄호(`}`) 뒤에 놓습니다.
1. **Enter**를 누른 다음 **Ctrl\$1d**를 눌러 파일을 저장하고 cat을 종료합니다.
**Amazon ECS로 태스크 정의 파일을 등록하려면**
1. 의 `CodeCatalystECSUser`에서 작업 정의를 AWS CloudShell등록합니다.
```
aws ecs register-task-definition \
--cli-input-json file://taskdef.json
```
1. (선택 사항) 태스크 정의가 등록되었는지 확인합니다.
```
aws ecs list-task-definitions
```
`codecatalyst-ecs-task-def` 태스크 정의가 목록에 나타나야 합니다.
**Amazon ECS 서비스를 생성하는 방법**
Amazon ECS 서비스는 Apache 자리 표시자 애플리케이션과 이후 Hello World 애플리케이션의 태스크(및 관련 Docker 컨테이너)를 실행합니다.
1. `CodeCatalystECSUser`로서 아직 하지 않았다면 Amazon Elastic Container Service 콘솔로 전환합니다.
1. 앞서 생성한 `codecatalyst-ecs-cluster` 클러스터를 선택합니다.
1. **서비스** 탭에서 **생성**을 선택합니다.
1. **생성** 페이지에서 다음을 수행합니다.
1. 다음에 나열된 설정을 제외한 모든 기본 설정을 유지합니다.
1. **시작 유형**에서 **FARGATE**를 선택합니다.
1. **태스크 정의**의 **패밀리** 드롭다운 목록에서 다음을 선택합니다.
`codecatalyst-ecs-task-def`
1. **서비스 이름**에 다음을 입력합니다.
```
codecatalyst-ecs-service
```
1. **원하는 태스크**에 다음을 입력합니다.
```
3
```
이 자습서에서는 각 작업이 단일 Docker 컨테이너를 시작합니다.
1. **네트워킹** 섹션을 확장합니다.
1. **VPC**에서 VPC를 선택합니다.
1. **서브넷**에서 서브넷을 선택합니다.
**참고**
서브넷을 하나만 지정합니다. 이 자습서에 필요한 것은 이것뿐입니다.
**참고**
VPC와 서브넷이 없는 경우 생성합니다. *Amazon VPC 사용 설명서*의 [VPC에 서브넷 생성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet)을 참조하여 [VPC를 생성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC)합니다.
1. **보안 그룹**에서 **새 보안 그룹 생성**을 선택하고 다음을 수행합니다.
1. **보안 그룹 이름**에 다음을 입력합니다.
```
codecatalyst-ecs-security-group
```
1. **보안 그룹 설명**에 다음을 입력합니다.
```
CodeCatalyst ECS security group
```
1. **규칙 추가**를 선택합니다. **유형**에서 **HTTP**를 선택하고 **소스**에서 **Anywhere**를 선택합니다.
1. 하단에서 **생성**을 선택합니다.
1. 서비스가 생성되는 동안 기다립니다. 몇 분 정도 소요될 수 있습니다.
1. **태스크** 탭을 선택한 후 새로 고침 버튼을 선택합니다. 세 태스크 모두에서 **마지막 상태** 열이 **실행 중**으로 설정되어 있는지 확인합니다.
**(선택 사항) Apache 자리 표시자 애플리케이션이 실행 중인지 확인하려면**
1. **태스크** 탭에서 세 가지 작업 중 하나를 선택합니다.
1. **퍼블릭 IP** 필드에서 **개방형 주소**를 선택합니다.
`It Works!` 페이지가 나타납니다. 이는 Amazon ECS 서비스가 Apache 이미지로 Docker 컨테이너를 시작한 태스크를 성공적으로 시작했음을 나타냅니다.
자습서의 이 시점에서 Amazon ECS 클러스터, 서비스 및 태스크 정의와 Apache 자리 표시자 애플리케이션을 수동으로 배포했습니다. 이러한 모든 항목이 준비되면 이제 Apache 자리 표시자 애플리케이션을 자습서의 Hello World 애플리케이션으로 대체하는 워크플로를 생성할 준비가 된 것입니다.
## 3단계: Amazon ECR 이미지 리포지토리 생성
이 섹션에서는 Amazon Elastic Container Registry(Amazon ECR)에서 프라이빗 이미지 리포지토리를 생성합니다. 이 리포지토리에는 이전에 배포한 Apache 자리 표시자 이미지를 대체하는 자습서의 Docker 이미지가 저장됩니다.
Amazon ECR에 대한 자세한 내용은 *Amazon Elastic Container Registry 사용 설명서*를 참조합니다.
**Amazon ECR에서 이미지 리포지토리를 생성하려면**
1. 에서 Amazon ECR에 빈 리포지토리를 `CodeCatalystECSUser` AWS CloudShell생성합니다.
```
aws ecr create-repository --repository-name codecatalyst-ecs-image-repo
```
1. Amazon ECR 리포지토리의 세부 정보를 표시합니다.
```
aws ecr describe-repositories \
--repository-names codecatalyst-ecs-image-repo
```
1. `“repositoryUri”:` 값을 기록해 둡니다. 예시: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`.
나중에 워크플로에 리포지토리를 추가할 때 필요합니다.
## 4단계: AWS 역할 생성
이 섹션에서는 CodeCatalyst 워크플로가 작동하는 데 필요한 AWS IAM 역할을 생성합니다. 이러한 역할은 다음과 같습니다.
+ **빌드 역할** - CodeCatalyst 빌드 작업(워크플로 내)에 AWS 계정에 액세스하고 Amazon ECR 및 Amazon EC2에 쓸 수 있는 권한을 부여합니다.
+ **역할 배포** - CodeCatalyst **ECS에 배포** 작업(워크플로 내)에 AWS 계정, Amazon ECS 및 기타 몇 가지 AWS 서비스에 액세스할 수 있는 권한을 부여합니다.
IAM 역할에 대한 자세한 내용은 *AWS Identity and Access Management 사용 설명서*의 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 섹션을 참조하세요.
**참고**
시간을 절약하기 위해 이전에 나열한 두 역할 대신 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할이라는 단일 역할을 생성할 수 있습니다. 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에는 보안 위험을 초래할 수 있는 매우 광범위한 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다. 이 자습서에서는 이전에 나열된 두 역할을 생성하고 있다고 가정합니다.
빌드 및 배포 역할을 생성하려면 AWS Management Console 또는를 사용할 수 있습니다 AWS CLI.
------
#### [ AWS Management Console ]
빌드 및 배포 역할을 생성하려면 다음 절차 시리즈를 완료합니다.
**빌드 역할을 생성하려면**
1. 역할에 대한 정책을 다음과 같이 생성합니다.
1. 에 로그인합니다 AWS.
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **Policies**를 선택합니다.
1. **정책 생성**을 선택합니다.
1. **JSON** 탭을 선택합니다.
1. 기존 코드를 삭제합니다.
1. 다음 코드를 붙여넣습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:*",
"ec2:*"
],
"Resource": "*"
}
]
}
```
------
**참고**
역할을 처음 사용하여 워크플로 작업을 실행할 때 리소스 정책 문에서 와일드카드를 사용한 다음, 사용 가능한 리소스 이름으로 정책 범위를 좁힙니다.
```
"Resource": "*"
```
1. **다음: 태그**를 선택합니다.
1. **다음: 검토**를 선택합니다.
1. **이름**에 다음과 같이 입력합니다.
```
codecatalyst-ecs-build-policy
```
1. **정책 생성**을 선택합니다.
이제 권한 정책을 생성했습니다.
1. 다음과 같이 빌드 역할을 생성합니다.
1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. **사용자 지정 신뢰 정책**을 선택합니다.
1. 기존 사용자 지정 신뢰 정책을 삭제합니다.
1. 다음 사용자 지정 신뢰 정책을 추가합니다.
1. **다음**을 선택합니다.
1. **권한 정책**에서 `codecatalyst-ecs-build-policy`를 검색하고 해당 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **역할 이름**에 다음과 같이 입력합니다.
```
codecatalyst-ecs-build-role
```
1. **역할 설명**에 다음과 같이 입력합니다.
```
CodeCatalyst ECS build role
```
1. **역할 생성**을 선택합니다.
이제 신뢰 정책 및 권한 정책으로 빌드 역할을 생성했습니다.
1. 다음과 같이 빌드 역할 ARN을 가져옵니다.
1. 탐색 창에서 **역할**을 선택합니다.
1. 검색 상자에 방금 생성한 역할의 이름을 입력합니다(`codecatalyst-ecs-build-role`).
1. 목록에서 역할을 선택합니다.
역할의 **요약** 페이지가 나타납니다.
1. 상단에서 **ARN** 값을 복사합니다. 나중에 필요합니다.
**배포 역할을 생성하려면**
1. 역할에 대한 정책을 다음과 같이 생성합니다.
1. 에 로그인합니다 AWS.
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **Policies**를 선택합니다.
1. **정책 생성**을 선택하세요.
1. **JSON** 탭을 선택합니다.
1. 기존 코드를 삭제합니다.
1. 다음 코드를 붙여넣습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Action":[
"ecs:DescribeServices",
"ecs:CreateTaskSet",
"ecs:DeleteTaskSet",
"ecs:ListClusters",
"ecs:RegisterTaskDefinition",
"ecs:UpdateServicePrimaryTaskSet",
"ecs:UpdateService",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:DescribeRules",
"elasticloadbalancing:ModifyRule",
"lambda:InvokeFunction",
"lambda:ListFunctions",
"cloudwatch:DescribeAlarms",
"sns:Publish",
"sns:ListTopics",
"s3:GetObject",
"s3:GetObjectVersion",
"codedeploy:CreateApplication",
"codedeploy:CreateDeployment",
"codedeploy:CreateDeploymentGroup",
"codedeploy:GetApplication",
"codedeploy:GetDeployment",
"codedeploy:GetDeploymentGroup",
"codedeploy:ListApplications",
"codedeploy:ListDeploymentGroups",
"codedeploy:ListDeployments",
"codedeploy:StopDeployment",
"codedeploy:GetDeploymentTarget",
"codedeploy:ListDeploymentTargets",
"codedeploy:GetDeploymentConfig",
"codedeploy:GetApplicationRevision",
"codedeploy:RegisterApplicationRevision",
"codedeploy:BatchGetApplicationRevisions",
"codedeploy:BatchGetDeploymentGroups",
"codedeploy:BatchGetDeployments",
"codedeploy:BatchGetApplications",
"codedeploy:ListApplicationRevisions",
"codedeploy:ListDeploymentConfigs",
"codedeploy:ContinueDeployment"
],
"Resource":"*",
"Effect":"Allow"
},{"Action":[
"iam:PassRole"
],
"Effect":"Allow",
"Resource":"*",
"Condition":{"StringLike":{"iam:PassedToService":[
"ecs-tasks.amazonaws.com",
"codedeploy.amazonaws.com"
]
}
}
}]
}
```
------
**참고**
역할을 처음 사용하여 워크플로 작업을 실행할 때 리소스 정책 문의 와일드카드를 사용합니다. 그런 다음 사용 가능한 리소스 이름을 사용하여 정책의 범위를 좁힐 수 있습니다.
```
"Resource": "*"
```
1. **다음: 태그**를 선택합니다.
1. **다음: 검토**를 선택합니다.
1. **이름**에 다음과 같이 입력합니다.
```
codecatalyst-ecs-deploy-policy
```
1. **정책 생성**을 선택합니다.
이제 권한 정책을 생성했습니다.
1. 다음과 같이 배포 역할을 생성합니다.
1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. **사용자 지정 신뢰 정책**을 선택합니다.
1. 기존 사용자 지정 신뢰 정책을 삭제합니다.
1. 다음 사용자 지정 신뢰 정책을 추가합니다.
1. **다음**을 선택합니다.
1. **권한 정책**에서 `codecatalyst-ecs-deploy-policy`를 검색하고 해당 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **역할 이름**에 다음과 같이 입력합니다.
```
codecatalyst-ecs-deploy-role
```
1. **역할 설명**에 다음과 같이 입력합니다.
```
CodeCatalyst ECS deploy role
```
1. **역할 생성**을 선택합니다.
이제 신뢰 정책으로 배포 역할을 생성했습니다.
1. 다음과 같이 배포 역할 ARN을 가져옵니다.
1. 탐색 창에서 **역할**을 선택합니다.
1. 검색 상자에 방금 생성한 역할의 이름을 입력합니다(`codecatalyst-ecs-deploy-role`).
1. 목록에서 역할을 선택합니다.
역할의 **요약** 페이지가 나타납니다.
1. 상단에서 **ARN** 값을 복사합니다. 나중에 필요합니다.
------
#### [ AWS CLI ]
빌드 및 배포 역할을 생성하려면 다음 절차 시리즈를 완료합니다.
**두 역할에 대한 신뢰 정책을 생성하려면**
의 `CodeCatalystECSUser`에서 신뢰 정책 파일을 AWS CloudShell생성합니다.
1. 다음 파일을 생성합니다.
```
cat > codecatalyst-ecs-trust-policy.json
```
1. 터미널 프롬프트에서 다음 코드를 붙여넣습니다.
1. 커서를 마지막 중괄호(`}`) 뒤에 놓습니다.
1. **Enter**를 누른 다음 **Ctrl\$1d**를 눌러 파일을 저장하고 cat을 종료합니다.
**빌드 정책 및 빌드 역할을 생성하려면**
1. 다음 빌드 정책을 생성합니다.
1. `CodeCatalystECSUser`에서 로 빌드 정책 파일을 AWS CloudShell생성합니다.
```
cat > codecatalyst-ecs-build-policy.json
```
1. 프롬프트에서 다음 코드를 입력합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:*",
"ec2:*"
],
"Resource": "*"
}
]
}
```
------
1. 커서를 마지막 중괄호(`}`) 뒤에 놓습니다.
1. **Enter**를 누른 다음 **Ctrl\$1d**를 눌러 파일을 저장하고 cat을 종료합니다.
1. 빌드 정책을 AWS다음에 추가합니다.
```
aws iam create-policy \
--policy-name codecatalyst-ecs-build-policy \
--policy-document file://codecatalyst-ecs-build-policy.json
```
1. 명령 출력에서 와 같은 `"arn":` 값을 기록해 둡니다(예: `arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy`). 나중에 이 ARN이 필요합니다.
1. 빌드 역할을 생성하여 신뢰 정책에 연결합니다.
```
aws iam create-role \
--role-name codecatalyst-ecs-build-role \
--assume-role-policy-document file://codecatalyst-ecs-trust-policy.json
```
1. 빌드 정책을 빌드 역할에 연결합니다.
```
aws iam attach-role-policy \
--role-name codecatalyst-ecs-build-role \
--policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy
```
*arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy*가 앞서 언급한 빌드 정책의 ARN으로 대체되는 경우.
1. 빌드 역할의 세부 정보를 표시합니다.
```
aws iam get-role \
--role-name codecatalyst-ecs-build-role
```
1. 역할의 `"Arn":` 값을 기록해 둡니다. 예시: `arn:aws:iam::111122223333:role/codecatalyst-ecs-build-role`. 나중에 이 ARN이 필요합니다.
**배포 정책을 생성하고 역할을 배포하려면**
1. 배포 정책 생성:
1. 에서 배포 정책 파일을 AWS CloudShell생성합니다.
```
cat > codecatalyst-ecs-deploy-policy.json
```
1. 프롬프트에서 다음 코드를 입력합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Action":[
"ecs:DescribeServices",
"ecs:CreateTaskSet",
"ecs:DeleteTaskSet",
"ecs:ListClusters",
"ecs:RegisterTaskDefinition",
"ecs:UpdateServicePrimaryTaskSet",
"ecs:UpdateService",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:DescribeRules",
"elasticloadbalancing:ModifyRule",
"lambda:InvokeFunction",
"lambda:ListFunctions",
"cloudwatch:DescribeAlarms",
"sns:Publish",
"sns:ListTopics",
"s3:GetObject",
"s3:GetObjectVersion",
"codedeploy:CreateApplication",
"codedeploy:CreateDeployment",
"codedeploy:CreateDeploymentGroup",
"codedeploy:GetApplication",
"codedeploy:GetDeployment",
"codedeploy:GetDeploymentGroup",
"codedeploy:ListApplications",
"codedeploy:ListDeploymentGroups",
"codedeploy:ListDeployments",
"codedeploy:StopDeployment",
"codedeploy:GetDeploymentTarget",
"codedeploy:ListDeploymentTargets",
"codedeploy:GetDeploymentConfig",
"codedeploy:GetApplicationRevision",
"codedeploy:RegisterApplicationRevision",
"codedeploy:BatchGetApplicationRevisions",
"codedeploy:BatchGetDeploymentGroups",
"codedeploy:BatchGetDeployments",
"codedeploy:BatchGetApplications",
"codedeploy:ListApplicationRevisions",
"codedeploy:ListDeploymentConfigs",
"codedeploy:ContinueDeployment"
],
"Resource":"*",
"Effect":"Allow"
},{"Action":[
"iam:PassRole"
],
"Effect":"Allow",
"Resource":"*",
"Condition":{"StringLike":{"iam:PassedToService":[
"ecs-tasks.amazonaws.com",
"codedeploy.amazonaws.com"
]
}
}
}]
}
```
------
**참고**
역할을 처음 사용하여 워크플로 작업을 실행할 때 리소스 정책 문에서 와일드카드를 사용한 다음, 사용 가능한 리소스 이름으로 정책 범위를 좁힙니다.
```
"Resource": "*"
```
1. 커서를 마지막 중괄호(`}`) 뒤에 놓습니다.
1. **Enter**를 누른 다음 **Ctrl\$1d**를 눌러 파일을 저장하고 cat을 종료합니다.
1. 배포 정책을 AWS다음에 추가합니다.
```
aws iam create-policy \
--policy-name codecatalyst-ecs-deploy-policy \
--policy-document file://codecatalyst-ecs-deploy-policy.json
```
1. 명령 출력에서 와 같은 `"arn":` 값을 기록해 둡니다(예: `arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy`). 나중에 이 ARN이 필요합니다.
1. 빌드 역할을 생성하여 신뢰 정책에 연결합니다.
```
aws iam create-role \
--role-name codecatalyst-ecs-deploy-role \
--assume-role-policy-document file://codecatalyst-ecs-trust-policy.json
```
1. 배포 정책을 배포 역할에 연결합니다. 여기서 *arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy*는 앞서 언급한 배포 정책의 ARN으로 대체됩니다.
```
aws iam attach-role-policy \
--role-name codecatalyst-ecs-deploy-role \
--policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy
```
1. 배포 역할의 세부 정보를 표시합니다.
```
aws iam get-role \
--role-name codecatalyst-ecs-deploy-role
```
1. 역할의 `"Arn":` 값을 기록해 둡니다. 예시: `arn:aws:iam::111122223333:role/codecatalyst-ecs-deploy-role`. 나중에 이 ARN이 필요합니다.
------
## 5단계: CodeCatalyst에 AWS 역할 추가
이 단계에서는 빌드 역할(`codecatalyst-ecs-build-role`)을 추가하고 스페이스의 CodeCatalyst 계정 연결에 역할(`codecatalyst-ecs-deploy-role`)을 배포합니다.
**계정 연결에 빌드 및 배포 역할을 추가하려면**
1. CodeCatalyst에서 스페이스로 이동합니다.
1. **AWS 계정**을 선택합니다. 계정 연결 목록이 나타납니다.
1. 빌드 및 배포 역할을 생성한 계정을 나타내는 AWS 계정 연결을 선택합니다.
1. **관리 콘솔에서 역할 AWS 관리를** 선택합니다.
**Amazon CodeCatalyst 스페이스에 IAM 역할 추가** 페이지가 나타납니다. 페이지에 액세스하려면 로그인해야 할 수 있습니다.
1. **IAM에서 생성한 기존 역할 추가**를 선택합니다.
드롭다운 목록이 나타납니다. 목록에는 `codecatalyst-runner.amazonaws.com` 및 `codecatalyst.amazonaws.com` 서비스 위탁자가 포함된 신뢰 정책이 있는 모든 IAM 역할이 표시됩니다.
1. 드롭다운 목록에서 `codecatalyst-ecs-build-role`을 선택하고 **역할 추가**를 선택합니다.
**참고**
`The security token included in the request is invalid`가 표시되면 적절한 권한이 없기 때문일 수 있습니다. 이 문제를 해결하려면 CodeCatalyst 스페이스를 생성할 때 사용한 AWS 계정으로 다시 로그인 AWS 하면에서 로그아웃합니다.
1. **IAM 역할 추가**를 선택하고 **IAM에서 생성한 기존 역할 추가**를 선택한 다음 드롭다운 목록에서 `codecatalyst-ecs-deploy-role`을 선택합니다. [**Add role**]을 선택합니다.
이제 스페이스에 빌드 및 배포 역할을 추가했습니다.
1. **Amazon CodeCatalyst 표시 이름**의 값을 복사합니다. 워크플로를 생성할 때 나중에 이 값이 필요합니다.
## 6단계: 소스 리포지토리 생성
이 단계에서는 CodeCatalyst에 소스 리포지토리를 생성합니다. 이 리포지토리는 작업 정의 파일과 같은 자습서의 소스 파일을 저장합니다.
소스 리포지토리에 대한 자세한 정보는 [소스 리포지토리 생성](source-repositories-create.md) 섹션을 참조하세요.
**소스 리포지토리를 생성하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-ecs-project` 프로젝트로 이동합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. **리포지토리 추가**를 선택하고 **리포지토리 생성**을 선택합니다.
1. **리포지토리 이름**에 다음과 같이 입력합니다.
```
codecatalyst-ecs-source-repository
```
1. **생성(Create)**을 선택합니다.
## 7단계: 소스 파일 추가
이 섹션에서는 Hello World 소스 파일을 CodeCatalyst 리포지토리 `codecatalyst-ecs-source-repository`에 추가합니다. 다음과 같이 구성됩니다.
+ `index.html` 파일 - 브라우저에 Hello World 메시지를 표시합니다.
+ Dockerfile - Docker 이미지에 사용할 기본 이미지와 Docker 명령으로 적용할 기본 이미지를 설명합니다.
+ `taskdef.json` 파일 - 클러스터에서 작업을 시작할 때 사용할 Docker 이미지를 정의합니다.
폴더의 구조는 다음과 같습니다.
```
.
|— public-html
| |— index.html
|— Dockerfile
|— taskdef.json
```
**참고**
다음 지침은 CodeCatalyst 콘솔을 사용하여 파일을 추가하는 방법을 보여주지만 원하는 경우 Git을 사용할 수 있습니다. 자세한 내용은 [소스 리포지토리 복제](source-repositories-clone.md)을 참조하세요.
**Topics**
+ [index.html](#deploy-tut-ecs-source-files-index)
+ [Dockerfile](#deploy-tut-ecs-source-files-dockerfile)
+ [taskdef.json](#deploy-tut-ecs-source-files-taskdef)
### index.html
`index.html` 파일에 브라우저에 Hello World 메시지가 표시됩니다.
**index.html 파일을 추가하려면**
1. CodeCatalyst 콘솔에서 `codecatalyst-ecs-source-repository` 소스 리포지토리로 이동합니다.
1. **파일**에서 **파일 생성**을 선택합니다.
1. **파일 이름**에 다음과 같이 입력합니다.
```
public-html/index.html
```
**중요**
동일한 이름의 폴더를 만들려면 `public-html/` 접두사를 포함해야 합니다. `index.html`이 폴더에 있을 것으로 예상됩니다.
1. 다음 코드를 텍스트 상자에 입력합니다.
```
Hello World
Hello World
```
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
`index.html`은 `public-html` 폴더의 리포지토리에 추가됩니다.
### Dockerfile
Dockerfile은 사용할 기본 Docker 이미지와 적용할 Docker 명령을 설명합니다. Dockerfile에 대한 자세한 내용은 [Dockerfile 참조](https://docs.docker.com/engine/reference/builder/)를 참조하세요.
여기에 지정된 Dockerfile은 Apache 2.4 기본 이미지(`httpd`)를 사용함을 나타냅니다. 또한 `index.html` 소스 파일을 웹 페이지를 제공하는 Apache 서버의 폴더에 복사하는 방법도 포함되어 있습니다. Dockerfile의 `EXPOSE` 지침은 컨테이너가 포트 80에서 수신 중임을 Docker에게 알립니다.
**Dockerfile을 추가하려면**
1. 소스 리포지토리에서 **파일 생성**을 선택합니다.
1. **파일 이름**에 다음과 같이 입력합니다.
```
Dockerfile
```
파일 확장자는 제외합니다.
**중요**
Dockerfile은 리포지토리의 루트 폴더에 있어야 합니다. 워크플로의 `Docker build` 명령은 해당 파일이 있을 것으로 예상합니다.
1. 다음 코드를 텍스트 상자에 입력합니다.
```
FROM httpd:2.4
COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html
EXPOSE 80
```
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
Dockerfile이 리포지토리에 추가됩니다.
### taskdef.json
이 단계에서 추가하는 `taskdef.json` 파일은 [2단계: Amazon ECS에 자리 표시자 애플리케이션 배포](#deploy-tut-ecs-placeholder)에서 이미 지정한 파일과 동일하며 다음과 같은 차이점이 있습니다.
`image:` 필드(`httpd:2.4`)에 하드코딩된 Docker 이미지 이름을 지정하는 대신, 여기서 태스크 정의는 몇 가지 변수를 사용하여 이미지(`$REPOSITORY_URI` 및 `$IMAGE_TAG`)를 나타냅니다. 이러한 변수는 이후 단계에서 워크플로를 실행할 때 워크플로의 빌드 작업에서 생성된 실제 값으로 대체됩니다.
태스크 정의 파라미터에 대한 자세한 정보는 *Amazon Elastic Container Service 개발자 안내서*의 [태스크 정의 파라미터](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html)를 참조하세요.
**taskdef.json 파일을 추가하려면**
1. 소스 리포지토리에서 **파일 생성**을 선택합니다.
1. **파일 이름**에 다음과 같이 입력합니다.
```
taskdef.json
```
1. 다음 코드를 텍스트 상자에 입력합니다.
```
{
"executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role",
"containerDefinitions": [
{
"name": "codecatalyst-ecs-container",
# The $REPOSITORY_URI and $IMAGE_TAG variables will be replaced
# by the workflow at build time (see the build action in the
# workflow)
"image": $REPOSITORY_URI:$IMAGE_TAG,
"essential": true,
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
]
}
],
"requiresCompatibilities": [
"FARGATE"
],
"networkMode": "awsvpc",
"cpu": "256",
"memory": "512",
"family": "codecatalyst-ecs-task-def"
}
```
앞의 코드에서
*arn:aws:iam::account\$1ID:role/codecatalyst-ecs-task-execution-role*
[태스크 실행 역할을 생성하는 방법](#deploy-tut-ecs-create-task-execution-role)에서 기록한 태스크 실행 역할의 ARN으로 바꿉니다.
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
`taskdef.json` 파일이 리포지토리에 추가됩니다.
## 8단계: 워크플로 생성 및 실행
이 단계에서는 소스 파일을 가져와 Docker 이미지로 빌드한 다음 Amazon ECS 클러스터에 이미지를 배포하는 워크플로를 생성합니다. 이 배포는 기존 Apache 자리 표시자 애플리케이션을 대체합니다.
워크플로는 순차적으로 실행되는 다음 구성 요소로 구성됩니다.
+ 트리거 - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ 빌드 작업(`BuildBackend`) - 트리거 시 작업은 Dockerfile을 사용하여 Docker 이미지를 빌드하고 Amazon ECR에 이미지를 푸시합니다. 빌드 작업은 또한 `taskdef.json`를 올바른 `image` 필드 값으로 업데이트한 다음 이 파일의 출력 아티팩트를 생성합니다. 이 아티팩트는 다음 배포 작업의 입력으로 사용됩니다.
빌드 작업에 대한 자세한 내용은 [워크플로로 빌드하기](build-workflow-actions.md) 섹션을 참조하세요.
+ 배포 작업(`DeployToECS`) - 빌드 작업이 완료되면 배포 작업은 빌드 작업(`TaskDefArtifact`)에서 생성된 출력 아티팩트를 찾고, 그 안에서 `taskdef.json`을 찾아 Amazon ECS 서비스에 등록합니다. 그런 다음 Amazon ECS 서비스는 `taskdef.json` 파일의 지침에 따라 Amazon ECS 클러스터 내에서 Amazon ECS 작업 및 연결된 Docker 컨테이너를 실행합니다.
**워크플로 생성**
1. CodeCatalyst 콘솔의 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
1. **소스 리포지토리**에서 `codecatalyst-ecs-source-repository`을 선택합니다.
1. **브랜치**에서 `main`을 선택합니다.
1. **생성(Create)**을 선택합니다.
1. YAML 샘플 코드를 삭제합니다.
1. 다음 YAML 코드를 추가합니다.
**참고**
다음 YAML 코드에서 원하는 경우 `Connections:` 섹션을 생략할 수 있습니다. 이 섹션을 생략하는 경우 환경의 **기본 IAM 역할** 필드에 지정된 역할에 [5단계: CodeCatalyst에 AWS 역할 추가](#deploy-tut-ecs-import-roles)에 설명된 두 역할의 권한 및 신뢰 정책이 포함되어 있는지 확인해야 합니다. 기본 IAM 역할이 있는 환경 설정에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
```
Name: codecatalyst-ecs-workflow
SchemaVersion: 1.0
Triggers:
- Type: PUSH
Branches:
- main
Actions:
BuildBackend:
Identifier: aws/build@v1
Environment:
Name: codecatalyst-ecs-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-ecs-build-role
Inputs:
Sources:
- WorkflowSource
Variables:
- Name: REPOSITORY_URI
Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo
- Name: IMAGE_TAG
Value: ${WorkflowSource.CommitId}
Configuration:
Steps:
#pre_build:
- Run: echo Logging in to Amazon ECR...
- Run: aws --version
- Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com
#build:
- Run: echo Build started on `date`
- Run: echo Building the Docker image...
- Run: docker build -t $REPOSITORY_URI:latest .
- Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
#post_build:
- Run: echo Build completed on `date`
- Run: echo Pushing the Docker images...
- Run: docker push $REPOSITORY_URI:latest
- Run: docker push $REPOSITORY_URI:$IMAGE_TAG
# Replace the variables in taskdef.json
- Run: find taskdef.json -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g"
- Run: find taskdef.json -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g"
- Run: cat taskdef.json
# The output artifact will be a zip file that contains a task definition file.
Outputs:
Artifacts:
- Name: TaskDefArtifact
Files:
- taskdef.json
DeployToECS:
DependsOn:
- BuildBackend
Identifier: aws/ecs-deploy@v1
Environment:
Name: codecatalyst-ecs-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-ecs-deploy-role
Inputs:
Sources: []
Artifacts:
- TaskDefArtifact
Configuration:
region: us-west-2
cluster: codecatalyst-ecs-cluster
service: codecatalyst-ecs-service
task-definition: taskdef.json
```
앞의 코드에서
+ *codecatalyst-ecs-environment* 인스턴스 두 개를 모두 [사전 조건](#deploy-tut-ecs-prereqs)에서 생성한 환경 이름으로 바꿉니다.
+ *codecatalyst-account-connection* 인스턴스 두 개를 모두 계정 연결의 표시 이름으로 바꿉니다. 표시 이름은 숫자일 수 있습니다. 자세한 내용은 [5단계: CodeCatalyst에 AWS 역할 추가](#deploy-tut-ecs-import-roles) 섹션을 참조하세요.
+ *codecatalyst-ecs-build-role*을 [4단계: AWS 역할 생성](#deploy-tut-ecs-build-deploy-roles)에서 생성한 빌드 역할 이름으로 바꿉니다.
+ *111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo*(`Value:` 속성 내)를 [3단계: Amazon ECR 이미지 리포지토리 생성](#deploy-tut-ecs-ecr)에서 생성한 Amazon ECR 리포지토리의 URI로 바꿉니다.
+ *111122223333.dkr.ecr.us-west-2.amazonaws.com*(`Run: aws ecr` 명령 내)을 이미지 접미사(`/codecatalyst-ecs-image-repo`) 제외 Amazon ECR 리포지토리의 URI로 바꿉니다.
+ *codecatalyst-ecs-deploy-role*을 [4단계: AWS 역할 생성](#deploy-tut-ecs-build-deploy-roles)에서 생성한 배포 역할의 이름으로 바꿉니다.
+ AWS 리전 코드가 있는 *us-west-2*의 두 인스턴스. 리전 코드 목록은 *AWS 일반 참조*의 [리전 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)를 참조하세요.
**참고**
빌드 및 배포 역할을 생성하지 않기로 결정한 경우 *codecatalyst-ecs-build-role* 및 *codecatalyst-ecs-deploy-role*을 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할 이름으로 바꿉니다. 이에 대한 자세한 내용은 [4단계: AWS 역할 생성](#deploy-tut-ecs-build-deploy-roles) 섹션을 참조하세요.
**작은 정보**
이전 워크플로 코드에 표시된 `find` 및 `sed` 명령을 사용하여 리포지토리 및 이미지 이름을 업데이트하는 대신 이 용도로 **Amazon ECS 작업 정의 렌더링** 작업을 사용할 수 있습니다. 자세한 내용은 [Amazon ECS 작업 정의 수정](render-ecs-action.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택합니다.
1. **워크플로 커밋** 대화 상자에서 다음을 입력합니다.
1. **커밋 메시지**에서 텍스트를 제거하고 다음을 입력합니다.
```
Add first workflow
```
1. **리포지토리**에서 `codecatalyst-ecs-source-repository`를 선택합니다.
1. **브랜치 이름**에서 기본을 선택합니다.
1. **커밋**을 선택합니다.
이제 워크플로를 생성했습니다. 워크플로 상단에 정의된 트리거로 인해 워크플로 실행이 자동으로 시작됩니다. 특히 `workflow.yaml` 파일을 소스 리포지토리에 커밋(및 푸시)할 때 트리거가 워크플로 실행을 시작했습니다.
**진행 중인 워크플로 실행을 보려면**
1. CodeCatalyst 콘솔의 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 방금 생성한 `codecatalyst-ecs-workflow` 워크플로를 선택합니다.
1. **BuildBackend**를 선택하여 빌드 진행 상황을 확인합니다.
1. **DeployToECS**를 선택하여 배포 진행 상황을 확인합니다.
실행 세부 정보 보기에 대한 자세한 내용은 [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md)를 참조하세요.
**배포를 확인하려면**
1. [https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/)에서 Amazon ECS 클래식 콘솔을 엽니다.
1. `codecatalyst-ecs-cluster` 클러스터를 선택합니다.
1. **작업** 탭을 선택합니다.
1. 세 가지 태스크 중 하나를 선택합니다.
1. **퍼블릭 IP** 필드에서 **개방형 주소**를 선택합니다.
브라우저에 "Hello World" 페이지가 나타나 Amazon ECS 서비스가 애플리케이션을 성공적으로 배포했음을 나타냅니다.
## 9단계: 소스 파일 변경
이 섹션에서는 소스 리포지토리의 `index.html` 파일을 변경합니다. 이 변경으로 인해 워크플로는 새 Docker 이미지를 빌드하고 커밋 ID로 태그를 지정하고 Amazon ECR에 푸시한 다음 Amazon ECS에 배포합니다.
**index.html을 변경하려면**
1. CodeCatalyst 콘솔의 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택하고 `codecatalyst-ecs-source-repository` 리포지토리를 선택합니다.
1. [`public-html`]를 선택한 다음 [`index.html`]를 선택합니다.
`index.html`의 내용이 나타납니다.
1. **편집**을 선택합니다.
1. 14행에서 `Hello World` 텍스트를 `Tutorial complete!`로 변경합니다.
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
커밋으로 인해 새 워크플로 실행이 시작됩니다.
1. (선택 사항) 소스 리포지토리의 메인 페이지로 이동하여 **커밋 보기**를 선택한 다음 `index.html` 변경 사항에 대한 커밋 ID를 기록해 둡니다.
1. 배포 진행 상황 보기:
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 최신 실행을 보려면 `codecatalyst-ecs-workflow`를 선택합니다.
1. **BuildBackend** 및 **DeployToECS**를 선택하여 워크플로 실행 진행 상황을 확인합니다.
1. 다음과 같이 애플리케이션이 업데이트되었는지 확인합니다.
1. [https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/)에서 Amazon ECS 클래식 콘솔을 엽니다.
1. `codecatalyst-ecs-cluster` 클러스터를 선택합니다.
1. **작업** 탭을 선택합니다.
1. 세 가지 태스크 중 하나를 선택합니다.
1. **퍼블릭 IP** 필드에서 **개방형 주소**를 선택합니다.
`Tutorial complete!` 페이지가 나타납니다.
1. (선택 사항)에서 Amazon ECR 콘솔로 AWS전환하고 새 Docker 이미지에 6단계의 커밋 ID로 태그가 지정되었는지 확인합니다.
## 정리
요금이 부과되지 않도록 이 자습서에서 사용하는 파일과 서비스를 정리합니다.
에서 다음 순서로 AWS Management Console정리합니다.
1. Amazon ECS에서 다음을 수행합니다.
1. `codecatalyst-ecs-service`을 삭제합니다.
1. `codecatalyst-ecs-cluster`을 삭제합니다.
1. `codecatalyst-ecs-task-definition` 등록을 취소합니다.
1. Amazon ECR에서 `codecatalyst-ecs-image-repo`를 삭제합니다.
1. Amazon EC2에서 `codecatalyst-ecs-security-group`를 삭제합니다.
1. IAM Identity Center에서 다음을 삭제합니다.
1. `CodeCatalystECSUser`
1. `CodeCatalystECSPermissionSet`
CodeCatalyst 콘솔에서 다음과 같이 정리합니다.
1. `codecatalyst-ecs-workflow`를 삭제합니다.
1. `codecatalyst-ecs-environment`를 삭제합니다.
1. `codecatalyst-ecs-source-repository`를 삭제합니다.
1. `codecatalyst-ecs-project`를 삭제합니다.
이 자습서에서는 CodeCatalyst 워크플로와 Amazon ECS에 배포 작업을 사용하여 **Amazon ECS 서비스에 애플리케이션을 배포**하는 방법을 배웠습니다.
# 'Amazon ECS에 배포' 작업 추가
다음 지침을 사용하여 워크플로에 **Amazon ECS에 배포** 작업을 추가합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 'Amazon ECS에 배포' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **Amazon ECS에 배포** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **Amazon ECS에 배포**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **다운로드**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['Amazon ECS에 배포' 작업 YAML](deploy-action-ref-ecs.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 'Amazon ECS에 배포' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **Amazon ECS에 배포** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **Amazon ECS에 배포**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **다운로드**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['Amazon ECS에 배포' 작업 YAML](deploy-action-ref-ecs.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 'Amazon ECS에 배포' 변수
**Amazon ECS에 배포** 작업은 런타임에 다음 변수를 생성하고 설정합니다. 이를 *사전 정의된 변수*라고 합니다.
워크플로에서 이러한 변수를 참조하는 방법에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
| Key(키) | 값 |
| --- | --- |
| 클러스터 | 워크플로 실행 중에 배포된 Amazon ECS 클러스터의 이름입니다. 예시: `codecatalyst-ecs-cluster` |
| deployment-platform | 배포 플랫폼의 이름입니다. `AWS:ECS`로 하드코딩되었습니다. |
| 서비스 | 워크플로 실행 중에 에 배포된 Amazon ECS 서비스의 이름입니다. 예시: `codecatalyst-ecs-service` |
| task-definition-arn | 워크플로 실행 중에 등록된 작업 정의의 Amazon 리소스 이름(ARN)입니다. 예시: `arn:aws:ecs:us-west-2:111122223333:task-definition/codecatalyst-task-def:8`위 예시의 `:8`은 등록된 리비전을 나타냅니다. |
| deployment-url | 워크플로 실행과 연결된 Amazon ECS 배포의 세부 정보를 볼 수 있는 Amazon ECS 콘솔의 **이벤트** 탭에 대한 링크입니다. 예시: `https://console.aws.amazon.com/ecs/home?region=us-west-2#/clusters/codecatalyst-ecs-cluster/services/codecatalyst-ecs-service/events` |
| 리전 | 워크플로 실행 중에에 배포 AWS 리전 된의 리전 코드입니다. 예시: `us-west-2` |
# 'Amazon ECS에 배포' 작업 YAML
다음은 **Amazon ECS에 배포** 작업의 YAML 정의입니다. 이러한 작업 사용 방법을 배우려면 [워크플로를 사용하여 Amazon ECS에 배포](deploy-action-ecs.md) 섹션을 참조하세요.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
ECSDeployAction\$1nn:
Identifier: aws/ecs-deploy@v1
DependsOn:
- build-action
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
Timeout: timeout-minutes
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Inputs:
# Specify a source or an artifact, but not both.
Sources:
- source-name-1
Artifacts:
- task-definition-artifact
Configuration:
region: us-east-1
cluster: ecs-cluster
service: ecs-service
task-definition: task-definition-path
force-new-deployment: false|true
codedeploy-appspec: app-spec-file-path
codedeploy-application: application-name
codedeploy-deployment-group: deployment-group-name
codedeploy-deployment-description: deployment-description
```
## ECSDeployAction
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
기본값: `ECSDeployAction_nn`.
해당 UI: 구성 탭/**작업 표시 이름**
## Identifier
(*ECSDeployAction*/**Identifier**)
(필수)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
기본값: `aws/ecs-deploy@v1`.
해당 UI: 워크플로 다이어그램/ECSDeployAction\$1nn/**aws/ecs-deploy@v1** 레이블
## DependsOn
(*ECSDeployAction*/**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*ECSDeployAction*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Type
(*ECSDeployAction*/Compute/**Type**)
([Compute](#deploy.action.ecs.computename) 포함 시 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 구성 탭/고급 - 선택 사항/**컴퓨팅 유형**
## Fleet
(*ECSDeployAction*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/고급 - 선택적/**컴퓨팅 플릿**
## Timeout
(*ECSDeployAction*/**Timeout**)
(선택 사항)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Environment
(*ECSDeployAction*/**Environment**)
(필수)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*ECSDeployAction*/Environment/**Name**)
([Environment](#deploy.action.ecs.environment) 포함 시 필수)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*ECSDeployAction*/Environment/**Connections**)
(최신 버전의 작업에서는 선택 사항, 이전 버전에서는 필수)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Name
(*ECSDeployAction*/Environment/Connections/**Name**)
([Connections](#deploy.action.ecs.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Role
(*ECSDeployAction*/Environment/Connections/**Role**)
([Connections](#deploy.action.ecs.environment.connections) 포함 시 필수)
**Amazon ECS에 배포** 작업이 AWS에 액세스하는 데 사용하는 IAM 역할의 이름을 지정합니다. [CodeCatalyst 스페이스에 역할을 추가](ipa-connect-account-addroles.md)했고 역할에 다음 정책이 포함되어 있는지 확인합니다.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 다음 정책이 있는지 확인합니다.
+ 다음 권한 정책:
**주의**
다음 정책에 표시된 대로 권한을 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Action":[
"ecs:DescribeServices",
"ecs:CreateTaskSet",
"ecs:DeleteTaskSet",
"ecs:ListClusters",
"ecs:RegisterTaskDefinition",
"ecs:UpdateServicePrimaryTaskSet",
"ecs:UpdateService",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:DescribeRules",
"elasticloadbalancing:ModifyRule",
"lambda:InvokeFunction",
"lambda:ListFunctions",
"cloudwatch:DescribeAlarms",
"sns:Publish",
"sns:ListTopics",
"s3:GetObject",
"s3:GetObjectVersion",
"codedeploy:CreateApplication",
"codedeploy:CreateDeployment",
"codedeploy:CreateDeploymentGroup",
"codedeploy:GetApplication",
"codedeploy:GetDeployment",
"codedeploy:GetDeploymentGroup",
"codedeploy:ListApplications",
"codedeploy:ListDeploymentGroups",
"codedeploy:ListDeployments",
"codedeploy:StopDeployment",
"codedeploy:GetDeploymentTarget",
"codedeploy:ListDeploymentTargets",
"codedeploy:GetDeploymentConfig",
"codedeploy:GetApplicationRevision",
"codedeploy:RegisterApplicationRevision",
"codedeploy:BatchGetApplicationRevisions",
"codedeploy:BatchGetDeploymentGroups",
"codedeploy:BatchGetDeployments",
"codedeploy:BatchGetApplications",
"codedeploy:ListApplicationRevisions",
"codedeploy:ListDeploymentConfigs",
"codedeploy:ContinueDeployment"
],
"Resource":"*",
"Effect":"Allow"
},{"Action":[
"iam:PassRole"
],
"Effect":"Allow",
"Resource":"*",
"Condition":{"StringLike":{"iam:PassedToService":[
"ecs-tasks.amazonaws.com",
"codedeploy.amazonaws.com"
]
}
}
}]
}
```
------
**참고**
역할을 처음 사용할 때는 리소스 정책 설명에서 다음 와일드카드를 사용한 다음 사용 가능한 리소스 이름으로 정책의 범위를 좁힙니다.
```
"Resource": "*"
```
+ 다음 사용자 지정 신뢰 정책:
**참고**
원하는 경우 이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**역할**
## Inputs
(*ECSDeployAction*/**Inputs**)
(선택 사항)
이 `Inputs` 섹션에서는 워크플로 실행 중 `ECSDeployAction`에 필요한 데이터를 정의합니다.
**참고**
**Amazon ECS에 배포** 작업당 하나의 입력(소스 또는 아티팩트)만 허용됩니다.
해당 UI: **입력** 탭
## Sources
(*ECSDeployAction*/Inputs/**Sources**)
(작업 정의 파일이 소스 리포지토리에 저장된 경우 필수)
태스크 정의 파일이 소스 리포지토리에 저장되어 있는 경우 해당 소스 리포지토리의 레이블을 지정합니다. 현재, `WorkflowSource` 레이블만 지원됩니다.
태스크 정의 파일이 소스 리포지토리에 포함되어 있지 않은 경우, 다른 작업에서 생성된 아티팩트에 있어야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*ECSDeployAction*/Inputs/**Artifacts**)
(작업 정의 파일이 이전 작업의 [출력 아티팩트](workflows-working-artifacts-output.md)에 저장된 경우 필수)
배포하려는 작업 정의 파일이 이전 작업에서 생성된 아티팩트에 포함된 경우 여기에 해당 아티팩트를 지정합니다. 태스크 정의 파일이 아티팩트 내에 포함되어 있지 않은 경우 소스 리포지토리에 있어야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**아티팩트 - 선택 사항**
## Configuration
(*ECSDeployAction*/**Configuration**)
(필수)
작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## region
(Configuration/**region**)
(필수)
Amazon ECS 클러스터 및 서비스가 상주하는 AWS 리전을 지정합니다. 리전 코드 목록은 *AWS 일반 참조*의 [리전 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)를 참조하세요.
해당 UI: 구성 탭/**리전**
## cluster
(*ECSDeployAction*/Configuration/**cluster**)
(필수)
기존 Amazon ECS 클러스터의 이름을 지정합니다. **Amazon ECS에 배포** 작업을 수행하면 컨테이너화된 애플리케이션이 이 클러스터에 작업으로 배포됩니다. 자세한 내용을 알아보려면 *Amazon Elastic Container Service 개발자 안내서*에서 [클러스터](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters)를 참조하세요.
해당 UI: 구성 탭/**클러스터**
## service
(*ECSDeployAction*/Configuration/**service**)
(필수)
작업 정의 파일을 인스턴스화할 기존 Amazon ECS 서비스의 이름을 지정합니다. 이 서비스는 `cluster` 필드에 지정된 클러스터 아래에 있어야 합니다. Amazon ECS에 대한 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [Amazon ECS 서비스](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)를 참조하세요.
해당 UI: 구성 탭/**서비스**
## task-definition
(*ECSDeployAction*/Configuration/**task-definition**)
(필수)
기존 작업 정의 파일의 경로를 지정합니다. 파일이 소스 리포지토리에 있는 경우 경로는 소스 리포지토리 루트 폴더를 기준으로 합니다. 파일이 이전 워크플로 작업의 아티팩트에 있는 경우 경로는 아티팩트 루트 폴더를 기준으로 합니다. 자세한 내용을 알아보려면 *Amazon Elastic Container Service 개발자 안내서*의 [작업 정의](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions)를 참조하세요.
해당 UI: 구성 탭/**작업 정의**
## force-new-deployment
(*ECSDeployAction*/Configuration/**force-new-deployment**)
(필수)
활성화된 경우 Amazon ECS 서비스는 서비스 정의 변경 없이 새 배포를 시작할 수 있습니다. 배포를 강제하면 서비스가 현재 실행 중인 모든 작업을 중지하고 새 작업을 시작합니다. 새 배포 강제 적용에 대한 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [서비스 업데이트](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service.html)를 참조하세요.
기본값: `false`
해당 UI: 구성 탭/**서비스의 새 배포 강제 적용**
## codedeploy-appspec
(*ECSDeployAction*/Configuration/**codedeploy-appspec**)
(블루/그린 배포를 사용하도록 Amazon ECS 서비스를 구성한 경우 필수, 그렇지 않으면 생략)
기존 CodeDeploy 애플리케이션 사양(AppSpec) 파일의 이름과 경로를 지정합니다. 이 파일은 CodeCatalyst 소스 리포지토리의 루트에 있어야 합니다. AppSpec 파일에 대한 자세한 내용은 *AWS CodeDeploy 사용 설명서*의 [CodeDeploy 애플리케이션 사양(AppSpec) 파일](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html)을 참조하세요.
**참고**
블루/그린 배포를 수행하도록 Amazon ECS 서비스를 구성한 경우에만 CodeDeploy 정보를 제공합니다. 롤링 업데이트 배포(기본값)의 경우 CodeDeploy 정보를 생략합니다. Amazon ECS 배포에 대해 자세한 내용을 알아보려면 *Amazon Elastic Container Service 개발자 안내서*의 [Amazon ECS 배포 유형](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html)을 참조하세요.
**참고**
**CodeDeploy** 필드는 시각적 편집기에 숨겨질 수 있습니다. 해당 항목이 표시되도록 하려면 [시각적 편집기에서 CodeDeploy 필드가 누락된 이유는 무엇인가요?](troubleshooting-workflows.md#troubleshooting-workflows-codedeploy) 섹션을 참조하세요.
해당 UI: 구성 탭/**CodeDeploy AppSpec**
## codedeploy-application
(*ECSDeployAction*/Configuration/**codedeploy-application**)
(`codedeploy-appspec` 포함 시 필수)
기존 CodeDeploy 애플리케이션의 이름을 지정합니다. CodeDeploy 애플리케이션에 대한 자세한 내용은 *AWS CodeDeploy 사용 설명서*의 [CodeDeploy에서 애플리케이션 작업](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications.html)을 참조하세요.
해당 UI: 구성 탭/**CodeDeploy 애플리케이션**
## codedeploy-deployment-group
(*ECSDeployAction*/Configuration/**codedeploy-deployment-group**)
(`codedeploy-appspec` 포함 시 필수)
기존 CodeDeploy 배포 그룹의 이름을 지정합니다. CodeDeploy 배포 그룹에 대한 자세한 내용은 *AWS CodeDeploy 사용 설명서*의 [CodeDeploy에서 배포 그룹 작업](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)을 참조하세요.
해당 UI: 구성 탭/**CodeDeploy 배포 그룹**
## codedeploy-deployment-description
(*ECSDeployAction*/Configuration/**codedeploy-deployment-description**)
(선택 사항)
이 작업에서 생성할 배포에 대한 설명을 지정합니다. 자세한 정보는 *AWS CodeDeploy 사용자 가이드*의 [CodeDeploy에서 배포로 작업](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments.html)을 잠조하세요.
해당 UI: 구성 탭/**CodeDeploy 배포 설명**
# 워크플로를 사용하여 Amazon EKS에 배포
**작은 정보**
**Kubernetes 클러스터에 배포** 작업을 사용하는 방법을 보여주는 자습서는 [자습서: Amazon EKS에 애플리케이션 배포](deploy-tut-eks.md) 섹션을 참조하세요.
이 섹션에서는 CodeCatalyst 워크플로를 사용하여 컨테이너화된 애플리케이션을 Kubernetes 클러스터에 배포하는 방법을 설명합니다. 이렇게 하려면 워크플로에 **Kubernetes 클러스터에 배포** 작업을 추가해야 합니다. 이 작업은 하나 이상의 Kubernetes 매니페스트 파일을 사용하여 Amazon Elastic Kubernetes Service(EKS)에서 설정한 Kubernetes 클러스터에 애플리케이션을 배포합니다. 샘플 매니페스트는 [자습서: Amazon EKS에 애플리케이션 배포](deploy-tut-eks.md)의 [deployment.yaml](deploy-tut-eks.md#deploy-tut-eks-source-files-deployment-yml) 섹션을 참조하세요.
Kubernetes에 대한 자세한 내용은 [Kubernetes 문서](https://kubernetes.io/docs/home/)을 참조하세요.
Amazon EKS에 관한 자세한 내용은 *Amazon EKS 사용 설명서*의 [Amazon EKS란?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)을 참조하세요.
**Topics**
+ ['Kubernetes 클러스터에 배포' 작업 작동 방식](#deploy-action-eks-howitworks)
+ ['Amazon EKS에 배포' 작업에서 사용되는 런타임 이미지](#deploy-action-eks-runtime)
+ [자습서: Amazon EKS에 애플리케이션 배포](deploy-tut-eks.md)
+ ['Kubernetes 클러스터에 배포' 작업 추가](deploy-action-eks-adding.md)
+ ['Kubernetes 클러스터에 배포' 변수](deploy-action-eks-variables.md)
+ ['Kubernetes 클러스터에 배포' 작업 YAML](deploy-action-ref-eks.md)
## 'Kubernetes 클러스터에 배포' 작업 작동 방식
**Kubernetes 클러스터에 배포**는 다음과 같이 작동합니다.
1. 런타임 시 작업은 작업이 실행 중인 CodeCatalyst 컴퓨팅 시스템에 Kubernetes `kubectl` 유틸리티를 설치합니다. 작업을 구성할 때 제공한 Amazon EKS 클러스터를 가리키도록 작업이 `kubectl`을 구성합니다. 다음에는 `kubectl apply` 명령을 실행하는 데 `kubectl` 유틸리티가 필요합니다.
1. 이 작업은 *my-manifest.yaml*의 `kubectl apply -f my-manifest.yaml` 명령을 실행하여 애플리케이션을 컨테이너 및 포드 세트로 구성된 클러스터에 배포합니다. 이 명령에 대한 자세한 내용은 *Kubernetes 참조 설명서*의 [kubectl 적용](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) 주제를 참조하세요.
## 'Amazon EKS에 배포' 작업에서 사용되는 런타임 이미지
**Amazon EKS에 배포** 작업은 [2022년 11월 이미지](build-images.md#build.previous-image)에서 실행됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 섹션을 참조하세요.
# 자습서: Amazon EKS에 애플리케이션 배포
이 자습서에서는 Amazon CodeCatalyst 워크플로, Amazon EKS 및 기타 몇 가지 AWS 서비스를 사용하여 컨테이너화된 애플리케이션을 Amazon Elastic Kubernetes Service에 배포하는 방법을 알아봅니다. 배포된 애플리케이션은 간단한 'Hello, World\$1'입니다. Apache 웹 서버 Docker 이미지를 기반으로 구축된 웹 사이트입니다. 이 자습서에서는 개발 머신 및 Amazon EKS 클러스터 설정과 같은 필수 준비 작업을 안내한 다음 애플리케이션을 빌드하고 클러스터에 배포하기 위한 워크플로를 생성하는 방법을 설명합니다.
초기 배포가 완료되면 자습서에서 애플리케이션 소스를 변경하도록 지시합니다. 이 변경으로 인해 새 Docker 이미지가 빌드되고 새 개정 정보와 함께 Docker 이미지 리포지토리로 푸시됩니다. 그런 다음 Docker 이미지의 새 개정이 Amazon EKS에 배포됩니다.
**작은 정보**
이 자습서를 진행하는 대신 전체 Amazon EKS 설정을 수행하는 블루프린트를 사용할 수 있습니다. **EKS 앱 배포** 블루프린트를 사용해야 합니다. 자세한 내용은 [블루프린트를 사용하여 프로젝트 생성](projects-create.md#projects-create-console-template) 섹션을 참조하세요.
**Topics**
+ [사전 조건](#deploy-tut-eks-prereqs)
+ [1단계: 개발 머신 설정](#deploy-tut-eks-dev-env-create)
+ [2단계: Amazon EKS 클러스터 생성](#deploy-tut-eks-cluster)
+ [3단계: Amazon ECR 이미지 리포지토리 생성](#deploy-tut-eks-ecr)
+ [4단계: 소스 파일 추가](#deploy-tut-eks-source-files)
+ [5단계: AWS 역할 생성](#deploy-tut-eks-roles)
+ [6단계: CodeCatalyst에 AWS 역할 추가](#deploy-tut-eks-import-roles)
+ [7단계: ConfigMap 업데이트](#deploy-tut-eks-configmap)
+ [8단계: 워크플로 생성 및 실행](#deploy-tut-eks-workflow)
+ [9단계: 소스 파일 변경](#deploy-tut-eks-change)
+ [정리](#deploy-tut-eks-cleanup)
## 사전 조건
이 자습서를 시작하기 전에 다음을 수행합니다.
+ 연결된 AWS 계정이 있는 Amazon CodeCatalyst **스페이스**가 필요합니다. 자세한 내용은 [스페이스 생성](spaces-create.md) 단원을 참조하십시오.
+ 스페이스에는 다음과 같은 빈 프로젝트가 필요합니다.
```
codecatalyst-eks-project
```
**처음부터 시작** 옵션을 사용하여 이 프로젝트를 생성합니다.
자세한 내용은 [Amazon CodeCatalyst에서 빈 프로젝트 생성](projects-create.md#projects-create-empty) 섹션을 참조하세요.
+ 프로젝트에는 다음과 같은 빈 CodeCatalyst **소스 리포지토리**가 필요합니다.
```
codecatalyst-eks-source-repository
```
자세한 내용은 [CodeCatalyst의 소스 리포지토리로 코드 저장 및 협업소스 리포지토리를 사용하여 코드 저장 및 협업](source.md) 섹션을 참조하세요.
+ 프로젝트에는 다음과 같은 CodeCatalyst CI/CD **환경**(개발 환경 아님)이 필요합니다.
```
codecatalyst-eks-environment
```
다음과 같이 이 환경을 구성합니다.
+ **비프로덕션**과 같은 유형을 선택합니다.
+ AWS 계정에 연결합니다.
+ **기본 IAM 역할**의 경우 아무 역할이나 선택합니다. 나중에 다른 역할을 지정합니다.
자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 섹션을 참조하세요.
## 1단계: 개발 머신 설정
이 자습서의 첫 번째 단계는 이 자습서 전체에서 사용할 몇 가지 도구를 사용하여 개발 머신을 구성하는 것입니다. 이러한 도구는 다음과 같습니다.
+ `eksctl` 유틸리티 - 클러스터 생성용
+ `kubectl` 유틸리티 - `eksctl`의 사전 조건
+ AWS CLI -의 사전 조건이기도 합니다. `eksctl`
이러한 도구가 있는 경우 기존 개발 시스템에 설치하거나 클라우드 기반 CodeCatalyst 개발 환경를 사용할 수 있습니다. CodeCatalyst 개발 환경의 이점은 스핀 업 및 테이크 다운이 쉽고 다른 CodeCatalyst 서비스와 통합되어 있어 이 자습서를 더 적은 단계로 진행할 수 있다는 것입니다.
이 자습서에서는 CodeCatalyst 개발 환경를 사용한다고 가정합니다.
다음 지침은 CodeCatalyst 개발 환경를 시작하고 필요한 도구로 구성하는 빠른 방법을 설명하지만 자세한 지침은 다음을 참조하세요.
+ [개발 환경 생성](devenvironment-create.md) 섹션을 참조하세요.
+ **Amazon EKS 사용 설명서**의 [kubectl 설치](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html).
+ **Amazon EKS 사용 설명서**의 [eksctl 설치 또는 업그레이드](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html).
+ *AWS Command Line Interface 사용자 안내서*의 [AWS CLI최신 버전 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
**새 개발 환경을 시작하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-eks-project` 프로젝트로 이동합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. 소스 리포지토리 `codecatalyst-eks-source-repository`의 이름을 선택합니다.
1. 상단 근처에서 **개발 환경 생성**을 선택한 다음 **AWS Cloud9 (브라우저에서)**를 선택합니다.
1. **기존 브랜치에서 작업** 및 **메인**이 선택되어 있는지 확인한 다음 **생성**을 선택합니다.
개발 환경가 새 브라우저 탭에서 시작되고 리포지토리(`codecatalyst-eks-source-repository`)가 복제됩니다.
**kubectl을 설치 및 구성하려면**
1. 개발 환경 터미널에 다음을 입력합니다.
```
curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/linux/amd64/kubectl
```
1. 입력:
```
chmod +x ./kubectl
```
1. 입력:
```
mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
```
1. 입력:
```
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
```
1. 입력:
```
kubectl version --short --client
```
1. 버전이 나타나는지 확인합니다.
이제 `kubectl`이 설치됐습니다.
**eksctl을 설치 및 구성하려면**
**참고**
대신 `kubectl`을 사용할 수 있으므로 `eksctl`이 반드시 필요한 것은 아닙니다. 그러나 `eksctl`은 클러스터 구성의 대부분을 자동화하는 이점을 제공하므로 이 자습서에 권장되는 도구입니다.
1. 개발 환경 터미널에 다음을 입력합니다.
```
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
```
1. 입력:
```
sudo cp /tmp/eksctl /usr/bin
```
1. 입력:
```
eksctl version
```
1. 버전이 나타나는지 확인합니다.
이제 `eksctl`이 설치됐습니다.
**AWS CLI 가 설치되었는지 확인하려면**
1. 개발 환경 터미널에 다음을 입력합니다.
```
aws --version
```
1. 버전이 표시되어 AWS CLI 가 설치되었는지 확인합니다.
나머지 절차를 완료하여에 액세스하는 데 필요한 권한 AWS CLI 으로를 구성합니다 AWS.
**를 구성하려면 AWS CLI**
AWS 서비스에 대한 액세스 권한을 부여하려면 AWS CLI 액세스 키와 세션 토큰으로를 구성해야 합니다. 다음 지침은 키와 토큰을 구성하는 빠른 방법을 제공하지만 자세한 지침은 *AWS Command Line Interface 사용자 설명서*의 [AWS CLI구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)을 참조하세요.
1. 다음과 같이 IAM Identity Center 사용자를 생성합니다.
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/) AWS IAM Identity Center 콘솔을 엽니다.
(IAM Identity Center에 로그인한 적이 없는 경우 **활성화**를 선택해야 할 수 있습니다.)
**참고**
CodeCatalyst 스페이스에 AWS 계정 연결된를 사용하여 로그인해야 합니다. 스페이스로 이동하여 **AWS 계정** 탭을 선택하고 연결된 계정을 확인할 수 있습니다. 자세한 내용은 [스페이스 생성](spaces-create.md) 섹션을 참조하세요.
1. 탐색 창에서 **Users**와 **Add user**를 차례대로 선택합니다.
1. **사용자 이름**에 다음을 입력합니다.
```
codecatalyst-eks-user
```
1. **암호**에서 **이 사용자와 공유할 수 있는 일회용 암호 생성**을 선택합니다.
1. **이메일 주소** 및 **이메일 주소 확인**에 IAM Identity Center에 아직 없는 이메일 주소를 입력합니다.
1. **이름**에 다음을 입력합니다.
```
codecatalyst-eks-user
```
1. **성**에 다음을 입력합니다.
```
codecatalyst-eks-user
```
1. **표시 이름**에서 다음을 유지합니다.
```
codecatalyst-eks-user codecatalyst-eks-user
```
1. **다음**을 선택합니다.
1. **그룹에 사용자 추가** 페이지에서 **다음**을 선택합니다.
1. **검토 및 사용자 추가** 페이지에서 정보를 검토하고 **사용자 추가**를 선택합니다.
**일회용 암호** 대화 상자가 나타납니다.
1. **복사**를 선택한 다음 로그인 정보를 텍스트 파일에 붙여넣습니다. 로그인 정보는 AWS 액세스 포털 URL, 사용자 이름 및 일회용 암호로 구성됩니다.
1. **닫기**를 선택하세요.
1. 다음과 같이 권한 세트를 생성합니다.
1. 탐색 창에서 **권한 세트**를 선택한 다음 **권한 세트 생성**을 선택합니다.
1. **사전 정의된 권한 세트**를 선택하고 **AdministratorAccess**를 선택합니다. 이 정책은 모든 AWS 서비스에 대한 전체 권한을 제공합니다.
1. **다음**을 선택합니다.
1. **권한 세트 이름**에서 `AdministratorAccess`를 제거하고 다음을 입력합니다.
```
codecatalyst-eks-permission-set
```
1. **다음**을 선택합니다.
1. **검토 및 생성** 페이지에서 정보를 검토하고 **생성**을 선택합니다.
1. 다음과 같이 권한 세트를 `codecatalyst-eks-user`에 할당합니다.
1. 탐색 창에서 **AWS 계정**를 선택한 다음 현재 로그인 AWS 계정 한 옆의 확인란을 선택합니다.
1. **사용자 또는 그룹 할당**을 선택합니다.
1. **사용자** 탭을 선택합니다.
1. `codecatalyst-eks-user` 옆의 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. `codecatalyst-eks-permission-set` 옆의 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. 정보를 검토하고 **제출**을 선택합니다.
이제 `codecatalyst-eks-user` 및를 `codecatalyst-eks-permission-set`에 할당하여 함께 AWS 계정바인딩했습니다.
1. 다음과 같이 `codecatalyst-eks-user`의 액세스 키 및 세션 토큰을 가져옵니다.
1. 에 대한 AWS 액세스 포털 URL과 사용자 이름 및 일회용 암호가 있는지 확인합니다`codecatalyst-eks-user`. 이전에 이 정보를 텍스트 편집기에 복사했어야 합니다.
**참고**
이 정보가 없는 경우 IAM Identity Center의 `codecatalyst-eks-user` 세부 정보 페이지로 이동하여 **암호 재설정**, **일회용 암호 생성 [...]**을 선택한 후 **암호 재설정**을 다시 선택하면 화면에 해당 정보가 표시됩니다.
1. 로그아웃합니다 AWS.
1. AWS 액세스 포털 URL을 브라우저의 주소 표시줄에 붙여 넣습니다.
1. 다음을 사용하여 로그인:
+ **사용자 이름**:
```
codecatalyst-eks-user
```
+ **암호**:
*일회용 암호*
1. **새 암호 설정**에서 새 암호를 입력하고 **새 암호 설정**을 선택합니다.
화면에 **AWS 계정** 상자가 나타납니다.
1. **AWS 계정**을 선택한 다음 `codecatalyst-eks-user` 사용자 및 권한 세트를 할당한 AWS 계정 의 이름을 선택합니다.
1. `codecatalyst-eks-permission-set` 옆의 **명령줄 또는 프로그래밍 액세스**를 선택합니다.
1. 페이지 중간에 있는 명령을 복사합니다. 다음처럼 보일 것입니다.
```
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="session-token"
```
...여기서 *세션 토큰*은 긴 무작위 문자열입니다.
1. 다음과 AWS CLI같이 액세스 키와 세션 토큰을에 추가합니다.
1. CodeCatalyst 개발 환경으로 돌아갑니다.
1. 터미널 프롬프트에서 복사한 명령을 붙여넣습니다. 입력을 누릅니다.
이제 액세스 키와 세션 토큰 AWS CLI 으로를 구성했습니다. 이제 AWS CLI 를 사용하여이 자습서에 필요한 작업을 완료할 수 있습니다.
**중요**
이 자습서 중에 언제든지 다음과 유사한 메시지가 표시되는 경우:
`Unable to locate credentials. You can configure credentials by running "aws configure".`
또는 다음과 같습니다.
`ExpiredToken: The security token included in the request is expired`
... AWS CLI 세션이 만료되었기 때문입니다. 이 경우 `aws configure` 명령을 실행하지 *않습니다*. 대신 `Obtain codecatalyst-eks-user's access key and session token`로 시작하는 이 절차의 4단계에 있는 지침을 사용하여 세션을 새로 고칩니다.
## 2단계: Amazon EKS 클러스터 생성
이 섹션에서는 Amazon EKS에서 클러스터를 생성합니다. 아래 지침은 `eksctl`를 사용하여 클러스터를 생성하는 빠른 방법을 설명하지만 자세한 지침은 다음을 참조하세요.
+ **Amazon EKS 사용 설명서**의 [eksctl 시작하기](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)
또는
+ **Amazon EKS 사용 설명서**의 [콘솔 및 AWS CLI시작하기](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html)(이 주제에서는 클러스터 생성 `kubectl` 지침을 제공합니다)
**참고**
[프라이빗 클러스터](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html)는 Amazon EKS와의 CodeCatalyst 통합에서 지원되지 않습니다.
**시작하기 전에**
개발 시스템에서 다음 작업을 완료했는지 확인합니다.
+ `eksctl` 유틸리티를 설치했습니다.
+ `kubectl` 유틸리티를 설치했습니다.
+ 를 설치하고 액세스 키와 세션 토큰으로 AWS CLI 구성했습니다.
이러한 작업을 완료하는 방법에 대한 자세한 정보는 [1단계: 개발 머신 설정](#deploy-tut-eks-dev-env-create) 섹션을 참조하세요.
**클러스터 생성**
**중요**
클러스터가 올바르게 구성되지 않으므로 Amazon EKS 서비스의 사용자 인터페이스를 사용하여 클러스터를 생성하지 마세요. 다음 단계에 설명된 대로 `eksctl` 유틸리티를 사용합니다.
1. 개발 환경으로 이동합니다.
1. 클러스터 및 노드를 생성합니다.
```
eksctl create cluster --name codecatalyst-eks-cluster --region us-west-2
```
위치:
+ *codecatalyst-eks-cluster*는 클러스터에 부여하려는 이름으로 대체됩니다.
+ *us-west-2*를 해당 리전으로 바꿉니다.
10\$120분 후 다음과 비슷한 메시지가 나타납니다.
`EKS cluster "codecatalyst-eks-cluster" in "us-west-2" region is ready`
**참고**
AWS 에서 클러스터를 생성하는 동안 여러 `waiting for CloudFormation stack` 메시지가 표시됩니다. 이는 예상된 동작입니다.
1. 클러스터가 성공적으로 생성되었는지 확인합니다.
```
kubectl cluster-info
```
성공적인 클러스터 생성을 나타내는 다음과 유사한 메시지가 표시됩니다.
```
Kubernetes master is running at https://long-string.gr7.us-west-2.eks.amazonaws.com
CoreDNS is running at https://long-string.gr7.us-west-2.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
```
## 3단계: Amazon ECR 이미지 리포지토리 생성
이 섹션에서는 Amazon Elastic Container Registry(Amazon ECR)에서 프라이빗 이미지 리포지토리를 생성합니다. 이 리포지토리는 자습서의 Docker 이미지를 저장합니다.
Amazon ECR에 대한 자세한 내용은 *Amazon Elastic Container Registry 사용 설명서*를 참조합니다.
**Amazon ECR에서 이미지 리포지토리를 생성하려면**
1. 개발 환경으로 이동합니다.
1. Amazon ECR에 빈 리포지토리를 생성합니다.
```
aws ecr create-repository --repository-name codecatalyst-eks-image-repo
```
*codecatalyst-eks-image-repo*를 Amazon ECR 리포지토리에 부여하려는 이름으로 바꿉니다.
이 자습서에서는 리포지토리 이름을 `codecatalyst-eks-image-repo`로 지정했다고 가정합니다.
1. Amazon ECR 리포지토리의 세부 정보를 표시합니다.
```
aws ecr describe-repositories \
--repository-names codecatalyst-eks-image-repo
```
1. `“repositoryUri”:` 값을 기록해 둡니다. 예시: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo`.
나중에 워크플로에 리포지토리를 추가할 때 필요합니다.
## 4단계: 소스 파일 추가
이 섹션에서는 소스 리포지토리(`codecatalyst-eks-source-repository`)에 애플리케이션 소스 파일을 추가합니다. 다음과 같이 구성됩니다.
+ `index.html` 파일 - 'Hello, World\$1' 메시지를 브라우저에 표시합니다.
+ Dockerfile - Docker 이미지에 사용할 기본 이미지와 Docker 명령으로 적용할 기본 이미지를 설명합니다.
+ `deployment.yaml` 파일 - Kubernetes 서비스 및 배포를 정의하는 Kubernetes 매니페스트입니다.
폴더의 구조는 다음과 같습니다.
```
|— codecatalyst-eks-source-repository
|— Kubernetes
|— deployment.yaml
|— public-html
| |— index.html
|— Dockerfile
```
**Topics**
+ [index.html](#deploy-tut-eks-source-files-index)
+ [Dockerfile](#deploy-tut-eks-source-files-dockerfile)
+ [deployment.yaml](#deploy-tut-eks-source-files-deployment-yml)
### index.html
`index.html` 파일 - 'Hello, World\$1' 메시지를 브라우저에 표시합니다.
**index.html 파일을 추가하려면**
1. 개발 환경으로 이동합니다.
1. `codecatalyst-eks-source-repository`에서 이름이 `public-html`인 폴더를 생성합니다.
1. `/public-html`에서 다음 콘텐츠로 `index.html` 파일을 생성합니다.
```
Hello World
Hello, World!
```
1. 터미널 프롬프트에서 다음을 입력합니다.
```
cd /projects/codecatalyst-eks-source-repository
```
1. 추가, 커밋 및 푸시:
```
git add .
git commit -m "add public-html/index.html"
git push
```
`index.html`은 `public-html` 폴더의 리포지토리에 추가됩니다.
### Dockerfile
Dockerfile은 사용할 기본 Docker 이미지와 적용할 Docker 명령을 설명합니다. Dockerfile에 대한 자세한 내용은 [Dockerfile 참조](https://docs.docker.com/engine/reference/builder/)를 참조하세요.
여기에 지정된 Dockerfile은 Apache 2.4 기본 이미지(`httpd`)를 사용함을 나타냅니다. 또한 `index.html` 소스 파일을 웹 페이지를 제공하는 Apache 서버의 폴더에 복사하는 방법도 포함되어 있습니다. Dockerfile의 `EXPOSE` 지침은 컨테이너가 포트 80에서 수신 중임을 Docker에게 알립니다.
**Dockerfile을 추가하려면**
1. `codecatalyst-eks-source-repository`에서 다음 콘텐츠로 `Dockerfile` 파일을 생성합니다.
```
FROM httpd:2.4
COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html
EXPOSE 80
```
파일 확장자는 제외합니다.
**중요**
Dockerfile은 리포지토리의 루트 폴더에 있어야 합니다. 워크플로의 `Docker build` 명령은 해당 파일이 있을 것으로 예상합니다.
1. 추가, 커밋 및 푸시:
```
git add .
git commit -m "add Dockerfile"
git push
```
Dockerfile이 리포지토리에 추가됩니다.
### deployment.yaml
이 섹션에서는 리포지토리에 `deployment.yaml` 파일을 추가합니다. `deployment.yaml` 파일은 '서비스'와 '배포'라는 두 가지 Kubernetes 리소스 유형 또는 *실행 유형*을 정의하는 Kubernetes 매니페스트입니다.
+ '서비스'는 Amazon EC2에 로드 밸런서를 배포합니다. 로드 밸런서는 'Hello, World\$1'를 탐색하는 데 사용할 수 있는 인터넷 연결 퍼블릭 URL 및 표준 포트(포트 80)를 제공합니다. 애플리케이션을 배포합니다.
+ '배포'는 포드 3개를 배포하며 각 포드에는 'Hello, World\$1'가 포함된 Docker 컨테이너가 포함됩니다. 애플리케이션을 배포합니다. 세 포드는 클러스터를 생성할 때 생성된 노드에 배포됩니다.
이 자습서의 매니페스트는 짧지만 매니페스트에는 포드, 작업, 수신 및 네트워크 정책과 같은 다양한 Kubernetes 리소스 유형이 포함될 수 있습니다. 또한 배포가 복잡한 경우 여러 매니페스트 파일을 사용할 수 있습니다.
**deployment.yaml 파일을 추가하려면**
1. `codecatalyst-eks-source-repository`에서 이름이 `Kubernetes`인 폴더를 생성합니다.
1. `/Kubernetes`에서 다음 콘텐츠로 `deployment.yaml` 파일을 생성합니다.
```
apiVersion: v1
kind: Service
metadata:
name: my-service
labels:
app: my-app
spec:
type: LoadBalancer
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
labels:
app: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: codecatalyst-eks-container
# The $REPOSITORY_URI and $IMAGE_TAG placeholders will be replaced by actual values supplied by the build action in your workflow
image: $REPOSITORY_URI:$IMAGE_TAG
ports:
- containerPort: 80
```
1. 추가, 커밋 및 푸시:
```
git add .
git commit -m "add Kubernetes/deployment.yaml"
git push
```
`deployment.yaml`은 `Kubernetes` 폴더의 리포지토리에 추가됩니다.
이제 모든 소스 파일을 추가했습니다.
잠시 시간을 내어 작업을 다시 확인하고 모든 파일을 올바른 폴더에 넣었는지 확인하세요. 폴더의 구조는 다음과 같습니다.
```
|— codecatalyst-eks-source-repository
|— Kubernetes
|— deployment.yaml
|— public-html
| |— index.html
|— Dockerfile
```
## 5단계: AWS 역할 생성
이 섹션에서는 CodeCatalyst 워크플로가 작동하는 데 필요한 AWS IAM 역할을 생성합니다. 이러한 역할은 다음과 같습니다.
+ **빌드 역할** - CodeCatalyst 빌드 작업(워크플로 내)에 AWS 계정에 액세스하고 Amazon ECR 및 Amazon EC2에 쓸 수 있는 권한을 부여합니다.
+ **역할 배포** - CodeCatalyst **Kubernetes 클러스터에 배포** 작업(워크플로 내)에 AWS 계정 및 Amazon EKS에 액세스할 수 있는 권한을 부여합니다.
IAM 역할에 대한 자세한 내용은 *AWS Identity and Access Management 사용 설명서*의 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 섹션을 참조하세요.
**참고**
시간을 절약하기 위해 이전에 나열한 두 역할 대신 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할이라는 단일 역할을 생성할 수 있습니다. 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에는 보안 위험을 초래할 수 있는 매우 광범위한 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다. 이 자습서에서는 이전에 나열된 두 역할을 생성하고 있다고 가정합니다.
빌드 및 배포 역할을 생성하려면 다음 절차 시리즈를 완료합니다.
**1. 두 역할에 대한 신뢰 정책을 생성하려면**
1. 개발 환경으로 이동합니다.
1. `Cloud9-long-string` 디렉터리에 다음 콘텐츠로 `codecatalyst-eks-trust-policy.json` 파일을 생성합니다.
**2. 빌드 역할에 대한 빌드 정책을 생성하려면**
+ `Cloud9-long-string` 디렉터리에 다음 콘텐츠로 `codecatalyst-eks-build-policy.json` 파일을 생성합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:*",
"ec2:*"
],
"Resource": "*"
}
]
}
```
------
**참고**
역할을 처음 사용하여 워크플로 작업을 실행할 때 리소스 정책 문에서 와일드카드를 사용한 다음, 사용 가능한 리소스 이름으로 정책 범위를 좁힙니다.
```
"Resource": "*"
```
**3. 배포 정책을 생성하고 역할을 배포하려면**
+ `Cloud9-long-string` 디렉터리에 다음 콘텐츠로 `codecatalyst-eks-deploy-policy.json` 파일을 생성합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
------
**참고**
역할을 처음 사용하여 워크플로 작업을 실행할 때 리소스 정책 문에서 와일드카드를 사용한 다음, 사용 가능한 리소스 이름으로 정책 범위를 좁힙니다.
```
"Resource": "*"
```
이제 개발 환경에 세 개의 정책 문서를 추가했습니다. 디렉터리 구조는 다음과 같습니다.
```
|— Cloud9-long-string
|— .c9
|— codecatalyst-eks-source-repository
|— Kubernetes
|— public-html
|— Dockerfile
codecatalyst-eks-build-policy.json
codecatalyst-eks-deploy-policy.json
codecatalyst-eks-trust-policy.json
```
**4. 에 빌드 정책을 추가하려면 AWS**
1. 개발 환경 터미널에 다음을 입력합니다.
```
cd /projects
```
1. 입력:
```
aws iam create-policy \
--policy-name codecatalyst-eks-build-policy \
--policy-document file://codecatalyst-eks-build-policy.json
```
1. **Enter**를 누릅니다.
1. 명령 출력에서 와 같은 `"arn":` 값을 기록해 둡니다(예: `arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy`). 나중에 이 ARN이 필요합니다.
**5. 에 배포 정책을 추가하려면 AWS**
1. 입력:
```
aws iam create-policy \
--policy-name codecatalyst-eks-deploy-policy \
--policy-document file://codecatalyst-eks-deploy-policy.json
```
1. **Enter**를 누릅니다.
1. 명령 출력에서 와 같은 `"arn":` 값을 기록해 둡니다(예: `arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy`). 나중에 이 ARN이 필요합니다.
**6. 빌드 역할을 생성하려면**
1. 입력:
```
aws iam create-role \
--role-name codecatalyst-eks-build-role \
--assume-role-policy-document file://codecatalyst-eks-trust-policy.json
```
1. **Enter**를 누릅니다.
1. 입력:
```
aws iam attach-role-policy \
--role-name codecatalyst-eks-build-role \
--policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy
```
*arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy*가 앞서 언급한 빌드 정책의 ARN으로 대체되는 경우.
1. **Enter**를 누릅니다.
1. 터미널 프롬프트에서 다음을 입력합니다.
```
aws iam get-role \
--role-name codecatalyst-eks-build-role
```
1. **Enter**를 누릅니다.
1. 역할의 `"Arn":` 값을 기록해 둡니다. 예시: `arn:aws:iam::111122223333:role/codecatalyst-eks-build-role`. 나중에 이 ARN이 필요합니다.
**7. 배포 역할을 생성하려면**
1. 입력:
```
aws iam create-role \
--role-name codecatalyst-eks-deploy-role \
--assume-role-policy-document file://codecatalyst-eks-trust-policy.json
```
1. **Enter**를 누릅니다.
1. 입력:
```
aws iam attach-role-policy \
--role-name codecatalyst-eks-deploy-role \
--policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy
```
*arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy*가 앞서 언급한 배포 정책의 ARN으로 대체되는 경우.
1. **Enter**를 누릅니다.
1. 입력:
```
aws iam get-role \
--role-name codecatalyst-eks-deploy-role
```
1. **Enter**를 누릅니다.
1. 역할의 `"Arn":` 값을 기록해 둡니다. 예시: `arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role`. 나중에 이 ARN이 필요합니다.
이제 빌드 및 배포 역할을 생성하고 해당 ARN을 기록했습니다.
## 6단계: CodeCatalyst에 AWS 역할 추가
이 단계에서는 스페이스에 AWS 계정 연결된에 빌드 역할(`codecatalyst-eks-build-role`) 및 배포 역할(`codecatalyst-eks-deploy-role`)을 추가합니다. 이렇게 하면 워크플로에서 역할을 사용할 수 있습니다.
**에 빌드 및 배포 역할을 추가하려면 AWS 계정**
1. CodeCatalyst 콘솔에서 스페이스로 이동합니다.
1. 상단에서 **설정**을 선택합니다.
1. 탐색 창에서 **AWS 계정**을 선택합니다. 계정 목록이 나타납니다.
1. **Amazon CodeCatalyst 표시 이름** 열에서 빌드 및 배포 역할을 생성한 AWS 계정 의 표시 이름을 복사합니다. (숫자일 수 있습니다.) 워크플로를 생성할 때 나중에 이 값이 필요합니다.
1. 표시 이름을 선택합니다.
1. **관리 콘솔에서 역할 AWS 관리를** 선택합니다.
**Amazon CodeCatalyst 스페이스에 IAM 역할 추가** 페이지가 나타납니다. 페이지에 액세스하려면 로그인해야 할 수 있습니다.
1. **IAM에서 생성한 기존 역할 추가**를 선택합니다.
드롭다운 목록이 나타납니다. 목록에는 빌드 및 배포 역할, `codecatalyst-runner.amazonaws.com` 및 `codecatalyst.amazonaws.com` 서비스 위탁자가 포함된 신뢰 정책이 있는 기타 IAM 역할이 표시됩니다.
1. 드롭다운 목록에서 다음을 추가합니다.
+ `codecatalyst-eks-build-role`
+ `codecatalyst-eks-deploy-role`
**참고**
`The security token included in the request is invalid`가 표시되면 적절한 권한이 없기 때문일 수 있습니다. 이 문제를 해결하려면 CodeCatalyst 스페이스를 생성할 때 사용한 AWS 계정으로 다시 로그인 AWS 하면에서 로그아웃합니다.
1. CodeCatalyst 콘솔로 돌아가 페이지를 새로 고칩니다.
이제 빌드 및 배포 역할이 **IAM 역할** 아래에 표시됩니다.
이제 CodeCatalyst 워크플로에서 이러한 역할을 사용할 수 있습니다.
## 7단계: ConfigMap 업데이트
[5단계: AWS 역할 생성](#deploy-tut-eks-roles)에서 생성한 배포 역할을 Kubernetes `ConfigMap` 파일에 추가하여 (워크플로의) **Kubernetes 클러스터에 배포** 작업에 클러스터에 액세스하고 상호 작용할 수 있는 기능을 부여해야 합니다. `eksctl` 또는 `kubectl`를 사용하여 이러한 작업을 수행할 수 있습니다.
**eksctl을 사용하여 Kubernetes ConfigMap 파일을 구성하려면**
+ 개발 환경 터미널에 다음을 입력합니다.
```
eksctl create iamidentitymapping --cluster codecatalyst-eks-cluster --arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role --group system:masters --username codecatalyst-eks-deploy-role --region us-west-2
```
위치:
+ *codecatalyst-eks-cluster*는 Amazon EKS 클러스터의 클러스터 이름으로 대체됩니다.
+ *arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role*은 [5단계: AWS 역할 생성](#deploy-tut-eks-roles)에서 생성한 배포 역할의 ARN으로 대체됩니다.
+ *codecatalyst-eks-deploy-role*(`--username` 옆)은 [5단계: AWS 역할 생성](#deploy-tut-eks-roles)에서 생성한 배포 역할의 이름으로 대체됩니다.
**참고**
배포 역할을 생성하지 않기로 결정한 경우 *codecatalyst-eks-deploy-role*을 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할 이름으로 바꿉니다. 이에 대한 자세한 내용은 [5단계: AWS 역할 생성](#deploy-tut-eks-roles) 섹션을 참조하세요.
+ *us-west-2*를 해당 리전으로 바꿉니다.
이 명령에 대한 자세한 내용은 [IAM 사용자 및 역할 관리](https://eksctl.io/usage/iam-identity-mappings/)를 참조하세요.
다음과 비슷한 메시지가 나타납니다.
```
2023-06-09 00:58:29 [ℹ] checking arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role against entries in the auth ConfigMap
2023-06-09 00:58:29 [ℹ] adding identity "arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role" to auth ConfigMap
```
**kubectl을 사용하여 Kubernetes ConfigMap 파일을 구성하려면**
1. 개발 환경 터미널에 다음을 입력합니다.
```
kubectl edit configmap -n kube-system aws-auth
```
ConfigMap 파일이 화면에 나타납니다.
1. 빨간색 기울임꼴로 텍스트를 추가합니다.
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/eksctl-codecatalyst-eks-cluster-n-NodeInstanceRole-16BC456ME6YR5
username: system:node:{{EC2PrivateDNSName}}
- groups:
- system:masters
rolearn: arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role
username: codecatalyst-eks-deploy-role
mapUsers: |
[]
kind: ConfigMap
metadata:
creationTimestamp: "2023-06-08T19:04:39Z"
managedFields:
...
```
위치:
+ *arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role*은 [5단계: AWS 역할 생성](#deploy-tut-eks-roles)에서 생성한 배포 역할의 ARN으로 대체됩니다.
+ *codecatalyst-eks-deploy-role*(`username:` 옆)은 [5단계: AWS 역할 생성](#deploy-tut-eks-roles)에서 생성한 배포 역할의 이름으로 대체됩니다.
**참고**
배포 역할을 생성하지 않기로 결정한 경우 *codecatalyst-eks-deploy-role*을 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할 이름으로 바꿉니다. 이에 대한 자세한 내용은 [5단계: AWS 역할 생성](#deploy-tut-eks-roles) 섹션을 참조하세요.
자세한 내용은 **Amazon EKS 사용 설명서**의 [클러스터에 대한 IAM 위탁자 액세스 활성화](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)를 참조하세요.
이제 배포 역할을 부여하고 **Amazon EKS에 배포** 작업을 확장하여 Kubernetes 클러스터에 대한 `system:masters` 권한을 부여했습니다.
## 8단계: 워크플로 생성 및 실행
이 단계에서는 소스 파일을 가져와 Docker 이미지로 빌드한 다음 Amazon EKS 클러스터의 트리 포드에 이미지를 배포하는 워크플로를 생성합니다.
워크플로는 순차적으로 실행되는 다음 구성 요소로 구성됩니다.
+ 트리거 - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ 빌드 작업(`BuildBackend`) - 트리거 시 작업은 Dockerfile을 사용하여 Docker 이미지를 빌드하고 Amazon ECR에 이미지를 푸시합니다. 빌드 작업은 `deployment.yaml` 파일의 `$REPOSITORY_URI` 및 `$IMAGE_TAG` 변수를 올바른 값으로 업데이트한 다음 이 파일과 `Kubernetes` 폴더의 다른 모든 출력 아티팩트를 생성합니다. 이 자습서에서 `Kubernetes` 폴더의 유일한 파일은 `deployment.yaml`이지만 더 많은 파일을 포함할 수 있습니다. 아티팩트는 배포 작업의 입력으로 사용되며, 그 다음입니다.
빌드 작업에 대한 자세한 내용은 [워크플로로 빌드하기](build-workflow-actions.md) 섹션을 참조하세요.
+ 배포 작업(`DeployToEKS`) - 빌드 작업이 완료되면 배포 작업은 빌드 작업(`Manifests`)에서 생성된 출력 아티팩트를 찾아 그 안의 `deployment.yaml` 파일을 찾습니다. 그런 다음 이 작업은 `deployment.yaml` 파일의 지침에 따라 각각 단일 'Hello, World\$1'가 포함된 세 개의 포드를 실행합니다. Docker 컨테이너 - Amazon EKS 클러스터 내부.
**워크플로 생성**
1. CodeCatalyst 콘솔로 이동합니다.
1. 프로젝트(`codecatalyst-eks-project`)로 이동합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
1. **소스 리포지토리**에서 `codecatalyst-eks-source-repository`을 선택합니다.
1. **브랜치**에서 `main`을 선택합니다.
1. **생성(Create)**을 선택합니다.
1. YAML 샘플 코드를 삭제합니다.
1. 다음 YAML 코드를 추가하여 새 워크플로 정의 파일을 생성합니다.
**참고**
워크플로 정의 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
**참고**
다음 YAML 코드에서 원하는 경우 `Connections:` 섹션을 생략할 수 있습니다. 이 섹션을 생략하는 경우 환경의 **기본 IAM 역할** 필드에 지정된 역할에 [6단계: CodeCatalyst에 AWS 역할 추가](#deploy-tut-eks-import-roles)에 설명된 두 역할의 권한 및 신뢰 정책이 포함되어 있는지 확인해야 합니다. 기본 IAM 역할이 있는 환경 설정에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
```
Name: codecatalyst-eks-workflow
SchemaVersion: 1.0
Triggers:
- Type: PUSH
Branches:
- main
Actions:
BuildBackend:
Identifier: aws/build@v1
Environment:
Name: codecatalyst-eks-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-eks-build-role
Inputs:
Sources:
- WorkflowSource
Variables:
- Name: REPOSITORY_URI
Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo
- Name: IMAGE_TAG
Value: ${WorkflowSource.CommitId}
Configuration:
Steps:
#pre_build:
- Run: echo Logging in to Amazon ECR...
- Run: aws --version
- Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com
#build:
- Run: echo Build started on `date`
- Run: echo Building the Docker image...
- Run: docker build -t $REPOSITORY_URI:latest .
- Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
#post_build:
- Run: echo Build completed on `date`
- Run: echo Pushing the Docker images...
- Run: docker push $REPOSITORY_URI:latest
- Run: docker push $REPOSITORY_URI:$IMAGE_TAG
# Replace the variables in deployment.yaml
- Run: find Kubernetes/ -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g"
- Run: find Kubernetes/ -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g"
- Run: cat Kubernetes/*
# The output artifact will be a zip file that contains Kubernetes manifest files.
Outputs:
Artifacts:
- Name: Manifests
Files:
- "Kubernetes/*"
DeployToEKS:
DependsOn:
- BuildBackend
Identifier: aws/kubernetes-deploy@v1
Environment:
Name: codecatalyst-eks-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-eks-deploy-role
Inputs:
Artifacts:
- Manifests
Configuration:
Namespace: default
Region: us-west-2
Cluster: codecatalyst-eks-cluster
Manifests: Kubernetes/
```
앞의 코드에서
+ *codecatalyst-eks-environment* 인스턴스 두 개를 모두 [사전 조건](#deploy-tut-eks-prereqs)에서 생성한 환경 이름으로 바꿉니다.
+ *codecatalyst-account-connection* 인스턴스 두 개를 모두 계정 연결의 표시 이름으로 바꿉니다. 표시 이름은 숫자일 수 있습니다. 자세한 내용은 [6단계: CodeCatalyst에 AWS 역할 추가](#deploy-tut-eks-import-roles) 섹션을 참조하세요.
+ *codecatalyst-eks-build-role*을 [5단계: AWS 역할 생성](#deploy-tut-eks-roles)에서 생성한 빌드 역할 이름으로 바꿉니다.
+ *111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo*(`Value:` 속성 내)를 [3단계: Amazon ECR 이미지 리포지토리 생성](#deploy-tut-eks-ecr)에서 생성한 Amazon ECR 리포지토리의 URI로 바꿉니다.
+ *111122223333.dkr.ecr.us-west-2.amazonaws.com*(`Run: aws ecr` 명령 내)을 이미지 접미사(`/codecatalyst-eks-image-repo`) 제외 Amazon ECR 리포지토리의 URI로 바꿉니다.
+ *codecatalyst-eks-deploy-role*을 [5단계: AWS 역할 생성](#deploy-tut-eks-roles)에서 생성한 배포 역할의 이름으로 바꿉니다.
+ AWS 리전 코드가 있는 *us-west-2*의 두 인스턴스. 리전 코드 목록은 *AWS 일반 참조*의 [리전 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html)를 참조하세요.
**참고**
빌드 및 배포 역할을 생성하지 않기로 결정한 경우 *codecatalyst-eks-build-role* 및 *codecatalyst-eks-deploy-role*을 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할 이름으로 바꿉니다. 이에 대한 자세한 내용은 [5단계: AWS 역할 생성](#deploy-tut-eks-roles) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택합니다.
1. **워크플로 커밋** 대화 상자에서 다음을 입력합니다.
1. **커밋 메시지**에서 텍스트를 제거하고 다음을 입력합니다.
```
Add first workflow
```
1. **리포지토리**에서 `codecatalyst-eks-source-repository`를 선택합니다.
1. **브랜치 이름**에서 기본을 선택합니다.
1. **커밋**을 선택합니다.
이제 워크플로를 생성했습니다. 워크플로 상단에 정의된 트리거로 인해 워크플로 실행이 자동으로 시작됩니다. 특히 `workflow.yaml` 파일을 소스 리포지토리에 커밋(및 푸시)할 때 트리거가 워크플로 실행을 시작했습니다.
**진행 중인 워크플로 실행을 보려면**
1. CodeCatalyst 콘솔의 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 방금 생성한 `codecatalyst-eks-workflow` 워크플로를 선택합니다.
1. **BuildBackend**를 선택하여 빌드 진행 상황을 확인합니다.
1. **DeployToEKS**를 선택하여 배포 진행 상황을 확인합니다.
실행 세부 정보 보기에 대한 자세한 내용은 [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md)를 참조하세요.
**배포를 확인하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 왼쪽 하단에서 **로드 밸런서**를 선택합니다.
1. Kubernetes 배포의 일부로 생성된 로드 밸런서를 선택합니다. 선택할 로드 밸런서가 확실하지 않은 경우 태그 탭에서 다음 **태그**를 찾습니다.
+ `kubernetes.io/service-name`
+ `kubernetes.io/cluster/ekstutorialcluster`
1. 올바른 로드 밸런서를 선택한 상태에서 **설명** 탭을 선택합니다.
1. **DNS 이름** 값을 복사하여 브라우저의 주소 표시줄에 붙여 넣습니다.
“Hello World\$1” 웹페이지가 브라우저에 표시되며 애플리케이션을 성공적으로 배포했음을 나타냅니다.
## 9단계: 소스 파일 변경
이 섹션에서는 소스 리포지토리의 `index.html` 파일을 변경합니다. 이 변경으로 인해 워크플로는 새 Docker 이미지를 빌드하고 커밋 ID로 태그를 지정하고 Amazon ECR에 푸시한 다음 Amazon ECS에 배포합니다.
**index.html을 변경하려면**
1. 개발 환경으로 이동합니다.
1. 터미널 프롬프트에서 소스 리포지토리로 변경합니다.
```
cd /projects/codecatalyst-eks-source-repository
```
1. 최신 워크플로 변경 사항 가져오기:
```
git pull
```
1. `codecatalyst-eks-source-repository/public-html/index.html`를 엽니다.
1. 14행에서 `Hello, World!` 텍스트를 `Tutorial complete!`로 변경합니다.
1. 추가, 커밋 및 푸시:
```
git add .
git commit -m "update index.html title"
git push
```
워크플로 실행이 자동으로 시작됩니다.
1. (선택 사항) 다음을 입력합니다.
```
git show HEAD
```
`index.html` 변경 사항에 대한 커밋 ID를 기록해 둡니다. 이 커밋 ID는 방금 시작한 워크플로 실행에 의해 배포될 Docker 이미지에 태그가 지정됩니다.
1. 배포 진행 상황 보기:
1. CodeCatalyst 콘솔의 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 최신 실행을 보려면 `codecatalyst-eks-workflow`를 선택합니다.
1. **BuildBackend** 및 **DeployToEKS**를 선택하여 워크플로 실행 진행 상황을 확인합니다.
1. 다음과 같이 애플리케이션이 업데이트되었는지 확인합니다.
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 왼쪽 하단에서 **로드 밸런서**를 선택합니다.
1. Kubernetes 배포의 일부로 생성된 로드 밸런서를 선택합니다.
1. **DNS 이름** 값을 복사하여 브라우저의 주소 표시줄에 붙여 넣습니다.
‘자습서가 완료되었습니다\$1’ 웹 페이지가 브라우저에 나타나 애플리케이션의 새 버전을 성공적으로 배포했음을 나타냅니다.
1. (선택 사항)에서 Amazon ECR 콘솔로 AWS전환하고이 절차의 7단계에서 커밋 ID로 새 Docker 이미지에 태그가 지정되었는지 확인합니다.
## 정리
이 자습서에서 사용하는 스토리지 및 컴퓨팅 리소스에 대해 불필요한 요금이 부과되지 않도록 환경을 정리해야 합니다.
**정리하려면**
1. 클러스터 삭제:
1. 개발 환경 터미널에 다음을 입력합니다.
```
eksctl delete cluster --region=us-west-2 --name=codecatalyst-eks-cluster
```
위치:
+ *us-west-2*를 해당 리전으로 바꿉니다.
+ *codecatalyst-eks-cluster*는 생성한 클러스터의 이름으로 대체됩니다.
5\$110분이 지나면 CloudFormation 스택, 노드 그룹(Amazon EC2) 및 로드 밸런서를 포함하되 이에 국한되지 않는 클러스터 및 관련 리소스가 삭제됩니다.
**중요**
`eksctl delete cluster` 명령이 작동하지 않으면 자격 AWS 증명 또는 자격 `kubectl` 증명을 새로 고쳐야 할 수 있습니다. 어떤 자격 증명을 새로 고칠지 확실하지 않은 경우 먼저 AWS 자격 증명을 새로 고칩니다. AWS 자격 증명을 새로 고치려면 ['Unable to locate credentials' 및 'ExpiredToken' 오류를 해결하려면 어떻게 해야 하나요?](troubleshooting-workflows.md#troubleshooting-workflows-auth-errors-eks) 섹션을 참조하세요. `kubectl` 자격 증명을 새로 고치려면 ['Unable to connect to the server' 오류를 해결하려면 어떻게 해야 하나요?](troubleshooting-workflows.md#troubleshooting-workflows-unable-connect-eks) 섹션을 참조하세요.
1. AWS 콘솔에서 다음과 같이 정리합니다.
1. Amazon ECR에서 `codecatalyst-eks-image-repo`를 삭제합니다.
1. IAM Identity Center에서 다음을 삭제합니다.
1. `codecatalyst-eks-user`
1. `codecatalyst-eks-permission-set`
1. IAM에서 다음을 삭제합니다.
+ `codecatalyst-eks-build-role`
+ `codecatalyst-eks-deploy-role`
+ `codecatalyst-eks-build-policy`
+ `codecatalyst-eks-deploy-policy`
1. CodeCatalyst 콘솔에서 다음과 같이 정리합니다.
1. `codecatalyst-eks-workflow`를 삭제합니다.
1. `codecatalyst-eks-environment`를 삭제합니다.
1. `codecatalyst-eks-source-repository`를 삭제합니다.
1. 개발 환경을 삭제합니다.
1. `codecatalyst-eks-project`를 삭제합니다.
이 자습서에서는 CodeCatalyst 워크플로와 **Kubernetes 클러스터에 배포** 작업을 사용하여 Amazon EKS 서비스에 애플리케이션을 배포하는 방법을 배웠습니다.
# 'Kubernetes 클러스터에 배포' 작업 추가
다음 지침을 사용하여 워크플로에 **Kubernetes 클러스터에 배포** 작업을 추가합니다.
**시작하기 전에**
워크플로에 **Kubernetes 클러스터에 배포** 작업을 추가하기 전에 다음을 준비해야 합니다.
**작은 정보**
이러한 사전 조건을 빠르게 설정하려면 [자습서: Amazon EKS에 애플리케이션 배포](deploy-tut-eks.md)의 지침을 따르세요.
+ Amazon EKS의 Kubernetes 클러스터. 클러스터에 대한 자세한 내용은 **Amazon EKS 사용 설명서**의 [Amazon EKS 클러스터](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html)을 참조하세요.
+ 애플리케이션을 Docker 이미지로 조립하는 방법을 설명하는 Dockerfile이 하나 이상 있습니다. Dockerfile에 대한 자세한 내용은 [Dockerfile 참조](https://docs.docker.com/engine/reference/builder/)를 참조하세요.
+ Kubernetes 설명서에서 *구성 파일* 또는 *구성*이라는 하나 이상의 Kubernetes 매니페스트 파일. 자세한 내용은 Kubernetes 문서의 [리소스 관리](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/)를 참조하세요.
+ **Kubernetes 클러스터에 배포** 작업에 Amazon EKS 클러스터에 액세스하고 상호 작용할 수 있는 기능을 제공하는 IAM 역할입니다. 자세한 내용은 ['Kubernetes 클러스터에 배포' 작업 YAML](deploy-action-ref-eks.md)에서 [Role](deploy-action-ref-eks.md#deploy.action.eks.environment.connections.role) 주제를 참조하세요.
이 역할을 생성한 후 다음 위치에 추가해야 합니다.
+ Kubernetes ConfigMap 파일. ConfigMap 파일에 역할을 추가하는 방법을 알아보려면 **Amazon EKS 사용 설명서**의 [클러스터에 대한 IAM 위탁자 액세스 활성화](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)를 참조하세요.
+ CodeCatalyst CodeCatalyst에 IAM 역할을 추가하는 방법은 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요.
+ CodeCatalyst 스페이스, 프로젝트 및 환경. 스페이스와 환경은 모두 애플리케이션을 배포할 AWS 계정에 연결되어야 합니다. 자세한 내용은 [스페이스 생성](spaces-create.md), [Amazon CodeCatalyst에서 빈 프로젝트 생성](projects-create.md#projects-create-empty), [AWS 계정 및 VPCs에 배포](deploy-environments.md) 섹션을 참조하세요.
+ CodeCatalyst에서 지원하는 소스 리포지토리입니다. 리포지토리는 애플리케이션 소스 파일, Dockerfiles 및 Kubernetes 매니페스트를 저장합니다. 자세한 내용은 [CodeCatalyst의 소스 리포지토리로 코드 저장 및 협업소스 리포지토리를 사용하여 코드 저장 및 협업](source.md) 섹션을 참조하세요.
------
#### [ Visual ]
**시각적 편집기를 사용하여 'Kubernetes 클러스터에 배포' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **Kubernetes에 배포 클러스터** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **Kubernetes 클러스터에 배포**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **다운로드**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['Kubernetes 클러스터에 배포' 작업 YAML](deploy-action-ref-eks.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 'Kubernetes 클러스터에 배포' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **Kubernetes에 배포 클러스터** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **Kubernetes 클러스터에 배포**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **다운로드**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['Kubernetes 클러스터에 배포' 작업 YAML](deploy-action-ref-eks.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 'Kubernetes 클러스터에 배포' 변수
**Kubernetes 클러스터에 배포** 작업은 런타임에 다음 변수를 생성하고 설정합니다. 이를 *사전 정의된 변수*라고 합니다.
워크플로에서 이러한 변수를 참조하는 방법에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
| Key(키) | 값 |
| --- | --- |
| 클러스터 | 워크플로 실행 중에 에 배포된 Amazon EKS 클러스터의 Amazon.com 리소스 이름(ARN)입니다. 예시: `arn:aws:eks:us-west-2:111122223333:cluster/codecatalyst-eks-cluster` |
| deployment-platform | 배포 플랫폼의 이름입니다. `AWS:EKS`로 하드코딩되었습니다. |
| metadata | 예약. 워크플로 실행 중에 배포된 클러스터와 관련된 JSON 형식 메타데이터입니다. |
| 네임스페이스 | 클러스터가 배포된 Kubernetes 네임스페이스입니다. 예시: `default` |
| 리소스 | 예약. 워크플로 실행 중에 배포된 리소스와 관련된 JSON 형식 메타데이터입니다. |
| 서버 | `kubectl` 같은 관리 도구를 사용하여 클러스터와 통신하는 데 사용할 수 있는 API 서버 엔드포인트의 이름입니다. 자세한 내용은 **Amazon EKS 사용 설명서**의 [Amazon EKS 클러스터 엔드포인트 액세스 제어](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html)를 참조하세요. 예시: `https://random-string.gr7.us-west-2.eks.amazonaws.com` |
# 'Kubernetes 클러스터에 배포' 작업 YAML
다음은 **Kubernetes에 배포 클러스터** 작업의 YAML 정의입니다. 이러한 작업 사용 방법을 배우려면 [워크플로를 사용하여 Amazon EKS에 배포](deploy-action-eks.md) 섹션을 참조하세요.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
DeployToKubernetesCluster\$1nn:
Identifier: aws/kubernetes-deploy@v1
DependsOn:
- build-action
Compute:
- Type: EC2 | Lambda
- Fleet: fleet-name
Timeout: timeout-minutes
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: DeployToEKS
Inputs:
# Specify a source or an artifact, but not both.
Sources:
- source-name-1
Artifacts:
- manifest-artifact
Configuration:
Namespace: namespace
Region: us-east-1
Cluster: eks-cluster
Manifests: manifest-path
```
## DeployToKubernetesCluster
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
기본값: `DeployToKubernetesCluster_nn`.
해당 UI: 구성 탭/**작업 표시 이름**
## Identifier
(*DeployToKubernetesCluster*/**Identifier**)
(필수)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
기본값: `aws/kubernetes-deploy@v1`.
해당 UI: 워크플로 다이어그램/DeployToKubernetesCluster\$1nn/**aws/kubernetes-deploy@v1** 레이블
## DependsOn
(*DeployToKubernetesCluster*/**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*DeployToKubernetesCluster*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Type
(*DeployToKubernetesCluster*/Compute/**Type**)
([Compute](#deploy.action.eks.computename) 포함 시 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 구성 탭/고급 - 선택 사항/**컴퓨팅 유형**
## Fleet
(*DeployToKubernetesCluster*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/고급 - 선택적/**컴퓨팅 플릿**
## Timeout
(*DeployToKubernetesCluster*/**Timeout**)
(선택 사항)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Environment
(*DeployToKubernetesCluster*/**Environment**)
(필수)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*DeployToKubernetesCluster*/Environment/**Name**)
([Environment](#deploy.action.eks.environment) 포함 시 필수)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*DeployToKubernetesCluster*/Environment/**Connections**)
(최신 버전의 작업에서는 선택 사항, 이전 버전에서는 필수)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Name
(*DeployToKubernetesCluster*/Environment/Connections/**Name**)
(선택 사항)
계정 연결의 이름을 지정합니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Role
(*DeployToKubernetesCluster*/Environment/Connections/**Role**)
([Connections](#deploy.action.eks.environment.connections) 포함 시 필수)
**Kubernetes 클러스터에 배포** 작업이 AWS에 액세스하는 데 사용하는 IAM 역할의 이름을 지정합니다. [CodeCatalyst 스페이스에 역할을 추가](ipa-connect-account-addroles.md)했고 역할에 다음 정책이 포함되어 있는지 확인합니다.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 다음 정책이 있는지 확인합니다.
+ 다음 권한 정책:
**주의**
다음 정책에 표시된 대로 권한을 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
------
**참고**
역할을 처음 사용할 때는 리소스 정책 설명에서 다음 와일드카드를 사용한 다음 사용 가능한 리소스 이름으로 정책의 범위를 좁힙니다.
```
"Resource": "*"
```
+ 다음 사용자 지정 신뢰 정책:
이 역할이 다음에 추가되었는지 확인합니다.
+ 계정 연결. IAM 역할을 계정 연결에 추가하는 방법에 대한 자세한 내용은 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요.
+ Kubernetes ConfigMap. ConfigMap에 IAM 역할을 추가하는 방법에 대한 자세한 내용은 `eksctl` 설명서의 [IAM 사용자 및 역할 관리를](https://eksctl.io/usage/iam-identity-mappings/) 참조하세요.
**작은 정보**
계정 연결 및 ConfigMap에 am IAM 역할을 추가하는 방법에 대한 지침은 [자습서: Amazon EKS에 애플리케이션 배포](deploy-tut-eks.md) 섹션을 참조하세요.
**참고**
원하는 경우 이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**역할**
## Inputs
(*DeployToKubernetesCluster*/**Inputs**)
([Connections](#deploy.action.eks.environment.connections) 포함 시 필수)
이 `Inputs` 섹션에서는 워크플로 실행 중 `DeployToKubernetesCluster`에 필요한 데이터를 정의합니다.
**참고**
**Amazon EKS에 배포** 작업당 하나의 입력(소스 또는 아티팩트)만 허용됩니다.
해당 UI: **입력** 탭
## Sources
(*DeployToKubernetesCluster*/Inputs/**Sources**)
(매니페스트 파일이 소스 리포지토리에 저장된 경우 필수)
Kubernetes 매니페스트 파일 또는 파일이 소스 리포지토리에 저장되는 경우 해당 소스 리포지토리의 레이블을 지정합니다. 현재, `WorkflowSource` 레이블만 지원됩니다.
매니페스트 파일이 소스 리포지토리에 포함되지 않은 경우 다른 작업에서 생성된 아티팩트에 있어야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*DeployToKubernetesCluster*/Inputs/**Artifacts**)
(매니페스트 파일이 이전 작업의 [출력 아티팩트](workflows-working-artifacts-output.md)에 저장된 경우 필수)
Kubernetes 매니페스트 파일 또는 파일이 이전 작업에서 생성된 아티팩트에 포함된 경우 여기에 해당 아티팩트를 지정합니다. 매니페스트 파일이 아티팩트 내에 포함되어 있지 않은 경우 해당 파일은 소스 리포지토리에 있어야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**아티팩트 - 선택 사항**
## Configuration
(*DeployToKubernetesCluster*/**Configuration**)
(필수)
작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## Namespace
(*DeployToKubernetesCluster*/Configuration/**Namespace**)
(선택 사항)
Kubernetes 애플리케이션을 배포할 Kubernetes 네임스페이스를 지정합니다. 클러스터에서 네임스페이스를 사용하지 않는 경우 `default`를 사용합니다. 네임스페이스에 대한 자세한 내용은 Kubernetes 설명서의 [Kubernetes 네임스페이스를 사용하여 클러스터 세분화](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#subdividing-your-cluster-using-kubernetes-namespaces)를 참조하세요.
네임스페이스를 생략하면 `default` 값이 사용됩니다.
해당 UI: 구성 탭/**네임스페이스**
## Region
(*DeployToKubernetesCluster*/Configuration/**Region**)
(필수)
Amazon EKS 클러스터 및 서비스가 상주하는 AWS 리전을 지정합니다. 리전 코드 목록은 *AWS 일반 참조*의 [리전 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)를 참조하세요.
해당 UI: 구성 탭/**리전**
## Cluster
(*DeployToKubernetesCluster*/Configuration/**Cluster**)
(필수)
기존 Amazon EKS 클러스터의 이름을 지정합니다. **Kubernetes 클러스터에 배포** 작업을 수행하면 컨테이너화된 애플리케이션이 이 클러스터에 배포됩니다. Amazon EKS 클러스터에 대한 자세한 내용은 **Amazon EKS 사용 설명서**의 [Amazon EKS 클러스터](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html)을 참조하세요.
해당 UI: 구성 탭/**클러스터**
## Manifests
(*DeployToKubernetesCluster*/Configuration/**Manifests**)
(필수)
Kubernetes 설명서에서 구성 파일, *구성 파일*, *config 파일* 또는 단순히 *구성*이라고 하는 YAML 형식의 Kubernetes 매니페스트 파일(들)의 경로를 지정합니다.
여러 매니페스트 파일을 사용하는 경우 단일 폴더에 배치하고 해당 폴더를 참조합니다. 매니페스트 파일은 Kubernetes에서 영숫자로 처리되므로 파일 이름 앞에 숫자 또는 문자가 늘어나도록 하여 처리 순서를 제어해야 합니다. 예제:
`00-namespace.yaml`
`01-deployment.yaml`
매니페스트 파일이 소스 리포지토리에 있는 경우 경로는 소스 리포지토리 루트 폴더를 기준으로 합니다. 파일이 이전 워크플로 작업의 아티팩트에 있는 경우 경로는 아티팩트 루트 폴더를 기준으로 합니다.
예시:
`Manifests/`
`deployment.yaml`
`my-deployment.yml`
와일드카드(`*`)를 사용하지 않습니다.
**참고**
[헬름 차트](https://helm.sh/docs/topics/charts/) 및 [kustomization 파일](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/)은 지원되지 않습니다.
매니페스트 파일에 대한 자세한 내용은 Kubernetes 설명서의 [리소스 구성 조직하기](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#organizing-resource-configurations) 섹션을 참조하세요.
해당 UI: 구성 탭/**매니페스트**
# CloudFormation 스택 배포
이 섹션에서는 CodeCatalyst 워크플로를 사용하여 AWS CloudFormation 스택을 배포하는 방법을 설명합니다. 이렇게 하려면 ** CloudFormation 스택 배포** 작업을 워크플로에 추가해야 합니다. 작업은 사용자가 제공한 템플릿을 AWS 기반으로 리소스의 CloudFormation 스택을에 배포합니다. 템플릿은 다음과 같을 수 있습니다.
+ CloudFormation 템플릿 - 자세한 내용은 [템플릿 작업을 CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)참조하세요.
+ AWS SAM 템플릿 - 자세한 내용은 [AWS Serverless Application Model (AWS SAM) 사양을](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html) 참조하세요.
**참고**
AWS SAM 템플릿을 사용하려면 먼저 `[sam package](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-package.html)` 작업을 사용하여 AWS SAM 애플리케이션을 패키징해야 합니다. Amazon CodeCatalyst 워크플로의 일부로 이 패키징을 자동으로 수행하는 방법을 보여주는 자습서는 [자습서: 서버리스 애플리케이션 배포](deploy-tut-lambda.md) 섹션을 참조하세요.
스택이 이미 있는 경우 작업은 CloudFormation `[CreateChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html)` 작업을 실행한 다음 `[ExecuteChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ExecuteChangeSet.html)` 작업을 실행합니다. 그러면 작업이 변경 사항이 배포될 때까지 대기한 뒤 결과에 따라 성공 또는 실패로 표시됩니다.
배포하려는 리소스가 포함된 CloudFormation 또는 AWS SAM 템플릿이 이미 있거나 AWS SAM 및와 같은 도구를 사용하여 워크플로 빌드 작업의 일부로 스택을 자동으로 생성할 계획인 경우 ** CloudFormation 스택** 배포 작업을 사용합니다[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html). [빌드 작업 추가](build-add-action.md)
CloudFormation에서 작성하거나 ** CloudFormation 스택 배포** 작업과 함께 AWS SAM 사용할 수 있는 템플릿에는 제한이 없습니다.
**작은 정보**
** CloudFormation 스택 배포** 작업을 사용하여 서버리스 애플리케이션을 배포하는 방법을 보여주는 자습서는 섹션을 참조하세요[자습서: 서버리스 애플리케이션 배포](deploy-tut-lambda.md).
**Topics**
+ ['스 CloudFormation 택 배포' 작업에서 사용하는 런타임 이미지](#deploy-action-cfn-runtime)
+ [자습서: 서버리스 애플리케이션 배포](deploy-tut-lambda.md)
+ ['스 CloudFormation 택 배포' 작업 추가](deploy-action-cfn-adding.md)
+ [롤백 구성](deploy-consumption-enable-alarms.md)
+ ['스 CloudFormation 택 배포' 변수](deploy-action-cfn-variables.md)
+ ['스 CloudFormation 택 배포' 작업 YAML](deploy-action-ref-cfn.md)
## '스 CloudFormation 택 배포' 작업에서 사용하는 런타임 이미지
** CloudFormation 스택 배포** 작업은 [2022년 11월 이미지](build-images.md#build.previous-image)에서 실행됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 단원을 참조하십시오.
# 자습서: 서버리스 애플리케이션 배포
이 자습서에서는 워크플로를 사용하여 CloudFormation 스택으로 서버리스 애플리케이션을 빌드, 테스트 및 배포하는 방법을 알아봅니다.
이 자습서의 애플리케이션은 'Hello World' 메시지를 출력하는 간단한 웹 애플리케이션입니다. AWS Lambda 함수와 Amazon API Gateway로 구성되며의 확장인 [AWS Serverless Application Model (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)를 사용하여 빌드합니다[CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html).
**Topics**
+ [사전 조건](#deploy-tut-lambda-cfn-prereqs)
+ [1단계: 소스 리포지토리 생성](#deploy-tut-lambda-cfn-source)
+ [2단계: AWS 역할 생성](#deploy-tut-lambda-cfn-roles)
+ [3단계: CodeCatalyst에 AWS 역할 추가](#deploy-tut-lambda-cfn-roles-add)
+ [4단계: Amazon S3 버킷 생성](#deploy-tut-lambda-cfn-s3)
+ [5단계: 소스 파일 추가](#deploy-tut-lambda-cfn-files)
+ [6단계: 워크플로 생성 및 실행](#deploy-tut-lambda-cfn-workflow)
+ [7단계: 변경](#deploy-tut-lambda-cfn-change)
+ [정리](#deploy-tut-lambda-cfn-clean-up)
## 사전 조건
시작하기 전:
+ 연결된 AWS 계정이 있는 CodeCatalyst **스페이스**가 필요합니다. 자세한 내용은 [스페이스 생성](spaces-create.md) 단원을 참조하십시오.
+ 스페이스에는 다음과 같은 빈 프로젝트가 필요합니다.
```
codecatalyst-cfn-project
```
**처음부터 시작** 옵션을 사용하여 이 프로젝트를 생성합니다.
자세한 내용은 [Amazon CodeCatalyst에서 빈 프로젝트 생성](projects-create.md#projects-create-empty) 섹션을 참조하세요.
+ 프로젝트에는 다음과 같은 CodeCatalyst **환경**이 필요합니다.
```
codecatalyst-cfn-environment
```
다음과 같이 이 환경을 구성합니다.
+ **비프로덕션**과 같은 유형을 선택합니다.
+ AWS 계정에 연결합니다.
+ **기본 IAM 역할**의 경우 아무 역할이나 선택합니다. 나중에 다른 역할을 지정합니다.
자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 섹션을 참조하세요.
## 1단계: 소스 리포지토리 생성
이 단계에서는 CodeCatalyst에 소스 리포지토리를 생성합니다. 이 리포지토리는 Lambda 함수 파일과 같은 자습서의 소스 파일을 저장하는 데 사용됩니다.
소스 리포지토리에 대한 자세한 정보는 [소스 리포지토리 생성](source-repositories-create.md) 섹션을 참조하세요.
**소스 리포지토리를 생성하려면**
1. CodeCatalyst의 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. **리포지토리 추가**를 선택하고 **리포지토리 생성**을 선택합니다.
1. **리포지토리 이름**에 다음과 같이 입력합니다.
```
codecatalyst-cfn-source-repository
```
1. **생성(Create)**을 선택합니다.
이제 `codecatalyst-cfn-source-repository` 리포지토리를 생성했습니다.
## 2단계: AWS 역할 생성
이 단계에서는 다음 AWS IAM 역할을 생성합니다.
+ **역할 배포** - CodeCatalyst ** CloudFormation 스택 배포** 작업에 서버리스 애플리케이션을 배포할 AWS 계정 및 CloudFormation 서비스에 액세스할 수 있는 권한을 부여합니다. ** CloudFormation 스택 배포** 작업은 워크플로의 일부입니다.
+ **빌드 역할** - CodeCatalyst 빌드 작업에 AWS 계정에 액세스하고 서버리스 애플리케이션 패키지가 저장될 Amazon S3에 쓸 수 있는 권한을 부여합니다. 빌드 작업은 워크플로의 일부입니다.
+ **스택 역할** - 나중에 제공할 AWS SAM 템플릿에 지정된 리소스를 읽고 수정할 수 있는 CloudFormation 권한을 부여합니다. 또한 CloudWatch에 권한을 부여합니다.
IAM 역할에 대한 자세한 내용은 *AWS Identity and Access Management 사용 설명서*의 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 섹션을 참조하세요.
**참고**
시간을 절약하기 위해 이전에 나열한 세 가지 역할 대신 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할이라는 단일 역할을 생성할 수 있습니다. 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에는 보안 위험을 초래할 수 있는 매우 광범위한 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다. 이 자습서에서는 이전에 나열된 세 가지 역할을 생성하고 있다고 가정합니다.
**참고**
[Lambda 실행 역할](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)도 필요하지만 5단계에서 워크플로를 실행할 때 `sam-template.yml` 파일이 생성하므로 지금 생성할 필요가 없습니다.
**배포 역할을 생성하려면**
1. 역할에 대한 정책을 다음과 같이 생성합니다.
1. 에 로그인합니다 AWS.
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **Policies**를 선택합니다.
1. **정책 생성**을 선택합니다.
1. **JSON** 탭을 선택합니다.
1. 기존 코드를 삭제합니다.
1. 다음 코드를 붙여넣습니다.
**참고**
역할을 처음 사용하여 워크플로 작업을 실행할 때 리소스 정책 문에서 와일드카드를 사용한 다음, 사용 가능한 리소스 이름으로 정책 범위를 좁힙니다.
```
"Resource": "*"
```
1. **다음: 태그**를 선택합니다.
1. **다음: 검토**를 선택합니다.
1. **이름**에 다음과 같이 입력합니다.
```
codecatalyst-deploy-policy
```
1. **정책 생성**을 선택합니다.
이제 권한 정책을 생성했습니다.
1. 다음과 같이 배포 역할을 생성합니다.
1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. **사용자 지정 신뢰 정책**을 선택합니다.
1. 기존 사용자 지정 신뢰 정책을 삭제합니다.
1. 다음 사용자 지정 신뢰 정책을 추가합니다.
1. **다음**을 선택합니다.
1. **권한 정책**에서 `codecatalyst-deploy-policy`를 검색하고 해당 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **역할 이름**에 다음과 같이 입력합니다.
```
codecatalyst-deploy-role
```
1. **역할 설명**에 다음과 같이 입력합니다.
```
CodeCatalyst deploy role
```
1. **역할 생성**을 선택합니다.
이제 신뢰 정책 및 권한 정책으로 배포 역할을 생성했습니다.
1. 다음과 같이 배포 역할 ARN을 가져옵니다.
1. 탐색 창에서 **Roles**를 선택합니다.
1. 검색 상자에 방금 생성한 역할의 이름을 입력합니다(`codecatalyst-deploy-role`).
1. 목록에서 역할을 선택합니다.
역할의 **요약** 페이지가 나타납니다.
1. 상단에서 **ARN** 값을 복사합니다.
이제 적절한 권한으로 배포 역할을 생성하고 ARN을 획득했습니다.
**빌드 역할을 생성하려면**
1. 역할에 대한 정책을 다음과 같이 생성합니다.
1. 에 로그인합니다 AWS.
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **Policies**를 선택합니다.
1. **정책 생성**을 선택합니다.
1. **JSON** 탭을 선택합니다.
1. 기존 코드를 삭제합니다.
1. 다음 코드를 붙여넣습니다.
**참고**
역할을 처음 사용하여 워크플로 작업을 실행할 때 리소스 정책 문에서 와일드카드를 사용한 다음, 사용 가능한 리소스 이름으로 정책 범위를 좁힙니다.
```
"Resource": "*"
```
1. **다음: 태그**를 선택합니다.
1. **다음: 검토**를 선택합니다.
1. **이름**에 다음과 같이 입력합니다.
```
codecatalyst-build-policy
```
1. **정책 생성**을 선택합니다.
이제 권한 정책을 생성했습니다.
1. 다음과 같이 빌드 역할을 생성합니다.
1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. **사용자 지정 신뢰 정책**을 선택합니다.
1. 기존 사용자 지정 신뢰 정책을 삭제합니다.
1. 다음 사용자 지정 신뢰 정책을 추가합니다.
1. **다음**을 선택합니다.
1. **권한 정책**에서 `codecatalyst-build-policy`를 검색하고 해당 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **역할 이름**에 다음과 같이 입력합니다.
```
codecatalyst-build-role
```
1. **역할 설명**에 다음과 같이 입력합니다.
```
CodeCatalyst build role
```
1. **역할 생성**을 선택합니다.
이제 신뢰 정책 및 권한 정책으로 빌드 역할을 생성했습니다.
1. 다음과 같이 빌드 역할 ARN을 가져옵니다.
1. 탐색 창에서 **Roles**를 선택합니다.
1. 검색 상자에 방금 생성한 역할의 이름을 입력합니다(`codecatalyst-build-role`).
1. 목록에서 역할을 선택합니다.
역할의 **요약** 페이지가 나타납니다.
1. 상단에서 **ARN** 값을 복사합니다.
이제 적절한 권한으로 빌드 역할을 생성하고 ARN을 획득했습니다.
**스택 역할을 생성하려면**
1. 스택을 배포하려는 계정을 AWS 사용하여에 로그인합니다.
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. 다음과 같이 스택 역할을 생성합니다.
1. 탐색 창에서 **Roles**를 선택합니다.
1. **역할 생성(Create role)**을 선택합니다.
1. **AWS 서비스**를 선택합니다.
1. **사용 사례** 섹션의 드롭다운 목록에서 **CloudFormation**을 선택합니다.
1. **CloudFormation** 라디오 버튼을 선택합니다.
1. 하단에서 **다음**을 선택합니다.
1. 검색 상자를 사용하여 다음 권한 정책을 찾은 다음 해당 확인란을 선택합니다.
**참고**
정책을 검색했지만 표시되지 않는 경우 **필터 지우기**를 선택하고 다시 시도해야 합니다.
+ **CloudWatchFullAccess**
+ **AWS CloudFormationFullAccess**
+ **IAMFullAccess**
+ **AWS Lambda\$1FullAccess**
+ **AmazonAPIGatewayAdministrator**
+ **AmazonS3FullAccess**
+ **AmazonEC2ContainerRegistryFullAccess**
첫 번째 정책은 경보가 발생할 때 스택 롤백을 활성화하기 위해 CloudWatch에 대한 액세스를 허용합니다.
나머지 정책은가이 자습서에서 배포할 스택의 서비스 및 리소스에 AWS SAM 액세스할 수 있도록 허용합니다. 자세한 내용은 *AWS Serverless Application Model 개발자 안내서*의 [권한](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html) 섹션을 참조하세요.
1. **다음**을 선택합니다.
1. **역할 이름**에 다음과 같이 입력합니다.
```
codecatalyst-stack-role
```
1. **역할 생성**을 선택합니다.
1. 다음과 같이 스택 역할 ARN을 가져옵니다.
1. 탐색 창에서 **Roles**를 선택합니다.
1. 검색 상자에 방금 생성한 역할의 이름을 입력합니다(`codecatalyst-stack-role`).
1. 목록에서 역할을 선택합니다.
1. **요약** 섹션에 표시된 **ARN** 값을 복사합니다. 나중에 필요합니다.
이제 적절한 권한으로 스택 역할을 생성했으며 ARN을 획득했습니다.
## 3단계: CodeCatalyst에 AWS 역할 추가
이 단계에서는 빌드 역할(`codecatalyst-build-role`)을 추가하고 스페이스의 CodeCatalyst 계정 연결에 역할(`codecatalyst-deploy-role`)을 배포합니다.
**참고**
스택 역할(`codecatalyst-stack-role`)을 연결에 추가할 필요가 없습니다. 이는 배포 역할을 사용하여 CodeCatalyst와 AWS 간에 연결이 이미 설정된 *후* *CloudFormation*(CodeCatalyst 아님)에서 스택 역할을 사용하기 때문입니다. 스택 역할은 CodeCatalyst에서 AWS에 대한 액세스 권한을 얻는 데 사용되지 않으므로 계정 연결과 연결할 필요가 없습니다.
**계정 연결에 빌드 및 배포 역할을 추가하려면**
1. CodeCatalyst에서 스페이스로 이동합니다.
1. **AWS 계정**을 선택합니다. 계정 연결 목록이 나타납니다.
1. 빌드 및 배포 역할을 생성한 계정을 나타내는 AWS 계정 연결을 선택합니다.
1. **관리 콘솔에서 역할 AWS 관리를** 선택합니다.
**Amazon CodeCatalyst 스페이스에 IAM 역할 추가** 페이지가 나타납니다. 페이지에 액세스하려면 로그인해야 할 수 있습니다.
1. **IAM에서 생성한 기존 역할 추가**를 선택합니다.
드롭다운 목록이 나타납니다. 목록에는 `codecatalyst-runner.amazonaws.com` 및 `codecatalyst.amazonaws.com` 서비스 위탁자가 포함된 신뢰 정책이 있는 모든 IAM 역할이 표시됩니다.
1. 드롭다운 목록에서 `codecatalyst-build-role`을 선택하고 **역할 추가**를 선택합니다.
1. **IAM 역할 추가**를 선택하고 **IAM에서 생성한 기존 역할 추가**를 선택한 다음 드롭다운 목록에서 `codecatalyst-deploy-role`을 선택합니다. [**Add role**]을 선택합니다.
이제 스페이스에 빌드 및 배포 역할을 추가했습니다.
1. **Amazon CodeCatalyst 표시 이름**의 값을 복사합니다. 워크플로를 생성할 때 나중에 이 값이 필요합니다.
## 4단계: Amazon S3 버킷 생성
이 단계에서는 서버리스 애플리케이션의 배포 패키지 .zip 파일을 저장하는 Amazon S3 버킷을 생성합니다.
**Amazon S3 버킷을 생성하려면**
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 기본 창에서 **버킷 생성**을 선택합니다.
1. **버킷 이름**에 다음과 같이 입력합니다.
```
codecatalyst-cfn-s3-bucket
```
1. **AWS 리전**에서 리전을 선택합니다. 이 자습서에서는 **미국 서부(오리건) us-west-2**를 선택했다고 가정합니다. Amazon S3에서 지원되는 리전에 대한 자세한 내용은 *AWS 일반 참조*의 [Amazon Simple Storage Service 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/s3.html)을 참조하세요.
1. 페이지 맨 아래에 있는 **버킷 생성** 버튼을 선택합니다.
이제 미국 서부(오리건) us-west-2 리전에 **codecatalyst-cfn-s3-bucket** 버킷을 생성했습니다.
## 5단계: 소스 파일 추가
이 단계에서는 CodeCatalyst 소스 리포지토리에 여러 애플리케이션 소스 파일을 추가합니다. `hello-world` 폴더에는 배포할 애플리케이션 파일이 포함되어 있습니다. `tests` 폴더에는 단위 테스트가 포함되어 있습니다. 폴더의 구조는 다음과 같습니다.
```
.
|— hello-world
| |— tests
| |— unit
| |— test-handler.js
| |— app.js
|— .npmignore
|— package.json
|— sam-template.yml
|— setup-sam.sh
```
### .npmignore 파일
`.npmignore` 파일은 npm이 애플리케이션 패키지에서 제외해야 하는 파일 및 폴더를 나타냅니다. 이 자습서에서는 npm이 애플리케이션의 일부가 아니기 때문에 `tests` 폴더를 제외합니다.
**.npmignore 파일을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-cfn-project` 프로젝트를 선택합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. 소스 리포지토리 목록에서 `codecatalyst-cfn-source-repository` 리포지토리를 선택합니다.
1. **파일**에서 **파일 생성**을 선택합니다.
1. **파일 이름**에 다음과 같이 입력합니다.
```
.npmignore
```
1. 다음 코드를 텍스트 상자에 입력합니다.
```
tests/*
```
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
이제 리포지토리 루트에서 `.npmignore` 파일을 생성했습니다.
### package.json 파일
`package.json` 파일에는 프로젝트 이름, 버전 번호, 설명, 종속성 및 애플리케이션과 상호 작용하고 실행하는 방법을 설명하는 기타 세부 정보와 같은 노드 프로젝트에 대한 중요한 메타데이터가 포함되어 있습니다.
`package.json` 이 자습서의 `test` 에는 종속성 목록과 스크립트가 포함되어 있습니다. 테스트 스크립트는 다음 작업을 수행합니다.
+ [mocha](https://mochajs.org/)를 사용하여 테스트 스크립트는 `hello-world/tests/unit/`에 지정된 단위 테스트를 실행하고 [xunit]() 리포터를 사용하여 `junit.xml` 파일에 결과를 기록합니다.
+ [이스탄불(nyc)](https://istanbul.js.org/)을 사용하면 테스트 스크립트가 [클로버](https://openclover.org/doc/manual/4.2.0/general--about-openclover.html) 리포터를 사용하여 코드 적용 범위 보고서(`clover.xml`)를 생성합니다. 자세한 내용은 이스탄불 설명서의 [대체 리포터 사용을](https://istanbul.js.org/docs/advanced/alternative-reporters/#clover) 참조하세요.
**package.json 파일을 추가하려면**
1. 리포지토리의 **파일**에서 **파일 생성**을 선택합니다.
1. **파일 이름**에 다음과 같이 입력합니다.
```
package.json
```
1. 다음 코드를 텍스트 상자에 입력합니다.
```
{
"name": "hello_world",
"version": "1.0.0",
"description": "hello world sample for NodeJS",
"main": "app.js",
"repository": "https://github.com/awslabs/aws-sam-cli/tree/develop/samcli/local/init/templates/cookiecutter-aws-sam-hello-nodejs",
"author": "SAM CLI",
"license": "MIT",
"dependencies": {
"axios": "^0.21.1",
"nyc": "^15.1.0"
},
"scripts": {
"test": "nyc --reporter=clover mocha hello-world/tests/unit/ --reporter xunit --reporter-option output=junit.xml"
},
"devDependencies": {
"aws-sdk": "^2.815.0",
"chai": "^4.2.0",
"mocha": "^8.2.1"
}
}
```
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
이제 리포지토리 루트에서 `package.json` 파일을 생성했습니다.
### sam-template.yml 파일
`sam-template.yml` 파일에는 Lambda 함수 및 API Gateway를 배포하고 함께 구성하는 지침이 포함되어 있습니다. [AWS Serverless Application Model 템플릿 사양을](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html) 따르는 템플릿 CloudFormation 사양을 따릅니다.
는 유용한 [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) 리소스 유형을 AWS SAM 제공하기 때문에이 자습서 AWS SAM 에서는 일반 템플릿 대신 CloudFormation 템플릿을 사용합니다. 이 유형은 기본 CloudFormation 구문을 사용하기 위해 일반적으로 작성해야 하는 보이지 않는 구성을 다수 수행합니다. 예를 들어 `AWS::Serverless::Function`은 Lambda 함수, Lambda 실행 역할 및 함수를 시작하는 이벤트 소스 매핑을 생성합니다. 기본 CloudFormation 을 사용하여 작성하려면 이 모든 것을 코딩해야 합니다.
이 자습서에서는 미리 작성된 템플릿을 사용하지만 빌드 작업을 사용하여 워크플로의 일부로 템플릿을 생성할 수 있습니다. 자세한 내용은 [CloudFormation 스택 배포](deploy-action-cfn.md) 섹션을 참조하세요.
**sam-template.yml 파일을 추가하려면**
1. 리포지토리의 **파일**에서 **파일 생성**을 선택합니다.
1. **파일 이름**에 다음과 같이 입력합니다.
```
sam-template.yml
```
1. 다음 코드를 텍스트 상자에 입력합니다.
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
serverless-api
Sample SAM Template for serverless-api
# More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
Globals:
Function:
Timeout: 3
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function # For details on this resource type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
Properties:
CodeUri: hello-world/
Handler: app.lambdaHandler
Runtime: nodejs12.x
Events:
HelloWorld:
Type: Api # For details on this event source type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
Properties:
Path: /hello
Method: get
Outputs:
# ServerlessRestApi is an implicit API created out of the events key under Serverless::Function
# Find out about other implicit resources you can reference within AWS SAM at
# https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api
HelloWorldApi:
Description: "API Gateway endpoint URL for the Hello World function"
Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
HelloWorldFunction:
Description: "Hello World Lambda function ARN"
Value: !GetAtt HelloWorldFunction.Arn
HelloWorldFunctionIamRole:
Description: "Implicit Lambda execution role created for the Hello World function"
Value: !GetAtt HelloWorldFunctionRole.Arn
```
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
이제 리포지토리의 루트 폴더 아래에 `sam-template.yml` 파일을 추가했습니다.
### setup-sam.sh 파일
`setup-sam.sh` 파일에는 AWS SAM CLI 유틸리티 다운로드 및 설치 지침이 포함되어 있습니다. 워크플로는 이 유틸리티를 사용하여 `hello-world` 소스를 패키징합니다.
**setup-sam.sh 파일을 추가하려면**
1. 리포지토리의 **파일**에서 **파일 생성**을 선택합니다.
1. **파일 이름**에 다음과 같이 입력합니다.
```
setup-sam.sh
```
1. 다음 코드를 텍스트 상자에 입력합니다.
```
#!/usr/bin/env bash
echo "Setting up sam"
yum install unzip -y
curl -LO https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip
unzip -qq aws-sam-cli-linux-x86_64.zip -d sam-installation-directory
./sam-installation-directory/install; export AWS_DEFAULT_REGION=us-west-2
```
앞의 코드에서 *us-west-2*를 AWS 리전으로 바꿉니다.
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
이제 리포지토리 루트에서 `setup-sam.sh` 파일을 생성했습니다.
### app.js 파일
`app.js`는 Lambda 함수 코드를 포함합니다. 이 자습서에서는 코드가 `hello world` 텍스트를 반환합니다.
**app.js 파일을 추가하려면**
1. 리포지토리의 **파일**에서 **파일 생성**을 선택합니다.
1. **파일 이름**에 다음과 같이 입력합니다.
```
hello-world/app.js
```
1. 다음 코드를 텍스트 상자에 입력합니다.
```
// const axios = require('axios')
// const url = 'http://checkip.amazonaws.com/';
let response;
/**
*
* Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
* @param {Object} event - API Gateway Lambda Proxy Input Format
*
* Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html
* @param {Object} context
*
* Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
* @returns {Object} object - API Gateway Lambda Proxy Output Format
*
*/
exports.lambdaHandler = async (event, context) => {
try {
// const ret = await axios(url);
response = {
'statusCode': 200,
'body': JSON.stringify({
message: 'hello world',
// location: ret.data.trim()
})
}
} catch (err) {
console.log(err);
return err;
}
return response
};
```
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
이제 `hello-world` 폴더와 `app.js` 파일을 생성했습니다.
### test-handler.js 파일
`test-handler.js` 파일에는 Lambda 함수에 대한 단위 테스트가 포함되어 있습니다.
**test-handler.js 파일을 추가하려면**
1. 리포지토리의 **파일**에서 **파일 생성**을 선택합니다.
1. **파일 이름**에 다음과 같이 입력합니다.
```
hello-world/tests/unit/test-handler.js
```
1. 다음 코드를 텍스트 상자에 입력합니다.
```
'use strict';
const app = require('../../app.js');
const chai = require('chai');
const expect = chai.expect;
var event, context;
describe('Tests index', function () {
it('verifies successful response', async () => {
const result = await app.lambdaHandler(event, context)
expect(result).to.be.an('object');
expect(result.statusCode).to.equal(200);
expect(result.body).to.be.an('string');
let response = JSON.parse(result.body);
expect(response).to.be.an('object');
expect(response.message).to.be.equal("hello world");
// expect(response.location).to.be.an("string");
});
});
```
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
이제 `hello-world/tests/unit` 폴더 아래에 `test-handler.js` 파일을 추가했습니다.
이제 모든 소스 파일을 추가했습니다.
잠시 시간을 내어 작업을 다시 확인하고 모든 파일을 올바른 폴더에 넣었는지 확인하세요. 폴더의 구조는 다음과 같습니다.
```
.
|— hello-world
| |— tests
| |— unit
| |— test-handler.js
| |— app.js
|— .npmignore
|— README.md
|— package.json
|— sam-template.yml
|— setup-sam.sh
```
## 6단계: 워크플로 생성 및 실행
이 단계에서는 Lambda 소스 코드를 패키징하고 배포하는 워크플로를 생성합니다. 워크플로는 순차적으로 실행되는 다음 구성 요소로 구성됩니다.
+ 트리거 - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ 테스트 작업(`Test`) - 트리거 시 이 작업은 [노드 패키지 관리자(npm)](https://www.npmjs.com/)를 설치한 다음 `npm run test` 명령을 실행합니다. 이 명령은 `package.json` 파일에 정의된 `test` 스크립트를 실행하도록 npm에 지시합니다. `test` 스크립트는 다시 단위 테스트를 실행하고 테스트 보고서(`junit.xml`)와 코드 적용 범위 보고서(`clover.xml`)의 두 가지 보고서를 생성합니다. 자세한 내용은 [package.json 파일](#deploy-tut-lambda-cfn-files-package-json) 섹션을 참조하세요.
다음으로 테스트 작업은 XML 보고서를 CodeCatalyst 보고서로 변환하고 테스트 작업의 **보고서** 탭 아래 CodeCatalyst 콘솔에 표시합니다.
테스트 작업에 대한 자세한 내용은 [워크플로를 사용한 테스트워크플로를 사용한 테스트](test-workflow-actions.md) 섹션을 참조하세요.
+ 빌드 작업(`BuildBackend`) - 테스트 작업이 완료되면 빌드 작업은 AWS SAM CLI를 다운로드하여 설치하고, `hello-world` 소스를 패키징하고, 패키지를 Lambda 서비스가 예상하는 Amazon S3 버킷에 복사합니다. 또한 작업은 라는 새 AWS SAM 템플릿 파일을 출력`sam-template-packaged.yml`하여 라는 출력 아티팩트에 배치합니다`buildArtifact`.
빌드 작업에 대한 자세한 내용은 [워크플로로 빌드하기](build-workflow-actions.md) 섹션을 참조하세요.
+ 배포 작업(`DeployCloudFormationStack`) - 빌드 작업이 완료되면 배포 작업은 빌드 작업()에서 생성된 출력 아티팩트를 찾고 그 안의 AWS SAM 템플릿을 `buildArtifact`찾은 다음 템플릿을 실행합니다. AWS SAM 템플릿은 서버리스 애플리케이션을 배포하는 스택을 생성합니다.
**워크플로 생성**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
1. **소스 리포지토리**에서 `codecatalyst-cfn-source-repository`을 선택합니다.
1. **브랜치**에서 `main`을 선택합니다.
1. **생성(Create)**을 선택합니다.
1. YAML 샘플 코드를 삭제합니다.
1. 다음 YAML 코드를 추가합니다.
**참고**
다음 YAML 코드에서 원하는 경우 `Connections:` 섹션을 생략할 수 있습니다. 이 섹션을 생략하는 경우 환경의 **기본 IAM 역할** 필드에 지정된 역할에 [2단계: AWS 역할 생성](#deploy-tut-lambda-cfn-roles)에 설명된 두 역할의 권한 및 신뢰 정책이 포함되어 있는지 확인해야 합니다. 기본 IAM 역할이 있는 환경 설정에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
```
Name: codecatalyst-cfn-workflow
SchemaVersion: 1.0
Triggers:
- Type: PUSH
Branches:
- main
Actions:
Test:
Identifier: aws/managed-test@v1
Inputs:
Sources:
- WorkflowSource
Outputs:
Reports:
CoverageReport:
Format: CLOVERXML
IncludePaths:
- "coverage/*"
TestReport:
Format: JUNITXML
IncludePaths:
- junit.xml
Configuration:
Steps:
- Run: npm install
- Run: npm run test
BuildBackend:
Identifier: aws/build@v1
DependsOn:
- Test
Environment:
Name: codecatalyst-cfn-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-build-role
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: . ./setup-sam.sh
- Run: sam package --template-file sam-template.yml --s3-bucket codecatalyst-cfn-s3-bucket --output-template-file sam-template-packaged.yml --region us-west-2
Outputs:
Artifacts:
- Name: buildArtifact
Files:
- "**/*"
DeployCloudFormationStack:
Identifier: aws/cfn-deploy@v1
DependsOn:
- BuildBackend
Environment:
Name: codecatalyst-cfn-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-deploy-role
Inputs:
Artifacts:
- buildArtifact
Sources: []
Configuration:
name: codecatalyst-cfn-stack
region: us-west-2
role-arn: arn:aws:iam::111122223333:role/StackRole
template: ./sam-template-packaged.yml
capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND
```
앞의 코드에서
+ *codecatalyst-cfn-environment* 인스턴스 두 개를 모두 에서 생성한 환경 이름으로 바꿉니다.
+ *codecatalyst-account-connection* 인스턴스 두 개를 모두 계정 연결의 표시 이름으로 바꿉니다. 표시 이름은 숫자일 수 있습니다. 자세한 내용은 [3단계: CodeCatalyst에 AWS 역할 추가](#deploy-tut-lambda-cfn-roles-add) 섹션을 참조하세요.
+ [2단계: AWS 역할 생성](#deploy-tut-lambda-cfn-roles)에서 생성한 빌드 역할의 이름을 갖는 *codecatalyst-build-role*.
+ [4단계: Amazon S3 버킷 생성](#deploy-tut-lambda-cfn-s3)에서 생성한 Amazon S3 버킷의 이름을 갖는 *codecatalyst-cfn-s3-bucket*입니다.
+ Amazon S3 버킷이 있는 리전(첫 번째 인스턴스)과 스택이 배포될 리전(두 번째 인스턴스)이 있는 *us-west-2*의 두 인스턴스 모두. 이러한 리전은 다를 수 있습니다. 이 자습서에서는 두 리전이 모두 `us-west-2`로 설정되어 있다고 가정합니다. Amazon S3 및에서 지원하는 리전에 대한 자세한 내용은의 서비스 엔드포인트 및 할당량을 CloudFormation참조하세요*AWS 일반 참조*. [https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [2단계: AWS 역할 생성](#deploy-tut-lambda-cfn-roles)에서 생성한 배포 역할의 이름을 갖는 *codecatalyst-deploy-role*.
+ [사전 조건](#deploy-tut-lambda-cfn-prereqs)에서 생성한 환경 이름을 갖는 *codecatalyst-cfn-environment*.
+ [2단계: AWS 역할 생성](#deploy-tut-lambda-cfn-roles)에서 생성한 스택 역할의 Amazon 리소스 이름(ARN)을 갖는 *arn:aws:iam::111122223333:role/StackRole*.
**참고**
빌드, 배포 및 스택 역할을 생성하지 않기로 결정한 경우 *codecatalyst-build-role*, *codecatalyst-deploy-role*및 *arn:aws:iam::111122223333:role/StackRole*을 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할의 이름 또는 ARN으로 바꿉니다. 이에 대한 자세한 내용은 [2단계: AWS 역할 생성](#deploy-tut-lambda-cfn-roles) 섹션을 참조하세요.
이전에 표시된 코드의 속성에 대한 자세한 내용은 섹션을 참조하세요['스 CloudFormation 택 배포' 작업 YAML](deploy-action-ref-cfn.md).
1. (선택 사항) 커밋하기 전에 YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택합니다.
1. **워크플로 커밋** 대화 상자에서 다음을 입력합니다.
1. **워크플로 파일 이름**의 경우 기본값인 `codecatalyst-cfn-workflow`를 유지합니다.
1. **커밋 메시지**에 다음을 입력합니다.
```
add initial workflow file
```
1. **리포지토리**에서 **codecatalyst-cfn-source-repositor **를 선택합니다.
1. **브랜치 이름**에서 **기본**을 선택합니다.
1. **커밋**을 선택합니다.
이제 워크플로를 생성했습니다. 워크플로 상단에 정의된 트리거로 인해 워크플로 실행이 자동으로 시작됩니다. 특히 `codecatalyst-cfn-workflow.yaml` 파일을 소스 리포지토리에 커밋(및 푸시)할 때 트리거가 워크플로 실행을 시작했습니다.
**진행 중인 워크플로 실행을 보려면**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 방금 생성한 `codecatalyst-cfn-workflow` 워크플로를 선택합니다.
1. **실행** 탭을 선택합니다.
1. **실행 ID** 열에서 실행 ID를 선택합니다.
1. **테스트**를 선택하여 테스트 진행 상황을 확인합니다.
1. **BuildBackend**를 선택하여 빌드 진행 상황을 확인합니다.
1. **DeployCloudFormationStack**을 선택하여 배포 진행 상황을 확인합니다.
실행 세부 정보 보기에 대한 자세한 내용은 [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md)를 참조하세요.
1. **DeployCloudFormationStack** 작업이 완료되면 다음을 수행합니다.
+ 워크플로 실행에 성공한 경우 다음 절차로 이동합니다.
+ **테스트** 또는 **BuildBackend** 작업에서 워크플로 실행이 실패한 경우 **로그**를 선택하여 문제를 해결합니다.
+ **DeployCloudFormationStack** 작업에서 워크플로 실행이 실패한 경우 배포 작업을 선택한 다음 **요약** 탭을 선택합니다. **CloudFormation 이벤트** 섹션으로 스크롤하여 자세한 오류 메시지를 확인합니다. 롤백이 발생한 경우 워크플로를 다시 실행하기 전에에서 CloudFormation AWS 콘솔을 통해 `codecatalyst-cfn-stack` 스택을 삭제합니다.
**배포를 확인하려면**
1. 성공적으로 배포한 후 상단 근처의 가로 메뉴 모음에서 **변수(7)**를 선택합니다. (오른쪽 창에서 **변수를** 선택하지 마세요.)
1. **HelloWorldApi** 옆에 `https://` URL을 브라우저에 붙여 넣습니다.
Lambda 함수의 **hello world** JSON 메시지가 표시되며, 이는 워크플로가 Lambda 함수 및 API Gateway를 성공적으로 배포하고 구성했음을 나타냅니다.
**작은 정보**
CodeCatalyst가 몇 가지 작은 구성으로 워크플로 다이어그램에 이 URL을 표시하도록 할 수 있습니다. 자세한 내용은 [워크플로 다이어그램에 앱 URL 표시](deploy-app-url.md) 섹션을 참조하세요.
**단위 테스트 결과 및 코드 적용 범위를 확인하려면**
1. 워크플로 다이어그램에서 **테스트**를 선택한 다음 **보고서**를 선택합니다.
1. **TestReport**를 선택하여 단위 테스트 결과를 보거나 **CoverageReport**를 선택하여 테스트 중인 파일의 코드 적용 범위 세부 정보를 봅니다. 이 경우 `app.js` 및 `test-handler.js`입니다.
**배포된 리소스를 확인하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/) API Gateway 콘솔을 엽니다.
1. AWS SAM 템플릿이 생성한 **codecatalyst-cfn-stack** API를 관찰합니다. API 이름은 워크플로 정의 파일(`codecatalyst-cfn-workflow.yaml`)의 `Configuration/name` 값에서 가져옵니다.
1. [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/) AWS Lambda 콘솔을 엽니다.
1. 탐색 창에서 **함수**를 선택합니다.
1. `codecatalyst-cfn-stack-HelloWorldFunction-string` Lambda 함수를 선택합니다.
1. API Gateway가 함수의 트리거인 방법을 확인할 수 있습니다. 이 통합은 리소스 유형에 따라 AWS SAM `AWS::Serverless::Function` 자동으로 구성되었습니다.
## 7단계: 변경
이 단계에서는 Lambda 소스 코드를 변경하고 커밋합니다. 이 커밋은 새 워크플로 실행을 시작합니다. 이 실행은 Lambda 콘솔에 지정된 기본 트래픽 이동 구성을 사용하는 청록색 체계로 새 Lambda 함수를 배포합니다.
**Lambda 소스를 변경하려면**
1. CodeCatalyst에서 프로젝트로 이동합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. `codecatalyst-cfn-source-repository` 소스 리포지토리를 선택합니다.
1. 애플리케이션 파일 변경:
1. `hello-world` 폴더를 선택합니다.
1. `app.js` 파일을 선택합니다.
1. **편집**을 선택합니다.
1. 23번 줄에서 `hello world`를 **Tutorial complete\$1**로 변경합니다.
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
커밋으로 인해 워크플로 실행이 시작됩니다. 이름 변경을 반영하도록 단위 테스트를 업데이트하지 않았기 때문에 이 실행은 실패합니다.
1. 단위 테스트를 업데이트합니다.
1. `hello-world\tests\unit\test-handler.js`을 선택합니다.
1. **편집**을 선택합니다.
1. 19번 줄에서 `hello world`를 **Tutorial complete\$1**로 변경합니다.
1. **커밋**을 선택한 다음 **커밋**을 다시 선택합니다.
커밋으로 인해 다른 워크플로 실행이 시작됩니다. 이 실행이 성공합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. `codecatalyst-cfn-workflow`를 선택한 다음 **실행**을 선택합니다.
1. 최신 실행의 실행 ID를 선택합니다. 상태는 진행 중이어야 합니다.
1. **테스트,** **BuildBackend** 및 **DeployCloudFormationStack**을 선택하여 워크플로 실행 진행 상황을 확인합니다.
1. 워크플로가 완료되면 상단 근처의 **변수(7)**를 선택합니다.
1. **HelloWorldApi** 옆에 `https://` URL을 브라우저에 붙여 넣습니다.
새 애플리케이션이 성공적으로 배포되었음을 나타내는 `Tutorial complete!` 메시지가 브라우저에 나타납니다.
## 정리
요금이 부과되지 않도록 이 자습서에서 사용하는 파일과 서비스를 정리합니다.
**CodeCatalyst 콘솔에서 정리하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-cfn-workflow`를 삭제합니다.
1. `codecatalyst-cfn-environment`를 삭제합니다.
1. `codecatalyst-cfn-source-repository`를 삭제합니다.
1. `codecatalyst-cfn-project`를 삭제합니다.
**에서 정리하려면 AWS Management Console**
1. 다음과 같이 CloudFormation에서 정리합니다.
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) CloudFormation 콘솔을 엽니다.
1. `codecatalyst-cfn-stack`를 삭제합니다.
스택을 삭제하면 API Gateway 및 Lambda 서비스에서 모든 자습서 리소스가 제거됩니다.
1. 다음과 같이 Amazon S3에서 정리합니다.
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. `codecatalyst-cfn-s3-bucket`을 선택합니다.
1. 버킷 콘텐츠를 삭제합니다.
1. 버킷을 삭제합니다.
1. 다음과 같이 IAM에서 정리합니다.
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. `codecatalyst-deploy-policy`를 삭제합니다.
1. `codecatalyst-build-policy`를 삭제합니다.
1. `codecatalyst-stack-policy`를 삭제합니다.
1. `codecatalyst-deploy-role`를 삭제합니다.
1. `codecatalyst-build-role`를 삭제합니다.
1. `codecatalyst-stack-role`를 삭제합니다.
이 자습서에서는 CodeCatalyst 워크플로 및 스택 배포 작업을 사용하여 서버리스 애플리케이션을 CloudFormation ** CloudFormation 스택으로 배포**하는 방법을 배웠습니다.
# '스 CloudFormation 택 배포' 작업 추가
다음 지침에 따라 ** CloudFormation 스택 배포** 작업을 워크플로에 추가합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 '스 CloudFormation 택 배포' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. ** CloudFormation 스택 배포** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ ** CloudFormation 스택 배포**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **다운로드**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['스 CloudFormation 택 배포' 작업 YAML](deploy-action-ref-cfn.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 '스 CloudFormation 택 배포' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. ** CloudFormation 스택 배포** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ ** CloudFormation 스택 배포**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **다운로드**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['스 CloudFormation 택 배포' 작업 YAML](deploy-action-ref-cfn.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 롤백 구성
기본적으로 ** CloudFormation 스택 배포** 작업이 실패하면 CloudFormation 가 스택을 마지막으로 알려진 안정 상태로 롤백합니다. 작업이 실패할 때뿐만 아니라 지정된 Amazon CloudWatch 경보가 발생할 때 롤백이 발생하도록 동작을 변경할 수 있습니다. CloudWatch 경보에 대한 자세한 내용을 알아보려면 *Amazon CloudWatch 사용 설명서*의 [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/)을 참조하세요.
작업이 실패할 때 CloudFormation이 스택을 롤백하지 않도록 기본 동작을 변경할 수도 있습니다.
다음 지침에 따라 롤백을 구성합니다.
**참고**
롤백을 수동으로 시작할 수 없습니다.
------
#### [ Visual ]
**시작하기 전 준비 사항**
1. 작동하는 ** CloudFormation 스택 배포** 작업이 포함된 [워크플로](workflow.md)가 있는지 확인합니다. 자세한 내용은 [CloudFormation 스택 배포](deploy-action-cfn.md) 단원을 참조하십시오.
1. **스택 배포 작업의 스택 역할 - 선택적** 필드에 지정된 역할에 **CloudWatchFullAccess** 권한을 포함해야 합니다. ** CloudFormation ** 적절한 권한이 있는 역할 생성에 대한 자세한 내용은 [2단계: AWS 역할 생성](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles)을 참조하세요.
**'스 CloudFormation 택 배포' 작업에 대한 롤백 경보를 구성하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. ** CloudFormation 스택 배포** 작업을 선택합니다.
1. 세부 정보 창에서 **구성**을 선택합니다.
1. 하단에서 **고급**을 확장합니다.
1. **경보 ARN 모니터링**에서 **경보 추가**를 선택합니다.
1. 다음 필드에 정보를 입력합니다.
+ **경보 ARN**
롤백 트리거를 추가하려면 Amazon CloudWatch 경보의 Amazon 리소스 이름(ARN)을 지정합니다. 예를 들어 `arn:aws:cloudwatch::123456789012:alarm/MyAlarm`입니다. 최대 5개의 롤백 트리거를 가질 수 있습니다.
**참고**
CloudWatch 경보 ARN을 지정하는 경우 작업이 CloudWatch에 액세스할 수 있도록 추가 권한도 구성해야 합니다. 자세한 내용은 [롤백 구성](#deploy-consumption-enable-alarms) 섹션을 참조하세요.
+ **모니터링 시간**
CloudFormation이 지정된 경보를 모니터링하는 데 걸리는 시간을 0\$1180분으로 지정합니다. 모니터링은 모든 스택 리소스가 배포된 *후* 시작됩니다. 지정된 모니터링 시간 내에 경보가 발생하면 배포가 실패하고 CloudFormation이 전체 스택 작업을 롤백합니다.
기본값: 0. CloudFormation은 스택 리소스가 배포되는 동안에만 경보를 모니터링하며 이후는 모니터링하지 않습니다.
------
#### [ YAML ]
**' CloudFormation 스택 배포' 작업에 대한 롤백 트리거를 구성하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. ** CloudFormation 스택 배포** 작업이 포함된 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. YAML 코드에 `monitor-alarm-arns` 및 `monitor-timeout-in-minutes` 속성을 추가하여 롤백 트리거를 추가합니다. 각 속성에 대한 설명은 ['스 CloudFormation 택 배포' 작업 YAML](deploy-action-ref-cfn.md) 섹션을 참조하세요.
1. ** CloudFormation 스택 배포** 작업의 `role-arn` 속성에 지정된 역할에서 **CloudWatchFullAccess** 권한을 포함해야 합니다. 적절한 권한이 있는 역할 생성에 대한 자세한 내용은 [2단계: AWS 역할 생성](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles)을 참조하세요.
------
------
#### [ Visual ]
**' CloudFormation 스택 배포' 작업에 대한 롤백을 끄려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. ** CloudFormation 스택 배포** 작업이 포함된 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. ** CloudFormation 스택 배포** 작업을 선택합니다.
1. 세부 정보 창에서 **구성**을 선택합니다.
1. 하단에서 **고급**을 확장합니다.
1. **롤백 비활성화**를 켭니다.
------
#### [ YAML ]
**' CloudFormation 스택 배포' 작업에 대한 롤백을 끄려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. ** CloudFormation 스택 배포** 작업이 포함된 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 롤백을 중지하려면 YAML 코드에 `disable-rollback: 1` 속성을 추가합니다. 이 속성에 대한 설명은 ['스 CloudFormation 택 배포' 작업 YAML](deploy-action-ref-cfn.md) 섹션을 참조하세요.
------
# '스 CloudFormation 택 배포' 변수
** CloudFormation 스택 배포** 작업은 런타임에 다음 변수를 생성하고 설정합니다. 이를 *사전 정의된 변수*라고 합니다.
워크플로에서 이러한 변수를 참조하는 방법에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
| Key(키) | 값 |
| --- | --- |
| deployment-platform | 배포 플랫폼의 이름입니다. `AWS:CloudFormation`로 하드코딩되었습니다. |
| 리전 | 워크플로 실행 중에에 배포 AWS 리전 된의 리전 코드입니다. 예시: `us-west-2` |
| stack-id | 배포 작업의 Amazon 리소스 이름(ARN)입니다. 예시: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cfn-stack/6aad4380-100a-11ec-a10a-03b8a84d40df` |
# '스 CloudFormation 택 배포' 작업 YAML
다음은 ** CloudFormation 스택 배포** 작업의 YAML 정의입니다. 이러한 작업 사용 방법을 배우려면 [CloudFormation 스택 배포](deploy-action-cfn.md) 섹션을 참조하세요.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
DeployCloudFormationStack:
Identifier: aws/cfn-deploy@v1
DependsOn:
- build-action
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
Timeout: timeout-minutes
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: DeployRole
Inputs:
Sources:
- source-name-1
Artifacts:
- CloudFormation-artifact
Configuration:
name: stack-name
region: us-west-2
template: template-path
role-arn: arn:aws:iam::123456789012:role/StackRole
capabilities: CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND
parameter-overrides: KeyOne=ValueOne,KeyTwo=ValueTwo | path-to-JSON-file
no-execute-changeset: 1|0
fail-on-empty-changeset: 1|0
disable-rollback: 1|0
termination-protection: 1|0
timeout-in-minutes: minutes
notification-arns: arn:aws:sns:us-east-1:123456789012:MyTopic,arn:aws:sns:us-east-1:123456789012:MyOtherTopic
monitor-alarm-arns: arn:aws:cloudwatch::123456789012:alarm/MyAlarm,arn:aws:cloudwatch::123456789012:alarm/MyOtherAlarm
monitor-timeout-in-minutes: minutes
tags: '[{"Key":"MyKey1","Value":"MyValue1"},{"Key":"MyKey2","Value":"MyValue2"}]'
```
## DeployCloudFormationStack
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
기본값: `DeployCloudFormationStack_nn`.
해당 UI: 구성 탭/**작업 표시 이름**
## Identifier
(*DeployCloudFormationStack*/**Identifier**)
(필수)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
기본값: `aws/cfn-deploy@v1`.
해당 UI: 워크플로 다이어그램/DeployCloudFormationStack\$1nn/**aws/cfn-deploy@v1** 레이블
## DependsOn
(*DeployCloudFormationStack*/**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*DeployCloudFormationStack*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Type
(*DeployCloudFormationStack*/Compute/**Type**)
([Compute](#deploy.action.cfn.computename) 포함 시 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 구성 탭/고급 - 선택 사항/**컴퓨팅 유형**
## Fleet
(*DeployCloudFormationStack*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/고급 - 선택적/**컴퓨팅 플릿**
## Timeout
(*DeployCloudFormationStack*/**Timeout**)
(선택 사항)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간을 분 단위로 표시 - 선택 사항 **
## Environment
(*DeployCloudFormationStack*/**Environment**)
(필수)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*DeployCloudFormationStack*/Environment/**Name**)
([Environment](#deploy.action.cfn.environment) 포함 시 필수)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*DeployCloudFormationStack*/Environment/**Connections**)
(최신 버전의 작업에서는 선택 사항, 이전 버전에서는 필수)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Name
(*DeployCloudFormationStack*/Environment/Connections/**Name**)
([Connections](#deploy.action.cfn.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Role
(*DeployCloudFormationStack*/Environment/Connections/**Role**)
([Connections](#deploy.action.cfn.environment.connections) 포함 시 필수)
** CloudFormation 스택 배포** 작업이 AWS 및 CloudFormation 서비스에 액세스하는 데 사용하는 IAM 역할의 이름을 지정합니다. [CodeCatalyst 스페이스에 역할을 추가](ipa-connect-account-addroles.md)했고 역할에 다음 정책이 포함되어 있는지 확인합니다.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 다음 정책이 있는지 확인합니다.
+ 다음 권한 정책:
**주의**
다음 정책에 표시된 대로 권한을 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
**참고**
역할을 처음 사용할 때는 리소스 정책 설명에서 다음 와일드카드를 사용한 다음 사용 가능한 리소스 이름으로 정책의 범위를 좁힙니다.
```
"Resource": "*"
```
+ 다음 사용자 지정 신뢰 정책:
**참고**
원하는 경우 이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**역할**
## Inputs
(*DeployCloudFormationStack*/**Inputs**)
(선택 사항)
이 `Inputs` 섹션에서는 워크플로 실행 중에 에 `DeployCloudFormationStack` 필요한 데이터를 정의합니다.
**참고**
** CloudFormation 스택 배포** 작업당 최대 4개의 입력(소스 1개 및 아티팩트 3개)이 허용됩니다.
서로 다른 입력(소스 및 아티팩트)에 있는 파일을 참조해야 하는 경우 소스 입력은 기본 입력이고 아티팩트는 보조 입력입니다. 보조 입력의 파일에 대한 참조는 특수 접두사를 사용하여 기본 입력에서 파일을 구분합니다. 자세한 내용은 [예시: 여러 아티팩트에서 파일 참조](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)을 참조하세요.
해당 UI: **입력** 탭
## Sources
(*DeployCloudFormationStack*/Inputs/**Sources**)
(CloudFormation 또는 AWS SAM 템플릿이 소스 리포지토리에 저장된 경우 필수)
CloudFormation 또는 AWS SAM 템플릿이 소스 리포지토리에 저장되어 있는 경우 해당 소스 리포지토리의 레이블을 지정합니다. 현재, `WorkflowSource` 레이블만 지원됩니다.
CloudFormation 또는 AWS SAM 템플릿이 소스 리포지토리에 포함되지 않은 경우 다른 작업에서 생성된 아티팩트 또는 Amazon S3 버킷에 있어야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*DeployCloudFormationStack*/Inputs/**Artifacts**)
(CloudFormation 또는 AWS SAM 템플릿이 이전 작업의 [출력 아티팩트](workflows-working-artifacts-output.md)에 저장된 경우 필수)
배포하려는 CloudFormation 또는 AWS SAM 템플릿이 이전 작업에서 생성된 아티팩트에 포함된 경우 여기에 해당 아티팩트를 지정합니다. CloudFormation 템플릿이 아티팩트 내에 포함되어 있지 않은 경우 소스 리포지토리 또는 Amazon S3 버킷에 있어야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**아티팩트 - 선택 사항**
## Configuration
(*DeployCloudFormationStack*/**Configuration**)
(필수)
작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## name
(*DeployCloudFormationStack*/Configuration/**name**)
(필수)
** CloudFormation 스택 배포** 작업이 생성하거나 업데이트하는 CloudFormation 스택의 이름을 지정합니다.
해당 UI: 구성 탭/**스택 이름**
## region
(*DeployCloudFormationStack*/Configuration/**region**)
(필수)
스택을 배포할 AWS 리전 를 지정합니다. 리전 코드 목록은 [리전 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)를 참조하세요.
해당 UI: 구성 탭/**스택 리전**
## template
(*DeployCloudFormationStack*/Configuration/**template**)
(필수)
CloudFormation 또는 AWS SAM 템플릿 파일의 이름과 경로를 지정합니다. 템플릿은 JSON 또는 YAML 형식일 수 있으며 소스 리포지토리, 이전 작업의 아티팩트 또는 Amazon S3 버킷에 상주할 수 있습니다. 템플릿 파일이 소스 리포지토리 또는 아티팩트에 있는 경우 경로는 소스 또는 아티팩트 루트를 기준으로 합니다. 템플릿이 Amazon S3 버킷에 있는 경우 경로는 템플릿의 **객체 URL** 값입니다.
예시:
`./MyFolder/MyTemplate.json`
`MyFolder/MyTemplate.yml`
`https://MyBucket.s3.us-west-2.amazonaws.com/MyTemplate.yml`
**참고**
템플릿의 파일 경로에 접두사를 추가하여 찾을 아티팩트 또는 소스를 나타내야 할 수 있습니다. 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**템플릿**
## role-arn
(*DeployCloudFormationStack*/Configuration/**role-arn**)
(필수)
스택 역할의 Amazon 리소스 이름(ARN)을 지정합니다. CloudFormation은 이 역할을 사용하여 스택의 리소스에 액세스하고 수정합니다. 예시: `arn:aws:iam::123456789012:role/StackRole`.
스택 역할에 다음이 포함되어 있는지 확인합니다.
+ 하나 이상의 권한 정책. 정책은 스택에 있는 리소스에 따라 달라집니다. 예를 들어 스택에 AWS Lambda 함수가 포함된 경우 Lambda에 대한 액세스 권한을 부여하는 권한을 추가해야 합니다. [자습서: 서버리스 애플리케이션 배포](deploy-tut-lambda.md)에 설명된 자습서를 따른 경우 일반적인 서버리스 애플리케이션 스택을 배포할 때 스택 역할에 필요한 권한을 나열하는 [스택 역할을 생성하려면](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles-stack) 프로시저가 포함됩니다.
**주의**
스택의 리소스에 액세스하기 위해 CloudFormation 서비스에 필요한 권한으로 권한을 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
+ 다음 신뢰 정책:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
필요에 따라 이 역할을 계정 연결에 연결합니다. IAM 역할을 계정 연결과 연결하는 방법에 대한 자세한 내용은 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요. 스택 역할을 계정 연결과 연결하지 않으면 스택 역할이 시각적 편집기의 **스택 역할** 드롭다운 목록에 표시되지 않지만 YAML 편집기를 사용하여 `role-arn` 필드에 역할 ARN을 계속 지정할 수 있습니다.
**참고**
원하는 경우 이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
해당 UI: 구성 탭/**스택 역할 - 선택 사항**
## capabilities
(*DeployCloudFormationStack*/Configuration/**capabilities**)
(필수)
가 특정 스택을 CloudFormation 생성하도록 허용하는 데 필요한 IAM 기능 목록을 지정합니다. 대부분의 경우 `CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND`의 기본값인 `capabilities`를 그대로 둡니다.
** CloudFormation 스택 배포** 작업의 로그에 `##[error] requires capabilities: [capability-name]` 오류가 표시되면 문제를 해결하는 방법에 대한 자세한 내용은 [IAM 기능 오류를 해결하려면 어떻게 해야 하나요?](troubleshooting-workflows.md#troubleshooting-workflows-capabilities) 섹션을 참조하세요.
IAM 기능에 대한 자세한 내용은 [IAM 사용 설명서의 CloudFormation 템플릿에서 IAM 리소스 확인을](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html#using-iam-capabilities) 참조하세요. **
해당 UI: 구성 탭/고급/**기능**
## parameter-overrides
(*DeployCloudFormationStack*/Configuration/**parameter-overrides**)
(선택 사항)
CloudFormation 또는 AWS SAM 템플릿에서 기본값이 없거나 기본값이 아닌 값을 지정하려는 파라미터를 지정합니다. 파라미터에 대한 자세한 내용은 * AWS CloudFormation 사용 설명서*의 [파라미터를](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) 참조하세요.
`parameter-overrides` 속성은 다음을 허용합니다.
+ 파라미터와 값이 포함된 JSON 파일입니다.
+ 파라미터 및 값의 쉼표로 구분된 목록입니다.
**JSON 파일을 지정하려면**
1. JSON 파일이 다음 구문 중 하나를 사용하는지 확인합니다.
```
{
"Parameters": {
"Param1": "Value1",
"Param2": "Value2",
...
}
}
```
또는…
```
[
{
"ParameterKey": "Param1",
"ParameterValue": "Value1"
},
...
]
```
(다른 구문이 있지만 작성 시 CodeCatalyst에서 지원하지 않습니다.) JSON 파일에서 CloudFormation 파라미터를 지정하는 방법에 대한 자세한 내용은 *AWS CLI 명령 참조* 의 [지원되는 JSON 구문](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudformation/deploy/index.html#supported-json-syntax)을 참조하세요.
1. 다음 형식 중 하나를 사용하여 JSON 파일의 경로를 지정합니다.
+ JSON 파일이 이전 작업의 출력 아티팩트에 있는 경우 다음을 사용합니다.
`file:///artifacts/current-action-name/output-artifact-name/path-to-json-file`
자세한 내용은 **예시 1**을 참조하세요.
+ JSON 파일이 소스 리포지토리에 있는 경우 다음을 사용합니다.
`file:///sources/WorkflowSource/path-to-json-file`
자세한 내용은 **예시 2**를 참조하세요.
**예시 1** - JSON 파일은 출력 아티팩트에 있습니다.
```
##My workflow YAML
...
Actions:
MyBuildAction:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ParamArtifact
Files:
- params.json
Configuration:
...
MyDeployCFNStackAction:
Identifier: aws/cfn-deploy@v1
Configuration:
parameter-overrides: file:///artifacts/MyDeployCFNStackAction/ParamArtifact/params.json
```
**예시 2** - JSON 파일은 소스 리포지토리의 `my/folder` 폴더에 있습니다.
```
##My workflow YAML
...
Actions:
MyDeployCloudFormationStack:
Identifier: aws/cfn-deploy@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
parameter-overrides: file:///sources/WorkflowSource/my/folder/params.json
```
**쉼표로 구분된 파라미터 목록을 사용하려면**
+ 다음 형식을 사용하여 `parameter-overrides` 속성에 파라미터 이름-값 페어를 추가합니다.
`param-1=value-1,param-2=value-2`
예를 들어 다음 CloudFormation 템플릿을 가정합니다.
```
##My CloudFormation template
Description: My CloudFormation template
Parameters:
InstanceType:
Description: Defines the Amazon EC2 compute for the production server.
Type: String
Default: t2.micro
AllowedValues:
- t2.micro
- t2.small
- t3.medium
Resources:
...
```
... 다음과 같이 `parameter-overrides` 속성을 설정할 수 있습니다.
```
##My workflow YAML
...
Actions:
...
DeployCloudFormationStack:
Identifier: aws/cfn-deploy@v1
Configuration:
parameter-overrides: InstanceType=t3.medium,UseVPC=true
```
**참고**
`undefined` 값을 사용하여 해당 값 없이 파라미터 이름을 지정할 수 있습니다. 예제:
`parameter-overrides: MyParameter=undefined`
그 효과는 스택 업데이트 중에 CloudFormation이 지정된 파라미터 이름에 기존 파라미터 값을 사용한다는 것입니다.
해당 UI:
+ 구성 탭/고급/**파라미터 재정의**
+ 구성 탭/고급/파라미터 재정의/**파일을 사용하여 재정의 지정**
+ 구성 탭/고급/파라미터 재정의/**값 세트를 사용하여 재정의 지정**
## no-execute-changeset
(*DeployCloudFormationStack*/Configuration/**no-execute-changeset**)
(선택 사항)
CodeCatalyst가 CloudFormation 변경 세트를 생성한 다음 실행하기 전에 중지할지 여부를 지정합니다. 이렇게 하면 CloudFormation 콘솔에서 변경 세트를 검토할 수 있습니다. 변경 세트가 양호한 것으로 판단되면 이 옵션을 비활성화한 다음 워크플로를 다시 실행하여 CodeCatalyst가 중지 없이 변경 세트를 생성하고 실행할 수 있도록 합니다. 기본값은 중지 없이 변경 세트를 생성하고 실행하는 것입니다. 자세한 내용은 *AWS CLI 명령* 참조의 CloudFormation [배포](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) 파라미터를 참조하세요. 변경 세트 보기에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [변경 세트 보기](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-view.html)를 참조하세요.
해당 UI: 구성 탭/고급/**변경 세트 실행 안 함**
## fail-on-empty-changeset
(*DeployCloudFormationStack*/Configuration/**fail-on-empty-changeset**)
(선택 사항)
CloudFormation 변경 세트가 비어 있는 경우 CodeCatalyst가 ** CloudFormation 스택 배포** 작업에 실패할지 여부를 지정합니다. (변경 세트가 비어 있으면 최신 배포 중에 스택에 변경 사항이 없음을 의미합니다.) 기본값은 변경 세트가 비어 있는 경우 작업을 진행하도록 허용하고 스택이 업데이트되지 않았더라도 `UPDATE_COMPLETE` 메시지를 반환하는 것입니다.
이 설정에 대한 자세한 내용은 *AWS CLI 명령* 참조의 CloudFormation [배포](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) 파라미터를 참조하세요. 변경 집합에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [변경 집합을 사용하여 스택 업데이트](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html)를 참조하세요.
해당 UI: 구성 탭/고급/**빈 변경 사항 세트 실패**
## disable-rollback
(*DeployCloudFormationStack*/Configuration/**disable-rollback**)
(선택 사항)
CodeCatalyst가 스택 배포가 실패할 경우 롤백할지 여부를 지정합니다. 롤백은 스택을 마지막으로 알려진 안정 상태로 반환합니다. 기본값은 롤백을 활성화하는 것입니다. 이 설정에 대한 자세한 내용은 *AWS CLI 명령* 참조의 CloudFormation [배포](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) 파라미터를 참조하세요.
** CloudFormation 스택 배포** 작업이 롤백을 처리하는 방법에 대한 자세한 내용은 섹션을 참조하세요[롤백 구성](deploy-consumption-enable-alarms.md).
스택 롤백에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [스택 실패 옵션](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stack-failure-options.html)을 참조하세요.
해당 UI: 구성 탭/고급/**롤백 비활성화**
## termination-protection
(*DeployCloudFormationStack*/Configuration/**termination-protection**)
(선택 사항)
**배포 스택이 배포 중인 CloudFormation 스택**에 종료 방지 기능을 추가할지 여부를 지정합니다. 종료 방지 기능이 활성화된 스택을 삭제하려고 시도하면 삭제가 실패하고 스택은 상태를 포함하여 변함없이 그대로 유지됩니다. 종료 방지 기능은 기본적으로 비활성화됩니다. 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [스택이 삭제되지 않도록 보호](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html)를 참조하세요.
해당 UI: 구성 탭/고급/**종료 보호**
## timeout-in-minutes
(*DeployCloudFormationStack*/Configuration/**timeout-in-minutes**)
(선택 사항)
스택 생성 작업 시간이 초과되어 스택 상태를 `CREATE_FAILED`로 설정하기 전에 CloudFormation이 할당해야 하는 시간(분)을 지정합니다. CloudFormation이 할당된 시간 내에 전체 스택을 생성하지 못할 경우, 시간 초과로 인해 스택 생성이 실패하고 스택이 롤백됩니다.
기본적으로 스택 생성에는 시간 초과가 없습니다. 하지만 개인 리소스에는 해당 리소스가 구현하는 서비스의 특성에 따라 자체 시간 초과가 설정될 수 있습니다. 예를 들어 스택의 개별 리소스가 시간 초과될 경우, 스택 생성에 대해 지정한 시간 초과 시간이 아직 지나지 않았더라도 스택 생성이 시간 초과됩니다.
해당 UI: 구성 탭/고급/**CloudFormation 제한 시간**
## notification-arns
(*DeployCloudFormationStack*/Configuration/**notification-arns**)
(선택 사항)
CodeCatalyst에서 알림 메시지를 보낼 Amazon SNS 주제의 ARN을 지정합니다. 예를 들어 `arn:aws:sns:us-east-1:111222333:MyTopic`입니다. ** CloudFormation 스택 배포** 작업이 실행되면 CodeCatalyst는 CloudFormation과 조정하여 스택 생성 또는 업데이트 프로세스 중에 발생하는 CloudFormation 이벤트당 하나의 알림을 보냅니다. (이 이벤트는 스택에 대한 CloudFormation 콘솔의 **이벤트** 탭에 표시됩니다.) 최대 다섯 개의 주제를 지정할 수 있습니다. 자세한 내용은 [Amazon SNS란 무엇인가?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)를 참조하세요.
해당 UI: 구성 탭/고급/**알림 ARN**
## monitor-alarm-arns
(*DeployCloudFormationStack*/Configuration/**monitor-alarm-arns**)
(선택 사항)
롤백 트리거를 추가하려면 Amazon CloudWatch 경보의 Amazon 리소스 이름(ARN)을 지정합니다. 예를 들어 `arn:aws:cloudwatch::123456789012:alarm/MyAlarm`입니다. 최대 5개의 롤백 트리거를 가질 수 있습니다.
**참고**
CloudWatch 경보 ARN을 지정하는 경우 작업이 CloudWatch에 액세스할 수 있도록 추가 권한도 구성해야 합니다. 자세한 내용은 [롤백 구성](deploy-consumption-enable-alarms.md) 섹션을 참조하세요.
해당 UI: 구성 탭/고급/**모니터 경보 ARN**
## monitor-timeout-in-minutes
(*DeployCloudFormationStack*/Configuration/**monitor-timeout-in-minutes**)
(선택 사항)
CloudFormation이 지정된 경보를 모니터링하는 데 걸리는 시간을 0\$1180분으로 지정합니다. 모니터링은 모든 스택 리소스가 배포된 *후* 시작됩니다. 지정된 모니터링 시간 내에 경보가 발생하면 배포가 실패하고 CloudFormation이 전체 스택 작업을 롤백합니다.
기본값: 0. CloudFormation은 스택 리소스가 배포되는 동안에만 경보를 모니터링하며 이후는 모니터링하지 않습니다.
해당 UI: 구성 탭/고급/**모니터링 시간**
## tags
(*DeployCloudFormationStack*/Configuration/**tags**)
(선택 사항)
CloudFormation 스택에 연결할 태그를 지정합니다. 태그는 비용 할당과 같은 용도를 위해 스택을 식별하는 데 사용할 수 있는 임의의 키-값 페어입니다. 어떤 태그를 어떤 방식으로 사용할지에 대한 자세한 내용을 알아보려면 *Amazon EC2 사용 설명서*의 [리소스에 태그 지정](https://docs.aws.amazon.com/)을 참조하세요. CloudFormation의 태그 지정에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [CloudFormation 스택 옵션 설정을](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html) 참조하세요.
키는 영숫자 문자 또는 공백을 포함할 수 있으며 최대 127자를 포함할 수 있습니다. 값은 영숫자 문자 또는 공백을 포함할 수 있으며 최대 255자를 포함할 수 있습니다.
각 스택에 대해 최대 50개의 고유 태그를 추가할 수 있습니다.
해당 UI: 구성 탭/고급/**태그**
# 워크플로를 사용하여 AWS CDK 앱 배포
이 섹션에서는 워크플로를 사용하여 AWS 계정에 AWS Cloud Development Kit (AWS CDK) 앱을 배포하는 방법을 설명합니다. 이렇게 하려면 워크플로에 **AWS CDK 배포** 작업을 추가해야 합니다. **AWS CDK 배포** 작업은 앱을 합성하고에 배포합니다 AWS Cloud Development Kit (AWS CDK) AWS. 앱 AWS이 이미에 있는 경우 필요한 경우 작업이 앱을 업데이트합니다.
를 사용하여 앱을 작성하는 방법에 대한 일반적인 내용은 란 무엇입니까?를 AWS CDK참조하세요. [AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html) *AWS Cloud Development Kit (AWS CDK) 개발자 안내서*의 .
**Topics**
+ ['AWS CDK 배포' 작업을 사용해야 하는 경우](#cdk-dep-action-when-to-use)
+ ['AWS CDK 배포' 작업의 작동 방식](#cdk-dep-action-how-it-works)
+ ['AWS CDK 배포' 작업에서 사용하는 CDK CLI 버전](#cdk-dep-action-cdk-version)
+ ['AWS CDK 배포' 작업에서 사용하는 런타임 이미지](#cdk-dep-action-runtime)
+ [작업이 배포할 수 있는 스택 수는 몇 개입니까?](#cdk-dep-action-how-many-stacks)
+ [예: AWS CDK 앱 배포](cdk-dep-action-example-workflow.md)
+ ['AWS CDK 배포' 작업 추가](cdk-dep-action-add.md)
+ ['AWS CDK 배포' 변수](cdk-dep-action-variables.md)
+ ['AWS CDK 배포' 작업 YAML](cdk-dep-action-ref.md)
## 'AWS CDK 배포' 작업을 사용해야 하는 경우
를 사용하여 앱을 개발했으며 AWS CDK이제 자동화된 지속적 통합 및 전송(CI/CD) 워크플로의 일부로 앱을 자동으로 배포하려는 경우이 작업을 사용합니다. 예를 들어 누군가 AWS CDK 앱 소스와 관련된 풀 요청을 병합할 때마다 AWS CDK 앱을 자동으로 배포할 수 있습니다.
## 'AWS CDK 배포' 작업의 작동 방식
**AWS CDK 배포**는 다음과 같이 작동합니다.
1. 런타임 시 작업 버전 1.0.12 이하를 지정한 경우 작업은 최신 CDK CLI( AWS CDK Tookit이라고도 함)를 CodeCatalyst [런타임 환경 이미지](#cdk-dep-action-runtime)로 다운로드합니다.
버전 1.0.13 이상을 지정한 경우 작업은 [특정 버전](#cdk-dep-action-cdk-version)의 CDK CLI와 번들로 제공되므로 다운로드가 발생하지 않습니다.
1. 작업은 CDK CLI를 사용하여 `cdk deploy` 명령을 실행합니다. 이 명령은 AWS CDK 앱을 합성하고에 배포합니다 AWS. 자세한 내용은 *AWS Cloud Development Kit (AWS CDK) 개발자 가이드*의 [AWS CDK 툴킷(cdk 명령)](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html)을 참조하세요.
## 'AWS CDK 배포' 작업에서 사용하는 CDK CLI 버전
다음 표에는 기본적으로 **AWS CDK 배포** 작업의 여러 버전에서 사용되는 CDK CLI 버전이 나와 있습니다.
**참고**
기본값을 재정의할 수 있습니다. 자세한 내용은 ['AWS CDK 배포' 작업 YAML](cdk-dep-action-ref.md)의 [CdkCliVersion](cdk-dep-action-ref.md#cdk.dep.cdk.cli.version) 섹션을 참조하세요.
| 'AWS CDK 배포' 작업 버전 | AWS CDK CLI 버전 |
| --- | --- |
| 1.0.0\$11.0.12 | 최신 |
| 1.0.13 이상 | 2.99.1 |
## 'AWS CDK 배포' 작업에서 사용하는 런타임 이미지
다음 표에는 CodeCatalyst가 **AWS CDK 배포** 작업의 다른 버전을 실행하는 데 사용하는 런타임 환경 이미지가 나와 있습니다. 이미지에는 사전 설치된 다양한 도구 세트가 포함됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 섹션을 참조하세요.
**참고**
2024년 3월 이미지에서 사용할 수 있는 최신 도구를 활용하려면 **AWS CDK 배포** 작업을 버전 2.x로 업그레이드하는 것이 좋습니다. 작업을 업그레이드하려면 워크플로 정의 파일에서 `Identifier` 속성을 `aws/cdk-deploy@v2`로 설정합니다. 자세한 내용은 ['AWS CDK 배포' 작업 YAML](cdk-dep-action-ref.md) 단원을 참조하십시오.
| 'AWS CDK 배포' 작업 버전 | 런타임 환경 이미지 |
| --- | --- |
| 1.x | 2022년 11월 이미지 |
| 2.x | 2024년 3월 이미지 |
## 작업이 배포할 수 있는 스택 수는 몇 개입니까?
**AWS CDK 배포**는 단일 스택만 배포할 수 있습니다. AWS CDK 앱이 여러 스택으로 구성된 경우 중첩 스택이 있는 상위 스택을 생성하고이 작업을 사용하여 상위 스택을 배포해야 합니다.
# 예: AWS CDK 앱 배포
다음 워크플로 예시에는 **AWS CDK 부트스트랩** 작업과 함께 **AWS CDK 배포** 작업이 포함됩니다. 워크플로는 순차적으로 실행되는 다음 구성 요소로 구성됩니다.
+ **트리거** - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 이 리포지토리에는 AWS CDK 앱이 포함되어 있습니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ **AWS CDK 부트스트랩** 작업(`CDKBootstrap`) - 트리거 시 작업은 `CDKToolkit` 부트스트랩 스택을에 배포합니다 AWS. `CDKToolkit` 스택이 이미 환경에 있는 경우 필요한 경우 업그레이드됩니다. 그렇지 않으면 아무 일도 발생하지 않고 작업이 성공으로 표시됩니다.
+ **AWS CDK 배포** 작업(`AWS CDK Deploy`) - **AWS CDK 부트스트랩** 작업이 완료되면 **AWS CDK 배포** 작업은 AWS CDK 앱 코드를 CloudFormation 템플릿으로 합성하고 템플릿에 정의된 스택을에 배포합니다 AWS.
**참고**
다음 워크플로 예시는 설명을 돕기 위한 참고용이며 추가 구성 없이는 작동하지 않습니다.
**참고**
다음 YAML 코드에서 원하는 경우 `Connections:` 섹션을 생략할 수 있습니다. 이러한 섹션을 생략하는 경우 환경의 **기본 IAM 역할** 필드에 지정된 역할에 **AWS CDK 부트스트랩** 및 **AWS CDK 배포** 작업에 필요한 권한 및 신뢰 정책이 포함되어 있는지 확인해야 합니다. 기본 IAM 역할이 있는 환경 설정에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요. **AWS CDK 부트스트랩** 및 **AWS CDK 배포** 작업에 필요한 권한 및 신뢰 정책에 대한 자세한 내용은 ['AWS CDK 부트스트랩' 작업 YAML](cdk-boot-action-ref.md) 및 ['AWS CDK 배포' 작업 YAML](cdk-dep-action-ref.md)의 `Role` 속성 설명을 참조하세요.
```
Name: codecatalyst-cdk-deploy-workflow
SchemaVersion: 1.0
Triggers:
- Type: PUSH
Branches:
- main
Actions:
CDKBootstrap:
Identifier: aws/cdk-bootstrap@v2
Inputs:
Sources:
- WorkflowSource
Environment:
Name: codecatalyst-cdk-deploy-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-cdk-bootstrap-role
Configuration:
Region: us-west-2
CDKDeploy:
Identifier: aws/cdk-deploy@v2
DependsOn:
- CDKBootstrap
Environment:
Name: codecatalyst-cdk-deploy-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-cdk-deploy-role
Inputs:
Sources:
- WorkflowSource
Configuration:
StackName: my-app-stack
Region: us-west-2
```
# 'AWS CDK 배포' 작업 추가
다음 지침에 따라 **AWS CDK 배포** 작업을 워크플로에 추가합니다.
**시작하기 전에**
워크플로에 **AWS CDK 배포** 작업을 추가하기 전에 다음 작업을 완료합니다.
1. ** AWS CDK 앱을 준비합니다**. 에서 지원하는 모든 프로그래밍 언어로 AWS CDK v1 또는 v2를 사용하여 AWS CDK 앱을 작성할 수 있습니다 AWS CDK. AWS CDK 앱 파일을 다음에서 사용할 수 있는지 확인합니다.
+ CodeCatalyst [소스 리포지토리](source.md) 또는
+ 다른 워크플로 작업에서 생성된 CodeCatalyst [출력 아티팩트](workflows-working-artifacts.md)
1. ** AWS 환경을 부트스트랩합니다**. 부트스트랩을 수행하려면 다음을 수행할 수 있습니다.
+ *AWS Cloud Development Kit (AWS CDK) 개발자 안내서*의 [부트스트랩 방법](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-howto)에 설명된 방법 중 하나를 사용합니다.
+ **AWS CDK 부트스트랩** 작업을 사용합니다. **AWS CDK 배포**와 동일한 워크플로 또는 다른 워크플로에서 이 작업을 추가할 수 있습니다. **AWS CDK 배포** 작업을 실행하기 전에 부트스트랩 작업이 한 번 이상 실행되어 필요한 리소스가 준비되었는지 확인하세요. **AWS CDK 부트스트랩** 작업에 대한 자세한 내용은 섹션을 참조하세요[워크플로를 사용하여 AWS CDK 앱 부트스트래핑](cdk-boot-action.md).
부트스트래핑에 대한 자세한 내용은 *AWS Cloud Development Kit (AWS CDK) 개발자 안내서*의 [부트스트래핑](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)을 참조하세요.
------
#### [ Visual ]
**시각적 편집기를 사용하여 'AWS CDK 배포' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **AWS CDK 배포** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **AWS CDK 배포**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **다운로드**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['AWS CDK 배포' 작업 YAML](cdk-dep-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
**참고**
**AWS CDK 배포** 작업이 실패하고 `npm install` 오류가 발생하는 경우 오류를 수정하는 방법에 대한 자세한 내용은 ['npm install' 오류를 해결하려면 어떻게 해야 하나요?](troubleshooting-workflows.md#troubleshooting-workflows-npm) 섹션을 참조하세요.
------
#### [ YAML ]
**YAML 편집기를 사용하여 'AWS CDK 배포' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **AWS CDK 배포** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **AWS CDK 배포**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **다운로드**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['AWS CDK 배포' 작업 YAML](cdk-dep-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
**참고**
**AWS CDK 배포** 작업이 실패하고 `npm install` 오류가 발생하는 경우 오류를 수정하는 방법에 대한 자세한 내용은 ['npm install' 오류를 해결하려면 어떻게 해야 하나요?](troubleshooting-workflows.md#troubleshooting-workflows-npm) 섹션을 참조하세요.
------
# 'AWS CDK 배포' 변수
**AWS CDK 배포** 작업은 런타임에 다음 변수를 생성하고 설정합니다. 이를 *사전 정의된 변수*라고 합니다.
워크플로에서 이러한 변수를 참조하는 방법에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
| Key(키) | 값 |
| --- | --- |
| stack-id | 워크플로 실행 중에에 배포된 AWS CDK 애플리케이션 스택의 Amazon 리소스 이름(ARN)입니다. 예시: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-app-stack/6aad4380-100a-11ec-a10a-03b8a84d40df` |
| deployment-platform | 배포 플랫폼의 이름입니다. `AWS:CloudFormation`로 하드코딩되었습니다. |
| 리전 | 워크플로 실행 중에에 배포 AWS 리전 된의 리전 코드입니다. 예시: `us-west-2` |
| SKIP-DEPLOYMENT | 값이 이면 워크플로 실행 중에 AWS CDK 애플리케이션 스택의 배포를 건너뛰었음을 `true` 나타냅니다. 마지막 배포 이후 스택에 변경 사항이 없는 경우 스택 배포를 건너뜁니다. 이 변수는 값이 `true`인 경우에만 생성됩니다. `true`로 하드코딩되었습니다. |
| *CloudFormation variables* | **AWS CDK 배포** 작업은 이전에 나열된 변수를 생성하는 것 외에도 *CloudFormation* 출력 변수를 후속 *워크플로* 작업에 사용할 워크플로 변수로 노출합니다. 기본적으로 작업은 처음 찾은 4개(또는 그 이하)의 CloudFormation 변수만 노출합니다. 어떤 배포 작업이 노출되었는지 확인하려면 **AWS CDK 배포** 작업을 한 번 실행한 다음 실행 세부 정보 페이지의 **변수** 탭을 확인합니다. 변수 탭에 나열된 변수가 원하는 변수가 아닌 경우 `CfnOutputVariables` YAML 속성을 사용하여 다른 **변수**를 구성할 수 있습니다. 자세한 내용은 ['AWS CDK 배포' 작업 YAML](cdk-dep-action-ref.md)의 [CfnOutputVariables](cdk-dep-action-ref.md#cdk.dep.cfn.out) 작업에 관한 설명을 참조하세요. |
# 'AWS CDK 배포' 작업 YAML
다음은 **AWS CDK 배포** 작업의 YAML 정의입니다. 이러한 작업 사용 방법을 배우려면 [워크플로를 사용하여 AWS CDK 앱 배포](cdk-dep-action.md) 섹션을 참조하세요.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
CDKDeploy\$1nn:
Identifier: aws/cdk-deploy@v2
DependsOn:
- CDKBootstrap
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
Timeout: timeout-minutes
Inputs:
# Specify a source or an artifact, but not both.
Sources:
- source-name-1
Artifacts:
- artifact-name
Outputs:
Artifacts:
- Name: cdk_artifact
Files:
- "cdk.out/**/*"
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Configuration:
StackName: my-cdk-stack
Region: us-west-2
Tags: '{"key1": "value1", "key2": "value2"}'
Context: '{"key1": "value1", "key2": "value2"}'
CdkCliVersion: version
CdkRootPath: directory-containing-cdk.json-file
CfnOutputVariables: '["CnfOutputKey1","CfnOutputKey2","CfnOutputKey3"]'
CloudAssemblyRootPath: path-to-cdk.out
```
## CDKDeploy
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
기본값: `CDKDeploy_nn`.
해당 UI: 구성 탭/**작업 이름**
## Identifier
(*CDKDeploy*/**Identifier**)
(필수)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
**참고**
를 지정`aws/cdk-deploy@v2`하면 Node.js 18과 같은 최신 도구가 포함된 [2024년 3월 이미지](build-images.md#build.default-image)에서 작업이 실행됩니다. 를 지정`aws/cdk-deploy@v1`하면 Node.js 16과 같은 이전 도구가 포함된 [2022년 11월 이미지](build-images.md#build.previous-image)에서 작업이 실행됩니다.
기본값: `aws/cdk-deploy@v2`.
해당 UI: 워크플로 다이어그램/CDKDeploy\$1nn/**aws/cdk-deploy@v2** 레이블
## DependsOn
(*CDKDeploy*/**DependsOn**)
(선택 사항)
**AWS CDK 배포** 작업을 실행하려면 성공적으로 실행해야 하는 작업 또는 작업 그룹을 지정합니다. 다음과 같이 `DependsOn` 속성에서 **AWS CDK 부트스트랩** 작업을 지정하는 것이 좋습니다.
```
CDKDeploy:
Identifier: aws/cdk-deploy@v2
DependsOn:
- CDKBootstrap
```
**참고**
[부트스트래핑](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)은 AWS CDK 앱을 배포하기 위한 필수 사전 조건입니다. 워크플로에 **AWS CDK 부트스트랩** 작업을 포함하지 않는 경우 **AWS CDK 배포** 작업을 실행하기 전에 AWS CDK 부트스트랩 스택을 배포할 다른 방법을 찾아야 합니다. 자세한 설명은 [워크플로를 사용하여 AWS CDK 앱 배포](cdk-dep-action.md)에서 ['AWS CDK 배포' 작업 추가](cdk-dep-action-add.md) 섹션을 참조하세요.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*CDKDeploy*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Type
(*CDKDeploy*/Compute/**Type**)
([Compute](#cdk.dep.computename) 포함 시 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 구성 탭/고급 - 선택 사항/**컴퓨팅 유형**
## Fleet
(*CDKDeploy*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/고급 - 선택적/**컴퓨팅 플릿**
## Timeout
(*CDKDeploy*/**Timeout**)
(필수)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Inputs
(*CDKDeploy*/**Inputs**)
(선택 사항)
이 `Inputs` 섹션에서는 워크플로 실행 중에 에 `CDKDeploy` 필요한 데이터를 정의합니다.
**참고**
각 **AWS CDK 배포** 작업에 대해 하나의 입력(소스 또는 아티팩트)만 허용됩니다.
해당 UI: **입력** 탭
## Sources
(*CDKDeploy*/Inputs/**Sources**)
(배포하려는 AWS CDK 앱이 소스 리포지토리에 저장된 경우 필수)
AWS CDK 앱이 소스 리포지토리에 저장된 경우 해당 소스 리포지토리의 레이블을 지정합니다. **AWS CDK 배포** 작업은 배포 프로세스를 시작하기 전에 이 리포지토리의 앱을 합성합니다. 현재, `WorkflowSource` 레이블만 지원됩니다.
AWS CDK 앱이 소스 리포지토리에 포함되지 않은 경우 다른 작업에서 생성된 아티팩트에 있어야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*CDKDeploy*/Inputs/**Artifacts**)
(배포하려는 AWS CDK 앱이 이전 작업의 [출력 아티팩트](workflows-working-artifacts-output.md)에 저장된 경우 필수)
AWS CDK 앱이 이전 작업에서 생성된 아티팩트에 포함된 경우 여기에 해당 아티팩트를 지정합니다. **AWS CDK 배포** 작업은 배포 프로세스를 시작하기 전에 지정된 아티팩트의 앱을 CloudFormation 템플릿으로 합성합니다. AWS CDK 앱이 아티팩트에 포함되지 않은 경우 앱은 소스 리포지토리에 있어야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**아티팩트 - 선택 사항**
## Outputs
(*CDKDeploy*/**Outputs**)
(선택 사항)
워크플로 실행 중에 작업에 의해 출력되는 데이터를 정의합니다.
해당 UI: **출력** 탭
## Artifacts - output
(*CDKDeploy*/Outputs/**Artifacts**
(선택 사항)
작업에서 생성된 아티팩트를 지정합니다. 이러한 아티팩트를 다른 작업의 입력으로 참조할 수 있습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/**아티팩트**
## Name
(*CDKDeploy*/Outputs/Artifacts/**Name**)
([Artifacts - output](#cdk.dep.outputs.artifacts) 포함 시 필수)
런타임 시 **AWS CDK 배포** 작업에 의해 합성되는 CloudFormation 템플릿을 포함할 아티팩트의 이름을 지정합니다. 기본값은 `cdk_artifact`입니다. 아티팩트를 지정하지 않으면 작업이 템플릿을 합성하지만 아티팩트에 저장하지는 않습니다. 테스트 또는 문제 해결을 위해 합성된 템플릿을 아티팩트에 저장하여 레코드를 보존하는 것이 좋습니다.
해당 UI: 출력 탭/아티팩트/아티팩트 추가/**빌드 아티팩트 이름**
## Files
(*CDKDeploy*/Outputs/Artifacts/**Files**)
([Artifacts - output](#cdk.dep.outputs.artifacts) 포함 시 필수)
아티팩트에 포함할 파일을 지정합니다. AWS CDK 앱의 합성된 CloudFormation 템플릿을 `"cdk.out/**/*"` 포함하도록를 지정해야 합니다.
**참고**
`cdk.out` 는 합성된 파일이 저장되는 기본 디렉터리입니다. `cdk.json` 파일에 이외의 출력 디렉터리를 지정한 경우 대신 여기에 해당 디렉터리`cdk.out`를 지정합니다`cdk.out`.
해당 UI: 출력 탭/아티팩트/아티팩트 추가/**빌드에서 생성된 파일**
## Environment
(*CDKDeploy*/**Environment**)
(필수)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*CDKDeploy*/Environment/**Name**)
([Environment](#cdk.dep.environment) 포함 시 필수)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*CDKDeploy*/Environment/**Connections**)
(최신 버전의 작업에서는 선택 사항, 이전 버전에서는 필수)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Name
(*CDKDeploy*/Environment/Connections/**Name**)
([Connections](#cdk.dep.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Role
(*CDKDeploy*/Environment/Connections/**Role**)
([Connections](#cdk.dep.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
**AWS CDK 배포** 작업이 AWS CDK 애플리케이션 스택에 액세스 AWS 하고 배포하는 데 사용하는 IAM 역할의 이름을 지정합니다. [CodeCatalyst 스페이스에 역할을 추가](ipa-connect-account-addroles.md)했고 역할에 다음 정책이 포함되어 있는지 확인합니다.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 다음 정책이 있는지 확인합니다.
+ 다음 권한 정책:
**주의**
다음 정책에 표시된 대로 권한을 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"cloudformation:DescribeStackEvents",
"cloudformation:DescribeChangeSet",
"cloudformation:DescribeStacks",
"cloudformation:ListStackResources"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/cdk-*"
}
]
}
```
------
+ 다음 사용자 지정 신뢰 정책:
**참고**
원하는 경우 이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**역할**
## Configuration
(*CDKDeploy*/**Configuration**)
(필수)
작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## StackName
(*CDKDeploy*/Configuration/**StackName**)
(필수)
AWS CDK 앱 `bin` 디렉터리의 진입점 파일에 표시되는 AWS CDK 앱 스택의 이름입니다. 다음 예시에서는 스택 이름이 *빨간색 기울임꼴*로 강조 표시된 TypeScript 진입점 파일의 내용을 보여줍니다. 진입점 파일이 다른 언어로 되어 있는 경우 비슷해 보일 것입니다.
```
import * as cdk from 'aws-cdk-lib';
import { CdkWorksopTypescriptStack } from '../lib/cdk_workshop_typescript-stack';
const app = new cdk.App();
new CdkWorkshopTypescriptStack(app, 'CdkWorkshopTypescriptStack');
```
하나의 스택만 지정할 수 있습니다.
**작은 정보**
스택이 여러 개 있는 경우 중첩 스택이 있는 상위 스택을 생성할 수 있습니다. 그런 다음 이 작업에서 상위 스택을 지정하여 모든 스택을 배포할 수 있습니다.
해당 UI: 구성 탭/**스택 이름**
## Region
(*CDKDeploy*/Configuration/**Region**)
(선택 사항)
AWS CDK 애플리케이션 스택을 배포할 AWS 리전 를 지정합니다. 리전 코드 목록은 [리전 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)를 참조하세요.
리전을 지정하지 않으면 **AWS CDK 배포** 작업이 AWS CDK 코드에 지정된 리전에 배포됩니다. 자세한 내용을 알아보려면 *AWS Cloud Development Kit (AWS CDK) 개발자 안내서*의 [환경](https://docs.aws.amazon.com/cdk/v2/guide/environments.html)을 참조하세요.
해당 UI: 구성 탭/**리전**
## Tags
(*CDKDeploy*/Configuration/**Tags**)
(선택 사항)
AWS CDK 애플리케이션 스택의 AWS 리소스에 적용할 태그를 지정합니다. 태그는 스택 자체뿐만 아니라 스택의 개별 리소스에도 적용됩니다. 태그에 대한 자세한 내용을 알아보려면 *AWS Cloud Development Kit (AWS CDK) 개발자 안내서*의 [태그 지정](https://docs.aws.amazon.com/cdk/v2/guide/tagging.html)을 참조하세요.
해당 UI: 구성 탭/고급 - 선택적/**태그**
## Context
(*CDKDeploy*/Configuration/**Context**)
(선택 사항)
AWS CDK 애플리케이션 스택과 연결할 컨텍스트를 키-값 페어 형태로 지정합니다. 컨텍스트에 대한 자세한 내용을 알아보려면 *AWS Cloud Development Kit (AWS CDK) 개발자 안내서*의 [ 런타임 컨텍스트](https://docs.aws.amazon.com/cdk/v2/guide/context.html)를 참조하세요.
해당 UI: 구성 탭/고급 - 선택 사항/**컨텍스트**
## CdkCliVersion
(*CDKDeploy*/Configuration/**CdkCliVersion**)
(선택 사항)
이 속성은 버전 1.0.13 이상의 **AWS CDK 배포** 작업과 버전 1.0.8 이상의 **AWS CDK 부트스트랩** 작업에서 사용할 수 있습니다.
다음 중 하나를 지정하세요.
+ 이 작업에서 사용할 AWS Cloud Development Kit (AWS CDK) 명령줄 인터페이스(CLI)( 도구 키트라고 AWS CDK 도 함)의 전체 버전입니다. 예시: `2.102.1`. 애플리케이션을 구축하고 배포할 때 일관성과 안정성을 보장하기 위해 전체 버전을 지정하는 것이 좋습니다.
또는
+ `latest`. CDK CLI의 최신 기능과 수정 사항을 활용하도록 `latest`를 지정하는 것이 좋습니다.
이 작업은 지정된 CLI 버전(또는 최신 버전)을 CodeCatalyst [빌드 이미지](build-images.md) AWS CDK 에 다운로드한 다음이 버전을 사용하여 CDK 애플리케이션을 배포하거나 환경을 부트스트랩 AWS 하는 데 필요한 명령을 실행합니다.
사용할 수 있는 지원되는 CDK CLI 버전 목록은 [AWS CDK 버전](https://docs.aws.amazon.com/cdk/api/versions.html) 섹션을 참조하세요.
이 속성을 생략하면 작업은 다음 주제 중 하나에 설명된 기본 AWS CDK CLI 버전을 사용합니다.
+ ['AWS CDK 배포' 작업에서 사용하는 CDK CLI 버전](cdk-dep-action.md#cdk-dep-action-cdk-version)
+ ["AWS CDK bootstrap" 작업에서 사용하는 CDK CLI 버전](cdk-boot-action.md#cdk-boot-action-cdk-version)
해당 UI: 구성 탭/**AWS CDK CLI 버전**
## CdkRootPath
(*CDKDeploy*/Configuration/**CdkRootPath**)
(선택 사항)
AWS CDK 프로젝트 `cdk.json` 파일이 포함된 디렉터리의 경로입니다. **AWS CDK 배포** 작업은 이 폴더에서 실행되며 작업에서 생성된 모든 출력이 이 디렉터리에 추가됩니다. 지정하지 않으면 **AWS CDK 배포** 작업은 `cdk.json` 파일이 AWS CDK 프로젝트의 루트에 있다고 가정합니다.
해당 UI: **cdk.json이 있는 구성 탭/디렉터리**
## CfnOutputVariables
(*CDKDeploy*/Configuration/**CfnOutputVariables**)
(선택 사항)
AWS CDK 애플리케이션 코드에서 워크플로 출력 변수로 노출하려는 `CfnOutput` 구문을 지정합니다. 그런 다음 워크플로의 후속 작업에서 워크플로 출력 변수를 참조할 수 있습니다. CodeCatalyst의 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
예를 들어 AWS CDK 애플리케이션 코드가 다음과 같은 경우:
```
import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as s3 from 'aws-cdk-lib/aws-s3';
import { Construct } from 'constructs';
import * as cdk from 'aws-cdk-lib';
export class HelloCdkStack extends Stack {
constructor(scope: Construct, id: string, props?: StackProps) {
super(scope, id, props);
const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
removalPolicy: RemovalPolicy.DESTROY,
});
new CfnOutput(this, 'bucketName', {
value: bucket.bucketName,
description: 'The name of the s3 bucket',
exportName: 'amzn-s3-demo-bucket',
});
const table = new dynamodb.Table(this, 'todos-table', {
partitionKey: {name: 'todoId', type: dynamodb.AttributeType.NUMBER},
billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
removalPolicy: RemovalPolicy.DESTROY,
})
new CfnOutput(this, 'tableName', {
value: table.tableName,
description: 'The name of the dynamodb table',
exportName: 'myDynamoDbTable',
});
...
}
}
```
...그리고 `CfnOutputVariables` 속성은 다음과 같습니다.
```
Configuration:
...
CfnOutputVariables: '["bucketName","tableName"]'
```
...그런 다음 작업은 다음과 같은 워크플로 출력 변수를 생성합니다.
| Key(키) | 값 |
| --- | --- |
| bucketName | `bucket.bucketName` |
| tableName | `table.tableName` |
그런 다음 후속 작업에서 `bucketName` 및 `tableName` 변수를 참조할 수 있습니다. 후속 작업에서 워크플로 출력 변수를 참조하는 방법을 알아보려면 [사전 정의된 변수 참조](workflows-working-with-variables-reference-output-vars.md) 섹션을 참조하세요.
`CfnOutputVariables` 속성에서 `CfnOutput` 구문을 지정하지 않으면 작업에서 워크플로 출력 변수로 찾는 처음 4개(또는 그 이하)의 CloudFormation 출력 변수가 표시됩니다. 자세한 내용은 ['AWS CDK 배포' 변수](cdk-dep-action-variables.md) 섹션을 참조하세요.
**작은 정보**
작업이 생성하는 모든 CloudFormation 출력 변수 목록을 가져오려면 **AWS CDK 배포** 작업이 포함된 워크플로를 한 번 실행한 다음 작업의 **로그** 탭을 확인합니다. 로그에는 AWS CDK 앱과 연결된 모든 CloudFormation 출력 변수 목록이 포함됩니다. 모든 CloudFormation 변수가 무엇인지 알고 나면 `CfnOutputVariables` 속성을 사용하여 워크플로 출력 변수로 변환할 변수를 지정할 수 있습니다.
CloudFormation 출력 변수에 대한 자세한 내용은 *AWS Cloud Development Kit (AWS CDK) API* 참조의 [클래스 CfnOutput(construct)](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutput.html)에서 제공되는 `CfnOutput` 구문 설명서를 참조하세요.
해당 UI: 구성 탭/**CloudFormation 출력 변수**
## CloudAssemblyRootPath
(*CDKDeploy*/Configuration/**CloudAssemblyRootPath**)
(선택 사항)
AWS CDK 앱 스택을 클라우드 어셈블리로 이미 합성한 경우( `cdk synth` 작업 사용) 클라우드 어셈블리 디렉터리의 루트 경로()를 지정합니다`cdk.out`. 지정된 클라우드 어셈블리 디렉터리에 있는 CloudFormation 템플릿은 `cdk deploy --app` 명령을 AWS 계정 사용하여 **AWS CDK 배포** 작업에 의해에 배포됩니다. `--app` 옵션이 있으면 `cdk synth` 작업이 발생하지 않습니다.
클라우드 어셈블리 디렉터리를 지정하지 않으면 **AWS CDK 배포** 작업이 `--app` 옵션 없이 `cdk deploy` 명령을 실행합니다. `--app` 옵션이 없으면 `cdk deploy` 작업은 (`cdk synth`)를 합성하고 AWS CDK 앱을에 배포합니다 AWS 계정.
**"AWS CDK 배포" 작업이 런타임에 합성을 수행할 수 있는 경우 합성된 기존 클라우드 어셈블리를 지정하는 이유는 무엇입니까?**
기존 합성 클라우드 어셈블리를 지정하여 다음을 수행할 수 있습니다.
+ **"AWS CDK 배포" 작업이 실행될 때마다 정확히 동일한 리소스 세트가 배포되는지 확인합니다.**
클라우드 어셈블리를 지정하지 않으면 **AWS CDK 배포** 작업이 실행 시점에 따라 다른 파일을 합성하고 배포할 수 있습니다. 예를 들어, **AWS CDK 배포** 작업은 테스트 단계 동안 하나의 종속성 세트와 프로덕션 단계 동안 다른 종속성 세트(단계 간에 종속성이 변경된 경우)를 사용하여 클라우드 어셈블리를 합성할 수 있습니다. 테스트 대상과 배포 대상 간의 정확한 패리티를 보장하려면 한 번 합성한 다음 **클라우드 어셈블리 디렉터리 경로** 필드(시각적 편집기) 또는 `CloudAssemblyRootPath` 속성(YAML 편집기)을 사용하여 이미 합성된 클라우드 어셈블리를 지정하는 것이 좋습니다.
+ ** AWS CDK 앱에서 비표준 패키지 관리자 및 도구 사용**
`synth` 작업 중에 **AWS CDK 배포** 작업은 npm 또는 pip와 같은 표준 도구를 사용하여 앱을 실행하려고 시도합니다. 이러한 도구를 사용하여 작업을 성공적으로 실행할 수 없는 경우 합성이 발생하지 않고 작업이 실패합니다. 이 문제를 해결하려면 앱 `cdk.json` 파일에서 AWS CDK 앱을 성공적으로 실행하는 데 필요한 정확한 명령을 지정한 다음 **AWS CDK 배포** 작업이 포함되지 않은 방법을 사용하여 앱을 합성할 수 있습니다. 클라우드 어셈블리가 생성된 후 **AWS CDK 배포** 작업의 **클라우드 어셈블리 디렉터리 경로** 필드(시각 편집기) 또는 `CloudAssemblyRootPath` 속성(YAML 편집기)에서 지정할 수 있습니다.
AWS CDK 앱을 설치하고 실행하기 위한 명령을 포함하도록 `cdk.json` 파일을 구성하는 방법에 대한 자세한 내용은 [앱 명령 지정을](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-app-command) 참조하세요.
`cdk deploy` 및 `cdk synth` 명령과 `--app` 옵션에 대한 자세한 내용은 *AWS Cloud Development Kit (AWS CDK) 개발자 안내서*의 [스택 배포](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy), [스택 합성](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-synth) 및 [합성 건너뛰기](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy-nosynth)를 참조하세요.
클라우드 어셈블리에 대한 자세한 내용은 *AWS Cloud Development Kit (AWS CDK) API 참조*의 [클라우드 어셈블리](https://docs.aws.amazon.com/cdk/api/v2/docs/cloud-assembly-schema-readme.html)를 참조하세요.
해당 UI: 구성 탭/**클라우드 어셈블리 디렉터리 경로**
# 워크플로를 사용하여 AWS CDK 앱 부트스트래핑
이 섹션에서는 CodeCatalyst 워크플로를 사용하여 AWS CDK 애플리케이션을 부트스트랩하는 방법을 설명합니다. 이렇게 하려면 워크플로에 **AWS CDK 부트스트랩** 작업을 추가해야 합니다. **AWS CDK 부트스트랩** 작업은 [최신 템플릿](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-template)을 사용하여 AWS 환경의 부트스트랩 스택을 프로비저닝합니다. 부트스트랩 스택이 이미 있는 경우 필요한 경우 작업이 해당 스택을 업데이트합니다. 에 부트스트랩 스택 AWS 이 있으면 AWS CDK 앱을 배포하기 위한 사전 조건입니다.
부트스트래핑에 대한 자세한 내용은 *AWS Cloud Development Kit (AWS CDK) 개발자 안내서*의 [부트스트래핑](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)을 참조하세요.
**Topics**
+ ['AWS CDK bootstrap' 작업을 사용해야 하는 경우](#cdk-boot-action-when-to-use)
+ ['AWS CDK 부트스트랩' 작업 작동 방식](#cdk-boot-action-how-it-works)
+ ["AWS CDK bootstrap" 작업에서 사용하는 CDK CLI 버전](#cdk-boot-action-cdk-version)
+ ['AWS CDK bootstrap' 작업에서 사용하는 런타임 이미지](#cdk-boot-action-runtime)
+ [예: AWS CDK 앱 부트스트래핑](cdk-boot-action-example-workflow.md)
+ ['AWS CDK bootstrap' 작업 추가](cdk-boot-action-add.md)
+ ['AWS CDK 부트스트랩' 변수](cdk-boot-action-variables.md)
+ ['AWS CDK 부트스트랩' 작업 YAML](cdk-boot-action-ref.md)
## 'AWS CDK bootstrap' 작업을 사용해야 하는 경우
AWS CDK 앱을 배포하는 워크플로가 있고 부트스트랩 스택을 동시에 배포(및 필요한 경우 업데이트)하려는 경우이 작업을 사용합니다. 이 경우 AWS CDK 앱을 배포하는 워크플로와 동일한 워크플로에 **AWS CDK 부트스트랩** 작업을 추가합니다.
다음 중 하나가 적용되는 경우 이 작업을 사용하지 **마세요**.
+ 다른 메커니즘을 사용하여 부트스트랩 스택을 이미 배포했으며 그대로 유지하고자 합니다(업데이트 없음).
+ **AWS CDK 부트스트랩** 작업에서 지원되지 않는 [사용자 지정 부트스트랩 템플릿](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-customizing)을 사용하려고 합니다.
## 'AWS CDK 부트스트랩' 작업 작동 방식
**AWS CDK 부트스트랩**은 다음과 같이 작동합니다.
1. 런타임 시 작업 버전 1.0.7 이하를 지정한 경우 작업은 최신 CDK CLI( AWS CDK Tookit이라고도 함)를 CodeCatalyst [빌드 이미지](build-images.md)에 다운로드합니다.
버전 1.0.8 이상을 지정한 경우 작업은 [특정 버전](cdk-dep-action.md#cdk-dep-action-cdk-version)의 CDK CLI와 번들로 제공되므로 다운로드가 발생하지 않습니다.
1. 작업은 CDK CLI를 사용하여 `cdk bootstrap` 명령을 실행합니다. 이 명령은 *AWS Cloud Development Kit (AWS CDK) 개발자 안내서*의 부트스트래핑 주제에 설명된 [부트스트래핑](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) 작업을 수행합니다.
## "AWS CDK bootstrap" 작업에서 사용하는 CDK CLI 버전
다음 표에는 **AWS CDK 부트스트랩** 작업의 다양한 버전에서 기본적으로 사용되는 CDK CLI 버전이 나와 있습니다.
**참고**
기본값을 재정의할 수 있습니다. 자세한 내용은 ['AWS CDK 부트스트랩' 작업 YAML](cdk-boot-action-ref.md)의 [CdkCliVersion](cdk-boot-action-ref.md#cdk.boot.cdk.cli.version) 섹션을 참조하세요.
| 'AWS CDK 부트스트랩' 작업 버전 | AWS CDK CLI 버전 |
| --- | --- |
| 1.0.0 – 1.0.7 | 최신 |
| 1.0.8 이상 | 2.99.1 |
## 'AWS CDK bootstrap' 작업에서 사용하는 런타임 이미지
다음 표에는 CodeCatalyst가 **AWS CDK 부트스트랩** 작업의 다른 버전을 실행하는 데 사용하는 런타임 환경 이미지가 나와 있습니다. 이미지에는 사전 설치된 다양한 도구 세트가 포함됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 섹션을 참조하세요.
**참고**
2024년 3월 이미지에서 사용할 수 있는 최신 도구를 활용하려면 **AWS CDK 부트스트랩** 작업을 버전 2.x로 업그레이드하는 것이 좋습니다. 작업을 업그레이드하려면 워크플로 정의 파일에서 `Identifier` 속성을 `aws/cdk-bootstrap@v2`로 설정합니다. 자세한 내용은 ['AWS CDK 배포' 작업 YAML](cdk-dep-action-ref.md) 단원을 참조하십시오.
| 'AWS CDK 부트스트랩' 작업 버전 | 런타임 환경 이미지 |
| --- | --- |
| 1.x | 2022년 11월 이미지 |
| 2.x | 2024년 3월 이미지 |
# 예: AWS CDK 앱 부트스트래핑
**AWS CDK 부트스트랩** 작업이 포함된 워크플로는 [워크플로를 사용하여 AWS CDK 앱 배포](cdk-dep-action.md)의 [예: AWS CDK 앱 배포](cdk-dep-action-example-workflow.md)를 참조하세요.
# 'AWS CDK bootstrap' 작업 추가
다음 지침에 따라 **AWS CDK 부트스트랩** 작업을 워크플로에 추가합니다.
**시작하기 전에**
**AWS CDK 부트스트랩** 작업을 사용하려면 먼저 AWS CDK 앱이 준비되었는지 확인하세요. 부트스트랩 작업은 부트스트랩 전에 AWS CDK 앱을 합성합니다. AWS CDK에서 지원하는 모든 프로그래밍 언어로 앱을 작성할 수 있습니다.
AWS CDK 앱 파일을 다음에서 사용할 수 있는지 확인합니다.
+ CodeCatalyst [소스 리포지토리](source.md) 또는
+ 다른 워크플로 작업에서 생성된 CodeCatalyst [출력 아티팩트](workflows-working-artifacts.md)
------
#### [ Visual ]
**시각적 편집기를 사용하여 'AWS CDK bootstrap' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **AWS CDK 부트스트랩** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **AWS CDK 부트스트랩**을 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력,** **구성** 및 **출력** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['AWS CDK 부트스트랩' 작업 YAML](cdk-boot-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
**참고**
**AWS CDK 부트스트랩** 작업이 실패하고 `npm install` 오류가 발생하는 경우 오류를 수정하는 방법에 대한 자세한 내용은 ['npm install' 오류를 해결하려면 어떻게 해야 하나요?](troubleshooting-workflows.md#troubleshooting-workflows-npm) 섹션을 참조하세요.
------
#### [ YAML ]
**YAML 편집기를 사용하여 'AWS CDK bootstrap' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **AWS CDK 부트스트랩** 작업을 검색하고 **\$1**를 선택하여 워크플로 다이어그램에 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['AWS CDK 부트스트랩' 작업 YAML](cdk-boot-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
**참고**
**AWS CDK 부트스트랩** 작업이 실패하고 `npm install` 오류가 발생하는 경우 오류를 수정하는 방법에 대한 자세한 내용은 ['npm install' 오류를 해결하려면 어떻게 해야 하나요?](troubleshooting-workflows.md#troubleshooting-workflows-npm) 섹션을 참조하세요.
------
# 'AWS CDK 부트스트랩' 변수
**AWS CDK 부트스트랩** 작업은 런타임에 다음 변수를 생성하고 설정합니다. 이를 *사전 정의된 변수*라고 합니다.
워크플로에서 이러한 변수를 참조하는 방법에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
| Key(키) | 값 |
| --- | --- |
| deployment-platform | 배포 플랫폼의 이름입니다. `AWS:CloudFormation`로 하드코딩되었습니다. |
| 리전 | 워크플로 실행 중에 AWS CDK 부트스트랩 스택 AWS 리전 이 배포된의 리전 코드입니다. 예시: `us-west-2` |
| stack-id | 배포된 AWS CDK 부트스트랩 스택의 Amazon 리소스 이름(ARN)입니다. 예시: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-bootstrap-stack/6aad4380-100a-11ec-a10a-03b8a84d40df` |
| SKIP-DEPLOYMENT | 값이 이면 워크플로 실행 중에 AWS CDK 부트스트랩 스택의 배포를 건너뛰었음을 `true` 나타냅니다. 마지막 배포 이후 스택에 변경 사항이 없는 경우 스택 배포를 건너뜁니다. 이 변수는 값이 `true`인 경우에만 생성됩니다. `true`로 하드코딩되었습니다. |
# 'AWS CDK 부트스트랩' 작업 YAML
다음은 **AWS CDK 부트스트랩** 작업의 YAML 정의입니다. 이러한 작업 사용 방법을 배우려면 [워크플로를 사용하여 AWS CDK 앱 부트스트래핑](cdk-boot-action.md) 섹션을 참조하세요.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
CDKBootstrapAction\$1nn:
Identifier: aws/cdk-bootstrap@v2
DependsOn:
- action-name
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
Timeout: timeout-minutes
Inputs:
# Specify a source or an artifact, but not both.
Sources:
- source-name-1
Artifacts:
- artifact-name
Outputs:
Artifacts:
- Name: cdk_bootstrap_artifacts
Files:
- "cdk.out/**/*"
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Configuration:
Region: us-west-2
CdkCliVersion: version
```
## CDKBootstrapAction
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
기본값: `CDKBootstrapAction_nn`.
해당 UI: 구성 탭/**작업 표시 이름**
## Identifier
(*CDKBootstrapAction*/**Identifier**)
(필수)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
**참고**
를 지정`aws/cdk-bootstrap@v2`하면 Node.js 18과 같은 최신 도구가 포함된 [2024년 3월 이미지](build-images.md#build.default-image)에서 작업이 실행됩니다. 를 지정`aws/cdk-bootstrap@v1`하면 Node.js 16과 같은 이전 도구가 포함된 [2022년 11월 이미지](build-images.md#build.previous-image)에서 작업이 실행됩니다.
기본값: `aws/cdk-bootstrap@v2`.
해당 UI: 워크플로 다이어그램/CDKBootstrapAction\$1nn/**aws/cdk-bootstrap@v2** 레이블
## DependsOn
(*CDKBootstrapAction*/**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*CDKBootstrapAction*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Type
(*CDKBootstrapAction*/Compute/**Type**)
([Compute](#cdk.boot.computename) 포함 시 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 구성 탭/고급 - 선택 사항/**컴퓨팅 유형**
## Fleet
(*CDKBootstrapAction*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/고급 - 선택적/**컴퓨팅 플릿**
## Timeout
(*CDKBootstrapAction*/**Timeout**)
(필수)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Inputs
(*CDKBootstrapAction*/**Inputs**)
(선택 사항)
이 `Inputs` 섹션에서는 워크플로 실행 중에 **AWS CDK 부트스트랩** 작업에 필요한 데이터를 정의합니다.
해당 UI: **입력** 탭
**참고**
각 **AWS CDK 부트스트랩** 작업에 대해 하나의 입력(소스 또는 아티팩트)만 허용됩니다.
## Sources
(*CDKBootstrapAction*/Inputs/**Sources**)
( AWS CDK 앱이 소스 리포지토리에 저장된 경우 필수)
AWS CDK 앱이 소스 리포지토리에 저장된 경우 해당 소스 리포지토리의 레이블을 지정합니다. **AWS CDK 부트스트랩** 작업은 부트스트랩 프로세스를 시작하기 전에 이 리포지토리의 앱을 합성합니다. 현재, `WorkflowSource` 리포지토리 레이블만 지원됩니다.
AWS CDK 앱이 소스 리포지토리에 포함되지 않은 경우 다른 작업에서 생성된 아티팩트에 있어야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*CDKBootstrapAction*/Inputs/**Artifacts**)
( AWS CDK 앱이 이전 작업의 [출력 아티팩트](workflows-working-artifacts-output.md)에 저장된 경우 필수)
AWS CDK 앱이 이전 작업에서 생성된 아티팩트에 포함된 경우 여기에 해당 아티팩트를 지정합니다. **AWS CDK 부트스트랩** 작업은 부트스트랩 프로세스를 시작하기 전에 지정된 아티팩트의 앱을 CloudFormation 템플릿으로 합성합니다. AWS CDK 앱이 아티팩트 내에 포함되어 있지 않은 경우 앱은 소스 리포지토리에 있어야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**아티팩트 - 선택 사항**
## Outputs
(*CDKBootstrapAction*/**Outputs**)
(선택 사항)
워크플로 실행 중에 작업에 의해 출력되는 데이터를 정의합니다.
해당 UI: **출력** 탭
## Artifacts - output
(*CDKBootstrapAction*/Outputs/**Artifacts**)
(선택 사항)
작업에서 생성된 아티팩트를 지정합니다. 이러한 아티팩트를 다른 작업의 입력으로 참조할 수 있습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/**아티팩트**
## Name
(*CDKBootstrapAction*/Outputs/Artifacts/**Name**)
([Artifacts - output](#cdk.boot.outputs.artifacts) 포함 시 필수)
런타임 시 **AWS CDK 부트스트랩** 작업으로 합성되는 CloudFormation 템플릿을 포함할 아티팩트의 이름을 지정합니다. 기본값은 `cdk_bootstrap_artifacts`입니다. 아티팩트를 지정하지 않으면 작업이 템플릿을 합성하지만 아티팩트에 저장하지는 않습니다. 테스트 또는 문제 해결을 위해 합성된 템플릿을 아티팩트에 저장하여 레코드를 보존하는 것이 좋습니다.
해당 UI: 출력 탭/아티팩트/아티팩트 추가/**빌드 아티팩트 이름**
## Files
(*CDKBootstrapAction*/Outputs/Artifacts/**Files**)
([Artifacts - output](#cdk.boot.outputs.artifacts) 포함 시 필수)
아티팩트에 포함할 파일을 지정합니다. AWS CDK 앱의 합성된 CloudFormation 템플릿을 `"cdk.out/**/*"` 포함하도록를 지정해야 합니다.
**참고**
`cdk.out` 는 합성된 파일이 저장되는 기본 디렉터리입니다. `cdk.json` 파일에 이외의 출력 디렉터리를 지정한 경우 대신 여기에 해당 디렉터리`cdk.out`를 지정합니다`cdk.out`.
해당 UI: 출력 탭/아티팩트/아티팩트 추가/**빌드에서 생성된 파일**
## Environment
(*CDKBootstrapAction*/**Environment**)
(필수)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*CDKBootstrapAction*/Environment/**Name**)
([Environment](#cdk.boot.environment) 포함 시 필수)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*CDKBootstrapAction*/Environment/**Connections**)
(최신 버전의 작업에서는 선택 사항, 이전 버전에서는 필수)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Name
(*CDKBootstrapAction*/Environment/Connections/**Name**)
([Connections](#cdk.boot.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Role
(*CDKBootstrapAction*/Environment/Connections/**Role**)
([Connections](#cdk.boot.environment.connections) 포함 시 필수)
**AWS CDK 부트스트랩** 작업이 부트스트랩 스택에 액세스 AWS 하고 추가하는 데 사용하는 IAM 역할의 이름을 지정합니다. [CodeCatalyst 스페이스에 역할을 추가](ipa-connect-account-addroles.md)했고 역할에 다음 정책이 포함되어 있는지 확인합니다.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 적절한 정책이 있는지 확인합니다.
원하는 경우 이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**역할**
## Configuration
(*CDKBootstrapAction*/**Configuration**)
(필수)
작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## Region
(*CDKBootstrapAction*/Configuration/**Region**)
(필수)
부트스트랩 스택 AWS 리전 을 배포할를 지정합니다. 이 리전은 AWS CDK 앱이 배포된 리전과 일치해야 합니다. 리전 코드 목록은 [리전 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)를 참조하세요.
해당 UI: 구성 탭/**리전**
## CdkCliVersion
(*CDKBootstrapAction*/Configuration/**CdkCliVersion**)
(선택 사항)
이 속성은 버전 1.0.13 이상의 **AWS CDK 배포** 작업과 버전 1.0.8 이상의 **AWS CDK 부트스트랩** 작업에서 사용할 수 있습니다.
다음 중 하나를 지정하세요.
+ 이 작업에서 사용할 AWS Cloud Development Kit (AWS CDK) 명령줄 인터페이스(CLI)( 도구 키트라고 AWS CDK 도 함)의 전체 버전입니다. 예시: `2.102.1`. 애플리케이션을 구축하고 배포할 때 일관성과 안정성을 보장하기 위해 전체 버전을 지정하는 것이 좋습니다.
또는
+ `latest`. CDK CLI의 최신 기능과 수정 사항을 활용하도록 `latest`를 지정하는 것이 좋습니다.
작업은 지정된 CLI 버전(또는 최신 버전)을 CodeCatalyst [빌드 이미지](build-images.md) AWS CDK 에 다운로드한 다음이 버전을 사용하여 CDK 애플리케이션을 배포하거나 환경을 부트스트랩 AWS 하는 데 필요한 명령을 실행합니다.
사용할 수 있는 지원되는 CDK CLI 버전 목록은 [AWS CDK 버전](https://docs.aws.amazon.com/cdk/api/versions.html) 섹션을 참조하세요.
이 속성을 생략하면 작업은 다음 주제 중 하나에 설명된 기본 AWS CDK CLI 버전을 사용합니다.
+ ['AWS CDK 배포' 작업에서 사용하는 CDK CLI 버전](cdk-dep-action.md#cdk-dep-action-cdk-version)
+ ["AWS CDK bootstrap" 작업에서 사용하는 CDK CLI 버전](cdk-boot-action.md#cdk-boot-action-cdk-version)
해당 UI: 구성 탭/**AWS CDK CLI 버전**
# 워크플로를 사용하여 Amazon S3에 파일 게시
이 섹션에서는 CodeCatalyst 워크플로를 사용하여 Amazon S3에 파일을 게시하는 방법을 설명합니다. 이렇게 하려면, 워크플로에 **Amazon S3 게시** 작업을 추가해야 합니다. **Amazon S3 게시** 작업은 소스 디렉터리의 파일을 Amazon S3 버킷으로 복사합니다. 소스 디렉터리는 다음 위치에 있을 수 있습니다.
+ [소스 리포지토리](source.md) 또는
+ 다른 워크플로 작업에서 생성된 [출력 아티팩트](workflows-working-artifacts.md)
**Topics**
+ ['Amazon S3 게시' 작업을 사용하는 경우](#s3-pub-action-when-to-use)
+ ['Amazon S3 게시' 작업에 사용되는 런타임 이미지](#s3-pub-action-runtime)
+ [예시: Amazon S3에 파일 게시](s3-pub-action-example-workflow.md)
+ ['Amazon S3 게시' 작업 추가](s3-pub-action-add.md)
+ ['Amazon S3 게시' 작업 YAML](s3-pub-action-ref.md)
## 'Amazon S3 게시' 작업을 사용하는 경우
다음과 같은 경우 이 작업을 사용합니다.
+ Amazon S3에 저장하려는 파일을 생성하는 워크플로가 있습니다.
예를 들어, Amazon S3에서 호스팅하려는 정적 웹 사이트를 빌드하는 워크플로가 있을 수 있습니다. 이 경우 워크플로에는 사이트의 HTML 및 지원 파일을 빌드하기 위한 빌드 [작업](build-add-action.md)과 파일을 Amazon S3에 복사하기 위한 **Amazon S3 게시** 작업이 포함됩니다.
+ Amazon S3에 저장하려는 파일이 포함된 소스 리포지토리가 있습니다.
예를 들어, Amazon S3에 매일 밤 보관하려는 애플리케이션 소스 파일이 있는 소스 리포지토리가 있을 수 있습니다.
## 'Amazon S3 게시' 작업에 사용되는 런타임 이미지
**Amazon S3 게시 작업은 **[2022년 11월 이미지](build-images.md#build.previous-image)에서 실행됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 단원을 참조하십시오.
# 예시: Amazon S3에 파일 게시
다음 예시 워크플로에는 빌드 작업과 함께 **Amazon S3 게시** 작업이 포함됩니다. 워크플로는 정적 설명서 웹 사이트를 빌드한 다음 Amazon S3에 게시하여 호스팅합니다. 워크플로는 순차적으로 실행되는 다음 구성 요소로 구성됩니다.
+ **트리거** - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ **빌드** 작업(`BuildDocs`) - 트리거 시 작업은 정적 설명서 웹 사이트(`mkdocs build`)를 빌드하고 연결된 HTML 파일과 지원 메타데이터를 `MyDocsSite`라는 아티팩트에 추가합니다. 빌드 작업에 대한 자세한 내용은 [워크플로로 빌드하기](build-workflow-actions.md) 섹션을 참조하세요.
+ **Amazon S3 게시** 작업(`PublishToS3`) - 빌드 작업이 완료되면, 이 작업은 호스팅을 위해 `MyDocsSite` 아티팩트의 사이트를 Amazon S3에 복사합니다.
**참고**
다음 워크플로 예시는 설명을 돕기 위한 참고용이며 추가 구성 없이는 작동하지 않습니다.
**참고**
다음 YAML 코드에서 원하는 경우 `Connections:` 섹션을 생략할 수 있습니다. 이 섹션을 생략하는 경우, 환경의 **기본 IAM 역할** 필드에서 지정된 역할에 **Amazon S3 게시** 작업에 필요한 권한 및 신뢰 정책이 포함되어 있는지 확인해야 합니다. 기본 IAM 역할이 있는 환경 설정에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요. **Amazon S3 게시** 작업에 필요한 권한 및 신뢰 정책에 대한 자세한 내용은 ['Amazon S3 게시' 작업 YAML](s3-pub-action-ref.md)의 [Role](s3-pub-action-ref.md#s3.pub.environment.connections.role) 속성 설명을 참조하세요.
```
Name: codecatalyst-s3-publish-workflow
SchemaVersion: 1.0
Triggers:
- Type: PUSH
Branches:
- main
Actions:
BuildDocs:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: echo BuildDocs started on `date`
- Run: pip install --upgrade pip
- Run: pip install mkdocs
- Run: mkdocs build
- Run: echo BuildDocs completed on `date`
Outputs:
Artifacts:
- Name: MyDocsSite
Files:
- "site/**/*"
PublishToS3:
Identifier: aws/s3-publish@v1
Environment:
Name: codecatalyst-s3-publish-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-s3-publish-build-role
Inputs:
Sources:
- WorkflowSource
Artifacts:
- MyDocsSite
Configuration:
DestinationBucketName: amzn-s3-demo-bucket
SourcePath: /artifacts/PublishToS3/MyDocSite/site
TargetPath: my/docs/site
```
# 'Amazon S3 게시' 작업 추가
다음 지침에 따라 **Amazon S3 게시** 작업을 워크플로에 추가합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 'Amazon S3 게시' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **Amazon S3 게시** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **Amazon S3 게시**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력,** **구성** 및 **출력** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['Amazon S3 게시' 작업 YAML](s3-pub-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 'Amazon S3 게시' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **Amazon S3 게시** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **Amazon S3 게시**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['Amazon S3 게시' 작업 YAML](s3-pub-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 'Amazon S3 게시' 작업 YAML
다음은 **Amazon S3 게시** 작업의 YAML 정의입니다. 이러한 작업 사용 방법을 배우려면 [워크플로를 사용하여 Amazon S3에 파일 게시](s3-pub-action.md) 섹션을 참조하세요.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
S3Publish\$1nn:
Identifier: aws/s3-publish@v1
DependsOn:
- build-action
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
Timeout: timeout-minutes
Inputs:
Sources:
- source-name-1
Artifacts:
- artifact-name
Variables:
- Name: variable-name-1
Value: variable-value-1
- Name: variable-name-2
Value: variable-value-2
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Configuration:
SourcePath: my/source
DestinationBucketName: amzn-s3-demo-bucket
TargetPath: my/target
```
## S3Publish
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
기본값: `S3Publish_nn`.
해당 UI: 구성 탭/**작업 이름**
## Identifier
(*S3Publish*/**Identifier**)
(필수)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
기본값: `aws/s3-publish@v1`.
해당 UI: 워크플로 다이어그램/S3Publish\$1nn/**aws/s3-publish@v1** 레이블
## DependsOn
(*S3Publish*/**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*S3Publish*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Type
(*S3Publish*/Compute/**Type**)
([Compute](#s3.pub.computename) 포함 시 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 구성 탭/**컴퓨팅 유형**
## Fleet
(*S3Publish*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/**컴퓨팅 플릿**
## Timeout
(*S3Publish*/**Timeout**)
(필수)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Inputs
(*S3Publish*/**Inputs**)
(선택 사항)
이 `Inputs` 섹션에서는 워크플로 실행 중에 `S3Publish`에 필요한 데이터를 정의합니다.
**참고**
각 **AWS CDK 배포** 작업에 대해 최대 4개의 입력(소스 1개 및 아티팩트 3개)이 허용됩니다. 변수는 이 합계에 포함되지 않습니다.
서로 다른 입력(소스 및 아티팩트)에 있는 파일을 참조해야 하는 경우 소스 입력은 기본 입력이고 아티팩트는 보조 입력입니다. 보조 입력의 파일에 대한 참조는 특수 접두사를 사용하여 기본 입력에서 파일을 구분합니다. 자세한 내용은 [예시: 여러 아티팩트에서 파일 참조](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)을 참조하세요.
해당 UI: **입력** 탭
## Sources
(*S3Publish*/Inputs/**Sources**)
(Amazon S3에 게시하려는 파일이 소스 리포지토리에 저장된 경우 필수)
Amazon S3에 게시하려는 파일이 소스 리포지토리에 저장된 경우, 해당 소스 리포지토리의 레이블을 지정합니다. 현재, `WorkflowSource` 레이블만 지원됩니다.
Amazon S3에 게시하려는 파일이 소스 리포지토리에 포함되어 있지 않은 경우, 다른 작업에서 생성된 아티팩트에 있어야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*S3Publish*/Inputs/**Artifacts**)
(Amazon S3에 게시하려는 파일이 이전 작업의 [출력 아티팩트](workflows-working-artifacts-output.md)에 저장되는 경우 필수)
Amazon S3에 게시하려는 파일이 이전 작업에서 생성된 아티팩트에 포함된 경우, 여기에 해당 아티팩트를 지정합니다. 아티팩트 내에 파일이 포함되어 있지 않은 경우 파일은 소스 리포지토리에 있어야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**아티팩트 - 선택 사항**
## Variables - input
(*S3Publish*/Inputs/**Variables**)
(선택 사항)
작업에 사용할 수 있도록 하려는 입력 변수를 정의하는 이름/값 페어의 시퀀스를 지정합니다. 변수 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 변수 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**변수 - 선택 사항**
## Environment
(*S3Publish*/**Environment**)
(필수)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*S3Publish*/Environment/**Name**)
([Environment](#s3.pub.environment) 포함 시 필수)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*S3Publish*/Environment/**Connections**)
(최신 버전의 작업에서는 선택 사항, 이전 버전에서는 필수)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Name
(*S3Publish*/Environment/Connections/**Name**)
([Connections](#s3.pub.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Role
(*S3Publish*/Environment/Connections/**Role**)
([Connections](#s3.pub.environment.connections) 포함 시 필수)
**Amazon S3 게시** 작업이 Amazon S3에 액세스 AWS 하고 파일을 복사하는 데 사용하는 IAM 역할의 이름을 지정합니다Amazon S3. [CodeCatalyst 스페이스에 역할을 추가](ipa-connect-account-addroles.md)했고 역할에 다음 정책이 포함되어 있는지 확인합니다.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 다음 정책이 있는지 확인합니다.
+ 다음 권한 정책:
**주의**
다음 정책에 표시된 대로 권한을 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListBucket",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
}
]
}
```
------
+ 다음 사용자 지정 신뢰 정책:
**참고**
원하는 경우 이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**역할**
## Configuration
(*S3Publish*/**Configuration**)
(필수)
작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## SourcePath
(*S3Publish*/Configuration/**SourcePath**)
(필수)
Amazon S3에 게시하려는 디렉터리 또는 파일의 이름과 경로를 지정합니다. 디렉터리 또는 파일은 이전 작업의 소스 리포지토리 또는 아티팩트에 상주할 수 있으며 소스 리포지토리 또는 아티팩트 루트를 기준으로 합니다.
예시:
`./myFolder/`를 지정하면 `/myFolder`의 내용이 Amazon S3에 복사되고, 기본 디렉터리 구조가 보존됩니다.
Amazon S3*에만 *`myfile.txt` `./myFolder/myfile.txt` 복사본 지정 (디렉토리 구조가 제거됩니다.)
와일드카드는 사용할 수 없습니다.
**참고**
디렉터리 또는 파일 경로에 접두사를 추가하여 찾을 아티팩트 또는 소스를 나타내야 할 수 있습니다. 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**소스 경로**
## DestinationBucketName
(*S3Publish*/Configuration/**DestinationBucketName**)
(필수)
파일을 게시하려는 Amazon S3 버킷의 이름을 지정합니다.
해당 UI: 구성 탭/**대상 버킷 - 선택 사항**
## TargetPath
(*S3Publish*/Configuration/**TargetPath**)
(선택 사항)
Amazon S3에서 파일을 게시할 디렉터리의 이름과 경로를 지정합니다. 디렉터리가 존재하지 않으면 새로 생성됩니다. 디렉터리 경로에는 버킷 이름이 포함되어서는 안 됩니다.
예시:
`myS3Folder`
`./myS3Folder/myS3Subfolder`
해당 UI: 구성 탭/**대상 디렉터리 - 선택 사항**
# AWS 계정 및 VPCs에 배포
[CodeCatalyst 워크플로](workflow.md)를 사용하면 애플리케이션 및 기타 리소스를 AWS 클라우드의 대상 AWS 계정및 Amazon VPCs에 배포할 수 있습니다. 이러한 배포를 활성화하려면 CodeCatalyst 환경을 설정해야 합니다.
[개발](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html) *환경*과 혼동해서는 안 되는 CodeCatalyst 환경은 CodeCatalyst [워크플로](workflow.md)가 연결되는 대상 AWS 계정 및 선택적 Amazon VPC를 정의합니다. 또한 환경은 워크플로가 대상 계정 내의 AWS 서비스 및 리소스에 액세스하는 데 필요한 [IAM 역할을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 정의합니다.
여러 환경을 설정하고 개발, 테스트, 스테이징 및 프로덕션과 같은 이름을 지정할 수 있습니다. 이러한 환경에 배포하면 배포에 대한 정보가 환경의 CodeCatalyst **배포 활동** 및 **배포 대상** 탭에 표시됩니다.
## 환경을 시작하려면 어떻게 해야 하나요?
CodeCatalyst 환경을 추가하고 사용하는 상위 단계는 다음과 같습니다.
1. CodeCatalyst 스페이스에서 **하나 이상의 AWS 계정을 연결합니다**. 이 프로세스 중에 워크플로가 AWS 계정의 리소스에 액세스하는 데 필요한 IAM 역할을 추가합니다. 자세한 내용은 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 단원을 참조하십시오.
1. CodeCatalyst 프로젝트에서 AWS 계정 1단계의 및 IAM 역할 중 하나를 포함하는 **환경을 생성합니다**. 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 단원을 참조하십시오.
1. CodeCatalyst 프로젝트의 워크플로에서 2단계에서 생성한 **환경을 가리키는 [작업](workflows-actions.md)을 추가합니다**. 자세한 내용은 [워크플로에 작업 추가](workflows-add-action.md) 섹션을 참조하세요.
이제 환경을 구성했습니다. 이제 작업은 환경에서 지정된 AWS 계정 에 리소스를 배포할 수 있습니다.
**참고**
Amazon VPC를 환경에 추가할 수도 있습니다. 자세한 내용은 *CodeCatalyst 관리 안내서* 및 [VPC를 환경과 연결](deploy-environments-associate-vpc.md)의 [스페이스에 대한 VPC 연결 추가](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)를 참조하세요.
## 단일 워크플로 내에 여러 환경이 존재할 수 있습니까?
예. 워크플로에 여러 작업이 포함된 경우 각 작업에 환경을 할당할 수 있습니다. 예를 들어 두 개의 배포 작업이 포함된 워크플로가 있을 때, 하나는 `my-staging-enviroment` 환경이 할당되고 다른 하나는 `my-production-environment` 환경이 할당될 수 있습니다.
## 환경을 지원하는 워크플로 작업은 무엇입니까?
AWS 클라우드에 리소스를 배포하거나 다른 이유(예: 모니터링 및 보고)로 AWS 서비스와 통신하는 모든 워크플로 작업은 환경을 지원합니다.
## CodeCatalyst에 배포 정보가 표시되는 것을 지원하는 작업은 무엇입니까?
환경을 지원하는 워크플로 작업 중 CodeCatalyst 콘솔의 **배포 활동** 및 **배포 대상** 페이지에 배포 정보가 표시되는 작업은 몇 개뿐입니다.
다음 워크플로 작업은 배포 정보가 표시되는 것을 지원합니다.
+ ** CloudFormation 스택 배포** - 자세한 내용은 섹션을 참조하세요. [CloudFormation 스택 배포](deploy-action-cfn.md)
+ **Amazon ECS에 배포** - 자세한 내용은 [워크플로를 사용하여 Amazon ECS에 배포](deploy-action-ecs.md) 섹션을 참조하세요.
+ **Kubernetes 클러스터에 배포** - 자세한 내용은 [워크플로를 사용하여 Amazon EKS에 배포](deploy-action-eks.md) 섹션을 참조하세요.
+ **AWS CDK 배포** - 자세한 내용은 섹션을 참조하세요. [워크플로를 사용하여 AWS CDK 앱 배포](cdk-dep-action.md)
## 지원되는 리전:
**환경** 페이지에서는 모든 AWS 리전의 리소스를 표시할 수 있습니다.
## 환경은 필수입니까?
할당된 워크플로 작업이 AWS 클라우드에 리소스를 배포하거나 다른 이유(예: 모니터링 및 보고)로 AWS 서비스와 통신하는 경우 환경은 필수입니다.
예를 들어 애플리케이션을 빌드하지만 AWS 계정 또는 Amazon VPC와 통신할 필요가 없는 빌드 작업이 있는 경우 작업에 환경을 할당할 필요가 없습니다. 그러나 빌드 작업이 AWS 계정의 Amazon CloudWatch 서비스로 로그를 전송하는 경우 작업에 환경이 할당되어 있어야 합니다.
**Topics**
+ [환경을 시작하려면 어떻게 해야 하나요?](#deploy-environments-get-started)
+ [단일 워크플로 내에 여러 환경이 존재할 수 있습니까?](#deploy-environments-multiple)
+ [환경을 지원하는 워크플로 작업은 무엇입니까?](#deploy-environments-supported)
+ [CodeCatalyst에 배포 정보가 표시되는 것을 지원하는 작업은 무엇입니까?](#deploy-environments-supported-targets)
+ [지원되는 리전:](#deploy-environments-supported-regions)
+ [환경은 필수입니까?](#deploy-environments-optional-or-mandatory)
+ [환경 생성](deploy-environments-creating-environment.md)
+ [작업과 환경 연결](deploy-environments-add-app-to-environment.md)
+ [VPC를 환경과 연결](deploy-environments-associate-vpc.md)
+ [환경 AWS 계정 과 연결](deploy-environments-associate-account.md)
+ [작업의 IAM 역할 변경](deploy-environments-switch-role.md)
# 환경 생성
다음 지침을 사용하여 나중에 워크플로 작업과 연결할 수 있는 환경을 생성합니다.
**시작하기 전 준비 사항**
다음 항목이 필요합니다.
+ CodeCatalyst 스페이스. 자세한 내용은 [CodeCatalyst 설정 및 로그인CodeCatalyst 설정 및 로그인](setting-up-topnode.md) 섹션을 참조하세요.
+ CodeCatalyst 프로젝트. 자세한 내용은 [블루프린트를 사용하여 프로젝트 생성](projects-create.md#projects-create-console-template) 단원을 참조하십시오.
+ 워크플로 작업이 액세스해야 하는 IAM 역할을 포함하는 AWS 계정 연결입니다 AWS. 계정 연결 생성에 대한 자세한 내용은 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경당 최대 하나의 계정 연결을 사용할 수 있습니다.
**참고**
계정 연결 없이 환경을 생성할 수 있지만 나중에 다시 돌아와 연결을 추가해야 합니다.
+ 다음 CodeCatalyst 역할 중 하나:
+ **스페이스 관리자**
+ **프로젝트 관리자**
+ **기고자**
**참고**
**기고자 역할**이 있는 경우 환경을 생성할 수 있지만 AWS 계정 연결에는 연결할 수 없습니다. **스페이스 관리자** 또는 **프로젝트 관리자** 역할을 가진 사람에게 환경을 AWS 계정 연결에 연결하도록 요청해야 합니다.
역할과 권한에 대한 자세한 내용은 [사용자에게 프로젝트 권한 부여](projects-members.md) 섹션을 참조하세요.
**환경을 생성하는 방법**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **환경**을 선택합니다.
1. **환경 이름**에 **Production** 또는 **Staging** 같은 이름을 입력합니다.
1. **환경 유형**에서 다음 중 하나를 선택합니다.
+ **비프로덕션** - 애플리케이션을 프로덕션으로 이동하기 전에 애플리케이션을 테스트하여 의도한 대로 작동하는지 확인할 수 있는 환경입니다.
+ **프로덕션** - 공개적으로 사용할 수 있고 최종 애플리케이션을 호스팅하는 '라이브' 환경입니다.
**프로덕션**을 선택하면 환경이 연결된 작업 옆으로 **프로덕션** 배지가 UI에 나타납니다. 배지를 사용하면 프로덕션에 배포되는 작업을 빠르게 확인할 수 있습니다. 배지 모양 외에는 프로덕션 환경과 비프로덕션 환경 간에 차이가 없습니다.
1. (선택 사항) **설명**: 설명을 입력합니다. 예시: **Production environment for the hello-world app**.
1. **AWS 계정 연결 - 선택 사항**에서이 환경과 연결할 AWS 계정 연결을 선택합니다. 이 환경에 할당된 워크플로 작업은 연결된 AWS 계정에 연결할 수 있습니다. CodeCatalyst에서 AWS 계정 연결을 생성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md).
사용하려는 AWS 계정 연결이 나열되지 않은 경우 프로젝트에서 허용되지 않기 때문일 수 있습니다. 자세한 내용은 *Amazon CodeCatalyst 관리자 안내서*의 [프로젝트 제한 계정 연결 구성](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)을 참조하세요.
1. **기본 IAM 역할**에서 이 환경과 연결할 IAM 역할을 선택합니다. 이 환경에 할당된 워크플로 작업은이 IAM 역할을 상속하며 이를 사용하여의 서비스 및 리소스에 연결할 수 있습니다 AWS 계정.
여러 작업에 환경을 할당해야 하는데 이러한 작업에 여기에 지정된 기본 역할과 다른 IAM 역할이 필요한 경우, **역할 전환** 옵션을 사용하여 각 작업의 **구성** 탭에서 서로 다른 역할을 지정할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 단원을 참조하십시오.
기본값으로 사용하려는 IAM 역할이 나열되지 않은 경우 아직 AWS 계정 연결에 추가하지 않았기 때문일 수 있습니다. 계정 연결에 IAM 역할을 추가하려면 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요.
1. (선택 사항) **VPC 연결**에서 이 환경과 연결할 VPC 연결을 선택합니다. VPC 연결 생성에 대한 자세한 내용은 [ Amazon CodeCatalyst 관리자 안내서](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html)의 *Amazon Virtual Private Clouds 관리*를 참조하세요.
사용하려는 VPC 연결이 나열되지 않은 경우 프로젝트에 허용되지 않는 AWS 계정 연결이 포함되어 있기 때문일 수 있습니다. 자세한 내용은 *Amazon CodeCatalyst 관리자 안내서*의 [프로젝트 제한 계정 연결 구성](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)을 참조하세요.
1. **환경 생성**을 선택합니다. CodeCatalyst는 빈 환경을 생성합니다.
**다음 단계**
+ 이제 환경을 생성했으므로 워크플로 작업과 연결할 준비가 되었습니다. 자세한 내용은 [작업과 환경 연결](deploy-environments-add-app-to-environment.md) 섹션을 참조하세요.
# 작업과 환경 연결
환경을 [지원되는 워크플로 작업](deploy-environments.md#deploy-environments-supported)과 연결하면 환경의 , AWS 계정기본 IAM 역할 및 선택적 Amazon VPC가 작업에 할당됩니다. 그런 다음 IAM 역할을 사용하여 작업을 AWS 계정 에 연결 및 배포하고 선택적 Amazon VPC에도 연결할 수 있습니다.
다음 지침을 사용하여 환경을 작업과 연결합니다.
## 1단계: 환경을 워크플로 작업과 연결
다음 절차에 따라 환경을 워크플로 작업과 연결합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 환경을 워크플로 작업과 연결하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 환경에서 지원되는 작업을 선택합니다. 자세한 내용은 [CodeCatalyst에 배포 정보가 표시되는 것을 지원하는 작업은 무엇입니까?](deploy-environments.md#deploy-environments-supported-targets) 섹션을 참조하세요.
1. **구성** 탭을 선택하고 다음과 같이 **환경** 필드에 정보를 지정합니다.
**환경**
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
1. (선택 사항) 작업과 연결된 IAM 역할을 변경합니다. 작업에 대한 잘못된 권한 집합이 포함된 경우 역할을 변경할 수 있습니다.
역할을 생성하려면:
1. ***내 환경*에 무엇이 있나요?** 상자에서 세로 줄임표 아이콘(![\[Ellipsis.\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/elipsis.png))을 선택합니다.
1. 다음 중 하나를 선택합니다.
+ **역할을 전환합니다**. 이 작업에서 사용하는 IAM 역할을 변경하고 이 작업만 변경하려면 이 옵션을 선택합니다. 다른 작업은 연결된 환경에 지정된 기본 IAM 역할을 계속 사용합니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
+ **환경을 편집합니다**. 환경에 나열된 기본 IAM 역할을 변경하려면 이 옵션을 선택합니다. 이 옵션을 선택하면 작업과 동일한 환경과 연결된 다른 작업이 새 기본 IAM 역할을 사용하여 시작됩니다.
**중요**
기본 IAM 역할을 업데이트할 때 주의하세요. 역할의 권한이 환경을 공유하는 모든 작업에 충분하지 않은 경우 역할을 변경하면 작업 실패가 발생할 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 환경을 워크플로 작업과 연결하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 환경과 연결하려는 워크플로 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Environment:
Name: environment-name
```
자세한 내용은 [작업 유형](workflows-actions.md#workflows-actions-types) 항목을 참조하세요. 이 주제에는 YAML 참조를 포함하여 각 작업에 대한 설명서로 연결되는 링크가 있습니다.
1. (선택 사항) 작업에 환경에 나열된 기본 IAM 역할과 다른 역할을 사용하려면 사용하려는 역할이 포함된 `Connections:` 섹션을 추가합니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
## 2단계: 배포 활동 페이지 채우기
환경을 워크플로 작업과 연결한 후 CodeCatalyst 콘솔의 **환경** 섹션에 있는 **배포 활동** 및 **배포 대상** 페이지를 배포 정보로 채울 수 있습니다. 다음 지침을 사용하여 이러한 페이지를 채웁니다.
**참고**
CodeCatalyst 콘솔에 배포 정보가 표시되는 작업은 몇 가지뿐입니다. 자세한 내용은 [CodeCatalyst에 배포 정보가 표시되는 것을 지원하는 작업은 무엇입니까?](deploy-environments.md#deploy-environments-supported-targets) 섹션을 참조하세요.
**CodeCatalyst에 배포 정보를 추가하려면**
1. [1단계: 환경을 워크플로 작업과 연결](#deploy-environments-add-app-to-environment-assoc)에서 변경 사항을 커밋할 때 워크플로 실행이 자동으로 시작되지 않은 경우 다음과 같이 수동으로 실행을 시작합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **실행**을 선택합니다.
워크플로 실행은 새 배포를 시작하며, 이로 인해 CodeCatalyst는 CodeCatalyst에 배포 정보를 추가합니다.
1. CodeCatalyst 콘솔에 배포 활동이 추가되었는지 확인합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **환경**을 선택합니다.
1. 환경을 선택합니다(예: `Production`).
1. **배포 활동** 탭을 선택하고 배포가 **SUCCEEDED** **상태**로 나타나는지 확인합니다. 이는 워크플로 실행이 애플리케이션 리소스를 성공적으로 배포했음을 나타냅니다.
1. **배포 대상** 탭을 선택하고 애플리케이션 리소스가 나타나는지 확인합니다.
# VPC를 환경과 연결
작업이 VPC 연결이 있는 환경으로 구성된 경우 연결된 VPC에서 지정한 네트워크 규칙 및 액세스 리소스에 따라 작업이 VPC에 연결된 상태로 실행됩니다. 하나 이상의 환경에서 동일한 VPC 연결을 사용할 수 있습니다.
다음 지침에 따라 VPC 연결을 환경과 연결합니다.
**VPC 연결을 환경에 연결하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **환경**을 선택합니다.
1. 환경을 선택합니다(예: `Production`).
1. **환경 속성** 탭을 선택합니다.
1. **VPC 연결 관리**를 선택하고 원하는 VPC 연결을 선택한 다음 **확인**을 선택합니다. 이렇게 하면 선택한 VPC 연결이 이 환경과 연결됩니다.
**참고**
사용하려는 VPC 연결이 나열되지 않은 경우 프로젝트에 허용되지 않는 AWS 계정 연결이 포함되어 있기 때문일 수 있습니다. 자세한 내용은 *Amazon CodeCatalyst 관리자 안내서*의 [프로젝트 제한 계정 연결 구성](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)을 참조하세요.
자세한 내용은 *CodeCatalyst Cloud 관리자 안내서*의 [Amazon Virtual Private Clouds 관리하기](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html)를 참조하세요.
# 환경 AWS 계정 과 연결
다음 지침에 따라를 환경 AWS 계정 과 연결합니다. AWS 계정 를 환경에 연결하면 환경에 할당된 워크플로 작업이에 연결할 수 있습니다 AWS 계정.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요.
**시작하기 전 준비 사항**
다음 항목이 필요합니다.
+ 워크플로 작업이 액세스해야 하는 IAM 역할을 포함하는 AWS 계정 연결입니다 AWS. 계정 연결 생성에 대한 자세한 내용은 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경당 최대 하나의 계정 연결을 사용할 수 있습니다.
+ **스페이스 관리자** 또는 **프로젝트 관리자** CodeCatalyst 역할 중 하나를 선택합니다. 자세한 내용은 [사용자에게 프로젝트 권한 부여](projects-members.md) 단원을 참조하십시오.
**AWS 계정 를 환경에 연결하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **환경**을 선택합니다.
1. 환경을 선택합니다(예: `Production`).
1. **환경 편집**을 선택합니다.
1. **환경 속성**의 **AWS 계정 연결 - 선택 사항** 드롭다운 목록에서 원하는 AWS 계정을 선택합니다.
사용하려는 AWS 계정 연결이 나열되지 않은 경우 프로젝트에서 허용되지 않기 때문일 수 있습니다. 자세한 내용은 *Amazon CodeCatalyst 관리자 안내서*의 [프로젝트 제한 계정 연결 구성](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)을 참조하세요.
1. **기본 IAM 역할**에서 이 환경과 연결할 IAM 역할을 선택합니다. 이 환경에 할당된 워크플로 작업은이 IAM 역할을 상속하며 이를 사용하여의 서비스 및 리소스에 연결할 수 있습니다 AWS 계정.
기본값으로 사용하려는 IAM 역할이 나열되지 않은 경우 아직 AWS 계정 연결에 추가하지 않았기 때문일 수 있습니다. 계정 연결에 IAM 역할을 추가하려면 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요.
# 작업의 IAM 역할 변경
기본적으로 [환경](deploy-environments.md)을 워크플로 [작업](workflows-actions.md)과 연결하면 작업은 환경에 지정된 기본 IAM 역할을 상속합니다. 작업이 다른 역할을 사용하도록 이 동작을 변경할 수 있습니다. 작업이 AWS 클라우드에서 작동하는 데 필요한 권한이 기본 IAM 역할에 없는 경우 다른 역할을 사용할 수 있습니다.
작업에 다른 IAM 역할을 할당하려면 시각적 편집기에서 **역할 전환** 옵션을 사용하거나 YAML 편집기에서 `Connections:` 속성을 사용할 수 있습니다. 새 역할은 환경에 지정된 기본 IAM 역할을 재정의하므로 기본 IAM 역할을 그대로 유지할 수 있습니다. 기본 IAM 역할을 사용하는 다른 작업이 있는 경우 기본 IAM 역할을 그대로 유지할 수 있습니다.
다음 지침을 사용하여 환경에 지정된 것과 다른 IAM 역할을 사용하도록 작업을 구성합니다.
------
#### [ Visual ]
**작업에 다른 IAM 역할을 할당하려면(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. IAM 역할을 업데이트하려는 작업을 나타내는 상자를 선택합니다.
1. **구성** 탭을 선택합니다.
1. ***내 환경*에 무엇이 있나요?** 상자에서 세로 줄임표 아이콘(![\[Ellipsis.\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/elipsis.png))을 선택합니다.
1. **역할 전환**을 선택합니다.
1. **역할 전환** 대화 상자의 **IAM 역할** 드롭다운 목록에서 작업을 사용할 IAM 역할을 선택합니다. 이 역할은 환경의 기본 IAM 역할을 재정의합니다. 사용하려는 역할이 목록에 없는 경우 스페이스에 추가했는지 확인합니다. 자세한 내용은 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요.
이제 선택한 역할이 **워크플로에서 정의됨** 배지와 함께 ***내 환경*에 무엇이 있나요?** 상자에 나타납니다. 역할은 `Connections:` 섹션의 워크플로 정의 파일에도 표시됩니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**작업에 다른 IAM 역할을 할당하려면(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 다른 IAM 역할을 사용하려는 워크플로 작업에서 다음과 유사한 `Connections:` 섹션을 추가합니다.
```
action-name:
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
```
앞의 코드에서 *account-connection-name*을 IAM 역할이 포함된 [계정 연결](ipa-connect-account.md)의 이름으로 바꾸고, *iam-role-name*을 작업을 사용할 IAM 역할의 이름으로 바꿉니다. 이 역할은 환경의 기본 IAM 역할을 재정의합니다. 스페이스에 역할을 추가했는지 확인합니다. 자세한 내용은 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요.
자세한 내용은 [작업 유형](workflows-actions.md#workflows-actions-types) 항목을 참조하세요. 이 주제에는 YAML 참조를 포함하여 각 작업에 대한 설명서로 연결되는 링크가 있습니다.
------
# 워크플로 다이어그램에 앱 URL 표시
워크플로가 애플리케이션을 배포하는 경우 애플리케이션의 URL을 클릭 가능한 링크로 표시하도록 Amazon CodeCatalyst를 구성할 수 있습니다. 이 링크는 CodeCatalyst 콘솔에서 배포한 작업 내부에 나타납니다. 다음 워크플로 다이어그램은 작업 하단에 나타나는 **앱 보기** URL을 보여줍니다.
![\[앱 URL 보기\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/deploy/view-app-url.png)
CodeCatalyst 콘솔에서 이 URL을 클릭하여 애플리케이션 배포를 빠르게 확인할 수 있습니다.
**참고**
앱 URL은 **Amazon ECS에 배포** 작업에서는 지원되지 않습니다.
이 기능을 활성화하려면 `appurl` 또는 `endpointurl`이 포함된 이름으로 작업에 출력 변수를 추가합니다. 대시(`-`), 밑줄(`_`) 또는 공백(` `)과 함께 또는 없이 이름을 사용할 수 있습니다. 문자열은 대/소문자를 구분하지 않습니다. 변수 값을 배포된 애플리케이션의 `http` 또는 `https` URL로 설정합니다.
**참고**
`app url`, 또는 `endpoint url` 문자열을 포함하도록 기존 출력 변수를 업데이트하는 경우 새 변수 이름을 사용하도록 이 변수에 대한 모든 참조를 업데이트합니다.
자세한 단계는 다음 절차를 참조하세요.
+ ["AWS CDK 배포" 작업에 앱 URL을 표시하려면](#deploy-app-url-cdk)
+ [" CloudFormation 스택 배포" 작업에 앱 URL을 표시하려면](#deploy-app-url-cfn)
+ [다른 모든 작업에 앱 URL을 표시하려면](#deploy-app-url-other)
URL 구성을 완료했으면 다음 지침에 따라 URL이 예상대로 표시되는지 확인합니다.
+ [애플리케이션 URL이 추가되었는지 확인하려면](#deploy-app-url-verify)
**"AWS CDK 배포" 작업에 앱 URL을 표시하려면**
1. **AWS CDK 배포** 작업을 사용하는 경우 AWS CDK 애플리케이션 코드에 `CfnOutput` 구문(키-값 페어)을 추가합니다.
+ 키 이름에는 대시(`-`), 밑줄(`_`) 또는 공백(` `)이 있거나 없는 `appurl` 또는 `endpointurl`이 포함되어야 합니다. 문자열은 대/소문자를 구분하지 않습니다.
+ 값은 배포된 애플리케이션의 `http` 또는 `https` URL이어야 합니다.
예를 들어 AWS CDK 코드는 다음과 같을 수 있습니다.
```
import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as s3 from 'aws-cdk-lib/aws-s3';
import { Construct } from 'constructs';
import * as cdk from 'aws-cdk-lib';
export class HelloCdkStack extends Stack {
constructor(scope: Construct, id: string, props?: StackProps) {
super(scope, id, props);
const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
removalPolicy: RemovalPolicy.DESTROY,
});
new CfnOutput(this, 'APP-URL', {
value: https://mycompany.myapp.com,
description: 'The URL of the deployed application',
exportName: 'myApp',
});
...
}
}
```
`CfnOutput` 구문에 대한 자세한 내용은 *AWS Cloud Development Kit (AWS CDK) API 참조*의 [인터페이스 CfnOutputProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutputProps.html)를 참조하세요.
1. 코드를 저장하고 커밋합니다.
1. [애플리케이션 URL이 추가되었는지 확인하려면](#deploy-app-url-verify)로 이동합니다.
**" CloudFormation 스택 배포" 작업에 앱 URL을 표시하려면**
1. ** CloudFormation 스택 배포** 작업을 사용하는 경우 다음과 같은 특성을 가진 CloudFormation 템플릿 또는 AWS SAM 템플릿의 `Outputs` 섹션에 출력을 추가합니다.
+ 키(논리적 ID라고도 함)에는 대시(`-`), 밑줄(`_`) 또는 공백(` `)이 있거나 없는 `appurl` 또는 `endpointurl`이 포함되어야 합니다. 문자열은 대/소문자를 구분하지 않습니다.
+ 값은 배포된 애플리케이션의 `http` 또는 `https` URL이어야 합니다.
예를 들어 CloudFormation 템플릿은 다음과 같습니다.
```
"Outputs" : {
"APP-URL" : {
"Description" : "The URL of the deployed app",
"Value" : "https://mycompany.myapp.com",
"Export" : {
"Name" : "My App"
}
}
}
```
CloudFormation에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [출력](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html)을 참조하세요.
1. 코드를 저장하고 커밋합니다.
1. [애플리케이션 URL이 추가되었는지 확인하려면](#deploy-app-url-verify)로 이동합니다.
**다른 모든 작업에 앱 URL을 표시하려면**
빌드 작업 또는 **GitHub Actions**와 같은 다른 작업을 사용하여 애플리케이션을 배포하는 경우 다음을 수행하여 앱 URL을 표시합니다.
1. 워크플로 정의 파일의 작업 `Inputs` 또는 `Steps` 섹션에서 환경 변수를 정의합니다. 변수는 다음과 같은 특성을 가져야 합니다.
+ `name`에는 대시(`-`), 밑줄(`_`) 또는 공백(` `)이 있거나 없는 `appurl` 또는 `endpointurl`이 포함되어야 합니다. 문자열은 대/소문자를 구분하지 않습니다.
+ 값은 배포된 애플리케이션의 `http` 또는 `https` URL이어야 합니다.
예를 들어 빌드 작업은 다음과 같을 수 있습니다.
```
Build-action:
Identifier: aws/build@v1
Inputs:
Variables:
- Name: APP-URL
Value: https://mycompany.myapp.com
```
아니면 다음과 같습니다.
```
Actions:
Build:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: APP-URL=https://mycompany.myapp.com
```
환경 변수 정의에 대한 자세한 내용은 [변수 정의](workflows-working-with-variables-define-input.md) 섹션을 참조하세요.
1. 변수를 내보냅니다.
예를 들어 빌드 작업은 다음과 같습니다.
```
Build-action:
...
Outputs:
Variables:
- APP-URL
```
변수에 대한 자세한 내용은 [다른 작업에서 사용할 수 있도록 변수 내보내기](workflows-working-with-variables-export-input.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
1. [애플리케이션 URL이 추가되었는지 확인하려면](#deploy-app-url-verify)로 이동합니다.
**애플리케이션 URL이 추가되었는지 확인하려면**
+ 워크플로가 자동으로 시작되지 않은 경우 워크플로 실행을 시작합니다. 새 실행에는 워크플로 다이어그램에 클릭 가능한 링크로 표시되는 앱 URL이 있어야 합니다. 분석 시작하기에 대한 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
# 배포 대상 제거
CodeCatalyst 콘솔의 배포 대상 페이지에서 Amazon ECS 클러스터 또는 CloudFormation 스택과 같은 **배포 대상**을 제거할 수 있습니다.
**중요**
배포 대상을 제거하면 CodeCatalyst 콘솔에서 제거되지만 해당 배포 대상을 호스팅하는 AWS 서비스에서는 계속 사용할 수 있습니다(있는 경우).
CodeCatalyst에서 대상이 오래된 경우 배포 대상을 제거하는 것이 좋습니다. 다음과 같은 경우 대상이 오래될 수 있습니다.
+ 대상에 배포된 워크플로를 삭제했습니다.
+ 배포하려는 스택 또는 클러스터를 변경했습니다.
+ AWS 콘솔의 CloudFormation 또는 Amazon ECS 서비스에서 스택 또는 클러스터를 삭제했습니다.
**배포 대상을 제거하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **환경**을 선택합니다.
1. 제거하려는 배포 대상이 포함된 환경의 이름을 선택합니다. 환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 섹션을 참조하세요.
1. **배포 대상** 탭을 선택합니다.
1. 제거하려는 배포 대상 옆의 라디오 버튼을 선택합니다.
1. **** 제거를 선택합니다.
대상이 페이지에서 제거됩니다.
# 커밋별 배포 상태 추적
개발 수명 주기 중 언제든 버그 수정, 새로운 특성 또는 기타 영향력 있는 변경 사항과 같은 특정 커밋의 배포 상태를 파악하는 것이 중요합니다. 배포 상태 추적 기능이 개발팀에 도움이 되는 다음 시나리오를 고려해 보세요.
+ 개발자로서 버그를 해결하기 위해 수정 사항을 만들었고 팀의 배포 환경 전체에 배포된 상태를 보고하려고 합니다.
+ 릴리스 관리자는 배포된 커밋 목록을 보고 배포 상태를 추적하고 보고하려고 합니다.
CodeCatalyst는 개별 커밋 또는 변경 사항이 배포된 위치와 환경을 한 눈에 확인할 수 있는 보기를 제공합니다. 이 보기에는 다음이 포함됩니다.
+ 커밋 목록입니다.
+ 커밋을 포함하는 배포의 상태입니다.
+ 커밋이 성공적으로 배포되는 환경입니다.
+ CI/CD 워크플로에서 커밋에 대해 실행되는 모든 테스트의 상태입니다.
다음 절차에서는 이 보기로 이동하고 이 보기를 사용하여 프로젝트의 변경 사항을 추적하는 방법을 자세히 설명합니다.
**참고**
커밋별 배포 상태 추적은 [CodeCatalyst 리포지토리](source.md)에서만 지원됩니다. 이 특성은 [GitHub 리포지토리, Bitbucket 리포지토리 또는 GitLab 프로젝트 리포지토리](extensions.md)에서는 사용할 수 없습니다.
**커밋별 배포 상태 추적**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **추적 변경**을 선택합니다.
1. 메인 창 상단에 있는 두 개의 드롭다운 목록에서 릴리스 상태를 보려는 커밋이 포함된 소스 리포지토리와 브랜치를 선택합니다.
1. **변경 사항 보기**를 선택합니다.
커밋 목록이 나타납니다.
각 클러스터에 대해 다음을 볼 수 있습니다.
+ ID, 작성자, 메시지 및 커밋 시기와 같은 정보를 커밋합니다. 자세한 내용은 [CodeCatalyst의 소스 리포지토리로 코드 저장 및 협업소스 리포지토리를 사용하여 코드 저장 및 협업](source.md) 섹션을 참조하세요.
+ 각 환경에 대한 배포 상태입니다. 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 섹션을 참조하세요.
+ 테스트 및 코드 적용 범위 결과입니다. 자세한 내용은 [워크플로를 사용한 테스트워크플로를 사용한 테스트](test-workflow-actions.md) 섹션을 참조하세요.
**참고**
소프트웨어 구성 분석(SCA) 결과는 표시되지 않습니다.
1. 최신 배포, 자세한 코드 커버리지 및 단위 테스트 정보 등 특정 커밋과 관련된 변경 사항에 대한 자세한 정보를 보려면 해당 커밋에 대한 **세부 정보 보기**를 선택합니다.
# 배포 로그 보기
Amazon CodeCatalyst의 문제를 해결하기 위해 특정 배포 작업과 관련된 로그를 볼 수 있습니다.
[워크플로](workflow.md) 또는 [환경](deploy-environments.md)에서 시작하는 로그를 볼 수 있습니다.
**워크플로에서 시작하는 배포 작업의 로그를 보려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **실행**을 선택합니다.
1. 애플리케이션을 배포한 워크플로 실행을 선택합니다.
1. 워크플로 다이어그램에서 로그를 보려는 작업을 선택합니다.
1. **로그** 탭을 선택하고 섹션을 확장하여 로그 메시지를 표시합니다.
1. 더 많은 로그를 보려면 **요약** 탭을 선택한 다음 **CloudFormation에서 보기**(사용 가능한 경우)를 선택하여 더 많은 로그를 봅니다. AWS에 로그인해야 할 수도 있습니다.
**환경에서 시작하는 배포 작업의 로그를 보려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **환경**을 선택합니다.
1. 애플리케이션이 배포된 환경을 선택합니다.
1. **배포 활동**에서 **워크플로 실행 ID** 열을 찾고 스택을 배포한 워크플로 실행을 선택합니다.
1. 워크플로 다이어그램에서 로그를 보려는 작업을 선택합니다.
1. **로그** 탭을 선택하고 섹션을 확장하여 로그 메시지를 표시합니다.
1. 더 많은 로그를 보려면 **요약** 탭을 선택한 다음 **CloudFormation에서 보기**(사용 가능한 경우)를 선택하여 더 많은 로그를 봅니다. AWS에 로그인해야 할 수도 있습니다.
# 배포 정보 보기
Amazon CodeCatalyst에서 배포에 대한 다음 정보를 볼 수 있습니다.
+ 배포 상태, 시작 시간, 종료 시간, 기록 및 이벤트 기간을 포함한 배포 활동입니다.
+ 스택 이름, AWS 리전마지막 업데이트 시간 및 관련 워크플로.
+ 요청을 커밋하고 가져옵니다.
+ CloudFormation 이벤트 및 출력과 같은 작업별 정보입니다.
[워크플로](workflow.md), [환경](deploy-environments.md) 또는 워크플로 [작업](workflows-concepts.md#workflows-concepts-actions)부터 배포 정보를 볼 수 있습니다.
**워크플로에서 시작하는 배포 정보를 보려면**
+ 애플리케이션을 배포한 워크플로 실행으로 이동합니다. 지침은 [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md) 섹션을 참조하세요.
**환경에서 시작하는 배포 정보를 보려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **환경**을 선택합니다.
1. `Production` 같이 스택이 배포된 환경을 선택합니다.
1. **배포 활동**을 선택하여 스택의 배포 기록, 배포 상태(예: **성공** 또는 **실패**) 및 기타 배포 관련 정보를 확인합니다.
1. 환경에 배포된 스택, 클러스터 또는 기타 대상에 대한 정보를 보려면 **배포 대상**을 선택합니다. 스택 이름, 리전, 공급자 및 식별자와 같은 정보를 볼 수 있습니다.
**작업에서 시작하는 배포 정보를 보려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 워크플로 다이어그램에서 애플리케이션을 배포한 워크플로 작업을 선택합니다. 예를 들어 **DeployCloudFormationStack**을 선택할 수 있습니다.
1. 작업별 배포 정보는 오른쪽 창의 내용을 검토하세요.
# 워크플로 생성
*워크플로*는 지속적 통합 및 지속적 전송(CI/CD) 시스템의 일부로 코드를 빌드, 테스트 및 배포하는 방법을 설명하는 자동화된 절차입니다. 워크플로는 워크플로 실행 중에 수행할 일련의 단계 또는 *작업*을 정의합니다. 또한 워크플로는 워크플로를 시작하게 하는 이벤트 또는 *트리거*를 정의합니다. 워크플로를 설정하려면 CodeCatalyst 콘솔의 [시각적 또는 YAML 편집기](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors)를 사용하여 *워크플로 정의 파일*을 생성합니다.
**작은 정보**
프로젝트에서 워크플로를 사용하는 방법을 간략하게 알아보려면 [블루프린트가 있는 프로젝트를 생성](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template)합니다. 각 블루프린트는 검토, 실행 및 실험할 수 있는 기능 워크플로를 배포합니다.
CodeCatalyst에서 워크플로를 생성하려면 다음 절차를 따르세요. 워크플로는 선택한 소스 리포지토리의 `~/.codecatalyst/workflows/` 폴더에 YAML 파일로 저장됩니다. 선택적으로 워크플로를 커밋할 때 워크플로 파일 이름 앞에 폴더 이름을 붙여 워크플로를 `~/.codecatalyst/workflows/`의 하위 폴더에 저장할 수 있습니다. 자세한 내용은 다음 지침을 참조하세요.
워크플로에 대한 자세한 내용은 [워크플로를 사용하여 빌드, 테스트 및 배포워크플로를 사용하여 빌드, 테스트 및 배포](workflow.md) 섹션을 참조하세요.
------
#### [ Visual ]
**시각적 편집기를 사용하여 워크플로 생성**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
**워크플로 생성** 대화 상자가 표시됩니다.
1. **소스 리포지토리** 필드에서 워크플로 정의 파일이 상주할 소스 리포지토리를 선택합니다. 소스 리포지토리가 없는 경우 [하나를 생성](source-repositories-create.md)합니다.
1. **브랜치** 필드에서 워크플로 정의 파일이 상주할 브랜치를 선택합니다.
1. **생성(Create)**을 선택합니다.
Amazon CodeCatalyst는 리포지토리 및 브랜치 정보를 메모리에 저장하지만 워크플로는 아직 커밋되지 않았습니다.
1. **비주얼**을 선택합니다.
1. 워크플로 빌드:
1. (선택 사항) 워크플로 다이어그램에서 **소스** 및 **트리거** 상자를 선택합니다. **트리거** 창이 나타납니다. 트리거에 연결하려면 **트리거 추가**를 선택합니다. 자세한 내용은 [워크플로에 트리거 추가](workflows-add-trigger-add.md) 섹션을 참조하세요.
1. **\$1 작업**(상단 왼쪽)을 선택합니다. **작업** 카탈로그가 나타납니다.
1. 작업 내에서 더하기 기호(**\$1**)를 선택하여 워크플로에 추가합니다. 오른쪽에 있는 창을 사용하여 작업을 구성합니다. 자세한 내용은 [워크플로에 작업 추가](workflows-add-action.md) 섹션을 참조하세요.
1. (선택 사항) **워크플로 속성**(오른쪽 상단)을 선택합니다. **워크플로 속성** 창이 나타납니다. 워크플로 이름 실행 모드 및 컴퓨팅을 구성합니다. 자세한 내용은 [실행의 대기열 동작 구성](workflows-configure-runs.md) 및 [컴퓨팅 및 런타임 이미지 구성](workflows-working-compute.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 **커밋 워크플로** 대화 상자에서 다음을 수행합니다.
1. **워크플로 파일 이름**에 이름을 입력하거나 기본 이름을 그대로 유지합니다. 파일은 선택한 소스 리포지토리 및 브랜치의 `~/.codecatalyst/workflows/` 폴더에 저장됩니다. 파일 이름 앞에 폴더 또는 하위 폴더를 붙일 수 있습니다. 예시:
+ `my-workflow`(폴더 없음)를 지정하면 파일을 `~/.codecatalyst/workflows/my-workflow.yaml`로 저장
+ `folder/subfolder/my-workflow`를 지정하면 파일을 `~/.codecatalyst/workflows/folder/subfolder/my-workflow.yaml`로 저장
1. **커밋 메시지**의 경우 기본 메시지를 그대로 두거나 직접 입력합니다.
1. **리포지토리** 및 **브랜치**에서 워크플로 정의 파일의 소스 리포지토리 및 브랜치를 선택합니다. 이러한 필드는 **워크플로 생성** 대화 상자에서 앞서 지정한 리포지토리 및 브랜치로 설정해야 합니다. 원하는 경우 지금 리포지토리와 브랜치를 변경할 수 있습니다.
**참고**
워크플로 정의 파일을 커밋한 후에는 다른 리포지토리 또는 브랜치와 연결할 수 없으므로 신중하게 선택해야 합니다.
1. **커밋**을 선택하여 워크플로 정의 파일을 커밋합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 워크플로 생성**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
**워크플로 생성** 대화 상자가 표시됩니다.
1. **소스 리포지토리** 필드에서 워크플로 정의 파일이 상주할 소스 리포지토리를 선택합니다. 소스 리포지토리가 없는 경우 [하나를 생성](source-repositories-create.md)합니다.
1. **브랜치** 필드에서 워크플로 정의 파일이 상주할 브랜치를 선택합니다.
1. **생성(Create)**을 선택합니다.
Amazon CodeCatalyst는 리포지토리 및 브랜치 정보를 메모리에 저장하지만 워크플로는 아직 커밋되지 않았습니다.
1. **YAML**을 선택합니다.
1. 워크플로 빌드:
1. (선택 사항) YAML 코드에 트리거를 추가합니다. 자세한 내용은 [워크플로에 트리거 추가](workflows-add-trigger-add.md) 섹션을 참조하세요.
1. **\$1 작업**(상단 왼쪽)을 선택합니다. **작업** 카탈로그가 나타납니다.
1. 작업 내에서 더하기 기호(**\$1**)를 선택하여 워크플로에 추가합니다. 오른쪽에 있는 창을 사용하여 작업을 구성합니다. 자세한 내용은 [워크플로에 작업 추가](workflows-add-action.md) 섹션을 참조하세요.
1. (선택 사항) **워크플로 속성**(오른쪽 상단)을 선택합니다. **워크플로 속성** 창이 나타납니다. 워크플로 이름, 실행 모드 및 컴퓨팅을 구성합니다. 자세한 내용은 [실행의 대기열 동작 구성](workflows-configure-runs.md) 및 [컴퓨팅 및 런타임 이미지 구성](workflows-working-compute.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 **커밋 워크플로** 대화 상자에서 다음을 수행합니다.
1. **워크플로 파일 이름**에 이름을 입력하거나 기본 이름을 그대로 유지합니다. 파일은 선택한 소스 리포지토리 및 브랜치의 `~/.codecatalyst/workflows/` 폴더에 저장됩니다. 파일 이름 앞에 폴더 또는 하위 폴더를 붙일 수 있습니다. 예시:
+ `my-workflow`(폴더 없음)를 지정하면 파일을 `~/.codecatalyst/workflows/my-workflow.yaml`로 저장
+ `folder/subfolder/my-workflow`를 지정하면 파일을 `~/.codecatalyst/workflows/folder/subfolder/my-workflow.yaml`로 저장
1. **커밋 메시지**의 경우 기본 메시지를 그대로 두거나 직접 입력합니다.
1. **리포지토리** 및 **브랜치**에서 워크플로 정의 파일의 소스 리포지토리 및 브랜치를 선택합니다. 이러한 필드는 **워크플로 생성** 대화 상자에서 앞서 지정한 리포지토리 및 브랜치로 설정해야 합니다. 원하는 경우 지금 리포지토리와 브랜치를 변경할 수 있습니다.
**참고**
워크플로 정의 파일을 커밋한 후에는 다른 리포지토리 또는 브랜치와 연결할 수 없으므로 신중하게 선택해야 합니다.
1. **커밋**을 선택하여 워크플로 정의 파일을 커밋합니다.
------
# 워크플로 실행
*실행*은 워크플로의 단일 반복입니다. 실행하는 동안 CodeCatalyst는 워크플로 구성 파일에 정의된 작업을 수행하고 관련 로그, 아티팩트 및 변수를 출력합니다.
*워크플로 트리거*를 통해 수동으로 실행을 시작하거나 자동으로 실행할 수 있습니다. 워크플로 트리거의 예시로는 기본 브랜치에 커밋을 푸시하는 소프트웨어 개발자가 있습니다.
실수로 워크플로를 시작한 경우 처리 도중에 실행 중인 워크플로를 수동으로 중지할 수도 있습니다.
여러 워크플로 실행이 거의 동시에 시작되는 경우 이러한 실행을 대기열에 넣는 방법을 구성할 수 있습니다. 실행이 시작된 순서대로 차례로 대기하는 기본 대기 동작을 사용하거나, 나중에 실행된 실행이 이전 실행을 대체(또는 '인수')하도록 하여 전체적으로 실행 속도를 높일 수 있습니다. 워크플로 실행을 병렬로 실행하여 다른 실행을 기다리지 않도록 설정하는 것도 가능합니다.
워크플로 실행을 수동 또는 자동으로 시작한 후에는 실행 상태 및 기타 세부 정보를 볼 수 있습니다. 예를 들어 언제 시작되었는지, 누가 시작했는지, 아직 실행 중인지 등을 확인할 수 있습니다.
**Topics**
+ [워크플로 수동 실행 시작](workflows-manually-start.md)
+ [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md)
+ [수동 전용 트리거 구성](workflows-manual-only.md)
+ [워크플로 실행 중지](workflows-stop.md)
+ [워크플로 게이팅](workflows-gates.md)
+ [워크플로 실행에 대한 승인 요구](workflows-approval.md)
+ [실행의 대기열 동작 구성](workflows-configure-runs.md)
+ [워크플로 실행 간 파일 캐싱](workflows-caching.md)
+ [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md)
# 워크플로 수동 실행 시작
Amazon CodeCatalyst에서 CodeCatalyst 콘솔에서 수동으로 워크플로 실행을 시작할 수 있습니다.
워크플로 실행에 대한 자세한 내용은 [워크플로 실행](workflows-working-runs.md) 섹션을 참조하세요.
**참고**
[트리거를 구성](workflows-add-trigger.md)하여 워크플로 실행을 자동으로 시작할 수도 있습니다.
**워크플로 실행 수동 시작**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **실행**을 선택합니다.
# 트리거를 사용하여 워크플로 실행 자동 시작
워크플로 트리거를 사용하여 Amazon CodeCatalyst 워크플로가 자동으로 실행되도록 시작할 수 있습니다.
*워크플로 트리거* 또는 간단히 *트리거*를 사용하면 코드 푸시와 같은 특정 이벤트가 발생하면 워크플로 실행을 자동으로 시작할 수 있습니다. 트리거를 구성하여 소프트웨어 개발자가 CodeCatalyst 콘솔을 통해 워크플로 실행을 수동으로 시작하지 않아도 되도록 할 수 있습니다.
세 가지 유형의 트리거를 사용할 수 있습니다.
+ **푸시** - 코드 푸시 트리거는 커밋이 푸시될 때마다 워크플로 실행을 시작하도록 합니다.
+ **풀 요청** - 풀 요청 트리거는 풀 요청이 생성, 수정 또는 종료될 때마다 워크플로 실행을 시작하게 합니다.
+ **일정** - 일정 트리거는 정의한 일정에 따라 워크플로 실행이 시작되도록 합니다. 소프트웨어 개발자가 다음 날 아침에 작업할 수 있도록 최신 빌드를 준비할 수 있도록 일정 트리거를 사용하여 소프트웨어의 야간 빌드를 실행하는 것을 고려하세요.
푸시, 풀 요청 및 예약 트리거를 단독으로 사용하거나 동일한 워크플로에서 조합하여 사용할 수 있습니다.
트리거는 선택 사항입니다. 구성하지 않으면 워크플로를 수동으로만 시작할 수 있습니다.
**작은 정보**
트리거가 실제로 작동하는지 확인하려면 블루프린트가 있는 프로젝트를 시작합니다. 대부분의 블루프린트에는 트리거가 있는 워크플로가 포함되어 있습니다. 블루프린트의 워크플로 정의 파일에서 `Trigger` 속성을 찾습니다. 청사진에 대한 자세한 내용은 [블루프린트를 사용하여 프로젝트 생성](projects-create.md#projects-create-console-template)을 참조하세요.
**Topics**
+ [예시: 워크플로의 트리거](workflows-add-trigger-examples.md)
+ [트리거 및 브랜치 사용 지침](workflows-add-trigger-considerations.md)
+ [워크플로에 트리거 추가](workflows-add-trigger-add.md)
# 예시: 워크플로의 트리거
다음 예시에서는 Amazon CodeCatalyst 워크플로 정의 파일에 다양한 유형의 트리거를 추가하는 방법을 보여줍니다.
트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
**Topics**
+ [예시: 간단한 코드 푸시 트리거](#workflows-add-trigger-examples-push-simple)
+ [예시: 간단한 '메인으로 푸시' 트리거](#workflows-add-trigger-examples-push-main)
+ [예시: 간단한 풀 요청 트리거](#workflows-add-trigger-examples-pull-simple)
+ [예시: 간단한 일정 트리거](#workflows-add-trigger-examples-schedule-simple)
+ [예시: 일정 및 브랜치가 있는 트리거](#workflows-add-trigger-examples-schedule-branches)
+ [예시: 일정, 푸시 및 브랜치가 있는 트리거](#workflows-add-trigger-examples-schedule-push-branches)
+ [예시: 풀 및 브랜치가 있는 트리거](#workflows-add-trigger-examples-pull-branches)
+ [예시: 풀, 브랜치 및 'CLOSED' 이벤트가 있는 트리거](#workflows-add-trigger-examples-push-pull-close)
+ [예시: 푸시, 브랜치 및 파일이 있는 트리거](#workflows-add-trigger-examples-push-multi)
+ [예시: 수동 트리거](#workflows-add-trigger-examples-manual)
+ [예시: CI/CD 다중 워크플로 설정의 트리거](#workflows-add-trigger-usecases)
## 예시: 간단한 코드 푸시 트리거
다음 예시는 소스 리포지토리의 *모든* 브랜치로 코드가 푸시될 때마다 워크플로 실행을 시작하는 트리거를 보여줍니다.
이 트리거가 활성화되면 CodeCatalyst는 푸시*하려는* 브랜치(즉, 대상 브랜치)의 파일을 사용하여 워크플로 실행을 시작합니다.
예를 들어 커밋을 `main`에 푸시하면 CodeCatalyst는 `main`의 워크플로 정의 파일 및 기타 소스 파일을 사용하여 워크플로 실행을 시작합니다.
또 다른 예를 들면 커밋을 `feature-branch-123`에 푸시하면 CodeCatalyst는 `feature-branch-123`의 워크파우 정의 파일 및 기타 소스 파일을 사용하여 워크플로 실행을 시작합니다.
```
Triggers:
- Type: PUSH
```
**참고**
`main`으로 푸시할 때만 워크플로 실행을 시작하려면 [예시: 간단한 '메인으로 푸시' 트리거](#workflows-add-trigger-examples-push-main) 섹션을 참조하세요.
## 예시: 간단한 '메인으로 푸시' 트리거
다음 예시는 소스 리포지토리에서 코드가 `main` 브랜치(및 `main` 브랜치*만*)에 푸시될 때마다 워크플로 실행을 시작하는 트리거를 보여줍니다.
```
Triggers:
- Type: PUSH
Branches:
- main
```
## 예시: 간단한 풀 요청 트리거
다음 예시는 소스 리포지토리에서 풀 요청이 생성되거나 수정될 때마다 워크플로 실행을 시작하는 트리거를 보여줍니다.
이 트리거가 활성화되면 CodeCatalyst는 워크플로 정의 파일과 *가져오려는* 브랜치(즉, 소스 브랜치)의 다른 소스 파일을 사용하여 워크플로 실행을 시작합니다.
예를 들어, `feature-123` 소스 브랜치와 `main` 대상 브랜치가 있는 풀 요청을 만들면 CodeCatalyst는 `feature-123`에서 워크플로 정의 파일 및 기타 소스 파일을 사용하여 워크플로 실행을 시작합니다.
```
Triggers:
- Type: PULLREQUEST
Events:
- OPEN
- REVISION
```
## 예시: 간단한 일정 트리거
다음 예시는 매주 월요일부터 금요일까지 자정(UTC\$10)에 워크플로 실행을 시작하는 트리거를 보여줍니다.
이 트리거가 활성화되면 CodeCatalyst는 이 트리거가 포함된 워크플로 정의 파일이 포함된 소스 리포지토리의 각 브랜치에 대해 단일 워크플로 실행을 시작합니다.
예를 들어 소스 리포지토리에 `main`, `release-v1`, `feature-123`라는 세 개의 브랜치가 있고 각 브랜치에 트리거가 다음과 같은 워크플로 정의 파일이 포함된 경우 CodeCatalyst는 세 개의 워크플로 실행을 시작합니다. 하나는 `main`의 파일을 사용하고, 다른 하나는 `release-v1`의 파일을 사용하며, 다른 하나는 `feature-123`의 파일을 사용합니다.
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 ? * MON-FRI *"
```
`Expression` 속성에서 사용할 수 있는 cron 표현식의 자세한 예시는 [Expression](workflow-reference.md#workflow.triggers.expression) 섹션을 참조하세요.
## 예시: 일정 및 브랜치가 있는 트리거
다음 예시는 매일 오후 6시 15분(UTC\$10)에 워크플로 실행을 시작하는 트리거를 보여줍니다.
이 트리거가 활성화되면 CodeCatalyst는 `main` 브랜치의 파일을 사용하여 워크플로 실행을 시작하고 `release-`로 시작하는 각 브랜치에 대해 추가 실행을 시작합니다.
예를 들어 소스 리포지토리에 `main`, `release-v1`, `bugfix-1`, `bugfix-2`라는 브랜치가 있는 경우 CodeCatalyst는 두 개의 워크플로 실행을 시작합니다. 하나는 `main`의 파일을 사용하고 다른 하나는 `release-v1`의 파일을 사용합니다. `bugfix-1` 및 `bugfix-1` 브랜치에 대한 워크플로 실행을 시작*하지* 않습니다.
```
Triggers:
- Type: SCHEDULE
Expression: "15 18 * * ? *"
Branches:
- main
- release\-.*
```
`Expression` 속성에서 사용할 수 있는 cron 표현식의 자세한 예시는 [Expression](workflow-reference.md#workflow.triggers.expression) 섹션을 참조하세요.
## 예시: 일정, 푸시 및 브랜치가 있는 트리거
다음 예시에서는 매일 자정(UTC\$10)에 워크플로 실행을 시작하는 트리거와 코드가 `main` 브랜치로 푸시될 때마다 트리거를 보여줍니다.
이 예시에서는 다음이 적용됩니다.
+ 워크플로 실행은 매일 자정에 시작됩니다. 워크플로 실행은 `main` 브랜치의 워크플로 정의 파일 및 기타 소스 파일을 사용합니다.
+ 워크플로 실행은 또한 `main` 브랜치에 커밋을 푸시할 때마다 시작됩니다. 워크플로 실행은 대상 브랜치(`main`)의 워크플로 정의 파일 및 기타 소스 파일을 사용합니다.
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 * * ? *"
Branches:
- main
- Type: PUSH
Branches:
- main
```
`Expression` 속성에서 사용할 수 있는 cron 표현식의 자세한 예시는 [Expression](workflow-reference.md#workflow.triggers.expression) 섹션을 참조하세요.
## 예시: 풀 및 브랜치가 있는 트리거
다음 예시는 누군가 `main` 대상 브랜치로 풀 요청을 열거나 수정할 때마다 워크플로 실행을 시작하는 트리거를 보여줍니다. `Triggers` 구성에 지정된 브랜치는 `main`이지만 워크플로 실행은 소스 브랜치(*가져오는*브랜치)의 워크플로 정의 파일 및 기타 *소스* 파일을 사용합니다.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
## 예시: 풀, 브랜치 및 'CLOSED' 이벤트가 있는 트리거
다음 예시는 `main`로 시작하는 브랜치에서 풀 요청이 종료될 때마다 워크플로 실행을 시작하는 트리거를 보여줍니다.
이 예시에서는 다음이 적용됩니다.
+ `main`으로 시작하는 대상 브랜치로 풀 요청을 닫으면 워크플로 정의 파일과 (현재 닫힌) 소스 브랜치의 기타 소스 파일을 사용하여 워크플로 실행이 자동으로 시작됩니다.
+ 풀 요청이 병합된 후 소스 리포지토리가 브랜치를 자동으로 삭제하도록 구성한 경우 이러한 브랜치는 `CLOSED` 상태로 들어갈 기회가 없습니다. 즉, 병합된 브랜치는 풀 요청 `CLOSED` 트리거를 활성화하지 않습니다. 이 시나리오에서 `CLOSED` 트리거를 활성화하는 유일한 방법은 병합하지 않고 풀 요청을 닫는 것입니다.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- CLOSED
```
## 예시: 푸시, 브랜치 및 파일이 있는 트리거
다음 예시는 `main` 브랜치의 `filename.txt` 파일 또는 `src` 디렉터리에 있는 파일을 변경할 때마다 워크플로 실행을 시작하는 트리거를 보여줍니다.
이 트리거가 활성화되면 CodeCatalyst는 `main` 브랜치의 워크플로 정의 파일 및 기타 소스 파일을 사용하여 워크플로 실행을 시작합니다.
```
Triggers:
- Type: PUSH
Branches:
- main
FilesChanged:
- filename.txt
- src\/.*
```
## 예시: 수동 트리거
수동 트리거를 구성하려면 워크플로 정의 파일에서 `Triggers` 섹션을 생략합니다. 이 섹션이 없으면 사용자는 CodeCatalyst 콘솔에서 **실행** 버튼을 선택하여 워크플로를 수동으로 시작해야 합니다. 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
## 예시: CI/CD 다중 워크플로 설정의 트리거
이 예시에서는 지속적 통합(CI) 및 지속적 전송(CD)을 위해 별도의 Amazon CodeCatalyst 워크플로를 사용하려는 경우 트리거를 설정하는 방법을 설명합니다.
이 시나리오에서는 두 가지 워크플로를 설정합니다.
+ **CI 워크플로** - 이 워크플로는 풀 요청이 생성되거나 수정될 때 애플리케이션을 빌드하고 테스트합니다.
+ **CD 워크플로** - 이 워크플로는 풀 요청이 병합될 때 애플리케이션을 빌드하고 배포합니다.
**CI 워크플로**의 정의 파일은 다음과 비슷합니다.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
Actions:
BuildAction:
instructions-for-building-the-app
TestAction:
instructions-for-test-the-app
```
`Triggers` 코드는 소프트웨어 개발자가 특성 브랜치를 `main`브랜치에 병합하도록 요청하는 풀 요청을 생성할 때마다(또는 [수정](pull-requests-update.md)할 때마다) 워크플로 실행을 자동으로 시작하도록 나타냅니다. CodeCatalyst는 소스 브랜치(기능 브랜치)의 소스 코드를 사용하여 워크플로 실행을 시작합니다.
**CD 워크플로**의 정의 파일은 다음과 비슷합니다.
```
Triggers:
- Type: PUSH
Branches:
- main
Actions:
BuildAction:
instructions-for-building-the-app
DeployAction:
instructions-for-deploying-the-app
```
`Triggers` 코드는 `main`에 병합이 발생할 때 워크플로를 자동으로 시작하도록 나타냅니다. CodeCatalyst는 `main` 브랜치의 소스 코드를 사용하여 워크플로 실행을 시작합니다.
# 트리거 및 브랜치 사용 지침
이 섹션에서는 브랜치를 포함하는 Amazon CodeCatalyst 트리거를 설정할 때의 몇 가지 주요 지침에 대해 설명합니다.
트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ **지침 1:** 푸시 및 풀 요청 트리거 모두에서 브랜치를 지정하려면 트리거 구성에서 대상(또는 '대상') 브랜치를 지정해야 합니다. 소스(또는 'from') 브랜치를 지정하지 마세요.
다음 예시에서는 브랜치에서 `main`을 눌러 워크플로를 활성화합니다.
```
Triggers:
- Type: PUSH
Branches:
- main
```
다음 예시에서는 `main`으로 브랜치에서 요청을 가져오면 워크플로가 활성화됩니다.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
+ **지침 2:** 푸시 트리거의 경우 워크플로가 활성화되면 *destination* 브랜치에 있는 워크플로 정의 파일과 소스 파일을 사용하여 워크플로가 실행됩니다.
+ **지침 3:** 풀 요청 트리거의 경우 워크플로가 활성화되면 트리거 구성에서 대상 브랜치를 지정했더라도 *source* 브랜치에 있는 워크플로 정의 파일과 소스 파일을 사용하여 워크플로가 실행됩니다.
+ **지침 4:** 한 브랜치에서 정확히 동일한 트리거가 다른 브랜치에서는 실행되지 않을 수 있습니다.
다음 푸시 트리거를 고려합니다.
```
Triggers:
- Type: PUSH
Branches:
- main
```
이 트리거가 포함된 워크플로 정의 파일이 `main`에 존재하고 `test`에 복제된 경우 워크플로는 `test`의 파일을 사용하여 자동으로 시작되지 않습니다(`test`의 파일을 사용하도록 워크플로를 *수동*으로 시작할 수는 있지만). **지침 2**를 검토하여 `test`의 파일을 사용하여 워크플로가 자동으로 실행되지 않는 이유를 알아봅니다.
다음과 같은 풀 요청 트리거도 고려해 보세요.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
이 트리거가 포함된 워크플로 정의 파일이 `main`에 있는 경우 워크플로는 `main`의 파일을 사용하여 실행되지 않습니다. (단, `main`의 `test` 브랜치를 생성하면 워크플로는 `test`의 파일을 사용하여 실행됩니다.) **지침 3**을 검토하여 이유를 이해합니다.
# 워크플로에 트리거 추가
다음 지침에 따라 Amazon CodeCatalyst 워크플로에 푸시, 풀 또는 일정 트리거를 추가합니다.
트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
------
#### [ Visual ]
**트리거 추가(시각 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 **소스** 및 **트리거** 상자를 선택합니다.
1. 구성 창에서 **트리거 추가**를 선택합니다.
1. **트리거 추가** 대화 상자에서 다음과 같이 필드에 정보를 입력합니다.
**트리거 유형**
트리거 유형을 지정합니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **푸시**(시각적 편집기) 또는 `PUSH`(YAML 편집기)
푸시 트리거는 변경 사항이 소스 리포지토리로 푸시될 때 워크플로 실행을 시작합니다. 워크플로 실행은 푸시 *대상* 브랜치(즉, 대상 브랜치)의 파일을 사용합니다.
+ **풀 요청**(시각적 편집기) 또는 `PULLREQUEST`(YAML 편집기)
풀 요청 트리거는 소스 리포지토리에서 풀 요청이 열리거나 업데이트되거나 닫힐 때 워크플로 실행을 시작합니다. 워크플로 실행은 *가져오려는* 브랜치(즉, 소스 브랜치)의 파일을 사용합니다.
+ **일정**(시각적 편집기) 또는 `SCHEDULE`(YAML 편집기)
일정 트리거는 지정한 cron 표현식으로 정의된 일정에 따라 워크플로를 실행합니다. 브랜치 파일을 사용하여 소스 리포지토리의 각 브랜치에 대해 별도의 워크플로 실행이 시작됩니다. (트리거가 활성화되는 브랜치를 제한하려면 **브랜치** 필드(시각적 편집기) 또는 `Branches` 속성(YAML 편집기)을 사용합니다.)
일정 트리거를 구성할 때는 다음 지침을 따르세요.
+ 워크플로당 하나의 일정 트리거만 사용합니다.
+ CodeCatalyst 스페이스에 여러 워크플로를 정의한 경우 동시에 시작하도록 10개 이하로 예약하는 것이 좋습니다.
+ 실행 사이에 충분한 시간을 두고 트리거의 cron 표현식을 구성해야 합니다. 자세한 내용은 [Expression](workflow-reference.md#workflow.triggers.expression) 섹션을 참조하세요.
예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
**풀 요청에 대한 이벤트**
이 필드는 **풀 요청** 트리거 유형을 선택한 경우에만 나타납니다.
워크플로 실행을 시작할 풀 요청 이벤트의 유형을 지정합니다. 유효한 값은 다음과 같습니다.
+ **풀 요청이 생성됨**(시각적 편집기) 또는 `OPEN`(YAML 편집기)
풀 요청이 생성되면 워크플로 실행이 시작됩니다.
+ **풀 요청이 닫힘**(시각적 편집기) 또는 `CLOSED`(YAML 편집기)
풀 요청이 종료되면 워크플로 실행이 시작됩니다. `CLOSED` 이벤트의 동작은 까다롭고 예시를 통해 가장 잘 이해됩니다. 자세한 정보는 [예시: 풀, 브랜치 및 'CLOSED' 이벤트가 있는 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close)을 참조하세요.
+ **풀 요청에 대한 새 개정**(시각적 편집기) 또는 `REVISION`(YAML 편집기)
워크플로 실행은 풀 요청에 대한 개정이 생성될 때 시작됩니다. 풀 요청이 생성되면 첫 번째 개정이 생성됩니다. 그런 다음 풀 요청에 지정된 소스 브랜치에 새 커밋을 푸시할 때마다 새 개정이 생성됩니다. 풀 요청 트리거에 `REVISION` 이벤트를 포함하는 경우 `REVISION`는 `OPEN`의 수퍼 세트이므로 `OPEN` 이벤트를 생략할 수 있습니다.
동일한 풀 요청 트리거에서 여러 이벤트를 지정할 수 있습니다.
예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
**Schedule**
이 필드는 **일정** 트리거 유형을 선택한 경우에만 나타납니다.
예약된 워크플로 실행 시기를 설명하는 cron 표현식을 지정합니다.
CodeCatalyst의 Cron 표현식은 다음과 같은 6개 필드 구문을 사용합니다. 여기서 각 필드는 공백으로 구분됩니다.
*minutes* *hours* *days-of-month* *month* *days-of-week* *year*
**cron 표현식의 예**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/workflows-add-trigger-add.html)
CodeCatalyst에서 cron 표현식을 지정할 때는 다음 지침을 따라야 합니다.
+ `SCHEDULE` 트리거당 단일 cron 표현식을 지정합니다.
+ YAML 편집기에서 cron 표현식을 큰따옴표(`"`)로 묶습니다.
+ 시간은 협정 세계시(UTC)로 지정합니다. 다른 시간대는 지원되지 않습니다.
+ 실행 간격은 최소 30분으로 구성합니다. 더 빠른 주기는 지원되지 않습니다.
+ *days-of-month* 또는 *days-of-week* 필드를 지정하되 둘 다 지정하지는 않습니다. 필드 중 하나에 값 또는 별표(`*`)를 지정하는 경우 다른 필드에는 물음표(`?`)를 사용해야 합니다. 별표는 '모두'를 의미하고 물음표는 '모두'를 의미합니다.
cron 표현식의 더 많은 예시와 `?`, `*`, `L`과 같은 와일드카드에 대한 정보는 *Amazon EventBridge 사용 설명서*의 [cron 표현식 참조](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html)를 참조하세요. EventBridge 및 CodeCatalyst의 Cron 표현식은 정확히 동일한 방식으로 작동합니다.
일정 트리거의 예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
**브랜치** 및 **브랜치 패턴**
(선택 사항)
워크플로 실행을 시작할 시기를 알기 위해 트리거가 모니터링하는 소스 리포지토리의 브랜치를 지정합니다. 정규식 패턴을 사용하여 브랜치 이름을 정의할 수 있습니다. 예를 들어 `main.*`을 사용하여 `main`으로 시작하는 모든 브랜치를 일치시킵니다.
지정할 브랜치는 트리거 유형에 따라 다릅니다.
+ 푸시 트리거의 경우 푸시 *대상* 브랜치, 즉 *대상* 브랜치를 지정합니다. 일치하는 브랜치의 파일을 사용하여 일치하는 브랜치당 하나의 워크플로 실행이 시작됩니다.
예시: `main.*`, `mainline`
+ 풀 요청의 경우 *푸시할* 브랜치, 즉 *대상* 브랜치를 지정합니다. 워크플로 정의 파일과 소스 브랜치(일치하는 브랜치 *아님*)의 **소스** 파일을 사용하여 일치하는 브랜치당 하나의 워크플로 실행이 시작됩니다.
예시: `main.*`, `mainline`, `v1\-.*`(`v1-`로 시작하는 브랜치와 일치)
+ 일정 트리거의 경우 예약된 실행에서 사용할 파일이 포함된 브랜치를 지정합니다. 워크플로 정의 파일과 일치하는 브랜치의 소스 파일을 사용하여 일치하는 브랜치당 하나의 워크플로 실행이 시작됩니다.
예시: `main.*`, `version\-1\.0`
**참고**
브랜치를 지정하지 *않으면* 트리거는 소스 리포지토리의 모든 브랜치를 모니터링하고 다음에서 워크플로 정의 파일 및 소스 파일을 사용하여 워크플로 실행을 시작합니다.
푸시 *대상* 브랜치(푸시 트리거용). 자세한 내용은 [예시: 간단한 코드 푸시 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple) 섹션을 참조하세요.
풀 *원본* 브랜치(풀 요청 트리거용). 자세한 내용은 [예시: 간단한 풀 요청 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple) 섹션을 참조하세요.
모든 브랜치(일정 트리거용). 소스 리포지토리의 브랜치당 워크플로 실행이 한 번 시작됩니다. 자세한 내용은 [예시: 간단한 일정 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple) 섹션을 참조하세요.
브랜치 및 트리거에 대한 자세한 내용은 [트리거 및 브랜치 사용 지침](workflows-add-trigger-considerations.md) 섹션을 참조하세요.
더 많은 예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md)를 참조합니다.
**파일 변경됨**
이 필드는 **푸시** 또는 **풀 요청** 트리거 유형을 선택한 경우에만 나타납니다.
워크플로 실행을 시작해야 하는 시기를 알 수 있도록 트리거가 모니터링하는 소스 리포지토리의 파일 또는 폴더를 지정합니다. 정규식을 사용하여 파일 이름 또는 경로와 일치시킬 수 있습니다.
예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**트리거 추가(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 다음 예시를 안내서로 사용하여 `Triggers` 섹션 및 기본 속성을 추가합니다. 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 [Triggers](workflow-reference.md#triggers-reference)를 참조하세요.
코드 푸시 트리거는 다음과 같을 수 있습니다.
```
Triggers:
- Type: PUSH
Branches:
- main
```
풀 요청 트리거는 다음과 같을 수 있습니다.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- OPEN
- REVISION
- CLOSED
```
일정 트리거는 다음과 같을 수 있습니다.
```
Triggers:
- Type: SCHEDULE
Branches:
- main.*
# Run the workflow at 1:15 am (UTC+0) every Friday until the end of 2023
Expression: "15 1 ? * FRI 2022-2023"
```
`Expression` 속성에서 사용할 수 있는 cron 표현식의 자세한 예시는 [Expression](workflow-reference.md#workflow.triggers.expression) 섹션을 참조하세요.
푸시, 풀 요청 및 일정 트리거의 자세한 예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 수동 전용 트리거 구성
CodeCatalyst 콘솔의 **실행** 버튼을 사용하여 팀에서 수동으로만 워크플로를 시작할 수 있도록 워크플로를 제한할 수 있습니다. 이 기능을 구성하려면 워크플로 정의 파일에서 `Triggers` 섹션을 제거해야 합니다. `Triggers` 섹션은 워크플로를 생성할 때 기본적으로 포함되지만, 섹션은 선택 사항이며 제거할 수 있습니다.
워크플로를 수동으로만 시작할 수 있도록 다음 지침에 따라 워크플로 정의 파일의 `Triggers` 섹션을 제거합니다.
트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
워크플로 실행에 대한 자세한 내용은 [워크플로 실행](workflows-working-runs.md) 섹션을 참조하세요.
------
#### [ Visual ]
**'Triggers' 섹션 제거(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 **소스** 상자를 선택합니다.
1. **트리거**에서 휴지통 아이콘을 선택하여 워크플로에서 `Triggers` 섹션을 제거합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**'Triggers' 섹션 제거(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. `Triggers` 섹션을 찾아 제거합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 워크플로 실행 중지
진행 중인 워크플로 실행을 중지하려면 다음 절차를 따르세요. 실수로 시작된 경우 실행을 중지할 수 있습니다.
워크플로 실행을 중지하면 CodeCatalyst는 진행 중인 작업이 완료될 때까지 기다렸다가 CodeCatalyst 콘솔에서 실행을 **중지됨**으로 표시합니다. 시작할 기회를 얻지 못한 모든 작업은 시작되지 않고 **중단됨**으로 표시됩니다.
**참고**
실행이 대기열에 있는 경우(즉, 진행 중인 작업이 없는 경우) 실행이 즉시 중지됩니다.
워크플로 실행에 대한 자세한 내용은 [워크플로 실행](workflows-working-runs.md) 섹션을 참조하세요.
**워크플로 실행 중지**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로**에서 **실행**을 선택하고 목록에서 진행 중인 실행을 선택합니다.
1. **중지**를 선택합니다.
# 워크플로 게이팅
*게이트*는 특정 조건이 충족되지 않으면 워크플로 실행이 진행되지 않도록 하는 데 사용할 수 있는 워크플로 구성 요소입니다. 게이트의 예시로는 사용자가 워크플로 실행을 계속하기 전에 CodeCatalyst 콘솔에서 승인을 제출해야 하는 **승인** 게이트를 들 수 있습니다.
워크플로의 일련의 작업 사이에 또는 첫 번째 작업(**소스** 다운로드 직후에 실행되는) 전에 게이트를 추가할 수 있습니다. 필요한 경우 마지막 작업 후 게이트를 추가할 수도 있습니다.
워크플로 실행에 대한 자세한 내용은 [워크플로 실행](workflows-working-runs.md) 섹션을 참조하세요.
**Topics**
+ [게이트 유형](#workflows-gates-types)
+ [다른 작업과 병렬로 실행되도록 게이트를 설정할 수 있나요?](#workflows-approval-parallel)
+ [게이트를 사용하여 워크플로 실행이 시작되지 않도록 할 수 있나요?](#workflows-gates-prevent)
+ [게이트의 제한 사항](#workflows-gate-limitations)
+ [워크플로에 게이트 추가](workflows-gates-add.md)
+ [게이트 및 작업 순서 지정](workflows-gates-depends-on.md)
+ [게이트의 버전 지정](workflows-gates-version.md)
## 게이트 유형
현재 Amazon CodeCatalyst는 **승인** 게이트라는 한 가지 유형의 게이트를 지원합니다. 자세한 내용은 [워크플로 실행에 대한 승인 요구](workflows-approval.md) 섹션을 참조하세요.
## 다른 작업과 병렬로 실행되도록 게이트를 설정할 수 있나요?
아니요. 게이트는 작업 전후에만 실행할 수 있습니다. 자세한 내용은 [게이트 및 작업 순서 지정](workflows-gates-depends-on.md) 섹션을 참조하세요.
## 게이트를 사용하여 워크플로 실행이 시작되지 않도록 할 수 있나요?
예, 자격 조건이 있습니다.
워크플로 실행이 *태스크를 수행*하지 못하도록 할 수 있습니다. 이는 워크플로 실행이 *시작*하지 못하도록 하는 것과 약간 다릅니다.
워크플로가 작업을 수행하지 못하도록 워크플로의 첫 번째 작업 앞에 게이트를 추가합니다. 이 시나리오에서는 워크플로 실행이 *시작됩니다.* 즉, 소스 리포지토리 파일을 다운로드하지만 게이트가 잠금 해제될 때까지 태스크를 수행할 수 없습니다.
**참고**
워크플로가 시작되었다가 게이트에 의해 차단된 경우에도 *스페이스당 최대 동시 워크플로 실행 수* 할당량 및 기타 할당량에 포함됩니다. 워크플로 할당량을 초과하지 않도록 하려면 게이트를 사용하는 대신 워크플로 트리거를 사용하여 워크플로를 조건부로 시작하는 것이 좋습니다. 게이트 대신 풀 요청 승인 규칙을 사용하는 것도 좋습니다. 할당량, 트리거 및 풀 요청 승인 규칙에 대한 자세한 내용은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md), [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 및 [풀 요청을 승인 규칙과 병합하기 위한 요구 사항 관리](source-pull-requests-approval-rules.md) 섹션을 참조하세요.
## 게이트의 제한 사항
게이트에는 다음과 같은 제한 사항이 있습니다.
+ 게이츠는 컴퓨팅 공유 특성과 함께 사용할 수 없습니다. 이 기능에 대한 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md)을 참조하세요.
+ 게이트는 작업 그룹 내에서 사용할 수 없습니다. 작업 그룹에 대한 자세한 내용은 [작업을 작업 그룹으로 그룹화](workflows-group-actions.md) 섹션을 참조하세요.
# 워크플로에 게이트 추가
Amazon CodeCatalyst에서는 워크플로에 게이트를 추가하여 특정 조건이 충족되지 않으면 진행되지 않도록 할 수 있습니다. 다음 안내에 따라 워크플로에 게이트를 추가합니다.
게이트에 대한 자세한 내용은 [워크플로 게이팅](workflows-gates.md) 섹션을 참조하세요.
**게이트 추가 및 구성**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **Edit**(편집)을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽에서 **게이트**를 선택합니다.
1. 게이트 카탈로그에서 게이트를 검색한 다음 더하기 기호(**\$1**)를 선택하여 워크플로에 게이트를 추가합니다.
1. 게이스 구성 시각적 편집기를 사용하려면 **비주얼**을 선택하고, YAML 편집기를 사용하려면 **YAML**을 선택합니다. 자세한 지침은 다음을 참조하세요.
+ ['승인' 게이트 추가](workflows-approval-add.md)
1. (선택 사항) YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택하여 변경 사항을 커밋합니다.
# 게이트 및 작업 순서 지정
Amazon CodeCatalyst에서는 워크플로 작업, 작업 그룹 또는 게이트의 전후에 실행되도록 게이트를 설정할 수 있습니다. 예를 들어 `Deploy` 작업 전에 실행할 `Approval` 게이트를 설정할 수 있습니다. 이 경우 `Deploy` 작업은 `Approval` 게이트에 *종속된다*고 합니다.
게이트와 작업 간의 종속성을 설정하려면 게이트 또는 작업의 **Depends on** 속성을 구성합니다. 지침은 [작업 간 종속성 설정](workflows-depends-on-set-up.md) 섹션을 참조하세요. 참조된 지침은 워크플로 *작업*을 참조하지만 게이트에도 동일하게 적용됩니다.
게이트에서 **Depends on** 속성을 설정하는 방법의 예시는 [예시: '승인' 게이트](workflows-approval-example.md) 섹션을 참조하세요.
게이트에 대한 자세한 내용은 [워크플로 게이팅](workflows-gates.md) 섹션을 참조하세요.
워크플로 작업에 대한 자세한 내용은 [워크플로 작업 구성](workflows-actions.md) 섹션을 참조하세요.
# 게이트의 버전 지정
기본적으로 워크플로에 게이트를 추가하면 CodeCatalyst는 형식을 사용하여 워크플로 정의 파일에 전체 버전을 추가합니다.
`vmajor.minor.patch`
예:
```
My-Gate:
Identifier: aws/approval@v1
```
워크플로가 특정 메이저 또는 마이너 버전의 게이트를 사용하도록 버전을 늘릴 수 있습니다. 지침은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요. 참조된 주제는 워크플로 작업을 참조하지만 게이트에도 동일하게 적용됩니다.
CodeCatalyst의 게이트에 대한 자세한 내용은 [워크플로 게이팅](workflows-gates.md) 섹션을 참조하세요.
# 워크플로 실행에 대한 승인 요구
워크플로 실행을 구성하여 진행하기 전에 승인이 필요하도록 할 수 있습니다. 이렇게 하려면 워크플로에 **승인** [게이트](workflows-gates.md)를 추가해야 합니다. *승인 게이트*는 사용자 또는 사용자 집합이 CodeCatalyst 콘솔에서 하나 이상의 승인을 제출할 때까지 워크플로가 진행되지 않도록 합니다. 모든 승인이 제공되면 게이트가 '잠금 해제됨' 상태가 되고 워크플로 실행을 재개할 수 있습니다.
워크플로의 **승인** 게이트를 사용하여 개발, 운영 및 리더십 팀이 변경 사항을 더 많은 대상에 배포하기 전에 검토할 수 있는 기회를 제공합니다.
워크플로 실행에 대한 자세한 내용은 [워크플로 실행](workflows-working-runs.md) 섹션을 참조하세요.
**Topics**
+ [승인 게이트를 잠금 해제하려면 어떻게 해야 하나요?](#workflows-approval-conditions)
+ ['승인' 게이트를 사용해야 하는 경우](#workflows-approval-when)
+ [누가 승인을 제공할 수 있나요?](#workflows-approval-who)
+ [사용자에게 승인이 필요함을 알리려면 어떻게 해야 하나요?](#workflows-approval-notify-methods)
+ ['승인' 게이트를 사용하여 워크플로 실행이 시작되지 않도록 할 수 있나요?](#workflows-approval-prevent)
+ [워크플로 승인은 대기 중 실행, 대체된 실행 및 병렬 실행 모드에서 어떻게 작동하나요?](#workflows-approval-run-mode)
+ [예시: '승인' 게이트](workflows-approval-example.md)
+ ['승인' 게이트 추가](workflows-approval-add.md)
+ [승인 알림 구성](workflows-approval-notify.md)
+ [워크플로 실행 승인 또는 거부](workflows-approval-approve.md)
+ ['승인' 게이트 YAML](approval-ref.md)
## 승인 게이트를 잠금 해제하려면 어떻게 해야 하나요?
**승인** 게이트를 잠금 해제하려면 다음 조건을 *모두* 충족해야 합니다.
+ **조건 1**: 필요한 승인 수를 제출해야 합니다. 필요한 승인 수는 구성 가능하며 각 사용자는 단일 승인을 제출할 수 있습니다.
+ **조건 2**: 게이트 제한 시간 전에 모든 승인을 제출해야 합니다. 게이트는 활성화되고 14일 후에 시간 초과됩니다. 이 기간은 구성할 수 없습니다.
+ **조건 3**: 아무도 워크플로 실행을 거부해서는 안 됩니다. 단일 거부로 인해 워크플로 실행이 실패합니다.
+ **조건 4**: (대체된 실행 모드를 사용하는 경우에만 적용됩니다.) 이후 실행으로 실행을 대체해서는 안 됩니다. 자세한 내용은 [워크플로 승인은 대기 중 실행, 대체된 실행 및 병렬 실행 모드에서 어떻게 작동하나요?](#workflows-approval-run-mode) 섹션을 참조하세요.
조건이 충족되지 않으면 CodeCatalyst는 워크플로를 중지하고 실행 상태를 **실패**(**조건 1**\$1**3**의 경우) 또는 **대체됨**(**조건 4**의 경우)으로 설정합니다.
## '승인' 게이트를 사용해야 하는 경우
일반적으로 애플리케이션 및 기타 리소스를 프로덕션 서버 또는 품질 표준을 검증해야 하는 환경에 배포하는 워크플로에서 **승인** 게이트를 사용합니다. 프로덕션으로 배포하기 전에 게이트를 배치하면 검토자가 새 소프트웨어 개정을 공개적으로 사용할 수 있게 되기 전에 검증할 수 있습니다.
## 누가 승인을 제공할 수 있나요?
프로젝트의 멤버가고 **기여자** 또는 **프로젝트 관리자** 역할이 있는 모든 사용자는 승인을 제공할 수 있습니다. 프로젝트 스페이스에 속한 **스페이스 관리자** 역할을 가진 사용자도 승인을 제공할 수 있습니다.
**참고**
**검토자** 역할을 가진 사용자는 승인을 제공할 수 없습니다.
## 사용자에게 승인이 필요함을 알리려면 어떻게 해야 하나요?
사용자에게 승인이 필요함을 알리려면 다음을 수행해야 합니다.
+ CodeCatalyst가 Slack 알림을 보내도록 합니다. 자세한 내용은 [승인 알림 구성](workflows-approval-notify.md) 섹션을 참조하세요.
+ **승인** 및 **거부** 버튼이 있는 CodeCatalyst 콘솔의 페이지로 이동하여 해당 페이지의 URL을 승인자에게 전달되는 이메일 또는 메시징 애플리케이션에 붙여넣습니다. 이 페이지로 이동하는 방법에 대한 자세한 내용은 [워크플로 실행 승인 또는 거부](workflows-approval-approve.md) 섹션을 참조하세요.
## '승인' 게이트를 사용하여 워크플로 실행이 시작되지 않도록 할 수 있나요?
예, 자격 조건이 있습니다. 자세한 내용은 [게이트를 사용하여 워크플로 실행이 시작되지 않도록 할 수 있나요?](workflows-gates.md#workflows-gates-prevent) 섹션을 참조하세요.
## 워크플로 승인은 대기 중 실행, 대체된 실행 및 병렬 실행 모드에서 어떻게 작동하나요?
대기 중, 대체된, 병렬로 실행 모드를 사용하는 경우 **승인** 게이트는 [작업](workflows-actions.md)과 유사한 방식으로 작동합니다. 이러한 실행 모드를 숙지하려면 [대기 중 실행 모드 정보](workflows-configure-runs.md#workflows-configure-runs-queued), [대체된 실행 모드 정보](workflows-configure-runs.md#workflows-configure-runs-superseded), [병렬 실행 모드 정보](workflows-configure-runs.md#workflows-configure-runs-parallel) 섹션을 읽는 것이 좋습니다. 이러한 실행 모드에 대한 기본적인 이해가 되면 이 섹션으로 돌아가서 **승인** 게이트가 있을 때 이러한 실행 모드가 어떻게 작동하는지 알아봅니다.
**승인** 게이트가 있으면 다음과 같이 실행이 처리됩니다.
+ [대기 중 실행 모드](workflows-configure-runs.md#workflows-configure-runs-queued)를 사용하는 경우 실행은 현재 게이트에서 승인을 기다리고 있는 실행 뒤에 대기합니다. 해당 게이트가 잠금 해제되면(즉, 모든 승인이 제공됨) 대기열의 다음 실행이 게이트로 진행되고 승인을 기다립니다. 이 프로세스는 대기 중 실행이 게이트를 통해 하나씩 처리되는 동안 계속됩니다. [Figure 1](#figure-1-workflow-queued-run-mode-ma)는 이 프로세스를 보여줍니다.
+ [대체된 실행 모드](workflows-configure-runs.md#workflows-configure-runs-superseded)를 사용하는 경우 동작은 대기열에 있는 실행 모드의 동작과 동일합니다. 단, 게이트에서 대기열에 파일을 쌓는 대신 새 실행이 이전 실행을 대체(인수)합니다. 대기열이 없으며 현재 게이트에서 승인을 기다리고 있는 모든 실행은 취소되고 최신 실행으로 대체됩니다. [Figure 2](#figure-2-workflow-superseded-run-mode-ma)는 이 프로세스를 보여줍니다.
+ [병렬 실행 모드](workflows-configure-runs.md#workflows-configure-runs-parallel)를 사용하는 경우 실행이 병렬로 시작되며 대기열이 형성되지 않습니다. 앞에 실행이 없으므로 각 실행은 게이트에서 즉시 처리됩니다. [Figure 3](#figure-3-workflow-parallel-run-mode-ma)는 이 프로세스를 보여줍니다.
**그림 1**: '대기 중 실행 모드' 및 **승인** 게이트
![\['승인' 게이트가 '대기 중 실행 모드'와 작동하는 방법\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png)
**그림 2**: '대체된 실행 모드' 및 **승인** 게이트
![\['승인' 게이트가 '대체된 실행 모드'와 작동하는 방식\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png)
**그림 3**: '병렬 실행 모드' 및 **승인** 게이트
![\['승인' 게이트가 '병렬 실행 모드'로 작동하는 방법\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png)
# 예시: '승인' 게이트
다음 예시는 `Staging`과 `Production`이라는 두 작업 사이에 `Approval_01`라는 **승인** 게이트를 추가하는 방법을 보여줍니다. `Staging` 작업이 먼저 실행되고, `Approval_01` 게이트가 두 번째로 실행되며, `Production` 작업이 마지막으로 실행됩니다. `Production` 작업은 `Approval_01` 게이트가 잠금 해제된 경우에만 실행됩니다. `DependsOn` 속성은 `Staging`, `Approval_01` 및 `Production` 단계가 순차적으로 실행되도록 합니다.
**승인** 게이트에 대한 자세한 내용은 [워크플로 실행에 대한 승인 요구](workflows-approval.md) 섹션을 참조하세요.
```
Actions:
Staging: # Deploy to a staging server
Identifier: aws/ecs-deploy@v1
Configuration:
...
Approval_01:
Identifier: aws/approval@v1
DependsOn:
- Staging
Configuration:
ApprovalsRequired: 2
Production: # Deploy to a production server
Identifier: aws/ecs-deploy@v1
DependsOn:
- Approval_01
Configuration:
...
```
# '승인' 게이트 추가
승인이 필요하도록 워크플로를 구성하려면 워크플로에 **승인** 게이트를 추가해야 합니다. 다음 지침에 따라 워크플로에 **승인** 게이트를 추가합니다.
이 게이트에 대한 자세한 내용은 [워크플로 실행에 대한 승인 요구](workflows-approval.md) 섹션을 참조하세요.
------
#### [ Visual ]
**워크플로에 '승인' 게이트 추가(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. 왼쪽 상단에서 **게이트**를 선택합니다.
1. **게이트** 카탈로그의 **승인** 에서 더하기 기호(**\$1**)를 선택합니다.
1. **입력**을 선택하고 **종속 대상** 필드에서 다음을 수행합니다.
이 게이트를 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다. 기본적으로 워크플로에 게이트를 추가할 때 게이트는 워크플로의 마지막 작업에 따라 달라지도록 설정됩니다. 이 속성을 제거하면 게이트가 다른 작업에 종속되지 않고 다른 작업보다 먼저 실행됩니다.
**참고**
작업, 작업 그룹 또는 게이트 전후에 실행되도록 게이트를 구성해야 합니다. 다른 작업, 작업 그룹 및 게이트와 동시에 실행되도록 설정할 수 없습니다.
**Depends on** 함수에 대한 자세한 내용은 [게이트 및 작업 순서 지정](workflows-gates-depends-on.md) 섹션을 참조하세요.
1. **구성** 탭을 선택합니다.
1. **게이트 이름** 필드에서 다음을 수행합니다.
게이트에 부여할 이름을 지정합니다. 모든 게이트 이름은 워크플로 내에서 고유해야 합니다. 게이트 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스는 허용되지 않습니다. 게이트 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
1. (선택 사항) **승인 수** 필드에서 다음을 수행합니다.
**승인** 게이트를 잠금 해제하는 데 필요한 최소 승인 수를 지정합니다. 최소값은 `1`입니다. 최대값은 `2`입니다. 생략 시 기본값은 `1`입니다.
**참고**
`ApprovalsRequired` 속성을 생략하려면 워크플로 정의 파일에서 게이트 `Configuration` 섹션을 제거합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**워크플로에 '승인' 게이트 추가(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 다음 예시를 가이드로 사용하여 `Approval` 섹션 및 기본 속성을 추가합니다. 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 ['승인' 게이트 YAML](approval-ref.md)를 참조하세요.
```
Actions:
MyApproval_01:
Identifier: aws/approval@v1
DependsOn:
- PreviousAction
Configuration:
ApprovalsRequired: 2
```
다른 예시는 [예시: '승인' 게이트](workflows-approval-example.md)를 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 승인 알림 구성
CodeCatalyst가 워크플로 실행에 승인이 필요하다는 알림을 사용자에게 Slack 채널로 보내도록 할 수 있습니다. 사용자는 알림을 보고 해당 알림 내에 있는 링크를 클릭합니다. 이 링크는 워크플로를 승인하거나 거부할 수 있는 CodeCatalyst 승인 페이지로 이동합니다.
워크플로가 승인되었거나 거부되었거나 승인 요청이 만료되었음을 사용자에게 알리도록 알림을 구성할 수도 있습니다.
다음 지침에 따라 Slack 알림을 설정합니다.
**시작하기 전 준비 사항**
워크플로에 **승인** 게이트를 추가했는지 확인합니다. 자세한 내용은 ['승인' 게이트 추가](workflows-approval-add.md) 섹션을 참조하세요.
**Slack 채널로 워크플로 승인 알림 보내기**
1. Slack을 사용하여 CodeCatalyst를 구성합니다. 자세한 내용은 [스택 알림 시작하기](getting-started-notifications.md) 섹션을 참조하세요.
1. 승인이 필요한 워크플로가 포함된 CodeCatalyst 프로젝트에서 알림이 아직 활성화되어 있지 않은 경우 활성화합니다. 알림을 활성화하려면:
1. 프로젝트로 이동하고 탐색 창에서 **프로젝트 설정**을 선택합니다.
1. 상단에서 **알림**을 선택합니다.
1. **알림 이벤트**에서 **알림 편집**을 선택합니다.
1. **워크플로 승인 보류**를 켜고 CodeCatalyst가 알림을 보낼 Slack 채널을 선택합니다.
1. (선택 사항) 승인, 거부 및 만료된 승인에 대해 사용자에게 알리려면 추가 알림을 켭니다. **워크플로 실행 승인됨**, **워크플로 실행 거부됨**, **워크플로 승인 대체됨** 및 **워크플로 승인 제한 시간 초과됨**을 설정할 수 있습니다. 각 알림 옆에서 CodeCatalyst가 알림을 보낼 Slack 채널을 선택합니다.
1. **저장**을 선택합니다.
# 워크플로 실행 승인 또는 거부
**승인** 게이트가 포함된 워크플로 실행은 승인 또는 거부되어야 합니다. 사용자는 다음 시점부터 승인 또는 거부를 제공할 수 있습니다.
+ CodeCatalyst 콘솔
+ 팀원이 제공하는 링크
+ 자동 Slack 알림
사용자가 승인 또는 거부의 의사를 밝힌 후에는 이 결정을 되돌릴 수 없습니다.
**참고**
특정 사용자만 워크플로 실행을 승인하거나 거부할 수 있습니다. 자세한 내용은 [누가 승인을 제공할 수 있나요?](workflows-approval.md#workflows-approval-who) 섹션을 참조하세요.
**시작하기 전 준비 사항**
워크플로에 **승인** 게이트를 추가했는지 확인합니다. 자세한 내용은 ['승인' 게이트 추가](workflows-approval-add.md) 섹션을 참조하세요.
**CodeCatalyst 콘솔에서 시작하는 워크플로 실행 승인 또는 거부**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 워크플로 다이어그램에서 **승인** 게이트를 나타내는 상자를 선택합니다.
측면 패널이 나타납니다.
**참고**
이때 원한다면 이 페이지의 URL을 다른 승인자에게 보낼 수 있습니다.
1. **검토 결정**에서 **승인** 또는 **거부**를 선택합니다.
1. (선택 사항) **설명 - 선택 사항**에 워크플로 실행을 승인하거나 거부한 이유를 나타내는 설명을 입력합니다.
1. **제출**을 선택합니다.
**팀원이 제공한 링크에서 시작하는 워크플로 실행 승인 또는 거부**
1. 팀원이 전송한 링크를 선택합니다. (팀원에게 위의 절차를 읽고 링크를 받도록 할 수 있습니다.)
1. 메시지가 표시되면 CodeCatalyst에 로그인합니다.
워크플로 실행 승인 페이지로 리디렉션됩니다.
1. **검토 결정**에서 **승인** 또는 **거부**를 선택합니다.
1. (선택 사항) **설명 - 선택 사항**에 워크플로 실행을 승인하거나 거부한 이유를 나타내는 설명을 입력합니다.
1. **제출**을 선택합니다.
**자동 Slack 알림에서 시작하는 워크플로 실행 승인 또는 거부**
1. Slack 알림이 설정되어 있는지 확인합니다. [승인 알림 구성](workflows-approval-notify.md)을(를) 참조하세요.
1. Slack의 승인 알림이 전송된 채널에서 승인 알림의 링크를 선택합니다.
1. 메시지가 표시되면 CodeCatalyst에 로그인합니다.
워크플로 실행 페이지로 리디렉션됩니다.
1. 워크플로 다이어그램에서 승인 게이트를 선택합니다.
1. **검토 결정**에서 **승인** 또는 **거부**를 선택합니다.
1. (선택 사항) **설명 - 선택 사항**에 워크플로 실행을 승인하거나 거부한 이유를 나타내는 설명을 입력합니다.
1. **제출**을 선택합니다.
# '승인' 게이트 YAML
다음은 **승인** 게이트의 YAML 정의입니다. 이 게이트에 대해 자세히 알아보려면 [워크플로 실행에 대한 승인 요구](workflows-approval.md) 섹션을 참조하세요.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The 'Approval' gate definition starts here.
Approval:
Identifier: aws/approval@v1
DependsOn:
- another-action
Configuration:
ApprovalsRequired: number
```
## Approval
(필수)
게이트에 부여할 이름을 지정합니다. 모든 게이트 이름은 워크플로 내에서 고유해야 합니다. 게이트 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스는 허용되지 않습니다. 게이트 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
기본값: `Approval_nn`.
해당 UI: 구성 탭/**게이트 이름**
## Identifier
(*Approval*/**Identifier**)
(필수)
게이트를 식별합니다. **승인** 게이트는 버전 `1.0.0`을 지원합니다. 버전을 단축하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
기본값: `aws/approval@v1`.
해당 UI: 워크플로 다이어그램/Approval\$1nn/**aws/approval@v1** 레이블
## DependsOn
(*Approval*/**DependsOn**)
(선택 사항)
이 게이트를 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다. 기본적으로 워크플로에 게이트를 추가할 때 게이트는 워크플로의 마지막 작업에 따라 달라지도록 설정됩니다. 이 속성을 제거하면 게이트가 다른 작업에 종속되지 않고 다른 작업보다 먼저 실행됩니다.
**참고**
작업, 작업 그룹 또는 게이트 전후에 실행되도록 게이트를 구성해야 합니다. 다른 작업, 작업 그룹 및 게이트와 동시에 실행되도록 설정할 수 없습니다.
**Depends on** 함수에 대한 자세한 내용은 [게이트 및 작업 순서 지정](workflows-gates-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존**
## Configuration
(*Approval*/**Configuration**)
(선택 사항)
게이트의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## ApprovalsRequired
(*Approval*/Configuration/**ApprovalsRequired**)
(선택 사항)
**승인** 게이트를 잠금 해제하는 데 필요한 최소 승인 수를 지정합니다. 최소값은 `1`입니다. 최대값은 `2`입니다. 생략 시 기본값은 `1`입니다.
**참고**
`ApprovalsRequired` 속성을 생략하려면 워크플로 정의 파일에서 게이트 `Configuration` 섹션을 제거합니다.
해당 UI: 구성 탭/**승인 수**
# 실행의 대기열 동작 구성
Amazon CodeCatalyst에서 기본적으로 여러 워크플로가 동시에 실행되면 CodeCatalyst는 워크플로를 대기열에 넣고 시작 순서대로 하나씩 처리합니다. *실행 모드*를 지정하여 이 기본 동작을 변경할 수 있습니다. 몇 가지 실행 모드가 있습니다.
+ (기본값) 대기 중 실행 모드 - CodeCatalyst 프로세스가 하나씩 실행됩니다.
+ 대체된 실행 모드 - CodeCatalyst 프로세스는 하나씩 실행되며, 최신 실행은 이전 실행보다 우선합니다.
+ 병렬 실행 모드 - CodeCatalyst 프로세스는 병렬로 실행됩니다.
워크플로 실행에 대한 자세한 내용은 [워크플로 실행](workflows-working-runs.md) 섹션을 참조하세요.
**Topics**
+ [대기 중 실행 모드 정보](#workflows-configure-runs-queued)
+ [대체된 실행 모드 정보](#workflows-configure-runs-superseded)
+ [병렬 실행 모드 정보](#workflows-configure-runs-parallel)
+ [실행 모드 구성](#workflows-configure-runs-configure)
## 대기 중 실행 모드 정보
*대기 중 실행 모드 *에서 실행은 직렬로 수행되며 대기열을 구성하는 대기 실행이 있습니다.
대기열은 작업 및 작업 그룹에 대한 진입점에 형성되므로 *동일한 워크플로 내에 여러 대기열*을 가질 수 있습니다([Figure 1](#figure-1-workflow-queued-run-mode) 참조). 대기 중인 실행이 작업에 들어가면 작업이 잠기고 다른 실행은 입력할 수 없습니다. 실행이 완료되고 작업을 종료하면 작업이 잠금 해제되고 다음 실행을 위한 준비가 됩니다.
[Figure 1](#figure-1-workflow-queued-run-mode) 는 대기 중 실행 모드로 구성된 워크플로를 보여줍니다. 표시되는 정보는 다음과 같습니다.
+ 워크플로를 통해 7번의 실행이 수행됩니다.
+ 두 개의 대기열: 입력 소스에 대한 항목 외부의 대기열(**Repo:main**)과 **BuildTestActionGroup** 작업에 대한 항목 외부의 대기열.
+ 두 개의 잠긴 블록: 입력 소스(**Repo:main**) 및 **BuildTestActionGroup**.
워크플로가 처리 완료를 실행함에 따라 상황이 어떻게 트랜스피어링되는지는 다음과 같습니다.
+ **Run-4d444**가 소스 리포지토리 복제를 완료하면 입력 소스를 종료하고 **Run-3c333** 뒤에 있는 대기열에 조인합니다. 그런 다음 **Run-5e555**가 입력 소스를 입력합니다.
+ **Run-1a111**이 빌드 및 테스트를 완료하면 **BuildTestActionGroup** 작업을 종료하고 **DeployAction** 작업에 들어갑니다. 그런 다음 **Run-2b222**는 **BuildTestActionGroup** 작업에 들어갑니다.
**그림 1**: '대기 중 실행 모드'로 구성된 워크플로
![\['대기 중 실행 모드'로 구성된 워크플로\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png)
다음과 같은 경우 대기 중 실행 모드를 사용합니다.
+ **기능과 실행 간에 일대일 관계를 유지하려는 경우 대체된 모드 를 사용할 때 이러한 기능을 그룹화할 수 있습니다**. 예를 들어 커밋 1에서 기능 1을 병합하면 1이 시작되고 커밋 2에서 기능 2를 병합하면 2가 시작되는 등의 작업이 수행됩니다. 대기중 모드 대신 대체된 모드를 사용하는 경우 다른 기능(및 커밋)을 대체하는 기능(및 커밋)이 실행에서 함께 그룹화됩니다.
+ **병렬 모드 를 사용할 때 발생할 수 있는 레이스 조건과 예상치 못한 문제를 피하려고 합니다**. 예를 들어 Wang과 Saanvi라는 두 소프트웨어 개발자가 Amazon ECS 클러스터에 배포하기 위해 워크플로를 거의 동시에 실행하는 경우 Wang의 실행은 클러스터에서 통합 테스트를 시작할 수 있지만 Saanvi의 실행은 클러스터에 새 애플리케이션 코드를 배포하여 Wang의 테스트가 실패하거나 잘못된 코드를 테스트합니다. 또 다른 예로 잠금 메커니즘이 없는 대상이 있을 수 있습니다. 이 경우 두 실행이 예상치 못한 방식으로 서로의 변경 사항을 덮어쓸 수 있습니다.
+ CodeCatalyst가 실행을 처리하는 데 사용하는 컴퓨팅 리소스에 대한 **부하를 제한하려고** 합니다. 예를 들어 워크플로에 작업이 3개 있는 경우 동시에 최대 3회 실행할 수 있습니다. 한 번에 발생할 수 있는 실행 수에 제한을 가하면 실행 처리량을 더 예측할 수 있습니다.
+ 워크플로를 통해 **타사 서비스에 대한 요청 수를 제한하려고 합니다**. 예를 들어 워크플로에 Docker Hub에서 이미지를 가져오는 지침이 포함된 빌드 작업이 있을 수 있습니다. [Docker Hub는 계정별로 시간당 특정 수로 수행할 수 있는 풀 요청 수를 제한](https://www.docker.com/increase-rate-limits)하며, 한도를 초과하면 잠깁니다. 대기 중 실행 모드를 사용하여 실행 처리량을 줄이면 시간당 Docker Hub에 대한 요청을 더 적게 생성할 수 있으므로 잠금 및 그에 따른 빌드 및 실행 실패의 가능성이 제한됩니다.
**최대 대기열 크기**: 50
**최대 대기열 크기**에 대한 참고 사항:
+ 최대 대기열 크기는 워크플로의 *모든 대기열*에 허용되는 최대 실행 수를 나타냅니다.
+ 대기열이 50회 이상 실행되면 CodeCatalyst는 51번째 및 후속 실행을 삭제합니다.
**실패 동작**:
작업으로 처리되는 동안 실행이 응답하지 않으면 작업 시간이 초과될 때까지 대기열에 실행이 보류됩니다. 1시간 후 작업 제한 시간입니다.
작업 내에서 실행이 실패하면 작업 뒤에 있는 첫 번째 대기 중 실행을 계속 진행할 수 있습니다.
## 대체된 실행 모드 정보
*대체된 실행 모드*는 다음을 제외하고 *대기 중 실행 모드*와 동일합니다.
+ 대기열에서 대기 중인 실행이 대기열의 다른 실행을 따라잡으면 이후 실행이 이전 실행을 대체(인계)하고 이전 실행이 취소되고 '대체됨'으로 표시됩니다.
+ 첫 번째 글머리 기호에 설명된 동작의 결과로 대체된 실행 모드를 사용하는 경우 대기열에 하나의 실행만 포함될 수 있습니다.
[Figure 1](#figure-1-workflow-queued-run-mode)의 워크플로를 가이드로 사용하면 대체된 실행 모드를 이 워크플로에 적용하면 다음과 같은 결과가 발생합니다.
+ **Run-7g777**은 대기열의 다른 두 실행을 대체하며 **Queue \$11**에 남아 있는 유일한 실행입니다. **Run-6f666** 및 **Run-5e555**가 취소됩니다.
+ **Run-3c333**은 **Run-2b222**를 대체하며 **Queue \$12**에 남아 있는 유일한 실행입니다. **Run-2b222**가 취소됩니다.
원하는 경우 대체된 실행 모드를 사용합니다.
+ 대기 중 모드보다 처리량 향상
+ 대기 중 모드보다 타사 서비스에 대한 요청이 훨씬 적음. 이는 타사 서비스에 Docker Hub와 같은 속도 제한이 있는 경우 유용합니다.
## 병렬 실행 모드 정보
*병렬 실행 모드*에서 실행은 서로 독립적이며 시작하기 전에 다른 실행이 완료될 때까지 기다리지 않습니다. 대기열이 없으며 실행 처리량은 워크플로 내 작업이 완료되는 데 걸리는 속도에 따라 제한됩니다.
각 사용자에게 자체 기능 브랜치가 있고 다른 사용자가 공유하지 않는 대상에 배포하는 개발 환경에서 병렬 실행 모드를 사용합니다.
**중요**
프로덕션 환경의 Lambda 함수와 같이 여러 사용자가 배포할 수 있는 공유 대상이 있는 경우 레이스 조건이 발생할 수 있으므로 병렬 모드를 사용하지 마세요. *레이스 조건*은 병렬 워크플로 실행이 공유 리소스를 동시에 변경하려고 시도할 때 발생하며, 이로 인해 예측할 수 없는 결과가 발생합니다.
**최대 병렬 실행 수:** CodeCatalyst 스페이스당 1,000개
## 실행 모드 구성
실행 모드를 대기 중, 대체된 또는 병렬로 설정할 수 있습니다. 기본값은 대기 중입니다.
실행 모드를 대기 중이나 대체된에서 병렬로 변경하면 CodeCatalyst는 대기열에서 대기 중인 실행을 취소하고 현재 작업으로 처리 중인 실행을 취소하기 전에 완료할 수 있도록 허용합니다.
실행 모드를 병렬에서 대기 중 또는 대체된으로 변경하면 CodeCatalyst는 현재 실행 중인 모든 병렬 실행을 완료하도록 허용합니다. 실행 모드를 대기 중 또는 대체된으로 변경한 후 시작하는 모든 실행은 새 모드를 사용합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 실행 모드 변경**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. 오른쪽 상단에서 **워크플로 속성**을 선택합니다.
1. **고급**을 확장하고 **실행 모드**에서 다음 중 하나를 선택합니다.
1. **대기 중** - 참조 [대기 중 실행 모드 정보](#workflows-configure-runs-queued)
1. **대체됨** - [대체된 실행 모드 정보](#workflows-configure-runs-superseded) 참조
1. **병렬** - [병렬 실행 모드 정보](#workflows-configure-runs-parallel) 참조
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 실행 모드 변경**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 다음과 같이 `RunMode` 속성을 추가합니다.
```
Name: Workflow_6d39
SchemaVersion: "1.0"
RunMode: QUEUED|SUPERSEDED|PARALLEL
```
자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 [최상위 속성](workflow-reference.md#workflow.top.level) 섹션에서 `RunMode` 속성에 관한 설명을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 워크플로 실행 간 파일 캐싱
파일 캐싱이 활성화되면 빌드 및 테스트 작업은 온디스크 파일을 캐시에 저장하고 후속 워크플로 실행 시 해당 캐시에서 복원합니다. 캐싱은 실행 간에 변경되지 않은 종속성을 구축하거나 다운로드하여 발생하는 지연 시간을 줄입니다. CodeCatalyst는 필요한 종속성 중 일부를 포함하는 부분 캐시를 복원하는 데 사용할 수 있는 대체 캐시도 지원합니다. 이렇게 하면 캐시 누락의 지연 시간 영향을 줄일 수 있습니다.
**참고**
파일 캐싱은 Amazon CodeCatalyst [빌드](build-workflow-actions.md) 및 [테스트](test-workflow-actions.md) 작업과 **EC2** [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 사용하도록 구성된 경우에만 사용할 수 있습니다.
**Topics**
+ [파일 캐싱 정보](#workflows-caching.files)
+ [캐시 생성](#workflows-caching.fallback)
+ [파일 캐싱 제약 조건](#workflows-caching.constraints)
## 파일 캐싱 정보
파일 캐싱을 사용하면 데이터를 `FileCaching` 속성에서 각각 참조되는 여러 캐시로 구성할 수 있습니다. 각 캐시는 지정된 경로로 지정된 디렉터리를 저장합니다. 지정된 디렉터리는 향후 워크플로 실행 시 복원됩니다. 다음은 `cacheKey1` 및 `cacheKey2`라는 여러 캐시를 사용하여 캐싱하기 위한 YAML 조각의 예입니다.
```
Actions:
BuildMyNpmApp:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: npm install
- Run: npm run test
Caching:
FileCaching:
cacheKey1:
Path: file1.txt
RestoreKeys:
- restoreKey1
cacheKey2:
Path: /root/repository
RestoreKeys:
- restoreKey2
- restoreKey3
```
**참고**
CodeCatalyst는 로컬 캐시와 원격 캐시로 구성된 다층 캐싱을 사용합니다. 프로비저닝된 플릿 또는 온디맨드 시스템에서 로컬 캐시에서 캐시 누락이 발생하면 원격 캐시에서 종속성이 복원됩니다. 따라서 일부 작업 실행에서 원격 캐시 다운로드 지연이 발생할 수 있습니다.
CodeCatalyst는 캐시 액세스 제한을 적용하여 한 워크플로의 작업이 다른 워크플로의 캐시를 수정할 수 없도록 합니다. 이렇게 하면 빌드 또는 배포에 영향을 미치는 잘못된 데이터를 푸시할 수 있는 다른 워크플로로부터 각 워크플로를 보호할 수 있습니다. 제한은 모든 워크플로 및 브랜치 페어링에 캐시를 격리하는 캐시 범위에 적용됩니다. 예를 들어, 브랜치 `feature-A`의 `workflow-A`는 형제 브랜치 `feature-B`의 `workflow-A`와 다른 파일 캐시를 가지고 있습니다.
캐시 누락은 워크플로가 지정된 파일 캐시를 찾아 찾을 수 없을 때 발생합니다. 이는 새 브랜치가 생성되거나 새 캐시가 참조되고 아직 생성되지 않은 경우와 같이 여러 가지 이유로 발생할 수 있습니다. 캐시가 만료될 때도 발생할 수 있으며, 기본적으로 캐시는 마지막으로 사용된 후 14일 후에 발생합니다. 캐시 누락을 완화하고 캐시 적중률을 높이기 위해 CodeCatalyst는 대체 캐시를 지원합니다. 대체 캐시는 대체 캐시이며 캐시의 이전 버전일 수 있는 부분 캐시를 복원할 수 있는 기회를 제공합니다. 캐시는 먼저 `FileCaching`에서 속성 이름에 대한 일치 항목을 검색하여 복원되며, 찾을 수 없는 경우 `RestoreKeys`를 평가합니다. 속성 이름과 모든 `RestoreKeys` 모두에 캐시가 누락된 경우 캐싱은 최선의 노력이며 보장되지 않으므로 워크플로가 계속 실행됩니다.
## 캐시 생성
다음 지침에 따라 워크플로에 캐시를 추가할 수 있습니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 캐시 추가**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 캐시를 추가하려는 작업을 선택합니다.
1. **구성**을 선택합니다.
1. **파일 캐싱 - 선택 사항**에서 **캐시 추가**를 선택하고 다음과 같이 필드에 정보를 입력합니다.
**Key(키)**
기본 캐시 속성 이름의 이름을 지정합니다. 캐시 속성 이름은 워크플로 내에서 고유해야 합니다. 각 작업은 `FileCaching`에서 최대 5개의 항목을 가질 수 있습니다.
**경로**
캐시의 관련 경로를 지정합니다.
**키 복원 - 선택 사항**
기본 캐시 속성을 찾을 수 없을 때 대체로 사용할 복원 키를 지정합니다. 복원 키 이름은 워크플로 내에서 고유해야 합니다. 각 캐시는 `RestoreKeys`에서 최대 5개의 항목을 가질 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 캐시 추가**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 워크플로 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Configuration:
Steps: ...
Caching:
FileCaching:
key-name:
Path: file-path
# # Specify any additional fallback caches
# RestoreKeys:
# - restore-key
```
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
## 파일 캐싱 제약 조건
다음은 속성 이름 및 `RestoreKeys`에 대한 제약 조건입니다.
+ 이름은 워크플로 내에서 고유해야 합니다.
+ 이름은 영숫자 문자(A\$1Z, a\$1z, 0\$19), 하이픈(-) 및 밑줄(\$1)로 제한됩니다.
+ 이름은 최대 180자까지 가능합니다.
+ 각 작업에는 `FileCaching`에서 최대 5개의 캐시가 있을 수 있습니다.
+ 각 캐시는 `RestoreKeys`에서 최대 5개의 항목을 가질 수 있습니다.
다음은 경로에 대한 제약 조건입니다.
+ 별표(\$1)는 허용되지 않습니다.
+ 이름은 최대 255자까지 가능합니다.
# 워크플로 실행 상태 및 세부 정보 보기
Amazon CodeCatalyst에서 단일 워크플로 실행 또는 여러 실행의 상태 및 세부 정보를 동시에 볼 수 있습니다.
가능한 실행 상태 목록은 [워크플로 실행 상태](workflows-view-run-status.md) 섹션을 참조하세요.
**참고**
워크플로 *실행* 상태와 다른 워크플로 상태를 볼 수도 있습니다. 자세한 내용은 [워크플로의 상태 보기](workflows-view-status.md) 섹션을 참조하세요.
워크플로 실행에 대한 자세한 내용은 [워크플로 실행](workflows-working-runs.md) 섹션을 참조하세요.
**Topics**
+ [단일 실행의 상태 및 세부 정보 보기](#workflows-view-run-single)
+ [프로젝트의 모든 실행 상태 및 세부 정보 보기](#workflows-view-run-all)
+ [특정 워크플로의 모든 실행 상태 및 세부 정보 보기](#workflows-view-run-wf)
+ [워크플로 다이어그램에서 워크플로 실행 보기](#workflows-view-run-wf-diagram)
## 단일 실행의 상태 및 세부 정보 보기
단일 워크플로 실행의 상태 및 세부 정보를 보고 성공 여부를 확인하거나, 완료된 시간을 확인하거나, 누가 또는 무엇을 시작했는지 확인할 수 있습니다.
**단일 실행의 상태 및 세부 정보 보기**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 워크플로 이름에서 **실행**을 선택합니다.
1. **실행 기록**의 **실행 ID** 열에서 실행을 선택합니다. 예를 들어 `Run-95a4d`입니다.
1. 실행 이름에서 다음 중 하나를 수행합니다.
+ **워크플로** 실행의 작업과 상태를 보여주는 워크플로 다이어그램을 시각적으로 볼 수 있습니다([워크플로 실행 상태](workflows-view-run-status.md) 참조). 이 보기에는 실행 중에 사용되는 소스 리포지토리와 브랜치도 표시됩니다.
워크플로 다이어그램에서 작업을 선택하여 실행 중에 작업에 의해 생성된 로그, 보고서 및 출력과 같은 세부 정보를 확인합니다. 표시되는 정보는 선택한 작업 유형에 따라 달라집니다. 빌드 또는 배포 로그 보기에 대한 자세한 내용은 [빌드 작업 결과 보기](build-view-results.md) 또는 [배포 로그 보기](deploy-deployment-logs.md) 섹션을 참조하세요.
+ **YAML**을 사용하여 실행에 사용된 워크플로 정의 파일을 확인합니다.
+ 워크플로 실행에서 생성된 **아티팩트**를 볼 수 있는 아티팩트입니다. 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
+ 워크플로 실행에서 생성된 테스트 보고서 및 기타 유형의 **보고서**를 볼 수 있는 보고서입니다. 보고서에 대한 자세한 내용은 [품질 보고서 유형](test-workflow-actions.md#test-reporting)의 내용을 참조하세요.
+ 워크플로 실행에서 생성된 출력 변수를 볼 수 있는 **변수**입니다. 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
**참고**
실행의 상위 워크플로가 삭제된 경우 이 사실을 나타내는 메시지가 실행 세부 정보 페이지 상단에 나타납니다.
## 프로젝트의 모든 실행 상태 및 세부 정보 보기
프로젝트 내 모든 워크플로 실행의 상태와 세부 정보를 확인하여 프로젝트에서 진행 중인 워크플로 활동의 양을 파악하고 워크플로의 전반적인 건강 상태를 알아보고 싶을 수 있습니다.
**프로젝트의 모든 실행 상태 및 세부 정보 보기**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로**에서 **실행**을 선택합니다.
프로젝트의 모든 리포지토리에 걸쳐 모든 브랜치의 모든 워크플로에 대한 모든 실행이 표시됩니다.
페이지에 다음 열이 포함됩니다.
+ **실행 ID** - 실행의 고유 식별자입니다. 실행 ID 링크를 선택하여 실행에 대한 자세한 정보를 확인합니다.
+ **상태** - 워크플로 실행의 처리 상태입니다. 실행 상태에 대한 자세한 내용은 [워크플로 실행 상태](workflows-view-run-status.md) 섹션을 참조하세요.
+ **트리거** - 워크플로 실행을 시작한 사람, 커밋, 풀 요청(PR) 또는 일정입니다. 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 섹션을 참조하세요.
+ **워크플로** - 실행이 시작된 워크플로의 이름과 워크플로 정의 파일이 있는 소스 리포지토리 및 브랜치입니다. 이 정보를 보려면 열 너비를 확장해야 할 수 있습니다.
**참고**
이 열이 **사용 불가**로 설정된 경우 일반적으로 연결된 워크플로가 삭제되거나 이동되었기 때문입니다.
+ **시작 시간** - 워크플로 실행이 시작된 시간입니다.
+ **기간** - 워크플로 실행이 처리되는 데 걸린 시간입니다. 매우 길거나 매우 짧은 지속 시간은 문제를 나타낼 수 있습니다.
+ **종료 시간** - 워크플로 실행이 종료된 시간입니다.
## 특정 워크플로의 모든 실행 상태 및 세부 정보 보기
특정 워크플로와 연결된 모든 실행의 상태 및 세부 정보를 확인하여 워크플로 내에서 병목 현상이 발생하는 실행이 있는지 확인하거나 현재 진행 중이거나 완료된 실행을 확인할 수 있습니다.
**특정 워크플로의 모든 실행 상태 및 세부 정보 보기**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 워크플로 이름에서 **실행**을 선택합니다.
선택한 워크플로와 연결된 실행이 나타납니다.
이 페이지는 두 섹션으로 나뉘어 있습니다.
+ **활성 실행** - 진행 중인 실행을 표시합니다. 이러한 실행은 **진행 중** 상태 중 하나입니다.
+ **실행 기록** - 완료된 실행(즉, 진행 중이 아님)을 표시합니다.
실행 상태에 대한 자세한 내용은 [워크플로 실행 상태](workflows-view-run-status.md) 섹션을 참조하세요.
## 워크플로 다이어그램에서 워크플로 실행 보기
워크플로를 통해 함께 진행됨에 따라 워크플로의 모든 실행 상태를 볼 수 있습니다. 실행은 워크플로 다이어그램 내에 표시됩니다(목록 보기에는 표시되지 않음). 이를 통해 어떤 실행이 어떤 작업으로 처리되고 어떤 실행이 대기열에서 대기 중인지 시각적으로 표현할 수 있습니다.
**워크플로를 통해 함께 진행하면서 여러 실행의 상태 보기**
**참고**
이 절차는 워크플로가 대기 중, 대체된 실행 모드를 사용하는 경우에만 적용됩니다. 자세한 내용은 [실행의 대기열 동작 구성](workflows-configure-runs.md) 섹션을 참조하세요.
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
**참고**
실행 페이지가 아닌 워크플로 페이지를 보고 있는지 확인합니다.
1. 왼쪽 상단의 **최신 상태** 탭을 선택합니다.
워크플로 다이어그램이 나타납니다.
1. 워크플로 다이어그램을 검토합니다. 다이어그램은 워크플로 내에서 현재 진행 중인 모든 실행과 완료된 최신 실행을 보여줍니다. 보다 구체적으로는 다음과 같습니다.
+ **소스** 앞에 맨 위에 나타나는 실행은 대기열에 있고 시작을 기다립니다.
+ 작업 사이에 나타나는 실행은 대기 중 상태이며 다음 작업에서 처리되기를 기다립니다.
+ 작업 내에 나타나는 실행은 1. 현재 작업에서 처리 중, 2. 작업에서 처리 완료 또는 3. 작업에서 처리되지 않았습니다(일반적으로 이전 작업이 실패했기 때문).
# 워크플로 작업 구성
*작업*은 워크플로의 기본 구성 요소이며 워크플로 실행 중에 수행할 논리적 작업 단위 또는 태스크를 정의합니다. 일반적으로 워크플로에는 구성 방식에 따라 순차적으로 또는 병렬로 실행되는 여러 작업이 포함됩니다.
**Topics**
+ [작업 유형](#workflows-actions-types)
+ [워크플로에 작업 추가](workflows-add-action.md)
+ [워크플로에서 작업 제거](workflows-delete-action.md)
+ [사용자 지정 작업 개발](workflows-custom-action.md)
+ [작업을 작업 그룹으로 그룹화](workflows-group-actions.md)
+ [작업 순서 지정](workflows-depends-on.md)
+ [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md)
+ [사용할 작업 버전 지정](workflows-action-versions.md)
+ [사용 가능한 작업 버전 나열](workflows-action-versions-determine.md)
+ [작업의 소스 코드 보기](workflows-view-source.md)
+ [GitHub Actions와 통합](integrations-github-actions.md)
## 작업 유형
Amazon CodeCatalyst 워크플로 내에서 다음 유형의 작업을 사용할 수 있습니다.
**Topics**
+ [CodeCatalyst 작업](#workflows-actions-types-cc)
+ [CodeCatalyst Labs 작업](#workflows-actions-types-cc-labs)
+ [GitHub Actions](#workflows-actions-types-github)
+ [타사 작업](#workflows-actions-types-3p)
### CodeCatalyst 작업
*CodeCatalyst 작업*은 CodeCatalyst 개발 팀이 작성, 유지 및 완벽하게 지원하는 작업입니다.
애플리케이션 구축, 테스트 및 배포는 물론 AWS Lambda 함수 호출과 같은 기타 작업을 수행하기 위한 CodeCatalyst 작업이 있습니다.
다음 CodeCatalyst 작업을 사용할 수 있습니다.
+ **빌드**
이 작업은 아티팩트를 빌드하고 Docker 컨테이너에서 단위 테스트를 실행합니다. 자세한 내용은 [빌드 작업 추가](build-add-action.md) 섹션을 참조하세요.
+ **테스트**
이 작업은 애플리케이션 또는 아티팩트에 대해 통합 및 시스템 테스트를 실행합니다. 자세한 내용은 [테스트 작업 추가](test-add-action.md) 섹션을 참조하세요.
+ **Amazon S3 게시**
이 작업은 애플리케이션 아티팩트를 Amazon S3 버킷에 복사합니다. 자세한 내용은 [워크플로를 사용하여 Amazon S3에 파일 게시](s3-pub-action.md) 단원을 참조하십시오.
+ **AWS CDK 부트스트랩**
이 작업은가 CDK 앱을 배포하는 데 AWS CDK 필요한 리소스를 프로비저닝합니다. 자세한 내용은 [워크플로를 사용하여 AWS CDK 앱 부트스트래핑](cdk-boot-action.md) 단원을 참조하십시오.
+ **AWS CDK 배포**
이 작업은 AWS Cloud Development Kit (AWS CDK) 앱을 합성하고 배포합니다. 자세한 내용은 [워크플로를 사용하여 AWS CDK 앱 배포](cdk-dep-action.md) 단원을 참조하십시오.
+ **AWS Lambda 간접 호출**
이 작업은 AWS Lambda 함수를 호출합니다. 자세한 내용은 [워크플로를 사용하여 Lambda 함수 호출](lam-invoke-action.md) 단원을 참조하십시오.
+ **GitHub Actions**
이 작업은 *CodeCatalyst* 워크플로 내에서 GitHub Actions를 실행할 수 있는 CodeCatalyst 작업입니다. 자세한 내용은 [워크플로를 사용하여 Lambda 함수 호출](lam-invoke-action.md) 단원을 참조하십시오.
+ ** CloudFormation 스택 배포**
이 작업은 CloudFormation 스택을 배포합니다. 자세한 내용은 [CloudFormation 스택 배포](deploy-action-cfn.md) 단원을 참조하십시오.
+ **Amazon EKS에 배포**
이 작업은 Amazon ECS 작업 정의를 등록하고 Amazon ECS 서비스에 배포합니다. 자세한 내용은 [워크플로를 사용하여 Amazon ECS에 배포](deploy-action-ecs.md) 섹션을 참조하세요.
+ **Kubernetes 클러스터에 배포**
이 작업은 애플리케이션을 Kubernetes 클러스터에 배포합니다. 자세한 내용은 [워크플로를 사용하여 Amazon EKS에 배포](deploy-action-eks.md) 섹션을 참조하세요.
+ **Amazon ECS 태스크 정의 렌더링**
이 작업은 컨테이너 이미지 URI를 Amazon ECS 작업 정의 JSON 파일에 삽입하여 새 태스크 정의 파일을 생성합니다. 자세한 내용은 [Amazon ECS 작업 정의 수정](render-ecs-action.md) 섹션을 참조하세요.
CodeCatalyst 작업에 대한 설명서는 이 안내서와 각 작업의 읽어보기에서 확인할 수 있습니다.
사용 가능한 CodeCatalyst 작업과 워크플로에 추가하는 방법에 대한 자세한 내용은 [워크플로에 작업 추가](workflows-add-action.md) 섹션을 참조하세요.
### CodeCatalyst Labs 작업
*CodeCatalyst Labs 작업*은 실험 애플리케이션의 입증 근거인 Amazon CodeCatalyst Labs의 일부인 작업입니다. CodeCatalyst Labs 작업은 AWS 서비스와의 통합을 보여주기 위해 개발되었습니다.
다음 CodeCatalyst Labs 작업을 사용할 수 있습니다.
+ ** AWS Amplify 호스팅에 배포**
이 작업은 Amplify Hosting에 애플리케이션을 배포합니다.
+ **에 배포 AWS App Runner**
이 작업은 소스 이미지 리포지토리의 최신 이미지를 App Runner에 배포합니다.
+ **Amazon CloudFront 및 Amazon S3에 배포**
이 작업은 애플리케이션을 CloudFront 및 Amazon S3에 배포합니다.
+ **를 사용하여 배포 AWS SAM**
이 작업은 AWS Serverless Application Model (AWS SAM)를 사용하여 서버리스 애플리케이션을 배포합니다.
+ **Amazon CloudFront 캐시 무효화**
이 작업은 지정된 경로 집합에 대한 CloudFront 캐시를 무효화합니다.
+ **발신 웹후크**
이 작업을 통해 사용자는 HTTPS 요청을 사용하여 워크플로 내의 메시지를 임의의 웹 서버로 보낼 수 있습니다.
+ **에 게시 AWS CodeArtifact**
이 작업은 패키지를 CodeArtifact 리포지토리에 게시합니다.
+ **Amazon SNS에 게시**
이 작업을 통해 사용자는 주제를 생성하거나, 주제에 게시하거나, 주제를 구독하여 Amazon SNS와 통합할 수 있습니다.
+ **Amazon ECR에 게시**
이 작업은 Docker 이미지를 빌드하고 Amazon Elastic Container Registry(Amazon ECR) 리포지토리에 게시합니다.
+ **Amazon CodeGuru Security로 스캔**
이 작업은 구성된 코드 경로의 zip 아카이브를 생성하고 CodeGuru Security를 사용하여 코드 스캔을 실행합니다.
+ **Terraform Community Edition**
이 작업은 Terraform Community Edition `plan` 및 `apply` 작업을 실행합니다.
CodeCatalyst Labs 작업에 대한 설명서는 각 작업의 읽어보기에서 사용할 수 있습니다.
워크플로에 CodeCatalyst Labs 작업을 추가하고 해당 읽어보기를 보는 방법에 대한 자세한 내용은 [워크플로에 작업 추가](workflows-add-action.md) 섹션을 참조하세요.
### GitHub Actions
*GitHub 작업*은 GitHub 워크플로와 함께 사용하도록 개발되었다는 점을 제외하면 [CodeCatalyst 작업](#workflows-actions-types-cc)과 매우 유사합니다. GitHub Actions에 대한 자세한 내용은 [GitHub Actions](https://docs.github.com/en/actions) 설명서를 참조하세요.
CodeCatalyst 워크플로에서 기본 CodeCatalyst 작업과 함께 GitHub Actions를 사용할 수 있습니다.
편의를 위해 CodeCatalyst 콘솔은 인기 있는 여러 GitHub Actions에 대한 액세스를 제공합니다. [GitHub Marketplace](https://github.com/marketplace/actions)에 나열된 모든 GitHub 작업을 사용할 수도 있습니다(몇 가지 제한 사항이 적용됨).
GitHub Actions에 대한 설명서는 각 작업의 readme에서 사용할 수 있습니다.
자세한 내용은 [GitHub Actions와 통합](integrations-github-actions.md) 섹션을 참조하세요.
### 타사 작업
*타사 작업*은 타사 공급업체에서 작성하고 CodeCatalyst 콘솔에서 사용할 수 있는 작업입니다. 타사 작업의 예로는 각각 Mend 및 Sonar에서 작성한 **Mend SCA** 및 **SonarCloud Scan** 작업이 있습니다.
타사 작업에 대한 설명서는 각 작업의 readme에서 확인할 수 있습니다. 타사 공급업체에서 추가 문서를 제공할 수도 있습니다.
워크플로에 타사 작업을 추가하고 해당 읽어보기를 보는 방법에 대한 자세한 내용은 [워크플로에 작업 추가](workflows-add-action.md) 섹션을 참조하세요.
# 워크플로에 작업 추가
다음 지침에 따라 워크플로에 작업을 추가한 다음 구성합니다.
**작업 추가 및 구성**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. 왼쪽 상단에 **\$1 작업**을 선택하면 **작업** 카탈로그가 나타납니다.
1. 드롭다운 목록에서 다음 중 하나를 선택합니다.
+ **Amazon CodeCatalyst**를 선택하여 [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), [CodeCatalyst Labs ](workflows-actions.md#workflows-actions-types-cc-labs)또는 [타사](workflows-actions.md#workflows-actions-types-3p) 작업을 봅니다.
+ CodeCatalyst 작업에는 ** AWS레이블**이 있습니다.
+ CodeCatalyst Labs 작업에는 **by CodeCatalyst Labs** 레이블이 있습니다.
+ 타사 작업에는 **by *vendor*** 레이블이 있으며, 여기서 *vendor*는 타사 공급업체의 이름입니다.
+ **GitHub**를 선택하여 [큐레이션된 GitHub Actions 목록](integrations-github-action-add-curated.md)을 봅니다.
1. 작업 카탈로그에서 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로에 작업을 추가합니다.
+ 작업의 이름을 선택하여 읽어보기를 봅니다.
1. 작업을 구성합니다. 시각적 편집기를 사용하려면 **비주얼**을 선택하고, YAML 편집기를 사용하려면 **YAML**을 선택합니다. 자세한 지침은 다음 링크를 참조하세요.
[CodeCatalyst 작업](workflows-actions.md#workflows-actions-types-cc) 추가에 대한 지침은 다음을 참조하세요.
+ [빌드 작업 추가](build-add-action.md)
+ [테스트 작업 추가](test-add-action.md)
+ ['Amazon ECS에 배포' 작업 추가](deploy-action-ecs-adding.md)
+ ['Kubernetes 클러스터에 배포' 작업 추가](deploy-action-eks-adding.md)
+ ['스 CloudFormation 택 배포' 작업 추가](deploy-action-cfn-adding.md)
+ ['AWS CDK 배포' 작업 추가](cdk-dep-action-add.md)
+ ['AWS CDK bootstrap' 작업 추가](cdk-boot-action-add.md)
+ ['Amazon S3 게시' 작업 추가](s3-pub-action-add.md)
+ ['AWS Lambda 호출' 작업 추가](lam-invoke-action-add.md)
+ ['Amazon ECS 작업 정의 렌더링' 작업 추가](render-ecs-action-add.md)
[CodeCatalyst Labs 작업](workflows-actions.md#workflows-actions-types-cc-labs) 추가에 대한 지침은 다음을 참조하세요.
+ 작업의 readme입니다. 작업 카탈로그에서 작업의 이름을 선택하면 조사 결과를 확인할 수 있습니다.
[GitHub Actions](workflows-actions.md#workflows-actions-types-github) 추가에 대한 지침은 다음을 참조하세요.
+ [GitHub Actions와 통합](integrations-github-actions.md)
[타사 작업](workflows-actions.md#workflows-actions-types-3p) 추가에 대한 지침은 다음을 참조하세요.
+ 작업의 readme입니다. 작업 카탈로그에서 작업의 이름을 선택하면 조사 결과를 확인할 수 있습니다.
1. (선택 사항) YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택하여 변경 사항을 커밋합니다.
# 워크플로에서 작업 제거
다음 지침에 따라 워크플로에서 작업을 제거합니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 작업 제거**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 제거하려는 작업에서 세로 줄임표 아이콘(![\[Ellipsis.\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/images/flows/elipsis.png))을 선택하고 **제거**를 선택합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 작업 제거**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 제거하려는 작업이 포함된 YAML 섹션을 조사합니다.
섹션을 선택하고 키보드에서 delete 키를 누릅니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 사용자 지정 작업 개발
CodeCatalyst 작업 개발 키트(ADK)를 사용하여 워크플로에서 사용할 사용자 지정 작업을 개발할 수 있습니다. 그런 다음 해당 작업을 CodeCatalyst 작업 카탈로그에 게시하여 다른 CodeCatalyst 사용자가 워크플로에서 보고 사용할 수 있도록 할 수 있습니다.
**작업 개발, 테스트 및 게시(고급 태스크)**
1. 작업 개발에 필요한 도구와 패키지를 설치합니다.
1. 작업 코드를 저장할 CodeCatalyst 리포지토리를 만듭니다.
1. 작업을 초기화합니다. 이렇게 하면 자체 코드로 업데이트할 수 있는 작업 정의 파일(`action.yml`)을 포함하여 작업에 필요한 소스 파일이 정리됩니다.
1. 작업 코드를 부트스트랩하여 작업 프로젝트를 빌드, 테스트 및 릴리스하는 데 필요한 도구와 라이브러리를 가져옵니다.
1. 로컬 컴퓨터에서 작업을 빌드하고 변경 사항을 CodeCatalyst 리포지토리로 푸시합니다.
1. 로컬에서 단위 테스트를 통해 작업을 테스트하고, ADK에서 생성된 워크플로를 CodeCatalyst에서 실행합니다.
1. CodeCatalyst 콘솔에서 게시 버튼을 선택하여 CodeCatalyst 작업 카탈로그에 작업을 **게시**합니다.
자세한 단계는 [Amazon CodeCatalyst 작업 개발 키트 개발자 안내서](https://docs.aws.amazon.com/codecatalyst/latest/adk/what-is-action-development-kit.html)를 참조하세요.
# 작업을 작업 그룹으로 그룹화
*작업 그룹*에는 하나 이상의 작업이 포함됩니다. 작업을 작업 그룹으로 그룹화하면 워크플로를 체계적으로 관리할 수 있고, 서로 다른 그룹 간의 종속성을 구성할 수도 있습니다.
**참고**
다른 작업 그룹이나 작업 내에 작업 그룹을 중첩할 수 없습니다.
**Topics**
+ [작업 그룹 정의](#workflows-define-action-group)
+ [예시: 두 작업 그룹 정의](workflows-group-actions-example.md)
## 작업 그룹 정의
다음 지침에 따라 CodeCatalyst 작업 그룹을 정의합니다.
------
#### [ Visual ]
*사용할 수 없습니다. YAML을 선택하여 YAML 지침을 봅니다.*
------
#### [ YAML ]
**그룹 정의**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. `Actions`에서 다음과 유사한 코드를 추가합니다.
```
Actions:
action-group-name:
Actions:
action-1:
Identifier: aws/build@v1
Configuration:
...
action-2:
Identifier: aws/build@v1
Configuration:
...
```
다른 예시는 [예시: 두 작업 그룹 정의](workflows-group-actions-example.md)를 참조하세요. 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 [작업](workflow-reference.md#actions-reference)에서 `action-group-name` 속성에 관한 설명을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 예시: 두 작업 그룹 정의
다음 예시에서는 두 개의 Amazon CodeCatalyst 작업 그룹인 `BuildAndTest` 및 `Deploy`를 정의하는 방법을 보여줍니다. `BuildAndTest` 그룹에는 두 개의 작업(`Build` 및 `Test`)이 포함되며 `Deploy` 그룹에는 두 개의 작업(`DeployCloudFormationStack` 및 `DeployToECS`)도 포함됩니다.
```
Actions:
BuildAndTest: # Action group 1
Actions:
Build:
Identifier: aws/build@v1
Configuration:
...
Test:
Identifier: aws/managed-test@v1
Configuration:
Deploy: #Action group 2
Actions:
DeployCloudFormationStack:
Identifier: aws/cfn-deploy@v1
Configuration:
...
DeployToECS:
Identifier: aws/ecs-deploy@v1
Configuration:
...
```
# 작업 순서 지정
기본적으로 워크플로에 작업을 추가하면 [시각적 편집기](workflow.md#workflow.editors)에서 나란히 추가됩니다. 즉, 워크플로 실행을 시작할 때 작업이 병렬로 실행됩니다. 작업이 순차적으로 실행되고 시각적 편집기에서 세로로 표시되도록 하려면 작업 간에 종속성을 설정해야 합니다. 예를 들어, 테스트 작업이 빌드 작업 이후에 실행되도록 `Test`A 작업이 `Build` 작업에 종속되도록 설정할 수 있습니다.
작업과 작업 그룹 간에 종속성을 설정할 수 있습니다. 하나의 작업이 시작하기 위해 다른 여러 작업에 종속되도록 일대다 종속성을 구성할 수도 있습니다. [작업 간 종속성 설정](workflows-depends-on-set-up.md)의 가이드라인을 참조하여 종속성 설정이 워크플로의 YAML 구문을 준수하는지 확인하세요.
**Topics**
+ [작업 간의 종속성을 구성하는 방법의 예시](workflows-depends-on-examples.md)
+ [작업 간 종속성 설정](workflows-depends-on-set-up.md)
# 작업 간의 종속성을 구성하는 방법의 예시
다음 예시에서는 워크플로 정의 파일의 작업과 그룹 간에 종속성을 구성하는 방법을 보여줍니다.
**Topics**
+ [예시: 단순 종속성 구성](#workflows-depends-on-example-simple)
+ [예시: 작업에 종속되도록 작업 그룹 구성](#workflows-depends-on-example-action-groups-actions)
+ [예시: 다른 작업 그룹에 종속되도록 작업 그룹 구성](#workflows-depends-on-example-two-action-groups)
+ [예시: 여러 작업에 종속되도록 작업 그룹 구성](#workflows-depends-on-example-advanced)
## 예시: 단순 종속성 구성
다음 예시에서는 `DependsOn` 속성을 사용하여 `Build` 작업에 따라 `Test` 작업을 구성하는 방법을 보여줍니다.
```
Actions:
Build:
Identifier: aws/build@v1
Configuration:
...
Test:
DependsOn:
- Build
Identifier: aws/managed-test@v1
Configuration:
...
```
## 예시: 작업에 종속되도록 작업 그룹 구성
다음 예시에서는 `FirstAction` 작업에 따라 `DeployGroup` 작업 그룹을 구성하는 방법을 보여줍니다. 작업과 작업 그룹은 동일한 수준에 있습니다.
```
Actions:
FirstAction: #An action outside an action group
Identifier: aws/github-actions-runner@v1
Configuration:
...
DeployGroup: #An action group containing two actions
DependsOn:
- FirstAction
Actions:
DeployAction1:
...
DeployAction2:
...
```
## 예시: 다른 작업 그룹에 종속되도록 작업 그룹 구성
다음 예시에서는 `BuildAndTestGroup` 작업 그룹에 따라 `DeployGroup` 작업 그룹을 구성하는 방법을 보여줍니다. 작업 그룹은 동일한 수준에 있습니다.
```
Actions:
BuildAndTestGroup: # Action group 1
Actions:
BuildAction:
...
TestAction:
...
DeployGroup: #Action group 2
DependsOn:
- BuildAndTestGroup
Actions:
DeployAction1:
...
DeployAction2:
...
```
## 예시: 여러 작업에 종속되도록 작업 그룹 구성
다음 예시에서는 `FirstAction` 작업, `SecondAction` 작업 및 `BuildAndTestGroup` 작업 그룹에 따라 `DeployGroup` 작업 그룹을 구성하는 방법을 보여줍니다. `DeployGroup`은 `FirstAction`, `SecondAction` 및 `BuildAndTestGroup`과 동일한 수준에 있습니다.
```
Actions:
FirstAction: #An action outside an action group
...
SecondAction: #Another action
...
BuildAndTestGroup: #Action group 1
Actions:
Build:
...
Test:
...
DeployGroup: #Action group 2
DependsOn:
- FirstAction
- SecondAction
- BuildAndTestGroup
Actions:
DeployAction1:
...
DeployAction2:
...
```
# 작업 간 종속성 설정
다음 지침에 따라 워크플로의 작업 간 종속성을 설정합니다.
종속성을 구성할 때는 다음 지침을 따르세요.
+ 작업이 그룹 내에 있는 경우 해당 작업은 동일한 그룹 내의 다른 작업에만 의존할 수 있습니다.
+ 작업 및 작업 그룹은 YAML 계층 구조에서 *동일한 수준*의 다른 작업 및 작업 그룹에 의존할 수 있지만 다른 수준에서는 의존할 수 *없습니다*.
------
#### [ Visual ]
**시각적 편집기를 사용하여 종속성 설정**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 다른 작업에 종속될 작업을 선택합니다.
1. **입력** 탭을 선택합니다.
1. **종속 대상 - 선택 사항**에서 다음을 수행합니다.
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 종속성 설정**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 다른 항목에 종속되는 작업에서 다음과 유사한 코드를 추가합니다
```
action-name:
DependsOn:
- action-1
```
더 많은 예시는 [작업 간의 종속성을 구성하는 방법의 예시](workflows-depends-on-examples.md)를 참조합니다. 일반 지침은 [작업 간 종속성 설정](#workflows-depends-on-set-up) 섹션을 참조하세요. 자세한 내용은 작업에 대한 [워크플로 YAML 정의](workflow-reference.md)의 `DependsOn` 속성 설명을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 작업 간 아티팩트 및 파일 공유
*아티팩트*는 워크플로 작업의 출력이며 일반적으로 폴더 또는 파일 아카이브로 구성됩니다. 아티팩트를 사용하면 작업 간에 파일과 정보를 공유할 수 있기 때문에 아티팩트가 중요합니다.
예를 들어, `sam-template.yml` 파일을 *생성* 하는 빌드 작업이 있을 수 있지만 배포 작업에서 파일을 *사용*하려는 경우가 있습니다. 이 시나리오에서는 아티팩트를 사용하여 빌드 작업이 배포 작업과 `sam-template.yml` 파일을 공유하도록 허용합니다. 코드는 다음과 같을 것입니다.
```
Actions:
BuildAction:
Identifier: aws/build@v1
Steps:
- Run: sam package --output-template-file sam-template.yml
Outputs:
Artifacts:
- Name: MYARTIFACT
Files:
- sam-template.yml
DeployAction:
Identifier: aws/cfn-deploy@v1
Inputs:
Artifacts:
- MYARTIFACT
Configuration:
template: sam-template.yml
```
이전 코드에서 빌드 작업(`BuildAction`)은 `sam-template.yml` 파일을 생성한 다음 라는 출력 아티팩트 `MYARTIFACT`에 추가합니다. 후속 배포 작업(`DeployAction`)은 `MYARTIFACT`를 입력으로 지정하여 `sam-template.yml` 파일에 대한 액세스 권한을 부여합니다.
**Topics**
+ [아티팩트를 출력 및 입력으로 지정하지 않고 공유할 수 있나요?](#workflows-working-artifacts-share)
+ [워크플로 간에 아티팩트를 공유할 수 있나요?](#workflows-working-artifacts-share-wf)
+ [아티팩트 예시](workflows-working-artifacts-ex.md)
+ [출력 아티팩트 정의](workflows-working-artifacts-output.md)
+ [입력 아티팩트 정의](workflows-working-artifacts-refer.md)
+ [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md)
+ [아티팩트 다운로드](workflows-download-workflow-outputs.md)
## 아티팩트를 출력 및 입력으로 지정하지 않고 공유할 수 있나요?
예, 작업의 YAML 코드의 `Outputs` 및 `Inputs` 섹션에서 아티팩트를 지정하지 않고 작업 간에 아티팩트를 공유할 수 있습니다. 이렇게 하려면 컴퓨팅 공유를 켜야 합니다. 컴퓨팅 공유 및 아티팩트가 켜져 있을 때 아티팩트를 지정하는 방법에 대한 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
**참고**
컴퓨팅 공유 기능을 사용하면 `Outputs` 및 `Inputs` 섹션이 필요 없어 워크플로의 YAML 코드를 간소화할 수 있지만, 이 기능을 켜기 전에 알아두어야 할 제한 사항이 있습니다. 이러한 제한에 대한 자세한 내용은 [컴퓨팅 공유 고려 사항](compute-sharing.md#compare-compute-sharing) 섹션을 참조하세요.
## 워크플로 간에 아티팩트를 공유할 수 있나요?
아니요. 서로 다른 워크플로 간에 아티팩트를 공유할 수 없지만 동일한 워크플로 내의 작업 간에 아티팩트를 공유할 수 있습니다.
# 아티팩트 예시
다음 예시에서는 Amazon CodeCatalyst 워크플로 정의 파일에서 아티팩트를 출력, 입력 및 참조하는 방법을 보여줍니다.
**Topics**
+ [예시: 아티팩트 출력](#workflows-working-artifacts-ex-basic)
+ [예시: 다른 작업에서 생성된 아티팩트 입력](#workflows-working-artifacts-ex-ref)
+ [예시: 여러 아티팩트에서 파일 참조](#workflows-working-artifacts-ex-ref-file)
+ [예시: 단일 아티팩트에서 파일 참조](#workflows-working-artifacts-ex-ref-file-one)
+ [예시: WorkflowSource가 있을 때 아티팩트의 파일 참조](#workflows-working-artifacts-ex-ref-file-wf-source)
+ [예시: 작업 그룹이 있을 때 아티팩트의 파일 참조](#workflows-working-artifacts-ex-groups)
## 예시: 아티팩트 출력
다음 예시에서는 두 개의 .jar 파일이 포함된 아티팩트를 출력하는 방법을 보여줍니다.
```
Actions:
Build:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ARTIFACT1
Files:
- build-output/file1.jar
- build-output/file2.jar
```
## 예시: 다른 작업에서 생성된 아티팩트 입력
다음 예시에서는 `BuildActionA`의 `ARTIFACT4` 아티팩트를 출력하고 `BuildActionB`에 입력하는 방법을 보여줍니다.
```
Actions:
BuildActionA:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ARTIFACT4
Files:
- build-output/file1.jar
- build-output/file2.jar
BuildActionB:
Identifier: aws/build@v1
Inputs:
Artifacts:
- ARTIFACT4
Configuration:
```
## 예시: 여러 아티팩트에서 파일 참조
다음 예시에서는 `BuildActionC`의 `ART5` 및 `ART6`라는 두 개의 아티팩트를 출력한 다음 `BuildActionD`(`Steps` 아래)의 `file5.txt`(`ART5` 아티팩트) 및 `file6.txt`(`ART6` 아티팩트)라는 두 개의 파일을 참조하는 방법을 보여줍니다.
**참고**
파일 참조에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
**참고**
예시는 사용 중인 `$CATALYST_SOURCE_DIR_ART5` 접두사를 보여주지만 이를 생략할 수 있습니다. 이는 `ART5`가 *기본 입력*이기 때문입니다. 기본 입력에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
```
Actions:
BuildActionC:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART5
Files:
- build-output/file5.txt
- Name: ART6
Files:
- build-output/file6.txt
BuildActionD:
Identifier: aws/build@v1
Inputs:
Artifacts:
- ART5
- ART6
Configuration:
Steps:
- run: cd $CATALYST_SOURCE_DIR_ART5/build-output && cat file5.txt
- run: cd $CATALYST_SOURCE_DIR_ART6/build-output && cat file6.txt
```
## 예시: 단일 아티팩트에서 파일 참조
다음 예시에서는 `BuildActionE`의 `ART7` 아티팩트를 출력한 다음 `BuildActionF`(`Steps` 아래)의 `file7.txt`(`ART7` 아티팩트) 파일을 참조하는 방법을 보여줍니다.
[예시: 여러 아티팩트에서 파일 참조](#workflows-working-artifacts-ex-ref-file)에서와 같이 참조에 `build-output` 디렉터리 앞에 `$CATALYST_SOURCE_DIR_`*artifact-name* 접두사가 필요하지 않은 것을 확인할 수 있습니다. 이는 `Inputs`에 지정된 항목이 하나뿐이기 때문입니다.
**참고**
파일 참조에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
```
Actions:
BuildActionE:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART7
Files:
- build-output/file7.txt
BuildActionF:
Identifier: aws/build@v1
Inputs:
Artifacts:
- ART7
Configuration:
Steps:
- run: cd build-output && cat file7.txt
```
## 예시: WorkflowSource가 있을 때 아티팩트의 파일 참조
다음 예시에서는 `BuildActionG`의 `ART8` 아티팩트를 출력한 다음 `BuildActionH`(`Steps` 아래)의 `file8.txt`(`ART8` 아티팩트) 파일을 참조하는 방법을 보여줍니다.
참조에 `$CATALYST_SOURCE_DIR_`*artifact-name* 접두사가 [예시: 여러 아티팩트에서 파일 참조](#workflows-working-artifacts-ex-ref-file)에서와 같이 어떻게 필요한지 확인합니다. 이는 `Inputs`(소스 및 아티팩트)에 여러 항목이 지정되어 있기 때문에 파일을 찾을 위치를 나타내는 접두사가 필요합니다.
**참고**
파일 참조에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
```
Actions:
BuildActionG:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART8
Files:
- build-output/file8.txt
BuildActionH:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Artifacts:
- ART8
Configuration:
Steps:
- run: cd $CATALYST_SOURCE_DIR_ART8/build-output && cat file8.txt
```
## 예시: 작업 그룹이 있을 때 아티팩트의 파일 참조
다음 예시에서는 `ActionGroup1`, `ActionI`의 `ART9` 아티팩트를 출력한 다음 `ActionJ`의 `file9.txt`(`ART9` 아티팩트) 파일을 참조하는 방법을 보여줍니다.
파일 참조에 대한 자세한 내용은 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
```
Actions:
ActionGroup1:
Actions:
ActionI:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART9
Files:
- build-output/file9.yml
ActionJ:
Identifier: aws/cfn-deploy@v1
Inputs:
Sources:
- WorkflowSource
Artifacts:
- ART9
Configuration:
template: /artifacts/ActionGroup1@ActionJ/ART9/build-output/file9.yml
```
# 출력 아티팩트 정의
다음 지침에 따라 Amazon CodeCatalyst 작업이 출력할 아티팩트를 정의합니다. 그러면 이 아티팩트를 다른 작업에서 사용할 수 있게 됩니다.
**참고**
모든 작업이 출력 아티팩트를 지원하는 것은 아닙니다. 작업이 이를 지원하는지 확인하려면 다음에 나오는 시각적 편집기 지침을 실행하고 **출력** 탭에서 작업에 **출력 아티팩트** 버튼이 포함되어 있는지 확인합니다. 포함되어 있다면 출력 아티팩트가 지원됩니다.
------
#### [ Visual ]
**시각적 편집기를 사용하여 출력 아티팩트 정의**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 아티팩트를 생성할 작업을 선택합니다.
1. **출력** 탭을 선택합니다.
1. **아티팩트**에서 **아티팩트 추가**를 선택합니다.
1. **아티팩트 추가**를 선택하고 다음과 같이 필드에 정보를 입력합니다.
**빌드 아티팩트 이름**
작업에서 생성된 아티팩트의 이름을 지정합니다. 아티팩트 이름은 워크플로 내에서 고유해야 하며 영숫자 문자(a-z, A-Z, 0-9) 및 밑줄(\$1)로 제한됩니다. 공백, 하이픈(-) 및 특수 문자는 허용되지 않습니다. 출력 아티팩트 이름에서 공백, 하이픈 및 기타 특수 문자를 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**빌드로 생성한 파일**
CodeCatalyst가 작업으로 출력되는 아티팩트에 포함하는 파일을 지정합니다. 이러한 파일은 실행 시 워크플로 작업에 의해 생성되며 소스 리포지토리에서도 사용할 수 있습니다. 파일 경로는 소스 리포지토리 또는 이전 작업의 아티팩트에 상주할 수 있으며 소스 리포지토리 또는 아티팩트 루트와 관련이 있습니다. glob 패턴을 사용하여 경로를 지정할 수 있습니다. 예시:
+ 빌드 위치 또는 소스 리포지토리 위치의 루트에 있는 단일 파일을 지정하려면 `my-file.jar`를 사용합니다..
+ 하위 디렉터리에 단일 파일을 지정하려면 `directory/my-file.jar` 또는 `directory/subdirectory/my-file.jar`를 사용합니다.
+ 모든 파일을 지정하려면 `"**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리에 있는 모든 파일 및 디렉터리를 지정하려면 `"directory/**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리의 모든 파일을 지정하되 해당 하위 디렉터리는 지정하지 않으려면 `"directory/*"`를 사용합니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
파일 경로에 접두사를 추가하여 찾을 아티팩트 또는 소스를 나타내야 할 수 있습니다. 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 출력 아티팩트 정의**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 워크플로 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Outputs:
Artifacts:
- Name: artifact-name
Files:
- file-path-1
- file-path-2
```
더 많은 예시는 [아티팩트 예시](workflows-working-artifacts-ex.md)를 참조합니다. 자세한 내용은 작업에 해당하는 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 입력 아티팩트 정의
다른 Amazon CodeCatalyst 작업에서 생성된 아티팩트를 사용하려면 현재 작업의 입력으로 지정해야 합니다. 여러 아티팩트를 입력으로 지정할 수 있습니다. 이는 작업에 따라 다릅니다. 자세한 내용은 작업에 해당하는 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
**참고**
다른 워크플로의 아티팩트를 참조할 수 없습니다.
다음 지침에 따라 다른 작업의 아티팩트를 현재 작업에 대한 입력으로 지정합니다.
**사전 조건**
시작하기 전에 다른 작업에서 아티팩트가 출력되어 있는지 확인하세요. 자세한 내용은 [출력 아티팩트 정의](workflows-working-artifacts-output.md) 섹션을 참조하세요. 아티팩트를 출력하면 다른 작업에서 사용할 수 있습니다.
------
#### [ Visual ]
**아티팩트를 작업에 대한 입력으로 지정(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 아티팩트를 입력으로 지정하려는 작업을 선택합니다.
1. **입력**을 선택합니다.
1. **아티팩트 - 선택 사항**에서 다음을 수행합니다.
이 작업에 대한 입력으로 제공하려는 이전 작업의 아티팩트를 지정합니다. 이러한 아티팩트는 이전 작업에서 출력 아티팩트로 이미 정의되어 있어야 합니다.
입력 아티팩트를 지정하지 않으면 `action-name/Inputs/Sources` 아래에 소스 리포지토리를 하나 이상 지정해야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
**아티팩트 - 선택적** 드롭다운 목록을 사용할 수 없거나(시각적 편집기) YAML(YAML 편집기)을 검증할 때 오류가 발생하는 경우 작업이 하나의 입력만 지원하기 때문일 수 있습니다. 이 경우 소스 입력을 제거해 보세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**아티팩트를 작업에 대한 입력으로 지정(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 아티팩트를 입력으로 지정하려는 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Inputs:
Artifacts:
- artifact-name
```
더 많은 예시는 [아티팩트 예시](workflows-working-artifacts-ex.md)를 참조합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 아티팩트의 파일 참조
아티팩트 내에 파일이 있고 Amazon CodeCatalyst 워크플로 작업 중 하나에서 이 파일을 참조해야 하는 경우 다음 절차를 수행하세요.
**참고**
또한 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 섹션도 참조하세요.
------
#### [ Visual ]
*사용할 수 없습니다. YAML을 선택하여 YAML 지침을 봅니다.*
------
#### [ YAML ]
**아티팩트의 파일 참조(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 파일을 참조하려는 작업에서 다음과 유사한 코드를 추가합니다.
```
Actions:
My-action:
Inputs:
Sources:
- WorkflowSource
Artifacts:
- artifact-name
Configuration:
template: artifact-path/path/to/file.yml
```
이전 코드에서 다음을 바꿉니다.
+ *artifact-name*: 아티팩트 이름으로 바꿉니다.
+ *artifact-path*: 다음 테이블의 값으로 바꿉니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codecatalyst/latest/userguide/workflows-working-artifacts-refer-files.html)
예시는 [아티팩트 예시](workflows-working-artifacts-ex.md) 섹션을 참조하세요.
**참고**
다음과 같은 경우 *artifact-path*를 생략하고 아티팩트 루트 디렉터리를 기준으로 파일 경로를 지정할 수 있습니다.
참조를 포함하려는 작업이 `Inputs` 아래에 하나의 항목만 포함합니다(예: 입력 아티팩트 하나만 포함되고 소스는 포함되지 않음).
참조하려는 파일은 기본 입력에 있습니다. *기본 입력*은 `WorkflowSource`이거나 `WorkflowSource`가 없는 경우 나열된 첫 번째 입력 아티팩트입니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 아티팩트 다운로드
문제 해결을 위해 Amazon CodeCatalyst 워크플로 작업에서 생성된 아티팩트를 다운로드하여 검사할 수 있습니다. 다운로드할 수 있는 아티팩트에는 다음과 같이 두 가지 유형이 있습니다.
+ **소스 아티팩트** - 실행이 시작될 때 존재했던 소스 리포지토리 콘텐츠의 스냅샷이 포함된 아티팩트입니다.
+ **워크플로 아티팩트** - 워크플로 구성 파일의 `Outputs` 속성에 정의된 아티팩트입니다.
**워크플로에서 아티팩트 출력 다운로드**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 워크플로 이름에서 **실행**을 선택합니다.
1. **실행 기록**의 **실행 ID** 열에서 실행을 선택합니다. 예를 들어 `Run-95a4d`입니다.
1. 실행 이름에서 **아티팩트**를 선택합니다.
1. 아티팩트 옆에 있는 **다운로드**를 선택합니다. 아카이브 파일이 다운로드됩니다. 파일 이름은 7개의 무작위 문자로 구성됩니다.
1. 원하는 아카이브 추출 유틸리티를 사용하여 아카이브를 추출합니다.
# 사용할 작업 버전 지정
기본적으로 워크플로우에 작업을 추가하면 Amazon CodeCatalyst는 해당 형식을 사용하여 워크플로우 정의 파일에 정식 버전을 추가합니다.
`vmajor.minor.patch`
예제:
```
My-Build-Action:
Identifier: aws/build@v1.0.0
```
워크플로에서 항상 최신 마이너 또는 패치 버전의 작업을 사용하도록 `Identifier` 속성에서 정식 버전을 단축할 수 있습니다.
예를 들어, 다음을 지정해야 합니다.
```
My-CloudFormation-Action:
Identifier: aws/cfn-deploy@v1.0
```
...그리고 최신 패치 버전은 이며`1.0.4`, 그러면 작업은 `1.0.4` 버전을 사용합니다. 이후 버전 `1.0.5`가 릴리스되면 작업은 `1.0.5` 버전을 사용합니다. 마이너 버전 `1.1.0`이 릴리스되면 작업은 `1.0.5` 버전을 사용합니다.
버전 지정에 대한 자세한 지침은 다음 주제 중 하나를 참조하세요.
다음 지침에 따라 워크플로에서 사용할 작업 버전을 지정합니다. 최신 메이저 또는 마이너 버전 또는 특정 패치 버전을 지정할 수 있습니다.
작업의 최신 마이너 또는 패치 버전을 사용하는 것이 좋습니다.
------
#### [ Visual ]
*사용할 수 없습니다. YAML을 선택하여 YAML 지침을 봅니다.*
------
#### [ YAML ]
**작업의 최신 버전 또는 특정 패치 버전을 사용하도록 워크플로 구성**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 버전을 편집하려는 작업을 찾습니다.
1. 작업의 `Identifier` 속성을 찾아 버전을 다음 중 하나로 설정합니다.
+ action-identifier@v*major* - 이 구문을 사용하면 워크플로가 특정 메이저 버전을 사용하도록 하고 최신 마이너 및 패치 버전을 자동으로 선택할 수 있습니다.
+ action-identifier@v*major*.*minor* - 이 구문을 사용하면 워크플로가 특정 마이너 버전을 사용하도록 하고 최신 패치 버전을 자동으로 선택할 수 있습니다.
+ action-identifier@v*major*.*minor*.*patch* – 워크플로가 특정 패치 버전을 사용하도록 하려면 이 구문을 사용합니다.
**참고**
사용 가능한 버전이 확실하지 않은 경우 [사용 가능한 작업 버전 나열](workflows-action-versions-determine.md) 섹션을 참조하세요.
**참고**
메이저 버전은 생략할 수 없습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 사용 가능한 작업 버전 나열
다음 지침에 따라 워크플로에서 사용할 수 있는 작업의 버전을 확인하세요.
------
#### [ Visual ]
**사용 가능한 작업 버전 확인**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 확인하려는 버전의 작업을 찾습니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택하거나 새로 워크플로를 생성합니다. 워크플로 생성에 대한 자세한 내용은 [워크플로 생성](workflows-create-workflow.md) 섹션을 참조하세요.
1. **편집**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택하여 CodeCatalyst, CodeCatalyst Labs 및 타사 작업을 보거나 **GitHub**를 선택하여 선별된 GitHub Actions를 볼 수 있습니다.
1. 작업을 검색하고 해당 이름을 선택합니다. **\$1**(더하기 부호)를 선택합니다.
작업에 대한 세부 정보가 표시됩니다.
1. 작업 세부 정보 대화 상자의 오른쪽 상단에서 **버전** 드롭다운 목록을 선택하여 사용 가능한 작업의 버전 목록을 확인합니다.
------
#### [ YAML ]
*사용할 수 없습니다. 시각적 편집기 지침을 보려면 '비주얼'을 선택합니다.*
------
# 작업의 소스 코드 보기
작업의 소스 코드를 보고 위험한 코드, 보안 취약성 또는 기타 결함이 없는지 확인할 수 있습니다.
다음 지침에 따라 [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) 또는 [타사](workflows-actions.md#workflows-actions-types-3p) 작업의 소스 코드를 확인합니다.
**참고**
[GitHub 작업](workflows-actions.md#workflows-actions-types-github)의 소스 코드를 보려면 [GitHub Marketplace](https://github.com/marketplace/actions)의 작업 페이지로 이동합니다. 페이지에는 작업의 소스 코드를 찾을 수 있는 작업의 리포지토리에 대한 링크가 포함되어 있습니다.
**참고**
[빌드](build-workflow-actions.md), [테스트](test-workflow-actions.md), [GitHub Actions](integrations-github-action-add.md) 등의 CodeCatalyst 작업의 소스 코드는 볼 수 없습니다.
**참고**
AWS 는 GitHub Actions 또는 타사 작업의 작업 코드를 지원하거나 보장하지 않습니다.
**작업의 소스 코드 보기**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 코드를 보려는 작업을 찾습니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택하거나 새로 워크플로를 생성합니다. 워크플로 생성에 대한 자세한 내용은 [워크플로 생성](workflows-create-workflow.md) 섹션을 참조하세요.
1. **편집**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택하여 CodeCatalyst, CodeCatalyst Labs 및 타사 작업을 확인합니다.
1. 작업을 검색하고 해당 이름을 선택합니다. **\$1**(더하기 부호)를 선택합니다.
작업에 대한 세부 정보가 표시됩니다.
1. 작업 세부 정보 대화 상자 하단에서 **다운로드**를 선택합니다.
작업의 소스 코드가 있는 Amazon S3 버킷을 보여주는 페이지가 나타납니다. 자세한 내용은 *Amazon Simple Storage Service 사용 안내서*의 [Amazon S3란 무엇인가요?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)를 참조하세요.
1. 코드를 검사하여 품질 및 보안에 대한 기대치를 충족하는지 확인합니다.
# GitHub Actions와 통합
*GitHub 작업*은 GitHub 워크플로와 함께 사용하도록 개발되었다는 점을 제외하면 [CodeCatalyst 작업](workflows-actions.md#workflows-actions-types-cc)과 매우 유사합니다. GitHub Actions에 대한 자세한 내용은 [GitHub Actions](https://docs.github.com/en/actions) 설명서를 참조하세요.
CodeCatalyst 워크플로에서 기본 CodeCatalyst 작업과 함께 GitHub Actions를 사용할 수 있습니다.
CodeCatalyst 워크플로에 GitHub 작업을 추가하는 방법은 두 가지가 있습니다.
+ CodeCatalyst 콘솔의 큐레이션된 목록에서 GitHub 작업을 선택할 수 있습니다. 몇 가지 인기 있는 GitHub Actions를 사용할 수 있습니다. 자세한 내용은 [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md) 섹션을 참조하세요.
+ CodeCatalyst 콘솔에서 사용하려는 GitHub Actions를 사용할 수 없는 경우 **GitHub Actions** 작업을 사용하여 추가할 수 있습니다.
***GitHub Actions*** 작업은 GitHub Actions를 래핑하고 CodeCatalyst 워크플로와 호환되는 *CodeCatalyst 작업*입니다.
다음은 [Super-Linter](https://github.com/marketplace/actions/super-linter) GitHub Actions를 래핑하는 **GitHub Actions**의 예입니다.
```
Actions:
GitHubAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: "true"
DEFAULT_BRANCH: main
```
이전 코드에서 CodeCatalyst **GitHub Actions** 작업(`aws/github-actions-runner@v1`로 식별됨)은 Super-Linter OSS 작업(`github/super-linter@v4`로 식별됨)을 래핑하여 CodeCatalyst 워크플로에서 작동하도록 합니다.
자세한 내용은 ['GitHub Actions' 작업 추가](integrations-github-action-add.md) 섹션을 참조하세요.
이전 예시와 같이 큐레이션된 작업과 큐레이션되지 않은 모든 GitHub Actions는 **GitHub Actions**(`aws/github-actions-runner@v1`)으로 래핑해야 합니다. 작업이 제대로 작동하려면 래퍼가 필요합니다.
**Topics**
+ [GitHub Actions는 CodeCatalyst 작업과 어떻게 다릅니까?](#integrations-github-actions-how-different)
+ [GitHub Actions는 워크플로의 다른 CodeCatalyst 작업과 상호 작용할 수 있습니까?](#integrations-github-actions-interactions.title)
+ [어떤 GitHub Actions를 사용할 수 있나요?](#integrations-github-actions-supported)
+ [CodeCatalyst의 GitHub Actions 제한 사항](#integrations-github-actions-limitations)
+ [GitHub 작업(상위 단계)을 추가하려면 어떻게 해야 하나요?](#integrations-github-actions-how-to)
+ [GitHub 작업은 GitHub에서 실행되나요?](#integrations-github-actions-where-it-runs)
+ [GitHub 워크플로도 사용할 수 있나요?](#integrations-github-actions-workflows-support.title)
+ ['GitHub Actions' 작업에 사용되는 런타임 이미지](#integrations-github-actions-runtime)
+ [자습서: GitHub 작업을 사용한 린트 코드](integrations-github-action-tutorial.md)
+ ['GitHub Actions' 작업 추가](integrations-github-action-add.md)
+ [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md)
+ [GitHub 출력 파라미터 내보내기](integrations-github-action-export.md)
+ [GitHub 출력 파라미터 참조](integrations-github-action-referencing.md)
+ ['GitHub Actions' 작업 YAML](github-action-ref.md)
## GitHub Actions는 CodeCatalyst 작업과 어떻게 다릅니까?
CodeCatalyst 워크플로 내에서 사용되는 GitHub Actions는 CodeCatalyst 작업 AWS 과 동일한 수준의 액세스 및 CodeCatalyst 기능(예: [환경](deploy-environments.md) 및 [문제](issues.md))과의 통합을 제공하지 않습니다. CodeCatalyst
## GitHub Actions는 워크플로의 다른 CodeCatalyst 작업과 상호 작용할 수 있습니까?
예. 예를 들어 GitHub Actions는 다른 CodeCatalyst 작업에서 생성된 변수를 입력으로 사용할 수 있으며, 출력 파라미터 및 아티팩트를 CodeCatalyst 작업과 공유할 수도 있습니다. 자세한 내용은 [GitHub 출력 파라미터 내보내기](integrations-github-action-export.md) 및 [GitHub 출력 파라미터 참조](integrations-github-action-referencing.md) 섹션을 참조하세요.
## 어떤 GitHub Actions를 사용할 수 있나요?
CodeCatalyst 콘솔을 통해 사용 가능한 모든 GitHub 작업과 [GitHub Marketplace](https://github.com/marketplace/actions)에서 사용 가능한 모든 GitHub 작업을 사용할 수 있습니다. Marketplace에서 GitHub 작업을 사용하기로 결정한 경우 다음 [제한](#integrations-github-actions-limitations) 사항에 유의하세요.
## CodeCatalyst의 GitHub Actions 제한 사항
+ GitHub Actions는 CodeCatalyst [Lambda 컴퓨팅 유형](workflows-working-compute.md#compute.types)에 사용할 수 없습니다.
+ GitHub Actions는 이전 도구를 포함하는 [2022년 11월](build-images.md#build.previous-image) 런타임 환경 Docker 이미지에서 실행됩니다. 사용할 이미지 및 도구에 대한 자세한 내용은 [런타임 환경 이미지 지정](build-images.md) 섹션을 참조하세요.
+ 내부적으로 [`github` 컨텍스트](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context)를 사용하거나 GitHub 관련 리소스를 참조하는 GitHub Actions는 CodeCatalyst에서 지원되지 않습니다. 예를 들어 다음 작업은 CodeCatalyst에서 작동하지 않습니다.
+ GitHub 리소스를 추가, 변경 또는 업데이트하려는 작업입니다. 예를 들어 풀 요청을 업데이트하거나 GitHub에서 문제를 생성하는 작업이 있습니다.
+ [https://github.com/actions](https://github.com/actions) 나열된 거의 모든 작업이 이에 해당합니다.
+ [Docker 컨테이너 작업](https://docs.github.com/en/actions/creating-actions/about-custom-actions#docker-container-actions)인 GitHub Actions는 작동하지만, 빌드 프로젝트는 기본 Docker 사용자(루트)가 실행해야 합니다. 작업을 user 1001로 실행하지 않습니다. (작성 시점에서 사용자 user 1001은 GitHub 에서 작동하지만 CodeCatalyst에서는 작동하지 않습니다.) 자세한 내용은 [GitHub Actions에 대한 Dockerfile 지원](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions)의 [사용자](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user) 항목을 참조하세요.
CodeCatalyst 콘솔을 통해 사용할 수 있는 GitHub Actions 목록은 [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md) 섹션을 참조하세요.
## GitHub 작업(상위 단계)을 추가하려면 어떻게 해야 하나요?
GitHub 작업을 CodeCatalyst 워크플로에 추가하는 간략한 단계는 다음과 같습니다.
1. CodeCatalyst 프로젝트에서 **워크플로를 생성**합니다. 워크플로에서는 애플리케이션을 빌드, 테스트 및 배포하는 방법을 정의합니다. 자세한 내용은 [워크플로 시작하기](workflows-getting-started.md) 섹션을 참조하세요.
1. 워크플로에서 **큐레이션된 GitHub Actions를 추가**하거나 **GitHub Actions** 작업을 추가합니다.
1. 다음 중 하나를 수행할 수 있습니다.
+ 큐레이션된 작업을 추가하기로 선택한 경우 구성합니다. 자세한 내용은 [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md) 섹션을 참조하세요.
+ 큐레이션되지 않은 작업을 추가하기로 선택한 경우 **GitHub Actions** 작업 내에서 **GitHub Actions의 YAML 코드**를 붙여넣습니다. 이 코드는 [GitHub Marketplace](https://github.com/marketplace/actions)에서 선택한 GitHub 작업의 세부 정보 페이지에서 찾을 수 있습니다. CodeCatalyst에서 작동하려면 코드를 약간 수정해야 할 수 있습니다. 자세한 내용은 ['GitHub Actions' 작업 추가](integrations-github-action-add.md) 섹션을 참조하세요.
1. (선택 사항) 워크플로 내에 빌드 및 테스트 작업과 같은 **다른 작업을 추가**합니다. 자세한 내용은 [워크플로를 사용하여 빌드, 테스트 및 배포워크플로를 사용하여 빌드, 테스트 및 배포](workflow.md) 섹션을 참조하세요.
1. 트리거를 통해 **워크플로를 수동으로 또는 자동으로 시작**합니다. 워크플로는 GitHub 작업과 워크플로의 기타 작업을 실행합니다. 자세한 내용은 [워크플로 수동 실행 시작](workflows-manually-start.md) 섹션을 참조하세요.
자세한 단계는 다음을 참조하세요.
+ [큐레이션된 GitHub 작업 추가](integrations-github-action-add-curated.md).
+ ['GitHub Actions' 작업 추가](integrations-github-action-add.md).
## GitHub 작업은 GitHub에서 실행되나요?
아니요. GitHub 작업은 CodeCatalyst의 [런타임 환경 이미지](workflows-working-compute.md)를 사용하여 CodeCatalyst에서 실행됩니다.
## GitHub 워크플로도 사용할 수 있나요?
아니요.
## 'GitHub Actions' 작업에 사용되는 런타임 이미지
CodeCatalyst **GitHub Actions** 작업은 [2022년 11월 이미지](build-images.md#build.previous-image)에서 실행됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 섹션을 참조하세요.
# 자습서: GitHub 작업을 사용한 린트 코드
이 자습서에서는 Amazon CodeCatalyst 워크플로에 [Super-Linter GitHub 작업](https://github.com/marketplace/actions/super-linter)을 추가합니다. Super-Linter 작업은 코드를 검사하고, 코드에 오류가 있는 영역, 서식 문제, 의심스러운 구문을 찾은 다음, 결과를 CodeCatalyst 콘솔에 출력합니다. 워크플로에 린터를 추가한 후 워크플로를 실행하여 샘플 Node.js 애플리케이션(`app.js`)을 린트합니다. 그런 다음 보고된 문제를 수정하고 워크플로를 다시 실행하여 수정 사항이 제대로 작동하는지 확인합니다.
**작은 정보**
[CloudFormation 템플릿](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)과 같은 YAML 파일을 린트하기 위해 Super-Linter를 사용하는 것이 좋습니다.
**Topics**
+ [사전 조건](#integrations-github-action-tutorial-prereqs)
+ [1단계: 소스 리포지토리 생성](#integrations-github-action-tutorial-create-source-repo)
+ [2단계: app.js 파일 추가](#integrations-github-action-tutorial-add-appjs)
+ [3단계: Super-Linter 작업을 실행하는 워크플로 생성](#integrations-github-action-tutorial-create-workflow)
+ [4단계: Super-Linter에서 발견한 문제 해결](#integrations-github-action-tutorial-fix-probs)
+ [정리](#integrations-github-action-tutorial-cleanup)
## 사전 조건
시작하려면 다음이 필요합니다.
+ 가 연결된 CodeCatalyst **스페이스**입니다 AWS 계정. 자세한 내용은 [스페이스 생성](spaces-create.md) 단원을 참조하십시오.
+ CodeCatalyst 스페이스의 이름이 `codecatalyst-linter-project`인 빈 프로젝트로. **처음부터 시작** 옵션을 선택하여 이 프로젝트를 생성합니다.
```
```
자세한 내용은 [Amazon CodeCatalyst에서 빈 프로젝트 생성](projects-create.md#projects-create-empty) 섹션을 참조하세요.
## 1단계: 소스 리포지토리 생성
이 단계에서는 CodeCatalyst에 소스 리포지토리를 생성합니다. 이 리포지토리를 사용하여 이 자습서의 샘플 애플리케이션 소스 파일인 `app.js`를 저장합니다.
소스 리포지토리에 대한 자세한 정보는 [소스 리포지토리 생성](source-repositories-create.md) 섹션을 참조하세요.
**소스 리포지토리를 생성하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-linter-project` 프로젝트로 이동합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. **리포지토리 추가**를 선택하고 **리포지토리 생성**을 선택합니다.
1. **리포지토리 이름**에 다음과 같이 입력합니다.
```
codecatalyst-linter-source-repository
```
1. **생성(Create)**을 선택합니다.
## 2단계: app.js 파일 추가
이 단계에서는 원본 리포지토리에 `app.js` 파일을 추가합니다. `app.js`에는 린터에서 찾을 수 있는 몇 가지 실수가 있는 함수 코드가 포함되어 있습니다.
**app.js 파일을 추가하려면**
1. CodeCatalyst 콘솔에서 `codecatalyst-linter-project` 프로젝트를 선택합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. 소스 리포지토리 목록에서 `codecatalyst-linter-source-repository` 리포지토리를 선택합니다.
1. **파일**에서 **파일 생성**을 선택합니다.
1. 다음 코드를 텍스트 상자에 입력합니다.
```
// const axios = require('axios')
// const url = 'http://checkip.amazonaws.com/';
let response;
/**
*
* Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
* @param {Object} event - API Gateway Lambda Proxy Input Format
*
* Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html
* @param {Object} context
*
* Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
* @returns {Object} object - API Gateway Lambda Proxy Output Format
*
*/
exports.lambdaHandler = async (event, context) => {
try {
// const ret = await axios(url);
response = {
statusCode: 200,
'body': JSON.stringify({
message: 'hello world'
// location: ret.data.trim()
})
}
} catch (err) {
console.log(err)
return err
}
return response
}
```
1. **파일 이름**에 `app.js`를 입력합니다. 다른 기본 옵션을 유지합니다.
1. **커밋**을 선택합니다.
`app.js` 새 역할이 생성되었습니다.
## 3단계: Super-Linter 작업을 실행하는 워크플로 생성
이 단계에서는 코드를 소스 리포지토리로 푸시할 때 Super-Linter 작업을 실행하는 워크플로를 생성합니다. 워크플로는 YAML 파일에 정의한 다음 구성 요소로 구성됩니다.
+ **트리거** - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ **'GitHub Actions' 작업** - 트리거 시 **GitHub Actions** 작업은 Super-Linter 작업을 실행하여 소스 리포지토리의 모든 파일을 검사합니다. 리터에서 문제를 발견하면 워크플로 작업이 실패합니다.
**Super-Linter 작업을 실행하는 워크플로를 생성하려면**
1. CodeCatalyst 콘솔에서 `codecatalyst-linter-project` 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
1. **소스 리포지토리**에서 `codecatalyst-linter-source-repository`을 선택합니다.
1. **브랜치**에서 `main`을 선택합니다.
1. **생성(Create)**을 선택합니다.
1. YAML 샘플 코드를 삭제합니다.
1. 다음 YAML을 추가합니다:
```
Name: codecatalyst-linter-workflow
SchemaVersion: "1.0"
Triggers:
- Type: PUSH
Branches:
- main
Actions:
SuperLinterAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
github-action-code
```
이 절차의 다음 단계에 설명된 대로 앞의 코드에서 *github-action-code*를 Super-Linter 작업 코드로 바꿉니다.
1. GitHub Marketplace의 [Super-Linter 페이지로](https://github.com/marketplace/actions/super-linter) 이동합니다.
1. `steps:`(소문자)에서 코드를 찾아 CodeCatalyst 워크플로의 `Steps:`(대문자)에 붙여 넣습니다.
다음 코드와 같이 CodeCatalyst 표준에 맞게 GitHub 작업 코드를 조정합니다.
이제 CodeCatalyst 워크플로는 다음과 같습니다.
```
Name: codecatalyst-linter-workflow
SchemaVersion: "1.0"
Triggers:
- Type: PUSH
Branches:
- main
Actions:
SuperLinterAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: "true"
DEFAULT_BRANCH: main
```
1. (선택 사항) 커밋하기 전에 YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 **커밋 메시지**를 입력한 다음 `codecatalyst-linter-source-repository`**리포지토리**를 선택하고 **커밋**을 다시 선택합니다.
이제 워크플로를 생성했습니다. 워크플로 상단에 정의된 트리거로 인해 워크플로 실행이 자동으로 시작됩니다.
**진행 중인 워크플로 실행을 보려면**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 방금 생성한 `codecatalyst-linter-workflow` 워크플로를 선택합니다.
1. 워크플로 다이어그램에서 **SuperLinterAction**을 선택합니다.
1. 작업이 실패할 때까지 기다립니다. 이 실패는 코드에서 linter가 문제를 발견했기 때문에 예상됩니다.
1. CodeCatalyst 콘솔을 열어 두고 [4단계: Super-Linter에서 발견한 문제 해결](#integrations-github-action-tutorial-fix-probs)로 이동합니다.
## 4단계: Super-Linter에서 발견한 문제 해결
Super-Linter는 `app.js` 코드와 소스 리포지토리에 포함된 `README.md` 파일에서 문제를 발견했어야 합니다.
**린터에서 발견된 문제를 해결하려면**
1. CodeCatalyst 콘솔에서 **로그** 탭을 선택한 다음 **Lint Code Base**를 선택합니다.
생성된 슈퍼 린터 작업이 표시되는 로그입니다.
1. 슈퍼 린터 로그에서 90행을 따라 아래로 스크롤하면 문제의 시작을 찾을 수 있습니다. 다음처럼 보일 것입니다.
```
/github/workspace/hello-world/app.js:3:13: Extra semicolon.
/github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed.
/github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found.
/github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4.
/github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found.
```
1. 소스 리포지토리에서 `app.js` 및 `README.md`를 수정하고 변경 사항을 커밋합니다.
**작은 정보**
`README.md`를 수정하려면 다음과 같이 코드 블록에 `markdown`을 추가합니다.
```
```markdown
Setup examples:
...
```
```
변경하면 다른 워크플로가 자동으로 실행됩니다. 워크플로가 완료될 때까지 기다립니다. 모든 문제를 해결한 경우 워크플로가 성공해야 합니다.
## 정리
CodeCatalyst에서 정리하여 환경에서 이 자습서의 트레이스를 제거합니다.
**CodeCatalyst에서 정리하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-linter-source-repository`를 삭제합니다.
1. `codecatalyst-linter-workflow`를 삭제합니다.
이 자습서에서는 일부 코드를 린트하기 위해 CodeCatalyst 워크플로에 Super-Linter GitHub 작업을 추가하는 방법을 배웠습니다.
# 'GitHub Actions' 작업 추가
***GitHub Actions*** 작업은 GitHub Actions를 래핑하고 CodeCatalyst 워크플로와 호환되는 *CodeCatalyst 작업*입니다.
자세한 내용은 [GitHub Actions와 통합](integrations-github-actions.md) 섹션을 참조하세요.
워크플로에 **GitHub Actions** 작업을 추가하려면 다음 단계를 따르세요.
**작은 정보**
**GitHub Actions** 작업을 사용하는 방법을 보여주는 자습서는 [자습서: GitHub 작업을 사용한 린트 코드](integrations-github-action-tutorial.md) 섹션을 참조하세요.
------
#### [ Visual ]
**시각적 편집기를 사용하여 'GitHub Actions' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **GitHub**를 선택합니다.
1. **GitHub Actions** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **GitHub Actions**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['GitHub Actions' 작업 YAML](github-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 'GitHub Actions' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **GitHub**를 선택합니다.
1. **GitHub Actions** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **GitHub Actions**를 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['GitHub Actions' 작업 YAML](github-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
## 'GitHub Actions' 작업 정의
**GitHub Actions** 작업은 워크플로 정의 파일 내의 YAML 속성 집합으로 정의됩니다. 이러한 속성에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)의 ['GitHub Actions' 작업 YAML](github-action-ref.md) 섹션을 참조하세요.
# 큐레이션된 GitHub 작업 추가
*큐레이션된 GitHub 작업*은 CodeCatalyst 콘솔에서 사용할 수 있는 GitHub 작업이며 CodeCatalyst 워크플로 내에서 GitHub 작업을 사용하는 방법의 예입니다.
큐레이션된 GitHub Actions는 CodeCatalyst에서 만든 [**GitHub Actions** 작업](integrations-github-action-add.md)에 래핑되며 `aws/github-actions-runner@v1` 식별자로 식별됩니다. 예를 들어 큐레이션된 GitHub 작업인 [TruffleHog OSS](https://github.com/marketplace/actions/trufflehog-oss)는 다음과 같습니다.
```
Actions:
TruffleHogOSS_e8:
Identifier: aws/github-actions-runner@v1
Inputs:
Sources:
- WorkflowSource # This specifies that the action requires this Workflow as a source
Configuration:
Steps:
- uses: trufflesecurity/trufflehog@v3.16.0
with:
path: ' ' # Required; description: Repository path
base: ' ' # Required; description: Start scanning from here (usually main branch).
head: ' ' # Optional; description: Scan commits until here (usually dev branch).
extra_args: ' ' # Optional; description: Extra args to be passed to the trufflehog cli.
```
이전 코드에서 CodeCatalyst **GitHub Actions** 작업(`aws/github-actions-runner@v1`로 식별됨)은 TruffleHog OSS 작업(`trufflesecurity/trufflehog@v3.16.0`로 식별됨)을 래핑하여 CodeCatalyst 워크플로에서 작동하도록 합니다.
이 작업을 구성하려면 `with:`의 빈 문자열을 고유한 값으로 바꿉니다. 예:
```
Actions:
TruffleHogOSS_e8:
Identifier: aws/github-actions-runner@v1
Inputs:
Sources:
- WorkflowSource # This specifies that the action requires this Workflow as a source
Configuration:
Steps:
- uses: trufflesecurity/trufflehog@v3.16.0
with:
path: ./
base: main # Required; description: Start scanning from here (usually main branch).
head: HEAD # Optional; description: Scan commits until here (usually dev branch).
extra_args: '‐‐debug ‐‐only-verified' # Optional; description: Extra args to be passed to the trufflehog cli.
```
큐레이션된 GitHub 작업을 워크플로에 추가하려면 다음 절차를 사용합니다. CodeCatalyst 워크플로에서 GitHub Actions를 사용하는 방법에 대한 일반적인 내용은 [GitHub Actions와 통합](integrations-github-actions.md) 섹션을 참조하세요.
**참고**
큐레이션된 작업 목록 중에 GitHub Actions가 표시되지 않는 경우에도 **GitHub Actions** 작업을 사용하여 워크플로에 추가할 수 있습니다. 자세한 내용은 ['GitHub Actions' 작업 추가](integrations-github-action-add.md) 섹션을 참조하세요.
------
#### [ Visual ]
**시각적 편집기를 사용하여 큐레이션된 GitHub 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **GitHub**를 선택합니다.
1. GitHub 작업을 찾아보거나 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ GitHub 작업의 이름을 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력,** **구성** 및 **출력** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['GitHub Actions' 작업 YAML](github-action-ref.md) 섹션을 참조하세요. 이 참조는 **GitHub Actions** 작업에 사용할 수 있는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다. 이는 YAML 및 시각적 편집기 모두에 표시됩니다.
큐레이션된 GitHub 작업에서 사용할 수 있는 구성 옵션에 대한 자세한 내용은 해당 설명서를 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 큐레이션된 GitHub 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **GitHub**를 선택합니다.
1. GitHub 작업을 찾아보거나 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ GitHub 작업의 이름을 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. **GitHub Actions** 작업에 사용할 수 있는 각 속성에 대한 설명은 ['GitHub Actions' 작업 YAML](github-action-ref.md)에 나와 있습니다.
큐레이션된 GitHub 작업에서 사용할 수 있는 구성 옵션에 대한 자세한 내용은 해당 설명서를 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# GitHub 출력 파라미터 내보내기
CodeCatalyst 워크플로에서 [GitHub 출력 파라미터](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter)를 사용할 수 있습니다.
**참고**
*출력 파라미터*의 또 다른 단어는 *변수*입니다. GitHub는 설명서에서 용어 *출력 파라미터*를 사용하기 때문에 이 용어도 사용할 것입니다.
다른 CodeCatalyst 워크플로 작업에서 사용할 수 있도록 GitHub 작업에서 GitHub 출력 파라미터를 내보내려면 다음 지침을 사용합니다.
**GitHub 출력 파라미터를 내보내려면**
1. 워크플로를 열고 **편집**을 선택합니다. 자세한 내용은 [워크플로 생성](workflows-create-workflow.md) 섹션을 참조하세요.
1. 내보내려는 출력 파라미터를 생성하는 **GitHub Actions** 작업에서 다음과 같은 기본 `Variables` 속성이 있는 `Outputs` 섹션을 추가합니다.
```
Actions:
MyGitHubAction:
Identifier: aws/github-actions-runner@v1
Outputs:
Variables:
- 'step-id_output-name'
```
다음과 같이 바꿉니다.
+ *step-id*를 GitHub 작업 `steps` 섹션의 `id:` 속성 값으로 바꿉니다.
+ *output-name*을 GitHub 출력 파라미터의 이름으로 바꿉니다.
**예시**
다음 예시에서는 `SELECTEDCOLOR` GitHub 출력 파라미터를 내보내는 방법을 보여줍니다.
```
Actions:
MyGitHubAction:
Identifier: aws/github-actions-runner@v1
Outputs:
Variables:
- 'random-color-generator_SELECTEDCOLOR'
Configuration:
Steps:
- name: Set selected color
run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
id: random-color-generator
```
# GitHub 출력 파라미터 참조
다음 지침을 사용하여 GitHub 출력 파라미터를 참조합니다.
**GitHub 출력 파라미터를 참조하려면**
1. [GitHub 출력 파라미터 내보내기](integrations-github-action-export.md)의 단계를 수행하세요.
이제 GitHub 출력 파라미터를 다른 작업에 사용할 수 있습니다.
1. 출력 파라미터의 `Variables` 값을 기록해 둡니다. 밑줄(\$1)이 포함됩니다.
1. 다음 구문을 사용하여 출력 파라미터를 참조하세요.
```
${action-name.output-name}
```
다음과 같이 바꿉니다.
+ *action-name*을 출력 파라미터를 생성하는 CodeCatalyst **GitHub 작업** 이름으로 바꿉니다(GitHub 작업 `name` 또는 `id`는 사용하지 않습니다).
+ *output-name* 을 앞서 적어 둔 출력 파라미터의 `Variables` 값으로 바꿉니다.
**예제**
```
BuildActionB:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: echo ${MyGitHubAction.random-color-generator_SELECTEDCOLOR}
```
**컨텍스트가 있는 예시**
다음 예시에서는 `GitHubActionA`에서 `SELECTEDCOLOR` 변수를 설정하고 출력한 다음 `BuildActionB`에서 참조하는 방법을 보여줍니다.
```
Actions:
GitHubActionA:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Set selected color
run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
id: random-color-generator
Outputs:
Variables:
- 'random-color-generator_SELECTEDCOLOR'
BuildActionB:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: echo ${GitHubActionA.random-color-generator_SELECTEDCOLOR}
```
# 'GitHub Actions' 작업 YAML
다음은 **GitHub Actions** 작업의 YAML 정의입니다.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
다음 코드에서 YAML 속성을 선택하면 설명이 표시됩니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
action-name:
Identifier: aws/github-actions-runner@v1
DependsOn:
- dependent-action-name-1
Compute:
Fleet: fleet-name
Timeout: timeout-minutes
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Inputs:
Sources:
- source-name-1
- source-name-2
Artifacts:
- artifact-name
Variables:
- Name: variable-name-1
Value: variable-value-1
- Name: variable-name-2
Value: variable-value-2
Outputs:
Artifacts:
- Name: output-artifact-1
Files:
- github-output/artifact-1.jar
- "github-output/build*"
- Name: output-artifact-2
Files:
- github-output/artifact-2.1.jar
- github-output/artifact-2.2.jar
Variables:
- variable-name-1
- variable-name-2
AutoDiscoverReports:
Enabled: true | false
ReportNamePrefix: AutoDiscovered
IncludePaths:
- "**/*"
ExcludePaths:
- node_modules/cdk/junit.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
Number: whole-number
Reports:
report-name-1:
Format: format
IncludePaths:
- "*.xml"
ExcludePaths:
- report2.xml
- report3.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
Number: whole-number
Configuration
Steps:
- github-actions-code
```
## action-name
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
해당 UI: 구성 탭/*action-name*
## Identifier
(*action-name*/**Identifier**)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
`aws/github-actions-runner@v1`를 **GitHub Actions** 작업에 사용합니다.
해당 UI: 워크플로 다이어그램/*action-name */**aws/github-actions-runner@v1** 레이블
## DependsOn
(*action-name*/**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*action-name*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Fleet
(*action-name*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/**컴퓨팅 플릿 - 선택 사항**
## Timeout
(*action-name*/**Timeout**)
(선택 사항)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Environment
(*action-name*/**Environment**)
(선택 사항)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*action-name*/Environment/**Name**)
([Environment](#github.environment) 포함 시 필수)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*action-name*/Environment/**Connections**)
(선택 사항)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
## Name
(*action-name*/Environment/Connections/**Name**)
([Connections](#github.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
해당 UI: 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
## Role
(*action-name*/Environment/Connections/**Role**)
([Connections](#github.environment.connections) 포함 시 필수)
Amazon S3 및 Amazon ECR과 같은 AWS 서비스에 액세스하고 운영하기 위해 이 작업이 사용하는 IAM 역할의 이름을 지정합니다. 이 역할이 스페이스의 AWS 계정 연결에 추가되었는지 확인합니다. 계정 연결에 IAM 역할을 추가하려면 [계정 연결에 IAM 역할 추가](ipa-connect-account-addroles.md) 섹션을 참조하세요.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 다음 정책이 있는지 확인합니다.
**참고**
이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
**주의**
권한을 **GitHub 작업** 작업에 필요한 권한으로 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
해당 UI: 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
## Inputs
(*action-name*/**Inputs**)
(선택 사항)
이 `Inputs` 섹션에서는 워크플로 실행 중에 작업에 필요한 데이터를 정의합니다.
**참고**
**GitHub Actions** 작업당 최대 4개의 입력(소스 1개 및 아티팩트 3개)이 허용됩니다. 변수는 이 합계에 포함되지 않습니다.
서로 다른 입력(소스 및 아티팩트)에 있는 파일을 참조해야 하는 경우 소스 입력은 기본 입력이고 아티팩트는 보조 입력입니다. 보조 입력의 파일에 대한 참조는 특수 접두사를 사용하여 기본 입력에서 파일을 구분합니다. 자세한 내용은 [예시: 여러 아티팩트에서 파일 참조](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)을 참조하세요.
해당 UI: **입력** 탭
## Sources
(*action-name*/Inputs/**Sources**)
(선택 사항)
작업에 필요한 소스 리포지토리를 나타내는 레이블을 지정합니다. 현재 지원되는 유일한 레이블은 워크플로 정의 파일이 저장되는 소스 리포지토리를 나타내는 `WorkflowSource`입니다.
소스를 생략하는 경우 `action-name/Inputs/Artifacts` 아래에 하나 이상의 입력 아티팩트를 지정해야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*action-name*/Inputs/**Artifacts**)
(선택 사항)
이 작업에 대한 입력으로 제공하려는 이전 작업의 아티팩트를 지정합니다. 이러한 아티팩트는 이전 작업에서 출력 아티팩트로 이미 정의되어 있어야 합니다.
입력 아티팩트를 지정하지 않으면 `action-name/Inputs/Sources` 아래에 소스 리포지토리를 하나 이상 지정해야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
**아티팩트 - 선택적** 드롭다운 목록을 사용할 수 없거나(시각적 편집기) YAML(YAML 편집기)을 검증할 때 오류가 발생하는 경우 작업이 하나의 입력만 지원하기 때문일 수 있습니다. 이 경우 소스 입력을 제거해 보세요.
해당 UI: 입력 탭/**아티팩트 - 선택 사항**
## Variables - input
(*action-name*/Inputs/**Variables**)
(선택 사항)
작업에 사용할 수 있도록 하려는 입력 변수를 정의하는 이름/값 페어의 시퀀스를 지정합니다. 변수 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 변수 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**변수 - 선택 사항**
## Outputs
(*action-name*/**Outputs**)
(선택 사항)
워크플로 실행 중에 작업에 의해 출력되는 데이터를 정의합니다.
해당 UI: **출력** 탭
## Artifacts - output
(*action-name*/Outputs/**Artifacts**)
(선택 사항)
작업에서 생성된 아티팩트의 이름을 지정합니다. 아티팩트 이름은 워크플로 내에서 고유해야 하며 영숫자 문자(a-z, A-Z, 0-9) 및 밑줄(\$1)로 제한됩니다. 공백, 하이픈(-) 및 특수 문자는 허용되지 않습니다. 출력 아티팩트 이름에서 공백, 하이픈 및 기타 특수 문자를 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/**아티팩트**
## Name
(*action-name*/Outputs/Artifacts/**Name**)
([Artifacts - output](#github.outputs.artifacts) 포함 시 필수)
작업에서 생성된 아티팩트의 이름을 지정합니다. 아티팩트 이름은 워크플로 내에서 고유해야 하며 영숫자 문자(a-z, A-Z, 0-9) 및 밑줄(\$1)로 제한됩니다. 공백, 하이픈(-) 및 특수 문자는 허용되지 않습니다. 출력 아티팩트 이름에서 공백, 하이픈 및 기타 특수 문자를 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/아티팩트/아티팩트 추가/**빌드 아티팩트 이름**
## Files
(*action-name*/Outputs/Artifacts/**Files**)
([Artifacts - output](#github.outputs.artifacts) 포함 시 필수)
CodeCatalyst가 작업으로 출력되는 아티팩트에 포함하는 파일을 지정합니다. 이러한 파일은 실행 시 워크플로 작업에 의해 생성되며 소스 리포지토리에서도 사용할 수 있습니다. 파일 경로는 소스 리포지토리 또는 이전 작업의 아티팩트에 상주할 수 있으며 소스 리포지토리 또는 아티팩트 루트와 관련이 있습니다. glob 패턴을 사용하여 경로를 지정할 수 있습니다. 예시:
+ 빌드 위치 또는 소스 리포지토리 위치의 루트에 있는 단일 파일을 지정하려면 `my-file.jar`를 사용합니다..
+ 하위 디렉터리에 단일 파일을 지정하려면 `directory/my-file.jar` 또는 `directory/subdirectory/my-file.jar`를 사용합니다.
+ 모든 파일을 지정하려면 `"**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리에 있는 모든 파일 및 디렉터리를 지정하려면 `"directory/**/*"`를 사용합니다. `**` glob 패턴은 임의의 수의 하위 디렉터리와 일치함을 나타냅니다.
+ `directory`라는 디렉터리의 모든 파일을 지정하되 해당 하위 디렉터리는 지정하지 않으려면 `"directory/*"`를 사용합니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
**참고**
파일 경로에 접두사를 추가하여 찾을 아티팩트 또는 소스를 나타내야 할 수 있습니다. 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션을 참조하세요.
해당 UI: 출력 탭/아티팩트/아티팩트 추가/**빌드에서 생성된 파일**
## Variables - output
(*action-name*/Outputs/**Variables**)
(선택 사항)
후속 작업에서 사용할 수 있도록 작업을 내보낼 변수를 지정합니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 출력 탭/변수/**변수 추가**
## variable-name-1
(*action-name*/Outputs/Variables**variable-name-1**)
(선택 사항)
작업을 내보낼 변수의 이름을 지정합니다. 이 변수는 동일한 작업의 `Inputs` 또는 `Steps` 섹션에 이미 정의되어 있어야 합니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 출력 탭/변수/변수 추가/**이름**
## AutoDiscoverReports
(*action-name*/Outputs/**AutoDiscoverReports**)
(선택 사항)
자동 검색 기능의 구성을 정의합니다.
자동 검색을 활성화하면 CodeCatalyst는 작업에 전달된 모든 `Inputs`와 작업 자체에서 생성된 모든 파일을 검색하여 테스트, 코드 적용 범위 및 소프트웨어 구성 분석(SCA) 보고서를 찾습니다. 발견된 각 보고서에 대해 CodeCatalyst는 이를 CodeCatalyst 보고서로 변환합니다. *CodeCatalyst 보고서*는 CodeCatalyst 서비스에 완전히 통합되고 CodeCatalyst 콘솔을 통해 보고 조작할 수 있는 보고서입니다.
**참고**
기본적으로 자동 검색 기능은 모든 파일을 검사합니다. [IncludePaths](#github.reports.includepaths) 또는 [ExcludePaths](#github.reports.excludepaths) 속성을 사용하여 검사할 파일을 제한할 수 있습니다.
해당 UI: *없음*
## Enabled
(*action-name*/Outputs/AutoDiscoverReports/**Enabled**)
(선택 사항)
자동 검색 기능을 활성화하거나 비활성화합니다.
유효한 값은 `true` 또는 `false`입니다.
`Enabled` 생략 시 기본값은 `true`입니다.
해당 UI: 출력 탭/보고서/**자동 검색 보고서**
## ReportNamePrefix
(*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**)
([AutoDiscoverReports](#github.outputs.autodiscover) 포함 및 활성화 시 필수)
연결된 CodeCatalyst 보고서의 이름을 지정하기 위해 CodeCatalyst가 찾는 모든 보고서에 우선하는 접두사를 지정합니다. 예를 들어 접두사를 `AutoDiscovered`로 지정하고 CodeCatalyst가 두 개의 테스트 보고서, `TestSuiteOne.xml` 및 `TestSuiteTwo.xml`를 자동으로 검색하면 연결된 CodeCatalyst 보고서의 이름이 `AutoDiscoveredTestSuiteOne` 및 `AutoDiscoveredTestSuiteTwo`로 지정됩니다.
해당 UI: 출력 탭/보고서/보고서 자동 검색/**보고서 접두사**
## IncludePaths
(*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**)
([AutoDiscoverReports](#github.outputs.autodiscover) 포함 및 활성화 시 또는 [Reports](#github.configuration.reports) 포함 시 필수)
원시 보고서를 검색할 때 CodeCatalyst에 포함되는 파일 및 파일 경로를 지정합니다. 예를 들어 `"/test/report/*"` 지정 시 CodeCatalyst는 작업에서 `/test/report/*` 디렉터리를 찾는 데 사용되는 전체 [빌드 이미지](build-images.md)를 검색합니다. 해당 디렉터리를 찾으면 CodeCatalyst는 해당 디렉터리에서 보고서를 찾습니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
이 속성이 생략되면 기본값은 `"**/*"`입니다. 즉, 검색에 모든 경로의 모든 파일이 포함됩니다.
**참고**
수동으로 구성된 보고서의 경우 `IncludePaths`는 단일 파일과 일치하는 글로브 패턴이어야 합니다.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/'경로 포함/제외'/**경로 포함**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/'경로 포함/제외'/**경로 포함**
## ExcludePaths
(*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**)
또는
(*action-name*/Outputs/Reports/ *report-name-1*/**ExcludePaths**)
(선택 사항)
원시 보고서를 검색할 때 CodeCatalyst에서 제외하는 파일 및 파일 경로를 지정합니다. 예를 들어 `"/test/my-reports/**/*"` 지정 시 CodeCatalyst는 `/test/my-reports/` 디렉터리의 파일을 검색하지 않습니다. 디렉터리의 모든 파일을 무시하려면 `**/*` glob 패턴을 사용합니다.
**참고**
파일 경로에 별표(`*`) 또는 기타 특수 문자가 하나 이상 포함된 경우 경로를 큰따옴표(`""`)로 묶습니다. 특수 문자에 대한 자세한 내용은 [구문 지침 및 규칙](workflow-reference.md#workflow.terms.syntax.conv) 섹션을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/'경로 포함/제외'/**경로 제외**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/'경로 포함/제외'/**경로 제외**
## SuccessCriteria
(*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**)
또는
(*action-name*/Outputs/Reports/ *report-name-1*/**SuccessCriteria**)
(선택 사항)
테스트, 코드 적용 범위, 소프트웨어 구성 분석(SCA) 및 정적 분석(SA) 보고서의 성공 기준을 지정합니다.
자세한 내용은 [보고서의 성공 기준 구성](test-config-action.md#test.success-criteria) 섹션을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/**성공 기준**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/**성공 기준**
## PassRate
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**)
(선택 사항)
관련 CodeCatalyst 보고서를 통과로 표시하기 위해 통과해야 하는 테스트 보고서의 테스트 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 통과율 기준은 테스트 보고서에만 적용됩니다. 테스트 보고서에 대한 자세한 내용은 [테스트 보고서](test-workflow-actions.md#test-reports)의 내용을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/성공 기준/**통과율**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/성공 기준/**통과율**
## LineCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**)
(선택 사항)
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 줄 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 라인 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/성공 기준/**라인 적용 범위**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/성공 기준/**라인 적용 범위**
## BranchCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**)
(선택 사항)
연결된 CodeCatalyst 보고서를 통과로 표시하기 위해 다루어야 하는 코드 적용 범위 보고서의 브랜치 비율을 지정합니다. 유효한 값에는 십진수가 포함됩니다. 예시: `50`, `60.5`. 브랜치 적용 범위 기준은 코드 적용 범위 보고서에만 적용됩니다. 코드 적용 범위 보고서에 대한 자세한 내용은 [코드 적용 범위 보고서](test-workflow-actions.md#test-code-coverage-reports) 섹션을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/성공 기준/**브랜치 적용 범위**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/성공 기준/**브랜치 적용 범위**
## Vulnerabilities
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**)
또는
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**)
(선택 사항)
SCA 보고서에서 허용되는 취약성의 최대 수와 심각도를 지정하여 관련 CodeCatalyst 보고서를 통과로 표시합니다. 취약성을 지정하려면 다음을 지정해야 합니다.
+ 개수에 포함하려는 취약성의 최소 심각도입니다. 최대부터 최소 심각도까지 유효한 값은 `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` 및 `INFORMATIONAL`입니다.
예를 들어 `HIGH` 선택 시 `HIGH` 및 `CRITICAL` 취약성이 집계됩니다.
+ 허용하려는 지정된 심각도의 최대 취약성 수입니다. 이 수를 초과하면 CodeCatalyst 보고서가 실패로 표시됩니다. 유효한 값은 정수입니다.
취약성 기준은 SCA 보고서에만 적용됩니다. SCA 보고서에 대한 자세한 내용은 [소프트웨어 구성 분석 보고서](test-workflow-actions.md#test-sca-reports)의 내용을 참조하세요.
최소 심각도를 지정하려면 `Severity` 속성을 사용합니다. 최대 취약성 수를 지정하려면 `Number` 속성을 사용합니다.
SCA 보고서에 대한 자세한 내용은 [품질 보고서 유형](test-workflow-actions.md#test-reporting)의 내용을 참조하세요.
해당 UI:
+ 출력 탭/보고서/보고서 자동 검색/성공 기준/**취약성**
+ 출력 탭/보고서/보고서 수동 구성/*report-name-1*/성공 기준/**취약성**
## Reports
(*action-name*/Outputs/**Reports** )
(선택 사항)
테스트 보고서의 구성을 지정하는 섹션입니다.
해당 UI: 출력 탭/**보고서**
## report-name-1
(*action-name*/Outputs/Reports/**report-name-1** )
([Reports](#github.configuration.reports) 포함 시 필수)
원시 보고서에서 생성될 CodeCatalyst 보고서에 부여할 이름입니다.
해당 UI: 출력 탭/보고서 수동 구성/**보고서 이름**
## Format
(*action-name*/Outputs/Reports/*report-name-1*/**Format**)
([Reports](#github.configuration.reports) 포함 시 필수)
보고서에 사용할 파일 형식을 지정합니다. 가능한 값은 다음과 같습니다.
+ 테스트 보고서의 경우:
+ Cucumber JSON에서 **Cucumber**(시각 편집기) 또는 `CUCUMBERJSON`(YAML 편집기)를 지정합니다.
+ JUnit XML에 **JUnit**(시각 편집기) 또는 `JUNITXML`(YAML 편집기)를 지정합니다.
+ NUnit XML에 **NUnit**(시각 편집기) 또는 `NUNITXML`(YAML 편집기)를 지정합니다.
+ NUnit 3 XML에서 **NUnit3**(시각 편집기) 또는 `NUNIT3XML`(YAML 편집기)를 지정합니다.
+ Visual Studio TRX에서 **Visual Studio TRX**(시각 편집기) 또는 `VISUALSTUDIOTRX`(YAML 편집기)를 지정합니다.
+ TestNG XML에서 **TestNG**(시각 편집기) 또는 `TESTNGXML`(YAML 편집기)를 지정합니다.
+ 코드 적용 범위 보고서의 경우:
+ Clover XML에서 **Clover**(시각 편집기) 또는 `CLOVERXML`(YAML 편집기)를 지정합니다.
+ Cobertura XML에서 **Cobertura**(시각 편집기) 또는 `COBERTURAXML`(YAML 편집기)를 지정합니다.
+ JaCoCo XML의 경우 **JaCoCo**(시각 편집기) 또는 `JACOCOXML`(YAML 편집기)를 지정합니다.
+ [simplecov-json](https://github.com/vicentllongo/simplecov-json)이 아닌 [simplecov](https://github.com/simplecov-ruby/simplecov)에서 생성한 SimpleCov JSON의 경우 **Simplecov**(시각 편집기) 또는 `SIMPLECOV`(YAML 편집기)를 지정합니다.
+ 소프트웨어 구성 분석(SCA) 보고서의 경우:
+ SARIF에서 **SARIF**(시각 편집기) 또는 `SARIFSCA`(YAML 편집기)를 지정합니다.
해당 UI: 출력 탭/보고서/보고서 수동 구성/보고서 추가/*report–name-1*/**보고서 유형** 및 **보고서 형식**
## Configuration
(*action-name*/**Configuration**)
(필수) 작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## Steps
(*action-name*/Configuration/**Steps**)
(필수)
[GitHub Marketplace](https://github.com/marketplace)의 작업 세부 정보 페이지에 표시되는 대로 GitHub 작업 코드를 지정합니다. 다음 지침에 따라 코드를 추가합니다.
1. GitHub 작업 `steps:` 섹션의 코드를 CodeCatalyst 워크플로의 `Steps:` 섹션에 붙여 넣습니다. 코드는 대시(-)로 시작하며 다음과 비슷합니다.
붙여넣을 GitHub 코드:
```
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: master
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
1. 방금 붙여넣은 코드를 검토하고 CodeCatalyst 표준을 준수하도록 필요에 따라 수정합니다. 예를 들어 앞의 코드 블록을 사용하면 *빨간색 기울임*꼴로 된 코드를 제거하고 **굵은** 글씨체로 된 코드를 추가할 수 있습니다.
CodeCatalyst 워크플로 yaml:
```
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: mastermain
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
1. GitHub 작업에 포함되지만 `steps:` 섹션 내에 존재하지 않는 추가 코드는 CodeCatalyst에서 해당하는 코드를 사용하여 CodeCatalyst 워크플로에 추가합니다. [워크플로 YAML 정의](workflow-reference.md)를 검토하여 GitHub 코드를 CodeCatalyst에 이식하는 방법에 대한 인사이트를 얻을 수 있습니다. 자세한 마이그레이션 단계는 이 가이드의 범위를 벗어납니다.
다음은 **GitHub Actions** 작업에서 파일 경로를 지정하는 방법의 예입니다.
```
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
...
- run: cd /sources/WorkflowSource/MyFolder/ && cat file.txt
- run: cd /artifacts/MyGitHubAction/MyArtifact/MyFolder/ && cat file2.txt
```
파일 경로 지정에 대한 자세한 내용은 [소스 리포지토리 파일 참조](workflows-sources-reference-files.md) 및 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md)를 참조하세요.
해당 UI: 구성 탭/**GitHub Actions YAML**
# 컴퓨팅 및 런타임 이미지 구성
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
```
# 워크플로에 소스 리포지토리 연결
*입력 소스*라고도 하는 *소스*는 [워크플로 작업](workflows-actions.md)이 작업을 수행하는 데 필요한 파일을 얻기 위해 연결되는 소스 리포지토리입니다. 예를 들어 워크플로 작업은 애플리케이션을 빌드하기 위해 애플리케이션 소스 파일을 얻기 위해 소스 리포지토리에 연결할 수 있습니다.
CodeCatalyst 워크플로는 다음 소스를 지원합니다.
+ CodeCatalyst 소스 리포지토리 - 자세한 내용은 [CodeCatalyst의 소스 리포지토리로 코드 저장 및 협업소스 리포지토리를 사용하여 코드 저장 및 협업](source.md) 섹션을 참조하세요.
+ GitHub 리포지토리, Bitbucket 리포지토리 및 GitLab 프로젝트 리포지토리 - 자세한 내용은 [CodeCatalyst에서 확장 프로그램이 있는 프로젝트에 기능 추가확장 프로그램이 있는 프로젝트에 기능 추가](extensions.md) 섹션을 참조하세요.
**Topics**
+ [워크플로 파일의 소스 리포지토리 지정](workflows-sources-specify-workflow-def.md)
+ [워크플로 작업의 소스 리포지토리 지정](workflows-sources-specify-action.md)
+ [소스 리포지토리 파일 참조](workflows-sources-reference-files.md)
+ ['BranchName' 및 'CommitId' 변수](workflows-sources-variables.md)
# 워크플로 파일의 소스 리포지토리 지정
다음 지침에 따라 워크플로 정의 파일을 저장할 CodeCatalyst 소스 리포지토리를 지정합니다. GitHub 리포지토리, Bitbucket 리포지토리 또는 GitLab 프로젝트 리포지토리를 지정하려면 대신 [CodeCatalyst에서 확장 프로그램이 있는 프로젝트에 기능 추가확장 프로그램이 있는 프로젝트에 기능 추가](extensions.md)를 참조하세요.
워크플로 정의 파일이 있는 소스 리포지토리는 `WorkflowSource` 레이블로 식별됩니다.
**참고**
워크플로 정의 파일을 처음 커밋할 때 워크플로 정의 파일이 있는 소스 리포지토리를 지정합니다. 이 커밋 후에는 리포지토리와 워크플로 정의 파일이 영구적으로 서로 연결됩니다. 초기 커밋 후 리포지토리를 변경하는 유일한 방법은 다른 리포지토리에서 워크플로를 다시 만드는 것입니다.
**워크플로 정의 파일을 저장할 소스 리포지토리 지정**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택하여 워크플로를 생성합니다. 자세한 내용은 [워크플로 생성](workflows-create-workflow.md) 섹션을 참조하세요.
워크플로 생성 과정에서 워크플로 정의 파일을 저장할 CodeCatalyst 리포지토리, 브랜치 및 폴더를 지정할 수 있습니다.
# 워크플로 작업의 소스 리포지토리 지정
다음 지침에 따라 워크플로 작업에 사용할 소스 리포지토리를 지정합니다. 시작 시 작업은 구성된 소스 리포지토리에 있는 파일을 아티팩트로 번들링하고, 작업이 실행 중인 [런타임 환경 Docker 이미지](build-images.md)로 아티팩트를 다운로드한 다음 다운로드한 파일을 사용하여 처리를 완료합니다.
**참고**
현재 워크플로 작업 내에서 소스 리포지토리는 워크플로 정의 파일이 있는 소스 리포지토리(`.codecatalyst/workflows/` 디렉터리 또는 그 하위 디렉터리 중 하나)를 하나만 지정할 수 있습니다. 이 소스 리포지토리는 `WorkflowSource` 레이블로 표시됩니다.
------
#### [ Visual ]
**작업이 사용할 소스 리포지토리 지정(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 소스를 지정하려는 작업을 선택합니다.
1. **입력**을 선택합니다.
1. **소스 - 선택 사항**으로 다음을 수행합니다.
작업에 필요한 소스 리포지토리를 나타내는 레이블을 지정합니다. 현재 지원되는 유일한 레이블은 워크플로 정의 파일이 저장되는 소스 리포지토리를 나타내는 `WorkflowSource`입니다.
소스를 생략하는 경우 `action-name/Inputs/Artifacts` 아래에 하나 이상의 입력 아티팩트를 지정해야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**작업이 사용할 소스 리포지토리 지정(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Inputs:
Sources:
- WorkflowSource
```
자세한 내용은 작업에 대한 [워크플로 YAML 정의](workflow-reference.md)의 `Sources` 속성 설명을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 소스 리포지토리 파일 참조
소스 리포지토리에 있는 파일이 있고 워크플로 작업 중 하나에서 이러한 파일을 참조해야 하는 경우 다음 절차를 완료하세요.
**참고**
또한 [아티팩트의 파일 참조](workflows-working-artifacts-refer-files.md) 섹션도 참조하세요.
**소스 리포지토리에 저장된 파일 참조**
+ 파일을 참조하려는 작업에서 다음과 유사한 코드를 추가합니다.
```
Actions:
My-action:
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- run: cd my-app && cat file1.jar
```
이전 코드에서 작업은 `WorkflowSource` 소스 리포지토리 루트의 `my-app` 디렉터리에서 `file1.jar` 파일을 찾아 표시합니다.
# 'BranchName' 및 'CommitId' 변수
CodeCatalyst 소스는 워크플로가 실행될 때 `BranchName` 및 `CommitId` 변수를 생성하고 설정합니다. 이를 *사전 정의된 변수*라고 합니다. 이러한 변수에 대한 자세한 내용은 다음 표를 참조하세요.
워크플로에서 이러한 변수를 참조하는 방법에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
| Key(키) | 값 |
| --- | --- |
| CommitId | 워크플로 실행이 시작된 시점의 리포지토리 상태를 나타내는 커밋 ID입니다. 예시: `example3819261db00a3ab59468c8b` 또한 [예시: 'CommitId' 사전 정의된 변수 참조](workflows-predefined-examples.md#workflows-working-with-variables-ex-refer-action) 섹션도 참조하세요. |
| BranchName | 워크플로 실행이 시작된 브랜치의 이름입니다. 예: `main`, `feature/branch`, `test-LiJuan` 또한 [예시: 'BranchName' 사전 정의된 변수 참조](workflows-predefined-examples.md#workflows-working-with-variables-ex-branch) 섹션도 참조하세요. |
# 워크플로에 패키지 리포지토리 연결
*패키지*는 소프트웨어와 모든 종속성을 해결하고 소프트웨어를 설치하는 데 필요한 메타데이터를 포함한 번들입니다. CodeCatalyst는 npm 패키지 형식을 지원합니다.
패키지는 다음으로 구성됩니다.
+ 이름(예: `webpack`는 널리 사용되는 npm 패키지의 이름)
+ 선택적 [네임스페이스](packages-concepts.md#packages-concepts-package-namespaces)(예: `@types/node`의 `@types`)
+ [버전](packages-concepts.md#packages-concepts-package-versions) 세트(예: `1.0.0`, `1.0.1`, `1.0.2`)
+ 패키지 수준 메타데이터(예: npm dist 태그)
CodeCatalyst에서는 워크플로에서 CodeCatalyst 패키지 리포지토리에 패키지를 게시하고 패키지를 사용할 수 있습니다. CodeCatalyst 패키지 리포지토리로 빌드 또는 테스트 작업을 구성하여 지정된 리포지토리에서 패키지를 푸시 및 풀링하도록 작업의 npm 클라이언트를 자동으로 구성할 수 있습니다.
패키지에 대한 자세한 내용은 [CodeCatalyst에서 소프트웨어 패키지 게시 및 공유](packages.md) 섹션을 참조하세요.
**참고**
현재 빌드 및 테스트 작업은 CodeCatalyst 패키지 리포지토리를 지원합니다.
**Topics**
+ [자습서: 패키지 리포지토리에서 가져오기](packages-tutorial.md)
+ [워크플로에서 CodeCatalyst 패키지 리포지토리 지정](workflows-package-specify-action.md)
+ [워크플로 작업에서 권한 부여 토큰 사용](workflows-package-export-token.md)
+ [예시: 워크플로의 패키지 리포지토리](workflows-working-packages-ex.md)
# 자습서: 패키지 리포지토리에서 가져오기
이 자습서에서는 [CodeCatalyst 패키지 리포지토리](packages-concepts.md#packages-concepts-repository)에서 종속성을 가져오는 애플리케이션을 실행하는 워크플로를 생성하는 방법을 알아봅니다. 이 애플리케이션은 CodeCatalyst 로그에 'Hello World' 메시지를 출력하는 간단한 Node.js 앱입니다. 이 애플리케이션에는 단일 종속성으로 [lodash](https://www.npmjs.com/package/lodash) npm 패키지가 있습니다. `lodash` 패키지는 `hello-world` 문자열을 `Hello World`로 변환하는 데 사용됩니다. 이 패키지의 버전 4.17.20을 사용합니다.
애플리케이션 및 워크플로를 설정한 후 CodeCatalyst가 퍼블릭 외부 레지스트리([npmjs.com](https://www.npmjs.com/))에서 CodeCatalyst 패키지 리포지토리로 `lodash`의 추가 버전을 가져오는 것을 차단하도록 구성합니다. 그런 다음 `lodash`의 추가 버전이 성공적으로 차단되었는지 테스트합니다.
이 자습서를 마치면 워크플로가 CodeCatalyst 내부 및 외부의 패키지 리포지토리와 상호 작용하는 방식을 잘 이해하여 패키지를 검색할 수 있습니다. 또한 npm, 패키지 리포지토리, 워크플로 및 애플리케이션의 `package.json` 파일 간에 발생하는 백그라운드 상호 작용도 이해해야 합니다.
**Topics**
+ [사전 조건](#packages-tutorial-prereqs)
+ [1단계: 소스 리포지토리 생성](#packages-tutorial-source-repo)
+ [2단계: CodeCatalyst 및 게이트웨이 패키지 리포지토리 생성](#packages-tutorial-package-repo)
+ [3단계: 'Hello World' 애플리케이션 생성](#packages-tutorial-create-app)
+ [4단계: 'Hello World'를 실행하는 워크플로 생성](#packages-tutorial-create-workflow)
+ [5단계: 워크플로 확인](#packages-tutorial-verify)
+ [6단계: npmjs.com 가져오기 차단](#packages-tutorial-block)
+ [7단계: 차단 기능 테스트](#packages-tutorial-test-block)
+ [정리](#packages-tutorial-cleanup)
## 사전 조건
시작하기 전:
+ CodeCatalyst **스페이스**가 필요합니다. 자세한 내용은 [스페이스 생성](spaces-create.md) 섹션을 참조하세요.
+ CodeCatalyst 스페이스에는 다음과 같은 빈 프로젝트가 필요합니다.
```
codecatalyst-package-project
```
**처음부터 시작** 옵션을 사용하여 이 프로젝트를 생성합니다.
자세한 내용은 [Amazon CodeCatalyst에서 빈 프로젝트 생성](projects-create.md#projects-create-empty) 단원을 참조하십시오.
## 1단계: 소스 리포지토리 생성
이 단계에서는 CodeCatalyst에 소스 리포지토리를 생성합니다. 이 리포지토리에는 `index.js` 및 `package.json` 파일과 같은 자습서의 소스 파일이 저장됩니다.
소스 리포지토리에 대한 자세한 정보는 [소스 리포지토리 생성](source-repositories-create.md) 섹션을 참조하세요.
**소스 리포지토리를 생성하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. `codecatalyst-package-project` 프로젝트로 이동합니다.
1. 탐색 창에서 **코드**를 선택한 다음 **소스 리포지토리**를 선택합니다.
1. **리포지토리 추가**를 선택하고 **리포지토리 생성**을 선택합니다.
1. **리포지토리 이름**에 다음과 같이 입력합니다.
```
hello-world-app
```
1. **생성(Create)**을 선택합니다.
## 2단계: CodeCatalyst 및 게이트웨이 패키지 리포지토리 생성
이 단계에서는 CodeCatalyst 프로젝트에서 패키지 리포지토리를 생성하고 이를 게이트웨이 리포지토리와 CodeCatalyst 프로젝트에 연결합니다. 나중에 자습서의 종속성인 `lodash`를 npmjs.com에서 두 리포지토리로 가져옵니다.
게이트웨이 리포지토리는 CodeCatalyst의 패키지 리포지토리를 퍼블릭 npmjs.com 연결하는 '접착제' 역할을 합니다.
패키지 리포지토리에 대한 자세한 내용은 [CodeCatalyst에서 소프트웨어 패키지 게시 및 공유](packages.md) 섹션을 참조하세요.
**참고**
이 자습서에서는 *CodeCatalyst 패키지 리포지토리* 및 *게이트웨이 리포지토리*라는 용어를 사용하여 다음 절차에서 CodeCatalyst에서 생성한 두 리포지토리를 참조합니다.
**CodeCatalyst 패키지 및 게이트웨이 리포지토리를 생성하려면**
1. 탐색 창에서 **패키지**를 선택합니다.
1. **리포지토리 생성**을 선택합니다.
1. **리포지토리 이름**에 다음과 같이 입력합니다.
```
codecatalyst-package-repository
```
1. **\$1 업스트림 리포지토리 선택**을 선택합니다.
1. **게이트웨이 리포지토리**를 선택합니다.
1. **npm-public-registry-gateway** 상자에서 **생성**을 선택합니다.
1. **선택**을 선택하세요.
1. **생성(Create)**을 선택합니다.
CodeCatalyst는 게이트웨이 리포지토리에 연결된 `codecatalyst-package-repository`라는 패키지 리포지토리를 생성합니다. 게이트웨이 리포지토리는 npmjs.com 레지스트리에 연결됩니다.
## 3단계: 'Hello World' 애플리케이션 생성
이 단계에서는 'Hello World' Node.js 애플리케이션을 생성하고 해당 종속성(`lodash`)을 게이트웨이 및 CodeCatalyst 패키지 리포지토리로 가져옵니다.
애플리케이션을 생성하려면 Node.js와 연결된 `npm` 클라이언트가 설치된 개발 시스템이 필요합니다.
이 자습서에서는 CodeCatalyst 개발 환경을 개발 시스템으로 사용할 것이라고 가정합니다. CodeCatalyst 개발 환경을 사용할 필요는 없지만, 깨끗한 작업 환경을 제공하고 Node.js 및 `npm`가 사전 설치되어 있으며 자습서를 완료하고나서 쉽게 삭제할 수 있으므로 사용하는 것이 좋습니다. CodeCatalyst 개발 환경에 대한 자세한 내용은 [개발 환경 생성](devenvironment-create.md) 섹션을 참조하세요.
다음 지침을 사용하여 CodeCatalyst 개발 환경을 시작하고 이를 사용하여 'Hello World' 애플리케이션을 생성합니다.
**CodeCatalyst 개발 환경을 시작하려면**
1. 탐색 창에서 **코드**를 선택한 다음 **개발 환경**을 선택합니다.
1. 상단 근처에서 **개발 환경 생성**을 선택한 다음 **AWS Cloud9 (브라우저에서)**를 선택합니다.
1. **리포지토리**가 `hello-world-app`로 설정되어 있고 **기존 브랜치**가 `main`로 설정되어 있는지 확인합니다. **생성(Create)**을 선택합니다.
개발 환경이 새 브라우저 탭에서 시작되고 리포지토리(`hello-world-app`)가 복제됩니다.
1. 두 CodeCatalyst 브라우저 탭을 모두 열어 두고 다음 절차로 이동합니다.
**'Hello World' Node.js 애플리케이션을 생성하려면**
1. 개발 환경으로 이동합니다.
1. 터미널 프롬프트에서 `hello-world-app` 소스 리포지토리 루트 디렉터리로 변경합니다.
```
cd hello-world-app
```
1. Node.js 프로젝트 초기화:
```
npm init -y
```
초기화는 `hello-world-app`의 루트 디렉터리에 `package.json` 파일을 생성합니다.
1. 개발 환경의 npm 클라이언트를 CodeCatalyst 패키지 리포지토리에 연결합니다.
1. CodeCatalyst 콘솔로 전환합니다.
1. 탐색 창에서 **패키지**를 선택합니다.
1. `codecatalyst-package-repository`을 선택합니다.
1. **리포지토리에 연결**을 선택합니다.
1. **토큰 생성**을 선택합니다. 개인 액세스 토큰(PAT)이 생성됩니다.
1. **복사**를 선택하여 해당 명령을 복사합니다.
1. 개발 환경으로 전환합니다.
1. `hello-world-app` 디렉터리에 있는지 확인합니다.
1. 해당 명령을 붙여넣습니다. 다음처럼 보일 것입니다.
```
npm set registry=https://packages.us-west-2.codecatalyst.aws/npm/ExampleCompany/codecatalyst-package-project/codecatalyst-package-repository/ --location project
npm set //packages.us-west-2.codecatalyst.aws/npm/ExampleCompany/codecatalyst-package-project/hello-world-app/:_authToken=username:token-secret
```
1. `lodash` 버전 4.17.20 가져오기:
```
npm install lodash@v4.17.20 --save --save-exact
```
npm은 다음 위치에서 `lodash` 버전 4.17.20을 다음 순서로 찾습니다.
+ 개발 환경. 여기에서는 찾을 수 없습니다.
+ CodeCatalyst 패키지 리포지토리. 여기에서는 찾을 수 없습니다.
+ 게이트웨이 리포지토리. 여기에서는 찾을 수 없습니다.
+ npmjs.com. 여기에서 발견합니다.
npm은 `lodash`를 게이트웨이 리포지토리, CodeCatalyst 패키지 리포지토리 및 개발 환경으로 가져옵니다.
**참고**
4단계에서 npm 클라이언트를 CodeCatalyst 패키지 리포지토리에 연결하지 않았다면, npm은 `lodash`를 npmjs.com에서 직접 가져오고 두 리포지토리로는 해당 패키지를 가져오지 않았을 것입니다.
또한 npm은 `lodash` 종속성을 사용하여 `package.json` 파일을 업데이트하고 `lodash` 및 모든 종속성을 포함하는 `node_modules` 디렉터리를 생성합니다.
1. 개발 환경으로 `lodash`를 성공적으로 가져왔는지 테스트입니다. 입력:
```
npm list
```
가져오기가 성공했음을 나타내는 다음 메시지가 나타납니다.
```
`-- lodash@4.17.20
```
1. (선택 사항) `hello-world-app/package.json` 를 열고 ***빨간색으로 굵게*** 표시된 선이 추가되었는지 확인합니다.
```
{
"name": "hello-world-app",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC",
dependencies": {
"lodash": "4.17.20"
}
}
```
1. `/hello-world-app`에서 다음 콘텐츠로 `index.js` 파일을 생성합니다.
**작은 정보**
개발 환경에서 측면 탐색을 사용하여 이 파일을 생성할 수 있습니다.
```
// Importing lodash library
const _ = require('lodash');
// Input string
const inputString = 'hello-world';
// Transforming the string using lodash
const transformedString = _.startCase(inputString.replace('-', ' '));
// Outputting the transformed string to the console
console.log(transformedString);
```
**게이트웨이 및 CodeCatalyst 패키지 리포지토리로 'lodash'를 가져왔는지 테스트하려면**
1. CodeCatalyst 콘솔로 전환합니다.
1. 탐색 창에서 **패키지**를 선택합니다.
1. **npm-public-registry-gateway**를 선택합니다.
1. `lodash`가 표시되는지 확인합니다. **최신 버전** 열은 `4.17.20`을 나타냅니다.
1. `codecatalyst-package-repository`에 대해 이 절차를 반복합니다. 가져온 패키지를 보려면 브라우저 창을 새로 고쳐야 할 수 있습니다.
**개발 환경에서 'Hello World'를 테스트하려면**
1. 개발 환경으로 전환합니다.
1. `hello-world-app` 디렉터리에 아직 있는지 확인한 다음 애플리케이션을 실행합니다.
```
node index.js
```
`Hello World` 메시지가 나타납니다. Node.js가 이전 단계에서 개발 환경에 다운로드한 `lodash` 패키지를 사용하여 애플리케이션을 실행했습니다.
**'node\$1modules' 디렉터리를 무시하고 'Hello World'를 커밋하려면**
1. `node_modules` 디렉터리를 무시합니다. 입력:
```
echo "node_modules/" >> .gitignore
```
이 디렉터리를 커밋하지 않는 것이 가장 좋습니다. 또한 이 디렉터리를 커밋하면 이 자습서의 이후 단계에 방해가 됩니다.
1. 추가, 커밋 및 푸시:
```
git add .
git commit -m "add the Hello World application"
git push
```
'Hello World' 애플리케이션 및 프로젝트 파일이 소스 리포지토리에 추가됩니다.
## 4단계: 'Hello World'를 실행하는 워크플로 생성
이 단계에서는 `lodash` 종속성을 사용하여 'Hello World' 애플리케이션을 실행하는 워크플로를 생성합니다. 워크플로에는 단일 *작업* 또는 `RunHelloWorldApp`라는 작업이 포함됩니다. 이 `RunHelloWorldApp` 작업에는 다음과 같은 주목할 만한 명령 및 섹션이 포함됩니다.
+ **`Packages`**
이 섹션에서는 `npm install`를 실행할 때 작업이 연결해야 하는 CodeCatalyst 패키지 리포지토리의 이름을 나타냅니다.
+ **`- Run: npm install`**
이 명령은 `package.json` 파일에 지정된 종속성을 설치하도록 npm에 지시합니다. `package.json` 파일에 지정된 유일한 종속성은 `lodash`입니다. npm은 다음 위치에서 `lodash`를 찾습니다.
+ 작업을 실행하는 Docker 이미지. 여기에서는 찾을 수 없습니다.
+ CodeCatalyst 패키지 리포지토리. 여기에서 발견합니다.
npm이 `lodash`를 찾으면 작업을 실행하는 Docker 이미지로 가져옵니다.
+ **`- Run: npm list`**
이 명령은 해당 작업을 실행하는 Docker 이미지에 다운로드된 `lodash` 버전을 출력합니다.
+ **`- Run: node index.js`**
이 명령은 `package.json` 파일에 지정된 종속성을 사용하여 'Hello World' 애플리케이션을 실행합니다.
`RunHelloWorldApp` 작업은 워크플로 상단 근처의 `aws/build@v1` 식별자로 표시되는 빌드 작업입니다. 빌드 작업에 대한 자세한 내용은 [워크플로로 빌드하기](build-workflow-actions.md) 섹션을 참조하세요.
다음 지침을 사용하여 CodeCatalyst 패키지 리포지토리에서 `lodash` 종속성을 가져온 다음 'Hello World' 애플리케이션을 실행하는 워크플로를 생성합니다.
**워크플로 생성**
1. CodeCatalyst 콘솔로 전환합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. **워크플로 생성**을 선택합니다.
1. **소스 리포지토리**에서 `hello-world-app`을 선택합니다.
1. **브랜치**에서 `main`을 선택합니다.
워크플로 정의 파일은 선택한 소스 리포지토리 및 브랜치에 생성됩니다.
1. **생성(Create)**을 선택합니다.
1. 상단 근처에서 **YAML**을 선택합니다.
1. YAML 샘플 코드를 삭제합니다.
1. 다음 YAML 코드를 추가합니다.
```
Name: codecatalyst-package-workflow
SchemaVersion: "1.0"
# Required - Define action configurations.
Actions:
RunHelloWorldApp:
# Identifies the action. Do not modify this value.
Identifier: aws/build@v1
Compute:
Type: Lambda
Inputs:
Sources:
- WorkflowSource # This specifies your source repository.
Configuration:
Steps:
- Run: npm install
- Run: npm list
- Run: node index.js
Container: # This specifies the Docker image that runs the action.
Registry: CODECATALYST
Image: CodeCatalystLinuxLambda_x86_64:2024_03
Packages:
NpmConfiguration:
PackageRegistries:
- PackagesRepository: codecatalyst-package-repository
```
앞의 코드에서 *codecatalyst-package-repository*를 [2단계: CodeCatalyst 및 게이트웨이 패키지 리포지토리 생성](#packages-tutorial-package-repo)에서 생성한 CodeCatalyst 패키지 리포지토리의 이름으로 바꿉니다.
이러한 파일의 속성에 대한 자세한 내용은 [빌드 및 테스트 작업 YAML](build-action-ref.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 YAML 코드가 유효한지 확인하려면 **검증**을 선택합니다.
1. **커밋**을 선택합니다.
1. **워크플로 커밋** 대화 상자에서 다음을 입력합니다.
1. **워크플로 파일 이름**의 경우 기본값인 `codecatalyst-package-workflow`를 유지합니다.
1. **커밋 메시지**에 다음을 입력합니다.
```
add initial workflow file
```
1. **리포지토리**에서 **hello-world-app**를 선택합니다.
1. **브랜치 이름**에서 **기본**을 선택합니다.
1. **커밋**을 선택합니다.
이제 워크플로를 생성했습니다.
**해당 워크플로를 실행하려면**
1. 방금 생성한 워크플로(`codecatalyst-package-workflow`) 옆에 **작업**을 선택한 다음 **실행**을 선택합니다.
워크플로 실행이 시작됩니다.
1. 상단의 녹색 알림에서 오른쪽의 실행에 대한 링크를 선택합니다. 링크는 `View Run-1234`와 같습니다.
실행을 시작한 사람과 **RunHelloWorldApp** 작업을 보여주는 워크플로 다이어그램이 나타납니다.
1. **RunHelloWorldApp** 작업 상자를 선택하여 작업의 진행 상황을 확인합니다.
1. 실행이 완료되면 [5단계: 워크플로 확인](#packages-tutorial-verify)로 이동합니다.
## 5단계: 워크플로 확인
이 단계에서는 워크플로가 `lodash` 종속성으로 'Hello World' 애플리케이션을 성공적으로 실행했는지 확인합니다.
**'Hello World' 애플리케이션이 종속성을 사용하여 실행되었는지 확인하려면**
1. 워크플로 다이어그램에서 **RunHelloWorldApp** 상자를 선택합니다.
로그 메시지 목록이 나타납니다.
1. `node index.js` 로그 메시지를 확장합니다.
다음 메시지가 나타납니다.
```
[Container] 2024/04/24 21:15:41.545650 Running command node index.js
Hello World
```
`Hello Word`(`hello-world` 대신)이 나타나면 `lodash` 종속성이 성공적으로 사용되었음을 나타냅니다.
1. `npm list` 로그를 확장합니다.
다음과 비슷한 메시지가 나타납니다.
```
└── lodash@4.17.20
```
이 메시지는 `lodash` 버전 4.17.20이 워크플로 작업을 실행하는 Docker 이미지에 다운로드되었음을 나타냅니다.
## 6단계: npmjs.com 가져오기 차단
이제 게이트웨이 및 CodeCatalyst 패키지 리포지토리에 `lodash` 버전 4.17.20이 존재하므로 다른 버전 가져오기를 차단할 수 있습니다. 차단하면 악성 코드가 포함될 수 있는 `lodash`의 이후(또는 이전) 버전을 실수로 가져오는 일을 방지합니다. 자세한 내용은 [패키지 원본 제어 편집](package-origin-controls.md) 및 [종속성 대체 공격](package-origin-controls.md#dependency-substitution-attacks) 섹션을 참조하세요.
다음 지침에 따라 게이트웨이 리포지토리로 `lodash` 가져오기를 차단합니다. 게이트웨이에서 패키지를 차단하면 다운스트림 위치에서도 차단됩니다.
**게이트웨이 리포지토리로의 가져오기를 차단하려면**
1. 탐색 창에서 **패키지**를 선택합니다.
1. **npm-publish-registry-gateway**를 선택합니다.
1. `lodash`을 선택합니다.
1. 상단 근처에서 **원본 제어**를 선택합니다.
1. **업스트림**에서 **차단**을 선택합니다.
1. **저장**을 선택합니다.
이제 npmjs.com에서 게이트웨이 리포지토리(및 다운스트림 리포지토리 및 컴퓨터)로의 가져오기를 차단했습니다.
## 7단계: 차단 기능 테스트
이 섹션에서는 [6단계: npmjs.com 가져오기 차단](#packages-tutorial-block)에서 설정한 차단이 작동하는지 확인합니다. 게이트웨이 리포지토리에서 사용할 수 있는 버전인 4.17.2**0** `lodash` 대신 버전 4.17.2**1**을 요청하도록 'Hello World'를 구성하는 것으로 시작합니다. 그런 다음 애플리케이션이 nmpjs.com 버전 4.17.21을 가져올 수 없는지 확인하며, 이는 차단이 성공했음을 나타냅니다. 최종 테스트에서는 게이트웨이 리포지토리로의 가져오기 차단을 해제하고, 애플리케이션이 `lodash`의 버전 4.17.21을 성공적으로 가져올 수 있는지 확인합니다.
다음 절차 세트를 사용하여 차단 기능을 테스트합니다.
**시작하기 전 준비 사항**
1. 개발 환경으로 전환합니다.
1. CodeCatalyst 콘솔을 사용하여 이전에 생성한 `codecatalyst-package-workflow.yaml` 파일을 가져옵니다.
```
git pull
```
**'lodash' 버전 4.17.21을 요청하도록 'Hello World'를 구성하려면**
1. `/hello-world-app/package.json`를 엽니다.
1. ***빨간색으로 굵게*** 표시된 내용과 같이 `lodash` 버전을 4.17.21로 변경합니다.
```
{
"name": "hello-world-app",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"lodash": "4.17.21"
}
}
```
이제 `package.json` 파일의 버전(4.17.21)과 게이트웨이 및 CodeCatalyst 패키지 리포지토리의 버전(4.17.20)이 일치하지 않습니다.
1. 추가, 커밋 및 푸시:
```
git add .
git commit -m "update package.json to use lodash 4.17.21"
git push
```
**'Hello World'가 'lodash' 버전 4.17.21을 가져올 수 없는지 테스트하려면**
1. 버전이 불일치하는 워크플로를 실행합니다.
1. CodeCatalyst 콘솔로 전환합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. `codecatalyst-package-workflow` 옆에 **작업**을 선택한 후 **실행**을 선택합니다.
npm은 `package.json`에서 종속성을 찾고 'Hello World'에서 `lodash`의 버전 4.17.21이 필요함을 확인합니다. npm은 다음 위치에서 다음 순서로 종속성을 찾습니다.
+ 작업을 실행하는 Docker 이미지. 여기에서는 찾을 수 없습니다.
+ CodeCatalyst 패키지 리포지토리. 여기에서는 찾을 수 없습니다.
+ 게이트웨이 리포지토리. 여기에서는 찾을 수 없습니다.
+ npmjs.com. 여기에서 발견합니다.
npm이 npmjs.com에서 버전 4.17.21을 찾은 후 게이트웨이 리포지토리로 가져오려고 시도하지만 `lodash`의 가져오기를 차단하도록 게이트웨이를 설정했으므로 가져오기가 발생하지 않습니다.
가져오기가 발생하지 않으므로 워크플로가 실패합니다.
1. 워크플로가 실패했는지 확인합니다.
1. 상단의 녹색 알림에서 오른쪽의 실행에 대한 링크를 선택합니다. 링크는 `View Run-2345`와 같습니다.
1. 워크플로 다이어그램에서 **RunHelloWorldApp** 상자를 선택합니다.
1. `npm install` 로그 메시지를 확장합니다.
다음 메시지가 나타납니다.
```
[Container] 2024/04/25 17:20:34.995591 Running command npm install
npm ERR! code ETARGET
npm ERR! notarget No matching version found for lodash@4.17.21.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.
npm ERR! A complete log of this run can be found in: /tmp/.npm/_logs/2024-05-08T22_03_26_493Z-debug-0.log
```
오류는 버전 4.17.21을 찾을 수 없음을 나타냅니다. 이는 차단했기 때문에 나타나는 것으로 봅니다.
**npmjs.com에서 가져오기 차단을 해제하려면**
1. 탐색 창에서 **패키지**를 선택합니다.
1. **npm-publish-registry-gateway**를 선택합니다.
1. `lodash`을 선택합니다.
1. 상단 근처에서 **원본 제어**를 선택합니다.
1. **업스트림**에서 **허용**을 선택합니다.
1. **저장**을 선택합니다.
이제 `lodash`의 가져오기가 차단 해제됩니다.
이제 워크플로에서 `lodash`의 버전 4.17.21을 가져올 수 있습니다.
**npmjs.com에서 가져오기가 차단 해제되었는지 테스트하려면**
1. 워크플로를 다시 실행합니다. 이제 4.17.21의 가져오기가 작동하므로 이번에는 워크플로가 성공해야 합니다. 해당 워크플로를 실행하려면:
1. **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. `codecatalyst-package-workflow` 옆의 **작업**을 선택하고 **실행**을 선택합니다.
1. 상단의 녹색 알림에서 오른쪽의 실행에 대한 링크를 선택합니다. 링크는 `View Run-3456`와 같습니다.
실행을 시작한 사람과 **RunHelloWorldApp** 작업을 보여주는 워크플로 다이어그램이 나타납니다.
1. **RunHelloWorldApp** 작업 상자를 선택하여 작업의 진행 상황을 확인합니다.
1. `npm list` 로그 메시지를 확장하고 다음과 유사한 메시지가 나타나는지 확인합니다.
```
└── lodash@4.17.21
```
이 메시지는 `lodash` 버전 4.17.21이 다운로드되었음을 나타냅니다.
1. 버전 4.17.21을 CodeCatalyst 및 게이트웨이 리포지토리로 가져왔는지 확인합니다.
1. 탐색 창에서 **패키지**를 선택합니다.
1. **npm-public-registry-gateway**를 선택합니다.
1. `lodash`를 찾아 버전이 `4.17.21`인지 확인합니다.
**참고**
버전 4.17.20은 이 페이지에 나열되어 있지 않지만 `lodash`를 선택한 다음 상단에서 **버전**을 선택하여 찾을 수 있습니다.
1. 이 단계를 반복하여 버전 4.17.21을 `codecatalyst-package-repository`로 가져왔는지 확인합니다.
## 정리
요금이 부과되지 않도록 이 자습서에서 사용하는 파일과 서비스를 정리합니다.
**패키지 자습서를 정리하려면**
1. `codecatalyst-package-project`를 삭제합니다.
1. CodeCatalyst 콘솔에서 아직 프로젝트로 이동하지 않은 경우, `codecatalyst-package-project` 프로젝트로 이동합니다.
1. 탐색 창에서 **프로젝트 설정**을 선택합니다.
1. **프로젝트 삭제**를 선택하고 **delete**를 입력한 다음 **프로젝트 삭제**를 선택합니다.
CodeCatalyst는 소스, 게이트웨이 및 CodeCatalyst 패키지 리포지토리를 포함한 모든 프로젝트 리소스를 삭제합니다. 개발 환경도 삭제됩니다.
1. PAT 토큰을 삭제합니다.
1. 오른쪽에서 사용자 이름을 선택한 다음 **내 설정**을 선택합니다.
1. **개인 액세스 토큰**에서 이 자습서에서 생성한 토큰을 선택하고 **삭제**를 선택합니다.
이 자습서에서는 CodeCatalyst 패키지 리포지토리에서 종속성을 가져오는 애플리케이션을 실행하는 워크플로를 생성하는 방법을 배웠습니다. 또한 패키지가 게이트웨이 및 CodeCatalyst 패키지 리포지토리로 들어오는 것을 차단 및 차단 해제하는 방법을 배웠습니다.
# 워크플로에서 CodeCatalyst 패키지 리포지토리 지정
CodeCatalyst에서는 워크플로에서 빌드 및 테스트 작업에 CodeCatalyst 패키지 리포지토리를 추가할 수 있습니다. 패키지 리포지토리는 npm과 같은 패키지 형식으로 구성해야 합니다. 선택한 패키지 리포지토리에 대해 일련의 범위를 포함하도록 선택할 수도 있습니다.
다음 지침에 따라 워크플로 작업에 사용할 패키지 구성을 지정합니다.
------
#### [ Visual ]
**작업에서 사용할 패키지 구성 지정(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 패키지 리포지토리로 구성할 **빌드** 또는 **테스트** 작업을 선택합니다.
1. **패키지**를 선택합니다.
1. **구성 추가** 드롭다운 메뉴에서 워크플로 작업에 사용할 패키지 구성을 선택합니다.
1. **패키지 리포지토리 추가**를 선택합니다.
1. **패키지 리포지토리** 드롭다운 메뉴에서 작업을 사용할 CodeCatalyst *패키지 리포지토리*의 이름을 지정합니다.
패키지 리포지토리에 대한 자세한 내용은 [패키지 리포지토리](packages-concepts.md#packages-concepts-repository) 섹션을 참조하세요.
1. (선택 사항) **범위 - 선택 사항**에서 패키지 레지스트리에 정의할 *범위* 순서를 지정합니다.
범위를 정의할 때 지정된 패키지 리포지토리는 나열된 모든 범위에 대한 레지스트리로 구성됩니다. 해당 범위의 패키지가 npm 클라이언트를 통해 요청되면 기본값 대신 해당 리포지토리를 사용합니다. 각 범위 이름 앞에는 ‘@’ 접두사를 붙여야 합니다.
`Scopes` 생략 시 지정된 패키지 리포지토리가 작업에 사용되는 모든 패키지의 기본 레지스트리로 구성됩니다.
범위에 대한 자세한 내용은 [패키지 네임스페이스](packages-concepts.md#packages-concepts-package-namespaces) 및 [범위 지정 패키지](https://docs.npmjs.com/cli/v10/using-npm/scope) 섹션을 참조하세요.
1. **추가**를 선택합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**작업이 사용할 패키지 구성 지정(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. **빌드** 또는 **테스트** 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Configuration:
Packages:
NpmConfiguration:
PackageRegistries:
- PackagesRepository: package-repository
Scopes:
- "@scope"
```
자세한 내용은 작업에 대한 [빌드 및 테스트 작업 YAML](build-action-ref.md)의 `Packages` 속성 설명을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 워크플로 작업에서 권한 부여 토큰 사용
워크플로 작업에서 제공하는 토큰을 사용하여 패키지 관리자가 CodeCatalyst 패키지 리포지토리로 인증하도록 수동으로 구성할 수 있습니다. CodeCatalyst는 이 토큰을 작업에서 참조할 수 있도록 환경 변수로 사용할 수 있도록 합니다.
| 환경 변수 | 값 |
| --- | --- |
| CATALYST\$1MACHINE\$1RESOURCE\$1NAME | 권한 부여 토큰의 사용자 ID입니다. |
| CATALYST\$1PACKAGES\$1AUTHORIZATION\$1TOKEN | 권한 부여 토큰의 값입니다. |
**참고**
이러한 환경 변수는 권한 부여 토큰을 내보내도록 작업을 구성한 경우에만 채워집니다.
다음 지침에 따라 워크플로 작업과 함께 권한 부여 토큰을 사용합니다.
------
#### [ Visual ]
**작업에서 내보낸 권한 부여 토큰 사용(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 패키지 리포지토리로 구성할 **빌드** 또는 **테스트** 작업을 선택합니다.
1. **패키지**를 선택합니다.
1. **권한 부여 토큰 내보내기**를 켭니다.
------
#### [ YAML ]
**작업에서 내보낸 권한 부여 토큰 사용(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. **빌드** 또는 **테스트** 작업에서 다음과 유사한 코드를 추가합니다.
```
Actions:
action-name:
Packages:
ExportAuthorizationToken: true
```
YAML의 `Steps` 섹션에서 `$CATALYST_MACHINE_RESOURCE_NAME` 및 `$CATALYST_PACKAGES_AUTHORIZATION_TOKEN` 환경 변수를 참조할 수 있습니다. 자세한 정보는 [예시: CodeCatalyst로 인증하도록 수동으로 `pip` 구성](workflows-working-packages-ex.md#workflows-working-packages-pypi-token) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 예시: 워크플로의 패키지 리포지토리
다음 예시에서는 워크플로 정의 파일의 패키지를 참조하는 방법을 보여줍니다.
**Topics**
+ [예시: `NpmConfiguration`을 사용하여 패키지 정의](#workflows-working-packages-ex-basic)
+ [예시: 기본 레지스트리 재정의](#workflows-working-packages-ex-overriding-registry)
+ [예시: 패키지 레지스트리의 범위 재정의](#workflows-working-packages-ex-overriding-scopes)
+ [예시: CodeCatalyst로 인증하도록 수동으로 `pip` 구성](#workflows-working-packages-pypi-token)
## 예시: `NpmConfiguration`을 사용하여 패키지 정의
다음 예시는 워크플로 정의 파일에서 `NpmConfiguration`를 사용하여 패키지를 정의하는 방법을 보여줍니다.
```
Actions:
Build:
Identifier: aws/build-beta@v1
Configuration:
Packages:
NpmConfiguration:
PackageRegistries:
- PackagesRepository: main-repo
- PackagesRepository: scoped-repo
Scopes:
- "@scope1"
```
이 예시에서는 npm 클라이언트를 다음과 같이 구성합니다.
```
default: main-repo
@scope1: scoped-repo
```
이 예시에서는 두 개의 리포지토리가 정의되어 있습니다. 기본 레지스트리는 범위 없이 정의되므로 기본 레지스트리는`main-repo`로 설정됩니다. 범위 `@scope1`은 `scoped-repo`에 대해 `PackageRegistries`에 구성됩니다.
## 예시: 기본 레지스트리 재정의
다음 예시에서는 기본 레지스트리를 재정의하는 방법을 보여줍니다.
```
NpmConfiguration:
PackageRegistries:
- PackagesRepository: my-repo-1
- PackagesRepository: my-repo-2
- PackagesRepository: my-repo-3
```
이 예시에서는 npm 클라이언트를 다음과 같이 구성합니다.
```
default: my-repo-3
```
여러 기본 리포지토리를 지정하는 경우 마지막 리포지토리가 우선합니다. 이 예시에서 나열된 마지막 리포지토리는 `my-repo-3`이며, 이는 npm이 `my-repo-3`에 연결된다는 것을 의미합니다. 이렇게 하면 리포지토리 `my-repo-1` 및 `my-repo-2`를 재정의합니다.
## 예시: 패키지 레지스트리의 범위 재정의
다음 예시에서는 패키지 레지스트리의 범위를 재정의하는 방법을 보여줍니다.
```
NpmConfiguration:
PackageRegistries:
- PackagesRepository: my-default-repo
- PackagesRepository: my-repo-1
Scopes:
- "@scope1"
- "@scope2"
- PackagesRepository: my-repo-2
Scopes:
- "@scope2"
```
이 예시에서는 npm 클라이언트를 다음과 같이 구성합니다.
```
default: my-default-repo
@scope1: my-repo-1
@scope2: my-repo-2
```
범위 재정의를 포함하면 마지막 리포지토리가 우선합니다. 이 예시에서 `@scope2` 범위가 `my-repo-2`에 대해 마지막으로 구성된 것은 `PackageRegistries`입니다. 이렇게 하면 `my-repo-1`에 대해 구성된 범위 `@scope2`가 재정의됩니다.
## 예시: CodeCatalyst로 인증하도록 수동으로 `pip` 구성
다음 예시에서는 빌드 작업에서 CodeCatalyst 권한 부여 환경 변수를 참조하는 방법을 보여줍니다.
```
Actions:
Build:
Identifier: aws/build@v1.0.0
Configuration:
Steps:
- Run: pip config set global.index-url https://$CATALYST_MACHINE_RESOURCE_NAME:$CATALYST_PACKAGES_AUTHORIZATION_TOKEN@codecatalyst.aws/pypi/my-space/my-project/my-repo/simple/
Packages:
ExportAuthorizationToken: true
```
# 워크플로를 사용하여 Lambda 함수 호출
이 섹션에서는 CodeCatalyst 워크플로를 사용하여 AWS Lambda 함수를 호출하는 방법을 설명합니다. 이렇게 하려면 워크플로에 **AWS Lambda 간접 호출** 작업을 추가해야 합니다. **AWS Lambda 간접 호출** 작업은 지정한 Lambda 함수를 호출합니다.
함수를 간접적으로 호출하는 것 외에도 **AWS Lambda 간접 호출** 작업은 Lambda 함수에서 수신한 응답 페이로드의 각 최상위 키를 [워크플로 출력 변수](workflows-working-with-variables.md)로 변환합니다. 그런 다음 후속 워크플로 작업에서 이러한 변수를 참조할 수 있습니다. 모든 최상위 키를 변수로 변환하지 않으려면 필터를 사용하여 정확한 키를 지정할 수 있습니다. 자세한 내용은 ['AWS Lambda 간접 호출' 작업 YAML](lam-invoke-action-ref.md)의 [ResponseFilters](lam-invoke-action-ref.md#lam.invoke.response.filters) 속성 설명을 참조하세요.
**Topics**
+ [이 작업을 사용해야 하는 경우](#lam-invoke-action-when-to-use)
+ ['AWS Lambda 호출' 작업에서 사용하는 런타임 이미지](#lam-invoke-action-runtime)
+ [예시: Lambda 함수를 간접적으로 호출합니다.](lam-invoke-action-example-workflow.md)
+ ['AWS Lambda 호출' 작업 추가](lam-invoke-action-add.md)
+ ['AWS Lambda 간접 호출' 변수](lam-invoke-action-variables.md)
+ ['AWS Lambda 간접 호출' 작업 YAML](lam-invoke-action-ref.md)
## 이 작업을 사용해야 하는 경우
Lambda 함수에 캡슐화되고 Lambda 함수에서 수행하는 워크플로에 기능을 추가하려면, 이 작업을 사용합니다.
예를 들어, 애플리케이션 빌드를 시작하기 전에 워크플로가 Slack 채널에 `Build started` 알림을 보내도록 할 수 있습니다. 이 경우, 워크플로에는 Lambda를 호출하여 Slack 알림을 보내는 **AWS Lambda 간접 호출** 작업과 애플리케이션을 빌드하는 [빌드 작업](build-add-action.md)이 포함됩니다.
또 다른 예로 워크플로가 배포되기 전에 워크플로에서 애플리케이션의 취약성 스캔을 수행하게 할 수 있습니다. 이 경우, 빌드 작업을 사용하여 애플리케이션을 빌드하고, **AWS Lambda 간접 호출** 작업을 사용하여 Lambda를 호출해 취약성을 스캔하고, 배포 작업을 사용하여 스캔한 애플리케이션을 배포합니다.
## 'AWS Lambda 호출' 작업에서 사용하는 런타임 이미지
**AWS Lambda 간접 호출** 작업은 [2022년 11월 이미지](build-images.md#build.previous-image)에서 실행됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 단원을 참조하십시오.
# 예시: Lambda 함수를 간접적으로 호출합니다.
다음 워크플로 예시에는 **AWS Lambda 간접 호출** 작업과 배포 작업이 포함됩니다. 워크플로는 배포가 시작되었음을 나타내는 Slack 알림을 전송한 다음 CloudFormation 템플릿을 AWS 사용하여에 애플리케이션을 배포합니다. 워크플로는 순차적으로 실행되는 다음 구성 요소로 구성됩니다.
+ **트리거** - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ **AWS Lambda 호출** 작업(`LambdaNotify`) - 트리거 시 이 작업은 지정된 AWS 계정 및 리전(`my-aws-account` 및 `us-west-2`)에서 `Notify-Start` Lambda 함수를 간접적으로 호출합니다. 간접 호출 시 Lambda 함수는 배포가 시작되었음을 나타내는 Slack 알림을 보냅니다.
+ ** CloudFormation 스택 배포** 작업(`Deploy`) - **AWS Lambda 호출** 작업이 완료되면 **스택 배포 CloudFormation ** 작업은 템플릿(`cfn-template.yml`)을 실행하여 애플리케이션 스택을 배포합니다. ** CloudFormation 스택 배포** 작업에 대한 자세한 내용은 섹션을 참조하세요[CloudFormation 스택 배포](deploy-action-cfn.md).
**참고**
다음 워크플로 예시는 설명을 돕기 위한 참고용이며 추가 구성 없이는 작동하지 않습니다.
**참고**
다음 YAML 코드에서 원하는 경우 `Connections:` 섹션을 생략할 수 있습니다. 이러한 섹션을 생략하는 경우 환경의 **기본 IAM 역할** 필드에 지정된 역할에 **AWS Lambda 스택 호출** 및 **배포 CloudFormation ** 작업에 필요한 권한 및 신뢰 정책이 포함되어 있는지 확인해야 합니다. 기본 IAM 역할이 있는 환경 설정에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요. 스택 **AWS Lambda 호출** 및 배포 작업에 필요한 권한 및 신뢰 정책에 대한 자세한 내용은 ['AWS Lambda 간접 호출' 작업 YAML](lam-invoke-action-ref.md) 및의 `Role` 속성 설명을 참조하세요['스 CloudFormation 택 배포' 작업 YAML](deploy-action-ref-cfn.md). ** CloudFormation **
```
Name: codecatalyst-lamda-invoke-workflow
SchemaVersion: 1.0
Triggers:
- Type: PUSH
Branches:
- main
Actions:
LambdaNotify:
Identifier: aws/lambda-invoke@v1
Environment:
Name: my-production-environment
Connections:
- Name: my-aws-account
Role: codecatalyst-lambda-invoke-role
Inputs:
Sources:
- WorkflowSource
Configuration:
Function: Notify-Start
AWSRegion: us-west-2
Deploy:
Identifier: aws/cfn-deploy@v1
Environment:
Name: my-production-environment
Connections:
- Name: my-aws-account
Role: codecatalyst-deploy-role
Inputs:
Sources:
- WorkflowSource
Configuration:
name: my-application-stack
region: us-west-2
role-arn: arn:aws:iam::111122223333:role/StackRole
template: ./cfn-template.yml
capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND
```
# 'AWS Lambda 호출' 작업 추가
다음 지침에 따라 워크플로에 **AWS Lambda 간접 호출** 작업을 추가합니다.
**사전 조건**
시작하기 전에 AWS Lambda 함수 및 연결된 Lambda 실행 역할이에서 준비되고 사용 가능한지 확인합니다 AWS. 자세한 내용은 *AWS Lambda 개발자 안내서*의 [Lambda 실행 역할](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) 주제를 참조하세요.
------
#### [ Visual ]
**시각적 편집기를 사용하여 'AWS Lambda 호출' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **AWS Lambda 간접 호출** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **AWS Lambda 간접 호출**을 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력,** **구성** 및 **출력** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['AWS Lambda 간접 호출' 작업 YAML](lam-invoke-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 'AWS Lambda 호출' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **AWS Lambda 간접 호출** 작업을 검색하고 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **AWS Lambda 간접 호출**을 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['AWS Lambda 간접 호출' 작업 YAML](lam-invoke-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 'AWS Lambda 간접 호출' 변수
기본적으로 **AWS Lambda 간접 호출** 작업은 Lambda 응답 페이로드의 최상위 키당 하나의 변수를 생성합니다.
예를 들어, 응답 페이로드가 다음과 같은 경우:
```
responsePayload = {
"name": "Saanvi",
"location": "Seattle",
"department": {
"company": "Amazon",
"team": "AWS"
}
}
```
...그런 다음 해당 작업은 다음과 같은 변수를 생성합니다.
| Key(키) | 값 |
| --- | --- |
| 이름 | Saanvi |
| location | 시애틀 |
| department | \$1"company": "Amazon", "team": "AWS"\$1 |
**참고**
`ResponseFilters` YAML 속성을 사용하여 생성되는 변수를 변경할 수 있습니다. 자세한 내용은 ['AWS Lambda 간접 호출' 작업 YAML](lam-invoke-action-ref.md)의 [ResponseFilters](lam-invoke-action-ref.md#lam.invoke.response.filters)를 참조하세요.
실행 시간에 'AWS Lambda 호출' 작업에 의해 생성되고 설정된 변수를 *사전 정의된 변수*라고 합니다.
워크플로에서 이러한 변수를 참조하는 방법에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
# 'AWS Lambda 간접 호출' 작업 YAML
다음은 **AWS Lambda 간접 호출** 작업의 YAML 정의입니다. 이러한 작업 사용 방법을 배우려면 [워크플로를 사용하여 Lambda 함수 호출](lam-invoke-action.md) 섹션을 참조하세요.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
LambdaInvoke\$1nn:
Identifier: aws/lambda-invoke@v1
DependsOn:
- dependent-action
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
Timeout: timeout-minutes
Inputs:
# Specify a source or an artifact, but not both.
Sources:
- source-name-1
Artifacts:
- request-payload
Variables:
- Name: variable-name-1
Value: variable-value-1
- Name: variable-name-2
Value: variable-value-2
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Configuration:
Function: my-function|function-arn
AWSRegion: us-west-2
# Specify RequestPayload or RequestPayloadFile, but not both.
RequestPayload: '{"firstname": "Li", lastname: "Jean", "company": "ExampleCo", "team": "Development"}'
RequestPayloadFile: my/request-payload.json
ContinueOnError: true|false
LogType: Tail|None
ResponseFilters: '{"name": ".name", "company": ".department.company"}'
Outputs:
Artifacts:
- Name: lambda_artifacts
Files:
- "lambda-response.json"
```
## LambdaInvoke
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
기본값: `Lambda_Invoke_Action_Workflow_nn`.
해당 UI: 구성 탭/**작업 이름**
## Identifier
(*LambdaInvoke*/**Identifier**)
(필수)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
기본값: `aws/lambda-invoke@v1`.
해당 UI: 워크플로 다이어그램/LambdaInvoke\$1nn/**aws/lambda-invoke@v1** 레이블
## DependsOn
(*LambdaInvoke*/**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*LambdaInvoke*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Type
(*LambdaInvoke*/Compute/**Type**)
([Compute](#lam.invoke.computename) 포함 시 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 구성 탭/**컴퓨팅 유형**
## Fleet
(*LambdaInvoke*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/**컴퓨팅 플릿**
## Timeout
(*LambdaInvoke*/**Timeout**)
(필수)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Inputs
(*LambdaInvoke*/**Inputs**)
(필수)
이 `Inputs` 섹션에서는 워크플로 실행 중에 **AWS Lambda 간접 호출** 작업에 필요한 데이터를 정의합니다.
**참고**
**AWS Lambda 간접 호출** 작업당 하나의 입력(소스 또는 아티팩트)만 허용됩니다. 변수는 이 합계에 포함되지 않습니다.
해당 UI: **입력** 탭
## Sources
(*LambdaInvoke*/Inputs/**Sources**)
([RequestPayloadFile](#lam.invoke.request.payload.file)이 제공된 경우 필수)
요청 페이로드 JSON 파일을 **AWS Lambda 간접 호출** 작업에 전달하고자 하며 이 페이로드 파일이 소스 리포지토리에 저장되는 경우, 해당 소스 리포지토리의 레이블을 지정합니다. 현재, `WorkflowSource` 레이블만 지원됩니다.
요청 페이로드 파일이 소스 리포지토리에 포함되어 있지 않은 경우, 다른 작업에서 생성된 아티팩트에 있어야 합니다.
페이로드 파일에 대한 자세한 내용은 [RequestPayloadFile](#lam.invoke.request.payload.file)을 참조하세요.
**참고**
페이로드 파일을 지정하는 대신 `RequestPayload` 속성을 사용하여 페이로드의 JSON 코드를 작업에 직접 추가할 수 있습니다. 자세한 내용은 [RequestPayload](#lam.invoke.request.payload) 단원을 참조하십시오.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*LambdaInvoke*/Inputs/**Artifacts**)
([RequestPayloadFile](#lam.invoke.request.payload.file)이 제공된 경우 필수)
요청 페이로드 JSON 파일을 **AWS Lambda 간접 호출** 작업에 전달하고자 하며 이 페이로드 파일이 이전 작업의 [출력 아티팩트](build-action-ref.md#build.outputs.artifacts)에 포함된 경우, 여기에 해당 아티팩트를 지정합니다.
페이로드 파일에 대한 자세한 내용은 [RequestPayloadFile](#lam.invoke.request.payload.file)을 참조하세요.
**참고**
페이로드 파일을 지정하는 대신 `RequestPayload` 속성을 사용하여 페이로드의 JSON 코드를 작업에 직접 추가할 수 있습니다. 자세한 내용은 [RequestPayload](#lam.invoke.request.payload) 단원을 참조하십시오.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**아티팩트 - 선택 사항**
## Variables - input
(*LambdaInvoke*/Inputs/**Variables**)
(선택 사항)
작업에 사용할 수 있도록 하려는 입력 변수를 정의하는 이름/값 페어의 시퀀스를 지정합니다. 변수 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 변수 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**변수 - 선택 사항**
## Environment
(*LambdaInvoke*/**Environment**)
(필수)
작업에 사용할 CodeCatalyst 환경을 지정합니다. 작업은 선택한 환경에 지정된 AWS 계정 및 선택적 Amazon VPC에 연결됩니다. 작업은 환경에 지정된 기본 IAM 역할을 사용하여에 연결하고 [Amazon VPC 연결](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)에 지정된 IAM 역할을 AWS 계정사용하여 Amazon VPC에 연결합니다.
**참고**
기본 IAM 역할에 작업에 필요한 권한이 없는 경우 다른 역할을 사용하도록 작업을 구성할 수 있습니다. 자세한 내용은 [작업의 IAM 역할 변경](deploy-environments-switch-role.md) 섹션을 참조하세요.
환경에 대한 자세한 내용은 [AWS 계정 및 VPCs에 배포](deploy-environments.md) 및 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**환경**
## Name
(*LambdaInvoke*/Environment/**Name**)
([Environment](#lam.invoke.environment) 포함 시 필수)
작업과 연결하려는 기존 환경의 이름을 지정합니다.
해당 UI: 구성 탭/**환경**
## Connections
(*LambdaInvoke*/Environment/**Connections**)
(최신 버전의 작업에서는 선택 사항, 이전 버전에서는 필수)
작업과 연결할 계정 연결을 지정합니다. `Environment`에서 계정 연결을 최대 1개까지 지정할 수 있습니다.
계정 연결을 지정하지 않는 경우:
+ 작업은 CodeCatalyst 콘솔의 환경에 지정된 AWS 계정 연결 및 기본 IAM 역할을 사용합니다. 환경에 계정 연결 및 기본 IAM 역할을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
+ 기본 IAM 역할에는 작업에 필요한 정책 및 권한이 포함되어야 합니다. 이러한 정책 및 권한이 무엇인지 확인하려면 작업의 YAML 정의 설명서에서 **역할** 속성에 대한 설명을 참조하세요.
계정 연결에 대한 자세한 정보는 [연결된를 사용하여 AWS 리소스에 대한 액세스 허용 AWS 계정](ipa-connect-account.md) 섹션을 참조하세요. 환경에 계정 연결을 추가하는 방법에 대한 자세한 내용은 [환경 생성](deploy-environments-creating-environment.md) 섹션을 참조하세요.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Name
(*LambdaInvoke*/Environment/Connections/**Name**)
([Connections](#lam.invoke.environment.connections) 포함 시 필수)
계정 연결의 이름을 지정합니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**AWS 계정 연결**
## Role
(*LambdaInvoke*/Environment/Connections/**Role**)
([Connections](#lam.invoke.environment.connections) 포함 시 필수)
**AWS Lambda 간접 호출** 작업이 Lambda 함수에 액세스 AWS 하고 간접 호출하는 데 사용하는 IAM 역할의 이름을 지정합니다. [CodeCatalyst 스페이스에 역할을 추가](ipa-connect-account-addroles.md)했고 역할에 다음 정책이 포함되어 있는지 확인합니다.
IAM 역할을 지정하지 않으면 작업은 CodeCatalyst 콘솔의 [환경](deploy-environments.md)에 나열된 기본 IAM 역할을 사용합니다. 환경에서 기본 역할을 사용하는 경우 다음 정책이 있는지 확인합니다.
+ 다음 권한 정책:
**주의**
다음 정책에 표시된 대로 권한을 제한합니다. 더 광범위한 권한을 가진 역할을 사용하면 보안 위험이 발생할 수 있습니다.
+ 다음 사용자 지정 신뢰 정책:
**참고**
원하는 경우 이 작업에서 `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할을 사용할 수 있습니다. 이에 대한 자세한 내용은 [계정 및 스페이스의 **CodeCatalystWorkflowDevelopmentRole-*spaceName*** 역할 생성](ipa-iam-roles.md#ipa-iam-roles-service-create) 섹션을 참조하세요. `CodeCatalystWorkflowDevelopmentRole-spaceName` 역할에 보안 위험을 초래할 수 있는 전체 액세스 권한이 있음을 이해합니다. 보안에 대한 우려가 적은 자습서 및 시나리오에서만 이 역할을 사용하는 것이 좋습니다.
해당 UI: 작업 버전에 따라 다음 중 하나:
+ (최신 버전) 구성 탭/환경/*내 환경*의 내용/점 3개 메뉴/**역할 전환**
+ (이전 버전) 구성 탭/'환경/계정/역할'/**역할**
## Configuration
(*LambdaInvoke*/**Configuration**)
(필수)
작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## Function
(*LambdaInvoke*/Configuration/**Function**)
(필수)
이 작업이 호출할 AWS Lambda 함수를 지정합니다. 이 함수의 이름 또는 Amazon 리소스 이름(ARN)을 지정합니다. Lambda 콘솔에서 해당 이름 또는 ARN을 찾을 수 있습니다.
**참고**
Lambda 함수가 있는 AWS 계정은 아래에 지정된 계정과 다를 수 있습니다`Connections:`.
해당 UI: 구성 탭/**기능**
## AWSRegion
(*LambdaInvoke*/Configuration/**AWSRegion**)
(필수)
AWS Lambda 함수가 있는 AWS 리전을 지정합니다. 리전 코드 목록은 *AWS 일반 참조*의 [리전 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)를 참조하세요.
해당 UI: 구성 탭/**대상 버킷 - 선택 사항**
## RequestPayload
(*LambdaInvoke*/Configuration/**RequestPayload**)
(선택 사항)
**AWS Lambda 간접 호출** 작업에 요청 페이로드를 전달하려면, JSON 형식으로 여기에 요청 페이로드를 지정합니다.
요청 페이로드 예시:
```
'{ "key": "value" }'
```
Lambda 함수에 요청 페이로드를 전달하지 않으려면 이 속성을 생략합니다.
**참고**
`RequestPayload` 또는 `RequestPayloadFile`을 지정할 수 있지만 둘 다 함께 지정할 수는 없습니다.
요청 페이로드에 대한 자세한 내용은 *AWS Lambda API 참조* 의 [Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) 주제를 참조하세요.
해당 UI: 구성 탭/**요청 페이로드 - 선택 사항**
## RequestPayloadFile
(*LambdaInvoke*/Configuration/**RequestPayloadFile**)
(선택 사항)
**AWS Lambda 간접 호출** 작업에 요청 페이로드를 전달하려면, 여기에 이 요청 페이로드 파일의 경로를 지정합니다. 파일은 JSON 형식이어야 합니다.
요청 페이로드 파일은 소스 리포지토리 또는 이전 작업의 아티팩트에 상주할 수 있습니다. 파일 경로는 소스 리포지토리 또는 아티팩트 루트를 기준으로 합니다.
Lambda 함수에 요청 페이로드를 전달하지 않으려면 이 속성을 생략합니다.
**참고**
`RequestPayload` 또는 `RequestPayloadFile`을 지정할 수 있지만 둘 다 함께 지정할 수는 없습니다.
요청 페이로드 파일에 대한 자세한 내용은 *AWS Lambda API 참조*의 [Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) 주제를 참조하세요.
해당 UI: 구성 탭/**요청 페이로드 파일 - 선택 사항**
## ContinueOnError
(*LambdaInvoke*/Configuration/**RequestPayloadFile**)
(선택 사항)
간접적으로 호출된 AWS Lambda 함수가 실패하더라도 **AWS Lambda 간접 호출** 작업을 성공으로 표시할지 여부를 지정합니다. Lambda 실패에도 불구하고 워크플로의 후속 작업이 시작되도록 하려면 이 속성을 `true`로 설정하는 것을 고려하세요.
기본적으로 Lambda 함수가 실패하면(시각 편집기에서 ‘off’ 또는 YAML 편집기에서 `false`) 작업에 실패합니다.
해당 UI: 구성 탭/**오류 발생 시 계속 진행**
## LogType
(*LambdaInvoke*/Configuration/**LogType**)
(선택 사항)
간접 호출된 후 Lambda 함수의 응답에 오류 로그를 포함할지 여부를 지정합니다. 이러한 로그는 CodeCatalyst 콘솔의 **Lambda 간접 호출** 작업의 **로그** 탭에서 볼 수 있습니다. 가능한 값은 다음과 같습니다.
+ `Tail` – 로그를 반환함
+ `None` - 로그를 반환하지 않음
기본값은 **Tail**입니다.
로그 유형에 대한 자세한 내용은 *AWS Lambda API 참조*의 [Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) 주제를 참조하세요.
로그 보기에 대한 자세한 내용은 [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**로그 유형**
## ResponseFilters
(*LambdaInvoke*/Configuration/**ResponseFilters**)
(선택 사항)
Lambda 응답 페이로드에서 출력 변수로 변환할 키를 지정합니다. 그런 다음 워크플로의 후속 작업에서 출력 변수를 참조할 수 있습니다. CodeCatalyst의 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
예를 들어, 응답 페이로드가 다음과 같은 경우:
```
responsePayload = {
"name": "Saanvi",
"location": "Seattle",
"department": {
"company": "Amazon",
"team": "AWS"
}
}
```
...응답 필터는 다음과 같습니다.
```
Configuration:
...
ResponseFilters: '{"name": ".name", "company": ".department.company"}'
```
...그런 다음 해당 작업은 다음과 같은 출력 변수를 생성합니다.
| Key(키) | 값 |
| --- | --- |
| 이름 | Saanvi |
| company | Amazon |
그런 다음 후속 작업에서 `name` 및 `company` 변수를 참조할 수 있습니다.
`ResponseFilters`에서 키를 지정하지 않으면, 해당 작업은 Lambda 응답의 각 최상위 키를 출력 변수로 변환합니다. 자세한 내용은 ['AWS Lambda 간접 호출' 변수](lam-invoke-action-variables.md) 단원을 참조하십시오.
응답 필터를 사용하여 생성된 출력 변수를 실제로 사용하려는 변수로 제한하는 것이 좋습니다.
해당 UI: 구성 탭/**응답 필터 - 선택 사항**
## Outputs
(*LambdaInvoke*/**Outputs**)
(선택 사항)
워크플로 실행 중에 작업에 의해 출력되는 데이터를 정의합니다.
해당 UI: **출력** 탭
## Artifacts
(*LambdaInvoke*/Outputs/**Artifacts**)
(선택 사항)
작업에서 생성된 아티팩트를 지정합니다. 이러한 아티팩트를 다른 작업의 입력으로 참조할 수 있습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/아티팩트/**빌드 아티팩트 이름**
## Name
(*LambdaInvoke*/Outputs/Artifacts/**Name**)
(선택 사항)
Lambda 함수에서 반환되는 Lambda 응답 페이로드를 포함할 아티팩트의 이름을 지정합니다. 기본값은 `lambda_artifacts`입니다. 아티팩트를 지정하지 않으면, 작업의 로그에서 Lambda 응답 페이로드를 볼 수 있습니다. 이 로그는 CodeCatalyst 콘솔의 작업에 대한 **로그** 탭에서 사용할 수 있습니다. 로그 보기에 대한 자세한 내용은 [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md) 섹션을 참조하세요.
해당 UI: 출력 탭/아티팩트/**빌드 아티팩트 이름**
## Files
(*LambdaInvoke*/Outputs/Artifacts/**Files**)
(선택 사항)
아티팩트에 포함할 파일을 지정합니다. Lambda 응답 페이로드 파일이 포함`lambda-response.json`되도록 을 지정해야 합니다.
해당 UI: 출력 탭/아티팩트/**빌드에서 생성된 파일**
# Amazon ECS 작업 정의 수정
이 섹션에서는 CodeCatalyst 워크플로를 사용하여 Amazon Elastic Container Service(Amazon ECS) [작업 정의 파일](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions)의 `image` 필드를 업데이트하는 방법을 설명합니다. 이렇게 하려면, 워크플로에 **Amazon ECS 작업 정의 렌더링** 작업을 추가해야 합니다. 이 작업은 런타임 시 워크플로에서 제공하는 Docker 이미지 이름으로 작업 정의 파일의 이미지 필드를 업데이트합니다.
**참고**
이 작업을 사용하여 작업 정의의 `environment` 필드를 환경 변수로 업데이트할 수도 있습니다.
**Topics**
+ [이 작업을 사용해야 하는 경우](#render-ecs-action-when-to-use)
+ ['Amazon ECS 작업 정의 렌더링' 작업 작동 방식](#render-ecs-action-how-it-works)
+ ['Amazon ECS 작업 정의 렌더링' 작업에 사용되는 런타임 이미지](#render-ecs-action-runtime)
+ [예시: Amazon ECS 작업 정의 수정](render-ecs-action-example-workflow.md)
+ ['Amazon ECS 작업 정의 렌더링' 작업 추가](render-ecs-action-add.md)
+ [업데이트된 작업 정의 파일 보기](render-ecs-action-view.md)
+ ['Amazon ECS 작업 정의 렌더링' 변수](render-ecs-action-variables.md)
+ ['Amazon ECS 작업 정의 렌더링' 작업 YAML](render-ecs-action-ref.md)
## 이 작업을 사용해야 하는 경우
커밋 ID 또는 타임스탬프와 같은 동적 콘텐츠가 포함된 Docker 이미지를 빌드하고 태그를 지정하는 워크플로가 있는 경우 이 옵션을 사용합니다.
작업 정의 파일에 항상 동일하게 유지되는 이미지 값이 포함된 경우 이 작업을 사용하지 마세요. 이 경우 작업 정의 파일에 이미지 이름을 수동으로 입력할 수 있습니다.
## 'Amazon ECS 작업 정의 렌더링' 작업 작동 방식
워크플로의 **빌드** 및 **Amazon ECS에 배포** 작업과 함께 **Amazon ECS 작업 정의 렌더링** 작업을 사용해야 합니다. 이 작업들을 함께 사용하면 다음과 같이 작동합니다.
1. **빌드** 작업은 Docker 이미지를 빌드하고 이름, 커밋 ID, 타임스탬프 또는 기타 동적 콘텐츠로 태그를 지정합니다. 예를 들어 빌드 작업은 다음과 같습니다.
```
MyECSWorkflow
Actions:
BuildAction:
Identifier: aws/build@v1
...
Configuration:
Steps:
# Build, tag, and push the Docker image...
- Run: docker build -t MyDockerImage:${WorkflowSource.CommitId} .
...
```
앞의 코드에서 `docker build -t` 지시문은 Docker 이미지를 빌드하고 작업 런타임 시 커밋 ID로 태그를 지정하도록 나타냅니다. 생성된 이미지 이름은 다음과 같을 수 있습니다.
`MyDockerImage:a37bd7e`
1. **렌더링 Amazon ECS 작업 정의** 작업은 다음과 같이 동적으로 생성된 이미지 이름 `MyDockerImage:a37bd7e`를 작업 정의 파일에 추가합니다.
```
{
"executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role",
"containerDefinitions": [
{
"name": "codecatalyst-ecs-container",
"image": MyDockerImage:a37bd7e,
"essential": true,
...
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
]
}
],
...
}
```
필요에 따라 **렌더링 Amazon ECS 작업 정의** 작업에서 다음과 같은 환경 변수를 작업 정의에 추가하도록 할 수도 있습니다.
```
{
"executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role",
"containerDefinitions": [
{
"name": "codecatalyst-ecs-container",
"image": MyDockerImage:a37bd7e,
...
"environment": [
{
name": "ECS_LOGLEVEL",
value": "info"
}
]
}
],
...
}
```
자세한 내용을 알아보려면 *Amazon Elastic Container Service 개발자 안내서*의 [환경 변수 지정](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html)을 참조하세요.
1. **Amazon ECS에 배포** 작업은 업데이트된 작업 정의 파일을 Amazon ECS에 등록합니다. 업데이트된 작업 정의 파일을 등록하면 새 이미지 `MyDockerImage:a37bd7e`가 Amazon ECS에 배포됩니다.
## 'Amazon ECS 작업 정의 렌더링' 작업에 사용되는 런타임 이미지
**Amazon ECS 작업 정의 렌더링** 작업은 [2022년 11월 이미지](build-images.md#build.previous-image)에서 실행됩니다. 자세한 내용은 [활성 이미지](build-images.md#build-curated-images) 단원을 참조하십시오.
# 예시: Amazon ECS 작업 정의 수정
다음은 빌드 및 배포 작업과 함께 **렌더링 Amazon ECS 작업 정의** 작업을 포함하는 전체 워크플로의 예입니다. 워크플로의 목적은 Amazon ECS 클러스터에 Docker 이미지를 빌드하고 배포하는 것입니다. 워크플로는 순차적으로 실행되는 다음 구성 요소로 구성됩니다.
+ **트리거** - 이 트리거는 소스 리포지토리에 변경 사항을 푸시할 때 워크플로 실행을 자동으로 시작합니다. 트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
+ **빌드** 작업(`BuildDocker`) - 트리거 시 작업은 Dockerfile을 사용하여 Docker 이미지를 빌드하고, 커밋 ID로 태그를 지정하고, 이미지를 Amazon ECR로 푸시합니다. 빌드 작업에 대한 자세한 내용은 [워크플로로 빌드하기](build-workflow-actions.md) 섹션을 참조하세요.
+ **렌더링 Amazon ECS 작업 정의** 작업(`RenderTaskDef`) - 빌드 작업이 완료되면 이 작업은 소스 리포지토리의 루트에 있는 기존 `taskdef.json`를 올바른 커밋 ID가 포함된 `image` 필드 값으로 업데이트합니다. 업데이트된 파일을 새 파일 이름(`task-definition-random-string.json`)으로 저장한 다음 이 파일이 포함된 출력 아티팩트를 생성합니다. 렌더링 작업은 `task-definition`라는 변수 역시 생성하며, 이를 새 작업 정의 파일의 이름으로 설정합니다. 아티팩트와 변수는 배포 작업, 즉 다음 작업을 사용합니다.
+ **Amazon ECS에 배포** 작업(`DeployToECS`) - **Amazon ECS에 배포 작업 정의** 작업이 완료되면, **Amazon ECS에 배포** 작업은 렌더링 작업(`TaskDefArtifact`)에서 생성된 출력 아티팩트를 찾고 그 안의 `task-definition-random-string.json`파일을 발견해 Amazon ECS 서비스에 등록합니다. 그런 다음 Amazon ECS 서비스는 `task-definition-random-string.json` 파일의 지침에 따라 Amazon ECS 클러스터 내에서 Amazon ECS 작업 및 연결된 Docker 이미지 컨테이너를 실행합니다.
```
Name: codecatalyst-ecs-workflow
SchemaVersion: 1.0
Triggers:
- Type: PUSH
Branches:
- main
Actions:
BuildDocker:
Identifier: aws/build@v1
Environment:
Name: codecatalyst-ecs-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-ecs-build-role
Inputs:
Variables:
- Name: REPOSITORY_URI
Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo
- Name: IMAGE_TAG
Value: ${WorkflowSource.CommitId}
Configuration:
Steps:
#pre_build:
- Run: echo Logging in to Amazon ECR...
- Run: aws --version
- Run: aws ecr get-login-password --region us-east-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-2.amazonaws.com
#build:
- Run: echo Build started on `date`
- Run: echo Building the Docker image...
- Run: docker build -t $REPOSITORY_URI:latest .
- Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
#post_build:
- Run: echo Build completed on `date`
- Run: echo Pushing the Docker images...
- Run: docker push $REPOSITORY_URI:latest
- Run: docker push $REPOSITORY_URI:$IMAGE_TAG
RenderTaskDef:
DependsOn:
- BuildDocker
Identifier: aws/ecs-render-task-definition@v1
Inputs:
Variables:
- Name: REPOSITORY_URI
Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo
- Name: IMAGE_TAG
Value: ${WorkflowSource.CommitId}
Configuration:
task-definition: taskdef.json
container-definition-name: codecatalyst-ecs-container
image: $REPOSITORY_URI:$IMAGE_TAG
# The output artifact contains the updated task definition file.
# The new file is prefixed with 'task-definition'.
# The output variable is set to the name of the updated task definition file.
Outputs:
Artifacts:
- Name: TaskDefArtifact
Files:
- "task-definition*"
Variables:
- task-definition
DeployToECS:
Identifier: aws/ecs-deploy@v1
Environment:
Name: codecatalyst-ecs-environment
Connections:
- Name: codecatalyst-account-connection
Role: codecatalyst-ecs-deploy-role
#Input artifact contains the updated task definition file.
Inputs:
Sources: []
Artifacts:
- TaskDefArtifact
Configuration:
region: us-east-2
cluster: codecatalyst-ecs-cluster
service: codecatalyst-ecs-service
task-definition: ${RenderTaskDef.task-definition}
```
# 'Amazon ECS 작업 정의 렌더링' 작업 추가
다음 지침을 사용하여 워크플로에 **Amazon ECS 작업 정의 렌더링** 작업을 추가합니다.
**사전 조건**
시작하기 전에, Docker 이미지를 동적으로 생성하는 빌드 작업이 포함된 워크플로가 있는지 확인합니다. 자세한 내용은 앞의 [워크플로 예시](render-ecs-action-example-workflow.md)를 참조하세요.
------
#### [ Visual ]
**시각적 편집기를 사용하여 'Amazon ECS 작업 정의 렌더링' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **Amazon ECS 작업 정의 렌더링** 작업을 검색하고, 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **Amazon ECS 작업 정의 렌더링**을 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. **입력** 및 **구성** 탭에서 필요에 따라 필드를 작성합니다. 각 필드의 설명은 ['Amazon ECS 작업 정의 렌더링' 작업 YAML](render-ecs-action-ref.md) 섹션을 참조하세요. 이 참조는 YAML 및 시각적 편집기 모두에 나타나는 각 필드(및 해당 YAML 속성 값)에 대한 자세한 정보를 제공합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**YAML 편집기를 사용하여 'Amazon ECS 작업 정의 렌더링' 작업을 추가하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 왼쪽 상단에서 **\$1 작업**을 선택하여 작업 카탈로그를 엽니다.
1. 드롭다운 목록에서 **Amazon CodeCatalyst**를 선택합니다.
1. **Amazon ECS 작업 정의 렌더링** 작업을 검색하고, 다음 중 하나를 수행합니다.
+ 더하기 기호(**\$1**)를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
또는
+ **Amazon ECS 작업 정의 렌더링**을 선택합니다. 작업 세부 정보 대화 상자가 나타납니다. 이 대화 상자에서 다음을 수행합니다.
+ (선택 사항) **소스 보기**를 선택하여 [작업의 소스 코드를 봅니다](workflows-view-source.md#workflows-view-source.title).
+ **워크플로에 추가**를 선택하여 워크플로 다이어그램에 작업을 추가하고 구성 창을 엽니다.
1. 필요에 따라 YAML 코드의 속성을 수정합니다. 사용 가능한 각 속성에 대한 설명은 ['Amazon ECS 작업 정의 렌더링' 작업 YAML](render-ecs-action-ref.md)에서 볼 수 있습니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
**다음 단계**
렌더링 작업을 추가한 후, [워크플로를 사용하여 Amazon ECS에 배포](deploy-action-ecs.md)의 지침에 따라 **Amazon ECS에 배포** 작업을 워크플로에 추가합니다. 배포 작업을 추가하는 동안 다음을 수행합니다.
1. 배포 작업의 **입력** 탭의 **아티팩트 - 선택 사항**에서 렌더링 작업으로 생성된 아티팩트를 선택합니다. 여기에는 업데이트된 작업 정의 파일이 포함되어 있습니다.
아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
1. 배포 작업의 **구성** 탭의 **작업 정의** 필드에서 `RenderTaskDef`와 같이 *작업 이름*이 렌더링 작업의 이름인 `${action-name.task-definition}` 작업 변수를 지정합니다. 렌더링 작업은 이 변수를 태스크 정의 파일의 새 이름으로 설정합니다.
변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
배포 작업을 구성하는 방법에 대한 자세한 내용은 앞의 [워크플로 예시](render-ecs-action-example-workflow.md)를 참조하세요.
# 업데이트된 작업 정의 파일 보기
업데이트된 작업 정의 파일의 이름과 내용을 볼 수 있습니다.
****Amazon ECS 작업 정의 렌더링** 작업이 파일을 처리한 후에 업데이트된 작업 정의 파일의 이름을 볼 수 있습니다.**
1. 완료된 렌더링 작업이 포함된 실행을 찾습니다.
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 완료된 렌더링 작업이 포함된 실행을 선택합니다.
1. 워크플로 다이어그램에서 렌더링 작업을 선택합니다.
1. **출력**을 선택합니다.
1. **변수**를 선택합니다.
1. 작업 정의 파일 이름이 표시됩니다. 이 이름은 `task-definition--259-0a2r7gxlTF5X-.json`와 유사합니다.
**업데이트된 작업 정의 파일의 내용을 보려면**
1. 완료된 렌더링 작업이 포함된 실행을 찾습니다.
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. 완료된 렌더링 작업이 포함된 실행을 선택합니다.
1. 워크플로 실행의 상단에서 **비주얼** 및 **YAML** 옆에 있는 **워크플로 출력**을 선택합니다.
1. **아티팩트** 섹션에서 업데이트된 작업 정의 파일이 포함된 아티팩트 옆에 있는 **다운로드**를 선택합니다. 이 아티팩트에는 렌더링 작업의 이름으로 설정된 **생성 기준** 열이 있습니다.
1. .zip 파일을 열어 작업 정의 .json 파일을 봅니다.
# 'Amazon ECS 작업 정의 렌더링' 변수
**Amazon ECS 태스크 정의 렌더링** 작업은 런타임에 다음 변수를 생성하고 설정합니다. 이를 *사전 정의된 변수*라고 합니다.
워크플로에서 이러한 변수를 참조하는 방법에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
| Key(키) | 값 |
| --- | --- |
| 작업 정의 | **렌더링 Amazon ECS 작업 정의** 작업에 의해 업데이트된 작업 정의 파일에 지정된 이름입니다. 이름은 `task-definition-random-string.json` 형식입니다. 예시: `task-definition--259-0a2r7gxlTF5Xr.json` |
# 'Amazon ECS 작업 정의 렌더링' 작업 YAML
다음은 **렌더링 Amazon ECS 작업 정의** 작업의 YAML 정의입니다. 이러한 작업 사용 방법을 배우려면 [Amazon ECS 작업 정의 수정](render-ecs-action.md) 섹션을 참조하세요.
이 작업 정의는 더 광범위한 워크플로 정의 파일 내의 섹션으로 존재합니다. 이 파일에 대한 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)을 참조합니다.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
```
# The workflow definition starts here.
# See 최상위 속성 for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
ECSRenderTaskDefinition\$1nn:
Identifier: aws/ecs-render-task-definition@v1
DependsOn:
- build-action
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
Timeout: timeout-minutes
Inputs:
# Specify a source or an artifact, but not both.
Sources:
- source-name-1
Artifacts:
- task-definition-artifact
Variables:
- Name: variable-name-1
Value: variable-value-1
- Name: variable-name-2
Value: variable-value-2
Configuration
task-definition: task-definition-path
container-definition-name: container-definition-name
image: docker-image-name
environment-variables:
- variable-name-1=variable-value-1
- variable-name-2=variable-value-2
Outputs:
Artifacts:
- Name: TaskDefArtifact
Files: "task-definition*"
Variables:
- task-definition
```
## ECSRenderTaskDefinition
(필수)
작업 이름을 지정합니다. 워크플로 내의 모든 작업 이름은 고유해야 합니다. 작업 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 작업 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
기본값: `ECSRenderTaskDefinition_nn`.
해당 UI: 구성 탭/**작업 이름**
## Identifier
(*ECSRenderTaskDefinition*/**Identifier**)
(필수)
작업을 식별합니다. 버전을 변경하려는 경우가 아니면 이 속성을 변경하지 마세요. 자세한 내용은 [사용할 작업 버전 지정](workflows-action-versions.md) 섹션을 참조하세요.
기본값: `aws/ecs-render-task-definition@v1`.
해당 UI: 워크플로 다이어그램/ECSRenderTaskDefinition\$1nn/**aws/ecs-render-task-definition@v1** 레이블
## DependsOn
(*ECSRenderTaskDefinition*/**DependsOn**)
(선택 사항)
이 작업을 실행하기 위해 성공적으로 실행해야 하는 작업, 작업 그룹 또는 게이트를 지정합니다.
'depends on' 함수에 대한 자세한 내용은 [작업 순서 지정](workflows-depends-on.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**의존 - 선택 사항**
## Compute
(*ECSRenderTaskDefinition*/**Compute**)
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
## Type
(*ECSRenderTaskDefinition*/Compute/**Type**)
([Compute](#render.ecs.computename) 포함 시 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 구성 탭/**컴퓨팅 유형**
## Fleet
(*ECSRenderTaskDefinition*/Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
해당 UI: 구성 탭/**컴퓨팅 플릿**
## Timeout
(*ECSRenderTaskDefinition*/**Timeout**)
(선택 사항)
CodeCatalyst가 작업을 종료하기 전에 작업을 실행할 수 있는 시간을 분(YAML 편집기) 또는 시간 및 분(시각적 편집기) 단위로 지정합니다. 최소값은 5분이고 최대값은 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 설명되어 있습니다. 기본 제한 시간은 최대 제한 시간과 동일합니다.
해당 UI: 구성 탭/**제한 시간 - 선택 사항 **
## Inputs
(*ECSRenderTaskDefinition*/**Inputs**)
(선택 사항)
이 `Inputs` 섹션에서는 워크플로 실행 중에 `ECSRenderTaskDefinition`에 필요한 데이터를 정의합니다.
**참고**
**렌더링 Amazon ECS 작업 정의** 작업당 하나의 입력(소스 또는 아티팩트)만 허용됩니다. 변수는 이 합계에 포함되지 않습니다.
해당 UI: **입력** 탭
## Sources
(*ECSRenderTaskDefinition*/Inputs/**Sources**)
(작업 정의 파일이 소스 리포지토리에 저장된 경우 필수)
태스크 정의 파일이 소스 리포지토리에 저장되어 있는 경우 해당 소스 리포지토리의 레이블을 지정합니다. 현재, `WorkflowSource` 레이블만 지원됩니다.
태스크 정의 파일이 소스 리포지토리에 포함되어 있지 않은 경우, 다른 작업에서 생성된 아티팩트에 있어야 합니다.
소스에 대한 자세한 내용은 [워크플로에 소스 리포지토리 연결](workflows-sources.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**소스 - 선택 사항**
## Artifacts - input
(*ECSRenderTaskDefinition*/Inputs/**Artifacts**)
(작업 정의 파일이 이전 작업의 [출력 아티팩트](workflows-working-artifacts-output.md)에 저장된 경우 필수)
배포하려는 작업 정의 파일이 이전 작업에서 생성된 아티팩트에 포함된 경우 여기에 해당 아티팩트를 지정합니다. 태스크 정의 파일이 아티팩트 내에 포함되어 있지 않은 경우 소스 리포지토리에 있어야 합니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**아티팩트 - 선택 사항**
## Variables - input
(*ECSRenderTaskDefinition*/Inputs/**Variables**)
(필수)
작업에 사용할 수 있도록 하려는 입력 변수를 정의하는 이름/값 페어의 시퀀스를 지정합니다. 변수 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 변수 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 입력 탭/**변수 - 선택 사항**
## Configuration
(*ECSRenderTaskDefinition*/**Configuration**)
(필수)
작업의 구성 속성을 정의할 수 있는 섹션입니다.
해당 UI: **구성** 탭
## task-definition
(*ECSRenderTaskDefinition*/Configuration/**task-definition**)
(필수)
기존 작업 정의 파일의 경로를 지정합니다. 파일이 소스 리포지토리에 있는 경우 경로는 소스 리포지토리 루트 폴더를 기준으로 합니다. 파일이 이전 워크플로 작업의 아티팩트에 있는 경우 경로는 아티팩트 루트 폴더를 기준으로 합니다. 자세한 내용을 알아보려면 *Amazon Elastic Container Service 개발자 안내서*의 [작업 정의](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions)를 참조하세요.
해당 UI: 구성 탭/**작업 정의**
## container-definition-name
(*ECSRenderTaskDefinition*/Configuration/**container-definition-name**)
(필수)
Docker 이미지가 실행될 컨테이너의 이름을 지정합니다. 이 이름은 작업 정의 파일의 `containerDefinitions`, `name` 필드에서 찾을 수 있습니다. 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [이름](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_name) 섹션을 참조하세요.
해당 UI: 구성 탭/**컨테이너 이름**
## image
(*ECSRenderTaskDefinition*/Configuration/**image**)
(필수)
**Render Amazon ECS 작업 정의** 작업을 작업 정의 파일에 추가할 Docker 이미지의 이름을 지정합니다. 이 작업은 작업 정의 파일의 `containerDefinitions`, `image` 필드에 이 이름을 추가합니다. `image` 필드에 값이 이미 있는 경우, 이 작업이 값을 덮어씁니다. 이미지 이름에 변수를 포함할 수 있습니다.
예시:
`MyDockerImage:${WorkflowSource.CommitId}` 를 지정하면 `MyDockerImage:commit-id` 작업이 작업 정의 파일에 추가되며, 여기서 *commit-id*는 워크플로에서 런타임에 생성된 커밋 ID입니다.
`my-ecr-repo/image-repo:$(date +%m-%d-%y-%H-%m-%s)`를 지정하면 작업이 태스크 정의 파일에 *my-ecr-repo */image-repo:*date \$1%m-%d-%y-%H-%m-%s*를 추가합니다. 여기서 *my-ecr-repo*는 Amazon Elastic Container Registry(ECR)의 URI이며, *date \$1%m-%d-%y-%H-%m-%s*는 워크플로에서 런타임에 생성된 `month-day-year-hour-minute-second` 형식의 타임스탬프입니다.
`image` 필드에 대한 자세한 내용을 알아보려면, *Amazon Elastic Container Service 개발자 안내서*의 [이미지](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_image)를 참조하세요. 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
해당 UI: 구성 탭/**이미지 이름**
## environment-variables
(*ECSRenderTaskDefinition*/Configuration/**environment-variables**)
(필수)
**Amazon ECS 작업 정의 렌더링** 작업을 작업 정의 파일에 추가할 환경 변수를 지정합니다. 작업은 작업 정의 파일의 `containerDefinitions`, `environment` 필드에 변수를 추가합니다. 파일에 변수가 이미 있는 경우, 작업은 기존 변수의 값을 덮어쓰고 새 변수를 추가합니다. 자세한 내용을 알아보려면 *Amazon Elastic Container Service 개발자 안내서*의 [환경 변수 지정](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html)을 참조하세요.
해당 UI: 구성 탭/**환경 변수 - 선택 사항**
## Outputs
(*ECSRenderTaskDefinition*/**Outputs**)
(필수)
워크플로 실행 중에 작업에 의해 출력되는 데이터를 정의합니다.
해당 UI: **출력** 탭
## Artifacts
(*ECSRenderTaskDefinition*/Outputs/**Artifacts**)
(필수)
작업에서 생성된 아티팩트를 지정합니다. 이러한 아티팩트를 다른 작업의 입력으로 참조할 수 있습니다.
예시를 포함해 아티팩트에 대한 자세한 내용은 [작업 간 아티팩트 및 파일 공유](workflows-working-artifacts.md) 섹션을 참조하세요.
해당 UI: 출력 탭/**아티팩트**
## Name
(*ECSRenderTaskDefinition*/Outputs/Artifacts/**Name**)
(필수)
업데이트된 작업 정의 파일을 포함할 아티팩트의 이름을 지정합니다. 기본값은 `MyTaskDefinitionArtifact`입니다. 그런 다음 이 아티팩트를 **Amazon ECS에 배포** 작업에 대한 입력으로 지정해야 합니다. 이 아티팩트를 **Amazon ECS에 배포** 작업에 입력으로 추가하는 방법을 알아보려면 [예시: Amazon ECS 작업 정의 수정](render-ecs-action-example-workflow.md) 섹션을 참조하세요.
해당 UI: 출력 탭/아티팩트/**이름**
## Files
(*ECSRenderTaskDefinition*/Outputs/Artifacts/**Files**)
(필수)
아티팩트에 포함할 파일을 지정합니다. `task-definition-`으로 시작하는 업데이트된 작업 정의 파일이 포함되도록 `task-definition-*`을 지정해야 합니다.
해당 UI: 출력 탭/아티팩트/**파일**
## Variables
(*ECSRenderTaskDefinition*/Outputs/**Variables**)
(필수)
렌더링 작업에서 설정할 변수의 이름을 지정합니다. 렌더링 작업은 이 변수의 값을 업데이트된 작업 정의 파일 이름(예: `task-definition-random-string.json`)으로 설정합니다. 그런 다음 **Amazon ECS 작업에 배포** 작업의 **작업 정의**(시각 편집기) 또는 `task-definition`(yaml 편집기) 속성에서 이 변수를 지정해야 합니다. 이 변수를 **Amazon ECS에 배포** 작업에 추가하는 방법을 알아보려면 [예시: Amazon ECS 작업 정의 수정](render-ecs-action-example-workflow.md) 섹션을 참조하세요.
기본값: `task-definition`
해당 UI: 출력 탭/변수/**이름** 필드
# 워크플로에서 변수 사용
*변수*는 Amazon CodeCatalyst 워크플로에서 참조할 수 있는 정보를 포함하는 키-값 페어입니다. 변수의 값 부분은 워크플로가 실행될 때 실제 값으로 대체됩니다.
워크플로에서 사용할 수 있는 변수 유형에는 다음 두 가지가 있습니다.
+ **사용자 정의 변수** - 사용자가 정의한 키-값 페어입니다.
+ **사전 정의된 변수** - 워크플로에서 자동으로 내보내는 키-값 페어입니다. 정의할 필요가 없습니다.
워크플로에 대한 자세한 내용은 [워크플로를 사용하여 빌드, 테스트 및 배포워크플로를 사용하여 빌드, 테스트 및 배포](workflow.md) 섹션을 참조하세요.
**참고**
CodeCatalyst는 변수처럼 작동하고 다른 작업에서 참조할 수 있는 [GitHub 출력 파라미터](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter)도 지원합니다. 자세한 내용은 [GitHub 출력 파라미터 내보내기](integrations-github-action-export.md) 및 [GitHub 출력 파라미터 참조](integrations-github-action-referencing.md) 섹션을 참조하세요.
**Topics**
+ [사용자 정의된 변수 사용](workflows-using-variables.md)
+ [사전 정의된 변수 사용](workflows-using-predefined-variables.md)
# 사용자 정의된 변수 사용
*사용자된 정의 변수*는 사용자가 정의하는 키-값 페어입니다. 두 가지의 유형이 있습니다.
+ **일반 텍스트 변수** 또는 간단히 **변수** - 워크플로 정의 파일 내에서 일반 텍스트로 정의하는 키-값 페어입니다.
+ **보안 암호** - Amazon CodeCatalyst 콘솔의 별도의 **보안 암호** 페이지에서 정의하는 키-값 페어입니다. *키*(이름)는 퍼블릭 레이블이며, *값*은 비공개로 유지하려는 정보를 포함합니다. 워크플로 정의 파일에서 키만 지정하면 됩니다. 워크플로 정의 파일에 암호 및 기타 민감한 정보 대신 보안 암호를 사용합니다.
**참고**
간결성을 위해 이 가이드에서는 *변수*라는 용어를 *일반 텍스트 변수*를 의미하는 용어로 사용합니다.
변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
**Topics**
+ [변수의 예](workflows-working-with-variables-ex.md)
+ [변수 정의](workflows-working-with-variables-define-input.md)
+ [보안 암호 정의](workflows-working-with-variables-define-secret.md)
+ [다른 작업에서 사용할 수 있도록 변수 내보내기](workflows-working-with-variables-export-input.md)
+ [변수를 정의하는 작업에서 변수 참조](workflows-working-with-variables-reference-input.md)
+ [다른 작업에 의한 변수 출력 참조](workflows-working-with-variables-reference-action.md)
+ [보안 암호 참조](workflows-working-with-variables-reference-secret.md)
# 변수의 예
다음 예시에서는 워크플로 정의 파일에서 변수를 정의하고 참조하는 방법을 보여줍니다.
변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
**Topics**
+ [예시: Inputs 속성을 사용하여 변수 정의](#workflows-working-with-variables-ex-define-inputs)
+ [예시: Steps 속성을 사용하여 변수 정의](#workflows-working-with-variables-ex-define-steps)
+ [예시: Outputs 속성을 사용하여 변수 내보내기](#workflows-working-with-variables-ex-export-outputs)
+ [예시: 동일한 작업에 정의된 변수 참조](#workflows-working-with-variables-ex-refer-current)
+ [예시: 다른 작업에 정의된 변수 참조](#workflows-working-with-variables-ex-refer-other)
+ [예시: 보안 암호 참조](#workflows-working-with-variables-ex-refer-secret)
## 예시: Inputs 속성을 사용하여 변수 정의
다음 예시에서는 `Inputs` 섹션에서 두 개의 변수인 `VAR1` 및 `VAR2`를 정의하는 방법을 보여줍니다.
```
Actions:
Build:
Identifier: aws/build@v1
Inputs:
Variables:
- Name: VAR1
Value: "My variable 1"
- Name: VAR2
Value: "My variable 2"
```
## 예시: Steps 속성을 사용하여 변수 정의
다음 예시에서는 `Steps` 섹션에서 `DATE` 변수를 명시적으로 정의하는 방법을 보여줍니다.
```
Actions:
Build:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: DATE=$(date +%m-%d-%y)
```
## 예시: Outputs 속성을 사용하여 변수 내보내기
다음 예시에서는 두 개의 변수인 `REPOSITORY-URI` 및 `TIMESTAMP`를 정의하고 `Outputs` 섹션을 사용하여 내보내는 방법을 보여줍니다.
```
Actions:
Build:
Identifier: aws/build@v1
Inputs:
Variables:
- Name: REPOSITORY-URI
Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo
Configuration:
Steps:
- Run: TIMESTAMP=$(date +%m-%d-%y-%H-%m-%s)
Outputs:
Variables:
- REPOSITORY-URI
- TIMESTAMP
```
## 예시: 동일한 작업에 정의된 변수 참조
다음 예시에서는 `MyBuildAction`에서 `VAR1` 변수를 지정한 다음 `$VAR1`를 사용하여 동일한 작업에서 변수를 참조하는 방법을 보여줍니다.
```
Actions:
MyBuildAction:
Identifier: aws/build@v1
Inputs:
Variables:
- Name: VAR1
Value: my-value
Configuration:
Steps:
- Run: $VAR1
```
## 예시: 다른 작업에 정의된 변수 참조
다음 예시에서는 `BuildActionA`에서 `TIMESTAMP` 변수를 지정하고 `Outputs` 속성을 사용하여 내보낸 다음 `${BuildActionA.TIMESTAMP}`를 사용하여 `BuildActionB`에서 참조하는 방법을 보여줍니다.
```
Actions:
BuildActionA:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: TIMESTAMP=$(date +%m-%d-%y-%H-%m-%s)
Outputs:
Variables:
- TIMESTAMP
BuildActionB:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: docker build -t my-ecr-repo/image-repo:latest .
- Run: docker tag my-ecr-repo/image-repo:${BuildActionA.TIMESTAMP}
# Specifying just '$TIMESTAMP' here will not work
# because TIMESTAMP is not a variable
# in the BuildActionB action.
```
## 예시: 보안 암호 참조
다음 예시에서는 `my-password` 보안 암호를 참조하는 방법을 보여줍니다. `my-password`는 보안 암호의 키입니다. 이 보안 암호의 키와 해당 암호 값은 워크플로 정의 파일에서 사용하기 전에 CodeCatalyst 콘솔의 **보안 암호** 페이지에서 지정해야 합니다. 자세한 내용은 [보안 암호를 사용하여 데이터 마스킹](workflows-secrets.md) 섹션을 참조하세요.
```
Actions:
BuildActionA:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: curl -u LiJuan:${Secrets.my-password} https://example.com
```
# 변수 정의
두 가지 방법으로 변수를 정의할 수 있습니다.
+ 워크플로 작업 `Inputs` 섹션의 - ['입력' 섹션의 변수 정의](#workflows-to-define-variable-input)를 참조하세요.
+ 워크플로 작업 `Steps` 섹션의 - ['단계' 섹션의 변수 정의](#workflows-to-define-variable-steps)를 참조하세요.
**참고**
이 `Steps` 메서드는 CodeCatalyst 빌드, 테스트 및 **GitHub Actions** 작업에서만 작동합니다. `Steps` 섹션이 포함된 유일한 작업이기 때문입니다.
예시는 [변수의 예](workflows-working-with-variables-ex.md) 섹션을 참조하세요.
변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
------
#### [ Visual ]
**'입력' 섹션에서 변수 정의(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 변수를 설정하려는 작업을 선택합니다.
1. **입력**을 선택합니다.
1. **변수 - 선택 사항**에서 **변수 추가**를 선택한 후 다음을 수행합니다.
작업에 사용할 수 있도록 하려는 입력 변수를 정의하는 이름/값 페어의 시퀀스를 지정합니다. 변수 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 변수 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
예시를 비롯한 변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**'입력' 섹션에서 변수 정의(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 워크플로 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Inputs:
Variables:
- Name: variable-name
Value: variable-value
```
더 많은 예시는 [변수의 예](workflows-working-with-variables-ex.md)를 참조합니다. 자세한 내용은 작업에 해당하는 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
------
#### [ Visual ]
**'단계' 섹션에서 변수 정의(시각 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 변수를 설정하려는 작업을 선택합니다.
1. **구성**을 선택합니다.
1. 사용 가능한 **쉘 명령** 또는 **GitHub Actions YAML** 중 하나에서 명시적으로 또는 암시적으로 작업 `Steps`의 변수를 정의합니다.
+ 변수를 명시적으로 정의하려면 `Steps` 섹션으로 직접 bash 명령에 포함시킵니다.
+ 변수를 암시적으로 정의하려면 작업의 `Steps` 섹션에서 참조하는 파일에 변수를 지정합니다.
예시는 [변수의 예](workflows-working-with-variables-ex.md) 섹션을 참조하세요. 자세한 내용은 작업에 해당하는 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**'단계' 섹션에서 변수 정의(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 워크플로 작업에서 작업의 `Steps` 섹션에서 변수를 명시적으로 또는 암시적으로 정의합니다.
+ 변수를 명시적으로 정의하려면 `Steps` 섹션으로 직접 bash 명령에 포함시킵니다.
+ 변수를 암시적으로 정의하려면 작업의 `Steps` 섹션에서 참조하는 파일에 변수를 지정합니다.
예시는 [변수의 예](workflows-working-with-variables-ex.md) 섹션을 참조하세요. 자세한 내용은 작업에 해당하는 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 보안 암호 정의
CodeCatalyst 콘솔의 **보안 암호** 페이지에서 보안 암호를 정의합니다. 자세한 내용은 [보안 암호를 사용하여 데이터 마스킹](workflows-secrets.md) 섹션을 참조하세요.
예를 들어 보안 암호는 다음과 같이 정의할 수 있습니다.
+ 이름(키): **my-password**
+ 값: **^\$1H3\$1\$1b9**
보안 암호가 정의된 후 워크플로 정의 파일에 보안 암호 키(**my-password**)를 지정할 수 있습니다. 이렇게 하는 방법의 예는 [예시: 보안 암호 참조](workflows-working-with-variables-ex.md#workflows-working-with-variables-ex-refer-secret) 섹션을 참조하세요.
# 다른 작업에서 사용할 수 있도록 변수 내보내기
다음 지침에 따라 작업에서 변수를 내보내 다른 작업에서 참조할 수 있도록 합니다.
변수를 내보내기 전에 다음 사항에 유의하세요.
+ 변수가 정의된 작업 내에서 변수를 참조하기만 하면 되는 경우에는 내보낼 필요가 없습니다.
+ 모든 작업이 변수 내보내기를 지원하는 것은 아닙니다. 작업이 이 특성을 지원하는지 확인하려면 다음 시각적 편집기 지침을 실행하고 작업에 **출력** 탭의 **변수** 버튼이 포함되어 있는지 확인합니다. 그렇다면 변수 내보내기가 지원됩니다.
+ GitHub 작업에서 변수를 내보내려면 [GitHub 출력 파라미터 내보내기](integrations-github-action-export.md) 섹션을 참조하세요.
변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
**사전 조건**
내보낼 변수를 정의했는지 확인합니다. 자세한 내용은 [변수 정의](workflows-working-with-variables-define-input.md) 섹션을 참조하세요.
------
#### [ Visual ]
**변수 내보내기(시각적 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **비주얼**을 선택합니다.
1. 워크플로 다이어그램에서 변수를 내보낼 작업을 선택합니다.
1. **출력**을 선택합니다.
1. **변수 - 선택 사항**에서 **변수 추가**를 선택한 후 다음을 수행합니다.
작업을 내보낼 변수의 이름을 지정합니다. 이 변수는 동일한 작업의 `Inputs` 또는 `Steps` 섹션에 이미 정의되어 있어야 합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
#### [ YAML ]
**변수 내보내기(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 변수를 내보내려는 작업에서 다음과 유사한 코드를 추가합니다.
```
action-name:
Outputs:
Variables:
- Name: variable-name
```
더 많은 예시는 [변수의 예](workflows-working-with-variables-ex.md)를 참조합니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 변수를 정의하는 작업에서 변수 참조
다음 지침에 따라 변수를 정의하는 작업에서 변수를 참조합니다.
**참고**
GitHub 작업에서 생성된 변수를 참조하려면 [GitHub 출력 파라미터 참조](integrations-github-action-referencing.md) 섹션을 참조하세요.
변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
**사전 조건**
참조하려는 변수를 정의했는지 확인합니다. 자세한 내용은 [변수 정의](workflows-working-with-variables-define-input.md) 섹션을 참조하세요.
------
#### [ Visual ]
*사용할 수 없습니다. YAML을 선택하여 YAML 지침을 봅니다.*
------
#### [ YAML ]
**변수를 정의하는 작업에서 변수 참조**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 참조하려는 변수를 정의하는 CodeCatalyst 액션에서 다음 bash 구문을 사용하여 변수를 추가합니다.
```
$variable-name
```
예제:
```
MyAction:
Configuration:
Steps:
- Run: $variable-name
```
더 많은 예시는 [변수의 예](workflows-working-with-variables-ex.md)를 참조합니다. 자세한 내용은 [워크플로 YAML 정의](workflow-reference.md)에서 작업에 대한 참조 정보를 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 다른 작업에 의한 변수 출력 참조
다음 지침에 따라 다른 작업의 변수를 참조합니다.
**참고**
GitHub 작업의 변수 출력을 참조하려면 [GitHub 출력 파라미터 참조](integrations-github-action-referencing.md) 섹션을 참조하세요.
변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
**사전 조건**
참조하려는 변수를 내보냈는지 확인합니다. 자세한 내용은 [다른 작업에서 사용할 수 있도록 변수 내보내기](workflows-working-with-variables-export-input.md) 섹션을 참조하세요.
------
#### [ Visual ]
*사용할 수 없습니다. YAML을 선택하여 YAML 지침을 봅니다.*
------
#### [ YAML ]
**다른 작업의 변수 출력 참조(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. CodeCatalyst 작업에서 다음 구문을 사용하여 변수에 대한 참조를 추가합니다.
```
${action-group-name.action-name.variable-name}
```
다음과 같이 바꿉니다.
+ 변수를 출력하는 작업이 포함된 작업 그룹의 이름이 포함된 *action-group-name*입니다.
**참고**
작업 그룹이 없거나 변수가 동일한 작업 그룹의 작업에서 생성되는 경우 *action-group-name*을 생략할 수 있습니다.
+ *action-name*을 변수를 출력하는 작업의 이름으로 바꿉니다.
+ *variable-nam*을 변수 이름으로 바꿉니다.
예제:
```
MySecondAction:
Configuration:
Steps:
- Run: ${MyFirstAction.TIMESTAMP}
```
더 많은 예시는 [변수의 예](workflows-working-with-variables-ex.md)를 참조합니다. 자세한 내용은 작업에 해당하는 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 보안 암호 참조
워크플로 정의 파일에서 보안 암호 참조에 대한 지침은 [보안 암호 사용](workflows-secrets.using.md) 섹션을 참조하세요.
관련 예시는 [예시: 보안 암호 참조](workflows-working-with-variables-ex.md#workflows-working-with-variables-ex-refer-secret) 섹션을 참조하세요
# 사전 정의된 변수 사용
*사전 정의된 변수*는 워크플로에서 자동으로 내보내고 워크플로 작업에 사용할 수 있는 키-값 페어입니다.
변수에 대한 자세한 내용은 [워크플로에서 변수 사용](workflows-working-with-variables.md) 섹션을 참조하세요.
**Topics**
+ [사전 정의된 변수 참조의 예](workflows-predefined-examples.md)
+ [사전 정의된 변수 참조](workflows-working-with-variables-reference-output-vars.md)
+ [워크플로에서 내보내는 사전 정의된 변수 확인](workflows-working-with-variables-determine-output-vars.md)
+ [사전 정의된 변수 목록](workflow-ref-action-variables.md)
# 사전 정의된 변수 참조의 예
다음 예시에서는 워크플로 정의 파일에서 사전 정의된 변수를 참조하는 방법을 보여줍니다.
사전 정의된 변수에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
**Topics**
+ [예시: 'CommitId' 사전 정의된 변수 참조](#workflows-working-with-variables-ex-refer-action)
+ [예시: 'BranchName' 사전 정의된 변수 참조](#workflows-working-with-variables-ex-branch)
## 예시: 'CommitId' 사전 정의된 변수 참조
다음 예시에서는 `MyBuildAction` 작업에서 사전 정의된 `CommitId` 변수를 참조하는 방법을 보여줍니다. `CommitId` 변수는 CodeCatalyst에서 자동으로 출력됩니다. 자세한 내용은 [사전 정의된 변수 목록](workflow-ref-action-variables.md) 섹션을 참조하세요.
예시에서는 빌드 작업에서 사용되는 변수를 보여주지만 모든 작업에서 `CommitId`를 사용할 수 있습니다.
```
MyBuildAction:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
#Build Docker image and tag it with a commit ID
- Run: docker build -t image-repo/my-docker-image:latest .
- Run: docker tag image-repo/my-docker-image:${WorkflowSource.CommitId}
```
## 예시: 'BranchName' 사전 정의된 변수 참조
다음 예시에서는 `CDKDeploy` 작업에서 사전 정의된 `BranchName` 변수를 참조하는 방법을 보여줍니다. `BranchName` 변수는 CodeCatalyst에서 자동으로 출력됩니다. 자세한 내용은 [사전 정의된 변수 목록](workflow-ref-action-variables.md) 섹션을 참조하세요.
예시에서는 **AWS CDK 배포** 작업에 사용되는 변수를 보여 주지만, 모든 작업에서 `BranchName`을 사용할 수 있습니다.
```
CDKDeploy:
Identifier: aws/cdk-deploy@v2
Inputs:
Sources:
- WorkflowSource
Configuration:
StackName: app-stack-${WorkflowSource.BranchName}
```
# 사전 정의된 변수 참조
Amazon CodeCatalyst 워크플로 내의 모든 작업에서 사전 정의된 변수를 참조할 수 있습니다.
다음 지침에 따라 워크플로에서 사전 정의된 변수를 참조합니다.
사전 정의된 변수에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
**사전 조건**
`CommitId`와 같이 참조하려는 사전 정의된 변수의 이름을 결정합니다. 자세한 내용은 [워크플로에서 내보내는 사전 정의된 변수 확인](workflows-working-with-variables-determine-output-vars.md) 섹션을 참조하세요.
------
#### [ Visual ]
*사용할 수 없습니다. YAML을 선택하여 YAML 지침을 봅니다.*
------
#### [ YAML ]
**사전 정의된 변수 참조(YAML 편집기)**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. CodeCatalyst 작업에서 다음 구문을 사용하여 사전 정의된 변수 참조를 추가합니다.
```
${action-group-name.action-name-or-WorkflowSource.variable-name}
```
다음과 같이 바꿉니다.
+ *action-group-name*: 작업 이름의 그룹.
**참고**
작업 그룹이 없거나 변수가 동일한 작업 그룹의 작업에서 생성되는 경우 *action-group-name*을 생략할 수 있습니다.
+ *action-name-or-WorkflowSource*:
변수를 출력하는 작업의 이름.
또는
`WorkflowSource`, 변수가 `BranchName` 또는 `CommitId` 변수인 경우.
+ *variable-nam*을 변수 이름으로 바꿉니다.
예제:
```
MySecondAction:
Configuration:
Steps:
- Run: echo ${MyFirstECSAction.cluster}
```
또 다른 예시:
```
MySecondAction:
Configuration:
Steps:
- Run: echo ${WorkflowSource.CommitId}
```
더 많은 예시는 [사전 정의된 변수 참조의 예](workflows-predefined-examples.md)를 참조합니다. 자세한 내용은 작업에 해당하는 [워크플로 YAML 정의](workflow-reference.md) 섹션을 참조하세요.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
------
# 워크플로에서 내보내는 사전 정의된 변수 확인
다음 절차를 사용하여 워크플로가 실행될 때 내보내는 사전 정의된 변수를 결정합니다. 그런 다음 동일한 워크플로 내에서 이러한 변수를 참조할 수 있습니다.
사전 정의된 변수에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
**워크플로에서 내보내는 사전 정의된 변수 확인**
+ 다음 중 하나를 수행하세요.
+ **워크플로를 한 번 실행합니다**. 실행이 완료되면 워크플로에서 내보내는 변수가 실행 세부 정보 페이지의 **변수** 탭에 표시됩니다. 자세한 내용은 [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md) 섹션을 참조하세요.
+ **[사전 정의된 변수 목록](workflow-ref-action-variables.md) 섹션을 참조하세요**. 이 참조에는 사전 정의된 각 변수의 변수 이름(키)과 값이 나열됩니다.
**참고**
워크플로 변수의 최대 총 크기는 [CodeCatalyst의 워크플로 할당량](workflows-quotas.md)에 나열되어 있습니다. 총 크기가 최대값을 초과하면 최대값에 도달한 후 발생하는 작업이 실패할 수 있습니다.
# 사전 정의된 변수 목록
다음 섹션을 참조하여 워크플로 실행의 일부로 CodeCatalyst 작업에 의해 자동으로 생성되는 사전 정의된 변수를 확인하세요.
사전 정의된 변수에 대한 자세한 내용은 [사전 정의된 변수 사용](workflows-using-predefined-variables.md) 섹션을 참조하세요.
**참고**
이 목록에는 CodeCatalyst 소스 및 [CodeCatalyst 작업](workflows-actions.md#workflows-actions-types)에서 내보내는 사전 정의된 변수만 포함됩니다. GitHub Actions 또는 CodeCatalyst Labs 작업과 같은 다른 유형의 작업을 사용하는 경우 대신 [워크플로에서 내보내는 사전 정의된 변수 확인](workflows-working-with-variables-determine-output-vars.md)를 참조하세요.
**나열**
**참고**
모든 CodeCatalyst 작업이 사전 정의된 변수를 생성하는 것은 아닙니다. 작업이 목록에 없으면 변수가 생성되지 않습니다.
+ ['BranchName' 및 'CommitId' 변수](workflows-sources-variables.md)
+ ['스 CloudFormation 택 배포' 변수](deploy-action-cfn-variables.md)
+ ['Amazon ECS에 배포' 변수](deploy-action-ecs-variables.md)
+ ['Kubernetes 클러스터에 배포' 변수](deploy-action-eks-variables.md)
+ ['AWS CDK 배포' 변수](cdk-dep-action-variables.md)
+ ['AWS CDK 부트스트랩' 변수](cdk-boot-action-variables.md)
+ ['AWS Lambda 간접 호출' 변수](lam-invoke-action-variables.md)
+ ['Amazon ECS 작업 정의 렌더링' 변수](render-ecs-action-variables.md)
# 보안 암호를 사용하여 데이터 마스킹
워크플로에서 인증 자격 증명과 같은 민감한 데이터를 사용해야 하는 경우가 있을 수 있습니다. 보안 암호가 포함된 리포지토리에 액세스할 수 있는 사람은 누구나 볼 수 있으므로 이러한 값을 리포지토리 어디에도 일반 텍스트로 저장하는 것은 피해야 합니다. 마찬가지로 이러한 값은 리포지토리에 파일로 표시되므로 워크플로 정의에 직접 사용해서는 안 됩니다. CodeCatalyst를 사용하면 프로젝트에 보안 암호를 추가한 다음 워크플로 정의 파일에서 암호를 참조하여 이러한 값을 보호할 수 있습니다. 작업당 최대 5개의 보안 암호를 사용할 수 있습니다.
**참고**
보안 암호는 워크플로 정의 파일의 암호 및 민감한 정보를 대체하는 데만 사용할 수 있습니다.
**Topics**
+ [보안 암호 생성](workflows-secrets.creating.md)
+ [보안 암호 편집](workflows-secrets.editing.md)
+ [보안 암호 사용](workflows-secrets.using.md)
+ [보안 암호 삭제](workflows-secrets.deleting.md)
# 보안 암호 생성
다음 절차에 따라 보안 암호를 생성합니다. 보안 암호에는 보이지 않게 숨기고 싶은 민감한 정보가 포함되어 있습니다.
**참고**
보안 암호는 작업에 표시되며 파일에 기록될 때 가려지지 않습니다.
**보안 암호 생성**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 후, **보안 암호**를 선택합니다.
1. **보안 암호 생성**을 선택합니다.
1. 다음 정보를 입력합니다.
**이름**
보안 암호의 이름을 입력합니다.
**값**
보안 암호 값을 입력합니다. 표시되지 않도록 숨기고 싶은 민감한 정보입니다. 기본적으로 값은 표시되지 않습니다. 값을 표시하려면 **값 표시**를 선택합니다.
**설명**
(선택 사항) 보안 암호에 대한 설명을 입력합니다.
1. **생성(Create)**을 선택합니다.
# 보안 암호 편집
보안 암호를 편집하려면 다음 절차에 따르세요.
**보안 암호 편집**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 후, **보안 암호**를 선택합니다.
1. 보안 암호 목록에서 편집할 보안 암호를 선택합니다.
1. **편집**을 선택합니다.
1. 다음 속성을 참조하세요.
**값**
보안 암호 값을 입력합니다. 이 값은 표시되지 않도록 숨기려는 값입니다. 기본적으로 값은 표시되지 않습니다.
**설명**
(선택 사항) 보안 암호에 대한 설명을 입력합니다.
1. **저장**을 선택합니다.
# 보안 암호 사용
워크플로 작업에서 보안 암호를 사용하려면 암호의 참조 식별자를 얻은 다음 워크플로 작업에서 해당 식별자를 사용해야 합니다.
**Topics**
+ [보안 암호의 식별자 가져오기](#workflows-using-secrets.get-identifier)
+ [워크플로에서 보안 암호 참조](#workflows-using-secrets.using-identifier)
## 보안 암호의 식별자 가져오기
다음 절차에 따라 보안 암호의 참조 식별자를 가져옵니다. 워크플로에 이 식별자를 추가합니다.
**보안 암호의 참조 식별자 가져오기**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 후, **보안 암호**를 선택합니다.
1. 보안 암호 목록에서 사용하려는 보안 암호를 찾습니다.
1. **참조 ID** 열에서 보안 암호의 식별자를 복사합니다. 다음은 **참조 ID**의 구문입니다.
```
${Secrets.}
```
## 워크플로에서 보안 암호 참조
다음 절차에 따라 워크플로에서 보안 암호를 참조합니다.
**보안 암호 참조**
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 보안 암호의 식별자를 사용하도록 YAML을 수정합니다. 예를 들어 보안 암호로 저장된 사용자 이름과 암호를 `curl` 명령에 사용하려면 다음과 유사한 `Run` 명령을 사용합니다.
```
- Run: curl -u : https://example.com
```
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
# 보안 암호 삭제
다음 절차에 따라 보안 암호와 보안 암호 참조 식별자를 삭제합니다.
**참고**
보안 암호를 삭제하기 전에 모든 워크플로 작업에서 해당 보안 암호의 참조 식별자를 제거하는 것이 좋습니다. 참조 식별자를 삭제하지 않고 보안 암호를 삭제하면 다음에 실행할 때 작업이 실패합니다.
**워크플로에서 보안 암호의 참조 식별자 삭제**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
1. **편집**을 선택합니다.
1. **YAML**을 선택합니다.
1. 워크플로에서 다음 문자열을 검색합니다.
```
${Secrets.
```
이렇게 하면 모든 보안 암호의 모든 참조 식별자가 검색됩니다.
1. 선택한 보안 암호의 참조 식별자를 삭제하거나 일반 텍스트 값으로 바꿉니다.
1. (선택 사항) 커밋하기 전에 워크플로의 YAML 코드를 검증하려면 **검증**을 선택합니다.
1. **커밋**을 선택하고 커밋 메시지를 입력한 다음 **커밋**을 다시 선택합니다.
**보안 암호를 삭제하려면**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 탐색 창에서 **CI/CD**를 선택한 후, **보안 암호**를 선택합니다.
1. 보안 암호 목록에서 삭제할 보안 암호를 선택합니다.
1. **삭제**를 선택합니다.
1. **delete**를 입력하여 삭제를 확인합니다.
1. **삭제**를 선택합니다.
# 워크플로의 상태 보기
워크플로 상태를 확인하여 해결해야 할 워크플로 구성 문제가 있는지 확인하거나 시작에 실패하는 실행 문제를 해결하려고 할 수 있습니다. CodeCatalyst는 워크플로의 기본 워크플로 [정의 파일](workflows-concepts.md#workflows-concepts-workflows-def)을 생성하거나 업데이트할 때마다 워크플로 상태를 평가합니다.
**참고**
워크플로 상태와 다른 워크플로의 *실행* 상태를 볼 수도 있습니다. 자세한 내용은 [워크플로 실행 상태 및 세부 정보 보기](workflows-view-run.md) 섹션을 참조하세요.
가능한 워크플로 상태 목록은 [CodeCatalyst의 워크플로 상태](workflows-workflow-status.md) 섹션을 참조하세요.
**워크플로 상태 보기**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/)에서 CodeCatalyst 콘솔을 엽니다.
1. 프로젝트를 선택합니다.
1. 탐색 창에서 **CI/CD**를 선택한 다음 **워크플로**를 선택합니다.
1. 워크플로의 이름을 선택합니다. 소스 리포지토리 또는 워크플로가 정의된 브랜치 이름을 기준으로 필터링하거나, 워크플로 이름 또는 상태를 기준으로 필터링할 수 있습니다.
상태는 목록에 워크플로와 함께 표시됩니다.
1. (선택 사항) 워크플로의 이름을 선택하고 **워크플로 정의** 필드를 찾습니다. 워크플로 상태를 보여줍니다.
# CodeCatalyst의 워크플로 할당량
다음 테이블에서는 Amazon CodeCatalyst의 워크플로에 대한 쿼터 및 제한에 대해 설명합니다.
Amazon CodeCatalyst의 할당량에 대한 자세한 내용은 [CodeCatalyst 할당량](quotas.md) 섹션을 참조하세요.
| | |
| --- |--- |
| 스페이스당 최대 워크플로 수 | 800 |
| 최대 워크플로 정의 파일 크기 | 256KB |
| 단일 소스 이벤트에서 처리된 최대 워크플로 파일 수 | 50 |
| 단일 소스 이벤트에서 처리된 최대 파일 수 | 4,000 |
| 스페이스당 최대 활성 플릿 수 | 10 |
| 플릿당 최대 활성 컴퓨팅 인스턴스 수 | 20 |
| 작업당 최대 입력 아티팩트 수 | 10 |
| 작업당 최대 출력 아티팩트 수 | 10 |
| 단일 작업의 출력 변수의 최대 총 크기 | 120KB |
| 출력 변수 값의 최대 길이 | 값을 내보내는 작업에 따라 500자 이상입니다. 값이 작업의 한도를 초과하면 값이 잘릴 수 있습니다. |
| 워크플로 실행 중 생성된 아티팩트를 보관할 수 있는 최대 일수 | 30 |
| 작업당 최대 보고서 수 | 50 |
| 테스트 보고서당 최대 테스트 사례 수 | 20,000건 |
| 코드 적용 범위 보고서당 최대 파일 수 | 20,000건 |
| 보고서당 최대 소프트웨어 구성 분석 조사 결과 수 | 20,000건 |
| 정적 분석 보고서당 최대 파일 수 | 20,000건 |
| 페이스당 최대 동시 워크플로 실행 수 | 100 |
| 워크플로당 최대 작업 수 | 50 |
| 워크플로당 동시에 실행 중인 최대 작업 수 | 50 |
| 스페이스당 동시에 실행 중인 최대 작업 수 | 200 |
| 작업이 실행될 수 있는 최대 시간 | 빌드 및 테스트 작업의 경우 제한 시간은 8시간입니다. 다른 모든 작업의 경우 제한 시간은 1시간입니다. |
| 스페이스당 AWS 계정 과 연결된 최대 환경 수 | 5,000 |
| 작업당 최대 보안 암호 수 | 5 |
| 스페이스당 최대 보안 암호 수 | 500,000 |
# 워크플로 실행 상태
워크플로 실행은 다음 상태 중 하나일 수 있습니다.
+ **성공** - 워크플로 실행이 성공적으로 처리되었습니다.
+ **실패** - 워크플로 실행에서 하나 이상의 작업이 실패했습니다.
+ **진행 중** - 워크플로 실행이 현재 처리 중입니다.
+ **중지됨** - 워크플로가 진행 중인 동안 사용자가 워크플로 실행을 중지했습니다.
+ **중지 중** - 워크플로 실행이 현재 중지 중입니다.
+ **취소됨** - 실행이 진행되는 동안 연결된 워크플로가 삭제되거나 업데이트되어 CodeCatalyst에서 워크플로 실행이 취소되었습니다.
+ **대체됨** - [대체된 실행 모드 ](workflows-configure-runs.md#workflows-configure-runs-superseded)를 구성한 경우에만 발생합니다. 이후 워크플로 실행이 워크플로 실행을 대체했기 때문에 CodeCatalyst에서 워크플로 실행을 취소했습니다.
# CodeCatalyst의 워크플로 상태
워크플로는 다음 중 하나의 상태를 가질 수 있습니다.
+ **유효** - 워크플로를 실행할 수 있으며 [트리거](workflows-add-trigger.md#workflows-add-trigger.title)로 활성화할 수 있습니다.
워크플로를 유효로 표시하려면 다음 두 조건이 모두 true여야 합니다.
+ 워크플로 정의 파일이 유효 상태여야 합니다.
+ 워크플로에는 트리거, 푸시 트리거 또는 현재 브랜치의 파일을 사용하여 실행되는 푸시 트리거가 없어야 합니다. 자세한 내용은 [트리거 및 브랜치 사용 지침](workflows-add-trigger-considerations.md) 섹션을 참조하세요.
+ **유효하지 않음** - 워크플로의 정의 파일이 유효하지 않습니다. 워크플로는 수동으로 실행하거나 트리거를 통해 자동으로 실행할 수 없습니다. 유효하지 않은 워크플로는 CodeCatalyst 콘솔에서 **Workflow definition has *n* errors**(또는 이와 유사한 메시지)와 함께 표시됩니다.
워크플로를 유효하지 않음으로 표시하려면 다음 조건이 true여야 합니다.
+ 워크플로 정의 파일은 잘못 구성된 상태여야 합니다.
잘못 구성된 워크플로 정의 파일을 수정하려면 ['Workflow definition has *n* errors' 오류를 해결하려면 어떻게 해야 하나요?](troubleshooting-workflows.md#troubleshooting-workflows-asterisks) 섹션을 참조하세요.
+ **비활성** - 워크플로 정의가 유효하지만 수동으로 실행하거나 트리거를 통해 자동으로 실행할 수 없습니다.
워크플로를 비활성으로 표시하려면 다음 두 조건이 모두 true여야 합니다.
+ 워크플로 정의 파일이 유효 상태여야 합니다.
+ 워크플로 정의 파일에는 워크플로 정의 파일이 현재 있는 브랜치와 다른 브랜치를 지정하는 푸시 트리거가 포함되어야 합니다. 자세한 내용은 [트리거 및 브랜치 사용 지침](workflows-add-trigger-considerations.md) 섹션을 참조하세요.
워크플로를 **비활성**에서 **활성**으로 전환하려면 ['Workflow is inactive' 메시지를 해결하려면 어떻게 해야 하나요?](troubleshooting-workflows.md#troubleshooting-workflows-inactive) 섹션을 참조하세요.
**참고**
**비활성** 상태의 워크플로가 많으면 보기에서 필터링할 수 있습니다. 비활성 워크플로를 필터링하려면 **워크플로** 페이지 상단의 **워크플로 필터링** 필드를 선택하고 **상태**를 선택한 다음 **Status \$1= Does not equal**을 선택한 다음 **비활성**을 선택합니다.
**참고**
워크플로에 나중에 제거할 리소스(예시: 패키지 리포지토리)가 지정되어 있는 경우 CodeCatalyst는 이 변경 사항을 감지하지 않고 워크플로를 계속 유효한 것으로 표시합니다. 이러한 유형의 문제는 워크플로가 실행될 때 발견됩니다.
# 워크플로 YAML 정의
다음은 워크플로 정의 파일의 참조 설명서입니다.
*워크플로 정의 파일*은 워크플로를 설명하는 YAML 파일입니다. 기본적으로 파일은 [소스 리포지토리](source-repositories.md)의 루트에 있는 `~/.codecatalyst/workflows/` 폴더에 저장됩니다. 파일은 확장자가 .yml 또는 .yaml일 수 있으며 확장자는 소문자여야 합니다.
워크플로 정의 파일을 생성하고 편집하기 위해 vim과 같은 편집기를 사용하거나, CodeCatalyst 콘솔의 시각적 편집기 또는 YAML 편집기를 사용할 수 있습니다. 자세한 내용은 [CodeCatalyst 콘솔의 시각적 및 YAML 편집기 사용](workflow.md#workflow.editors) 섹션을 참조하세요.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
**Topics**
+ [워크플로 정의 파일의 예시](#workflow.anatomy)
+ [구문 지침 및 규칙](#workflow.terms.syntax.conv)
+ [최상위 속성](#workflow.top.level)
## 워크플로 정의 파일의 예시
다음은 간단한 워크플로 정의 파일의 예시입니다. 여기에는 몇 가지 최상위 속성, `Triggers` 섹션, `Build` 및 `Test`의 두 가지 작업이 있는 `Actions` 섹션이 포함됩니다. 자세한 내용은 [워크플로 정의 파일 정보](workflow.md#workflow.example) 섹션을 참조하세요.
```
Name: MyWorkflow
SchemaVersion: 1.0
RunMode: QUEUED
Triggers:
- Type: PUSH
Branches:
- main
Actions:
Build:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: docker build -t MyApp:latest .
Test:
Identifier: aws/managed-test@v1
DependsOn:
- Build
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: npm install
- Run: npm run test
```
## 구문 지침 및 규칙
이 섹션에서는 워크플로 정의 파일의 구문 규칙과 이 참조 설명서에 사용된 이름 지정 규칙에 대해 설명합니다.
### YAML 구문 지침
워크플로 정의 파일은 YAML로 작성되고 [YAML 1.1 사양](https://yaml.org/spec/)을 따르므로 해당 사양에서 허용되는 모든 항목도 워크플로 YAML에서 허용됩니다. YAML을 처음 사용하는 경우 유효한 YAML 코드를 제공하기 위한 몇 가지 간단한 지침이 있습니다.
+ **대/소문자 구분**: 워크플로 정의 파일은 대/소문자를 구분하므로 이 설명서에 표시된 케이싱을 사용해야 합니다.
+ **특수 문자**: `{`, `}` , `[` , `]` , &, `*` , `#` , `?` , `|` , `-` , < , >, `=` , `!` , `%` , `@` , `:` , ``` ,`,` 등의 특수 문자가 포함된 속성 값을 따옴표 또는 큰따옴표로 묶어 사용하는 것이 좋습니다.
따옴표를 포함하지 않으면 이전에 나열된 특수 문자가 예상치 못한 방식으로 해석될 수 있습니다.
+ **속성 이름**: 속성 *names*(속성 *values*가 아님)은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 따옴표나 큰따옴표를 사용하여 속성 이름에 특수 문자와 공백을 사용할 수 없습니다.
허용되지 않음:
`'My#Build@action'`
`My#Build@action`
`My Build Action`
허용:
`My-Build-Action_1`
+ **이스케이프 코드**: 속성 값에 이스케이프 코드(예: `\n` 또는 `\t`)가 포함된 경우 다음 지침을 따릅니다.
+ 작은따옴표를 사용하여 이스케이프 코드를 문자열로 반환합니다. 예를 들어, `'my string \n my string'`, `my string \n my string` 문자열을 분환합니다.
+ 큰따옴표를 사용하여 이스케이프 코드를 구문 분석합니다. 예를 들어, `"my string \n my new line"`는 다음을 반환합니다.
```
my string
my new line
```
+ **설명**: `#`를 사용한 서문 설명입니다.
예제:
```
Name: MyWorkflow
# This is a comment.
SchemaVersion: 1.0
```
+ **트리플 대시(`---`)**: YAML 코드에 `---`를 사용하지 마세요. CodeCatalyst는 `---` 이후의 모든 항목을 무시합니다.
### 이름 지정 규칙
이 가이드에서는 *속성* 및 *섹션*이라는 용어를 사용하여 워크플로 정의 파일의 주요 항목을 참조합니다.
+ *속성*은 콜론(`:`)을 포함하는 모든 항목입니다. 예를 들어, 다음 코드 조각에서 `Name`, `SchemaVersion`, `RunMode`, `Type`, `Triggers` 및 `Branches` 속성은 모두 입니다.
+ *섹션*은 하위 속성이 있는 모든 속성입니다. 다음 코드 조각에는 `Triggers` 섹션이 하나 있습니다.
**참고**
이 가이드에서는 컨텍스트에 따라 '섹션'을 '속성'이라고 하며 그 반대로 볼 수 있습니다.
```
Name: MyWorkflow
SchemaVersion: 1.0
RunMode: QUEUED
Triggers:
- Type: PUSH
Branches:
- main
```
## 최상위 속성
다음은 워크플로 정의 파일의 최상위 속성에 대한 참조 설명서입니다.
```
# Name
Name: workflow-name
# Schema version
SchemaVersion: 1.0
# Run mode
RunMode: QUEUED|SUPERSEDED|PARALLEL
# Compute
Compute:
...
# Triggers
Triggers:
...
# Actions
Actions:
...
```
### Name
(필수)
워크플로의 이름입니다. 워크플로 이름은 워크플로 목록에 표시되고 알림 및 로그에 언급됩니다. 워크플로 이름과 워크플로 정의 파일 이름이 일치하거나 이름을 다르게 지정할 수 있습니다. 워크플로 이름은 고유하지 않아도 됩니다. 워크플로 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 워크플로 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
해당 UI: 시각적 편집기/워크플로 속성/**워크플로 이름**
### SchemaVersion
(필수)
워크플로 정의의 스키마 버전입니다. 현재 유일한 유효 값은 `1.0`입니다.
해당 UI: *없음*
### RunMode
(선택 사항)
CodeCatalyst가 여러 실행을 처리하는 방법. 다음 값 중 하나를 사용할 수 있습니다.
+ `QUEUED` - 여러 실행이 대기 중이고 하나씩 실행됩니다. 대기열에서 최대 50회까지 실행할 수 있습니다.
+ `SUPERSEDED` - 여러 실행이 대기 중이고 하나씩 실행됩니다. 대기열은 한 번만 실행할 수 있으므로 두 개의 실행이 같은 대기열에서 동시에 종료되면, 나중에 실행된 것이 먼저 실행된 것을 대체(인계)하고, 먼저 실행된 것은 취소됩니다.
+ `PARALLEL` – 여러 번 동시에 실행됩니다.
생략 시 기본값은 `QUEUED`입니다.
자세한 내용은 [실행의 대기열 동작 구성](workflows-configure-runs.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 속성/고급/**실행 모드**
### Compute
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
컴퓨팅에 대한 자세한 내용은 [컴퓨팅 및 런타임 이미지 구성](workflows-working-compute.md) 섹션을 참조하세요.
해당 UI: *없음*
```
Name: MyWorkflow
SchemaVersion: 1.0
...
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
SharedInstance: true | false
```
#### Type
(Compute/**Type**)
(`Compute`로 설정된 경우 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 시각적 편집기/워크플로 속성/고급/**컴퓨팅 유형**
#### Fleet
(Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `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`입니다.
컴퓨팅 플릿에 대한 자세한 내용은 [컴퓨팅 플릿](workflows-working-compute.md#compute.fleets) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 속성/고급/**컴퓨팅 플릿**
#### SharedInstance
(Compute/**SharedInstance**)
(선택 사항)
작업에 대한 컴퓨팅 공유 기능을 지정합니다. 컴퓨팅 공유를 사용하면 워크플로의 작업이 동일한 인스턴스(런타임 환경 이미지)에서 실행됩니다. 다음 값 중 하나를 사용할 수 있습니다.
+ `TRUE`는 런타임 환경 이미지가 워크플로 작업 간에 공유됨을 의미합니다.
+ `FALSE`는 워크플로의 각 작업에 대해 별도의 런타임 환경 이미지가 시작되고 사용되므로 추가 구성 없이 아티팩트 및 변수와 같은 리소스를 공유할 수 없음을 의미합니다.
컴퓨팅 공유에 대한 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
### Triggers
(선택 사항)
이 워크플로를 위한 하나 이상의 트리거의 순서입니다. 트리거가 지정되지 않은 경우, 수동으로 워크플로를 시작해야 합니다.
트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/**트리거**
```
Name: MyWorkflow
SchemaVersion: 1.0
...
Triggers:
- Type: PUSH
Branches:
- branch-name
FilesChanged:
- folder1/file
- folder2/
- Type: PULLREQUEST
Events:
- OPEN
- CLOSED
- REVISION
Branches:
- branch-name
FilesChanged:
- file1.txt
- Type: SCHEDULE
# Run the workflow at 10:15 am (UTC+0) every Saturday
Expression: "15 10 ? * 7 *"
Branches:
- branch-name
```
#### Type
(Triggers/**Type**)
(`Triggers`로 설정된 경우 필수)
트리거 유형을 지정합니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **푸시**(시각적 편집기) 또는 `PUSH`(YAML 편집기)
푸시 트리거는 변경 사항이 소스 리포지토리로 푸시될 때 워크플로 실행을 시작합니다. 워크플로 실행은 푸시 *대상* 브랜치(즉, 대상 브랜치)의 파일을 사용합니다.
+ **풀 요청**(시각적 편집기) 또는 `PULLREQUEST`(YAML 편집기)
풀 요청 트리거는 소스 리포지토리에서 풀 요청이 열리거나 업데이트되거나 닫힐 때 워크플로 실행을 시작합니다. 워크플로 실행은 *가져오려는* 브랜치(즉, 소스 브랜치)의 파일을 사용합니다.
+ **일정**(시각적 편집기) 또는 `SCHEDULE`(YAML 편집기)
일정 트리거는 지정한 cron 표현식으로 정의된 일정에 따라 워크플로를 실행합니다. 브랜치 파일을 사용하여 소스 리포지토리의 각 브랜치에 대해 별도의 워크플로 실행이 시작됩니다. (트리거가 활성화되는 브랜치를 제한하려면 **브랜치** 필드(시각적 편집기) 또는 `Branches` 속성(YAML 편집기)을 사용합니다.)
일정 트리거를 구성할 때는 다음 지침을 따르세요.
+ 워크플로당 하나의 일정 트리거만 사용합니다.
+ CodeCatalyst 스페이스에 여러 워크플로를 정의한 경우 동시에 시작하도록 10개 이하로 예약하는 것이 좋습니다.
+ 실행 사이에 충분한 시간을 두고 트리거의 cron 표현식을 구성해야 합니다. 자세한 내용은 [Expression](#workflow.triggers.expression) 섹션을 참조하세요.
예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/트리거/**트리거 유형**
#### Events
(Triggers/**Events**)
(`Type` 트리거가 `PULLREQUEST`로 설정된 경우 필수)
워크플로 실행을 시작할 풀 요청 이벤트의 유형을 지정합니다. 유효한 값은 다음과 같습니다.
+ **풀 요청이 생성됨**(시각적 편집기) 또는 `OPEN`(YAML 편집기)
풀 요청이 생성되면 워크플로 실행이 시작됩니다.
+ **풀 요청이 닫힘**(시각적 편집기) 또는 `CLOSED`(YAML 편집기)
풀 요청이 종료되면 워크플로 실행이 시작됩니다. `CLOSED` 이벤트의 동작은 까다롭고 예시를 통해 가장 잘 이해됩니다. 자세한 정보는 [예시: 풀, 브랜치 및 'CLOSED' 이벤트가 있는 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close)을 참조하세요.
+ **풀 요청에 대한 새 개정**(시각적 편집기) 또는 `REVISION`(YAML 편집기)
워크플로 실행은 풀 요청에 대한 개정이 생성될 때 시작됩니다. 풀 요청이 생성되면 첫 번째 개정이 생성됩니다. 그런 다음 풀 요청에 지정된 소스 브랜치에 새 커밋을 푸시할 때마다 새 개정이 생성됩니다. 풀 요청 트리거에 `REVISION` 이벤트를 포함하는 경우 `REVISION`는 `OPEN`의 수퍼 세트이므로 `OPEN` 이벤트를 생략할 수 있습니다.
동일한 풀 요청 트리거에서 여러 이벤트를 지정할 수 있습니다.
예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/트리거/**풀 요청을 위한 이벤트**
#### Branches
(Triggers/**Branches**)
(선택 사항)
워크플로 실행을 시작할 시기를 알기 위해 트리거가 모니터링하는 소스 리포지토리의 브랜치를 지정합니다. 정규식 패턴을 사용하여 브랜치 이름을 정의할 수 있습니다. 예를 들어 `main.*`을 사용하여 `main`으로 시작하는 모든 브랜치를 일치시킵니다.
지정할 브랜치는 트리거 유형에 따라 다릅니다.
+ 푸시 트리거의 경우 푸시 *대상* 브랜치, 즉 *대상* 브랜치를 지정합니다. 일치하는 브랜치의 파일을 사용하여 일치하는 브랜치당 하나의 워크플로 실행이 시작됩니다.
예시: `main.*`, `mainline`
+ 풀 요청의 경우 *푸시할* 브랜치, 즉 *대상* 브랜치를 지정합니다. 워크플로 정의 파일과 소스 브랜치(일치하는 브랜치 *아님*)의 **소스** 파일을 사용하여 일치하는 브랜치당 하나의 워크플로 실행이 시작됩니다.
예시: `main.*`, `mainline`, `v1\-.*`(`v1-`로 시작하는 브랜치와 일치)
+ 일정 트리거의 경우 예약된 실행에서 사용할 파일이 포함된 브랜치를 지정합니다. 워크플로 정의 파일과 일치하는 브랜치의 소스 파일을 사용하여 일치하는 브랜치당 하나의 워크플로 실행이 시작됩니다.
예시: `main.*`, `version\-1\.0`
**참고**
브랜치를 지정하지 *않으면* 트리거는 소스 리포지토리의 모든 브랜치를 모니터링하고 다음에서 워크플로 정의 파일 및 소스 파일을 사용하여 워크플로 실행을 시작합니다.
푸시 *대상* 브랜치(푸시 트리거용). 자세한 내용은 [예시: 간단한 코드 푸시 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple) 섹션을 참조하세요.
풀 *원본* 브랜치(풀 요청 트리거용). 자세한 내용은 [예시: 간단한 풀 요청 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple) 섹션을 참조하세요.
모든 브랜치(일정 트리거용). 소스 리포지토리의 브랜치당 워크플로 실행이 한 번 시작됩니다. 자세한 내용은 [예시: 간단한 일정 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple) 섹션을 참조하세요.
브랜치 및 트리거에 대한 자세한 내용은 [트리거 및 브랜치 사용 지침](workflows-add-trigger-considerations.md) 섹션을 참조하세요.
더 많은 예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md)를 참조합니다.
해당 UI: 시각 편집기/워크플로 다이어그램/트리거/**브랜치**
#### FilesChanged
(Triggers/**FilesChanged**)
(`Type` 트리거가 `PUSH` 또는 `PULLREQUEST`로 설정된 경우 선택 사항. `Type` 트리거가 `SCHEDULE`로 설정된 경우에는 지원되지 않음)
워크플로 실행을 시작해야 하는 시기를 알 수 있도록 트리거가 모니터링하는 소스 리포지토리의 파일 또는 폴더를 지정합니다. 정규식을 사용하여 파일 이름 또는 경로와 일치시킬 수 있습니다.
예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/트리거/**파일 변경됨**
#### Expression
(Triggers/**Expression**)
(`Type` 트리거가 `SCHEDULE`로 설정된 경우 필수)
예약된 워크플로 실행 시기를 설명하는 cron 표현식을 지정합니다.
CodeCatalyst의 Cron 표현식은 다음과 같은 6개 필드 구문을 사용합니다. 여기서 각 필드는 공백으로 구분됩니다.
*minutes* *hours* *days-of-month* *month* *days-of-week* *year*
**cron 표현식의 예**
| 분 | 시간 | 일 | 월 | 요일 | 연도 | 의미 |
| --- | --- | --- | --- | --- | --- | --- |
| 0 | 0 | ? | \$1 | 월-금 | \$1 | 매주 월요일부터 금요일까지 자정(UTC\$10)에 워크플로를 실행합니다. |
| 0 | 2 | \$1 | \$1 | ? | \$1 | 매일 오전 2시(UTC\$10)에 워크플로를 실행합니다. |
| 15 | 22 | \$1 | \$1 | ? | \$1 | 매일 오후 10:15(UTC\$10)에 워크플로를 실행합니다. |
| 0/30 | 22-2 | ? | \$1 | 토-일 | \$1 | 시작일 오후 10시부터 다음 날 오전 2시(UTC\$10) 사이에 토요일부터 일요일까지 30분마다 워크플로를 실행합니다. |
| 45 | 13 | L | \$1 | ? | 2023-2027 | 2023년부터 2027년까지 매월 마지막 날 오후 1시 45분(UTC\$10)에 워크플로를 실행합니다. |
CodeCatalyst에서 cron 표현식을 지정할 때는 다음 지침을 따라야 합니다.
+ `SCHEDULE` 트리거당 단일 cron 표현식을 지정합니다.
+ YAML 편집기에서 cron 표현식을 큰따옴표(`"`)로 묶습니다.
+ 시간은 협정 세계시(UTC)로 지정합니다. 다른 시간대는 지원되지 않습니다.
+ 실행 간격은 최소 30분으로 구성합니다. 더 빠른 주기는 지원되지 않습니다.
+ *days-of-month* 또는 *days-of-week* 필드를 지정하되 둘 다 지정하지는 않습니다. 필드 중 하나에 값 또는 별표(`*`)를 지정하는 경우 다른 필드에는 물음표(`?`)를 사용해야 합니다. 별표는 '모두'를 의미하고 물음표는 '모두'를 의미합니다.
cron 표현식의 더 많은 예시와 `?`, `*`, `L`과 같은 와일드카드에 대한 정보는 *Amazon EventBridge 사용 설명서*의 [cron 표현식 참조](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html)를 참조하세요. EventBridge 및 CodeCatalyst의 Cron 표현식은 정확히 동일한 방식으로 작동합니다.
일정 트리거의 예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/트리거/**일정**
### 작업
이 워크플로에 대한 하나 이상의 작업 시퀀스입니다. CodeCatalyst는 다양한 유형의 기능을 제공하는 빌드 및 테스트 작업과 같은 여러 작업 유형을 지원합니다. 각 작업 유형에는 다음이 포함됩니다.
+ 작업의 고유 하드 코딩 ID를 나타내는 `Identifier` 속성입니다. 예를 들어 `aws/build@v1`은 빌드 작업을 식별합니다.
+ 작업과 관련된 속성이 포함된 `Configuration` 섹션입니다.
각 작업 유형에 대한 자세한 내용은 [작업 유형](workflows-actions.md#workflows-actions-types) 항목을 참조하세요. [작업 유형](workflows-actions.md#workflows-actions-types) 주제에는 각 작업에 대한 설명서 링크가 있습니다.
다음은 워크플로 정의 파일의 작업 및 작업 그룹에 대한 YAML 참조입니다.
```
Name: MyWorkflow
SchemaVersion: 1.0
...
Actions:
action-or-gate-name:
Identifier: identifier
Configuration:
...
#Action groups
action-group-name:
Actions:
...
```
#### action-or-gate-name
(Actions/*action-or-gate-name*)
(필수)
*action-name*을 작업을 수행할 이름으로 바꿉니다. 작업 이름은 워크플로 내에서 고유해야 하며 영숫자, 하이픈 및 밑줄만 포함해야 합니다. 구문 규칙에 대한 자세한 내용은 [YAML 구문 지침](#workflow.syntax.conv) 항목을 참조하세요.
제한을 포함한 작업의 이름 지정 방법에 대한 자세한 내용은 [action-or-gate-name](#workflow.actions.name) 섹션을 참조하세요.
해당 UI: 시각적 편집기/*action-name*/구성 탭/**작업 이름** 또는 **작업 표시 이름**
#### action-group-name
(Actions/*action-group-name*)
(선택 사항)
*작업 그룹*에는 하나 이상의 작업이 포함됩니다. 작업을 작업 그룹으로 그룹화하면 워크플로를 체계적으로 관리할 수 있고, 서로 다른 그룹 간의 종속성을 구성할 수도 있습니다.
*action-group-name*을 작업 그룹에 부여하려는 이름으로 바꿉니다. 작업 그룹 이름은 워크플로 내에서 고유해야 하며 영숫자, 하이픈 및 밑줄만 포함해야 합니다. 구문 규칙에 대한 자세한 내용은 [YAML 구문 지침](#workflow.syntax.conv) 항목을 참조하세요.
작업 그룹에 대한 자세한 내용은 [작업을 작업 그룹으로 그룹화](workflows-group-actions.md) 섹션을 참조하세요.
해당 UI: *없음*