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
```
------
# Fichiers modèles de paramètres pour les HealthOmics flux de travail
Les modèles de paramètres définissent les paramètres d'entrée d'un flux de travail. Vous pouvez définir des paramètres d'entrée pour rendre votre flux de travail plus flexible et plus polyvalent. Par exemple, vous pouvez définir un paramètre pour l'emplacement des fichiers génomiques de référence sur Amazon S3. Les modèles de paramètres peuvent être fournis par le biais d'un service de dépôt basé sur Git ou de votre disque local. Les utilisateurs peuvent ensuite exécuter le flux de travail à l'aide de différents ensembles de données.
Vous pouvez créer le modèle de paramètres pour votre flux de travail ou HealthOmics générer le modèle de paramètres pour vous.
Le modèle de paramètres est un fichier JSON. Dans le fichier, chaque paramètre d'entrée est un objet nommé qui doit correspondre au nom de l'entrée du flux de travail. Lorsque vous lancez une exécution, si vous ne fournissez pas de valeurs pour tous les paramètres requis, l'exécution échoue.
L'objet du paramètre d'entrée inclut les attributs suivants :
+ **description**— Cet attribut obligatoire est une chaîne que la console affiche sur la page **Démarrer l'exécution**. Cette description est également conservée sous forme de métadonnées d'exécution.
+ **optional**— Cet attribut facultatif indique si le paramètre d'entrée est facultatif. Si vous ne spécifiez pas le **optional** champ, le paramètre d'entrée est obligatoire.
L'exemple de modèle de paramètres suivant montre comment spécifier les paramètres d'entrée.
```
{
"myRequiredParameter1": {
"description": "this parameter is required",
},
"myRequiredParameter2": {
"description": "this parameter is also required",
"optional": false
},
"myOptionalParameter": {
"description": "this parameter is optional",
"optional": true
}
}
```
## Génération de modèles de paramètres
HealthOmics génère le modèle de paramètres en analysant la définition du flux de travail pour détecter les paramètres d'entrée. Si vous fournissez un fichier modèle de paramètres pour un flux de travail, les paramètres de votre fichier remplacent les paramètres détectés dans la définition du flux de travail.
Il existe de légères différences entre la logique d'analyse des moteurs CWL, WDL et Nextflow, comme décrit dans les sections suivantes.
**Topics**
+ [Détection de paramètres pour CWL](#parameter-parsing-cwl)
+ [Détection de paramètres pour WDL](#parameter-parsing-wdl)
+ [Détection de paramètres pour Nextflow](#parameter-parsing-nextflow)
### Détection de paramètres pour CWL
Dans le moteur de flux de travail CWL, la logique d'analyse repose sur les hypothèses suivantes :
+ Tous les types pris en charge par des valeurs nulles sont marqués comme paramètres d'entrée facultatifs.
+ Tous les types pris en charge non nuls sont marqués comme paramètres d'entrée obligatoires.
+ Tous les paramètres avec des valeurs par défaut sont marqués comme paramètres d'entrée facultatifs.
+ Les descriptions sont extraites de la `label` section de la définition du `main` flux de travail. Si `label` ce n'est pas spécifié, la description sera vide (chaîne vide).
Les tableaux suivants présentent des exemples d'interpolation CWL. Pour chaque exemple, le nom du paramètre est`x`. Si le paramètre est obligatoire, vous devez fournir une valeur pour le paramètre. Si le paramètre est facultatif, il n'est pas nécessaire de fournir de valeur.
Ce tableau présente des exemples d'interpolation CWL pour les types primitifs.
| Entrée | Exemple d'entrée/sortie | Obligatoire |
| --- | --- | --- |
| x:
type: int
| 1 ou 2 ou... | Oui |
| x:
type: int
default: 2
| La valeur par défaut est 2. L'entrée valide est 1 ou 2 ou... | Non |
| x:
type: int?
| L'entrée valide est None ou 1 ou 2 ou... | Non |
| x:
type: int?
default: 2
| La valeur par défaut est 2. L'entrée valide est None ou 1 ou 2 ou... | Non |
Le tableau suivant présente des exemples d'interpolation CWL pour les types complexes. Un type complexe est un ensemble de types primitifs.
| Entrée | Exemple d'entrée/sortie | Obligatoire |
| --- | --- | --- |
| x:
type: array
items: int
| [] ou [1,2,3] | Oui |
| x:
type: array?
items: int
| Aucun ou [] ou [1,2,3] | Non |
| x:
type: array
items: int?
| [] ou [Aucun, 3, Aucun] | Oui |
| x:
type: array?
items: int?
| [Aucun] ou Aucun ou [1,2,3] ou [Aucun, 3] mais pas [] | Non |
### Détection de paramètres pour WDL
Dans le moteur de flux de travail WDL, la logique d'analyse repose sur les hypothèses suivantes :
+ Tous les types pris en charge par des valeurs nulles sont marqués comme paramètres d'entrée facultatifs.
+ Pour les types pris en charge non nullables :
+ Toute variable d'entrée à laquelle sont assignés des littéraux ou des expressions est marquée comme paramètre facultatif. Par exemple :
```
Int x = 2
Float f0 = 1.0 + f1
```
+ Si aucune valeur ou expression n'a été affectée aux paramètres d'entrée, ils seront marqués comme paramètres obligatoires.
+ Les descriptions sont extraites de `parameter_meta` la définition du `main` flux de travail. Si `parameter_meta` ce n'est pas spécifié, la description sera vide (chaîne vide). Pour plus d'informations, consultez la spécification WDL pour les [métadonnées des paramètres](https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#metadata-sections).
Les tableaux suivants présentent des exemples d'interpolation WDL. Pour chaque exemple, le nom du paramètre est`x`. Si le paramètre est obligatoire, vous devez fournir une valeur pour le paramètre. Si le paramètre est facultatif, il n'est pas nécessaire de fournir de valeur.
Ce tableau présente des exemples d'interpolation WDL pour les types primitifs.
| Entrée | Exemple d'entrée/sortie | Obligatoire |
| --- | --- | --- |
| Int x | 1 ou 2 ou... | Oui |
| Int x = 2 | 2 | Non |
| Int x = 1\$12 | 3 | Non |
| Int x = y\$1z | y\$1z | Non |
| Int ? x | Aucun, 1 ou 2 ou... | Oui |
| Int ? x = 2 | Aucun ou 2 | Non |
| Int ? x = 1\$12 | Aucun ou 3 | Non |
| Int ? x = y\$1z | Aucun ou y\$1z | Non |
Le tableau suivant présente des exemples d'interpolation WDL pour les types complexes. Un type complexe est un ensemble de types primitifs.
| Entrée | Exemple d'entrée/sortie | Obligatoire |
| --- | --- | --- |
| Tableau [Int] x | [1,2,3] ou [] | Oui |
| Tableau [Int] \$1 x | [1], mais pas [] | Oui |
| Tableau [Int] ? x | Aucun ou [] ou [1,2,3] | Non |
| Tableau [Int ?] x | [] ou [Aucun, 3, Aucun] | Oui |
| Tableau [Int ?] = ? x | [Aucun] ou Aucun ou [1,2,3] ou [Aucun, 3] mais pas [] | Non |
| Exemple de structure \$1String a, Int y\$1 plus loin dans les entrées : Sample MySample | String a = mySample.a
Int y = mySample.y
| Oui |
| Exemple de structure \$1String a, Int y\$1 plus tard dans les entrées : Sample ? Mon échantillon | if (defined(mySample)) {
String a = mySample.a
Int y = mySample.y
} | Non |
### Détection de paramètres pour Nextflow
Pour Nextflow, HealthOmics génère le modèle de paramètres en analysant le `nextflow_schema.json` fichier. Si la définition du flux de travail n'inclut pas de fichier de schéma, HealthOmics analyse le fichier de définition du flux de travail principal.
**Topics**
+ [Analyse du fichier de schéma](#parameter-parsing-nextflow-schema)
+ [Analyse du fichier principal](#parameter-parsing-nextflow-main)
+ [Paramètres imbriqués](#parameter-parsing-nextflow-nested)
+ [Exemples d'interpolation Nextflow](#parameter-parsing-nextflow-examples)
#### Analyse du fichier de schéma
Pour que l'analyse fonctionne correctement, assurez-vous que le fichier de schéma répond aux exigences suivantes :
+ Le fichier de schéma est nommé `nextflow_schema.json` et se trouve dans le même répertoire que le fichier de flux de travail principal.
+ Le fichier de schéma est un fichier JSON valide tel que défini dans l'un des schémas suivants :
+ [schéma json. org/draft/2020-12/schema](https://json-schema.org/draft/2020-12/schema).
+ [schéma json. org/draft-07/schema](https://json-schema.org/draft-07/schema).
HealthOmics analyse le `nextflow_schema.json` fichier pour générer le modèle de paramètres :
+ Extrait tout **properties** ce qui est défini dans le schéma.
+ Comprend la propriété **description** si disponible pour la propriété.
+ Indique si chaque paramètre est facultatif ou obligatoire, en fonction du **required** champ de la propriété.
L'exemple suivant montre un fichier de définition et le fichier de paramètres généré.
```
{
"$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" }
]
}
```
Le modèle de paramètres généré :
```
{
"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
}
}
```
#### Analyse du fichier principal
Si la définition du flux de travail n'inclut aucun `nextflow_schema.json` fichier, HealthOmics analyse le fichier de définition du flux de travail principal.
HealthOmics analyse les `params` expressions présentes dans le fichier de définition du flux de travail principal et dans le `nextflow.config` fichier. Tous ceux `params` dont les valeurs par défaut sont marqués comme facultatifs.
Pour que l'analyse fonctionne correctement, tenez compte des exigences suivantes :
+ HealthOmics analyse uniquement le fichier de définition du flux de travail principal. Pour garantir que tous les paramètres sont capturés, nous vous recommandons de les connecter à tous **params** les sous-modules et aux flux de travail importés.
+ Le fichier de configuration est facultatif. Si vous en définissez un, nommez-le `nextflow.config` et placez-le dans le même répertoire que le fichier de définition du flux de travail principal.
L'exemple suivant montre un fichier de définition et le modèle de paramètres généré.
```
params.input_file = "default.txt"
params.threads = 4
params.memory = "8GB"
workflow {
if (params.version) {
println "Using version: ${params.version}"
}
}
```
Le modèle de paramètres généré :
```
{
"input_file": {
"description": None,
"optional": True
},
"threads": {
"description": None,
"optional": True
},
"memory": {
"description": None,
"optional": True
},
"version": {
"description": None,
"optional": False
}
}
```
Pour les valeurs par défaut définies dans nextflow.config, HealthOmics collecte les `params` assignations et les paramètres déclarés dans le fichier`params {}`, comme indiqué dans l'exemple suivant. Dans les instructions d'affectation, elles `params` doivent apparaître dans la partie gauche de la déclaration.
```
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}"
```
Le modèle de paramètres généré :
```
{
// 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
}
}
```
#### Paramètres imbriqués
Les deux `nextflow_schema.json` et `nextflow.config` autorisent les paramètres imbriqués. Toutefois, le modèle de HealthOmics paramètres ne nécessite que les paramètres de niveau supérieur. Si votre flux de travail utilise un paramètre imbriqué, vous devez fournir un objet JSON en entrée pour ce paramètre.
##### Paramètres imbriqués dans les fichiers de schéma
HealthOmics sauts imbriqués **params** lors de l'analyse d'un fichier. `nextflow_schema.json` Par exemple, si vous définissez le `nextflow_schema.json` fichier suivant :
```
{
"properties": {
"input": {
"properties": {
"input_file": { ... },
"input_num": { ... }
}
},
"input_bool": { ... }
}
}
```
HealthOmics ignore `input_file` et `input_num` lorsqu'il génère le modèle de paramètres :
```
{
"input": {
"description": None,
"optional": True
},
"input_bool": {
"description": None,
"optional": True
}
}
```
Lorsque vous exécutez ce flux de travail, HealthOmics vous vous attendez à un `input.json` fichier similaire au suivant :
```
{
"input": {
"input_file": "s3://bucket/obj",
"input_num": 2
},
"input_bool": false
}
```
##### Paramètres imbriqués dans les fichiers de configuration
HealthOmics ne collecte pas les données imbriquées **params** dans un `nextflow.config` fichier et les ignore lors de l'analyse. Par exemple, si vous définissez le `nextflow.config` fichier suivant :
```
params.alpha = "alpha"
params.nested.beta = "beta"
params {
gamma = "gamma"
group {
delta = "delta"
}
}
```
HealthOmics ignore `params.nested.beta` et `params.group.delta` lorsqu'il génère le modèle de paramètres :
```
{
"alpha": {
"description": None,
"optional": True
},
"gamma": {
"description": None,
"optional": True
}
}
```
#### Exemples d'interpolation Nextflow
Le tableau suivant présente des exemples d'interpolation Nextflow pour les paramètres du fichier principal.
| Paramètres | Obligatoire |
| --- | --- |
| params.input\$1file | Oui |
| params.input\$1file = "s3://bucket/data.json » | Non |
| params.nested.input\$1file | N/A |
| params.nested.input\$1file = "s3://bucket/data.json » | N/A |
Le tableau suivant présente des exemples d'interpolation Nextflow pour les paramètres du fichier. `nextflow.config`
| Paramètres | Obligatoire |
| --- | --- |
| params.input_file = "s3://bucket/data.json"
| Non |
| params {
input_file = "s3://bucket/data.json"
} | Non |
| params {
nested {
input_file = "s3://bucket/data.json"
}
} | N/A |
| input_file = params.input_file
| N/A |
# Images de conteneur pour les flux de travail privés
HealthOmics prend en charge les images de conteneurs hébergées dans les référentiels privés Amazon ECR. Vous pouvez créer des images de conteneur et les télécharger dans le référentiel privé. Vous pouvez également utiliser votre registre privé Amazon ECR comme cache d'extraction pour synchroniser le contenu des registres en amont.
Votre référentiel Amazon ECR doit résider dans la même AWS région que le compte appelant le service. Une autre personne Compte AWS peut être propriétaire de l'image du conteneur, à condition que le référentiel d'images source fournisse les autorisations appropriées. Pour de plus amples informations, veuillez consulter [Politiques relatives à l'accès multicompte à Amazon ECR](permissions-ecr.md#permissions-cross-account).
Nous vous recommandons de définir votre image de conteneur Amazon ECR en URIs tant que paramètre de votre flux de travail afin que l'accès puisse être vérifié avant le début de l'exécution. Cela facilite également l'exécution d'un flux de travail dans une nouvelle région en modifiant le paramètre Région.
**Note**
HealthOmics ne prend pas en charge les conteneurs ARM et ne prend pas en charge l'accès aux référentiels publics.
Pour plus d'informations sur la configuration des autorisations IAM pour accéder HealthOmics à Amazon ECR, consultez. [HealthOmics Autorisations relatives aux ressources](permissions-resource.md)
**Topics**
+ [Synchronisation avec des registres de conteneurs tiers](#ecr-pull-through)
+ [Considérations générales relatives aux images de conteneurs Amazon ECR](#ecr-considerations)
+ [Variables d'environnement pour les HealthOmics flux de travail](#ecr-env-vars)
+ [Utilisation de Java dans les images de conteneurs Amazon ECR](#ecr-java-considerations)
+ [Ajouter des entrées de tâches à une image de conteneur Amazon ECR](#ecr-tasks)
## Synchronisation avec des registres de conteneurs tiers
Vous pouvez utiliser les règles de cache d'extraction d'Amazon ECR pour synchroniser les référentiels d'un registre en amont pris en charge avec vos référentiels privés Amazon ECR. Pour plus d'informations, consultez [Synchroniser un registre en amont](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html) dans le *guide de l'utilisateur Amazon ECR.*
Le cache d'extraction crée automatiquement le référentiel d'images dans votre registre privé lorsque vous créez le cache, et il se synchronise automatiquement avec l'image mise en cache lorsque des modifications sont apportées à l'image en amont.
HealthOmics prend en charge le cache d'extraction pour les registres en amont suivants :
+ Amazon ECR Public
+ Registre d'images de conteneurs Kubernetes
+ Quay
+ Docker Hub
+ Microsoft Azure Container Registry
+ GitHub Registre des conteneurs
+ GitLab Registre des conteneurs
HealthOmics ne prend pas en charge le cache d'extraction pour un référentiel privé Amazon ECR en amont.
Les avantages de l'utilisation du cache d'extraction Amazon ECR sont les suivants :
1. Vous évitez d'avoir à migrer manuellement les images de conteneur vers Amazon ECR ou à synchroniser les mises à jour depuis le référentiel tiers.
1. Les flux de travail accèdent aux images de conteneur synchronisées de votre référentiel privé, ce qui est plus fiable que le téléchargement de contenu depuis un registre public au moment de l'exécution.
1. Comme les caches d'extraction Amazon ECR utilisent une structure d'URI prévisible, le HealthOmics service peut automatiquement mapper l'URI privé Amazon ECR avec l'URI de registre en amont. Vous n'êtes pas obligé de mettre à jour et de remplacer les valeurs d'URI dans la définition du flux de travail.
**Topics**
+ [Configuration du cache d'extraction](#ecr-pull-through-configure)
+ [Mappages de registres](#ecr-pull-through-registry-mapping)
+ [Mappages d'images](#ecr-pull-through-mapping-format)
### Configuration du cache d'extraction
Amazon ECR fournit un registre pour vous Compte AWS dans chaque région. Assurez-vous de créer la configuration Amazon ECR dans la même région que celle où vous prévoyez d'exécuter le flux de travail.
Les sections suivantes décrivent les tâches de configuration du cache d'extraction.
**Topics**
+ [Création d'une règle de cache d'extraction](#create-ecr-ptc)
+ [Autorisations de registre pour le registre en amont](#reg-ecr-ptc)
+ [Modèles de création de référentiels](#repo-create-templates-ptc)
+ [Création du flux de travail](#reg-mapping-ecr-ptc)
#### Création d'une règle de cache d'extraction
Créez une règle de cache d'extraction Amazon ECR pour chaque registre en amont contenant des images que vous souhaitez mettre en cache. Une règle spécifie un mappage entre un registre en amont et le référentiel privé Amazon ECR.
Pour un registre en amont qui nécessite une authentification, vous devez fournir vos informations d'identification à l'aide d'AWS Secrets Manager.
**Note**
Ne modifiez pas une règle de cache d'extraction lorsqu'une exécution active utilise le référentiel privé. L'exécution pourrait échouer ou, plus grave encore, entraîner l'utilisation d'images inattendues dans votre pipeline.
Pour plus d'informations, consultez la section [Création d'une règle de cache d'extraction](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) dans le *guide de l'utilisateur d'Amazon Elastic Container Registry*.
##### Création d'une règle de cache d'extraction à l'aide de la console
Pour configurer le cache d'extraction, procédez comme suit à l'aide de la console Amazon ECR :
1. Ouvrez la console Amazon ECR : https://console.aws.amazon.com /ecr
1. Dans le menu de gauche, sous **Registre privé**, développez **Fonctionnalités et paramètres**, puis choisissez **Pull through cache**.
1. Sur la page **du cache** d'extraction, choisissez **Ajouter une règle**.
1. Dans le panneau de **registre Upstream**, choisissez le registre amont à synchroniser avec votre registre privé, puis choisissez **Next**.
1. Si le registre en amont nécessite une authentification, la console ouvre une nouvelle page dans laquelle vous spécifiez le secret SageMaker AI qui contient vos informations d'identification. Choisissez **Suivant**.
1. Sous **Spécifier les espaces de noms**, dans le panneau de l'**espace de noms du cache**, choisissez de créer les référentiels privés à l'aide d'un préfixe de référentiel spécifique ou sans préfixe. Si vous choisissez d'utiliser un préfixe, spécifiez le nom du préfixe dans le préfixe du **référentiel de cache**.
1. Dans le panneau de l'**espace de noms Upstream**, choisissez si vous souhaitez extraire des référentiels en amont en utilisant un préfixe de référentiel spécifique ou sans préfixe. Si vous choisissez d'utiliser un préfixe, spécifiez le nom du préfixe dans le préfixe du **référentiel Upstream**.
Le panneau d'**exemple Namespace** affiche un exemple de pull request, une URL en amont et l'URL du référentiel de cache créé.
1. Choisissez **Suivant**.
1. Vérifiez la configuration et choisissez **Create** pour créer la règle.
Pour plus d'informations, voir [Création d'une règle de cache d'extraction (console AWS de gestion)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-console).
##### Création d'une règle de cache d'extraction à l'aide de la CLI
Utilisez la **create-pull-through-cache-rule** commande Amazon ECR pour créer une règle de cache d'extraction. Pour les registres en amont qui nécessitent une authentification, stockez les informations d'identification dans un secret Secrets Manager.
Les sections suivantes fournissent des exemples pour chaque registre en amont pris en charge.
##### Pour Amazon ECR Public
L'exemple suivant crée une règle de mise en cache par extraction pour le registre public Amazon ECR. Il spécifie un préfixe de référentiel de `ecr-public`, ce qui fait que chaque référentiel créé à l'aide de la règle de mise en cache par extraction aura le schéma de dénomination de `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
```
##### Pour Kubernetes Container Registry
L'exemple suivant crée une règle de mise en cache par extraction pour le registre public Kubernetes. Il spécifie un préfixe de référentiel de `kubernetes`, ce qui fait que chaque référentiel créé à l'aide de la règle de mise en cache par extraction aura le schéma de dénomination de `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
```
##### Pour Quay
L'exemple suivant crée une règle de mise en cache par extraction pour le registre public Quay. Il spécifie un préfixe de référentiel de `quay`, ce qui fait que chaque référentiel créé à l'aide de la règle de mise en cache par extraction aura le schéma de dénomination de `quay/upstream-repository-name`.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix quay \
--upstream-registry-url quay.io \
--region us-east-1
```
##### Pour Docker Hub
L'exemple suivant crée une règle de mise en cache par extraction pour le registre Docker Hub. Il spécifie un préfixe de référentiel de `docker-hub`, ce qui fait que chaque référentiel créé à l'aide de la règle de mise en cache par extraction aura le schéma de dénomination de `docker-hub/upstream-repository-name`. Vous devez spécifier l'Amazon Resource Name (ARN) complet du secret contenant vos informations d'identification Docker Hub.
```
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
```
##### Pour le registre des GitHub conteneurs
L'exemple suivant crée une règle de cache d'extraction pour le registre des GitHub conteneurs. Il spécifie un préfixe de référentiel de `github`, ce qui fait que chaque référentiel créé à l'aide de la règle de mise en cache par extraction aura le schéma de dénomination de `github/upstream-repository-name`. Vous devez spécifier le nom Amazon Resource Name (ARN) complet du secret contenant vos informations d'identification du registre des GitHub conteneurs.
```
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
```
##### Pour Microsoft Azure Container Registry
L'exemple suivant crée une règle de cache d'extraction pour le Microsoft Azure Container Registry. Il spécifie un préfixe de référentiel de `azure`, ce qui fait que chaque référentiel créé à l'aide de la règle de mise en cache par extraction aura le schéma de dénomination de `azure/upstream-repository-name`. Vous devez spécifier l'Amazon Resource Name (ARN) complet du secret contenant vos informations d'identification Azure Container Registry.
```
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
```
##### Pour le registre des GitLab conteneurs
L'exemple suivant crée une règle de cache d'extraction pour le registre des GitLab conteneurs. Il spécifie un préfixe de référentiel de `gitlab`, ce qui fait que chaque référentiel créé à l'aide de la règle de mise en cache par extraction aura le schéma de dénomination de `gitlab/upstream-repository-name`. Vous devez spécifier le nom Amazon Resource Name (ARN) complet du secret contenant vos informations d'identification du registre des GitLab conteneurs.
```
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
```
Pour plus d'informations, consultez la section [Créer une règle de cache d'extraction (CLI)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-cli) dans le *guide de l'utilisateur Amazon ECR.*
Vous pouvez utiliser la commande **get-run-task** CLI pour récupérer des informations sur l'image du conteneur utilisée pour une tâche spécifique :
```
aws omics get-run-task --id 1234567 --task-id
```
La sortie inclut les informations suivantes concernant l'image du conteneur :
```
"imageDetails": {
"image": "string",
"imageDigest": "string",
"sourceImage": "string",
...
}
```
#### Autorisations de registre pour le registre en amont
Utilisez les autorisations de registre HealthOmics pour autoriser l'utilisation du cache d'extraction et l'extraction des images du conteneur dans le registre privé Amazon ECR. Ajoutez une politique de registre Amazon ECR au registre qui fournit les conteneurs utilisés lors des exécutions.
La politique suivante autorise le HealthOmics service à créer des référentiels avec le ou les préfixes de cache d'extraction spécifiés et à lancer des extractions en amont dans ces référentiels.
1. Depuis la console Amazon ECR, ouvrez le menu de gauche, sous **Registre privé**, développez **les autorisations du registre**, puis choisissez **Generate statement**.
1. En haut à droite, choisissez JSON. Entrez une politique similaire à la suivante :
------
#### [ 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/*"
]
}
]
}
```
------
#### Modèles de création de référentiels
Pour utiliser la mise en cache par extraction HealthOmics, le référentiel Amazon ECR doit disposer d'un modèle de création de référentiel. Le modèle définit les paramètres de configuration lorsque vous ou Amazon ECR créez un référentiel privé pour un registre en amont.
Chaque modèle contient un préfixe d'espace de noms de référentiel, qu'Amazon ECR utilise pour associer les nouveaux référentiels à un modèle spécifique. Les modèles spécifient la configuration de tous les paramètres du référentiel, notamment les politiques d'accès basées sur les ressources, l'immuabilité des balises, le chiffrement et les politiques de cycle de vie.
Pour plus d'informations, consultez les [modèles de création de référentiels](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) dans le *guide de l'utilisateur d'Amazon Elastic Container Registry*.
Comment créer un modèle de création de référentiel :
1. Depuis la console Amazon ECR, ouvrez le menu de gauche, sous **Registre privé**, développez **Fonctionnalités et paramètres**, puis choisissez **Modèles de création de référentiel**.
1. Sélectionnez **Create template (Créer un modèle)**.
1. Dans **Détails du modèle**, choisissez **Pull through cache**.
1. Choisissez d'appliquer ce modèle à un préfixe spécifique ou à tous les référentiels qui ne correspondent pas à un autre modèle.
**Si vous choisissez **Un préfixe spécifique, entrez la valeur du préfixe** de l'espace de noms dans Préfixe.** Vous avez spécifié ce préfixe lors de la création de la règle PTC.
1. Choisissez **Suivant**.
1. Dans la **page de configuration de la création d'un référentiel**, entrez **les autorisations du référentiel**. Utilisez l'un des exemples de déclarations de politique ou saisissez-en un similaire à l'exemple suivant :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PTCRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
1. Vous pouvez éventuellement ajouter des paramètres de référentiel tels que la politique de cycle de vie et les balises. Amazon ECR applique ces règles à toutes les images de conteneur créées pour le cache d'extraction qui utilisent le préfixe spécifié.
1. Choisissez **Suivant**.
1. Vérifiez la configuration et choisissez **Next**.
#### Création du flux de travail
Lorsque vous créez un nouveau flux de travail ou une nouvelle version de flux de travail, passez en revue les mappages de registre et mettez-les à jour si nécessaire. Pour en savoir plus, consultez [Création d'un flux de travail privé](create-private-workflow.md).
### Mappages de registres
Vous définissez des mappages de registre pour mapper les préfixes de votre registre Amazon ECR privé et les noms de registre en amont.
Pour plus d'informations sur les mappages de registre Amazon ECR, consultez [Création d'une règle de cache d'extraction dans Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) ECR.
L'exemple suivant montre les mappages de registre vers Docker Hub, Quay et Amazon ECR Public.
```
{
"registryMappings": [
{
"upstreamRegistryUrl": "registry-1.docker.io",
"ecrRepositoryPrefix": "docker-hub"
},
{
"upstreamRegistryUrl": "quay.io",
"ecrRepositoryPrefix": "quay"
},
{
"upstreamRegistryUrl": "public.ecr.aws",
"ecrRepositoryPrefix": "ecr-public"
}
]
}
```
### Mappages d'images
Vous définissez des mappages d'images pour établir une correspondance entre les noms d'images tels que définis dans vos flux de travail Amazon ECR privés et les noms d'images dans le registre en amont.
Vous pouvez utiliser des mappages d'images avec des registres qui prennent en charge le pull through cache. Vous pouvez également utiliser des mappages d'images avec des registres en amont où le cache d'extraction HealthOmics n'est pas pris en charge. Vous devez synchroniser manuellement le registre en amont avec votre dépôt privé.
Pour plus d'informations sur les mappages d'images Amazon ECR, consultez [Création d'une règle de cache d'extraction dans Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) ECR.
L'exemple suivant montre les mappages entre des images Amazon ECR privées et une image génomique publique et la dernière image 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",
}
]
}
```
## Considérations générales relatives aux images de conteneurs Amazon ECR
+ Architecture
HealthOmics prend en charge les conteneurs x86\$164. Si votre machine locale est basée sur ARM, comme Apple Mac, utilisez une commande telle que la suivante pour créer une image de conteneur x86\$164 :
```
docker build --platform amd64 -t my_tool:latest .
```
+ Point d'entrée et coque
HealthOmics les moteurs de flux de travail injectent des scripts bash pour remplacer les commandes des images de conteneur utilisées par les tâches de flux de travail. Ainsi, les images de conteneur doivent être créées sans point d'entrée spécifié, de sorte qu'un shell bash soit le shell par défaut.
+ Chemins montés
Un système de fichiers partagé est monté sur les tâches du conteneur dans /tmp. Toutes les données ou tous les outils intégrés à l'image du conteneur à cet emplacement seront remplacés.
La définition du flux de travail est accessible aux tâches via un montage en lecture seule sur /mnt/workflow.
+ Taille de l’image
Voir [HealthOmics quotas de taille fixe du flux de travail](fixed-quotas.md#fixed-quotas-workflows) pour les tailles maximales des images des conteneurs.
## Variables d'environnement pour les HealthOmics flux de travail
HealthOmics fournit des variables d'environnement contenant des informations sur le flux de travail exécuté dans le conteneur. Vous pouvez utiliser les valeurs de ces variables dans la logique de vos tâches de flux de travail.
Toutes les variables HealthOmics de flux de travail commencent par le `AWS_WORKFLOW_` préfixe. Ce préfixe est un préfixe de variable d'environnement protégée. N'utilisez pas ce préfixe pour vos propres variables dans les conteneurs de flux de travail.
HealthOmics fournit les variables d'environnement de flux de travail suivantes :
**AWS\$1REGION**
Cette variable correspond à la région dans laquelle le conteneur est exécuté.
**AWS\$1WORKFLOW\$1EXÉCUTER**
Cette variable est le nom de l'exécution en cours.
**AWS\$1WORKFLOW\$1RUN\$1ID**
Cette variable est l'identifiant de l'exécution en cours.
**AWS\$1WORKFLOW\$1EXÉCUTER\$1UUID**
Cette variable est l'UUID d'exécution de l'exécution en cours.
**AWS\$1WORKFLOW\$1TÂCHE**
Cette variable est le nom de la tâche en cours.
**AWS\$1WORKFLOW\$1IDENTIFIANT DE TÂCHE**
Cette variable est l'identifiant de la tâche en cours.
**AWS\$1WORKFLOW\$1UUID DE TÂCHE**
Cette variable est l'UUID de la tâche en cours.
L'exemple suivant montre les valeurs typiques de chaque variable d'environnement :
```
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
```
## Utilisation de Java dans les images de conteneurs Amazon ECR
Si une tâche de flux de travail utilise une application Java telle que GATK, tenez compte des exigences de mémoire suivantes pour le conteneur :
+ Les applications Java utilisent de la mémoire en pile et de la mémoire en tas. Par défaut, la mémoire de segment maximale est un pourcentage de la mémoire totale disponible dans le conteneur. Cette valeur par défaut dépend de la distribution et de la version de la JVM spécifiques. Consultez donc la documentation correspondante à votre machine virtuelle Java ou définissez explicitement le maximum de mémoire à l'aide des options de ligne de commande Java (telles que `-Xmx`).
+ Ne définissez pas la mémoire de segment maximale à 100 % de l'allocation de mémoire du conteneur, car la pile JVM nécessite également de la mémoire. De la mémoire est également requise pour le ramasse-miettes de la machine virtuelle Java et pour tout autre processus du système d'exploitation exécuté dans le conteneur.
+ Certaines applications Java, telles que GATK, peuvent utiliser des invocations de méthodes natives ou d'autres optimisations telles que des fichiers de mappage de mémoire. Ces techniques nécessitent des allocations de mémoire effectuées « hors segment », qui ne sont pas contrôlées par le paramètre de mémoire maximale de la JVM.
Si vous savez (ou pensez) que votre application Java alloue de la mémoire hors segment, assurez-vous que l'allocation de mémoire aux tâches inclut les exigences en matière de mémoire externe.
Si ces allocations hors segment entraînent un manque de mémoire du conteneur, vous ne verrez généralement pas d'**OutOfMemory**erreur Java, car la JVM ne contrôle pas cette mémoire.
## Ajouter des entrées de tâches à une image de conteneur Amazon ECR
Ajoutez tous les exécutables, bibliothèques et scripts nécessaires pour exécuter une tâche de flux de travail dans l'image Amazon ECR utilisée pour exécuter la tâche.
Il est recommandé d'éviter d'utiliser des scripts, des fichiers binaires et des bibliothèques externes à une image de conteneur de tâches. Cela est particulièrement important lorsque vous utilisez `nf-core` des flux de travail qui utilisent un `bin` répertoire dans le cadre du package de flux de travail. Bien que ce répertoire soit disponible pour la tâche de flux de travail, il est monté en tant que répertoire en lecture seule. Les ressources requises dans ce répertoire doivent être copiées dans l'image de la tâche et mises à disposition lors de l'exécution ou lors de la création de l'image de conteneur utilisée pour la tâche.
Voir [HealthOmics quotas de taille fixe du flux de travail](fixed-quotas.md#fixed-quotas-workflows) pour connaître la taille maximale de l'image de conteneur prise HealthOmics en charge.
# HealthOmics Fichiers README du flux de travail
Vous pouvez télécharger un fichier README.md contenant des instructions, des diagrammes et des informations essentielles pour votre flux de travail. Chaque version du flux de travail prend en charge un fichier README, que vous pouvez mettre à jour à tout moment.
**Les exigences du README incluent :**
+ Le fichier README doit être au format Markdown (.md)
+ Taille de fichier maximale : 500 KiB
**Topics**
+ [Utiliser un fichier README existant](#workflows-add-readme)
+ [Conditions de rendu](#workflows-rendering-readme)
## Utiliser un fichier README existant
READMEs exportés depuis les référentiels Git contiennent des liens relatifs qui ne fonctionnent généralement pas en dehors du référentiel. HealthOmics L'intégration Git les convertit automatiquement en liens absolus pour un rendu correct dans la console, éliminant ainsi le besoin de mises à jour manuelles des URL.
Pour les images READMEs importées depuis Amazon S3 ou des lecteurs locaux, les images et les liens doivent être soit publics, URLs soit avoir leurs chemins relatifs mis à jour pour un rendu correct.
**Note**
Les images doivent être hébergées publiquement pour être affichées dans la HealthOmics console. Les images stockées dans GitHub Enterprise Server ou dans GitLab Self-Managed des référentiels ne peuvent pas être rendues.
## Conditions de rendu
La HealthOmics console interpole les images et les liens accessibles au public à l'aide de chemins absolus. Pour effectuer un rendu à URLs partir de référentiels privés, l'utilisateur doit avoir accès au référentiel. GitLab Self-ManagedLes référentiels For GitHub Enterprise Server ou, qui utilisent des domaines personnalisés, HealthOmics ne peuvent pas résoudre les liens relatifs ni afficher les images stockées dans ces référentiels privés.
Le tableau suivant indique les éléments Markdown pris en charge par la vue README de la AWS console.
| Element | AWS console |
| --- | --- |
| Alerts (Alertes) | Oui, mais sans icônes |
| Badges | Oui |
| Formatage de texte de base | Oui |
| [Blocs de code](https://www.markdownguide.org/basic-syntax/#code-blocks) | Oui, mais ne possède pas de fonctionnalité de [surlignage syntaxique](https://www.markdownguide.org/extended-syntax/#syntax-highlighting) et de bouton de copie |
| Sections pliables | Oui |
| [Rubriques](https://www.markdownguide.org/basic-syntax/#headings) | Oui |
| [Formats d'image](https://www.markdownguide.org/basic-syntax/#images-1) | Oui |
| [Image (cliquable)](https://www.markdownguide.org/basic-syntax/#linking-images) | Oui |
| [Sauts de ligne](https://www.markdownguide.org/basic-syntax/#line-breaks) | Oui |
| Schéma de la sirène | Peut uniquement ouvrir le graphique, déplacer la position du graphique et copier le code |
| Quotes | Oui |
| [Indice](https://www.markdownguide.org/extended-syntax/#subscript) [et exposant](https://www.markdownguide.org/extended-syntax/#superscript) | Oui |
| [Tables](https://www.markdownguide.org/extended-syntax/#tables) | Oui, mais ne prend pas en charge l'alignement du texte |
| Alignement du texte | Oui |
### Utilisation de l'image et du lien URLs
En fonction de votre fournisseur de source, structurez votre base URLs de pages et d'images dans les formats suivants.
+ `{username}`: nom d'utilisateur où le dépôt est hébergé.
+ `{repo}`: nom du référentiel.
+ `{ref}`: référence source (branche, balise et ID de validation).
+ `{path}`: chemin du fichier vers la page ou l'image dans le référentiel.
| Fournisseur de source | URL de la page | URL de l'image |
| --- | --- | --- |
| 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, et Bitbucket prend en charge à la fois les pages et URLs les images qui renvoient vers un dépôt public. Le tableau suivant indique la prise en charge par chaque fournisseur de source pour le rendu d'images et de liens URLs pour les référentiels privés.
| Support pour les référentiels privés | Fournisseur de source | URL de la page | URL de l'image |
| --- | --- | --- | --- |
| GitHub | Uniquement avec accès au référentiel | Non |
| GitLab | Uniquement avec accès au référentiel | Non |
| Bitbucket | Uniquement avec accès au référentiel | Non |
# Demande de licences Sentieon pour des flux de travail privés
Si votre flux de travail privé utilise le logiciel Sentieon, vous avez besoin d'une licence Senieon. Pour demander et configurer une licence pour le logiciel Sentieon, procédez comme suit :
+ Demandez une licence Sentieon
+ Envoyez un e-mail au groupe de support Sentieon (support@sentieon.com) pour demander une licence logicielle.
+ Indiquez votre nom d'utilisateur AWS canonique dans l'e-mail.
+ Trouvez votre nom d'utilisateur AWS canonique en suivant [ces instructions](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId).
+ Mettez à jour votre rôle de HealthOmics service pour lui accorder l'accès au proxy du serveur de licences Sentieon et au bucket Sentieon Omics de votre région. L'exemple suivant autorise l'accès à`us-east-1`. Si nécessaire, remplacez ce texte par votre région.
------
#### [ 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/*"
]
}
]
}
```
------
+ Générez un dossier d' AWS assistance pour accéder au proxy du serveur de licences Sentieon.
+ Pour créer un dossier d'assistance, accédez à [support.console.aws.amazon.com](https://support.console.aws.amazon.com).
+ Indiquez votre région Compte AWS et votre région dans le dossier d'assistance. Votre compte est ajouté à la liste des autorisations pour le proxy du serveur de licences.
+ Créez votre flux de travail privé à l'aide du conteneur Sentieon et du script de licence Sentieon.
+ Pour des instructions supplémentaires sur l'utilisation des outils Sentieon dans des flux de travail privés, voir [Sentieon-Amazon-Omics](https://github.com/Sentieon/sentieon-amazon-omics) dans. GitHub
+ La version 202112.07 et supérieure du logiciel Sentieon prend en charge le proxy du HealthOmics serveur de licences. Pour utiliser les versions du logiciel Sentieon antérieures au 202112.07, contactez le support Sentieon.
# Linters de flux de travail dans HealthOmics
Après avoir créé un flux de travail, nous vous recommandons d'exécuter un linter sur le flux de travail avant de commencer la première exécution. Le linter détecte les erreurs susceptibles de provoquer l'échec de l'exécution.
Pour WDL, exécute HealthOmics automatiquement un linter lorsque vous créez le flux de travail. La sortie Linter est disponible dans le `statusMessage` champ de la **get-workflow** réponse. Utilisez la commande CLI suivante pour récupérer la sortie d'état (utilisez l'ID du flux de travail WDL que vous avez créé) :
```
aws omics get-workflow
—id 123456
—query 'statusMessage'
```
HealthOmics fournit des linters que vous pouvez exécuter sur la définition du flux de travail avant de créer le flux de travail. Exécutez ces linters sur les pipelines existants vers lesquels vous effectuez la migration. HealthOmics
+ **WDL**— Une image Amazon ECR publique pour exécuter un linter [WDL](https://gallery.ecr.aws/aws-genomics/healthomics-linter).
+ **Nextflow**— Une image Amazon ECR publique pour exécuter les [règles Linter pour]( https://gallery.ecr.aws/aws-genomics/linter-rules-for-nextflow) Nextflow. Vous pouvez accéder au code source de ce linter à partir de [GitHub](https://github.com/awslabs/linter-rules-for-nextflow).
+ **CWL**— non disponible
# HealthOmics opérations de flux de travail
Pour créer un flux de travail privé, vous devez :
+ **Workflow definition file:**Un fichier de définition de flux de travail écrit en WDLNextflow, ouCWL. La définition du flux de travail spécifie les entrées et les sorties pour les exécutions qui utilisent le flux de travail. Il inclut également des spécifications pour les exécutions et les tâches d'exécution pour votre flux de travail, y compris les exigences en matière de calcul et de mémoire. Le fichier de définition du flux de travail doit être au `.zip` format. Pour plus d'informations, consultez la section [Fichiers de définition du flux](workflow-definition-files.md) de travail dans HealthOmics.
+ Vous pouvez utiliser [Amazon Q CLI](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) pour créer et valider vos fichiers de définition de flux de travail dans WDL, Nextflow et CWL. Pour plus d'informations, consultez les [exemples d'instructions pour Amazon Q CLI](getting-started.md#omics-q-prompts) et le didacticiel [HealthOmics Agentic Generative AI](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) sur. GitHub
+ **(Optional) Parameter template file:**Un fichier de modèle de paramètres écrit enJSON. Créez le fichier pour définir les paramètres d'exécution ou HealthOmics générez le modèle de paramètres pour vous. Pour plus d'informations, consultez la section [Fichiers modèles de paramètres pour les HealthOmics flux de travail](parameter-templates.md).
+ **Amazon ECR container images:**Créez des référentiels Amazon ECR privés pour chaque conteneur utilisé dans le flux de travail. Créez des images de conteneur pour le flux de travail et stockez-les dans un référentiel privé, ou synchronisez le contenu d'un registre en amont pris en charge avec votre référentiel privé ECR.
+ **(Optional) Sentieon licenses:**Demandez une Sentieon licence pour utiliser le Sentieon logiciel dans des flux de travail privés.
Pour les fichiers de définition de flux de travail supérieurs à 4 Mo (compressés), choisissez l'une des options suivantes lors de la création du flux de travail :
+ Téléchargez-le dans un dossier Amazon Simple Storage Service et spécifiez l'emplacement.
+ Téléchargez vers un référentiel externe (taille maximale de 1 GiB) et spécifiez les détails du référentiel.
Après avoir créé un flux de travail, vous pouvez mettre à jour les informations de flux de travail suivantes avec l'`UpdateWorkflow`opération :
+ Nom
+ Description
+ Type de stockage par défaut
+ Capacité de stockage par défaut (avec ID de flux de travail)
+ fichier README.md
Pour modifier d'autres informations du flux de travail, créez un nouveau flux de travail ou une nouvelle version de flux de travail.
Utilisez le versionnement des flux de travail pour organiser et structurer vos flux de travail. Les versions vous aident également à gérer l'introduction de mises à jour itératives du flux de travail. Pour plus d'informations sur les versions, consultez [Création d'une version de flux de travail](workflows-version-create.md).
**Topics**
+ [Création d'un flux de travail privé](create-private-workflow.md)
+ [Mettre à jour un flux de travail privé](update-private-workflow.md)
+ [Supprimer un flux de travail privé](delete-private-workflow.md)
+ [Vérifier l'état du flux de travail](using-get-workflow.md)
+ [Référencer des fichiers génomiques à partir d'une définition de flux de travail](create-ref-files.md)
# Création d'un flux de travail privé
Créez un flux de travail à l'aide de la HealthOmics console, des commandes de la AWS CLI ou de l'une des AWS SDKs.
**Note**
N'incluez aucune information personnellement identifiable (PII) dans les noms des flux de travail. Ces noms sont visibles dans les CloudWatch journaux.
Lorsque vous créez un flux de travail, HealthOmics attribuez un identifiant unique universel (UUID) au flux de travail. L'UUID du flux de travail est un identifiant global unique (GUID) unique pour tous les flux de travail et toutes les versions de flux de travail. À des fins de provenance des données, nous vous recommandons d'utiliser l'UUID du flux de travail pour identifier les flux de travail de manière unique.
Si vos tâches de flux de travail utilisent des outils externes (exécutables, bibliothèques ou scripts), vous créez ces outils dans une image de conteneur. Vous disposez des options suivantes pour héberger l'image du conteneur :
+ Hébergez l'image du conteneur dans le registre privé ECR. Les conditions requises pour cette option sont les suivantes :
+ Créez un référentiel privé ECR ou choisissez un référentiel existant.
+ Configurez la politique de ressources ECR comme décrit dans[Autorisations Amazon ECR](permissions-ecr.md).
+ Téléchargez l'image de votre conteneur dans le référentiel privé.
+ Synchronisez l'image du conteneur avec le contenu d'un registre tiers pris en charge. Les conditions requises pour cette option sont les suivantes :
+ Dans le registre privé ECR, configurez une règle de cache d'extraction pour chaque registre en amont. Pour de plus amples informations, veuillez consulter [Mappages d'images](workflows-ecr.md#ecr-pull-through-mapping-format).
+ Configurez la politique de ressources ECR comme décrit dans[Autorisations Amazon ECR](permissions-ecr.md).
+ Créez des modèles de création de référentiels. Le modèle définit les paramètres à partir desquels Amazon ECR crée le référentiel privé pour un registre en amont.
+ Créez des mappages de préfixes pour remapper les références d'images de conteneur dans la définition du flux de travail avec les espaces de noms du cache ECR.
Lorsque vous créez un flux de travail, vous fournissez une définition de flux de travail contenant des informations sur le flux de travail, les exécutions et les tâches. HealthOmics peut récupérer la définition du flux de travail sous forme d'archive .zip stockée localement ou dans un compartiment Amazon S3, ou à partir d'un référentiel Git compatible.
**Topics**
+ [Création d'un flux de travail à l'aide de la console](#console-create-workflows)
+ [Création d'un flux de travail à l'aide de la CLI](#api-create-workflows)
+ [Création d'un flux de travail à l'aide d'un SDK](#sdk-create-workflows)
## Création d'un flux de travail à l'aide de la console
**Étapes de création d'un flux de travail**
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez des **flux de travail privés**.
1. Sur la page **Flux de travail privés**, choisissez **Créer un flux de travail**.
1. Sur la page **Définir le flux** de travail, fournissez les informations suivantes :
1. **Nom du flux** de travail : nom distinctif pour ce flux de travail. Nous vous recommandons de définir des noms de flux de travail pour organiser vos exécutions dans la AWS HealthOmics console et CloudWatch les journaux.
1. **Description** (facultatif) : description de ce flux de travail.
1. Dans le panneau **de définition du flux** de travail, fournissez les informations suivantes :
1. **Langue du flux** de travail (facultatif) : sélectionnez la langue de spécification du flux de travail. Dans le cas contraire, HealthOmics détermine la langue à partir de la définition du flux de travail.
1. Pour **la source de définition du flux** de travail, choisissez d'importer le dossier de définition à partir d'un référentiel Git, d'un emplacement Amazon S3 ou d'un lecteur local.
1. Pour **l'importation depuis un service de référentiel** :
**Note**
HealthOmics prend en charge les référentiels publics et privés pour GitHubGitLab,, BitbucketGitHub self-managed,GitLab self-managed.
1. Choisissez une **connexion** pour connecter vos AWS ressources au référentiel externe. Pour créer une connexion, voir[Connectez-vous à des référentiels de code externes](setting-up-new.md#setting-up-omics-repository).
**Note**
Les clients de la TLV région doivent créer une connexion dans la région IAD (us-east-1) pour créer un flux de travail.
1. Dans ID de **référentiel complet, entrez votre ID** de référentiel sous forme de nom d'utilisateur/nom de dépôt. Vérifiez que vous avez accès aux fichiers de ce dépôt.
1. Dans **Référence de source** (facultatif), entrez une référence de source de référentiel (branche, balise ou ID de validation). HealthOmics utilise la branche par défaut si aucune référence de source n'est spécifiée.
1. Dans **Exclure les modèles** de fichiers, entrez les modèles de fichiers pour exclure des dossiers, des fichiers ou des extensions spécifiques. Cela permet de gérer la taille des données lors de l'importation de fichiers de référentiel. Il y a un maximum de 50 modèles, et les modèles doivent suivre la syntaxe du [modèle global](https://fossil-scm.org/home/doc/tip/www/globs.md). Par exemple :
1. `tests/`
1. `*.jpeg`
1. `large_data.zip`
1. Pour **Sélectionner le dossier de définition depuis S3** :
1. Entrez l'emplacement Amazon S3 qui contient le dossier de définition du flux de travail compressé. Le compartiment Amazon S3 doit se trouver dans la même région que le flux de travail.
1. Si votre compte ne possède pas le compartiment Amazon S3, entrez l'ID de AWS compte du propriétaire du compartiment dans l'ID **de compte du propriétaire du compartiment S3**. Ces informations sont nécessaires pour vérifier HealthOmics la propriété du compartiment.
1. Pour **Sélectionner le dossier de définition à partir d'une source locale** :
1. Entrez l'emplacement du lecteur local du dossier de définition du flux de travail compressé.
1. **Chemin du fichier de définition du flux de travail principal** (facultatif) : entrez le chemin du fichier depuis le dossier ou le référentiel de définition du flux de travail compressé vers le `main` fichier. Ce paramètre n'est pas obligatoire s'il n'existe qu'un seul fichier dans le dossier de définition du flux de travail ou si le fichier principal est nommé « main ».
1. Dans le panneau du **fichier README** (facultatif), sélectionnez la **source du fichier README** et fournissez les informations suivantes :
+ Pour **Importer depuis un service de référentiel**, dans le **champ Chemin du fichier README**, entrez le chemin du fichier README dans le référentiel.
+ Pour **Select file from S3**, dans le **fichier README dans S3**, entrez l'URI Amazon S3 du fichier README.
+ Pour **Sélectionner un fichier à partir d'une source locale** : dans **README, facultatif**, **choisissez Choisir un fichier** pour sélectionner le fichier Markdown (.md) à télécharger.
1. Dans le panneau de **configuration du stockage d'exécution par** défaut, indiquez le type de stockage d'exécution par défaut et la capacité pour les exécutions utilisant ce flux de travail :
1. **Type de stockage d'exécution** : choisissez d'utiliser le stockage statique ou dynamique par défaut pour le stockage d'exécution temporaire. La valeur par défaut est le stockage statique.
1. **Capacité de stockage d'exécution** (facultatif) : pour le type de stockage d'exécution statique, vous pouvez entrer la quantité de stockage d'exécution par défaut requise pour ce flux de travail. La valeur par défaut de ce paramètre est de 1200 GiB. Vous pouvez remplacer ces valeurs par défaut lorsque vous démarrez une course.
1. **Balises** (facultatif) : vous pouvez associer jusqu'à 50 balises à ce flux de travail.
1. Choisissez **Suivant**.
1. Sur la page **Ajouter des paramètres de flux** de travail (facultatif), sélectionnez la **source du paramètre** :
1. Pour **Parse from fichier de définition de flux de travail**, HealthOmics analysera automatiquement les paramètres du flux de travail à partir du fichier de définition de flux de travail.
1. Pour **Provide parameter template from Git repository**, utilisez le chemin d'accès au fichier de modèle de paramètres depuis votre dépôt.
1. Pour **Select JSON file from local source**, téléchargez un JSON fichier depuis une source locale qui spécifie les paramètres.
1. Pour **saisir manuellement les paramètres du flux** de travail, entrez manuellement les noms et les descriptions des paramètres.
1. Dans le panneau d'**aperçu des paramètres**, vous pouvez consulter ou modifier les paramètres de cette version du flux de travail. Si vous restaurez le JSON fichier, vous perdrez toutes les modifications locales que vous avez apportées.
1. Choisissez **Suivant**.
1. Sur la page de **remappage des URI du conteneur**, dans le panneau **Règles de mappage**, vous pouvez définir des règles de mappage des URI pour votre flux de travail.
Pour **Source du fichier de mappage**, sélectionnez l'une des options suivantes :
+ **Aucune : aucune** règle de mappage n'est requise.
+ **Sélectionnez le fichier JSON dans S3** — Spécifiez l'emplacement S3 du fichier de mappage.
+ **Sélectionnez un fichier JSON à partir d'une source locale** : spécifiez l'emplacement du fichier de mappage sur votre appareil local.
+ **Entrez les mappages manuellement** **: entrez les mappages de registre et les mappages d'images dans le panneau Mappages.**
1. La console affiche le panneau **Mappings.** Si vous avez choisi un fichier source de mappage, la console affiche les valeurs du fichier.
1. Dans **les mappages de registre**, vous pouvez modifier les mappages ou ajouter des mappages (maximum de 20 mappages de registre).
Chaque mappage de registre contient les champs suivants :
+ **URL du registre en amont** : URI du registre en amont.
+ Préfixe **du référentiel ECR : préfixe** du référentiel à utiliser dans le référentiel privé Amazon ECR.
+ (Facultatif) **Préfixe du référentiel en amont** : préfixe du référentiel dans le registre en amont.
+ (Facultatif) ID de **compte ECR : ID** de compte du compte propriétaire de l'image du conteneur en amont.
1. Dans **Mappages d'images**, vous pouvez modifier les mappages d'images ou ajouter des mappages (maximum de 100 mappages d'images).
Chaque mappage d'image contient les champs suivants :
+ **Image source** — Spécifie l'URI de l'image source dans le registre en amont.
+ **Image de destination** — Spécifie l'URI de l'image correspondante dans le registre Amazon ECR privé.
1. Choisissez **Suivant**.
1. Vérifiez la configuration du flux de travail, puis choisissez **Créer un flux de travail**.
## Création d'un flux de travail à l'aide de la CLI
Si vos fichiers de flux de travail et le fichier de modèle de paramètres se trouvent sur votre machine locale, vous pouvez créer un flux de travail à l'aide de la commande CLI suivante.
```
aws omics create-workflow \
--name "my_workflow" \
--definition-zip fileb://my-definition.zip \
--parameter-template file://my-parameter-template.json
```
L'`create-workflow`opération renvoie la réponse suivante :
```
{
"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"
}
```
### Paramètres facultatifs à utiliser lors de la création d'un flux de travail
Vous pouvez spécifier n'importe quel paramètre facultatif lorsque vous créez un flux de travail. Pour plus de détails sur la syntaxe, consultez [CreateWorkflow](https://docs.aws.amazon.com/omics/latest/api/API_CreateWorkflow.html)le manuel de référence des HealthOmics API AWS.
**Topics**
+ [Spécifiez la définition du flux de travail (emplacement Amazon S3)](#create-defn-uri-parameter)
+ [Utiliser la définition du flux de travail à partir d'un référentiel basé sur Git](#create-defn-uri-git)
+ [Spécifier un fichier Readme](#specify-readme-file)
+ [Spécifiez le fichier **main** de définition](#create-main-parameter)
+ [Spécifiez le type de stockage d'exécution](#create-run-storage-parameter)
+ [Spécifiez la configuration du GPU](#create-accelerator-parameter)
+ [Configuration des paramètres de mappage du cache à extraction](#create-prefix-mapping-parameters)
#### Spécifiez la définition du flux de travail (emplacement Amazon S3)
Si le fichier de définition de votre flux de travail se trouve dans un dossier Amazon S3, spécifiez l'emplacement à l'aide du `definition-uri` paramètre, comme indiqué dans l'exemple suivant. Si votre compte ne possède pas le compartiment Amazon S3, fournissez l' Compte AWS ID du propriétaire.
```
aws omics create-workflow \
--name Test \
--definition-uri s3://omics-bucket/workflow-definition/ \
--owner-id 123456789012
...
```
#### Utiliser la définition du flux de travail à partir d'un référentiel basé sur Git
Pour utiliser la définition du flux de travail provenant d'un référentiel Git compatible, utilisez le `definition-repository` paramètre dans votre demande. Ne fournissez aucun autre `definition` paramètre, car une demande échoue si elle inclut plusieurs sources d'entrée.
Le `definition-respository` paramètre contient les champs suivants :
+ **connectionArn**— ARN de la connexion au code qui connecte vos ressources AWS au référentiel externe.
+ **fullRepositoryId**— Entrez l'ID du référentiel sous la forme`owner-name/repo-name`. Vérifiez que vous avez accès aux fichiers de ce dépôt.
+ **sourceReference**(Facultatif) — Entrez un type de référence de référentiel (BRANCH, TAG ou COMMIT) et une valeur.
HealthOmics utilise le dernier commit sur la branche par défaut si vous ne spécifiez pas de référence de source.
+ **excludeFilePatterns**(Facultatif) — Entrez les modèles de fichiers pour exclure des dossiers, des fichiers ou des extensions spécifiques. Cela permet de gérer la taille des données lors de l'importation de fichiers de référentiel. Fournissez un maximum de 50 modèles. Les modèles doivent suivre la syntaxe du modèle [global.](https://fossil-scm.org/home/doc/tip/www/globs.md) Par exemple :
+ `tests/`
+ `*.jpeg`
+ `large_data.zip`
Lorsque vous spécifiez la définition du flux de travail à partir d'un référentiel basé sur Git, utilisez-la `parameter-template-path` pour spécifier le fichier de modèle de paramètres. Si vous ne fournissez pas ce paramètre, HealthOmics crée le flux de travail sans modèle de paramètres.
L'exemple suivant montre les paramètres liés au contenu d'un dépôt privé basé sur 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" \
```
Pour d'autres exemples, consultez le billet de blog [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).
#### Spécifier un fichier Readme
Vous pouvez spécifier l'emplacement du fichier README à l'aide de l'un des paramètres suivants :
+ **readme-markdown**— Entrée d'une chaîne ou d'un fichier sur votre machine locale.
+ **readme-uri**— L'URI d'un fichier stocké sur S3.
+ **readme-path **— Le chemin d'accès au fichier README dans le référentiel.
**Utilisez readme-path uniquement en conjonction avec definition-respository.** Si vous ne spécifiez aucun paramètre README, HealthOmics importe le fichier README.md de niveau racine dans le référentiel (s'il existe).
Les exemples suivants montrent comment spécifier l'emplacement du fichier README en utilisant readme-path et readme-uri.
```
# 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"
```
Pour de plus amples informations, veuillez consulter [HealthOmics Fichiers README du flux de travail](workflows-readme.md).
#### Spécifiez le fichier **main** de définition
Si vous incluez plusieurs fichiers de définition de flux de travail, utilisez le `main` paramètre pour spécifier le fichier de définition principal de votre flux de travail.
```
aws omics create-workflow \
--name Test \
--main multi_workflow/workflow2.wdl \
...
```
#### Spécifiez le type de stockage d'exécution
Vous pouvez spécifier le type de stockage d'exécution par défaut (DYNAMIC ou STATIC) et la capacité de stockage d'exécution (requise pour le stockage statique). Pour plus d'informations sur les types de stockage d'exécution, consultez[Exécuter les types de stockage dans les HealthOmics flux de travail](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 \
```
#### Spécifiez la configuration du GPU
Utilisez le paramètre accelerators pour créer un flux de travail qui s'exécute sur une instance de calcul accéléré. L'exemple suivant montre comment utiliser le `accelerators` paramètre. Vous spécifiez la configuration du GPU dans la définition du flux de travail. Consultez [Instances de calcul accéléré](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
```
#### Configuration des paramètres de mappage du cache à extraction
Si vous utilisez la fonctionnalité de mappage de cache par extraction d'Amazon ECR, vous pouvez remplacer les mappages par défaut. Pour plus d'informations sur les paramètres de configuration du conteneur, consultez[Images de conteneur pour les flux de travail privés](workflows-ecr.md).
Dans l'exemple suivant, le fichier `mappings.json` contient le contenu suivant :
```
{
"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"
}
]
}
```
Spécifiez les paramètres de mappage dans la commande create-workflow :
```
aws omics create-workflow \
...
--container-registry-map-file file://mappings.json
...
```
Vous pouvez également spécifier l'emplacement S3 du fichier de paramètres de mappage :
```
aws omics create-workflow \
...
--container-registry-map-uri s3://amzn-s3-demo-bucket1/test.zip
...
```
## Création d'un flux de travail à l'aide d'un SDK
Vous pouvez créer un flux de travail à l'aide de l'un des SDKs. L'exemple suivant montre comment créer un flux de travail à l'aide du SDK Python
```
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={ ... }
)
```
# Mettre à jour un flux de travail privé
Vous pouvez mettre à jour un flux de travail à l'aide de la HealthOmics console, des commandes de la AWS CLI ou de l'une des AWS SDKs.
**Note**
N'incluez aucune information personnellement identifiable (PII) dans les noms des flux de travail. Ces noms sont visibles dans les CloudWatch journaux.
**Topics**
+ [Mettre à jour un flux de travail à l'aide de la console](#console-update-workflows)
+ [Mettre à jour un flux de travail à l'aide de la CLI](#api-update-workflows)
+ [Mettre à jour un flux de travail à l'aide d'un SDK](#sdk-update-workflows)
## Mettre à jour un flux de travail à l'aide de la console
**Étapes pour mettre à jour un flux de travail**
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez des **flux de travail privés**.
1. Sur la page **Flux de travail privés**, choisissez le flux de travail à mettre à jour.
1. Sur la page **Workflow** :
+ Si le flux de travail comporte des versions, assurez-vous de sélectionner la **version par défaut**.
+ Choisissez **Modifier dans** la liste des **actions**.
1. Sur la page **Modifier le flux** de travail, vous pouvez modifier l'une des valeurs suivantes :
+ **Nom du flux de travail**.
+ **Description du flux** de travail.
+ **Type de stockage Run** par défaut pour le flux de travail.
+ **Capacité de stockage d'exécution** par défaut (si le type de stockage d'exécution est un stockage statique). Pour plus d'informations sur la configuration d'exécution du stockage par défaut, consultez[Création d'un flux de travail à l'aide de la console](create-private-workflow.md#console-create-workflows).
1. Choisissez **Enregistrer les modifications** pour appliquer les modifications.
## Mettre à jour un flux de travail à l'aide de la CLI
Comme le montre l'exemple suivant, vous pouvez mettre à jour le nom et la description du flux de travail. Vous pouvez également modifier le type de stockage d'exécution par défaut (STATIC ou DYNAMIC) et la capacité de stockage d'exécution (pour le type de stockage statique). Pour plus d'informations sur les types de stockage d'exécution, consultez[Exécuter les types de stockage dans les HealthOmics flux de travail](workflows-run-types.md).
```
aws omics update-workflow \
--id 1234567 \
--name my_workflow \
--description "updated workflow" \
--storage-type 'STATIC' \
--storage-capacity 1200
```
Vous ne recevez pas de réponse à cette `update-workflow` demande.
## Mettre à jour un flux de travail à l'aide d'un SDK
Vous pouvez mettre à jour un flux de travail à l'aide de l'un des SDKs.
L'exemple suivant montre comment mettre à jour un flux de travail à l'aide du SDK Python
```
import boto3
omics = boto3.client('omics')
response = omics.update_workflow(
name='my_workflow',
description='updated workflow'
)
```
# Supprimer un flux de travail privé
Lorsque vous n'avez plus besoin d'un flux de travail, vous pouvez le supprimer à l'aide de la HealthOmics console, des commandes de la AWS CLI ou de l'une des commandes AWS SDKs. Vous pouvez supprimer un flux de travail répondant aux critères suivants :
+ Son statut est ACTIF ou ÉCHEC.
+ Elle ne possède aucune action active.
+ Vous avez supprimé toutes les versions du flux de travail.
La suppression d'un flux de travail n'a aucune incidence sur les exécutions en cours utilisant le flux de travail.
**Topics**
+ [Supprimer un flux de travail à l'aide de la console](#console-delete-workflows)
+ [Supprimer un flux de travail à l'aide de la CLI](#api-delete-workflows)
+ [Supprimer un flux de travail à l'aide d'un SDK](#sdk-delete-workflows)
## Supprimer un flux de travail à l'aide de la console
**Pour supprimer un flux de travail**
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez des **flux de travail privés**.
1. Sur la page **Flux de travail privés**, choisissez le flux de travail à supprimer.
1. Sur la page **Workflow**, choisissez **Supprimer la sélection** dans la liste des **actions**.
1. Dans le mode **Supprimer le flux** de travail, entrez « confirmer » pour confirmer la suppression.
1. Sélectionnez **Delete (Supprimer)**.
## Supprimer un flux de travail à l'aide de la CLI
L'exemple suivant montre comment utiliser la AWS CLI commande pour supprimer un flux de travail. Pour exécuter l'exemple, remplacez le `workflow id` par l'ID du flux de travail que vous souhaitez supprimer.
```
aws omics delete-workflow
--id workflow id
```
HealthOmics n'envoie pas de réponse à la `delete-workflow` demande.
## Supprimer un flux de travail à l'aide d'un SDK
Vous pouvez supprimer un flux de travail à l'aide de l'un des SDKs.
L'exemple suivant montre comment supprimer un flux de travail à l'aide du SDK Python.
```
import boto3
omics = boto3.client('omics')
response = omics.delete_workflow(
id='1234567'
)
```
# Vérifier l'état du flux de travail
Après avoir créé votre flux de travail, vous pouvez vérifier son statut et consulter d'autres détails du flux de travail à l'aide de **get-workflow**, comme indiqué.
```
aws omics get-workflow --id 1234567
```
La réponse inclut les détails du flux de travail, y compris le statut, comme indiqué.
```
{
"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"
}
```
Vous pouvez démarrer une exécution à l'aide de ce flux de travail une fois que le statut est passé à`ACTIVE`.
# Référencer des fichiers génomiques à partir d'une définition de flux de travail
Un objet de magasin de HealthOmics référence peut être référencé avec un URI comme celui-ci. Utilisez le vôtre `account ID``reference store ID`, et `reference ID` là où cela est indiqué.
```
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id
```
Certains flux de travail nécessiteront à la fois `INDEX` les fichiers `SOURCE` et pour le génome de référence. L'URI précédent est la forme abrégée par défaut et sera le fichier SOURCE par défaut. Pour spécifier l'un ou l'autre des fichiers, vous pouvez utiliser le format URI long, comme suit.
```
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
```
L'utilisation d'un ensemble de lecture de séquences aurait un schéma similaire, comme indiqué.
```
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
```
Certains ensembles de lecture, tels que ceux basés sur FASTQ, peuvent contenir des lectures jumelées. Dans les exemples suivants, ils sont appelés SOURCE1 et SOURCE2. Les formats tels que BAM et CRAM n'auront qu'un SOURCE1 fichier. Certains ensembles de lecture contiendront des fichiers INDEX tels que `crai` des fichiers `bai` ou. L'URI précédent est la forme abrégée par défaut et sera le SOURCE1 fichier par défaut. Pour spécifier le fichier ou l'index exact, vous pouvez utiliser le format URI long, comme suit.
```
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
```
Voici un exemple de fichier JSON d'entrée qui utilise deux 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/"
}
```
Référencez le fichier JSON d'entrée dans le AWS CLI en l'ajoutant `--inputs file://` à votre demande de **démarrage**.