input:
path input_file
val name
val threshold
output:
path 'results.txt', emit: results
script:
"""
my_tool --name ${name} --threshold ${threshold} ${input_file}
"""
}
workflow MY_WORKFLOW {
my_task(
params.input_file,
params.name,
params.threshold
)
}
workflow {
MY_WORKFLOW()
}
```
------
#### [ CWL ]
```
cwlVersion: v1.2
class: Workflow
requirements:
InlineJavascriptRequirement: {}
inputs:
input_file: File
name: string
threshold: int
outputs:
result:
type: ...
outputSource: ...
steps:
my_task:
run:
class: CommandLineTool
baseCommand: my_tool
requirements:
...
inputs:
name:
type: string
inputBinding:
prefix: "--name"
threshold:
type: int
inputBinding:
prefix: "--threshold"
input_file:
type: File
inputBinding: {}
outputs:
results:
type: File
outputBinding:
glob: results.txt
```
------
# HealthOmics 워크플로용 파라미터 템플릿 파일
파라미터 템플릿은 워크플로의 입력 파라미터를 정의합니다. 입력 파라미터를 정의하여 워크플로를 보다 유연하고 다양하게 만들 수 있습니다. 예를 들어 참조 유전체 파일의 Amazon S3 위치에 대한 파라미터를 정의할 수 있습니다. 파라미터 템플릿은 Git 기반 리포지토리 서비스 또는 로컬 드라이브를 통해 제공할 수 있습니다. 그런 다음 사용자는 다양한 데이터 세트를 사용하여 워크플로를 실행할 수 있습니다.
워크플로에 대한 파라미터 템플릿을 생성하거나 HealthOmics에서 파라미터 템플릿을 생성할 수 있습니다.
파라미터 템플릿은 JSON 파일입니다. 파일에서 각 입력 파라미터는 워크플로 입력의 이름과 일치해야 하는 명명된 객체입니다. 실행을 시작할 때 필요한 모든 파라미터에 값을 제공하지 않으면 실행이 실패합니다.
입력 파라미터 객체에는 다음 속성이 포함됩니다.
+ **description** -이 필수 속성은 콘솔이 **실행 시작** 페이지에 표시하는 문자열입니다. 이 설명은 실행 메타데이터로도 유지됩니다.
+ **optional** -이 선택적 속성은 입력 파라미터가 선택 사항인지 여부를 나타냅니다. **optional** 필드를 지정하지 않으면 입력 파라미터가 필요합니다.
다음 예제 파라미터 템플릿은 입력 파라미터를 지정하는 방법을 보여줍니다.
```
{
"myRequiredParameter1": {
"description": "this parameter is required",
},
"myRequiredParameter2": {
"description": "this parameter is also required",
"optional": false
},
"myOptionalParameter": {
"description": "this parameter is optional",
"optional": true
}
}
```
## 파라미터 템플릿 생성
HealthOmics는 워크플로 정의를 구문 분석하여 입력 파라미터를 감지하여 파라미터 템플릿을 생성합니다. 워크플로에 파라미터 템플릿 파일을 제공하는 경우 파일의 파라미터가 워크플로 정의에서 감지된 파라미터를 재정의합니다.
다음 섹션에 설명된 대로 CWL, WDL 및 Nextflow 엔진의 구문 분석 로직에는 약간의 차이가 있습니다.
**Topics**
+ [CWL에 대한 파라미터 감지](#parameter-parsing-cwl)
+ [WDL에 대한 파라미터 감지](#parameter-parsing-wdl)
+ [Nextflow에 대한 파라미터 감지](#parameter-parsing-nextflow)
### CWL에 대한 파라미터 감지
CWL 워크플로 엔진에서 구문 분석 로직은 다음과 같이 가정합니다.
+ null이 가능한 지원되는 모든 유형은 선택적 입력 파라미터로 표시됩니다.
+ null이 아닌 지원 유형은 필수 입력 파라미터로 표시됩니다.
+ 기본값이 있는 모든 파라미터는 선택적 입력 파라미터로 표시됩니다.
+ 설명은 `main` 워크플로 정의의 `label` 섹션에서 추출됩니다. `label`를 지정하지 않으면 설명이 비어 있습니다(빈 문자열).
다음 표에는 CWL 보간 예제가 나와 있습니다. 각 예제의 파라미터 이름은 입니다`x`. 파라미터가 필요한 경우 파라미터 값을 제공해야 합니다. 파라미터가 선택 사항인 경우 값을 제공할 필요가 없습니다.
이 표에는 기본 유형에 대한 CWL 보간 예제가 나와 있습니다.
| 입력 | 입력/출력 예제 | 필수 |
| --- | --- | --- |
| x:
type: int
| 1 또는 2 또는 ... | 예 |
| x:
type: int
default: 2
| 기본값은 2입니다. 유효한 입력은 1 또는 2 또는 ...입니다. | 아니요 |
| x:
type: int?
| 유효한 입력은 없음, 1 또는 2 또는 ...입니다. | 아니요 |
| x:
type: int?
default: 2
| 기본값은 2입니다. 유효한 입력은 없음, 1 또는 2 또는 ...입니다. | 아니요 |
다음 표에는 복잡한 유형에 대한 CWL 보간 예제가 나와 있습니다. 복합 유형은 기본 유형의 모음입니다.
| 입력 | 입력/출력 예제 | 필수 |
| --- | --- | --- |
| x:
type: array
items: int
| [] 또는 [1,2,3] | 예 |
| x:
type: array?
items: int
| 없음 또는 [] 또는 [1,2,3] | 아니요 |
| x:
type: array
items: int?
| [] 또는 [없음, 3, 없음] | 예 |
| x:
type: array?
items: int?
| [없음] 또는 없음 또는 [1,2,3] 또는 [없음, 3]이지만 []는 아님 | 아니요 |
### WDL에 대한 파라미터 감지
WDL 워크플로 엔진에서 구문 분석 로직은 다음과 같은 가정을 합니다.
+ null이 가능한 지원되는 모든 유형은 선택적 입력 파라미터로 표시됩니다.
+ Null링할 수 없는 지원되는 유형의 경우:
+ 리터럴 또는 표현식이 할당된 모든 입력 변수는 선택적 파라미터로 표시됩니다. 예:
```
Int x = 2
Float f0 = 1.0 + f1
```
+ 입력 파라미터에 값 또는 표현식이 할당되지 않은 경우 필수 파라미터로 표시됩니다.
+ 설명은 `main` 워크플로 정의의 `parameter_meta`에서 추출됩니다. `parameter_meta`를 지정하지 않으면 설명이 비어 있습니다(빈 문자열). 자세한 내용은 [파라미터 메타데이터](https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#metadata-sections)에 대한 WDL 사양을 참조하세요.
다음 표에는 WDL 보간 예제가 나와 있습니다. 각 예제의 파라미터 이름은 입니다`x`. 파라미터가 필요한 경우 파라미터 값을 제공해야 합니다. 파라미터가 선택 사항인 경우 값을 제공할 필요가 없습니다.
이 표에는 기본 유형에 대한 WDL 보간 예제가 나와 있습니다.
| 입력 | 입력/출력 예제 | 필수 |
| --- | --- | --- |
| 정수 x | 1 또는 2 또는 ... | 예 |
| 정수 x = 2 | 2 | 아니요 |
| 정수 x = 1\$12 | 3 | 아니요 |
| 정수 x = y\$1z | y\$1z | 아니요 |
| 정수? x | 없음 또는 1 또는 2 또는 ... | 예 |
| 정수? x = 2 | 없음 또는 2 | 아니요 |
| 정수? x = 1\$12 | 없음 또는 3 | 아니요 |
| 정수? x = y\$1z | 없음 또는 y\$1z | 아니요 |
다음 표에는 복잡한 유형에 대한 WDL 보간 예제가 나와 있습니다. 복합 유형은 기본 유형의 모음입니다.
| 입력 | 입력/출력 예제 | 필수 |
| --- | --- | --- |
| 배열[Int] x | [1,2,3] 또는 [] | 예 |
| 배열[Int]\$1 x | [1]이지만 []는 아님 | 예 |
| 배열[Int]? x | 없음 또는 [] 또는 [1,2,3] | 아니요 |
| 배열[Int?] x | [] 또는 [없음, 3, 없음] | 예 |
| 배열[Int?]=? x | [없음] 또는 없음 또는 [1,2,3] 또는 [없음, 3]이지만 []는 아님 | 아니요 |
| 구조 샘플 \$1문자열 a, 정수 y\$1 입력의 뒷부분: 샘플 mySample | String a = mySample.a
Int y = mySample.y
| 예 |
| 구조 샘플 \$1문자열 a, 정수 y\$1 입력의 후반부: 샘플? mySample | if (defined(mySample)) {
String a = mySample.a
Int y = mySample.y
} | 아니요 |
### Nextflow에 대한 파라미터 감지
Nextflow의 경우 HealthOmics는 `nextflow_schema.json` 파일을 구문 분석하여 파라미터 템플릿을 생성합니다. 워크플로 정의에 스키마 파일이 포함되지 않은 경우 HealthOmics는 기본 워크플로 정의 파일을 구문 분석합니다.
**Topics**
+ [스키마 파일 구문 분석](#parameter-parsing-nextflow-schema)
+ [기본 파일 구문 분석](#parameter-parsing-nextflow-main)
+ [중첩 파라미터](#parameter-parsing-nextflow-nested)
+ [Nextflow 보간의 예](#parameter-parsing-nextflow-examples)
#### 스키마 파일 구문 분석
구문 분석이 올바르게 작동하려면 스키마 파일이 다음 요구 사항을 충족하는지 확인합니다.
+ 스키마 파일의 이름은 이며 기본 워크플로 파일`nextflow_schema.json`과 동일한 디렉터리에 있습니다.
+ 스키마 파일은 다음 스키마 중 하나에 정의된 유효한 JSON입니다.
+ [json-schema.org/draft/2020-12/schema](https://json-schema.org/draft/2020-12/schema).
+ [json-schema.org/draft-07/schema](https://json-schema.org/draft-07/schema).
HealthOmics는 `nextflow_schema.json` 파일을 구문 분석하여 파라미터 템플릿을 생성합니다.
+ 스키마에 **properties** 정의된 모든를 추출합니다.
+ 속성에 사용할 수 있는 **description** 경우 속성을 포함합니다.
+ 속성의 **required** 필드를 기반으로 각 파라미터가 선택 사항인지 필수인지 식별합니다.
다음 예제에서는 정의 파일과 생성된 파라미터 파일을 보여줍니다.
```
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"$defs": {
"input_options": {
"title": "Input options",
"type": "object",
"required": ["input_file"],
"properties": {
"input_file": {
"type": "string",
"format": "file-path",
"pattern": "^s3://[a-z0-9.-]{3,63}(?:/\\S*)?$",
"description": "description for input_file"
},
"input_num": {
"type": "integer",
"default": 42,
"description": "description for input_num"
}
}
},
"output_options": {
"title": "Output options",
"type": "object",
"required": ["output_dir"],
"properties": {
"output_dir": {
"type": "string",
"format": "file-path",
"description": "description for output_dir",
}
}
}
},
"properties": {
"ungrouped_input_bool": {
"type": "boolean",
"default": true
}
},
"required": ["ungrouped_input_bool"],
"allOf": [
{ "$ref": "#/$defs/input_options" },
{ "$ref": "#/$defs/output_options" }
]
}
```
생성된 파라미터 템플릿:
```
{
"input_file": {
"description": "description for input_file",
"optional": False
},
"input_num": {
"description": "description for input_num",
"optional": True
},
"output_dir": {
"description": "description for output_dir",
"optional": False
},
"ungrouped_input_bool": {
"description": None,
"optional": False
}
}
```
#### 기본 파일 구문 분석
워크플로 정의에 `nextflow_schema.json` 파일이 포함되지 않은 경우 HealthOmics는 기본 워크플로 정의 파일을 구문 분석합니다.
HealthOmics는 기본 워크플로 정의 파일 및 `nextflow.config` 파일에 있는 `params` 표현식을 분석합니다. 기본값이 `params` 있는 모든는 선택 사항으로 표시됩니다.
구문 분석이 올바르게 작동하려면 다음 요구 사항에 유의하세요.
+ HealthOmics는 기본 워크플로 정의 파일만 구문 분석합니다. 모든 파라미터를 캡처하려면 모든 하위 모듈과 가져온 워크플로에 **params** 모든 파라미터를 연결하는 것이 좋습니다.
+ 구성 파일은 선택 사항입니다. 정의한 경우 이름을 지정`nextflow.config`하고 기본 워크플로 정의 파일과 동일한 디렉터리에 배치합니다.
다음 예제에서는 정의 파일과 생성된 파라미터 템플릿을 보여줍니다.
```
params.input_file = "default.txt"
params.threads = 4
params.memory = "8GB"
workflow {
if (params.version) {
println "Using version: ${params.version}"
}
}
```
생성된 파라미터 템플릿:
```
{
"input_file": {
"description": None,
"optional": True
},
"threads": {
"description": None,
"optional": True
},
"memory": {
"description": None,
"optional": True
},
"version": {
"description": None,
"optional": False
}
}
```
nextflow.config에 정의된 기본값의 경우 HealthOmics는 다음 예제`params {}`와 같이 내에 선언된 `params` 할당 및 파라미터를 수집합니다. 할당 문에서는 문 왼쪽에 나타나`params`야 합니다.
```
params.alpha = "alpha"
params.beta = "beta"
params {
gamma = "gamma"
delta = "delta"
}
env {
// ignored, as this assignment isn't in the params block
VERSION = "TEST"
}
// ignored, as params is not on the left side
interpolated_image = "${params.cli_image}"
```
생성된 파라미터 템플릿:
```
{
// other params in your main workflow defintion
"alpha": {
"description": None,
"optional": True
},
"beta": {
"description": None,
"optional": True
},
"gamma": {
"description": None,
"optional": True
},
"delta": {
"description": None,
"optional": True
}
}
```
#### 중첩 파라미터
`nextflow_schema.json` 및 모두 중첩된 파라미터를 `nextflow.config` 허용합니다. 그러나 HealthOmics 파라미터 템플릿에는 최상위 파라미터만 필요합니다. 워크플로에서 중첩 파라미터를 사용하는 경우 JSON 객체를 해당 파라미터의 입력으로 제공해야 합니다.
##### 스키마 파일의 중첩 파라미터
HealthOmics는 `nextflow_schema.json` 파일을 구문 분석할 **params** 때 중첩된를 건너뜁니다. 예를 들어 다음 `nextflow_schema.json` 파일을 정의하는 경우:
```
{
"properties": {
"input": {
"properties": {
"input_file": { ... },
"input_num": { ... }
}
},
"input_bool": { ... }
}
}
```
HealthOmics는 파라미터 템플릿을 생성할 `input_num` 때 `input_file` 및를 무시합니다.
```
{
"input": {
"description": None,
"optional": True
},
"input_bool": {
"description": None,
"optional": True
}
}
```
이 워크플로를 실행하면 HealthOmics는 다음과 유사한 `input.json` 파일을 예상합니다.
```
{
"input": {
"input_file": "s3://bucket/obj",
"input_num": 2
},
"input_bool": false
}
```
##### 구성 파일의 중첩 파라미터
HealthOmics는 `nextflow.config` 파일에 중첩된 **params**를 수집하지 않으며 구문 분석 중에 이를 건너뜁니다. 예를 들어 다음 `nextflow.config` 파일을 정의하는 경우:
```
params.alpha = "alpha"
params.nested.beta = "beta"
params {
gamma = "gamma"
group {
delta = "delta"
}
}
```
HealthOmics는 파라미터 템플릿을 생성할 `params.group.delta` 때 `params.nested.beta` 및를 무시합니다.
```
{
"alpha": {
"description": None,
"optional": True
},
"gamma": {
"description": None,
"optional": True
}
}
```
#### Nextflow 보간의 예
다음 표에는 기본 파일의 파라미터에 대한 Nextflow 보간 예제가 나와 있습니다.
| 파라미터 | 필수 |
| --- | --- |
| params.input\$1file | 예 |
| params.input\$1file = "s3://bucket/data.json" | 아니요 |
| params.nested.input\$1file | N/A |
| params.nested.input\$1file = "s3://bucket/data.json" | N/A |
다음 표에는 `nextflow.config` 파일의 파라미터에 대한 Nextflow 보간 예제가 나와 있습니다.
| 파라미터 | 필수 |
| --- | --- |
| params.input_file = "s3://bucket/data.json"
| 아니요 |
| params {
input_file = "s3://bucket/data.json"
} | 아니요 |
| params {
nested {
input_file = "s3://bucket/data.json"
}
} | N/A |
| input_file = params.input_file
| N/A |
# 프라이빗 워크플로용 컨테이너 이미지
HealthOmics는 Amazon ECR 프라이빗 리포지토리에서 호스팅되는 컨테이너 이미지를 지원합니다. 컨테이너 이미지를 생성하여 프라이빗 리포지토리에 업로드할 수 있습니다. Amazon ECR 프라이빗 레지스트리를 풀스루 캐시로 사용하여 업스트림 레지스트리의 콘텐츠를 동기화할 수도 있습니다.
Amazon ECR 리포지토리는 서비스를 호출하는 계정과 동일한 AWS 리전에 있어야 합니다. 소스 이미지 리포지토리가 적절한 권한을 제공하는 한 다른가 컨테이너 이미지를 소유할 AWS 계정 수 있습니다. 자세한 내용은 [교차 계정 Amazon ECR 액세스에 대한 정책](permissions-ecr.md#permissions-cross-account) 단원을 참조하십시오.
실행이 시작되기 전에 액세스를 확인할 수 있도록 Amazon ECR 컨테이너 이미지 URIs를 워크플로의 파라미터로 정의하는 것이 좋습니다. 또한 리전 파라미터를 변경하여 새 리전에서 워크플로를 더 쉽게 실행할 수 있습니다.
**참고**
HealthOmics는 ARM 컨테이너를 지원하지 않으며 퍼블릭 리포지토리에 대한 액세스를 지원하지 않습니다.
HealthOmics가 Amazon ECR에 액세스하도록 IAM 권한을 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[HealthOmics 리소스 권한](permissions-resource.md).
**Topics**
+ [타사 컨테이너 레지스트리와 동기화](#ecr-pull-through)
+ [Amazon ECR 컨테이너 이미지에 대한 일반 고려 사항](#ecr-considerations)
+ [HealthOmics 워크플로의 환경 변수](#ecr-env-vars)
+ [Amazon ECR 컨테이너 이미지에서 Java 사용](#ecr-java-considerations)
+ [Amazon ECR 컨테이너 이미지에 작업 입력 추가](#ecr-tasks)
## 타사 컨테이너 레지스트리와 동기화
Amazon ECR 풀스루 캐시 규칙을 사용하여 지원되는 업스트림 레지스트리의 리포지토리를 Amazon ECR 프라이빗 리포지토리와 동기화할 수 있습니다. 자세한 내용은 *Amazon ECR 사용 설명서*의 [업스트림 레지스트리 동기화](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html)를 참조하세요.
풀스루 캐시는 캐시를 생성할 때 프라이빗 레지스트리에 이미지 리포지토리를 자동으로 생성하고 업스트림 이미지가 변경될 때 캐시된 이미지와 자동으로 동기화됩니다.
HealthOmics는 다음 업스트림 레지스트리에 대한 풀스루 캐시를 지원합니다.
+ Amazon ECR 퍼블릭
+ Kubernetes 컨테이너 이미지 레지스트리
+ Quay
+ Docker Hub
+ Microsoft Azure 컨테이너 레지스트리
+ GitHub 컨테이너 레지스트리
+ GitLab 컨테이너 레지스트리
HealthOmics는 업스트림 Amazon ECR 프라이빗 리포지토리에 대한 풀스루 캐시를 지원하지 않습니다.
Amazon ECR 풀스루 캐시 사용의 이점은 다음과 같습니다.
1. 컨테이너 이미지를 Amazon ECR로 수동으로 마이그레이션하거나 타사 리포지토리에서 업데이트를 동기화할 필요가 없습니다.
1. 워크플로는 프라이빗 리포지토리의 동기화된 컨테이너 이미지에 액세스하며, 이는 퍼블릭 레지스트리에서 런타임에 콘텐츠를 다운로드하는 것보다 더 안정적입니다.
1. Amazon ECR 풀스루 캐시는 예측 가능한 URI 구조를 사용하기 때문에 HealthOmics 서비스는 Amazon ECR 프라이빗 URI를 업스트림 레지스트리 URI와 자동으로 매핑할 수 있습니다. 워크플로 정의에서 URI 값을 업데이트하고 바꿀 필요는 없습니다.
**Topics**
+ [풀스루 캐시 구성](#ecr-pull-through-configure)
+ [레지스트리 매핑](#ecr-pull-through-registry-mapping)
+ [이미지 매핑](#ecr-pull-through-mapping-format)
### 풀스루 캐시 구성
Amazon ECR은 각 리전 AWS 계정 에서에 대한 레지스트리를 제공합니다. 워크플로를 실행하려는 리전과 동일한 리전에서 Amazon ECR 구성을 생성해야 합니다.
다음 섹션에서는 풀스루 캐시의 구성 작업에 대해 설명합니다.
**Topics**
+ [풀스루 캐시 규칙 생성](#create-ecr-ptc)
+ [업스트림 레지스트리에 대한 레지스트리 권한](#reg-ecr-ptc)
+ [리포지토리 생성 템플릿](#repo-create-templates-ptc)
+ [워크플로 생성](#reg-mapping-ecr-ptc)
#### 풀스루 캐시 규칙 생성
캐시하려는 이미지가 있는 각 업스트림 레지스트리에 대해 Amazon ECR 풀스루 캐시 규칙을 생성합니다. 규칙은 업스트림 레지스트리와 Amazon ECR 프라이빗 리포지토리 간의 매핑을 지정합니다.
인증이 필요한 업스트림 레지스트리의 경우 AWS Secrets Manager를 사용하여 자격 증명을 제공합니다.
**참고**
활성 실행이 프라이빗 리포지토리를 사용하는 동안에는 풀스루 캐시 규칙을 변경하지 마십시오. 실행이 실패하거나 더 심각하게는 예상치 못한 이미지를 사용하는 파이프라인이 발생할 수 있습니다.
자세한 내용은 *Amazon Elastic Container Registry 사용 설명서*의 [풀스루 캐시 규칙 생성을](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) 참조하세요.
##### 콘솔을 사용하여 풀스루 캐시 규칙 생성
풀스루 캐시를 구성하려면 Amazon ECR 콘솔을 사용하여 다음 단계를 따릅니다.
1. Amazon ECR 콘솔 열기: https://console.aws.amazon.com/ecr
1. 왼쪽 메뉴의 **프라이빗 레지스트리**에서 **기능 및 설정을** 확장한 다음 **캐시 풀스루**를 선택합니다.
1. **풀스루 캐시** 페이지에서 **규칙 추가**를 선택합니다.
1. **업스트림 레지스트리** 패널에서 프라이빗 레지스트리와 동기화할 업스트림 레지스트리를 선택한 **후 다음을** 선택합니다.
1. 업스트림 레지스트리에 인증이 필요한 경우 보안 인증 정보가 포함된 SageMaker AI 보안 암호를 지정하는 새 페이지가 콘솔에 열립니다. **다음**을 선택합니다.
1. **네임스페이스 지정**의 **캐시 네임**스페이스 패널에서 특정 리포지토리 접두사를 사용하거나 접두사 없이 프라이빗 리포지토리를 생성할지 여부를 선택합니다. 접두사를 사용하도록 선택한 경우 **캐시 리포지토리 접두사에 접두사** 이름을 지정합니다.
1. **업스트림 네임스페이스** 패널에서 특정 리포지토리 접두사를 사용하거나 접두사 없이 업스트림 리포지토리에서 가져올지 여부를 선택합니다. 접두사를 사용하도록 선택한 경우 **Upstream 리포지토리 접두사에 접두사** 이름을 지정합니다.
**네임스페이스 예제** 패널에는 예제 풀 요청, 업스트림 URL 및 생성된 캐시 리포지토리의 URL이 표시됩니다.
1. **다음**을 선택합니다.
1. 구성을 검토하고 **생성을** 선택하여 규칙을 생성합니다.
자세한 내용은 [ 풀스루 캐시 규칙 생성(AWS 관리 콘솔)을 참조하세요](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-console).
##### CLI를 사용하여 풀스루 캐시 규칙 생성
Amazon ECR **create-pull-through-cache-rule** 명령을 사용하여 풀스루 캐시 규칙을 생성합니다. 인증이 필요한 업스트림 레지스트리의 경우 Secrets Manager 보안 암호에 자격 증명을 저장합니다.
다음 섹션에서는 지원되는 각 업스트림 레지스트리의 예를 제공합니다.
##### Amazon ECR 퍼블릭의 경우
다음 예제에서는 Amazon ECR 퍼블릭 레지스트리에 대한 풀스루 캐시 규칙을 생성합니다. 리포지토리 접두사를 `ecr-public`으로 지정합니다. 이렇게 하면 풀스루 캐시 규칙을 통해 생성한 각 리포지토리가 `ecr-public/upstream-repository-name`의 명명 체계를 사용하게 됩니다.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix ecr-public \
--upstream-registry-url public.ecr.aws \
--region us-east-1
```
##### Kubernetes Container Registry의 경우
다음 예제에서는 Kubernetes 퍼블릭 레지스트리에 대한 풀스루 캐시 규칙을 생성합니다. 리포지토리 접두사를 `kubernetes`으로 지정합니다. 이렇게 하면 풀스루 캐시 규칙을 통해 생성한 각 리포지토리가 `kubernetes/upstream-repository-name`의 명명 체계를 사용하게 됩니다.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix kubernetes \
--upstream-registry-url registry.k8s.io \
--region us-east-1
```
##### Quay의 경우
다음 예제에서는 Quay 퍼블릭 레지스트리에 대한 풀스루 캐시 규칙을 생성합니다. 리포지토리 접두사를 `quay`로 지정합니다. 이렇게 하면 풀스루 캐시 규칙을 통해 생성한 각 리포지토리가 `quay/upstream-repository-name`의 명명 체계를 사용하게 됩니다.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix quay \
--upstream-registry-url quay.io \
--region us-east-1
```
##### Docker Hub의 경우
다음 예제에서는 Docker Hub 레지스트리에 대한 풀스루 캐시 규칙을 생성합니다. 리포지토리 접두사를 `docker-hub`으로 지정합니다. 이렇게 하면 풀스루 캐시 규칙을 통해 생성한 각 리포지토리가 `docker-hub/upstream-repository-name`의 명명 체계를 사용하게 됩니다. Docker Hub 보안 인증 정보가 포함된 보안 암호의 전체 Amazon 리소스 이름(ARN)을 지정해야 합니다.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix docker-hub \
--upstream-registry-url registry-1.docker.io \
--credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
--region us-east-1
```
##### GitHub Container Registry의 경우
다음 예제에서는 GitHub 컨테이너 레지스트리에 대한 풀스루 캐시 규칙을 생성합니다. 리포지토리 접두사를 `github`으로 지정합니다. 이렇게 하면 풀스루 캐시 규칙을 통해 생성한 각 리포지토리가 `github/upstream-repository-name`의 명명 체계를 사용하게 됩니다. GitHub 컨테이너 레지스트리 보안 인증 정보가 포함된 보안 암호의 전체 Amazon 리소스 이름(ARN)을 지정해야 합니다.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix github \
--upstream-registry-url ghcr.io \
--credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
--region us-east-1
```
##### Microsoft Azure 컨테이너 레지스트리의 경우
다음 예제에서는 Microsoft Azure 컨테이너 레지스트리에 대한 풀스루 캐시 규칙을 생성합니다. 리포지토리 접두사를 `azure`으로 지정합니다. 이렇게 하면 풀스루 캐시 규칙을 통해 생성한 각 리포지토리가 `azure/upstream-repository-name`의 명명 체계를 사용하게 됩니다. Microsoft Azure 컨테이너 레지스트리 보안 인증 정보가 포함된 보안 암호의 전체 Amazon 리소스 이름(ARN)을 지정해야 합니다.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix azure \
--upstream-registry-url myregistry.azurecr.io \
--credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
--region us-east-1
```
##### GitLab 컨테이너 레지스트리의 경우
다음 예제에서는 GitLab 컨테이너 레지스트리에 대한 풀스루 캐시 규칙을 생성합니다. 리포지토리 접두사를 `gitlab`으로 지정합니다. 이렇게 하면 풀스루 캐시 규칙을 통해 생성한 각 리포지토리가 `gitlab/upstream-repository-name`의 명명 체계를 사용하게 됩니다. GitLab 컨테이너 레지스트리 보안 인증 정보가 포함된 보안 암호의 전체 Amazon 리소스 이름(ARN)을 지정해야 합니다.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix gitlab \
--upstream-registry-url registry.gitlab.com \
--credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
--region us-east-1
```
자세한 내용은 *Amazon ECR 사용 설명서*의 [ 풀스루 캐시 규칙(CLI) 생성을](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-cli) 참조하세요.
**get-run-task** CLI 명령을 사용하여 특정 작업에 사용되는 컨테이너 이미지에 대한 정보를 검색할 수 있습니다.
```
aws omics get-run-task --id 1234567 --task-id
```
출력에는 컨테이너 이미지에 대한 다음 정보가 포함됩니다.
```
"imageDetails": {
"image": "string",
"imageDigest": "string",
"sourceImage": "string",
...
}
```
#### 업스트림 레지스트리에 대한 레지스트리 권한
레지스트리 권한을 사용하여 HealthOmics가 풀스루 캐시를 사용하고 컨테이너 이미지를 Amazon ECR 프라이빗 레지스트리로 가져올 수 있도록 허용합니다. 실행에 사용되는 컨테이너를 제공하는 Amazon ECR 레지스트리 정책을 레지스트리에 추가합니다.
다음 정책은 HealthOmics 서비스가 지정된 풀스루 캐시 접두사(들)로 리포지토리를 생성하고 이러한 리포지토리로 업스트림 풀을 시작할 수 있는 권한을 부여합니다.
1. Amazon ECR 콘솔에서 왼쪽 메뉴를 열고 **프라이빗 레지스트리**에서 **레지스트리 권한을** 확장한 다음 **명령문 생성을** 선택합니다.
1. 오른쪽 상단에서 JSON을 선택합니다. 다음과 유사한 정책을 입력합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPTCinRegPermissions",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:CreateRepository",
"ecr:BatchImportUpstreamImage"
],
"Resource": [
"arn:aws:ecr:us-east-1:123456789012:repository/ecr-public/*",
"arn:aws:ecr:us-east-1:123456789012:repository/docker-hub/*"
]
}
]
}
```
------
#### 리포지토리 생성 템플릿
HealthOmics에서 풀스루 캐싱을 사용하려면 Amazon ECR 리포지토리에 리포지토리 생성 템플릿이 있어야 합니다. 템플릿은 사용자 또는 Amazon ECR이 업스트림 레지스트리에 대한 프라이빗 리포지토리를 생성할 때의 구성 설정을 정의합니다.
각 템플릿에는 Amazon ECR이 새 리포지토리를 특정 템플릿과 일치시키는 데 사용하는 리포지토리 네임스페이스 접두사가 포함되어 있습니다. 템플릿은 리소스 기반 액세스 정책, 태그 불변성, 암호화 및 수명 주기 정책을 포함한 모든 리포지토리 설정에 대한 구성을 지정합니다.
자세한 내용은 *Amazon Elastic Container Registry 사용 설명서의 *[리포지토리 생성 템플릿을](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) 참조하세요.
리포지토리 생성 템플릿을 생성하는 방법:
1. Amazon ECR 콘솔에서 왼쪽 메뉴를 열고 **프라이빗 레지스트리**에서 **기능 및 설정을** 확장한 다음 **리포지토리 생성 템플릿을** 선택합니다.
1. **템플릿 생성**을 선택합니다.
1. **템플릿 세부 정보**에서 **풀스루 캐시**를 선택합니다.
1. 이 템플릿을 특정 접두사에 적용할지 아니면 다른 템플릿과 일치하지 않는 모든 리포지토리에 적용할지 선택합니다.
**특정 접두사를** 선택하는 경우 접두사에 네임스페이스 **접**두사 값을 입력합니다. PTC 규칙을 생성할 때이 접두사를 지정했습니다.
1. **다음**을 선택합니다.
1. **리포지토리 생성 구성 추가** 페이지에서 **리포지토리 권한을** 입력합니다. 샘플 정책 설명 중 하나를 사용하거나 다음 예제와 유사한 명령문을 입력합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PTCRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
1. 선택적으로 수명 주기 정책 및 태그와 같은 리포지토리 설정을 추가할 수 있습니다. Amazon ECR은 지정된 접두사를 사용하는 풀스루 캐시용으로 생성된 모든 컨테이너 이미지에 이러한 규칙을 적용합니다.
1. **다음**을 선택합니다.
1. 구성을 검토하고 **다음을** 선택합니다.
#### 워크플로 생성
새 워크플로 또는 워크플로 버전을 생성할 때 레지스트리 매핑을 검토하고 필요한 경우 업데이트합니다. 자세한 내용은 [프라이빗 워크플로 생성](create-private-workflow.md)을 참조하세요.
### 레지스트리 매핑
프라이빗 Amazon ECR 레지스트리의 접두사와 업스트림 레지스트리 이름 간에 매핑하도록 레지스트리 매핑을 정의합니다.
Amazon ECR 레지스트리 매핑에 대한 자세한 내용은 [ Amazon ECR에서 풀스루 캐시 규칙 생성을](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) 참조하세요.
다음 예제에서는 Docker Hub, Quay 및 Amazon ECR Public에 대한 레지스트리 매핑을 보여줍니다.
```
{
"registryMappings": [
{
"upstreamRegistryUrl": "registry-1.docker.io",
"ecrRepositoryPrefix": "docker-hub"
},
{
"upstreamRegistryUrl": "quay.io",
"ecrRepositoryPrefix": "quay"
},
{
"upstreamRegistryUrl": "public.ecr.aws",
"ecrRepositoryPrefix": "ecr-public"
}
]
}
```
### 이미지 매핑
프라이빗 Amazon ECR 워크플로에 정의된 이미지 이름과 업스트림 레지스트리의 이미지 이름 간에 매핑하도록 이미지 매핑을 정의합니다.
풀스루 캐시를 지원하는 레지스트리에서 이미지 매핑을 사용할 수 있습니다. HealthOmics 않는 업스트림 레지스트리에서 이미지 매핑을 사용할 수도 있습니다. 업스트림 레지스트리를 프라이빗 리포지토리와 수동으로 동기화해야 합니다.
Amazon ECR 이미지 매핑에 대한 자세한 내용은 [ Amazon ECR에서 풀스루 캐시 규칙 생성을](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) 참조하세요.
다음 예제에서는 프라이빗 Amazon ECR 이미지에서 퍼블릭 게놈 이미지 및 최신 Ubuntu 이미지로의 매핑을 보여줍니다.
```
{
"imageMappings": [
{
"sourceImage": "public.ecr.aws/aws-genomics/broadinstitute/gatk:4.6.0.2",
"destinationImage": "123456789012.dkr.ecr.us-east-1.amazonaws.com/broadinstitute/gatk:4.6.0.2"
},
{
"sourceImage": "ubuntu:latest",
"destinationImage": "123456789012.dkr.ecr.us-east-1.amazonaws.com/custom/ubuntu:latest",
}
]
}
```
## Amazon ECR 컨테이너 이미지에 대한 일반 고려 사항
+ 아키텍처
HealthOmics는 x86\$164 컨테이너를 지원합니다. 로컬 시스템이 Apple Mac과 같은 ARM 기반인 경우 다음과 같은 명령을 사용하여 x86\$164 컨테이너 이미지를 빌드합니다.
```
docker build --platform amd64 -t my_tool:latest .
```
+ 진입점 및 쉘
HealthOmics 워크플로 엔진은 워크플로 작업에 사용되는 컨테이너 이미지에 대한 명령 재정의로 bash 스크립트를 삽입합니다. 따라서 컨테이너 이미지는 bash 쉘이 기본값이 되도록 지정된 ENTRYPOINT 없이 빌드해야 합니다.
+ 탑재된 경로
공유 파일 시스템은 /tmp에서 컨테이너 작업에 마운트됩니다. 이 위치의 컨테이너 이미지에 내장된 모든 데이터 또는 도구는 재정의됩니다.
워크플로 정의는 /mnt/workflow의 읽기 전용 탑재를 통해 태스크에 사용할 수 있습니다.
+ 이미지 크기
최대 컨테이너 이미지 크기는 [HealthOmics 워크플로 고정 크기 할당량](fixed-quotas.md#fixed-quotas-workflows) 섹션을 참조하세요.
## HealthOmics 워크플로의 환경 변수
HealthOmics는 컨테이너에서 실행되는 워크플로에 대한 정보가 있는 환경 변수를 제공합니다. 워크플로 작업의 로직에서 이러한 변수의 값을 사용할 수 있습니다.
모든 HealthOmics 워크플로 변수는 `AWS_WORKFLOW_` 접두사로 시작합니다. 이 접두사는 보호된 환경 변수 접두사입니다. 워크플로 컨테이너에서 자체 변수에이 접두사를 사용하지 마세요.
HealthOmics는 다음과 같은 워크플로 환경 변수를 제공합니다.
**AWS\$1REGION**
이 변수는 컨테이너가 실행 중인 리전입니다.
**AWS\$1WORKFLOW\$1RUN**
이 변수는 현재 실행의 이름입니다.
**AWS\$1WORKFLOW\$1RUN\$1ID**
이 변수는 현재 실행의 실행 식별자입니다.
**AWS\$1WORKFLOW\$1RUN\$1UUID**
이 변수는 현재 실행의 실행 UUID입니다.
**AWS\$1WORKFLOW\$1TASK**
이 변수는 현재 작업의 이름입니다.
**AWS\$1WORKFLOW\$1TASK\$1ID**
이 변수는 현재 작업의 작업 식별자입니다.
**AWS\$1WORKFLOW\$1TASK\$1UUID**
이 변수는 현재 작업의 작업 UUID입니다.
다음 예제에서는 각 환경 변수의 일반적인 값을 보여줍니다.
```
AWS Region: us-east-1
Workflow Run: arn:aws:omics:us-east-1:123456789012:run/6470304
Workflow Run ID: 6470304
Workflow Run UUID: f4d9ed47-192e-760e-f3a8-13afedbd4937
Workflow Task: arn:aws:omics:us-east-1:123456789012:task/4192063
Workflow Task ID: 4192063
Workflow Task UUID: f0c9ed49-652c-4a38-7646-60ad835e0a2e
```
## Amazon ECR 컨테이너 이미지에서 Java 사용
워크플로 태스크가 GATK와 같은 Java 애플리케이션을 사용하는 경우 컨테이너에 대한 다음 메모리 요구 사항을 고려하세요.
+ Java 애플리케이션은 스택 메모리와 힙 메모리를 사용합니다. 기본적으로 최대 힙 메모리는 컨테이너에서 사용 가능한 총 메모리의 백분율입니다. 이 기본값은 특정 JVM 배포 및 JVM 버전에 따라 달라지므로 JVM 관련 설명서를 참조하거나 Java 명령줄 옵션(예: `-Xmx`)을 사용하여 힙 메모리 최대값을 명시적으로 설정합니다.
+ JVM 스택에도 메모리가 필요하므로 최대 힙 메모리를 컨테이너 메모리 할당의 100%로 설정하지 마세요. 메모리는 JVM 가비지 수집기 및 컨테이너에서 실행되는 기타 운영 체제 프로세스에도 필요합니다.
+ GATK와 같은 일부 Java 애플리케이션은 기본 메서드 호출 또는 메모리 매핑 파일과 같은 기타 최적화를 사용할 수 있습니다. 이러한 기법에는 JVM 최대 힙 파라미터로 제어되지 않는 "오프 힙"으로 수행되는 메모리 할당이 필요합니다.
Java 애플리케이션이 오프 힙 메모리를 할당한다는 것을 알고 있는 경우(또는 의심하는 경우) 태스크 메모리 할당에 오프 힙 메모리 요구 사항이 포함되어 있는지 확인합니다.
이러한 오프 힙 할당으로 인해 컨테이너의 메모리가 부족해지는 경우 일반적으로 JVM이이 메모리를 제어하지 않기 때문에 Java **OutOfMemory** 오류가 표시되지 않습니다.
## Amazon ECR 컨테이너 이미지에 작업 입력 추가
워크플로 작업을 실행하는 데 필요한 모든 실행 파일, 라이브러리 및 스크립트를 작업을 실행하는 데 사용되는 Amazon ECR 이미지에 추가합니다.
작업 컨테이너 이미지 외부에 있는 스크립트, 바이너리 및 라이브러리를 사용하지 않는 것이 좋습니다. 이는 `bin` 디렉터리를 `nf-core` 워크플로 패키지의 일부로 사용하는 워크플로를 사용할 때 특히 중요합니다. 이 디렉터리는 워크플로 작업에 사용할 수 있지만 읽기 전용 디렉터리로 마운트됩니다. 이 디렉터리의 필수 리소스는 작업 이미지에 복사해야 하며 런타임 시 또는 작업에 사용되는 컨테이너 이미지를 빌드할 때 사용할 수 있어야 합니다.
HealthOmics가 지원하는 컨테이너 이미지의 최대 크기는 [HealthOmics 워크플로 고정 크기 할당량](fixed-quotas.md#fixed-quotas-workflows) 섹션을 참조하세요. HealthOmics
# HealthOmics 워크플로 README 파일
워크플로에 대한 지침, 다이어그램 및 필수 정보가 포함된 README.md 파일을 업로드할 수 있습니다. 각 워크플로 버전은 언제든지 업데이트할 수 있는 README 파일 하나를 지원합니다.
**README 요구 사항은 다음과 같습니다.**
+ README 파일은 마크다운(.md) 형식이어야 합니다.
+ 최대 파일 크기: 500KiB
**Topics**
+ [기존 README 사용](#workflows-add-readme)
+ [렌더링 조건](#workflows-rendering-readme)
## 기존 README 사용
Git 리포지토리에서 내보낸 READMEs에는 일반적으로 리포지토리 외부에서 작동하지 않는 상대 링크가 포함되어 있습니다. HealthOmics Git 통합은 콘솔에서 적절한 렌더링을 위해 이를 절대 링크로 자동 변환하므로 수동 URL 업데이트가 필요하지 않습니다.
Amazon S3 또는 로컬 드라이브에서 가져온 READMEs 경우 이미지와 링크는 퍼블릭 URLs 사용하거나 적절한 렌더링을 위해 상대 경로를 업데이트해야 합니다.
**참고**
HealthOmics 콘솔에 표시하려면 이미지를 공개적으로 호스팅해야 합니다. GitHub Enterprise Server 또는 GitLab Self-Managed리포지토리에 저장된 이미지는 렌더링할 수 없습니다.
## 렌더링 조건
HealthOmics 콘솔은 절대 경로를 사용하여 공개적으로 액세스할 수 있는 이미지와 링크를 보간합니다. 프라이빗 리포지토리에서 URLs을 렌더링하려면 사용자가 리포지토리에 액세스할 수 있어야 합니다. 사용자 지정 도메인을 사용하는 GitHub Enterprise Server 또는 GitLab Self-Managed리포지토리의 경우 HealthOmics는 이러한 프라이빗 리포지토리에 저장된 상대 링크를 확인하거나 이미지를 렌더링할 수 없습니다.
다음 표에는 AWS 콘솔 README 뷰에서 지원하는 마크다운 요소가 나와 있습니다.
| 요소 | AWS 콘솔 |
| --- | --- |
| 알림 | 예, 하지만 아이콘은 없습니다. |
| 배지 | 예 |
| 기본 텍스트 형식 지정 | 예 |
| [코드 블록](https://www.markdownguide.org/basic-syntax/#code-blocks) | 예, 하지만 [구문 강조](https://www.markdownguide.org/extended-syntax/#syntax-highlighting) 표시 및 복사 버튼 기능이 없습니다. |
| 축소 가능한 섹션 | 예 |
| [제목](https://www.markdownguide.org/basic-syntax/#headings) | 예 |
| [이미지 형식](https://www.markdownguide.org/basic-syntax/#images-1) | 예 |
| [이미지(클릭 가능)](https://www.markdownguide.org/basic-syntax/#linking-images) | 예 |
| [줄 바꿈](https://www.markdownguide.org/basic-syntax/#line-breaks) | 예 |
| Mermaid 다이어그램 | 만 그래프를 열고, 그래프 위치를 이동하고, 코드를 복사할 수 있습니다. |
| 견적 | 예 |
| [Subscript](https://www.markdownguide.org/extended-syntax/#subscript) 및 [Superscript](https://www.markdownguide.org/extended-syntax/#superscript) | 예 |
| [테이블](https://www.markdownguide.org/extended-syntax/#tables) | 예, 하지만 텍스트 정렬을 지원하지 않습니다. |
| 텍스트 정렬 | 예 |
### 이미지 및 링크 URLs 사용
소스 공급자에 따라 페이지 및 이미지URLs을 다음 형식으로 구성합니다.
+ `{username}`: 리포지토리가 호스팅되는 사용자 이름입니다.
+ `{repo}`: 리포지토리 이름입니다.
+ `{ref}`: 소스 참조(브랜치, 태그 및 커밋 ID).
+ `{path}`: 리포지토리의 페이지 또는 이미지에 대한 파일 경로입니다.
| 소스 공급자 | 페이지 URL | 이미지 URL |
| --- | --- | --- |
| GitHub | https://github.com/\$1username\$1/\$1repo\$1/blob/\$1ref\$1/\$1path\$1 | `https://github.com/{username}/{repo}/blob/{ref}/{path}?raw=true` `https://raw.githubusercontent.com/{username}/{repo}/{ref}/{path}` |
| GitLab | https://gitlab.com/\$1username\$1/\$1repo\$1/-/blob/\$1ref\$1/\$1path\$1 | https://gitlab.com/\$1username\$1/\$1repo\$1/-/raw/\$1ref\$1/\$1path\$1 |
| Bitbucket | https://bitbucket.org/\$1username\$1/\$1repo\$1/src/\$1ref\$1/\$1path\$1 | https://bitbucket.org/\$1username\$1/\$1repo\$1/raw/\$1ref\$1/\$1path\$1 |
GitHub, GitLab및는 퍼블릭 리포지토리에 연결되는 페이지 및 이미지 URLs을 모두 Bitbucket 지원합니다. 다음 표에는 프라이빗 리포지토리에 대한 이미지 및 링크 URLs 렌더링에 대한 각 소스 공급자의 지원이 나와 있습니다.
| 프라이빗 리포지토리 지원 | 소스 공급자 | 페이지 URL | 이미지 URL |
| --- | --- | --- | --- |
| GitHub | 리포지토리에 액세스할 수 있는 경우에만 | 아니요 |
| GitLab | 리포지토리에 액세스할 수 있는 경우에만 | 아니요 |
| Bitbucket | 리포지토리에 액세스할 수 있는 경우에만 | 아니요 |
# 프라이빗 워크플로에 대한 Sentieon 라이선스 요청
프라이빗 워크플로에서 Sentieon 소프트웨어를 사용하는 경우 Senieon 라이선스가 필요합니다. 다음 단계에 따라 Sentieon 소프트웨어에 대한 라이선스를 요청하고 설정합니다.
+ Sentieon 라이선스 요청
+ Sentieon 지원 그룹(support@sentieon.com)에 이메일을 보내 소프트웨어 라이선스를 요청합니다.
+ 이메일에 AWS 정식 사용자 ID를 입력합니다.
+ [ 다음 지침에](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId) 따라 AWS 정식 사용자 ID를 찾습니다.
+ HealthOmics 서비스 역할을 업데이트하여 해당 리전의 Sentieon 라이선스 서버 프록시 및 Sentieon Omics 버킷에 대한 액세스 권한을 부여합니다. 다음 예제에서는에서 액세스 권한을 부여합니다`us-east-1`. 필요한 경우이 텍스트를 해당 리전으로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObjectAcl",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::omics-ap-us-east-1/*",
"arn:aws:s3:::sentieon-omics-license-us-east-1/*"
]
}
]
}
```
------
+ AWS 지원 사례를 생성하여 Sentieon 라이선스 서버 프록시에 액세스합니다.
+ 지원 사례를 생성하려면 [ support.console.aws.amazon.com 이동합니다.](https://support.console.aws.amazon.com)
+ 지원 사례에 AWS 계정 및 리전을 제공합니다. 계정이 라이선스 서버 프록시의 허용 목록에 추가됩니다.
+ Sentieon 컨테이너와 Sentieon 라이선스 스크립트를 사용하여 프라이빗 워크플로를 빌드합니다.
+ 프라이빗 워크플로 내에서 Sentieon 도구를 사용하는 방법에 대한 추가 지침은 GitHub의 [Sentieon-Amazon-Omics](https://github.com/Sentieon/sentieon-amazon-omics)를 참조하세요.
+ Sentieon 소프트웨어 버전 202112.07 이상은 HealthOmics 라이선스 서버 프록시를 지원합니다. 202112.07 이전의 Sentieon 소프트웨어 버전을 사용하려면 Sentieon 지원팀에 문의하십시오.
# HealthOmics의 워크플로 린터
워크플로를 생성한 후에는 첫 번째 실행을 시작하기 전에 워크플로에서 린터를 실행하는 것이 좋습니다. 린터는 실행이 실패할 수 있는 오류를 감지합니다.
WDL의 경우 워크플로를 생성할 때 HealthOmics가 자동으로 린터를 실행합니다. 린터 출력은 **get-workflow** 응답의 `statusMessage` 필드에서 사용할 수 있습니다. 다음 CLI 명령을 사용하여 상태 출력을 검색합니다(생성한 WDL 워크플로의 워크플로 ID 사용).
```
aws omics get-workflow
—id 123456
—query 'statusMessage'
```
HealthOmics는 워크플로를 생성하기 전에 워크플로 정의에서 실행할 수 있는 린터를 제공합니다. HealthOmics로 마이그레이션하려는 기존 파이프라인에서 이러한 린터를 실행합니다.
+ **WDL** - [WDL 린터](https://gallery.ecr.aws/aws-genomics/healthomics-linter)를 실행하는 퍼블릭 Amazon ECR 이미지입니다.
+ **Nextflow** - [Nextflow에 대한 Linter 규칙을]( https://gallery.ecr.aws/aws-genomics/linter-rules-for-nextflow) 실행하는 퍼블릭 Amazon ECR 이미지입니다. [GitHub](https://github.com/awslabs/linter-rules-for-nextflow)에서이 린터의 소스 코드에 액세스할 수 있습니다.
+ **CWL** - 사용할 수 없음
# HealthOmics 워크플로 작업
프라이빗 워크플로를 생성하려면 다음이 필요합니다.
+ **Workflow definition file:** WDL, Nextflow또는 로 작성된 워크플로 정의 파일입니다CWL. 워크플로 정의는 워크플로를 사용하는 실행에 대한 입력 및 출력을 지정합니다. 또한 컴퓨팅 및 메모리 요구 사항을 포함하여 워크플로의 실행 및 실행 작업에 대한 사양도 포함되어 있습니다. 워크플로 정의 파일은 `.zip` 형식이어야 합니다. 자세한 내용은 HealthOmics의 [워크플로 정의 파일을](workflow-definition-files.md) 참조하세요. HealthOmics
+ [Amazon Q CLI](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)를 사용하여 WDL, Nextflow 및 CWL에서 워크플로 정의 파일을 빌드하고 검증할 수 있습니다. 자세한 내용은 [Amazon Q CLI에 대한 프롬프트 예제](getting-started.md#omics-q-prompts) 및 GitHub의 [HealthOmics Agentic 생성형 AI 자습](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai)서를 참조하세요.
+ **(Optional) Parameter template file:**에 작성된 파라미터 템플릿 파일입니다JSON. 파일을 생성하여 실행 파라미터를 정의하거나 HealthOmics가 파라미터 템플릿을 생성합니다. 자세한 내용은 [ HealthOmics 워크플로용 파라미터 템플릿 파일을 참조하세요](parameter-templates.md).
+ **Amazon ECR container images:** 워크플로에 사용되는 각 컨테이너에 대해 프라이빗 Amazon ECR 리포지토리를 생성합니다. 워크플로용 컨테이너 이미지를 생성하여 프라이빗 리포지토리에 저장하거나 지원되는 업스트림 레지스트리의 콘텐츠를 ECR 프라이빗 리포지토리와 동기화합니다.
+ **(Optional) Sentieon licenses:** 프라이빗 워크플로에서 Sentieon 소프트웨어를 사용할 수 있는 Sentieon 라이선스를 요청합니다.
4MiB(압축)보다 큰 워크플로 정의 파일의 경우 워크플로 생성 중에 다음 옵션 중 하나를 선택합니다.
+ Amazon Simple Storage Service 폴더에 업로드하고 위치를 지정합니다.
+ 외부 리포지토리(최대 크기 1GiB)에 업로드하고 리포지토리 세부 정보를 지정합니다.
워크플로를 생성한 후 `UpdateWorkflow` 작업으로 다음 워크플로 정보를 업데이트할 수 있습니다.
+ 명칭
+ 설명
+ 기본 스토리지 유형
+ 기본 스토리지 용량(워크플로 ID 사용)
+ README.md 파일
워크플로의 다른 정보를 변경하려면 새 워크플로 또는 워크플로 버전을 생성합니다.
워크플로 버전 관리를 사용하여 워크플로를 구성하고 구조화합니다. 버전은 반복 워크플로 업데이트의 도입을 관리하는 데도 도움이 됩니다. 버전에 대한 자세한 내용은 [워크플로 버전 생성](workflows-version-create.md)을 참조하십시오.
**Topics**
+ [프라이빗 워크플로 생성](create-private-workflow.md)
+ [프라이빗 워크플로 업데이트](update-private-workflow.md)
+ [프라이빗 워크플로 삭제](delete-private-workflow.md)
+ [워크플로 상태 확인](using-get-workflow.md)
+ [워크플로 정의에서 게놈 파일 참조](create-ref-files.md)
# 프라이빗 워크플로 생성
HealthOmics 콘솔, AWS CLI 명령 또는 AWS SDKs 중 하나를 사용하여 워크플로를 생성합니다.
**참고**
워크플로 이름에 개인 식별 정보(PII)를 포함하지 마십시오. 이러한 이름은 CloudWatch 로그에 표시됩니다.
워크플로를 생성할 때 HealthOmics는 워크플로에 범용 고유 식별자(UUID)를 할당합니다. 워크플로 UUID는 워크플로 및 워크플로 버전에서 고유한 글로벌 고유 식별자(guid)입니다. 데이터 출처를 위해 워크플로 UUID를 사용하여 워크플로를 고유하게 식별하는 것이 좋습니다.
워크플로 작업에서 외부 도구(실행 파일, 라이브러리 또는 스크립트)를 사용하는 경우 이러한 도구를 컨테이너 이미지에 빌드합니다. 컨테이너 이미지를 호스팅하는 옵션은 다음과 같습니다.
+ ECR 프라이빗 레지스트리에서 컨테이너 이미지를 호스팅합니다. 이 옵션의 사전 조건:
+ ECR 프라이빗 리포지토리를 생성하거나 기존 리포지토리를 선택합니다.
+ 에 설명된 대로 ECR 리소스 정책을 구성합니다[Amazon ECR 권한](permissions-ecr.md).
+ 컨테이너 이미지를 프라이빗 리포지토리에 업로드합니다.
+ 컨테이너 이미지를 지원되는 타사 레지스트리의 콘텐츠와 동기화합니다. 이 옵션의 사전 조건:
+ ECR 프라이빗 레지스트리에서 각 업스트림 레지스트리에 대한 풀스루 캐시 규칙을 구성합니다. 자세한 내용은 [이미지 매핑](workflows-ecr.md#ecr-pull-through-mapping-format) 단원을 참조하십시오.
+ 에 설명된 대로 ECR 리소스 정책을 구성합니다[Amazon ECR 권한](permissions-ecr.md).
+ 리포지토리 생성 템플릿을 생성합니다. 템플릿은 Amazon ECR이 업스트림 레지스트리에 대한 프라이빗 리포지토리를 생성하는 시기에 대한 설정을 정의합니다.
+ 접두사 매핑을 생성하여 워크플로 정의의 컨테이너 이미지 참조를 ECR 캐시 네임스페이스에 다시 매핑합니다.
워크플로를 생성할 때 워크플로, 실행 및 작업에 대한 정보가 포함된 워크플로 정의를 제공합니다. HealthOmics는 워크플로 정의를 로컬 또는 Amazon S3 버킷 또는 지원되는 Git 기반 리포지토리에 저장된 .zip 아카이브로 검색할 수 있습니다.
**Topics**
+ [콘솔을 사용하여 워크플로 생성](#console-create-workflows)
+ [CLI를 사용하여 워크플로 생성](#api-create-workflows)
+ [SDK를 사용하여 워크플로 생성](#sdk-create-workflows)
## 콘솔을 사용하여 워크플로 생성
**워크플로를 생성하는 단계**
1. [HealthOmics 콘솔](https://console.aws.amazon.com/omics/)을 엽니다.
1. 필요한 경우 왼쪽 탐색 창(™)을 엽니다. **프라이빗 워크플로**를 선택합니다.
1. **프라이빗 워크플로** 페이지에서 **워크플로 생성을** 선택합니다.
1. **워크플로 정의** 페이지에서 다음 정보를 제공합니다.
1. **워크플로 이름**:이 워크플로의 고유한 이름입니다. AWS HealthOmics 콘솔 및 CloudWatch 로그에서 실행을 구성하려면 워크플로 이름을 설정하는 것이 좋습니다.
1. **설명**(선택 사항):이 워크플로에 대한 설명입니다.
1. **워크플로 정의** 패널에서 다음 정보를 제공합니다.
1. **워크플로 언어**(선택 사항): 워크플로의 사양 언어를 선택합니다. 그렇지 않으면 HealthOmics가 워크플로 정의에서 언어를 결정합니다.
1. **워크플로 정의 소스**에서 Git 기반 리포지토리, Amazon S3 위치 또는 로컬 드라이브에서 정의 폴더를 가져오도록 선택합니다.
1. **리포지토리 서비스에서 가져오기의** 경우:
**참고**
HealthOmics는 GitHub, , , GitLab, Bitbucket에 대한 퍼블릭 및 프라이빗 리포지토리GitHub self-managed를 지원합니다GitLab self-managed.
1. **연결을** 선택하여 AWS 리소스를 외부 리포지토리에 연결합니다. 연결을 생성하려면 섹션을 참조하세요[외부 코드 리포지토리와 연결](setting-up-new.md#setting-up-omics-repository).
**참고**
TLV 리전의 고객은 워크플로를 생성하려면 IAD (us-east-1) 리전에서 연결을 생성해야 합니다.
1. **전체 리포지토리 ID**에 리포지토리 ID를 user-name/repo-name으로 입력합니다. 이 리포지토리의 파일에 액세스할 수 있는지 확인합니다.
1. **소스 참조**(선택 사항)에 리포지토리 소스 참조(브랜치, 태그 또는 커밋 ID)를 입력합니다. HealthOmics는 소스 참조가 지정되지 않은 경우 기본 브랜치를 사용합니다.
1. **파일 패턴 제외**에 파일 패턴을 입력하여 특정 폴더, 파일 또는 확장자를 제외합니다. 이렇게 하면 리포지토리 파일을 가져올 때 데이터 크기를 관리하는 데 도움이 됩니다. 패턴은 최대 50개이며 패턴은 [glob 패턴 구문](https://fossil-scm.org/home/doc/tip/www/globs.md)을 따라야 합니다. 예제:
1. `tests/`
1. `*.jpeg`
1. `large_data.zip`
1. **S3에서 정의 폴더 선택**의 경우:
1. 압축된 워크플로 정의 폴더가 포함된 Amazon S3 위치를 입력합니다. Amazon S3 버킷은 워크플로와 동일한 리전에 있어야 합니다.
1. 계정이 Amazon S3 버킷을 소유하지 않은 경우 S3 버킷 소유자의 AWS 계정 ID에 버킷 소유자의 계정 ID를 입력합니다. **S3 ** 이 정보는 HealthOmics가 버킷 소유권을 확인할 수 있도록 하기 위해 필요합니다.
1. **로컬 소스에서 정의 폴더 선택의** 경우:
1. 압축된 워크플로 정의 폴더의 로컬 드라이브 위치를 입력합니다.
1. **기본 워크플로 정의 파일 경로**(선택 사항): 압축된 워크플로 정의 폴더 또는 리포지토리에서 파일로의 `main` 파일 경로를 입력합니다. 워크플로 정의 폴더에 파일이 하나만 있거나 기본 파일의 이름이 "main"인 경우에는이 파라미터가 필요하지 않습니다.
1. **README 파일**(선택 사항) 패널에서 **README 파일의 소스를** 선택하고 다음 정보를 제공합니다.
+ **리포지토리 서비스에서 가져오기**의 **README 파일 경로**에 리포지토리 내의 README 파일 경로를 입력합니다.
+ **S3에서 파일 선택**의 S3**의 README 파일에 README 파일의 Amazon S3 URI를 S3**입력합니다. Amazon S3
+ **로컬 소스에서 파일 선택**: **README - 선택** 사항에서 **파일 선택을** 선택하여 업로드할 마크다운(.md) 파일을 선택합니다.
1. **기본 실행 스토리지 구성** 패널에서이 워크플로를 사용하는 실행에 대한 기본 실행 스토리지 유형 및 용량을 제공합니다.
1. **실행 스토리지 유형**: 정적 또는 동적 스토리지를 임시 실행 스토리지의 기본값으로 사용할지 여부를 선택합니다. 기본값은 정적 스토리지입니다.
1. **스토리지 용량 실행**(선택 사항): 정적 실행 스토리지 유형의 경우이 워크플로에 필요한 기본 실행 스토리지 양을 입력할 수 있습니다. 이 파라미터의 기본값은 1200GiB입니다. 실행을 시작할 때 이러한 기본값을 재정의할 수 있습니다.
1. **태그**(선택 사항):이 워크플로에 최대 50개의 태그를 연결할 수 있습니다.
1. **다음**을 선택합니다.
1. **워크플로 파라미터 추가**(선택 사항) 페이지에서 **파라미터 소스를** 선택합니다.
1. **워크플로 정의 파일에서 구문 분석**의 경우 HealthOmics는 워크플로 정의 파일에서 워크플로 파라미터를 자동으로 구문 분석합니다.
1. **Git 리포지토리에서 파라미터 템플릿 제공**에서 리포지토리의 파라미터 템플릿 파일 경로를 사용합니다.
1. **로컬 소스에서 JSON 파일 선택**에서 파라미터를 지정하는 로컬 소스에서 JSON 파일을 업로드합니다.
1. **워크플로 파라미터를 수동으로 입력**하려면 파라미터 이름과 설명을 수동으로 입력합니다.
1. **파라미터 미리 보기** 패널에서이 워크플로 버전의 파라미터를 검토하거나 변경할 수 있습니다. JSON 파일을 복원하면 로컬 변경 사항이 손실됩니다.
1. **다음**을 선택합니다.
1. **컨테이너 URI 다시 매핑** 페이지의 **매핑 규칙** 패널에서 워크플로에 대한 URI 매핑 규칙을 정의할 수 있습니다.
**매핑 파일 소스**에서 다음 옵션 중 하나를 선택합니다.
+ **없음** - 매핑 규칙이 필요하지 않습니다.
+ **S3에서 JSON 파일 선택** - 매핑 파일의 S3 위치를 지정합니다.
+ **로컬 소스에서 JSON 파일 선택** - 로컬 디바이스에서 매핑 파일 위치를 지정합니다.
+ **수동으로 매핑 입력 **- 매핑 패널에 레지스트리 매핑 및 이미지 **매핑을** 입력합니다.
1. 콘솔에 **매핑 패널이** 표시됩니다. 매핑 소스 파일을 선택한 경우 콘솔에 파일의 값이 표시됩니다.
1. **레지스트리 매핑**에서 매핑을 편집하거나 매핑을 추가할 수 있습니다(최대 20개의 레지스트리 매핑).
각 레지스트리 매핑에는 다음 필드가 포함됩니다.
+ **업스트림 레지스트리 URL** - 업스트림 레지스트리의 URI입니다.
+ **ECR 리포지토리 접두사** - Amazon ECR 프라이빗 리포지토리에서 사용할 리포지토리 접두사입니다.
+ (선택 사항) **업스트림 리포지토리 접두사** - 업스트림 레지스트리에 있는 리포지토리의 접두사입니다.
+ (선택 사항) **ECR 계정 ID** - 업스트림 컨테이너 이미지를 소유한 계정의 계정 ID입니다.
1. **이미지 매핑**에서 이미지 매핑을 편집하거나 매핑을 추가할 수 있습니다(최대 100개의 이미지 매핑).
각 이미지 매핑에는 다음 필드가 포함됩니다.
+ **소스 이미지** - 업스트림 레지스트리에서 소스 이미지의 URI를 지정합니다.
+ **대상 이미지** - 프라이빗 Amazon ECR 레지스트리에서 해당 이미지의 URI를 지정합니다.
1. **다음**을 선택합니다.
1. 워크플로 구성을 검토한 다음 **워크플로 생성을** 선택합니다.
## CLI를 사용하여 워크플로 생성
워크플로 파일과 파라미터 템플릿 파일이 로컬 시스템에 있는 경우 다음 CLI 명령을 사용하여 워크플로를 생성할 수 있습니다.
```
aws omics create-workflow \
--name "my_workflow" \
--definition-zip fileb://my-definition.zip \
--parameter-template file://my-parameter-template.json
```
`create-workflow` 작업은 다음 응답을 반환합니다.
```
{
"arn": "arn:aws:omics:us-west-2:....",
"id": "1234567",
"status": "CREATING",
"tags": {
"resourceArn": "arn:aws:omics:us-west-2:...."
},
"uuid": "64c9a39e-8302-cc45-0262-2ea7116d854f"
}
```
### 워크플로를 생성할 때 사용할 선택적 파라미터
워크플로를 생성할 때 선택적 파라미터를 지정할 수 있습니다. 구문 세부 정보는 AWS HealthOmics API 참조의 [CreateWorkflow](https://docs.aws.amazon.com/omics/latest/api/API_CreateWorkflow.html)를 참조하세요.
**Topics**
+ [워크플로 정의 Amazon S3 위치 지정](#create-defn-uri-parameter)
+ [Git 기반 리포지토리에서 워크플로 정의 사용](#create-defn-uri-git)
+ [Readme 파일 지정](#specify-readme-file)
+ [**main** 정의 파일 지정](#create-main-parameter)
+ [실행 스토리지 유형 지정](#create-run-storage-parameter)
+ [GPU 구성 지정](#create-accelerator-parameter)
+ [풀스루 캐시 매핑 파라미터 구성](#create-prefix-mapping-parameters)
#### 워크플로 정의 Amazon S3 위치 지정
워크플로 정의 파일이 Amazon S3 폴더에 있는 경우 다음 예제와 같이 `definition-uri` 파라미터를 사용하여 위치를 지정합니다. 계정이 Amazon S3 버킷을 소유하지 않은 경우 소유자의 AWS 계정 ID를 입력합니다.
```
aws omics create-workflow \
--name Test \
--definition-uri s3://omics-bucket/workflow-definition/ \
--owner-id 123456789012
...
```
#### Git 기반 리포지토리에서 워크플로 정의 사용
지원되는 Git 기반 리포지토리의 워크플로 정의를 사용하려면 요청에 `definition-repository` 파라미터를 사용합니다. 입력 소스가 두 개 이상 포함된 경우 요청이 실패하므로 다른 `definition` 파라미터를 제공하지 마십시오.
`definition-respository` 파라미터에는 다음 필드가 포함됩니다.
+ **connectionArn** - AWS 리소스를 외부 리포지토리에 연결하는 코드 연결의 ARN입니다.
+ **fullRepositoryId** - 리포지토리 ID를 로 입력합니다`owner-name/repo-name`. 이 리포지토리의 파일에 액세스할 수 있는지 확인합니다.
+ **sourceReference** (선택 사항) - 리포지토리 참조 유형(BRANCH, TAG 또는 COMMIT)과 값을 입력합니다.
소스 참조를 지정하지 않으면 HealthOmics는 기본 브랜치에서 최신 커밋을 사용합니다.
+ **excludeFilePatterns** (선택 사항) - 파일 패턴을 입력하여 특정 폴더, 파일 또는 확장자를 제외합니다. 이렇게 하면 리포지토리 파일을 가져올 때 데이터 크기를 관리하는 데 도움이 됩니다. 최대 50개의 패턴을 제공합니다. 패턴은 [ glob 패턴 구문](https://fossil-scm.org/home/doc/tip/www/globs.md)을 따라야 합니다. 예제:
+ `tests/`
+ `*.jpeg`
+ `large_data.zip`
Git 기반 리포지토리에서 워크플로 정의를 지정할 때를 사용하여 파라미터 템플릿 파일을 `parameter-template-path` 지정합니다. 이 파라미터를 제공하지 않으면 HealthOmics는 파라미터 템플릿 없이 워크플로를 생성합니다.
다음 예제는 Git 기반 프라이빗 리포지토리의 콘텐츠와 관련된 파라미터를 보여줍니다.
```
aws omics create-workflow \
--name custom-variant \
--description "Custom variant calling pipeline" \
--engine "WDL" \
--definition-repository '{
"connectionArn": "arn:aws:codeconnections:us-east-1:123456789012:connection/abcd1234-5678-90ab-cdef-1234567890ab",
"fullRepositoryId": "myorg/my-genomics-workflows",
"sourceReference": {
"type": "BRANCH",
"value": "main"
},
"excludeFilePatterns": ["tests/**", "*.log"]
}' \
--main "workflows/variant-calling/main.wdl" \
--parameter-template-path "parameters/variant-calling-params.json" \
--readme-path "docs/variant-calling-README.md" \
--storage-type "DYNAMIC" \
```
자세한 예제는 블로그 게시물 [ How To Create a AWS HealthOmics Workflows from Content in Git를 참조하세요](https://repost.aws/articles/ARCEN7AjhaRSmteczRoc_QsA/how-to-create-an-aws-healthomics-workflows-from-content-in-git).
#### Readme 파일 지정
다음 파라미터 중 하나를 사용하여 README 파일 위치를 지정할 수 있습니다.
+ **readme-markdown** - 로컬 시스템의 문자열 입력 또는 파일입니다.
+ **readme-uri** - S3에 저장된 파일의 URI입니다.
+ **readme-path ** - 리포지토리의 README 파일 경로입니다.
readme-path는 **정의 리포지토리**와 함께 사용해야 합니다. README 파라미터를 지정하지 않으면 HealthOmics는 루트 수준 README.md 파일을 리포지토리에 가져옵니다(있는 경우).
다음 예제에서는 readme-path 및 readme-uri를 사용하여 README 파일 위치를 지정하는 방법을 보여줍니다.
```
# Using README from repository
aws omics create-workflow \
--name "documented-workflow" \
--definition-repository '...' \
--readme-path "docs/workflow-guide.md"
# Using README from S3
aws omics create-workflow \
--name "s3-readme-workflow" \
--definition-repository '...' \
--readme-uri "s3://my-bucket/workflow-docs/readme.md"
```
자세한 내용은 [HealthOmics 워크플로 README 파일](workflows-readme.md) 단원을 참조하십시오.
#### **main** 정의 파일 지정
여러 워크플로 정의 파일을 포함하는 경우 `main` 파라미터를 사용하여 워크플로의 기본 정의 파일을 지정합니다.
```
aws omics create-workflow \
--name Test \
--main multi_workflow/workflow2.wdl \
...
```
#### 실행 스토리지 유형 지정
기본 실행 스토리지 유형(DYNAMIC 또는 STATIC) 및 실행 스토리지 용량(정적 스토리지에 필요)을 지정할 수 있습니다. 실행 스토리지 유형에 대한 자세한 내용은 섹션을 참조하세요[HealthOmics 워크플로에서 스토리지 유형 실행](workflows-run-types.md).
```
aws omics create-workflow \
--name my_workflow \
--definition-zip fileb://my-definition.zip \
--parameter-template file://my-parameter-template.json \
--storage-type 'STATIC' \
--storage-capacity 1200 \
```
#### GPU 구성 지정
액셀러레이터 파라미터를 사용하여 가속 컴퓨팅 인스턴스에서 실행되는 워크플로를 생성합니다. 다음 예제에서는 `accelerators` 파라미터를 사용하는 방법을 보여줍니다. 워크플로 정의에서 GPU 구성을 지정합니다. [가속 컴퓨팅 인스턴스](memory-and-compute-tasks.md#workflow-task-accelerated-computing-instances)을(를) 참조하세요.
```
aws omics create-workflow --name workflow name \
--definition-uri s3://amzn-s3-demo-bucket1/GPUWorkflow.zip \
--accelerators GPU
```
#### 풀스루 캐시 매핑 파라미터 구성
Amazon ECR 풀스루 캐시 매핑 기능을 사용하는 경우 기본 매핑을 재정의할 수 있습니다. 컨테이너 설정 파라미터에 대한 자세한 내용은 섹션을 참조하세요[프라이빗 워크플로용 컨테이너 이미지](workflows-ecr.md).
다음 예제에서 파일에는이 콘텐츠가 `mappings.json` 포함되어 있습니다.
```
{
"registryMappings": [
{
"upstreamRegistryUrl": "registry-1.docker.io",
"ecrRepositoryPrefix": "docker-hub"
},
{
"upstreamRegistryUrl": "quay.io",
"ecrRepositoryPrefix": "quay",
"accountId": "123412341234"
},
{
"upstreamRegistryUrl": "public.ecr.aws",
"ecrRepositoryPrefix": "ecr-public"
}
],
"imageMappings": [{
"sourceImage": "docker.io/library/ubuntu:latest",
"destinationImage": "healthomics-docker-2/custom/ubuntu:latest",
"accountId": "123412341234"
},
{
"sourceImage": "nvcr.io/nvidia/k8s/dcgm-exporter",
"destinationImage": "healthomics-nvidia/k8s/dcgm-exporter"
}
]
}
```
create-workflow 명령에서 매핑 파라미터를 지정합니다.
```
aws omics create-workflow \
...
--container-registry-map-file file://mappings.json
...
```
매핑 파라미터 파일의 S3 위치를 지정할 수도 있습니다.
```
aws omics create-workflow \
...
--container-registry-map-uri s3://amzn-s3-demo-bucket1/test.zip
...
```
## SDK를 사용하여 워크플로 생성
SDKs. 다음 예제에서는 Python SDK를 사용하여 워크플로를 생성하는 방법을 보여줍니다.
```
import boto3
omics = boto3.client('omics')
with open('definition.zip', 'rb') as f:
definition = f.read()
response = omics.create_workflow(
name='my_workflow',
definitionZip=definition,
parameterTemplate={ ... }
)
```
# 프라이빗 워크플로 업데이트
HealthOmics 콘솔, AWS CLI 명령 또는 AWS SDKs.
**참고**
워크플로 이름에 개인 식별 정보(PII)를 포함하지 마세요. 이러한 이름은 CloudWatch 로그에 표시됩니다.
**Topics**
+ [콘솔을 사용하여 워크플로 업데이트](#console-update-workflows)
+ [CLI를 사용하여 워크플로 업데이트](#api-update-workflows)
+ [SDK를 사용하여 워크플로 업데이트](#sdk-update-workflows)
## 콘솔을 사용하여 워크플로 업데이트
**워크플로를 업데이트하는 단계**
1. [HealthOmics 콘솔](https://console.aws.amazon.com/omics/)을 엽니다.
1. 필요한 경우 왼쪽 탐색 창(™)을 엽니다. **프라이빗 워크플로**를 선택합니다.
1. **프라이빗 워크플로** 페이지에서 업데이트할 워크플로를 선택합니다.
1. **워크플로** 페이지에서:
+ 워크플로에 버전이 있는 경우 **기본 버전을** 선택해야 합니다.
+ **작업** 목록에서 **선택한 편집**을 선택합니다.
1. **워크플로 편집** 페이지에서 다음 값 중 하나를 변경할 수 있습니다.
+ **워크플로 이름**입니다.
+ **워크플로 설명**.
+ 워크플로의 기본 **실행 스토리지 유형**입니다.
+ 기본 **실행 스토리지 용량**(실행 스토리지 유형이 정적 스토리지인 경우). 기본 실행 스토리지 구성에 대한 자세한 내용은 섹션을 참조하세요[콘솔을 사용하여 워크플로 생성](create-private-workflow.md#console-create-workflows).
1. **변경 사항 저장**을 선택하여 변경 사항을 적용합니다.
## CLI를 사용하여 워크플로 업데이트
다음 예제와 같이 워크플로 이름과 설명을 업데이트할 수 있습니다. 기본 실행 스토리지 유형(STATIC 또는 DYNAMIC)과 실행 스토리지 용량(정적 스토리지 유형의 경우)을 변경할 수도 있습니다. 실행 스토리지 유형에 대한 자세한 내용은 섹션을 참조하세요[HealthOmics 워크플로에서 스토리지 유형 실행](workflows-run-types.md).
```
aws omics update-workflow \
--id 1234567 \
--name my_workflow \
--description "updated workflow" \
--storage-type 'STATIC' \
--storage-capacity 1200
```
`update-workflow` 요청에 대한 응답을 받지 못합니다.
## SDK를 사용하여 워크플로 업데이트
SDKs.
다음 예제에서는 Python SDK를 사용하여 워크플로를 업데이트하는 방법을 보여줍니다.
```
import boto3
omics = boto3.client('omics')
response = omics.update_workflow(
name='my_workflow',
description='updated workflow'
)
```
# 프라이빗 워크플로 삭제
워크플로가 더 이상 필요하지 않은 경우 HealthOmics 콘솔, AWS CLI 명령 또는 AWS SDKs. 다음 기준을 충족하는 워크플로를 삭제할 수 있습니다.
+ 상태는 ACTIVE 또는 FAILED입니다.
+ 활성 공유가 없습니다.
+ 모든 워크플로 버전을 삭제했습니다.
워크플로를 삭제해도 워크플로를 사용하는 진행 중인 실행에는 영향을 주지 않습니다.
**Topics**
+ [콘솔을 사용하여 워크플로 삭제](#console-delete-workflows)
+ [CLI를 사용하여 워크플로 삭제](#api-delete-workflows)
+ [SDK를 사용하여 워크플로 삭제](#sdk-delete-workflows)
## 콘솔을 사용하여 워크플로 삭제
**워크플로 삭제**
1. [HealthOmics 콘솔](https://console.aws.amazon.com/omics/)을 엽니다.
1. 필요한 경우 왼쪽 탐색 창(™)을 엽니다. **프라이빗 워크플로**를 선택합니다.
1. **프라이빗 워크플로** 페이지에서 삭제할 워크플로를 선택합니다.
1. **워크플로** 페이지의 **작업** 목록에서 **선택한 삭제**를 선택합니다.
1. **워크플로 삭제** 모달에 "확인"을 입력하여 삭제를 확인합니다.
1. **삭제**를 선택합니다.
## CLI를 사용하여 워크플로 삭제
다음 예제에서는 AWS CLI 명령을 사용하여 워크플로를 삭제하는 방법을 보여줍니다. 예제를 실행하려면를 삭제하려는 워크플로의 ID`workflow id`로 바꿉니다.
```
aws omics delete-workflow
--id workflow id
```
HealthOmics는 `delete-workflow` 요청에 대한 응답을 보내지 않습니다.
## SDK를 사용하여 워크플로 삭제
SDKs.
다음 예제에서는 Python SDK를 사용하여 워크플로를 삭제하는 방법을 보여줍니다.
```
import boto3
omics = boto3.client('omics')
response = omics.delete_workflow(
id='1234567'
)
```
# 워크플로 상태 확인
워크플로를 생성한 후 다음과 같이 **get-workflow**를 사용하여 워크플로의 상태를 확인하고 다른 세부 정보를 볼 수 있습니다.
```
aws omics get-workflow --id 1234567
```
응답에는 다음과 같이 상태를 포함한 워크플로 세부 정보가 포함됩니다.
```
{
"arn": "arn:aws:omics:us-west-2:....",
"creationTime": "2022-07-06T00:27:05.542459"
"id": "1234567",
"engine": "WDL",
"status": "ACTIVE",
"type": "PRIVATE",
"main": "workflow-crambam.wdl",
"name": "workflow_name",
"storageType": "STATIC",
"storageCapacity": "1200",
"uuid": "64c9a39e-8302-cc45-0262-2ea7116d854f"
}
```
상태가 로 전환된 후이 워크플로를 사용하여 실행을 시작할 수 있습니다`ACTIVE`.
# 워크플로 정의에서 게놈 파일 참조
HealthOmics 참조 스토어 객체는 다음과 같은 URI를 사용하여 참조할 수 있습니다. 필요한 `reference ID` 경우 자체 `reference store ID`, 및 `account ID`를 사용합니다.
```
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id
```
일부 워크플로에는 참조 유전체에 대한 `SOURCE` 및 `INDEX` 파일이 모두 필요합니다. 이전 URI는 기본 짧은 양식이며 기본적으로 SOURCE 파일로 설정됩니다. 두 파일 중 하나를 지정하려면 다음과 같이 긴 URI 양식을 사용할 수 있습니다.
```
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id/source
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id/index
```
시퀀스 읽기 세트를 사용하면 다음과 같이 유사한 패턴을 갖게 됩니다.
```
aws omics create-workflow \
--name workflow name \
--main sample workflow.wdl \
--definition-uri omics://account ID.storage.us-west-2.amazonaws.com/sequence_store_id/readSet/id \
--parameter-template file://parameters_sample_description.json
```
FASTQ 기반 읽기 세트와 같은 일부 읽기 세트에는 페어링된 읽기가 포함될 수 있습니다. 다음 예제에서는 이를 SOURCE1 및 SOURCE2라고 합니다. BAM 및 CRAM과 같은 형식에는 SOURCE1 파일만 있습니다. 일부 읽기 세트에는 `bai` 또는 파일과 같은 INDEX `crai` 파일이 포함됩니다. 앞의 URI는 기본 짧은 양식이며 SOURCE1 파일로 기본 설정됩니다. 다음과 같이 긴 URI 양식을 사용하여 정확한 파일 또는 인덱스를 지정할 수 있습니다.
```
omics://123456789012.storage.us-west-2.amazonaws.com//readSet//source1
omics://123456789012.storage.us-west-2.amazonaws.com//readSet//source2
omics://123456789012.storage.us-west-2.amazonaws.com//readSet//index
```
다음은 두 개의 Omics Storage URIs.
```
{
"input_fasta": "omics://123456789012.storage.us-west-2.amazonaws.com//reference/",
"input_cram": "omics://123456789012.storage.us-west-2.amazonaws.com//readSet/"
}
```
**시작 실행** 요청에를 AWS CLI 추가하여의 입력 JSON 파일을 참조`--inputs file://`합니다.