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
```
------
# File modello di parametri per i flussi HealthOmics di lavoro
I modelli di parametri definiscono i parametri di input per un flusso di lavoro. È possibile definire i parametri di input per rendere il flusso di lavoro più flessibile e versatile. Ad esempio, puoi definire un parametro per la posizione in Amazon S3 dei file del genoma di riferimento. I modelli di parametri possono essere forniti tramite un servizio di repository basato su Git o l'unità locale. Gli utenti possono quindi eseguire il flusso di lavoro utilizzando vari set di dati.
È possibile creare il modello di parametri per il flusso di lavoro HealthOmics oppure generare il modello di parametri automaticamente.
Il modello di parametro è un file JSON. Nel file, ogni parametro di input è un oggetto denominato che deve corrispondere al nome dell'input del flusso di lavoro. Quando si avvia un'esecuzione, se non si forniscono valori per tutti i parametri richiesti, l'esecuzione ha esito negativo.
L'oggetto del parametro di input include i seguenti attributi:
+ **description**— Questo attributo obbligatorio è una stringa che la console visualizza nella pagina **Start run**. Questa descrizione viene conservata anche come metadati di esecuzione.
+ **optional**— Questo attributo opzionale indica se il parametro di input è facoltativo. Se non si specifica il **optional** campo, il parametro di input è obbligatorio.
Il seguente modello di parametri di esempio mostra come specificare i parametri di input.
```
{
"myRequiredParameter1": {
"description": "this parameter is required",
},
"myRequiredParameter2": {
"description": "this parameter is also required",
"optional": false
},
"myOptionalParameter": {
"description": "this parameter is optional",
"optional": true
}
}
```
## Generazione di modelli di parametri
HealthOmics genera il modello di parametri analizzando la definizione del flusso di lavoro per rilevare i parametri di input. Se fornite un file modello di parametri per un flusso di lavoro, i parametri del file sostituiscono i parametri rilevati nella definizione del flusso di lavoro.
Esistono lievi differenze tra la logica di analisi dei motori CWL, WDL e Nextflow, come descritto nelle sezioni seguenti.
**Topics**
+ [Rilevamento dei parametri per CWL](#parameter-parsing-cwl)
+ [Rilevamento dei parametri per WDL](#parameter-parsing-wdl)
+ [Rilevamento dei parametri per Nextflow](#parameter-parsing-nextflow)
### Rilevamento dei parametri per CWL
Nel motore di workflow CWL, la logica di analisi si basa sui seguenti presupposti:
+ Tutti i tipi nullable supportati sono contrassegnati come parametri di input opzionali.
+ Tutti i tipi supportati non nulli sono contrassegnati come parametri di input obbligatori.
+ Tutti i parametri con valori predefiniti sono contrassegnati come parametri di input opzionali.
+ Le descrizioni vengono estratte dalla `label` sezione della definizione del `main` flusso di lavoro. Se non `label` è specificato, la descrizione sarà vuota (una stringa vuota).
Le tabelle seguenti mostrano esempi di interpolazione CWL. Per ogni esempio, il nome del parametro è. `x` Se il parametro è obbligatorio, è necessario fornire un valore per il parametro. Se il parametro è facoltativo, non è necessario fornire un valore.
Questa tabella mostra esempi di interpolazione CWL per tipi primitivi.
| Input | Esempio di input/output | Richiesto |
| --- | --- | --- |
| x:
type: int
| 1 o 2 o... | Sì |
| x:
type: int
default: 2
| Il valore predefinito è 2. L'input valido è 1 o 2 o... | No |
| x:
type: int?
| L'input valido è Nessuno o 1 o 2 o... | No |
| x:
type: int?
default: 2
| Il valore predefinito è 2. L'input valido è Nessuno o 1 o 2 o... | No |
La tabella seguente mostra esempi di interpolazione CWL per tipi complessi. Un tipo complesso è una raccolta di tipi primitivi.
| Input | Esempio di input/output | Richiesto |
| --- | --- | --- |
| x:
type: array
items: int
| [] o [1,2,3] | Sì |
| x:
type: array?
items: int
| Nessuno oppure [] o [1,2,3] | No |
| x:
type: array
items: int?
| [] o [Nessuno, 3, Nessuno] | Sì |
| x:
type: array?
items: int?
| [Nessuno] o Nessuno o [1,2,3] o [Nessuno, 3] ma non [] | No |
### Rilevamento dei parametri per WDL
Nel motore di workflow WDL, la logica di analisi si basa sui seguenti presupposti:
+ Tutti i tipi nullable supportati sono contrassegnati come parametri di input opzionali.
+ Per i tipi supportati che non possono essere annullati:
+ Qualsiasi variabile di input con assegnazione di valori letterali o espressioni è contrassegnata come parametri opzionali. Per esempio:
```
Int x = 2
Float f0 = 1.0 + f1
```
+ Se non sono stati assegnati valori o espressioni ai parametri di input, questi verranno contrassegnati come parametri obbligatori.
+ Le descrizioni vengono estratte dalla definizione `parameter_meta` del `main` flusso di lavoro. Se non `parameter_meta` è specificato, la descrizione sarà vuota (una stringa vuota). Per ulteriori informazioni, vedete la specifica WDL per i [metadati dei parametri](https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#metadata-sections).
Le tabelle seguenti mostrano esempi di interpolazione WDL. Per ogni esempio, il nome del parametro è. `x` Se il parametro è obbligatorio, è necessario fornire un valore per il parametro. Se il parametro è facoltativo, non è necessario fornire un valore.
Questa tabella mostra esempi di interpolazione WDL per tipi primitivi.
| Input | Esempio di input/output | Richiesto |
| --- | --- | --- |
| Int x | 1 o 2 o... | Sì |
| Int x = 2 | 2 | No |
| Intx = 1\$12 | 3 | No |
| Int x = y\$1z | y\$1z | No |
| Int? x | Nessuno o 1 o 2 o... | Sì |
| Int? x = 2 | Nessuno o 2 | No |
| Int? x = 1\$12 | Nessuno o 3 | No |
| Int? x = y\$1z | Nessuno o y\$1z | No |
La tabella seguente mostra esempi di interpolazione WDL per tipi complessi. Un tipo complesso è una raccolta di tipi primitivi.
| Input | Esempio di input/output | Richiesto |
| --- | --- | --- |
| Array [Int] x | [1,2,3] o [] | Sì |
| Matrice [Int] \$1 x | [1], ma non [] | Sì |
| Array [Int]? x | Nessuno o [] o [1,2,3] | No |
| Array [Int?] x | [] o [Nessuno, 3, Nessuno] | Sì |
| Array [Int?] =? x | [Nessuno] o Nessuno o [1,2,3] o [Nessuno, 3] ma non [] | No |
| Esempio di struttura \$1String a, Int y\$1 più avanti negli input: Sample MySample | String a = mySample.a
Int y = mySample.y
| Sì |
| Esempio di struttura \$1String a, Int y\$1 più avanti negli input: Sample? MySample | if (defined(mySample)) {
String a = mySample.a
Int y = mySample.y
} | No |
### Rilevamento dei parametri per Nextflow
Per Nextflow, HealthOmics genera il modello di parametro analizzando il file. `nextflow_schema.json` Se la definizione del flusso di lavoro non include un file di schema, HealthOmics analizza il file di definizione del flusso di lavoro principale.
**Topics**
+ [Analisi del file di schema](#parameter-parsing-nextflow-schema)
+ [Analisi del file principale](#parameter-parsing-nextflow-main)
+ [Parametri annidati](#parameter-parsing-nextflow-nested)
+ [Esempi di interpolazione Nextflow](#parameter-parsing-nextflow-examples)
#### Analisi del file di schema
Affinché l'analisi funzioni correttamente, assicurati che il file di schema soddisfi i seguenti requisiti:
+ Il file di schema è denominato `nextflow_schema.json` e si trova nella stessa directory del file di workflow principale.
+ Il file di schema è JSON valido come definito in uno dei seguenti schemi:
+ [schema json. org/draft/2020-12/schema](https://json-schema.org/draft/2020-12/schema).
+ [schema json. org/draft-07/schema](https://json-schema.org/draft-07/schema).
HealthOmics analizza il `nextflow_schema.json` file per generare il modello di parametro:
+ Estrae tutto ciò **properties** che è definito nello schema.
+ Include la proprietà **description** se disponibile per la proprietà.
+ Identifica se ogni parametro è facoltativo o obbligatorio, in base al **required** campo della proprietà.
L'esempio seguente mostra un file di definizione e il file dei parametri generato.
```
{
"$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" }
]
}
```
Il modello di parametro generato:
```
{
"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
}
}
```
#### Analisi del file principale
Se la definizione del flusso di lavoro non include un `nextflow_schema.json` file, HealthOmics analizza il file di definizione del flusso di lavoro principale.
HealthOmics analizza le `params` espressioni presenti nel file di definizione del flusso di lavoro principale e nel `nextflow.config` file. Tutte le `params` versioni con valori predefiniti sono contrassegnate come opzionali.
Affinché l'analisi funzioni correttamente, tieni presente i seguenti requisiti:
+ HealthOmics analizza solo il file di definizione del flusso di lavoro principale. Per garantire che tutti i parametri vengano acquisiti, ti consigliamo di collegarlo a tutti **params** i sottomoduli e ai flussi di lavoro importati.
+ Il file di configurazione è facoltativo. Se ne definite uno, assegnategli un nome `nextflow.config` e inseritelo nella stessa directory del file di definizione del flusso di lavoro principale.
L'esempio seguente mostra un file di definizione e il modello di parametri generato.
```
params.input_file = "default.txt"
params.threads = 4
params.memory = "8GB"
workflow {
if (params.version) {
println "Using version: ${params.version}"
}
}
```
Il modello di parametro generato:
```
{
"input_file": {
"description": None,
"optional": True
},
"threads": {
"description": None,
"optional": True
},
"memory": {
"description": None,
"optional": True
},
"version": {
"description": None,
"optional": False
}
}
```
Per i valori predefiniti definiti in nextflow.config, HealthOmics raccoglie le `params` assegnazioni e i parametri dichiarati all'interno`params {}`, come illustrato nell'esempio seguente. Nelle istruzioni di assegnazione, `params` deve apparire nella parte sinistra dell'istruzione.
```
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}"
```
Il modello di parametro generato:
```
{
// 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
}
}
```
#### Parametri annidati
Entrambi `nextflow.config` consentono `nextflow_schema.json` parametri annidati. Tuttavia, il modello di HealthOmics parametri richiede solo i parametri di primo livello. Se il flusso di lavoro utilizza un parametro annidato, è necessario fornire un oggetto JSON come input per quel parametro.
##### Parametri annidati nei file di schema
HealthOmics salti annidati **params** durante l'analisi di un file. `nextflow_schema.json` Ad esempio, se si definisce il seguente file: `nextflow_schema.json`
```
{
"properties": {
"input": {
"properties": {
"input_file": { ... },
"input_num": { ... }
}
},
"input_bool": { ... }
}
}
```
HealthOmics ignora `input_file` e `input_num` quando genera il modello di parametro:
```
{
"input": {
"description": None,
"optional": True
},
"input_bool": {
"description": None,
"optional": True
}
}
```
Quando si esegue questo flusso di lavoro, HealthOmics si aspetta un `input.json` file simile al seguente:
```
{
"input": {
"input_file": "s3://bucket/obj",
"input_num": 2
},
"input_bool": false
}
```
##### Parametri annidati nei file di configurazione
HealthOmics non raccoglie i dati annidati **params** in un `nextflow.config` file e li salta durante l'analisi. Ad esempio, se definisci il seguente file: `nextflow.config`
```
params.alpha = "alpha"
params.nested.beta = "beta"
params {
gamma = "gamma"
group {
delta = "delta"
}
}
```
HealthOmics ignora `params.nested.beta` e `params.group.delta` quando genera il modello di parametro:
```
{
"alpha": {
"description": None,
"optional": True
},
"gamma": {
"description": None,
"optional": True
}
}
```
#### Esempi di interpolazione Nextflow
La tabella seguente mostra esempi di interpolazione Nextflow per i parametri nel file principale.
| Parametri | Richiesto |
| --- | --- |
| params.input\$1file | Sì |
| params.input\$1file = "s3://bucket/data.json» | No |
| params.nested.input\$1file | N/D |
| params.nested.input\$1file = "s3://bucket/data.json» | N/D |
La tabella seguente mostra esempi di interpolazione Nextflow per i parametri nel file. `nextflow.config`
| Parametri | Richiesto |
| --- | --- |
| params.input_file = "s3://bucket/data.json"
| No |
| params {
input_file = "s3://bucket/data.json"
} | No |
| params {
nested {
input_file = "s3://bucket/data.json"
}
} | N/D |
| input_file = params.input_file
| N/D |
# Immagini di container per flussi di lavoro privati
HealthOmics supporta immagini di container ospitate in repository privati di Amazon ECR. Puoi creare immagini di contenitori e caricarle nel repository privato. Puoi anche utilizzare il tuo registro privato Amazon ECR come cache pull through per sincronizzare il contenuto dei registri upstream.
Il tuo repository Amazon ECR deve risiedere nella stessa AWS regione dell'account che chiama il servizio. L'immagine del contenitore Account AWS può essere di proprietà di un altro soggetto, a condizione che l'archivio delle immagini di origine fornisca le autorizzazioni appropriate. Per ulteriori informazioni, consulta [Politiche per l'accesso ad Amazon ECR su più account](permissions-ecr.md#permissions-cross-account).
Ti consigliamo di definire l'immagine del contenitore Amazon ECR URIs come parametri del flusso di lavoro in modo che l'accesso possa essere verificato prima dell'inizio dell'esecuzione. Inoltre, semplifica l'esecuzione di un flusso di lavoro in una nuova regione modificando il parametro Region.
**Nota**
HealthOmics non supporta i contenitori ARM e non supporta l'accesso agli archivi pubblici.
Per informazioni sulla configurazione delle autorizzazioni IAM per l'accesso HealthOmics ad Amazon ECR, consulta. [HealthOmics Autorizzazioni per le risorse](permissions-resource.md)
**Topics**
+ [Sincronizzazione con registri di container di terze parti](#ecr-pull-through)
+ [Considerazioni generali per le immagini dei container Amazon ECR](#ecr-considerations)
+ [Variabili di ambiente per i flussi HealthOmics di lavoro](#ecr-env-vars)
+ [Utilizzo di Java nelle immagini dei container Amazon ECR](#ecr-java-considerations)
+ [Aggiungi input di attività a un'immagine del contenitore Amazon ECR](#ecr-tasks)
## Sincronizzazione con registri di container di terze parti
Puoi utilizzare le regole pull through cache di Amazon ECR per sincronizzare i repository in un registro upstream supportato con i tuoi repository privati Amazon ECR. Per ulteriori informazioni, consulta [Sincronizzare un registro upstream](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html) nella *Amazon ECR User Guide.*
La cache pull through crea automaticamente l'archivio di immagini nel registro privato al momento della creazione della cache e si sincronizza automaticamente con l'immagine memorizzata nella cache in caso di modifiche all'immagine upstream.
HealthOmics supporta la cache pull through per i seguenti registri upstream:
+ Amazon ECR Public
+ Registro delle immagini del contenitore Kubernetes
+ Quay
+ Docker Hub
+ Microsoft Azure Container Registry
+ GitHub Registro dei contenitori
+ GitLab Registro dei contenitori
HealthOmics non supporta la cache pull through per un repository privato Amazon ECR upstream.
I vantaggi dell'utilizzo della cache pull through di Amazon ECR includono:
1. Evita di dover migrare manualmente le immagini dei container su Amazon ECR o sincronizzare gli aggiornamenti dal repository di terze parti.
1. I flussi di lavoro accedono alle immagini sincronizzate dei contenitori nel tuo repository privato, che è più affidabile rispetto al download di contenuti in fase di esecuzione da un registro pubblico.
1. Poiché le cache pull through di Amazon ECR utilizzano una struttura URI prevedibile, il HealthOmics servizio può mappare automaticamente l'URI privato di Amazon ECR con l'URI del registro upstream. Non è necessario aggiornare e sostituire i valori URI nella definizione del flusso di lavoro.
**Topics**
+ [Configurazione della cache pull through](#ecr-pull-through-configure)
+ [Mappature del registro](#ecr-pull-through-registry-mapping)
+ [Mappature delle immagini](#ecr-pull-through-mapping-format)
### Configurazione della cache pull through
Amazon ECR fornisce un registro per ogni Account AWS regione. Assicurati di creare la configurazione Amazon ECR nella stessa regione in cui intendi eseguire il flusso di lavoro.
Le seguenti sezioni descrivono le attività di configurazione per il pull through cache.
**Topics**
+ [Crea una regola pull through cache](#create-ecr-ptc)
+ [Autorizzazioni di registro per il registro upstream](#reg-ecr-ptc)
+ [Modelli per la creazione di repository](#repo-create-templates-ptc)
+ [Creazione del flusso di lavoro](#reg-mapping-ecr-ptc)
#### Crea una regola pull through cache
Crea una regola pull through cache di Amazon ECR per ogni registro upstream contenente immagini che desideri memorizzare nella cache. Una regola specifica una mappatura tra un registro upstream e l'archivio privato Amazon ECR.
Per un registro upstream che richiede l'autenticazione, fornisci le tue credenziali utilizzando AWS Secrets Manager.
**Nota**
Non modificare una regola di pull through cache mentre un'esecuzione attiva utilizza il repository privato. L'esecuzione potrebbe fallire o, cosa ancora più importante, far sì che la pipeline utilizzi immagini inaspettate.
Per ulteriori informazioni, consulta [Creazione di una regola pull through cache](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) nella *Amazon Elastic Container Registry User Guide*.
##### Crea una regola pull through cache utilizzando la console
Per configurare la cache pull through, segui questi passaggi utilizzando la console Amazon ECR:
1. Apri la console Amazon ECR: https://console.aws.amazon.com /ecr
1. Dal menu a sinistra, in **Registro privato**, espandi **Caratteristiche e impostazioni**, quindi scegli **Pull** through cache.
1. Dalla pagina **Pull through cache**, scegli **Aggiungi regola**.
1. **Nel pannello del **registro Upstream**, scegli il registro upstream da sincronizzare con il registro privato, quindi scegli Avanti.**
1. Se il registro upstream richiede l'autenticazione, la console apre una nuova pagina in cui specifichi il segreto SageMaker AI che contiene le tue credenziali. Scegli **Next (Successivo)**.
1. In **Specificate namespaces**, nel pannello **Cache namespace**, scegliete se creare i repository privati utilizzando un prefisso di repository specifico o senza prefisso. **Se scegliete di utilizzare un prefisso, specificate il nome del prefisso nel prefisso del repository Cache.**
1. Nel pannello dello spazio dei **nomi Upstream**, scegliete se estrarre dai repository upstream utilizzando un prefisso di repository specifico o senza prefisso. **Se scegliete di utilizzare un prefisso, specificate il nome del prefisso nel prefisso del repository Upstream.**
Il pannello di esempio **Namespace mostra un esempio** di pull request, un URL upstream e l'URL del cache repository che viene creato.
1. Scegli **Next (Successivo)**.
1. Rivedi la configurazione e scegli **Crea per creare** la regola.
Per ulteriori informazioni, consulta [Creare una regola pull through cache (AWS Management Console)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-console).
##### Crea una regola pull through cache utilizzando la CLI
Usa il **create-pull-through-cache-rule** comando Amazon ECR per creare una regola pull through cache. Per i registri upstream che richiedono l'autenticazione, memorizzate le credenziali in un segreto di Secrets Manager.
Le sezioni seguenti forniscono esempi per ogni registro upstream supportato.
##### Per Amazon ECR Public
L'esempio seguente crea una regola di cache pull-through per il registro pubblico di Amazon ECR. Specifica un prefisso di `ecr-public`, che fa sì che ciascun repository creato utilizzando la regola della cache pull-through abbia lo schema di denominazione di `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
```
##### Per Kubernetes Container Registry
L'esempio seguente crea una regola di cache pull through per il registro pubblico Kubernetes. Specifica un prefisso di `kubernetes`, che fa sì che ciascun repository creato utilizzando la regola della cache pull-through abbia lo schema di denominazione di `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
```
##### Per Quay
L'esempio seguente crea una regola di cache pull-through per il registro pubblico Quay. Specifica un prefisso di `quay`, che fa sì che ciascun repository creato utilizzando la regola della cache pull-through abbia lo schema di denominazione di `quay/upstream-repository-name`.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix quay \
--upstream-registry-url quay.io \
--region us-east-1
```
##### Per Docker Hub
L'esempio seguente crea una regola di cache pull-through per il registro Docker Hub. Specifica un prefisso di `docker-hub`, che fa sì che ciascun repository creato utilizzando la regola della cache pull-through abbia lo schema di denominazione di `docker-hub/upstream-repository-name`. Devi specificare nella sua interezza il nome della risorsa Amazon (ARN) del segreto contenente le credenziali di 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
```
##### Per Container Registry GitHub
L'esempio seguente crea una regola pull through cache per il GitHub Container Registry. Specifica un prefisso di `github`, che fa sì che ciascun repository creato utilizzando la regola della cache pull-through abbia lo schema di denominazione di `github/upstream-repository-name`. È necessario specificare l'Amazon Resource Name (ARN) completo del segreto contenente le credenziali del GitHub Container Registry.
```
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
```
##### Per Microsoft Azure Container Registry
L'esempio seguente crea una regola pull through cache per il Microsoft Azure Container Registry. Specifica un prefisso di `azure`, che fa sì che ciascun repository creato utilizzando la regola della cache pull-through abbia lo schema di denominazione di `azure/upstream-repository-name`. Devi specificare nella sua interezza il nome della risorsa Amazon (ARN) del segreto contenente le credenziali di Microsoft 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
```
##### Per GitLab Container Registry
L'esempio seguente crea una regola pull through cache per il GitLab Container Registry. Specifica un prefisso di `gitlab`, che fa sì che ciascun repository creato utilizzando la regola della cache pull-through abbia lo schema di denominazione di `gitlab/upstream-repository-name`. È necessario specificare l'Amazon Resource Name (ARN) completo del segreto contenente le credenziali del GitLab Container Registry.
```
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
```
Per ulteriori informazioni, consulta [Create a pull through cache rule (CLI)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-cli) nella *Amazon ECR* User Guide.
È possibile utilizzare il comando **get-run-task** CLI per recuperare informazioni sull'immagine del contenitore utilizzata per un'attività specifica:
```
aws omics get-run-task --id 1234567 --task-id
```
L'output include le seguenti informazioni sull'immagine del contenitore:
```
"imageDetails": {
"image": "string",
"imageDigest": "string",
"sourceImage": "string",
...
}
```
#### Autorizzazioni di registro per il registro upstream
Utilizza le autorizzazioni di registro HealthOmics per consentire l'utilizzo della cache pull through e per inserire le immagini del contenitore nel registro privato di Amazon ECR. Aggiungi una policy del registro Amazon ECR al registro che fornisce i contenitori utilizzati nelle esecuzioni.
La seguente policy concede al HealthOmics servizio l'autorizzazione a creare repository con i prefissi pull through cache specificati e ad avviare recuperi upstream in questi repository.
1. Dalla console Amazon ECR, apri il menu a sinistra, in **Registro privato**, espandi **le autorizzazioni del registro**, quindi scegli **Genera** dichiarazione.
1. In alto a destra, scegli JSON. Inserisci una politica simile alla seguente:
------
#### [ 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/*"
]
}
]
}
```
------
#### Modelli per la creazione di repository
Per utilizzare il pull through caching in HealthOmics, il repository Amazon ECR deve disporre di un modello di creazione del repository. Il modello definisce le impostazioni di configurazione per quando tu o Amazon ECR create un repository privato per un registro upstream.
Ogni modello contiene un prefisso dello spazio dei nomi del repository, che Amazon ECR utilizza per abbinare i nuovi repository a un modello specifico. I modelli specificano la configurazione per tutte le impostazioni del repository, comprese le politiche di accesso basate sulle risorse, l'immutabilità dei tag, la crittografia e le politiche del ciclo di vita.
Per ulteriori informazioni, consulta [Modelli di creazione di repository](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) nella *Amazon Elastic Container Registry User Guide*.
Come creare un modello per la creazione di un repository:
1. Dalla console Amazon ECR, apri il menu a sinistra, in **Registro privato**, espandi **Caratteristiche e impostazioni**, quindi scegli Modelli di **creazione di repository**.
1. Scegli **Crea modello**.
1. Nei **dettagli del modello**, scegli **Pull through cache**.
1. Scegli se applicare questo modello a un prefisso specifico o a tutti i repository che non corrispondono a un altro modello.
**Se scegli **Un prefisso specifico, inserisci il valore del prefisso** dello spazio dei nomi in Prefisso.** Avete specificato questo prefisso quando avete creato la regola PTC.
1. Scegli **Next (Successivo)**.
1. **Nella pagina **Aggiungi configurazione per la creazione del repository**, immettete le autorizzazioni per la creazione del repository.** Utilizza una delle istruzioni politiche di esempio o inseriscine una simile all'esempio seguente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PTCRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
1. Facoltativamente, puoi aggiungere impostazioni del repository come i criteri del ciclo di vita e i tag. Amazon ECR applica queste regole a tutte le immagini di container create per la cache pull through che utilizzano il prefisso specificato.
1. Scegli **Next (Successivo)**.
1. **Controlla la configurazione e scegli Avanti.**
#### Creazione del flusso di lavoro
Quando crei un nuovo flusso di lavoro o una nuova versione del flusso di lavoro, rivedi i mapping del registro e aggiornali se necessario. Per informazioni dettagliate, vedi [Creare un flusso di lavoro privato](create-private-workflow.md).
### Mappature del registro
Definisci le mappature del registro da mappare tra i prefissi nel tuo registro Amazon ECR privato e i nomi del registro upstream.
Per ulteriori informazioni sulle mappature del registro Amazon ECR, consulta [Creazione di una regola pull through cache in Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) ECR.
L'esempio seguente mostra le mappature del registro su Docker Hub, Quay e Amazon ECR Public.
```
{
"registryMappings": [
{
"upstreamRegistryUrl": "registry-1.docker.io",
"ecrRepositoryPrefix": "docker-hub"
},
{
"upstreamRegistryUrl": "quay.io",
"ecrRepositoryPrefix": "quay"
},
{
"upstreamRegistryUrl": "public.ecr.aws",
"ecrRepositoryPrefix": "ecr-public"
}
]
}
```
### Mappature delle immagini
Definisci le mappature delle immagini da mappare tra i nomi delle immagini definiti nei flussi di lavoro privati di Amazon ECR e i nomi delle immagini nel registro upstream.
Puoi utilizzare le mappature delle immagini con registri che supportano la cache pull through. È inoltre possibile utilizzare le mappature delle immagini con registri upstream che non supportano il pull through cache. HealthOmics È necessario sincronizzare manualmente il registro upstream con il repository privato.
Per ulteriori informazioni sulle mappature delle immagini di Amazon ECR, consulta [Creazione di una regola pull through cache in Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) ECR.
L'esempio seguente mostra le mappature da immagini private di Amazon ECR a un'immagine genomica pubblica e all'ultima immagine di 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",
}
]
}
```
## Considerazioni generali per le immagini dei container Amazon ECR
+ Architecture
HealthOmics supporta contenitori x86\$164. Se il computer locale è basato su ARM, come Apple Mac, usa un comando come il seguente per creare un'immagine del contenitore x86\$164:
```
docker build --platform amd64 -t my_tool:latest .
```
+ Entrypoint e shell
HealthOmics i motori di workflow iniettano gli script di bash come comando che sostituiscono le immagini dei contenitori utilizzate dalle attività del flusso di lavoro. Pertanto, le immagini dei contenitori dovrebbero essere create senza un ENTRYPOINT specificato in modo tale che una shell bash sia l'impostazione predefinita.
+ Percorsi montati
Un filesystem condiviso viene montato sulle attività del contenitore in /tmp. Tutti i dati o gli strumenti incorporati nell'immagine del contenitore in questa posizione verranno sovrascritti.
La definizione del flusso di lavoro è disponibile per le attività tramite un montaggio in sola lettura in /mnt/workflow.
+ Dimensione dell’immagine
Vedi per le dimensioni massime delle immagini dei contenitori. [HealthOmics quote a dimensione fissa per il flusso di lavoro](fixed-quotas.md#fixed-quotas-workflows)
## Variabili di ambiente per i flussi HealthOmics di lavoro
HealthOmics fornisce variabili di ambiente che contengono informazioni sul flusso di lavoro in esecuzione nel contenitore. È possibile utilizzare i valori di queste variabili nella logica delle attività del flusso di lavoro.
Tutte le variabili HealthOmics del flusso di lavoro iniziano con il `AWS_WORKFLOW_` prefisso. Questo prefisso è un prefisso di variabile di ambiente protetto. Non utilizzate questo prefisso per le vostre variabili nei contenitori del flusso di lavoro.
HealthOmics fornisce le seguenti variabili di ambiente di flusso di lavoro:
**AWS\$1REGION**
Questa variabile è la regione in cui è in esecuzione il contenitore.
**AWS\$1WORKFLOW\$1ESEGUI**
Questa variabile è il nome dell'esecuzione corrente.
**AWS\$1WORKFLOW\$1RUN\$1ID**
Questa variabile è l'identificatore di esecuzione della corsa corrente.
**AWS\$1WORKFLOW\$1RUN\$1UUID**
Questa variabile è l'UUID di esecuzione dell'esecuzione corrente.
**AWS\$1WORKFLOW\$1ATTIVITÀ**
Questa variabile è il nome dell'attività corrente.
**AWS\$1WORKFLOW\$1TASK\$1ID**
Questa variabile è l'identificatore dell'attività corrente.
**AWS\$1WORKFLOW\$1TASK\$1UUID**
Questa variabile è l'UUID dell'attività corrente.
L'esempio seguente mostra i valori tipici per ogni variabile di ambiente:
```
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
```
## Utilizzo di Java nelle immagini dei container Amazon ECR
Se un'attività di workflow utilizza un'applicazione Java come GATK, considera i seguenti requisiti di memoria per il contenitore:
+ Le applicazioni Java utilizzano la memoria stack e la memoria heap. Per impostazione predefinita, la memoria heap massima è una percentuale della memoria totale disponibile nel contenitore. Questa impostazione predefinita dipende dalla distribuzione JVM specifica e dalla versione JVM, quindi consulta la documentazione pertinente per la tua JVM o imposta esplicitamente il massimo della memoria heap utilizzando le opzioni della riga di comando Java (come `-Xmx`).
+ Non impostate che la memoria heap massima sia pari al 100% dell'allocazione di memoria del contenitore, poiché anche lo stack JVM richiede memoria. La memoria è richiesta anche per il Garbage Collector JVM e per qualsiasi altro processo del sistema operativo in esecuzione nel contenitore.
+ Alcune applicazioni Java, come GATK, possono utilizzare invocazioni di metodi nativi o altre ottimizzazioni come i file di mappatura della memoria. Queste tecniche richiedono allocazioni di memoria eseguite «off heap», che non sono controllate dal parametro JVM maximum heap.
Se sai (o sospetti) che la tua applicazione Java alloca memoria off-heap, assicurati che l'allocazione della memoria delle attività includa i requisiti di memoria off-heap.
Se queste allocazioni off-heap causano l'esaurimento della memoria nel contenitore, in genere non viene visualizzato un **OutOfMemory** errore Java, perché la JVM non controlla questa memoria.
## Aggiungi input di attività a un'immagine del contenitore Amazon ECR
Aggiungi tutti gli eseguibili, le librerie e gli script necessari per eseguire un'attività di workflow nell'immagine Amazon ECR utilizzata per eseguire l'attività.
È consigliabile evitare l'uso di script, file binari e librerie esterni all'immagine del contenitore di attività. Ciò è particolarmente importante quando si utilizzano `nf-core` flussi di lavoro che utilizzano una `bin` directory come parte del pacchetto workflow. Sebbene questa directory sia disponibile per l'attività del flusso di lavoro, viene montata come directory di sola lettura. Le risorse richieste in questa directory devono essere copiate nell'immagine dell'attività e rese disponibili in fase di esecuzione o durante la creazione dell'immagine del contenitore utilizzata per l'attività.
Vedi [HealthOmics quote a dimensione fissa per il flusso di lavoro](fixed-quotas.md#fixed-quotas-workflows) la dimensione massima dell'immagine del contenitore HealthOmics supportata.
# HealthOmics File README del flusso di lavoro
Puoi caricare un file README.md contenente istruzioni, diagrammi e informazioni essenziali per il tuo flusso di lavoro. Ogni versione del flusso di lavoro supporta un file README, che è possibile aggiornare in qualsiasi momento.
**I requisiti README includono:**
+ Il file README deve essere in formato markdown (.md)
+ Dimensione massima del file: 500 KiB
**Topics**
+ [Usa un file README esistente](#workflows-add-readme)
+ [Condizioni di rendering](#workflows-rendering-readme)
## Usa un file README esistente
READMEs i file esportati dai repository Git contengono collegamenti relativi che in genere non funzionano al di fuori del repository. HealthOmics L'integrazione con Git li converte automaticamente in link assoluti per un corretto rendering nella console, eliminando la necessità di aggiornamenti manuali degli URL.
Per l' READMEs importazione da Amazon S3 o da unità locali, le immagini e i link devono essere pubblici URLs o avere i relativi percorsi aggiornati per un rendering corretto.
**Nota**
Le immagini devono essere ospitate pubblicamente per essere visualizzate nella HealthOmics console. Le immagini archiviate nei GitHub Enterprise Server nostri GitLab Self-Managed archivi non possono essere renderizzate.
## Condizioni di rendering
La HealthOmics console interpola immagini e collegamenti accessibili al pubblico utilizzando percorsi assoluti. Per eseguire il rendering URLs da archivi privati, l'utente deve avere accesso al repository. I nostri GitHub Enterprise Server GitLab Self-Managed repository, che utilizzano domini personalizzati, HealthOmics non possono risolvere collegamenti relativi o eseguire il rendering di immagini archiviate in questi archivi privati.
La tabella seguente mostra gli elementi markdown supportati dalla visualizzazione README della AWS console.
| Elemento | AWS console |
| --- | --- |
| Avvisi | Sì, ma senza icone |
| Distintivi | Sì |
| Formattazione di base del testo | Sì |
| [Blocchi di codice](https://www.markdownguide.org/basic-syntax/#code-blocks) | Sì, ma non dispone della funzionalità di [evidenziazione della sintassi](https://www.markdownguide.org/extended-syntax/#syntax-highlighting) e del pulsante di copia |
| Sezioni pieghevoli | Sì |
| [Titoli](https://www.markdownguide.org/basic-syntax/#headings) | Sì |
| [Formati di immagine](https://www.markdownguide.org/basic-syntax/#images-1) | Sì |
| [Immagine (cliccabile)](https://www.markdownguide.org/basic-syntax/#linking-images) | Sì |
| [Interruzioni di riga](https://www.markdownguide.org/basic-syntax/#line-breaks) | Sì |
| Diagramma a sirena | Solo può aprire il grafico, spostare la posizione del grafico e copiare il codice |
| Preventivi | Sì |
| [https://www.markdownguide.org/extended-syntax/#subscript](https://www.markdownguide.org/extended-syntax/#subscript) | Sì |
| [Tabelle](https://www.markdownguide.org/extended-syntax/#tables) | Sì, ma non supporta l'allineamento del testo |
| Allineamento del testo | Sì |
### Utilizzo di immagini e link URLs
A seconda del provider di origine, struttura la base URLs per pagine e immagini nei seguenti formati.
+ `{username}`: il nome utente in cui è ospitato il repository.
+ `{repo}`: il nome del repository.
+ `{ref}`: il riferimento alla fonte (branch, tag e commit ID).
+ `{path}`: il percorso del file alla pagina o all'immagine nel repository.
| Provider di origine | URL della pagina | URL dell'immagine |
| --- | --- | --- |
| 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, e Bitbucket supporta sia la pagina URLs che l'immagine che rimandano a un archivio pubblico. La tabella seguente mostra il supporto di ciascun fornitore di sorgenti per il rendering di immagini e collegamenti URLs per repository privati.
| Supporto per repository privati | Provider di origine | URL della pagina | URL dell'immagine |
| --- | --- | --- | --- |
| GitHub | Solo con accesso al repository | No |
| GitLab | Solo con accesso al repository | No |
| Bitbucket | Solo con accesso al repository | No |
# Richiesta di licenze Sentieon per flussi di lavoro privati
Se il tuo flusso di lavoro privato utilizza il software Sentieon, hai bisogno di una licenza Senieon. Segui questi passaggi per richiedere e configurare una licenza per il software Sentieon:
+ Richiedi una licenza Sentieon
+ Invia un'e-mail al gruppo di supporto Sentieon (support@sentieon.com) per richiedere una licenza software.
+ Fornisci il tuo ID utente AWS Canonical nell'e-mail.
+ [Trova il tuo ID utente AWS Canonical seguendo queste istruzioni.](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId)
+ Aggiorna il tuo ruolo HealthOmics di servizio per concedergli l'accesso al proxy del server di licenza Sentieon e al bucket Sentieon Omics nella tua regione. L'esempio seguente concede l'accesso a. `us-east-1` Se necessario, sostituisci questo testo con la tua regione.
------
#### [ 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/*"
]
}
]
}
```
------
+ Genera una AWS richiesta di supporto per accedere al proxy del server di licenza Sentieon.
+ [Per creare una richiesta di supporto, accedi a support.console.aws.amazon.com.](https://support.console.aws.amazon.com)
+ Fornisci la tua e la regione nella richiesta di assistenza. Account AWS Il tuo account viene aggiunto alla lista consentita per il proxy del server di licenza.
+ Crea il tuo flusso di lavoro privato utilizzando il contenitore Sentieon e lo script di licenza Sentieon.
+ [Per ulteriori istruzioni sull'uso degli strumenti Sentieon all'interno di flussi di lavoro privati, consulta Sentieon-Amazon-Omics in.](https://github.com/Sentieon/sentieon-amazon-omics) GitHub
+ La versione del software Sentieon 202112.07 e successive supportano il proxy del server di licenza. HealthOmics Per utilizzare le versioni del software Sentieon precedenti alla 202112.07, contatta l'assistenza Sentieon.
# Stampanti per flussi di lavoro in HealthOmics
Dopo aver creato un flusso di lavoro, ti consigliamo di eseguire un linter sul flusso di lavoro prima di iniziare la prima esecuzione. Il linter rileva gli errori che possono causare il fallimento dell'esecuzione.
Per WDL, esegue HealthOmics automaticamente un linter quando si crea il flusso di lavoro. L'output del linter è disponibile nel `statusMessage` campo della risposta. **get-workflow** Utilizzate il seguente comando CLI per recuperare l'output di stato (utilizzate l'ID del flusso di lavoro WDL che avete creato):
```
aws omics get-workflow
—id 123456
—query 'statusMessage'
```
HealthOmics fornisce linter che è possibile eseguire sulla definizione del flusso di lavoro prima di creare il flusso di lavoro. Esegui questi linter sulle pipeline esistenti verso cui stai migrando. HealthOmics
+ **WDL**— Un'immagine Amazon ECR pubblica per eseguire un linter [WDL](https://gallery.ecr.aws/aws-genomics/healthomics-linter).
+ **Nextflow**— Un'immagine Amazon ECR pubblica per eseguire le [regole Linter per]( https://gallery.ecr.aws/aws-genomics/linter-rules-for-nextflow) Nextflow. Puoi accedere al codice sorgente di questo linter da. [GitHub](https://github.com/awslabs/linter-rules-for-nextflow)
+ **CWL**— non disponibile
# HealthOmics operazioni del flusso di lavoro
Per creare un flusso di lavoro privato, devi:
+ **Workflow definition file:**Un file di definizione del flusso di lavoro scritto in WDLNextflow, oCWL. La definizione del flusso di lavoro specifica gli input e gli output per le esecuzioni che utilizzano il flusso di lavoro. Include inoltre le specifiche per le attività di esecuzione ed esecuzione del flusso di lavoro, inclusi i requisiti di calcolo e memoria. Il file di definizione del flusso di lavoro deve essere in `.zip` formato. Per ulteriori informazioni, vedere [File di definizione del flusso](workflow-definition-files.md) di lavoro in HealthOmics.
+ Puoi utilizzare [Amazon Q CLI per creare e convalidare i](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) file di definizione del flusso di lavoro in WDL, Nextflow e CWL. Per ulteriori informazioni, consulta le [istruzioni di esempio per la CLI di Amazon Q](getting-started.md#omics-q-prompts) e il tutorial sull'intelligenza artificiale generativa [HealthOmics Agentic](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) su. GitHub
+ **(Optional) Parameter template file:**Un file modello di parametro scritto in. JSON Crea il file per definire i parametri di esecuzione o HealthOmics genera automaticamente il modello dei parametri. Per ulteriori informazioni, consultate [File modello di parametri per i HealthOmics flussi di lavoro](parameter-templates.md).
+ **Amazon ECR container images:**Crea repository Amazon ECR privati per ogni contenitore utilizzato nel flusso di lavoro. Crea immagini di container per il flusso di lavoro e memorizzale in un repository privato oppure sincronizza il contenuto di un registro upstream supportato con il tuo repository privato ECR.
+ **(Optional) Sentieon licenses:**Richiedi una Sentieon licenza per utilizzare il software in flussi di lavoro privatiSentieon.
Per i file di definizione del flusso di lavoro più grandi di 4 MiB (compressi), scegli una di queste opzioni durante la creazione del flusso di lavoro:
+ Carica in una cartella Amazon Simple Storage Service e specifica la posizione.
+ Carica su un repository esterno (dimensione massima 1 GiB) e specifica i dettagli del repository.
Dopo aver creato un flusso di lavoro, è possibile aggiornare le seguenti informazioni sul flusso di lavoro con l'operazione: `UpdateWorkflow`
+ Nome
+ Description
+ Tipo di archiviazione predefinito
+ Capacità di archiviazione predefinita (con ID del flusso di lavoro)
+ File README.md
Per modificare altre informazioni nel flusso di lavoro, crea un nuovo flusso di lavoro o una nuova versione del flusso di lavoro.
Utilizza il controllo delle versioni del flusso di lavoro per organizzare e strutturare i flussi di lavoro. Le versioni consentono inoltre di gestire l'introduzione di aggiornamenti iterativi del flusso di lavoro. Per ulteriori informazioni sulle versioni, consulta [Creare una versione del flusso di lavoro](workflows-version-create.md).
**Topics**
+ [Creare un flusso di lavoro privato](create-private-workflow.md)
+ [Aggiornare un flusso di lavoro privato](update-private-workflow.md)
+ [Eliminare un flusso di lavoro privato](delete-private-workflow.md)
+ [Verifica lo stato del flusso di lavoro](using-get-workflow.md)
+ [Riferimento ai file del genoma da una definizione di workflow](create-ref-files.md)
# Creare un flusso di lavoro privato
Crea un flusso di lavoro utilizzando la HealthOmics console, i comandi AWS CLI o uno dei. AWS SDKs
**Nota**
Non includere informazioni di identificazione personale (PII) nei nomi dei flussi di lavoro. Questi nomi sono visibili nei CloudWatch registri.
Quando crei un flusso di lavoro, HealthOmics assegna un identificatore univoco universale (UUID) al flusso di lavoro. L'UUID del flusso di lavoro è un identificatore univoco globale (GUID) unico per i flussi di lavoro e le versioni del flusso di lavoro. Ai fini della provenienza dei dati, si consiglia di utilizzare l'UUID del flusso di lavoro per identificare in modo univoco i flussi di lavoro.
Se le attività del flusso di lavoro utilizzano strumenti esterni (eseguibili, librerie o script), questi strumenti vengono incorporati in un'immagine contenitore. Sono disponibili le seguenti opzioni per ospitare l'immagine del contenitore:
+ Ospita l'immagine del contenitore nel registro privato ECR. Prerequisiti per questa opzione:
+ Crea un archivio privato ECR o scegli un repository esistente.
+ Configurare la politica delle risorse ECR come descritto in. [Autorizzazioni Amazon ECR](permissions-ecr.md)
+ Carica l'immagine del contenitore nell'archivio privato.
+ Sincronizza l'immagine del contenitore con il contenuto di un registro di terze parti supportato. Prerequisiti per questa opzione:
+ Nel registro privato ECR, configura una regola pull through cache per ogni registro upstream. Per ulteriori informazioni, consulta [Mappature delle immagini](workflows-ecr.md#ecr-pull-through-mapping-format).
+ Configura la politica delle risorse ECR come descritto in. [Autorizzazioni Amazon ECR](permissions-ecr.md)
+ Crea modelli per la creazione di repository. Il modello definisce le impostazioni per quando Amazon ECR crea l'archivio privato per un registro upstream.
+ Crea mappature di prefissi per rimappare i riferimenti alle immagini dei contenitori nella definizione del flusso di lavoro ai namespace della cache ECR.
Quando si crea un flusso di lavoro, si fornisce una definizione del flusso di lavoro che contiene informazioni sul flusso di lavoro, sulle esecuzioni e sulle attività. HealthOmics può recuperare la definizione del flusso di lavoro come archivio.zip archiviato localmente o in un bucket Amazon S3 o da un repository basato su Git supportato.
**Topics**
+ [Creare un flusso di lavoro utilizzando la console](#console-create-workflows)
+ [Creazione di un flusso di lavoro utilizzando la CLI](#api-create-workflows)
+ [Creazione di un flusso di lavoro utilizzando un SDK](#sdk-create-workflows)
## Creare un flusso di lavoro utilizzando la console
**Passaggi per creare un flusso di lavoro**
1. Apri la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Se necessario, apri il riquadro di navigazione a sinistra (≡). Scegli **Flussi di lavoro privati**.
1. Nella pagina **Flussi di lavoro privati**, scegli **Crea** flusso di lavoro.
1. Nella pagina **Definisci flusso di lavoro**, fornisci le seguenti informazioni:
1. **Nome del flusso di lavoro**: un nome distintivo per questo flusso di lavoro. Ti consigliamo di impostare i nomi dei flussi di lavoro per organizzare le esecuzioni nella AWS HealthOmics console e nei CloudWatch registri.
1. **Descrizione** (opzionale): una descrizione di questo flusso di lavoro.
1. Nel pannello **di definizione del flusso** di lavoro, fornite le seguenti informazioni:
1. **Lingua del flusso** di lavoro (opzionale): seleziona la lingua specifica del flusso di lavoro. Altrimenti, HealthOmics determina la lingua dalla definizione del flusso di lavoro.
1. Per l'**origine delle definizioni di Workflow**, scegli di importare la cartella delle definizioni da un repository basato su Git, una posizione Amazon S3 o da un'unità locale.
1. Per l'**importazione da** un servizio di repository:
**Nota**
HealthOmics supporta repository pubblici e privati perGitHub,,, GitLabBitbucket,GitHub self-managed. GitLab self-managed
1. Scegli una **connessione** per connettere AWS le tue risorse al repository esterno. Per creare una connessione, consulta[Connect con repository di codice esterni](setting-up-new.md#setting-up-omics-repository).
**Nota**
I clienti della TLV regione devono creare una connessione nella regione IAD (us-east-1) per creare un flusso di lavoro.
1. In **Full repository ID, inserisci l'ID del repository** come nome utente/nome del repository. Verifica di avere accesso ai file in questo repository.
1. In **Riferimento alla fonte** (opzionale), inserisci un riferimento alla fonte del repository (branch, tag o ID di commit). HealthOmics utilizza il ramo predefinito se non viene specificato alcun riferimento alla fonte.
1. In **Escludi modelli** di file, inserisci i modelli di file per escludere cartelle, file o estensioni specifici. Questo aiuta a gestire le dimensioni dei dati durante l'importazione dei file del repository. Esistono un massimo di 50 pattern e i pattern devono seguire la sintassi del modello [glob](https://fossil-scm.org/home/doc/tip/www/globs.md). Esempio:
1. `tests/`
1. `*.jpeg`
1. `large_data.zip`
1. Per **Seleziona la cartella di definizione** da S3:
1. Inserisci la posizione Amazon S3 che contiene la cartella di definizione del flusso di lavoro compressa. Il bucket Amazon S3 deve trovarsi nella stessa regione del flusso di lavoro.
1. Se il tuo account non possiede il bucket Amazon S3, inserisci l'ID dell'account del proprietario del bucket nell'ID dell' AWS account del proprietario del **bucket S3**. Queste informazioni sono necessarie per verificare la proprietà del HealthOmics bucket.
1. Per **Seleziona la cartella di definizione da una fonte locale:**
1. Immettete la posizione sull'unità locale della cartella di definizione del flusso di lavoro compressa.
1. **Percorso principale del file di definizione del flusso** di lavoro (opzionale): immettete il percorso del file dalla cartella o dall'archivio di definizione del flusso di lavoro compresso al file. `main` Questo parametro non è richiesto se è presente un solo file nella cartella di definizione del flusso di lavoro o se il file principale è denominato «principale».
1. Nel pannello del **file README** (opzionale), selezionate l'**origine del file README** e fornite le seguenti informazioni:
+ Per **Importazione da un servizio di repository**, nel **percorso del file README, inserisci il percorso** del file README all'interno del repository.
+ Per **Seleziona file da S3**, nel file **README in S3, inserisci l'URI Amazon S3 per il file** README.
+ Per **Seleziona file da una fonte locale**: in **README - opzionale**, **scegli Scegli file per selezionare il file** markdown (.md) da caricare.
1. Nel pannello di **configurazione dell'archiviazione di esecuzione predefinita**, fornisci il tipo e la capacità di archiviazione di esecuzione predefiniti per le esecuzioni che utilizzano questo flusso di lavoro:
1. **Tipo di archiviazione di esecuzione**: scegli se utilizzare l'archiviazione statica o dinamica come impostazione predefinita per l'archiviazione di esecuzione temporanea. L'impostazione predefinita è l'archiviazione statica.
1. **Capacità di archiviazione di esecuzione** (opzionale): per il tipo di storage di esecuzione statico, è possibile inserire la quantità predefinita di storage di esecuzione richiesta per questo flusso di lavoro. Il valore predefinito per questo parametro è 1200 GiB. È possibile sovrascrivere questi valori predefiniti quando si avvia un'esecuzione.
1. **Tag** (opzionale): puoi associare fino a 50 tag a questo flusso di lavoro.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Aggiungi parametri del flusso** di lavoro (opzionale), seleziona l'**origine dei parametri**:
1. Per **Analizza dal file di definizione del flusso di lavoro**, HealthOmics analizzerà automaticamente i parametri del flusso di lavoro dal file di definizione del flusso di lavoro.
1. Per **Fornire un modello di parametro dal repository Git**, usa il percorso del file del modello di parametro dal tuo repository.
1. Per **Seleziona il file JSON dalla fonte locale**, carica un JSON file da una fonte locale che specifichi i parametri.
1. In **Inserisci manualmente i parametri del flusso di lavoro**, inserisci manualmente i nomi e le descrizioni dei parametri.
1. Nel pannello di **anteprima dei parametri**, è possibile rivedere o modificare i parametri per questa versione del flusso di lavoro. Se ripristinate il JSON file, perderete tutte le modifiche locali apportate.
1. Scegli **Next (Successivo)**.
1. Nella pagina di **rimappatura dell'URI del contenitore**, nel pannello **Regole di mappatura, puoi definire le regole** di mappatura URI per il tuo flusso di lavoro.
Per **Origine del file di mappatura**, selezionate una delle seguenti opzioni:
+ **Nessuna**: non è richiesta alcuna regola di mappatura.
+ **Seleziona il file JSON da S3**: specifica la posizione S3 per il file di mappatura.
+ **Seleziona il file JSON da una fonte locale**: specifica la posizione del file di mappatura sul tuo dispositivo locale.
+ **Inserisci manualmente le mappature: inserisci le mappature** **del registro e le mappature delle immagini nel pannello Mappature.**
1. La console **visualizza** il pannello Mappature. Se avete scelto un file sorgente di mappatura, la console visualizza i valori del file.
1. Nelle **mappature del registro**, è possibile modificare le mappature o aggiungere mappature (massimo 20 mappature del registro).
Ogni mappatura del registro contiene i seguenti campi:
+ **URL del registro upstream**: l'URI del registro upstream.
+ Prefisso del **repository ECR: il prefisso** del repository da utilizzare nell'archivio privato Amazon ECR.
+ (Facoltativo) Prefisso del repository **upstream: il prefisso del repository** nel registro upstream.
+ (Facoltativo) ID account **ECR: ID account** dell'account proprietario dell'immagine del contenitore upstream.
1. Nelle **mappature delle immagini**, è possibile modificare le mappature delle immagini o aggiungere mappature (massimo 100 mappature di immagini).
Ogni mappatura di immagini contiene i seguenti campi:
+ **Immagine di origine**: specifica l'URI dell'immagine di origine nel registro upstream.
+ **Immagine di destinazione**: specifica l'URI dell'immagine corrispondente nel registro privato di Amazon ECR.
1. Scegli **Next (Successivo)**.
1. Controlla la configurazione del flusso di lavoro, quindi scegli **Crea** flusso di lavoro.
## Creazione di un flusso di lavoro utilizzando la CLI
Se i file del flusso di lavoro e il file del modello dei parametri si trovano sul computer locale, è possibile creare un flusso di lavoro utilizzando il seguente comando CLI.
```
aws omics create-workflow \
--name "my_workflow" \
--definition-zip fileb://my-definition.zip \
--parameter-template file://my-parameter-template.json
```
L'`create-workflow`operazione restituisce la seguente risposta:
```
{
"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"
}
```
### Parametri opzionali da utilizzare durante la creazione di un flusso di lavoro
È possibile specificare uno qualsiasi dei parametri opzionali quando si crea un flusso di lavoro. Per i dettagli sulla sintassi, [CreateWorkflow](https://docs.aws.amazon.com/omics/latest/api/API_CreateWorkflow.html)consulta AWS HealthOmics API Reference.
**Topics**
+ [Specificare la definizione del flusso di lavoro (posizione Amazon S3)](#create-defn-uri-parameter)
+ [Usa la definizione del flusso di lavoro da un repository basato su Git](#create-defn-uri-git)
+ [Specificare un file Readme](#specify-readme-file)
+ [Specificare il file di definizione **main**](#create-main-parameter)
+ [Specificate il tipo di archiviazione di esecuzione](#create-run-storage-parameter)
+ [Specificare la configurazione della GPU](#create-accelerator-parameter)
+ [Configura i parametri di mappatura pull through cache](#create-prefix-mapping-parameters)
#### Specificare la definizione del flusso di lavoro (posizione Amazon S3)
Se il file di definizione del flusso di lavoro si trova in una cartella Amazon S3, specifica la posizione utilizzando il `definition-uri` parametro, come mostrato nell'esempio seguente. Se il tuo account non possiede il bucket Amazon S3, fornisci l'ID del proprietario. Account AWS
```
aws omics create-workflow \
--name Test \
--definition-uri s3://omics-bucket/workflow-definition/ \
--owner-id 123456789012
...
```
#### Usa la definizione del flusso di lavoro da un repository basato su Git
Per utilizzare la definizione del flusso di lavoro da un repository basato su Git supportato, usa il `definition-repository` parametro nella richiesta. Non fornire nessun altro `definition` parametro, poiché una richiesta ha esito negativo se include più di una fonte di input.
Il `definition-respository` parametro contiene i seguenti campi:
+ **connectionArn**— ARN della Code Connection che collega le risorse AWS al repository esterno.
+ **fullRepositoryId**— Inserisci l'ID del repository come. `owner-name/repo-name` Verifica di avere accesso ai file in questo repository.
+ **sourceReference**(Facoltativo): immettete un tipo di riferimento del repository (BRANCH, TAG o COMMIT) e un valore.
HealthOmics utilizza il commit più recente sul ramo predefinito se non specificate un riferimento alla fonte.
+ **excludeFilePatterns**(Facoltativo): immettete i modelli di file per escludere cartelle, file o estensioni specifiche. Questo aiuta a gestire le dimensioni dei dati durante l'importazione dei file del repository. [Fornisci un massimo di 50 pattern. I pattern devono seguire la sintassi del modello glob.](https://fossil-scm.org/home/doc/tip/www/globs.md) Esempio:
+ `tests/`
+ `*.jpeg`
+ `large_data.zip`
Quando specifichi la definizione del flusso di lavoro da un repository basato su Git, usa `parameter-template-path` per specificare il file modello dei parametri. Se non fornite questo parametro, HealthOmics crea il flusso di lavoro senza un modello di parametro.
L'esempio seguente mostra i parametri relativi al contenuto di un repository privato basato su 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" \
```
Per altri esempi, consulta il post sul 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).
#### Specificare un file Readme
È possibile specificare la posizione del file README utilizzando uno dei seguenti parametri:
+ **readme-markdown**— Inserimento di una stringa o di un file sul computer locale.
+ **readme-uri**— L'URI di un file archiviato su S3.
+ **readme-path **— Il percorso del file README nel repository.
**Utilizza readme-path solo insieme a definition-repository.** Se non specificate alcun parametro README, HealthOmics importa il file README.md di livello root nel repository (se esiste).
Gli esempi seguenti mostrano come specificare la posizione del file README utilizzando readme-path e 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"
```
Per ulteriori informazioni, consulta [HealthOmics File README del flusso di lavoro](workflows-readme.md).
#### Specificare il file di definizione **main**
Se state includendo più file di definizione del flusso di lavoro, utilizzate il `main` parametro per specificare il file di definizione principale per il flusso di lavoro.
```
aws omics create-workflow \
--name Test \
--main multi_workflow/workflow2.wdl \
...
```
#### Specificate il tipo di archiviazione di esecuzione
È possibile specificare il tipo di run storage predefinito (DYNAMIC o STATIC) e la capacità di storage di esecuzione (richiesta per lo storage statico). Per ulteriori informazioni sui tipi di run storage, consulta[Esegui tipi di storage nei flussi HealthOmics di lavoro](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 \
```
#### Specificare la configurazione della GPU
Utilizza il parametro accelerators per creare un flusso di lavoro che viene eseguito su un'istanza di calcolo accelerato. L'esempio seguente mostra come utilizzare il parametro. `accelerators` La configurazione della GPU viene specificata nella definizione del flusso di lavoro. Per informazioni, consulta [Istanze di elaborazione accelerata](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
```
#### Configura i parametri di mappatura pull through cache
Se utilizzi la funzionalità di mappatura pull through della cache di Amazon ECR, puoi sostituire le mappature predefinite. Per ulteriori informazioni sui parametri di configurazione del contenitore, consulta. [Immagini di container per flussi di lavoro privati](workflows-ecr.md)
Nell'esempio seguente, il file `mappings.json` contiene questo contenuto:
```
{
"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"
}
]
}
```
Specificate i parametri di mappatura nel comando create-workflow:
```
aws omics create-workflow \
...
--container-registry-map-file file://mappings.json
...
```
È inoltre possibile specificare la posizione S3 del file dei parametri di mappatura:
```
aws omics create-workflow \
...
--container-registry-map-uri s3://amzn-s3-demo-bucket1/test.zip
...
```
## Creazione di un flusso di lavoro utilizzando un SDK
Puoi creare un flusso di lavoro utilizzando uno dei SDKs. L'esempio seguente mostra come creare un flusso di lavoro utilizzando Python SDK.
```
import boto3
omics = boto3.client('omics')
with open('definition.zip', 'rb') as f:
definition = f.read()
response = omics.create_workflow(
name='my_workflow',
definitionZip=definition,
parameterTemplate={ ... }
)
```
# Aggiornare un flusso di lavoro privato
È possibile aggiornare un flusso di lavoro utilizzando la HealthOmics console, i comandi AWS CLI o uno dei. AWS SDKs
**Nota**
Non includere informazioni di identificazione personale (PII) nei nomi dei flussi di lavoro. Questi nomi sono visibili nei CloudWatch registri.
**Topics**
+ [Aggiornamento di un flusso di lavoro tramite la console](#console-update-workflows)
+ [Aggiornamento di un flusso di lavoro tramite la CLI](#api-update-workflows)
+ [Aggiornamento di un flusso di lavoro tramite un SDK](#sdk-update-workflows)
## Aggiornamento di un flusso di lavoro tramite la console
**Passaggi per aggiornare un flusso di lavoro**
1. Apri la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Se necessario, apri il riquadro di navigazione a sinistra (≡). Scegli **Flussi di lavoro privati**.
1. Nella pagina **Flussi di lavoro privati**, scegli il flusso di lavoro da aggiornare.
1. Nella pagina **Workflow**:
+ Se il flusso di lavoro ha delle versioni, assicurati di selezionare la **versione predefinita**.
+ Scegli **Modifica selezionato** dall'elenco **Azioni**.
1. Nella pagina **Modifica flusso di lavoro**, puoi modificare uno qualsiasi dei seguenti valori:
+ **Nome del flusso** di lavoro.
+ **Descrizione del flusso** di lavoro.
+ Il **tipo di archiviazione Run** predefinito per il flusso di lavoro.
+ La **capacità di archiviazione Run** predefinita (se il tipo di archiviazione di esecuzione è statica). Per ulteriori informazioni sulla configurazione predefinita di Run Storage, consulta[Creare un flusso di lavoro utilizzando la console](create-private-workflow.md#console-create-workflows).
1. Scegli **Salva modifiche** per applicare le modifiche.
## Aggiornamento di un flusso di lavoro tramite la CLI
Come illustrato nell'esempio seguente, è possibile aggiornare il nome e la descrizione del flusso di lavoro. È inoltre possibile modificare il tipo di archiviazione di esecuzione (STATIC o DYNAMIC) e la capacità di archiviazione di esecuzione (per il tipo di archiviazione statica). Per ulteriori informazioni sui tipi di run storage, consulta[Esegui tipi di storage nei flussi HealthOmics di lavoro](workflows-run-types.md).
```
aws omics update-workflow \
--id 1234567 \
--name my_workflow \
--description "updated workflow" \
--storage-type 'STATIC' \
--storage-capacity 1200
```
Non ricevi una risposta alla `update-workflow` richiesta.
## Aggiornamento di un flusso di lavoro tramite un SDK
Puoi aggiornare un flusso di lavoro utilizzando uno dei SDKs.
L'esempio seguente mostra come aggiornare un flusso di lavoro utilizzando Python SDK
```
import boto3
omics = boto3.client('omics')
response = omics.update_workflow(
name='my_workflow',
description='updated workflow'
)
```
# Eliminare un flusso di lavoro privato
Quando non è più necessario un flusso di lavoro, è possibile eliminarlo utilizzando la HealthOmics console, i comandi AWS CLI o uno dei. AWS SDKs È possibile eliminare un flusso di lavoro che soddisfa i seguenti criteri:
+ Il suo stato è ATTIVO o FALLITO.
+ Non ha condivisioni attive.
+ Hai eliminato tutte le versioni del flusso di lavoro.
L'eliminazione di un flusso di lavoro non influisce sulle esecuzioni in corso che utilizzano il flusso di lavoro.
**Topics**
+ [Eliminazione di un flusso di lavoro tramite la console](#console-delete-workflows)
+ [Eliminazione di un flusso di lavoro utilizzando la CLI](#api-delete-workflows)
+ [Eliminazione di un flusso di lavoro utilizzando un SDK](#sdk-delete-workflows)
## Eliminazione di un flusso di lavoro tramite la console
**Per eliminare un flusso di lavoro**
1. Apri la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Se necessario, apri il riquadro di navigazione a sinistra (≡). Scegli **Flussi di lavoro privati**.
1. Nella pagina **Flussi di lavoro privati**, scegli il flusso di lavoro da eliminare.
1. Nella pagina **Workflow**, scegli **Elimina selezionato** dall'elenco **Azioni**.
1. Nella modalità **Elimina flusso di lavoro**, inserisci «conferma» per confermare l'eliminazione.
1. Scegli **Elimina**.
## Eliminazione di un flusso di lavoro utilizzando la CLI
L'esempio seguente mostra come utilizzare il AWS CLI comando per eliminare un flusso di lavoro. Per eseguire l'esempio, sostituisci il `workflow id` con l'ID del flusso di lavoro che desideri eliminare.
```
aws omics delete-workflow
--id workflow id
```
HealthOmics non invia una risposta alla `delete-workflow` richiesta.
## Eliminazione di un flusso di lavoro utilizzando un SDK
Puoi eliminare un flusso di lavoro utilizzando uno dei. SDKs
L'esempio seguente mostra come eliminare un flusso di lavoro utilizzando Python SDK.
```
import boto3
omics = boto3.client('omics')
response = omics.delete_workflow(
id='1234567'
)
```
# Verifica lo stato del flusso di lavoro
Dopo aver creato il flusso di lavoro, puoi verificare lo stato e visualizzare altri dettagli del flusso di lavoro utilizzando **get-workflow**, come illustrato.
```
aws omics get-workflow --id 1234567
```
La risposta include i dettagli del flusso di lavoro, incluso lo stato, come mostrato.
```
{
"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"
}
```
È possibile avviare un'esecuzione utilizzando questo flusso di lavoro dopo la transizione dello stato a`ACTIVE`.
# Riferimento ai file del genoma da una definizione di workflow
È possibile HealthOmics fare riferimento a un oggetto dell'archivio di riferimento con un URI come il seguente. Usa il tuo `account ID` `reference store ID` e `reference ID` dove indicato.
```
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id
```
Alcuni flussi di lavoro richiederanno sia `SOURCE` i `INDEX` file che per il genoma di riferimento. L'URI precedente è il formato abbreviato predefinito e per impostazione predefinita sarà il file SOURCE. Per specificare uno dei due file, è possibile utilizzare il formato URI lungo, come segue.
```
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'utilizzo di un set di lettura della sequenza avrebbe uno schema simile, come mostrato.
```
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
```
Alcuni set di lettura, come quelli basati su FASTQ, possono contenere letture accoppiate. Negli esempi seguenti, vengono denominati e. SOURCE1 SOURCE2 I formati come BAM e CRAM avranno solo un SOURCE1 file. Alcuni set di lettura conterranno file INDEX come i file `bai` or`crai`. L'URI precedente è il formato abbreviato predefinito e per impostazione predefinita sarà il SOURCE1 file. Per specificare il file o l'indice esatto, è possibile utilizzare il formato URI lungo, come segue.
```
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
```
Di seguito è riportato un esempio di file JSON di input che utilizza due 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/"
}
```
**Fai riferimento al file JSON di input in AWS CLI aggiungendolo `--inputs file://` alla tua richiesta start-run.**