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 補間の例を示しています。
| Input | 入出力の例 | 必須 |
| --- | --- | --- |
| x:
type: int
| 1 または 2 または ... | あり |
| x:
type: int
default: 2
| デフォルト値は 2 です。有効な入力は 1 または 2 または ... | なし |
| x:
type: int?
| 有効な入力は None または 1 または 2 または ... です。 | なし |
| x:
type: int?
default: 2
| デフォルト値は 2 です。有効な入力は None または 1 または 2 または ... です。 | なし |
次の表は、複雑なタイプの CWL 補間の例を示しています。複合型はプリミティブ型のコレクションです。
| Input | 入出力の例 | 必須 |
| --- | --- | --- |
| 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?
| [None] または None または [1,2,3] または [None, 3] ですが [] ではありません | なし |
### WDL のパラメータ検出
WDL ワークフローエンジンでは、解析ロジックは次の前提になります。
+ NULL 対応タイプは、オプションの入力パラメータとしてマークされます。
+ nullable 以外のサポート対象タイプの場合：
+ リテラルまたは式が割り当てられた入力変数は、オプションパラメータとしてマークされます。例:
```
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 補間の例を示しています。
| Input | 入出力の例 | 必須 |
| --- | --- | --- |
| Int x | 1 または 2 または ... | あり |
| Int x = 2 | 2 | なし |
| Int x = 1\$12 | 3 | なし |
| Int x = y\$1z | y\$1z | なし |
| Int? x | なし、1 または 2 または ... | あり |
| Int? x = 2 | なしまたは 2 | なし |
| Int? x = 1\$12 | なしまたは 3 | なし |
| Int? x = y\$1z | なしまたは y\$1z | なし |
次の表は、複雑なタイプの WDL 補間の例を示しています。複合型はプリミティブ型のコレクションです。
| Input | 入出力の例 | 必須 |
| --- | --- | --- |
| 配列[Int] x | [1,2,3] または [] | あり |
| 配列[Int]\$1 x | [1]、ただし [] ではない | あり |
| Array[Int]? x | なしまたは [] または [1,2,3] | なし |
| 配列[Int?] x | [] または [なし、3、なし〕 | あり |
| Array[Int?]=? x | [None] または None または [1,2,3] または [None, 3] ですが [] ではありません | なし |
| 構造体サンプル \$1文字列 a、Int y\$1 後続の入力: サンプル mySample | String a = mySample.a
Int y = mySample.y
| あり |
| 構造体サンプル \$1文字列 a、Int y\$1 後の入力: Sample? 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 | 該当なし |
| params.nested.input\$1file = "s3://bucket/data.json" | 該当なし |
次の表は、 `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"
}
} | 該当なし |
| input_file = params.input_file
| 該当なし |
# プライベートワークフローのコンテナイメージ
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 Public
+ 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. **アップストリーム名前空間**パネルで、特定のリポジトリプレフィックスを使用してアップストリームリポジトリからプルするか、プレフィックスなしでプルするかを選択します。プレフィックスを使用する場合は、**アップストリームリポジトリ**プレフィックスでプレフィックス名を指定します。
**名前空間サンプル**パネルには、プルリクエストの例、アップストリーム 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 Public の場合
次の例では、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 コンテナレジストリの場合
次の例では、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 コンテナレジストリの場合
次の例では、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 イメージに追加します。
ベストプラクティスは、タスクコンテナイメージの外部にあるスクリプト、バイナリ、ライブラリを使用しないことです。これは、`nf-core`ワークフローパッケージの一部として`bin`ディレクトリを使用するワークフローを使用する場合に特に重要です。このディレクトリはワークフロータスクで使用できますが、読み取り専用ディレクトリとしてマウントされます。このディレクトリに必要なリソースはタスクイメージにコピーし、実行時またはタスクに使用されるコンテナイメージの構築時に使用できるようにする必要があります。
HealthOmics がサポートするコンテナイメージの最大サイズ[HealthOmics ワークフローの固定サイズクォータ](fixed-quotas.md#fixed-quotas-workflows)については、「」を参照してください。
# HealthOmics ワークフロー README ファイル
ワークフローの手順、図、重要な情報を含む README.md ファイルをアップロードできます。各ワークフローバージョンは 1 つの README ファイルをサポートしており、いつでも更新できます。
**README の要件は次のとおりです。**
+ README ファイルはマークダウン (.md) 形式である必要があります
+ 最大ファイルサイズ: 500 KiB
**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 の図 | グラフを開き、グラフの位置を移動し、コードをコピーできるのは のみです |
| 見積もり | はい |
| [サブスクリプト](https://www.markdownguide.org/extended-syntax/#subscript)と[スーパースクリプト](https://www.markdownguide.org/extended-syntax/#superscript) | はい |
| [テーブル](https://www.markdownguide.org/extended-syntax/#tables) | はい。ただし、テキストの整列はサポートされていません |
| テキストの整列 | はい |
### イメージ URL とリンク 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、および は、パブリックリポジトリにリンクするページ URL とイメージ URLs の両方Bitbucketをサポートします。次の表は、プライベートリポジトリのイメージ URL とリンク URLs のレンダリングに対する各ソースプロバイダーのサポートを示しています。
| プライベートリポジトリのサポート | ソースプロバイダー | ページ URL | イメージ URL |
| --- | --- | --- | --- |
| GitHub | リポジトリにアクセスできる場合のみ | いいえ |
| GitLab | リポジトリにアクセスできる場合のみ | いいえ |
| Bitbucket | リポジトリにアクセスできる場合のみ | いいえ |
# プライベートワークフローの Sentieon ライセンスのリクエスト
プライベートワークフローで Sentieon ソフトウェアを使用している場合は、Senieon ライセンスが必要です。Sentieon ソフトウェアのライセンスをリクエストしてセットアップするには、次の手順に従います。
+ Sentieon ライセンスをリクエストする
+ ソフトウェアライセンスをリクエストするには、Sentieon サポートグループ (support@sentieon.com) に E メールを送信します。
+ E メールに 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/*"
]
}
]
}
```
------
+ Sentieon ライセンスサーバープロキシにアクセスするための AWS サポートケースを生成します。
+ サポートケースを作成するには、[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 のワークフローlinters
ワークフローを作成したら、最初の実行を開始する前に、ワークフローで linter を実行することをお勧めします。linter は、実行が失敗する原因となるエラーを検出します。
WDL の場合、ワークフローを作成すると HealthOmics は自動的に linter を実行します。linter 出力は、**get-workflow**レスポンスの `statusMessage`フィールドで使用できます。次の CLI コマンドを使用してステータス出力を取得します (作成した WDL ワークフローのワークフロー ID を使用します）。
```
aws omics get-workflow
—id 123456
—query 'statusMessage'
```
HealthOmics には、ワークフローを作成する前にワークフロー定義で実行できる linter が用意されています。HealthOmics に移行する既存のパイプラインでこれらの linters を実行します。
+ **WDL** – [WDL linter を実行するためのパブリック Amazon ECR ](https://gallery.ecr.aws/aws-genomics/healthomics-linter)イメージ。
+ **Nextflow** – [Nextflow の Linter ルール]( https://gallery.ecr.aws/aws-genomics/linter-rules-for-nextflow)を実行するためのパブリック Amazon ECR イメージ。この linter のソースコードには、[GitHub](https://github.com/awslabs/linter-rules-for-nextflow) からアクセスできます。
+ **CWL** – 利用できません
# HealthOmics ワークフローオペレーション
プライベートワークフローを作成するには、以下が必要です。
+ **Workflow definition file:** WDL、Nextflow、または で記述されたワークフロー定義ファイルCWL。ワークフロー定義は、ワークフローを使用する実行の入力と出力を指定します。また、コンピューティングやメモリの要件など、ワークフローの実行タスクと実行タスクの仕様も含まれています。ワークフロー定義ファイルは `.zip`形式である必要があります。詳細については、HealthOmics の[ワークフロー定義ファイル](workflow-definition-files.md)」を参照してください。
+ [Amazon Q CLI ](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)を使用して、WDL、Nextflow、CWL でワークフロー定義ファイルを構築および検証できます。詳細については、GitHub の[「Amazon Q CLI のプロンプトの例](getting-started.md#omics-q-prompts)[」およびHealthOmics エージェント生成 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ライセンスをリクエストします。
4 MiB (圧縮) を超えるワークフロー定義ファイルの場合、ワークフローの作成時に次のいずれかのオプションを選択します。
+ Amazon Simple Storage Service フォルダにアップロードし、場所を指定します。
+ 外部リポジトリ (最大サイズ 1 GiB) にアップロードし、リポジトリの詳細を指定します。
ワークフローを作成したら、 `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 は、ワークフローとワークフローバージョン全体で一意なグローバル一意識別子 (ガイド) です。データ出所の目的で、ワークフロー 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 バケットに保存されている .zip アーカイブとして、またはサポートされている Git ベースのリポジトリからワークフロー定義を取得できます。
**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、、 のパブリックリポジトリとプライベートリポジトリをサポートしていますBitbucketGitHub self-managedGitLab 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. zip 形式のワークフロー定義フォルダを含む Amazon S3 の場所を入力します。Amazon S3 バケットは、ワークフローと同じリージョンにある必要があります。
1. アカウントが Amazon S3 バケットを所有していない場合は、S3 バケット所有者の AWS アカウント ID にバケット所有者のアカウント ID を入力します。 **S3 ** この情報は、HealthOmics がバケットの所有権を検証できるようにするために必要です。
1. **ローカルソースから定義フォルダを選択する**:
1. 圧縮ワークフロー定義フォルダのローカルドライブの場所を入力します。
1. **メインワークフロー定義ファイルパス** (オプション): 圧縮されたワークフロー定義フォルダまたはリポジトリから ファイルへの`main`ファイルパスを入力します。ワークフロー定義フォルダにファイルが 1 つしかない場合、またはメインファイルの名前が「main」の場合、このパラメータは必要ありません。
1. **README ファイル** (オプション) パネルで、**README ファイルのソース**を選択し、次の情報を指定します。
+ **リポジトリサービスからインポート**するには、**README ファイルパス**にリポジトリ内の README ファイルへのパスを入力します。
+ **S3 からファイルを選択する**には、S3 の **README ファイルに S3**README ファイルの Amazon S3 URI を入力します。
+ **ローカルソースからファイルを選択**: **README で - オプション**で、**ファイルを選択** を選択して、アップロードするマークダウン (.md) ファイルを選択します。
1. **デフォルトの実行ストレージ設定**パネルで、このワークフローを使用する実行のデフォルトの実行ストレージタイプと容量を指定します。
1. **実行ストレージタイプ**: 一時実行ストレージのデフォルトとして静的ストレージと動的ストレージのどちらを使用するかを選択します。デフォルトは静的ストレージです。
1. **Run storage capacity** (オプション): 静的実行ストレージタイプでは、このワークフローに必要なデフォルトの実行ストレージ量を入力できます。このパラメータのデフォルト値は 1200 GiB です。実行を開始するときに、これらのデフォルト値を上書きできます。
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 an 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 は **definition-respository** と組み合わせてのみ使用してください。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. **ワークフローの編集**ページで、次の値のいずれかを変更できます。
+ **ワークフロー名**。
+ **ワークフローの説明**。
+ ワークフローのデフォルトの **Run ストレージタイプ**。
+ デフォルトの **Run ストレージ容量** (実行ストレージタイプが静的ストレージの場合）。デフォルトの実行ストレージ設定の詳細については、「」を参照してください[コンソールを使用したワークフローの作成](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 コマンドを使用してワークフローを削除する方法を示しています。この例を実行するには、 を、削除するワークフローの `workflow id` 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`場合は、独自の `account ID`、`reference store 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
```
以下は、2 つの 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/"
}
```
**開始/実行**リクエスト`--inputs file://`に を追加して AWS CLI 、 の入力 JSON ファイルを参照します。