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
```
------
# Parametervorlagendateien für HealthOmics Workflows
Parametervorlagen definieren die Eingabeparameter für einen Workflow. Sie können Eingabeparameter definieren, um Ihren Workflow flexibler und vielseitiger zu gestalten. Sie können beispielsweise einen Parameter für den Amazon S3 S3-Speicherort der Referenzgenomdateien definieren. Parametervorlagen können über einen Git-basierten Repository-Dienst oder Ihr lokales Laufwerk bereitgestellt werden. Benutzer können den Workflow dann mit verschiedenen Datensätzen ausführen.
Sie können die Parametervorlage für Ihren Workflow oder HealthOmics die Parametervorlage für Sie erstellen.
Die Parametervorlage ist eine JSON-Datei. In der Datei ist jeder Eingabeparameter ein benanntes Objekt, das mit dem Namen der Workflow-Eingabe übereinstimmen muss. Wenn Sie einen Lauf starten und nicht Werte für alle erforderlichen Parameter angeben, schlägt der Lauf fehl.
Das Eingabeparameterobjekt umfasst die folgenden Attribute:
+ **description**— Dieses erforderliche Attribut ist eine Zeichenfolge, die von der Konsole auf der **Startrun-Seite** angezeigt wird. Diese Beschreibung wird auch als Run-Metadaten gespeichert.
+ **optional**— Dieses optionale Attribut gibt an, ob der Eingabeparameter optional ist. Wenn Sie das **optional** Feld nicht angeben, ist der Eingabeparameter erforderlich.
Die folgende Beispielparametervorlage zeigt, wie die Eingabeparameter angegeben werden.
```
{
"myRequiredParameter1": {
"description": "this parameter is required",
},
"myRequiredParameter2": {
"description": "this parameter is also required",
"optional": false
},
"myOptionalParameter": {
"description": "this parameter is optional",
"optional": true
}
}
```
## Generieren von Parametervorlagen
HealthOmics generiert die Parametervorlage, indem die Workflow-Definition analysiert wird, um Eingabeparameter zu ermitteln. Wenn Sie eine Parametervorlagendatei für einen Workflow bereitstellen, überschreiben die Parameter in Ihrer Datei die in der Workflow-Definition erkannten Parameter.
Es gibt geringfügige Unterschiede zwischen der Parsing-Logik der CWL-, WDL- und Nextflow-Engines, wie in den folgenden Abschnitten beschrieben.
**Topics**
+ [Parametererkennung für CWL](#parameter-parsing-cwl)
+ [Parametererkennung für WDL](#parameter-parsing-wdl)
+ [Parametererkennung für Nextflow](#parameter-parsing-nextflow)
### Parametererkennung für CWL
In der CWL-Workflow-Engine geht die Parsing-Logik von den folgenden Annahmen aus:
+ Alle unterstützten Typen, für die ein Nullwert zulässig ist, sind als optionale Eingabeparameter gekennzeichnet.
+ Alle unterstützten Typen, die nicht Null enthalten, werden als erforderliche Eingabeparameter gekennzeichnet.
+ Alle Parameter mit Standardwerten sind als optionale Eingabeparameter gekennzeichnet.
+ Die Beschreibungen werden aus dem `label` Abschnitt der `main` Workflow-Definition extrahiert. Wenn nicht angegeben, `label` ist die Beschreibung leer (eine leere Zeichenfolge).
Die folgenden Tabellen zeigen Beispiele für die CWL-Interpolation. Für jedes Beispiel lautet der Parametername. `x` Wenn der Parameter erforderlich ist, müssen Sie einen Wert für den Parameter angeben. Wenn der Parameter optional ist, müssen Sie keinen Wert angeben.
Diese Tabelle zeigt Beispiele für die CWL-Interpolation für primitive Typen.
| Eingabe | Beispiel für Eingabe/Ausgabe | Erforderlich |
| --- | --- | --- |
| x:
type: int
| 1 oder 2 oder... | Ja |
| x:
type: int
default: 2
| Der Standardwert ist 2. Gültige Eingabe ist 1 oder 2 oder... | Nein |
| x:
type: int?
| Gültige Eingabe ist Keine oder 1 oder 2 oder... | Nein |
| x:
type: int?
default: 2
| Der Standardwert ist 2. Gültige Eingabe ist Keine oder 1 oder 2 oder... | Nein |
Die folgende Tabelle enthält Beispiele für die CWL-Interpolation für komplexe Typen. Ein komplexer Typ ist eine Sammlung primitiver Typen.
| Eingabe | Beispiel für Eingabe/Ausgabe | Erforderlich |
| --- | --- | --- |
| x:
type: array
items: int
| [] oder [1,2,3] | Ja |
| x:
type: array?
items: int
| Keiner oder [] oder [1,2,3] | Nein |
| x:
type: array
items: int?
| [] oder [Keine, 3, Keine] | Ja |
| x:
type: array?
items: int?
| [Keine] oder Keine oder [1,2,3] oder [Keine, 3] aber nicht [] | Nein |
### Parametererkennung für WDL
In der WDL-Workflow-Engine geht die Parsing-Logik von den folgenden Annahmen aus:
+ Alle unterstützten Typen, für die NULL-Werte zulässig sind, sind als optionale Eingabeparameter gekennzeichnet.
+ Für unterstützte Typen, die keine NULL-Werte zulassen:
+ Jede Eingabevariable mit der Zuweisung von Literalen oder Ausdrücken ist als optionale Parameter gekennzeichnet. Zum Beispiel:
```
Int x = 2
Float f0 = 1.0 + f1
```
+ Wenn den Eingabeparametern keine Werte oder Ausdrücke zugewiesen wurden, werden sie als erforderliche Parameter markiert.
+ Beschreibungen werden aus `parameter_meta` der `main` Workflow-Definition extrahiert. Wenn nicht angegeben, `parameter_meta` ist die Beschreibung leer (eine leere Zeichenfolge). Weitere Informationen finden Sie in der WDL-Spezifikation für [Parameter-Metadaten](https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#metadata-sections).
Die folgenden Tabellen enthalten Beispiele für WDL-Interpolation. Für jedes Beispiel lautet der Parametername. `x` Wenn der Parameter erforderlich ist, müssen Sie einen Wert für den Parameter angeben. Wenn der Parameter optional ist, müssen Sie keinen Wert angeben.
Diese Tabelle zeigt Beispiele für WDL-Interpolation für primitive Typen.
| Eingabe | Beispiel für Eingabe/Ausgabe | Erforderlich |
| --- | --- | --- |
| Ganzzahl x | 1 oder 2 oder... | Ja |
| Int x = 2 | 2 | Nein |
| Ganzzahl x = 1\$12 | 3 | Nein |
| Ganzzahl x = y\$1z | y\$1z | Nein |
| Int? x | Keiner oder 1 oder 2 oder... | Ja |
| Int? x = 2 | Keiner oder 2 | Nein |
| Int? x = 1\$12 | Keiner oder 3 | Nein |
| Int? x = y\$1z | Keiner oder y\$1z | Nein |
Die folgende Tabelle zeigt Beispiele für die WDL-Interpolation für komplexe Typen. Ein komplexer Typ ist eine Sammlung primitiver Typen.
| Eingabe | Beispiel für Eingabe/Ausgabe | Erforderlich |
| --- | --- | --- |
| Array [Int] x | [1,2,3] oder [] | Ja |
| Reihe [Int] \$1 x | [1], aber nicht [] | Ja |
| Array [Int]? x | Keiner oder [] oder [1,2,3] | Nein |
| Array [Int?] x | [] oder [Keine, 3, Keine] | Ja |
| Array [Int?] =? x | [Keine] oder Keine oder [1,2,3] oder [Keine, 3] aber nicht [] | Nein |
| Strukturbeispiel \$1Zeichenfolge a, Int y\$1 später in den Eingaben: Beispiel mySample | String a = mySample.a
Int y = mySample.y
| Ja |
| Strukturbeispiel \$1Zeichenfolge a, Int y\$1 später in den Eingaben: Beispiel? Meine Probe | if (defined(mySample)) {
String a = mySample.a
Int y = mySample.y
} | Nein |
### Parametererkennung für Nextflow
HealthOmics Generiert für Nextflow die Parametervorlage durch Analysieren der Datei. `nextflow_schema.json` Wenn die Workflow-Definition keine Schemadatei enthält, wird die Haupt-Workflow-Definitionsdatei HealthOmics analysiert.
**Topics**
+ [Analysieren der Schemadatei](#parameter-parsing-nextflow-schema)
+ [Analysieren der Hauptdatei](#parameter-parsing-nextflow-main)
+ [Verschachtelte Parameter](#parameter-parsing-nextflow-nested)
+ [Beispiele für Nextflow-Interpolation](#parameter-parsing-nextflow-examples)
#### Analysieren der Schemadatei
Damit das Parsen korrekt funktioniert, stellen Sie sicher, dass die Schemadatei die folgenden Anforderungen erfüllt:
+ Die Schemadatei hat einen Namen `nextflow_schema.json` und befindet sich in demselben Verzeichnis wie die Haupt-Workflow-Datei.
+ Die Schemadatei ist gültiges JSON, wie in einem der folgenden Schemas definiert:
+ [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 analysiert die `nextflow_schema.json` Datei, um die Parametervorlage zu generieren:
+ Extrahiert alles**properties**, was im Schema definiert ist.
+ Schließt die Eigenschaft ein**description**, sofern sie für die Eigenschaft verfügbar ist.
+ Identifiziert, ob jeder Parameter optional oder erforderlich ist, basierend auf dem **required** Feld der Eigenschaft.
Das folgende Beispiel zeigt eine Definitionsdatei und die generierte Parameterdatei.
```
{
"$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" }
]
}
```
Die generierte Parametervorlage:
```
{
"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
}
}
```
#### Analysieren der Hauptdatei
Wenn die Workflow-Definition keine `nextflow_schema.json` Datei enthält, wird die Haupt-Workflow-Definitionsdatei HealthOmics analysiert.
HealthOmics analysiert die `params` Ausdrücke, die in der Workflow-Definitionsdatei und in der `nextflow.config` Datei gefunden wurden. Alle `params` mit Standardwerten sind als optional gekennzeichnet.
Beachten Sie die folgenden Anforderungen, damit das Parsen korrekt funktioniert:
+ HealthOmics analysiert nur die Haupt-Workflow-Definitionsdatei. Um sicherzustellen, dass alle Parameter erfasst werden, empfehlen wir, eine Verbindung zu allen **params** Untermodulen und importierten Workflows herzustellen.
+ Die Konfigurationsdatei ist optional. Wenn Sie eine definieren, geben Sie ihr einen Namen `nextflow.config` und platzieren Sie sie im selben Verzeichnis wie die Haupt-Workflow-Definitionsdatei.
Das folgende Beispiel zeigt eine Definitionsdatei und die generierte Parametervorlage.
```
params.input_file = "default.txt"
params.threads = 4
params.memory = "8GB"
workflow {
if (params.version) {
println "Using version: ${params.version}"
}
}
```
Die generierte Parametervorlage:
```
{
"input_file": {
"description": None,
"optional": True
},
"threads": {
"description": None,
"optional": True
},
"memory": {
"description": None,
"optional": True
},
"version": {
"description": None,
"optional": False
}
}
```
HealthOmics Sammelt bei Standardwerten, die in nextflow.config definiert sind, `params` Zuweisungen und Parameter, die darin deklariert sind`params {}`, wie im folgenden Beispiel gezeigt. `params`Muss in Zuweisungsanweisungen auf der linken Seite der Anweisung stehen.
```
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}"
```
Die generierte Parametervorlage:
```
{
// 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
}
}
```
#### Verschachtelte Parameter
Beides `nextflow_schema.json` und `nextflow.config` erlaubt verschachtelte Parameter. Für die HealthOmics Parametervorlage sind jedoch nur die Parameter der obersten Ebene erforderlich. Wenn Ihr Workflow einen verschachtelten Parameter verwendet, müssen Sie ein JSON-Objekt als Eingabe für diesen Parameter angeben.
##### Verschachtelte Parameter in Schemadateien
HealthOmics überspringt verschachtelte Elemente **params** beim Parsen einer Datei. `nextflow_schema.json` Wenn Sie beispielsweise die folgende Datei definieren: `nextflow_schema.json`
```
{
"properties": {
"input": {
"properties": {
"input_file": { ... },
"input_num": { ... }
}
},
"input_bool": { ... }
}
}
```
HealthOmics ignoriert `input_file` und `input_num` wenn es die Parametervorlage generiert:
```
{
"input": {
"description": None,
"optional": True
},
"input_bool": {
"description": None,
"optional": True
}
}
```
Wenn Sie diesen Workflow ausführen, HealthOmics erwartet eine `input.json` Datei, die der folgenden ähnelt:
```
{
"input": {
"input_file": "s3://bucket/obj",
"input_num": 2
},
"input_bool": false
}
```
##### Verschachtelte Parameter in Konfigurationsdateien
HealthOmics sammelt keine **params** in einer `nextflow.config` Datei verschachtelten Dateien und überspringt sie beim Parsen. Wenn Sie beispielsweise die folgende Datei definieren: `nextflow.config`
```
params.alpha = "alpha"
params.nested.beta = "beta"
params {
gamma = "gamma"
group {
delta = "delta"
}
}
```
HealthOmics ignoriert `params.nested.beta` und `params.group.delta` wenn es die Parametervorlage generiert:
```
{
"alpha": {
"description": None,
"optional": True
},
"gamma": {
"description": None,
"optional": True
}
}
```
#### Beispiele für Nextflow-Interpolation
Die folgende Tabelle zeigt Beispiele für die Nextflow-Interpolation für Parameter in der Hauptdatei.
| Parameter | Erforderlich |
| --- | --- |
| params.input\$1file | Ja |
| params.input\$1file = "s3://bucket/data.json“ | Nein |
| params.nested.input\$1file | N/A |
| params.nested.input\$1file = "s3://bucket/data.json“ | N/A |
Die folgende Tabelle zeigt Beispiele für die Nextflow-Interpolation für Parameter in der Datei. `nextflow.config`
| Parameter | Erforderlich |
| --- | --- |
| params.input_file = "s3://bucket/data.json"
| Nein |
| params {
input_file = "s3://bucket/data.json"
} | Nein |
| params {
nested {
input_file = "s3://bucket/data.json"
}
} | N/A |
| input_file = params.input_file
| N/A |
# Container-Images für private Workflows
HealthOmics unterstützt Container-Images, die in privaten Amazon ECR-Repositorys gehostet werden. Sie können Container-Images erstellen und sie in das private Repository hochladen. Sie können Ihre private Amazon ECR-Registrierung auch als Pull-Through-Cache verwenden, um den Inhalt von Upstream-Registrierungen zu synchronisieren.
Ihr Amazon ECR-Repository muss sich in derselben AWS Region befinden wie das Konto, das den Service aufruft. Eine andere Person AWS-Konto kann Eigentümer des Container-Images sein, sofern das Quell-Image-Repository die entsprechenden Berechtigungen bietet. Weitere Informationen finden Sie unter [Richtlinien für den kontenübergreifenden Zugriff auf Amazon ECR](permissions-ecr.md#permissions-cross-account).
Wir empfehlen Ihnen, Ihr Amazon ECR-Container-Image URIs als Parameter in Ihrem Workflow zu definieren, damit der Zugriff verifiziert werden kann, bevor der Lauf beginnt. Es macht es auch einfacher, einen Workflow in einer neuen Region auszuführen, indem der Parameter Region geändert wird.
**Anmerkung**
HealthOmics unterstützt keine ARM-Container und unterstützt keinen Zugriff auf öffentliche Repositorys.
Informationen zur Konfiguration von IAM-Berechtigungen für den Zugriff HealthOmics auf Amazon ECR finden Sie unter. [HealthOmics Berechtigungen für Ressourcen](permissions-resource.md)
**Topics**
+ [Synchronisieren mit Container-Registrierungen von Drittanbietern](#ecr-pull-through)
+ [Allgemeine Überlegungen zu Amazon ECR-Container-Images](#ecr-considerations)
+ [Umgebungsvariablen für HealthOmics Workflows](#ecr-env-vars)
+ [Verwenden von Java in Amazon ECR-Container-Images](#ecr-java-considerations)
+ [Hinzufügen von Aufgabeneingaben zu einem Amazon ECR-Container-Image](#ecr-tasks)
## Synchronisieren mit Container-Registrierungen von Drittanbietern
Sie können Amazon ECR Pull-Through-Cache-Regeln verwenden, um Repositorys in einer unterstützten Upstream-Registry mit Ihren privaten Amazon ECR-Repositorys zu synchronisieren. Weitere Informationen finden Sie unter [Synchronisieren einer Upstream-Registrierung](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html) im *Amazon ECR-Benutzerhandbuch*.
Der Pull-Through-Cache erstellt automatisch das Image-Repository in Ihrer privaten Registrierung, wenn Sie den Cache erstellen, und er synchronisiert sich automatisch mit dem zwischengespeicherten Image, wenn Änderungen am Upstream-Image vorgenommen werden.
HealthOmics unterstützt den Pull-Through-Cache für die folgenden Upstream-Registrierungen:
+ Amazon ECR Public
+ Registrierung für Kubernetes-Container-Images
+ Quay
+ Docker Hub
+ Microsoft Azure Container Registry
+ GitHub Container-Registrierung
+ GitLab Container-Registrierung
HealthOmics unterstützt keinen Pull-Through-Cache für ein privates Amazon ECR-Upstream-Repository.
Zu den Vorteilen der Verwendung des Amazon ECR Pull-Through-Cache gehören:
1. Sie müssen Container-Images nicht manuell zu Amazon ECR migrieren oder Updates aus dem Drittanbieter-Repository synchronisieren.
1. Workflows greifen auf die synchronisierten Container-Images in Ihrem privaten Repository zu. Dies ist zuverlässiger als das Herunterladen von Inhalten zur Laufzeit aus einer öffentlichen Registrierung.
1. Da Amazon ECR Pull-Through-Caches eine vorhersehbare URI-Struktur verwenden, kann der HealthOmics Service die private Amazon ECR-URI automatisch der Upstream-Registrierungs-URI zuordnen. Sie müssen die URI-Werte in der Workflow-Definition nicht aktualisieren und ersetzen.
**Topics**
+ [Pull-Through-Cache konfigurieren](#ecr-pull-through-configure)
+ [Registrierungszuordnungen](#ecr-pull-through-registry-mapping)
+ [Bildzuordnungen](#ecr-pull-through-mapping-format)
### Pull-Through-Cache konfigurieren
Amazon ECR bietet eine Registrierung für Sie AWS-Konto in jeder Region. Stellen Sie sicher, dass Sie die Amazon ECR-Konfiguration in derselben Region erstellen, in der Sie den Workflow ausführen möchten.
In den folgenden Abschnitten werden die Konfigurationsaufgaben für den Pull-Through-Cache beschrieben.
**Topics**
+ [Erstellen Sie eine Pull-Through-Cache-Regel](#create-ecr-ptc)
+ [Registrierungsberechtigungen für die Upstream-Registrierung](#reg-ecr-ptc)
+ [Vorlagen für die Erstellung von Reposit](#repo-create-templates-ptc)
+ [Den Workflow erstellen](#reg-mapping-ecr-ptc)
#### Erstellen Sie eine Pull-Through-Cache-Regel
Erstellen Sie eine Amazon ECR-Pull-Through-Cache-Regel für jede Upstream-Registrierung, die Bilder enthält, die Sie zwischenspeichern möchten. Eine Regel spezifiziert eine Zuordnung zwischen einer Upstream-Registrierung und dem privaten Amazon ECR-Repository.
Für eine Upstream-Registrierung, die eine Authentifizierung erfordert, geben Sie Ihre Anmeldeinformationen mithilfe von AWS Secrets Manager ein.
**Anmerkung**
Ändern Sie eine Pull-Through-Cache-Regel nicht, während ein aktiver Lauf das private Repository verwendet. Der Lauf könnte fehlschlagen oder, was noch wichtiger ist, dazu führen, dass Ihre Pipeline unerwartete Bilder verwendet.
Weitere Informationen finden Sie unter [Erstellen einer Pull-Through-Cache-Regel](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) im *Amazon Elastic Container Registry-Benutzerhandbuch*.
##### Erstellen Sie mithilfe der Konsole eine Pull-Through-Cache-Regel
Gehen Sie mit der Amazon ECR-Konsole wie folgt vor, um den Pull-Through-Cache zu konfigurieren:
1. Öffnen Sie die Amazon ECR-Konsole: https://console.aws.amazon.com /ecr
1. Erweitern Sie im linken Menü unter **Private Registrierung** die Option **Funktionen und Einstellungen**. Wählen Sie dann **Pull** through Cache aus.
1. Wählen **Sie auf der Seite Pull-Through-Cache** die Option **Regel hinzufügen** aus.
1. Wählen Sie im Bereich **Upstream-Registrierung** die Upstream-Registrierung aus, die mit Ihrer privaten Registrierung synchronisiert werden soll, und klicken Sie dann auf **Weiter**.
1. Wenn für die Upstream-Registrierung eine Authentifizierung erforderlich ist, öffnet die Konsole eine neue Seite, auf der Sie das SageMaker KI-Geheimnis angeben, das Ihre Anmeldeinformationen enthält. Wählen Sie **Weiter** aus.
1. Wählen **Sie unter Namespaces angeben** im Bereich **Cache-Namespace** aus, ob die privaten Repositorys mit einem bestimmten Repository-Präfix oder ohne Präfix erstellt werden sollen. **Wenn Sie ein Präfix verwenden möchten, geben Sie den Präfixnamen im Feld Cache-Repository-Präfix an.**
1. Wählen Sie im Bereich **Upstream-Namespace** aus, ob aus Upstream-Repositorys mit einem bestimmten Repository-Präfix oder ohne Präfix abgerufen werden soll. Wenn Sie ein Präfix verwenden möchten, geben Sie den Präfixnamen im Feld **Upstream-Repository-Präfix** an.
Das **Namespace-Beispielfenster** zeigt ein Beispiel für eine Pull-Anfrage, eine Upstream-URL und die URL des Cache-Repositorys, das erstellt wird.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Konfiguration und wählen Sie **Create**, um die Regel zu erstellen.
Weitere Informationen finden Sie unter [Eine Pull-Through-Cache-Regel erstellen (AWS Management Console)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-console).
##### Erstellen Sie mit der CLI eine Pull-Through-Cache-Regel
Verwenden Sie den Amazon **create-pull-through-cache-rule** ECR-Befehl, um eine Pull-Through-Cache-Regel zu erstellen. Für Upstream-Registrierungen, die eine Authentifizierung erfordern, speichern Sie die Anmeldeinformationen in einem Secrets Manager Manager-Geheimnis.
Die folgenden Abschnitte enthalten Beispiele für jede unterstützte Upstream-Registrierung.
##### Für Amazon ECR Public
Im folgenden Beispiel wird eine Pull-Through-Cache-Regel für die öffentliche Registrierung von Amazon ECR erstellt. Es gibt ein Repository-Präfix von `ecr-public`, was dazu führt, dass jedes Repository, das mit der Pull-Through-Cache-Regel erstellt wurde, das Benennungsschema von `ecr-public/upstream-repository-name` hat.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix ecr-public \
--upstream-registry-url public.ecr.aws \
--region us-east-1
```
##### Für Kubernetes Container Registry
Im folgenden Beispiel wird eine Pull-Through-Cache-Regel für das öffentliche Kubernetes-Registry erstellt. Es gibt ein Repository-Präfix von `kubernetes`, was dazu führt, dass jedes Repository, das mit der Pull-Through-Cache-Regel erstellt wurde, das Benennungsschema von `kubernetes/upstream-repository-name` hat.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix kubernetes \
--upstream-registry-url registry.k8s.io \
--region us-east-1
```
##### Für Quay
Im folgenden Beispiel wird eine Pull-Through-Cache-Regel für die öffentliche Registrierung von Quay erstellt. Es gibt ein Repository-Präfix von `quay`, was dazu führt, dass jedes Repository, das mit der Pull-Through-Cache-Regel erstellt wurde, das Benennungsschema von `quay/upstream-repository-name` hat.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix quay \
--upstream-registry-url quay.io \
--region us-east-1
```
##### Für Docker Hub
Im folgenden Beispiel wird eine Pull-Through-Cache-Regel für die Docker-Hub-Registrierung von Quay erstellt. Es gibt ein Repository-Präfix von `docker-hub`, was dazu führt, dass jedes Repository, das mit der Pull-Through-Cache-Regel erstellt wurde, das Benennungsschema von `docker-hub/upstream-repository-name` hat. Sie müssen den vollständigen Amazon-Ressourcennamen (ARN) des Secrets mit Ihren Anmeldeinformationen für Docker Hub angeben.
```
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
```
##### Für Container Registry GitHub
Im folgenden Beispiel wird eine Pull-Through-Cacheregel für die GitHub Container Registry erstellt. Es gibt ein Repository-Präfix von `github`, was dazu führt, dass jedes Repository, das mit der Pull-Through-Cache-Regel erstellt wurde, das Benennungsschema von `github/upstream-repository-name` hat. Sie müssen den vollständigen Amazon-Ressourcennamen (ARN) des Geheimnisses angeben, das Ihre Anmeldeinformationen für die GitHub Container Registry enthält.
```
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
```
##### Für Microsoft Azure Container Registry
Im folgenden Beispiel wird eine Pull-Through-Cacheregel für die Microsoft Azure Container Registry erstellt. Es gibt ein Repository-Präfix von `azure`, was dazu führt, dass jedes Repository, das mit der Pull-Through-Cache-Regel erstellt wurde, das Benennungsschema von `azure/upstream-repository-name` hat. Sie müssen den vollständigen Amazon-Ressourcennamen (ARN) des Secrets mit Ihren Anmeldeinformationen für die Microsoft Azure Container Registry angeben.
```
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
```
##### Für GitLab Container Registry
Im folgenden Beispiel wird eine Pull-Through-Cacheregel für die GitLab Container Registry erstellt. Es gibt ein Repository-Präfix von `gitlab`, was dazu führt, dass jedes Repository, das mit der Pull-Through-Cache-Regel erstellt wurde, das Benennungsschema von `gitlab/upstream-repository-name` hat. Sie müssen den vollständigen Amazon-Ressourcennamen (ARN) des Geheimnisses angeben, das Ihre Anmeldeinformationen für die GitLab Container Registry enthält.
```
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
```
Weitere Informationen finden Sie unter [Erstellen einer Pull-Through-Cache-Regel (CLI)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-cli) im *Amazon ECR-Benutzerhandbuch*.
Sie können den **get-run-task** CLI-Befehl verwenden, um Informationen über das Container-Image abzurufen, das für eine bestimmte Aufgabe verwendet wird:
```
aws omics get-run-task --id 1234567 --task-id
```
Die Ausgabe enthält die folgenden Informationen über das Container-Image:
```
"imageDetails": {
"image": "string",
"imageDigest": "string",
"sourceImage": "string",
...
}
```
#### Registrierungsberechtigungen für die Upstream-Registrierung
Verwenden Sie Registrierungsberechtigungen, um die Verwendung des Pull-Through-Cache und das Abrufen der Container-Images in die private Amazon ECR-Registrierung zu ermöglichen HealthOmics . Fügen Sie der Registrierung eine Amazon ECR-Registrierungsrichtlinie hinzu, die die in Läufen verwendeten Container bereitstellt.
Die folgende Richtlinie erteilt dem HealthOmics Service die Erlaubnis, Repositorys mit den angegebenen Pull-Through-Cache-Präfixen zu erstellen und Upstream-Pulls in diese Repositorys zu initiieren.
1. Öffnen Sie in der Amazon ECR-Konsole das linke Menü, erweitern Sie unter **Private Registrierung den Eintrag **Registrierungsberechtigungen****. Wählen Sie dann **Kontoauszug generieren** aus.
1. Wählen Sie oben rechts JSON aus. Geben Sie eine Richtlinie ein, die der folgenden ähnelt:
------
#### [ 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/*"
]
}
]
}
```
------
#### Vorlagen für die Erstellung von Reposit
Um das Pull-Through-Caching in verwenden zu können HealthOmics, muss das Amazon ECR-Repository über eine Vorlage für die Repository-Erstellung verfügen. Die Vorlage definiert Konfigurationseinstellungen für den Fall, dass Sie oder Amazon ECR ein privates Repository für eine Upstream-Registrierung erstellen.
Jede Vorlage enthält ein Repository-Namespace-Präfix, das Amazon ECR verwendet, um neue Repositorys einer bestimmten Vorlage zuzuordnen. Vorlagen spezifizieren die Konfiguration für alle Repository-Einstellungen, einschließlich ressourcenbasierter Zugriffsrichtlinien, Tag-Unveränderlichkeit, Verschlüsselung und Lebenszyklus-Richtlinien.
Weitere Informationen finden Sie unter [Vorlagen für die Erstellung von Repositorys](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) im *Amazon Elastic Container Registry User Guide*.
So erstellen Sie eine Vorlage für die Erstellung eines Repositorys:
1. Öffnen Sie in der Amazon ECR-Konsole das linke Menü unter **Private Registrierung**, erweitern Sie **Funktionen und Einstellungen**. Wählen Sie dann **Vorlagen zur Erstellung von Repositorys** aus.
1. Wählen Sie **Create template (Vorlage erstellen)** aus.
1. Wählen Sie in den **Vorlagendetails** die Option **Pull through cache** aus.
1. Wählen Sie aus, ob diese Vorlage auf ein bestimmtes Präfix oder auf alle Repositorys angewendet werden soll, die keiner anderen Vorlage entsprechen.
**Wenn Sie **Ein bestimmtes Präfix** wählen, geben Sie den Namespace-Präfixwert im Feld Präfix ein.** Sie haben dieses Präfix bei der Erstellung der PTC-Regel angegeben.
1. Wählen Sie **Weiter** aus.
1. **Geben Sie auf der Seite Konfiguration zur Repository-Erstellung hinzufügen** die **Repository-Berechtigungen** ein. Verwenden Sie eine der Beispiel-Richtlinienanweisungen oder geben Sie eine ein, die dem folgenden Beispiel ähnelt:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PTCRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
1. Optional können Sie Repository-Einstellungen wie Lebenszyklusrichtlinien und Tags hinzufügen. Amazon ECR wendet diese Regeln auf alle Container-Images an, die für den Pull-Through-Cache erstellt wurden und das angegebene Präfix verwenden.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Konfiguration und wählen Sie **Weiter**.
#### Den Workflow erstellen
Wenn Sie einen neuen Workflow oder eine neue Workflow-Version erstellen, überprüfen Sie die Registrierungszuordnungen und aktualisieren Sie sie bei Bedarf. Details hierzu finden Sie unter [Erstellen Sie einen privaten Workflow](create-private-workflow.md).
### Registrierungszuordnungen
Sie definieren Registrierungszuordnungen, um Präfixe in Ihrer privaten Amazon ECR-Registrierung und den Namen der Upstream-Registrierung zuzuordnen.
Weitere Informationen zu Amazon ECR-Registrierungszuordnungen finden Sie unter [Erstellen einer Pull-Through-Cache-Regel in](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) Amazon ECR.
Das folgende Beispiel zeigt Registrierungszuordnungen zu Docker Hub, Quay und Amazon ECR Public.
```
{
"registryMappings": [
{
"upstreamRegistryUrl": "registry-1.docker.io",
"ecrRepositoryPrefix": "docker-hub"
},
{
"upstreamRegistryUrl": "quay.io",
"ecrRepositoryPrefix": "quay"
},
{
"upstreamRegistryUrl": "public.ecr.aws",
"ecrRepositoryPrefix": "ecr-public"
}
]
}
```
### Bildzuordnungen
Sie definieren Bildzuordnungen, die zwischen den Bildnamen, wie sie in Ihren privaten Amazon ECR-Workflows definiert sind, und den Bildnamen in der Upstream-Registrierung zugeordnet werden.
Sie können Image-Zuordnungen mit Registern verwenden, die den Pull-Through-Cache unterstützen. Sie können Image-Zuordnungen auch für Upstream-Registrierungen verwenden, die den Pull-Through-Cache HealthOmics nicht unterstützen. Sie müssen die Upstream-Registrierung manuell mit Ihrem privaten Repository synchronisieren.
Weitere Informationen zu Amazon ECR-Image-Zuordnungen finden Sie unter [Erstellen einer Pull-Through-Cache-Regel in](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) Amazon ECR.
Das folgende Beispiel zeigt Zuordnungen von privaten Amazon ECR-Images zu einem öffentlichen Genomik-Image und dem neuesten Ubuntu-Image.
```
{
"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",
}
]
}
```
## Allgemeine Überlegungen zu Amazon ECR-Container-Images
+ Architektur
HealthOmics unterstützt x86\$164-Container. Wenn Ihr lokaler Computer ARM-basiert ist, z. B. Apple Mac, verwenden Sie einen Befehl wie den folgenden, um ein x86\$164-Container-Image zu erstellen:
```
docker build --platform amd64 -t my_tool:latest .
```
+ Entrypoint und Shell
HealthOmics Workflow-Engines fügen Bash-Skripten als Befehlsüberschreibung in die Container-Images ein, die von Workflow-Aufgaben verwendet werden. Daher sollten Container-Images ohne einen angegebenen ENTRYPOINT erstellt werden, sodass eine Bash-Shell die Standardeinstellung ist.
+ Bereitgestellte Pfade
Ein gemeinsam genutztes Dateisystem wird in Container-Aufgaben unter /tmp eingehängt. Alle Daten oder Tools, die an diesem Ort in das Container-Image integriert sind, werden überschrieben.
Die Workflow-Definition ist für Aufgaben über einen schreibgeschützten Mount unter /mnt/workflow verfügbar.
+ Größe des Images
Die maximalen Bildgrößen von Containern finden Sie unter[HealthOmics Workflow-Kontingente mit fester Größe](fixed-quotas.md#fixed-quotas-workflows).
## Umgebungsvariablen für HealthOmics Workflows
HealthOmics stellt Umgebungsvariablen bereit, die Informationen über den Workflow enthalten, der im Container ausgeführt wird. Sie können die Werte dieser Variablen in der Logik Ihrer Workflow-Aufgaben verwenden.
Alle HealthOmics Workflow-Variablen beginnen mit dem `AWS_WORKFLOW_` Präfix. Dieses Präfix ist ein geschütztes Umgebungsvariablenpräfix. Verwenden Sie dieses Präfix nicht für Ihre eigenen Variablen in Workflow-Containern.
HealthOmics stellt die folgenden Workflow-Umgebungsvariablen bereit:
**AWS\$1REGION**
Diese Variable ist die Region, in der der Container ausgeführt wird.
**AWS\$1WORKFLOW\$1AUSFÜHREN**
Diese Variable ist der Name des aktuellen Laufs.
**AWS\$1WORKFLOW\$1RUN\$1ID**
Diese Variable ist die Lauf-ID des aktuellen Laufs.
**AWS\$1WORKFLOW\$1RUN\$1UUID**
Diese Variable ist die Run-UUID des aktuellen Laufs.
**AWS\$1WORKFLOW\$1AUFGABE**
Diese Variable ist der Name der aktuellen Aufgabe.
**AWS\$1WORKFLOW\$1TASK\$1ID**
Diese Variable ist die Aufgaben-ID der aktuellen Aufgabe.
**AWS\$1WORKFLOW\$1TASK\$1UUID**
Diese Variable ist die Task-UUID der aktuellen Aufgabe.
Das folgende Beispiel zeigt typische Werte für jede Umgebungsvariable:
```
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
```
## Verwenden von Java in Amazon ECR-Container-Images
Wenn eine Workflow-Aufgabe eine Java-Anwendung wie GATK verwendet, sollten Sie die folgenden Speicheranforderungen für den Container berücksichtigen:
+ Java-Anwendungen verwenden Stack-Speicher und Heap-Speicher. Standardmäßig ist der maximale Heap-Speicher ein Prozentsatz des gesamten verfügbaren Speichers im Container. Dieser Standard hängt von der jeweiligen JVM-Distribution und der JVM-Version ab. Konsultieren Sie daher die entsprechende Dokumentation für Ihre JVM oder legen Sie das maximale Heap-Speicherlimit explizit mithilfe von Java-Befehlszeilenoptionen (wie `-Xmx`) fest.
+ Legen Sie den maximalen Heap-Speicher nicht auf 100% der Speicherzuweisung des Containers fest, da der JVM-Stack auch Speicher benötigt. Speicher ist auch für den JVM-Garbage-Collector und alle anderen Betriebssystemprozesse erforderlich, die im Container ausgeführt werden.
+ Einige Java-Anwendungen, wie GATK, können native Methodenaufrufe oder andere Optimierungen wie Speicherzuordnungsdateien verwenden. Diese Techniken erfordern Speicherzuweisungen, die „außerhalb des Heaps“ erfolgen und nicht durch den JVM-Parameter für maximale Heap-Anzahl gesteuert werden.
Wenn Sie wissen (oder vermuten), dass Ihre Java-Anwendung Off-Heap-Speicher zuweist, stellen Sie sicher, dass Ihre Aufgabenspeicherzuweisung die Anforderungen an Off-Heap-Speicher berücksichtigt.
Wenn diese Off-Heap-Zuweisungen dazu führen, dass dem Container nicht mehr genügend Speicher zur Verfügung steht, wird normalerweise kein **OutOfMemory** Java-Fehler angezeigt, da die JVM diesen Speicher nicht kontrolliert.
## Hinzufügen von Aufgabeneingaben zu einem Amazon ECR-Container-Image
Fügen Sie alle ausführbaren Dateien, Bibliotheken und Skripten, die für die Ausführung einer Workflow-Aufgabe erforderlich sind, in das Amazon ECR-Image ein, das für die Ausführung der Aufgabe verwendet wird.
Es hat sich bewährt, die Verwendung von Skripten, Binärdateien und Bibliotheken zu vermeiden, die sich außerhalb eines Task-Container-Images befinden. Dies ist besonders wichtig, wenn `nf-core` Workflows verwendet werden, die ein `bin` Verzeichnis als Teil des Workflow-Pakets verwenden. Dieses Verzeichnis wird zwar für die Workflow-Aufgabe verfügbar sein, es ist jedoch als schreibgeschütztes Verzeichnis bereitgestellt. Erforderliche Ressourcen in diesem Verzeichnis sollten in das Task-Image kopiert und zur Laufzeit oder beim Erstellen des für die Aufgabe verwendeten Container-Images verfügbar gemacht werden.
Die maximale Größe des HealthOmics unterstützten Container-Images finden [HealthOmics Workflow-Kontingente mit fester Größe](fixed-quotas.md#fixed-quotas-workflows) Sie unter.
# HealthOmics Workflow-README-Dateien
Sie können eine README.md-Datei hochladen, die Anweisungen, Diagramme und wichtige Informationen für Ihren Arbeitsablauf enthält. Jede Workflow-Version unterstützt eine README-Datei, die Sie jederzeit aktualisieren können.
**Zu den README-Anforderungen gehören:**
+ Die README-Datei muss im Markdown-Format (.md) vorliegen
+ Maximale Dateigröße: 500 KiB
**Topics**
+ [Verwenden Sie eine vorhandene README-Datei](#workflows-add-readme)
+ [Bedingungen für das Rendern](#workflows-rendering-readme)
## Verwenden Sie eine vorhandene README-Datei
READMEs Aus Git-Repositorys exportierte Dateien enthalten relative Links, die normalerweise außerhalb des Repositorys nicht funktionieren. HealthOmics Die Git-Integration konvertiert diese automatisch in absolute Links für das korrekte Rendern in der Konsole, sodass keine manuellen URL-Updates erforderlich sind.
Bei READMEs Importen aus Amazon S3 oder lokalen Laufwerken müssen Bilder und Links entweder öffentlich verwendet werden URLs oder ihre relativen Pfade müssen aktualisiert werden, damit sie korrekt gerendert werden.
**Anmerkung**
Bilder müssen öffentlich gehostet werden, damit sie in der HealthOmics Konsole angezeigt werden können. Bilder, die in GitHub Enterprise Server oder GitLab Self-Managed Repositorys gespeichert sind, können nicht gerendert werden.
## Bedingungen für das Rendern
Die HealthOmics Konsole interpoliert öffentlich zugängliche Bilder und Links mithilfe absoluter Pfade. Um URLs aus privaten Repositorys rendern zu können, muss der Benutzer Zugriff auf das Repository haben. Für GitHub Enterprise Server oder GitLab Self-Managed Repositorys, die benutzerdefinierte Domänen verwenden, können relative Links HealthOmics nicht aufgelöst oder Bilder gerendert werden, die in diesen privaten Repositorys gespeichert sind.
Die folgende Tabelle zeigt die Markdown-Elemente, die von der README-Ansicht der AWS Konsole unterstützt werden.
| Element | AWS Konsole |
| --- | --- |
| Benachrichtigungen | Ja, aber ohne Icons |
| Abzeichen | Ja |
| Grundlegende Textformatierung | Ja |
| [Codeblöcke](https://www.markdownguide.org/basic-syntax/#code-blocks) | Ja, hat aber keine [Syntaxhervorhebungs](https://www.markdownguide.org/extended-syntax/#syntax-highlighting) - und Kopierschaltflächenfunktionen |
| Zusammenklappbare Abschnitte | Ja |
| [Überschriften](https://www.markdownguide.org/basic-syntax/#headings) | Ja |
| [Bildformate](https://www.markdownguide.org/basic-syntax/#images-1) | Ja |
| [Bild (anklickbar)](https://www.markdownguide.org/basic-syntax/#linking-images) | Ja |
| [Zeilenumbrüche](https://www.markdownguide.org/basic-syntax/#line-breaks) | Ja |
| Meerjungfrau-Diagramm | Kann nur das Diagramm öffnen, die Position des Diagramms verschieben und Code kopieren |
| Angebote | Ja |
| [https://www.markdownguide.org/extended-syntax/#subscript](https://www.markdownguide.org/extended-syntax/#subscript) | Ja |
| [Tabellen](https://www.markdownguide.org/extended-syntax/#tables) | Ja, unterstützt aber keine Textausrichtung |
| Textausrichtung | Ja |
### Bild und Link werden verwendet URLs
Strukturieren Sie je nach Quellenanbieter Ihre Basis URLs für Seiten und Bilder in den folgenden Formaten.
+ `{username}`: Der Benutzername, unter dem das Repository gehostet wird.
+ `{repo}`: Der Name des Repositorys.
+ `{ref}`: Die Quellreferenz (Branch, Tag und Commit-ID).
+ `{path}`: Der Dateipfad zur Seite oder zum Bild im Repository.
| Quellanbieter | Seiten-URL | Bild-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 |
GitHubGitLab, und Bitbucket unterstützt sowohl Seiten als auch Bilder URLs , die auf ein öffentliches Repository verweisen. Die folgende Tabelle zeigt, wie die einzelnen Quellenanbieter das Rendern von Bildern und Links URLs für private Repositorys unterstützen.
| Unterstützung für private Repositorys | Quellenanbieter | Seiten-URL | Bild-URL |
| --- | --- | --- | --- |
| GitHub | Nur mit Zugriff auf das Repository | Nein |
| GitLab | Nur mit Zugriff auf das Repository | Nein |
| Bitbucket | Nur mit Zugriff auf das Repository | Nein |
# Sentieon-Lizenzen für private Workflows anfordern
Wenn Ihr privater Workflow die Sentieon-Software verwendet, benötigen Sie eine Senieon-Lizenz. Gehen Sie wie folgt vor, um eine Lizenz für die Sentieon-Software anzufordern und einzurichten:
+ Fordern Sie eine Sentieon-Lizenz an
+ Senden Sie eine E-Mail an die Sentieon-Supportgruppe (support@sentieon.com), um eine Softwarelizenz anzufordern.
+ Geben Sie in der AWS E-Mail Ihre Canonical Benutzer-ID an.
+ [Finden Sie Ihre AWS Canonical-Benutzer-ID, indem Sie diesen Anweisungen folgen.](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId)
+ Aktualisieren Sie Ihre HealthOmics Servicerolle, um ihr Zugriff auf den Sentieon-Lizenzserver-Proxy und den Sentieon Omics Bucket in Ihrer Region zu gewähren. Das folgende Beispiel gewährt Zugriff auf. `us-east-1` Falls erforderlich, ersetzen Sie diesen Text durch Ihre Region.
------
#### [ 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/*"
]
}
]
}
```
------
+ Generieren Sie eine AWS Support-Anfrage, um Zugriff auf den Sentieon-Lizenzserver-Proxy zu erhalten.
+ [Um einen Support-Fall zu erstellen, navigieren Sie zu support.console.aws.amazon.com.](https://support.console.aws.amazon.com)
+ Geben Sie im Support-Fall Ihre Region und Ihre Region an AWS-Konto . Ihr Konto wurde der Zulassungsliste für den Lizenzserver-Proxy hinzugefügt.
+ Erstellen Sie Ihren privaten Workflow mithilfe des Sentieon-Containers und des Sentieon-Lizenzskripts.
+ Weitere Anweisungen zur Verwendung von Sentieon-Tools in privaten Workflows finden Sie unter [Sentieon-Amazon-Omics](https://github.com/Sentieon/sentieon-amazon-omics) unter. GitHub
+ Die Sentieon-Softwareversion 202112.07 und höher unterstützen den Lizenzserver-Proxy. HealthOmics Um Sentieon-Softwareversionen vor 202112.07 zu verwenden, wenden Sie sich an den Sentieon-Support.
# Der Arbeitsablauf blinkt ein HealthOmics
Nachdem Sie einen Workflow erstellt haben, empfehlen wir, dass Sie einen Linter für den Workflow ausführen, bevor Sie mit der ersten Ausführung beginnen. Der Linter erkennt Fehler, die dazu führen können, dass der Lauf fehlschlägt.
Bei WDL HealthOmics wird automatisch ein Linter ausgeführt, wenn Sie den Workflow erstellen. Die Linterausgabe ist im `statusMessage` Feld der Antwort verfügbar. **get-workflow** Verwenden Sie den folgenden CLI-Befehl, um die Statusausgabe abzurufen (verwenden Sie die Workflow-ID des WDL-Workflows, den Sie erstellt haben):
```
aws omics get-workflow
—id 123456
—query 'statusMessage'
```
HealthOmics stellt Links bereit, die Sie auf der Workflow-Definition ausführen können, bevor Sie den Workflow erstellen. Führen Sie diese Linter auf vorhandenen Pipelines aus, zu denen Sie migrieren. HealthOmics
+ **WDL**— Ein öffentliches Amazon ECR-Image zum Ausführen eines [WDL-Linters](https://gallery.ecr.aws/aws-genomics/healthomics-linter).
+ **Nextflow**— Ein öffentliches Amazon ECR-Image zur Ausführung von [Linter-Regeln für]( https://gallery.ecr.aws/aws-genomics/linter-rules-for-nextflow) Nextflow. Sie können auf den Quellcode für diesen Linter von zugreifen. [GitHub](https://github.com/awslabs/linter-rules-for-nextflow)
+ **CWL**— nicht verfügbar
# HealthOmics Workflow-Operationen
Um einen privaten Workflow zu erstellen, benötigen Sie:
+ **Workflow definition file:**Eine inWDL, Nextflow oder geschriebene Workflow-DefinitionsdateiCWL. Die Workflow-Definition spezifiziert die Eingaben und Ausgaben für Läufe, die den Workflow verwenden. Sie enthält auch Spezifikationen für die Ausführungen und Ausführungsaufgaben für Ihren Workflow, einschließlich der Rechen- und Speicheranforderungen. Die Workflow-Definitionsdatei muss `.zip` das Format haben. Weitere Informationen finden Sie unter [Workflow-Definitionsdateien](workflow-definition-files.md) in HealthOmics.
+ Sie können [Amazon Q CLI](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) verwenden, um Ihre Workflow-Definitionsdateien in WDL, Nextflow und CWL zu erstellen und zu validieren. Weitere Informationen finden Sie unter [Beispielaufforderungen für Amazon Q CLI](getting-started.md#omics-q-prompts) und im [HealthOmics Agentic Generative AI-Tutorial](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) unter. GitHub
+ **(Optional) Parameter template file:**Eine Parameter-Vorlagendatei, die in geschrieben wurde. JSON Erstellen Sie die Datei, um die Ausführungsparameter zu definieren, oder HealthOmics generiert die Parametervorlage für Sie. Weitere Informationen finden Sie unter [Parametervorlagendateien für HealthOmics Workflows](parameter-templates.md).
+ **Amazon ECR container images:**Erstellen Sie private Amazon ECR-Repositorys für jeden Container, der im Workflow verwendet wird. Erstellen Sie Container-Images für den Workflow und speichern Sie sie in einem privaten Repository, oder synchronisieren Sie den Inhalt einer unterstützten Upstream-Registrierung mit Ihrem privaten ECR-Repository.
+ **(Optional) Sentieon licenses:**Fordern Sie eine Sentieon Lizenz an, um die Sentieon Software in privaten Workflows zu verwenden.
Für Workflow-Definitionsdateien, die größer als 4 MiB (gezippt) sind, wählen Sie bei der Workflow-Erstellung eine der folgenden Optionen:
+ Laden Sie in einen Amazon Simple Storage Service-Ordner hoch und geben Sie den Speicherort an.
+ Laden Sie in ein externes Repository hoch (maximale Größe 1 GiB) und geben Sie die Repository-Details an.
Nachdem Sie einen Workflow erstellt haben, können Sie die folgenden Workflow-Informationen mit dem `UpdateWorkflow` Vorgang aktualisieren:
+ Name
+ Description
+ Standard-Speichertyp
+ Standardspeicherkapazität (mit Workflow-ID)
+ README.md-Datei
Um andere Informationen im Workflow zu ändern, erstellen Sie einen neuen Workflow oder eine neue Workflow-Version.
Verwenden Sie die Workflow-Versionierung, um Ihre Workflows zu organisieren und zu strukturieren. Versionen helfen Ihnen auch dabei, die Einführung iterativer Workflow-Updates zu verwalten. Weitere Informationen zu Versionen erhalten Sie unter [Workflow-Version erstellen](workflows-version-create.md).
**Topics**
+ [Erstellen Sie einen privaten Workflow](create-private-workflow.md)
+ [Einen privaten Workflow aktualisieren](update-private-workflow.md)
+ [Löschen Sie einen privaten Workflow](delete-private-workflow.md)
+ [Überprüfen Sie den Workflow-Status](using-get-workflow.md)
+ [Referenzieren von Genomdateien aus einer Workflow-Definition](create-ref-files.md)
# Erstellen Sie einen privaten Workflow
Erstellen Sie einen Workflow mit der HealthOmics Konsole, AWS CLI-Befehlen oder einem der AWS SDKs.
**Anmerkung**
Nehmen Sie keine persönlich identifizierbaren Informationen (PII) in Workflow-Namen auf. Diese Namen sind in CloudWatch Protokollen sichtbar.
Wenn Sie einen Workflow erstellen, HealthOmics weist er dem Workflow einen Universally Unique Identifier (UUID) zu. Die Workflow-UUID ist eine GUID (Globally Unique Identifier), die für alle Workflows und Workflow-Versionen eindeutig ist. Aus Gründen der Datenherkunft empfehlen wir, die Workflow-UUID zu verwenden, um Workflows eindeutig zu identifizieren.
Wenn Ihre Workflow-Aufgaben externe Tools (ausführbare Dateien, Bibliotheken oder Skripts) verwenden, bauen Sie diese Tools in ein Container-Image ein. Sie haben die folgenden Optionen für das Hosten des Container-Images:
+ Hosten Sie das Container-Image in der privaten ECR-Registrierung. Voraussetzungen für diese Option:
+ Erstellen Sie ein privates ECR-Repository oder wählen Sie ein vorhandenes Repository aus.
+ Konfigurieren Sie die ECR-Ressourcenrichtlinie wie unter beschrieben. [Amazon-ECR-Berechtigungen](permissions-ecr.md)
+ Laden Sie Ihr Container-Image in das private Repository hoch.
+ Synchronisieren Sie das Container-Image mit dem Inhalt einer unterstützten Registrierung eines Drittanbieters. Voraussetzungen für diese Option:
+ Konfigurieren Sie in der privaten ECR-Registrierung eine Pull-Through-Cache-Regel für jede Upstream-Registrierung. Weitere Informationen finden Sie unter [Bildzuordnungen](workflows-ecr.md#ecr-pull-through-mapping-format).
+ Konfigurieren Sie die ECR-Ressourcenrichtlinie wie unter beschrieben. [Amazon-ECR-Berechtigungen](permissions-ecr.md)
+ Erstellen Sie Vorlagen für die Repository-Erstellung. Die Vorlage definiert Einstellungen für den Zeitpunkt, zu dem Amazon ECR das private Repository für eine Upstream-Registrierung erstellt.
+ Erstellen Sie Präfixzuordnungen, um Container-Image-Referenzen in der Workflow-Definition den ECR-Cache-Namespaces neu zuzuordnen.
Wenn Sie einen Workflow erstellen, geben Sie eine Workflow-Definition an, die Informationen über den Workflow, die Ausführungen und die Aufgaben enthält. HealthOmics kann die Workflow-Definition als lokal oder in einem Amazon S3 S3-Bucket gespeichertes ZIP-Archiv oder aus einem unterstützten Git-basierten Repository abrufen.
**Topics**
+ [Einen Workflow mithilfe der Konsole erstellen](#console-create-workflows)
+ [Einen Workflow mit der CLI erstellen](#api-create-workflows)
+ [Einen Workflow mithilfe eines SDK erstellen](#sdk-create-workflows)
## Einen Workflow mithilfe der Konsole erstellen
**Schritte zum Erstellen eines Workflows**
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (±1). Wählen Sie **Private Workflows** aus.
1. Wählen Sie auf der Seite **Private Workflows** die Option **Workflow erstellen** aus.
1. Geben Sie auf der Seite **Workflow definieren** die folgenden Informationen ein:
1. **Workflow-Name**: Ein eindeutiger Name für diesen Workflow. Wir empfehlen, Workflow-Namen festzulegen, um Ihre Läufe in der AWS HealthOmics Konsole und in den CloudWatch Protokollen zu organisieren.
1. **Beschreibung** (optional): Eine Beschreibung dieses Workflows.
1. Geben Sie im Bereich **Workflow-Definition** die folgenden Informationen ein:
1. **Workflow-Sprache** (optional): Wählen Sie die Spezifikationssprache des Workflows aus. Andernfalls HealthOmics bestimmt die Sprache anhand der Workflow-Definition.
1. Wählen Sie **unter Workflow-Definitionsquelle**, ob Sie den Definitionsordner aus einem Git-basierten Repository, einem Amazon S3 S3-Speicherort oder von einem lokalen Laufwerk importieren möchten.
1. Für den **Import aus einem Repository-Service**:
**Anmerkung**
HealthOmics unterstützt öffentliche und private Repositorys fürGitHub,GitLab,, BitbucketGitHub self-managed,GitLab self-managed.
1. Wählen Sie eine **Verbindung**, um Ihre AWS Ressourcen mit dem externen Repository zu verbinden. Informationen zum Herstellen einer Verbindung finden Sie unter[Connect mit externen Code-Repositorys her](setting-up-new.md#setting-up-omics-repository).
**Anmerkung**
Kunden in der TLV Region müssen eine Verbindung in der Region IAD (us-east-1) herstellen, um einen Workflow zu erstellen.
1. Geben Sie unter **Vollständige Repository-ID** Ihre Repository-ID als Benutzername/Repository-Name ein. Stellen Sie sicher, dass Sie Zugriff auf die Dateien in diesem Repository haben.
1. Geben Sie im Feld **Quellverweis** (optional) eine Repository-Quellenreferenz ein (Branch-, Tag- oder Commit-ID). HealthOmics verwendet den Standardzweig, wenn kein Quellverweis angegeben ist.
1. Geben Sie im Feld **Dateimuster ausschließen** die Dateimuster ein, um bestimmte Ordner, Dateien oder Erweiterungen auszuschließen. Dies hilft bei der Verwaltung der Datengröße beim Import von Repository-Dateien. Es gibt maximal 50 Muster, und die Muster müssen der [Glob-Pattern-Syntax](https://fossil-scm.org/home/doc/tip/www/globs.md) folgen. Beispiel:
1. `tests/`
1. `*.jpeg`
1. `large_data.zip`
1. Für **Select Definition Folder aus S3**:
1. Geben Sie den Amazon S3 S3-Speicherort ein, der den komprimierten Workflow-Definitionsordner enthält. Der Amazon S3 S3-Bucket muss sich in derselben Region wie der Workflow befinden.
1. Wenn Ihr Konto nicht Eigentümer des Amazon S3 S3-Buckets ist, geben Sie die Konto-ID des Bucket-Besitzers in die AWS Konto-ID des **S3-Bucket-Besitzers ein**. Diese Informationen sind erforderlich, um die Inhaberschaft des Buckets verifizieren zu HealthOmics können.
1. Für **Wählen Sie den Definitionsordner aus einer lokalen Quelle** aus:
1. Geben Sie den Speicherort des komprimierten Workflow-Definitionsordners auf dem lokalen Laufwerk ein.
1. **Haupt-Workflow-Definitionsdateipfad** (optional): Geben Sie den Dateipfad vom komprimierten Workflow-Definitionsordner oder Repository zur `main` Datei ein. Dieser Parameter ist nicht erforderlich, wenn der Workflow-Definitionsordner nur eine Datei enthält oder wenn die Hauptdatei den Namen „main“ hat.
1. Wählen Sie im Bereich **README-Datei** (optional) die **Quelle der README-Datei** aus und geben Sie die folgenden Informationen ein:
+ Geben **Sie für Import aus einem Repository-Service** im Feld **README-Dateipfad den Pfad** zur README-Datei innerhalb des Repositorys ein.
+ Geben **Sie unter Datei aus S3 auswählen** in der **README-Datei in S3** den Amazon S3 S3-URI für die README-Datei ein.
+ Für **Datei aus einer lokalen Quelle auswählen**: Wählen Sie in **README — optional** die Option **Datei auswählen**, um die hochzuladende Markdown-Datei (.md) auszuwählen.
1. Geben Sie im Bereich „**Konfiguration des Standardlaufspeichers**“ den Standardspeichertyp und die Kapazität für Läufe an, die diesen Workflow verwenden:
1. **Speichertyp ausführen**: Wählen Sie aus, ob statischer oder dynamischer Speicher als Standard für den temporären Laufspeicher verwendet werden soll. Die Standardeinstellung ist statischer Speicher.
1. **Laufspeicherkapazität** (optional): Für den statischen Laufspeichertyp können Sie die Standardmenge an Laufspeicher eingeben, die für diesen Workflow erforderlich ist. Der Standardwert für diesen Parameter ist 1200 GiB. Sie können diese Standardwerte überschreiben, wenn Sie einen Lauf starten.
1. **Tags** (optional): Sie können diesem Workflow bis zu 50 Tags zuordnen.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie auf der Seite **Workflow-Parameter hinzufügen** (optional) die **Parameterquelle** aus:
1. Bei **Aus Workflow-Definitionsdatei analysieren**: HealthOmics Analysiert automatisch die Workflow-Parameter aus der Workflow-Definitionsdatei.
1. Verwenden **Sie für Parametervorlage aus dem Git-Repository bereitstellen** den Pfad zur Parametervorlagendatei aus Ihrem Repository.
1. Laden **Sie für „JSON-Datei aus lokaler Quelle auswählen**“ eine JSON Datei aus einer lokalen Quelle hoch, die die Parameter angibt.
1. **Geben Sie für Workflow-Parameter** manuell eingeben die Parameternamen und Beschreibungen manuell ein.
1. Im Bereich **Parametervorschau** können Sie die Parameter für diese Workflow-Version überprüfen oder ändern. Wenn Sie die JSON Datei wiederherstellen, gehen alle lokalen Änderungen verloren, die Sie vorgenommen haben.
1. Wählen Sie **Weiter** aus.
1. Auf der Seite zur **Neuzuweisung von Container-URI** können Sie im Bereich **Zuordnungsregeln Regeln** für die URI-Zuordnung für Ihren Workflow definieren.
Wählen Sie für **Quelle der Zuordnungsdatei** eine der folgenden Optionen aus:
+ **Keine** — Keine Zuordnungsregeln erforderlich.
+ **JSON-Datei aus S3 auswählen** — Geben Sie den S3-Speicherort für die Zuordnungsdatei an.
+ **JSON-Datei aus einer lokalen Quelle auswählen** — Geben Sie den Speicherort der Mapping-Datei auf Ihrem lokalen Gerät an.
+ **Zuordnungen manuell eingeben** **— Geben Sie die Registry- und Image-Zuordnungen im Bereich „Zuordnungen“ ein.**
1. In der Konsole **wird** der Bereich „Zuordnungen“ angezeigt. Wenn Sie eine Mapping-Quelldatei ausgewählt haben, zeigt die Konsole die Werte aus der Datei an.
1. In **Registrierungszuordnungen** können Sie die Zuordnungen bearbeiten oder Zuordnungen hinzufügen (maximal 20 Registrierungszuordnungen).
Jede Registrierungszuweisung enthält die folgenden Felder:
+ **Upstream-Registrierungs-URL** — Die URI der Upstream-Registrierung.
+ **ECR-Repository-Präfix** — Das Repository-Präfix, das im privaten Amazon ECR-Repository verwendet werden soll.
+ (Optional) **Upstream-Repository-Präfix** — Das Präfix des Repositorys in der Upstream-Registrierung.
+ (Optional) **ECR-Konto-ID** — Konto-ID des Kontos, dem das Upstream-Container-Image gehört.
1. In **Image-Zuordnungen** können Sie die Image-Zuordnungen bearbeiten oder Zuordnungen hinzufügen (maximal 100 Image-Zuordnungen).
Jede Image-Zuordnung enthält die folgenden Felder:
+ **Quellbild** — Gibt den URI des Quellbilds in der Upstream-Registrierung an.
+ **Zielbild** — Gibt den URI des entsprechenden Images in der privaten Amazon ECR-Registrierung an.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Workflow-Konfiguration und wählen Sie dann **Workflow erstellen**.
## Einen Workflow mit der CLI erstellen
Wenn sich Ihre Workflow-Dateien und die Parameter-Vorlagendatei auf Ihrem lokalen Computer befinden, können Sie mit dem folgenden CLI-Befehl einen Workflow erstellen.
```
aws omics create-workflow \
--name "my_workflow" \
--definition-zip fileb://my-definition.zip \
--parameter-template file://my-parameter-template.json
```
Der `create-workflow` Vorgang gibt die folgende Antwort zurück:
```
{
"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"
}
```
### Optionale Parameter, die beim Erstellen eines Workflows verwendet werden können
Sie können jeden der optionalen Parameter angeben, wenn Sie einen Workflow erstellen. Einzelheiten zur Syntax finden Sie [CreateWorkflow](https://docs.aws.amazon.com/omics/latest/api/API_CreateWorkflow.html)in der HealthOmics AWS-API-Referenz.
**Topics**
+ [Geben Sie den Amazon S3 S3-Speicherort der Workflow-Definition an](#create-defn-uri-parameter)
+ [Verwenden Sie die Workflow-Definition aus einem Git-basierten Repository](#create-defn-uri-git)
+ [Geben Sie eine Readme-Datei an](#specify-readme-file)
+ [**main**Geben Sie die Definitionsdatei an](#create-main-parameter)
+ [Geben Sie den Speichertyp für die Ausführung an](#create-run-storage-parameter)
+ [Geben Sie die GPU-Konfiguration an](#create-accelerator-parameter)
+ [Konfigurieren Sie die Parameter für die Zuordnung des Pull-Through-C](#create-prefix-mapping-parameters)
#### Geben Sie den Amazon S3 S3-Speicherort der Workflow-Definition an
Wenn sich Ihre Workflow-Definitionsdatei in einem Amazon S3 S3-Ordner befindet, geben Sie den Speicherort mithilfe des `definition-uri` Parameters an, wie im folgenden Beispiel gezeigt. Wenn Ihr Konto nicht Eigentümer des Amazon S3 S3-Buckets ist, geben Sie die AWS-Konto ID des Besitzers an.
```
aws omics create-workflow \
--name Test \
--definition-uri s3://omics-bucket/workflow-definition/ \
--owner-id 123456789012
...
```
#### Verwenden Sie die Workflow-Definition aus einem Git-basierten Repository
Um die Workflow-Definition aus einem unterstützten Git-basierten Repository zu verwenden, verwenden Sie den `definition-repository` Parameter in Ihrer Anfrage. Geben Sie keinen anderen `definition` Parameter an, da eine Anfrage fehlschlägt, wenn sie mehr als eine Eingabequelle enthält.
Der `definition-respository` Parameter enthält die folgenden Felder:
+ **connectionArn**— ARN der Code-Verbindung, die Ihre AWS-Ressourcen mit dem externen Repository verbindet.
+ **fullRepositoryId**— Geben Sie die Repository-ID als ein`owner-name/repo-name`. Stellen Sie sicher, dass Sie Zugriff auf die Dateien in diesem Repository haben.
+ **sourceReference**(Optional) — Geben Sie einen Repository-Referenztyp (BRANCH, TAG oder COMMIT) und einen Wert ein.
HealthOmics verwendet den neuesten Commit für den Standard-Branch, wenn Sie keinen Quellverweis angeben.
+ **excludeFilePatterns**(Optional) — Geben Sie die Dateimuster ein, um bestimmte Ordner, Dateien oder Erweiterungen auszuschließen. Dies hilft bei der Verwaltung der Datengröße beim Import von Repository-Dateien. Geben Sie maximal 50 Muster an. Die Muster müssen der [Glob-Pattern-Syntax](https://fossil-scm.org/home/doc/tip/www/globs.md) folgen. Beispiel:
+ `tests/`
+ `*.jpeg`
+ `large_data.zip`
Wenn Sie die Workflow-Definition aus einem Git-basierten Repository angeben, verwenden Sie diese Option, `parameter-template-path` um die Parameter-Vorlagendatei anzugeben. Wenn Sie diesen Parameter nicht angeben, HealthOmics wird der Workflow ohne Parametervorlage erstellt.
Das folgende Beispiel zeigt die Parameter, die sich auf Inhalte aus einem Git-basierten privaten Repository beziehen:
```
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" \
```
Weitere Beispiele finden Sie im Blogbeitrag [So erstellen Sie HealthOmics AWS-Workflows aus Inhalten in Git](https://repost.aws/articles/ARCEN7AjhaRSmteczRoc_QsA/how-to-create-an-aws-healthomics-workflows-from-content-in-git).
#### Geben Sie eine Readme-Datei an
Sie können den Speicherort der README-Datei mit einem der folgenden Parameter angeben:
+ **readme-markdown**— Zeichenketteneingabe oder eine Datei auf Ihrem lokalen Computer.
+ **readme-uri**— Die URI einer auf S3 gespeicherten Datei.
+ **readme-path **— Der Pfad zur README-Datei im Repository.
**Verwenden Sie den Readme-Pfad nur in Verbindung mit definition-respository.** Wenn Sie keinen README-Parameter angeben, wird die README.md-Datei auf Stammebene in das Repository HealthOmics importiert (falls vorhanden).
Die folgenden Beispiele zeigen, wie der Speicherort der README-Datei mithilfe des Readme-Pfads und der Readme-URI angegeben wird.
```
# 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"
```
Weitere Informationen finden Sie unter [HealthOmics Workflow-README-Dateien](workflows-readme.md).
#### **main**Geben Sie die Definitionsdatei an
Wenn Sie mehrere Workflow-Definitionsdateien einbeziehen, verwenden Sie den `main` Parameter, um die Hauptdefinitionsdatei für Ihren Workflow anzugeben.
```
aws omics create-workflow \
--name Test \
--main multi_workflow/workflow2.wdl \
...
```
#### Geben Sie den Speichertyp für die Ausführung an
Sie können den Standard-Laufspeichertyp (DYNAMIC oder STATIC) und die Run-Speicherkapazität (erforderlich für statischen Speicher) angeben. Weitere Hinweise zu Laufspeichertypen finden Sie unter[Speichertypen in HealthOmics Workflows ausführen](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 \
```
#### Geben Sie die GPU-Konfiguration an
Verwenden Sie den Accelerators-Parameter, um einen Workflow zu erstellen, der auf einer Accelerated-Compute-Instance ausgeführt wird. Das folgende Beispiel zeigt, wie der Parameter verwendet wird. `accelerators` Sie geben die GPU-Konfiguration in der Workflow-Definition an. Siehe [Instanzen für beschleunigte Datenverarbeitung](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
```
#### Konfigurieren Sie die Parameter für die Zuordnung des Pull-Through-C
Wenn Sie die Amazon ECR Pull-Through-Cache-Zuordnungsfunktion verwenden, können Sie die Standardzuordnungen überschreiben. Weitere Informationen zu den Container-Einrichtungsparametern finden Sie unter. [Container-Images für private Workflows](workflows-ecr.md)
Im folgenden Beispiel `mappings.json` enthält die Datei diesen Inhalt:
```
{
"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"
}
]
}
```
Geben Sie die Zuordnungsparameter im Befehl create-workflow an:
```
aws omics create-workflow \
...
--container-registry-map-file file://mappings.json
...
```
Sie können auch den S3-Speicherort der Datei mit den Zuordnungsparametern angeben:
```
aws omics create-workflow \
...
--container-registry-map-uri s3://amzn-s3-demo-bucket1/test.zip
...
```
## Einen Workflow mithilfe eines SDK erstellen
Sie können einen Workflow mit einem der erstellen SDKs. Das folgende Beispiel zeigt, wie ein Workflow mit dem Python-SDK erstellt wird.
```
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={ ... }
)
```
# Einen privaten Workflow aktualisieren
Sie können einen Workflow über die HealthOmics Konsole, AWS CLI-Befehle oder einen der folgenden aktualisieren AWS SDKs.
**Anmerkung**
Nehmen Sie keine persönlich identifizierbaren Informationen (PII) in Workflow-Namen auf. Diese Namen sind in CloudWatch Protokollen sichtbar.
**Topics**
+ [Aktualisierung eines Workflows mithilfe der Konsole](#console-update-workflows)
+ [Aktualisieren eines Workflows mit der CLI](#api-update-workflows)
+ [Aktualisierung eines Workflows mithilfe eines SDK](#sdk-update-workflows)
## Aktualisierung eines Workflows mithilfe der Konsole
**Schritte zum Aktualisieren eines Workflows**
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (←). Wählen Sie **Private Workflows**.
1. Wählen Sie auf der Seite **Private Workflows** den Workflow aus, der aktualisiert werden soll.
1. Auf der **Workflow-Seite**:
+ Wenn der Workflow Versionen hat, stellen Sie sicher, dass Sie die **Standardversion** auswählen.
+ Wählen Sie in der Liste **Aktionen** die **Option Ausgewählte Bearbeitung** aus.
1. Auf der Seite **„Workflow bearbeiten**“ können Sie jeden der folgenden Werte ändern:
+ **Name des Workflows**.
+ **Beschreibung des Workflows**.
+ Der standardmäßige **Run-Speichertyp** für den Workflow.
+ Die standardmäßige **Run-Speicherkapazität** (wenn der Run-Speichertyp statischer Speicher ist). Weitere Informationen zur standardmäßigen Run-Speicherkonfiguration finden Sie unter[Einen Workflow mithilfe der Konsole erstellen](create-private-workflow.md#console-create-workflows).
1. Wählen Sie **Änderungen speichern**, um die Änderungen zu übernehmen.
## Aktualisieren eines Workflows mit der CLI
Wie im folgenden Beispiel gezeigt, können Sie den Namen und die Beschreibung des Workflows aktualisieren. Sie können auch den Standard-Laufspeichertyp (STATIC oder DYNAMIC) und die Run-Speicherkapazität (für den statischen Speichertyp) ändern. Weitere Informationen zu Laufspeichertypen finden Sie unter[Speichertypen in HealthOmics Workflows ausführen](workflows-run-types.md).
```
aws omics update-workflow \
--id 1234567 \
--name my_workflow \
--description "updated workflow" \
--storage-type 'STATIC' \
--storage-capacity 1200
```
Sie erhalten keine Antwort auf die `update-workflow` Anfrage.
## Aktualisierung eines Workflows mithilfe eines SDK
Sie können einen Workflow mit einem der aktualisieren SDKs.
Das folgende Beispiel zeigt, wie ein Workflow mit dem Python-SDK aktualisiert wird.
```
import boto3
omics = boto3.client('omics')
response = omics.update_workflow(
name='my_workflow',
description='updated workflow'
)
```
# Löschen Sie einen privaten Workflow
Wenn Sie einen Workflow nicht mehr benötigen, können Sie ihn mit der HealthOmics Konsole, AWS CLI-Befehlen oder einem der folgenden Befehle löschen AWS SDKs. Sie können einen Workflow löschen, der die folgenden Kriterien erfüllt:
+ Sein Status ist AKTIV oder FEHLGESCHLAGEN.
+ Es hat keine aktiven Aktien.
+ Sie haben alle Workflow-Versionen gelöscht.
Das Löschen eines Workflows hat keine Auswirkungen auf laufende Läufe, die den Workflow verwenden.
**Topics**
+ [Löschen eines Workflows mithilfe der Konsole](#console-delete-workflows)
+ [Löschen eines Workflows mit der CLI](#api-delete-workflows)
+ [Löschen eines Workflows mithilfe eines SDK](#sdk-delete-workflows)
## Löschen eines Workflows mithilfe der Konsole
**Um einen Workflow zu löschen**
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (←). Wählen Sie **Private Workflows** aus.
1. Wählen Sie auf der Seite **Private Workflows** den zu löschenden Workflow aus.
1. Wählen Sie auf der **Workflow-Seite** in der Liste **Aktionen** die **Option Ausgewählte löschen** aus.
1. Geben **Sie im Workflow-Modal „Löschen**“ „Bestätigen“ ein, um den Löschvorgang zu bestätigen.
1. Wählen Sie **Löschen** aus.
## Löschen eines Workflows mit der CLI
Das folgende Beispiel zeigt, wie Sie den AWS CLI Befehl verwenden können, um einen Workflow zu löschen. Um das Beispiel auszuführen, ersetzen Sie den `workflow id` durch die ID des Workflows, den Sie löschen möchten.
```
aws omics delete-workflow
--id workflow id
```
HealthOmics sendet keine Antwort auf die `delete-workflow` Anfrage.
## Löschen eines Workflows mithilfe eines SDK
Sie können einen Workflow mit einem der löschen SDKs.
Das folgende Beispiel zeigt, wie ein Workflow mit dem Python-SDK gelöscht wird.
```
import boto3
omics = boto3.client('omics')
response = omics.delete_workflow(
id='1234567'
)
```
# Überprüfen Sie den Workflow-Status
Nachdem Sie Ihren Workflow erstellt haben, können Sie den Status überprüfen und weitere Details des Workflows mithilfe von **get-workflow** anzeigen, wie in der Abbildung gezeigt.
```
aws omics get-workflow --id 1234567
```
Die Antwort enthält Workflow-Details, einschließlich des Status, wie in der Abbildung gezeigt.
```
{
"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"
}
```
Sie können mit diesem Workflow einen Lauf starten, nachdem der Status zu gewechselt ist`ACTIVE`.
# Referenzieren von Genomdateien aus einer Workflow-Definition
Auf ein HealthOmics Referenzspeicherobjekt kann mit einem URI wie dem folgenden verwiesen werden. Verwenden Sie Ihre eigenen`account ID`,`reference store ID`, und `reference ID` wo angegeben.
```
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id
```
Für einige Workflows sind `SOURCE` sowohl die als auch die `INDEX` Dateien für das Referenzgenom erforderlich. Der vorherige URI ist die Standardkurzform und wird standardmäßig auf die SOURCE-Datei gesetzt. Um eine der beiden Dateien anzugeben, können Sie die lange URI-Form wie folgt verwenden.
```
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
```
Die Verwendung eines Sequence-Readesets hätte ein ähnliches Muster, wie hier gezeigt.
```
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
```
Einige Lesesätze, z. B. solche, die auf FASTQ basieren, können gepaarte Lesesätze enthalten. In den folgenden Beispielen werden sie als SOURCE1 und SOURCE2 bezeichnet. Formate wie BAM und CRAM enthalten nur eine SOURCE1 Datei. Einige Lesesätze enthalten INDEX-Dateien wie `bai` ODER-Dateien. `crai` Der vorhergehende URI ist die Standardkurzform und verwendet standardmäßig die SOURCE1 Datei. Um die genaue Datei oder den Index anzugeben, können Sie die lange URI-Form wie folgt verwenden.
```
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
```
Im Folgenden finden Sie ein Beispiel für eine JSON-Eingabedatei, die zwei Omics Storage URIs verwendet.
```
{
"input_fasta": "omics://123456789012.storage.us-west-2.amazonaws.com//reference/",
"input_cram": "omics://123456789012.storage.us-west-2.amazonaws.com//readSet/"
}
```
Verweisen Sie auf die JSON-Eingabedatei in, AWS CLI indem Sie sie `--inputs file://` zu Ihrer **Start-Run-Anforderung** hinzufügen.