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
```
------
# Arquivos de modelo de parâmetros para HealthOmics fluxos de trabalho
Os modelos de parâmetros definem os parâmetros de entrada para um fluxo de trabalho. Você pode definir parâmetros de entrada para tornar seu fluxo de trabalho mais flexível e versátil. Por exemplo, você pode definir um parâmetro para a localização dos arquivos do genoma de referência no Amazon S3. Os modelos de parâmetros podem ser fornecidos por meio de um serviço de repositório baseado em Git ou de sua unidade local. Os usuários podem então executar o fluxo de trabalho usando vários conjuntos de dados.
Você pode criar o modelo de parâmetro para seu fluxo de trabalho ou HealthOmics gerar o modelo de parâmetro para você.
O modelo de parâmetro é um arquivo JSON. No arquivo, cada parâmetro de entrada é um objeto nomeado que deve corresponder ao nome da entrada do fluxo de trabalho. Ao iniciar uma execução, se você não fornecer valores para todos os parâmetros necessários, a execução falhará.
O objeto do parâmetro de entrada inclui os seguintes atributos:
+ **description**— Esse atributo obrigatório é uma string que o console exibe na página **Iniciar execução**. Essa descrição também é mantida como metadados de execução.
+ **optional**— Esse atributo opcional indica se o parâmetro de entrada é opcional. Se você não especificar o **optional** campo, o parâmetro de entrada será obrigatório.
O exemplo de modelo de parâmetro a seguir mostra como especificar os parâmetros de entrada.
```
{
"myRequiredParameter1": {
"description": "this parameter is required",
},
"myRequiredParameter2": {
"description": "this parameter is also required",
"optional": false
},
"myOptionalParameter": {
"description": "this parameter is optional",
"optional": true
}
}
```
## Geração de modelos de parâmetros
HealthOmics gera o modelo de parâmetros analisando a definição do fluxo de trabalho para detectar os parâmetros de entrada. Se você fornecer um arquivo de modelo de parâmetros para um fluxo de trabalho, os parâmetros em seu arquivo substituirão os parâmetros detectados na definição do fluxo de trabalho.
Há pequenas diferenças entre a lógica de análise dos mecanismos CWL, WDL e Nextflow, conforme descrito nas seções a seguir.
**Topics**
+ [Detecção de parâmetros para CWL](#parameter-parsing-cwl)
+ [Detecção de parâmetros para WDL](#parameter-parsing-wdl)
+ [Detecção de parâmetros para Nextflow](#parameter-parsing-nextflow)
### Detecção de parâmetros para CWL
No mecanismo de fluxo de trabalho da CWL, a lógica de análise faz as seguintes suposições:
+ Todos os tipos anuláveis suportados são marcados como parâmetros de entrada opcionais.
+ Todos os tipos não nulos suportados são marcados como parâmetros de entrada obrigatórios.
+ Todos os parâmetros com valores padrão são marcados como parâmetros de entrada opcionais.
+ As descrições são extraídas da `label` seção da definição do `main` fluxo de trabalho. Se não `label` for especificado, a descrição ficará em branco (uma string vazia).
As tabelas a seguir mostram exemplos de interpolação de CWL. Para cada exemplo, o nome do parâmetro é`x`. Se o parâmetro for necessário, você deverá fornecer um valor para o parâmetro. Se o parâmetro for opcional, você não precisará fornecer um valor.
Esta tabela mostra exemplos de interpolação CWL para tipos primitivos.
| Entrada | Exemplo de entrada/saída | Obrigatório |
| --- | --- | --- |
| x:
type: int
| 1 ou 2 ou... | Sim |
| x:
type: int
default: 2
| O valor padrão é 2. A entrada válida é 1 ou 2 ou... | Não |
| x:
type: int?
| A entrada válida é Nenhuma ou 1 ou 2 ou... | Não |
| x:
type: int?
default: 2
| O valor padrão é 2. A entrada válida é Nenhuma ou 1 ou 2 ou... | Não |
A tabela a seguir mostra exemplos de interpolação CWL para tipos complexos. Um tipo complexo é uma coleção de tipos primitivos.
| Entrada | Exemplo de entrada/saída | Obrigatório |
| --- | --- | --- |
| x:
type: array
items: int
| [] ou [1,2,3] | Sim |
| x:
type: array?
items: int
| Nenhum ou [] ou [1,2,3] | Não |
| x:
type: array
items: int?
| [] ou [Nenhum, 3, Nenhum] | Sim |
| x:
type: array?
items: int?
| [Nenhum] ou Nenhum ou [1,2,3] ou [Nenhum, 3] mas não [] | Não |
### Detecção de parâmetros para WDL
No mecanismo de fluxo de trabalho da WDL, a lógica de análise faz as seguintes suposições:
+ Todos os tipos anuláveis suportados são marcados como parâmetros de entrada opcionais.
+ Para tipos suportados não anuláveis:
+ Qualquer variável de entrada com atribuição de literais ou expressão é marcada como parâmetros opcionais. Por exemplo:
```
Int x = 2
Float f0 = 1.0 + f1
```
+ Se nenhum valor ou expressão tiver sido atribuído aos parâmetros de entrada, eles serão marcados como parâmetros obrigatórios.
+ As descrições são extraídas da definição `parameter_meta` do `main` fluxo de trabalho. Se não `parameter_meta` for especificado, a descrição ficará em branco (uma string vazia). Para obter mais informações, consulte a especificação WDL para [metadados de parâmetros](https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#metadata-sections).
As tabelas a seguir mostram exemplos de interpolação de WDL. Para cada exemplo, o nome do parâmetro é`x`. Se o parâmetro for necessário, você deverá fornecer um valor para o parâmetro. Se o parâmetro for opcional, você não precisará fornecer um valor.
Esta tabela mostra exemplos de interpolação de WDL para tipos primitivos.
| Entrada | Exemplo de entrada/saída | Obrigatório |
| --- | --- | --- |
| Int x | 1 ou 2 ou... | Sim |
| Int x = 2 | 2 | Não |
| Int x = 1\$12 | 3 | Não |
| Int x = y\$1z | y\$1z | Não |
| Int? x | Nenhum ou 1 ou 2 ou... | Sim |
| Int? x = 2 | Nenhum ou 2 | Não |
| Int? x = 1\$12 | Nenhum ou 3 | Não |
| Int? x = y\$1z | Nenhum ou y\$1z | Não |
A tabela a seguir mostra exemplos de interpolação de WDL para tipos complexos. Um tipo complexo é uma coleção de tipos primitivos.
| Entrada | Exemplo de entrada/saída | Obrigatório |
| --- | --- | --- |
| Matriz [Int] x | [1,2,3] ou [] | Sim |
| Matriz [Int] \$1 x | [1], mas não [] | Sim |
| Matriz [Int]? x | Nenhum ou [] ou [1,2,3] | Não |
| Matriz [Int?] x | [] ou [Nenhum, 3, Nenhum] | Sim |
| Matriz [Int?] =? x | [Nenhum] ou Nenhum ou [1,2,3] ou [Nenhum, 3] mas não [] | Não |
| Amostra de estrutura \$1String a, Int y\$1 posteriormente nas entradas: Sample MySample | String a = mySample.a
Int y = mySample.y
| Sim |
| Amostra de estrutura \$1String a, Int y\$1 posteriormente nas entradas: Amostra? Minha amostra | if (defined(mySample)) {
String a = mySample.a
Int y = mySample.y
} | Não |
### Detecção de parâmetros para Nextflow
Para o Nextflow, HealthOmics gera o modelo de parâmetro analisando o arquivo. `nextflow_schema.json` Se a definição do fluxo de trabalho não incluir um arquivo de esquema, HealthOmics analisará o arquivo principal de definição do fluxo de trabalho.
**Topics**
+ [Analisando o arquivo do esquema](#parameter-parsing-nextflow-schema)
+ [Analisando o arquivo principal](#parameter-parsing-nextflow-main)
+ [Parâmetros aninhados](#parameter-parsing-nextflow-nested)
+ [Exemplos de interpolação Nextflow](#parameter-parsing-nextflow-examples)
#### Analisando o arquivo do esquema
Para que a análise funcione corretamente, verifique se o arquivo do esquema atende aos seguintes requisitos:
+ O arquivo do esquema tem um nome `nextflow_schema.json` e está localizado no mesmo diretório do arquivo do fluxo de trabalho principal.
+ O arquivo do esquema é um JSON válido, conforme definido em um dos seguintes esquemas:
+ [esquema json. org/draft/2020-12/schema](https://json-schema.org/draft/2020-12/schema).
+ [esquema json. org/draft-07/schema](https://json-schema.org/draft-07/schema).
HealthOmics analisa o `nextflow_schema.json` arquivo para gerar o modelo de parâmetro:
+ Extrai tudo **properties** o que está definido no esquema.
+ Inclui a propriedade, **description** se disponível para a propriedade.
+ Identifica se cada parâmetro é opcional ou obrigatório, com base no **required** campo da propriedade.
O exemplo a seguir mostra um arquivo de definição e o arquivo de parâmetros gerado.
```
{
"$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" }
]
}
```
O modelo de parâmetro gerado:
```
{
"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
}
}
```
#### Analisando o arquivo principal
Se a definição do fluxo de trabalho não incluir um `nextflow_schema.json` arquivo, HealthOmics analisará o arquivo principal de definição do fluxo de trabalho.
HealthOmics analisa as `params` expressões encontradas no arquivo principal de definição do fluxo de trabalho e no `nextflow.config` arquivo. Todos `params` com valores padrão são marcados como opcionais.
Para que a análise funcione corretamente, observe os seguintes requisitos:
+ HealthOmics analisa somente o arquivo de definição do fluxo de trabalho principal. Para garantir que todos os parâmetros sejam capturados, recomendamos que você conecte tudo a todos **params** os submódulos e fluxos de trabalho importados.
+ O arquivo de configuração é opcional. Se você definir um, nomeie-o `nextflow.config` e coloque-o no mesmo diretório do arquivo principal de definição do fluxo de trabalho.
O exemplo a seguir mostra um arquivo de definição e o modelo de parâmetro gerado.
```
params.input_file = "default.txt"
params.threads = 4
params.memory = "8GB"
workflow {
if (params.version) {
println "Using version: ${params.version}"
}
}
```
O modelo de parâmetro gerado:
```
{
"input_file": {
"description": None,
"optional": True
},
"threads": {
"description": None,
"optional": True
},
"memory": {
"description": None,
"optional": True
},
"version": {
"description": None,
"optional": False
}
}
```
Para valores padrão definidos em nextflow.config, HealthOmics coleta `params` atribuições e parâmetros declarados em, conforme mostrado no `params {}` exemplo a seguir. Nas declarações de atribuição, `params` devem aparecer no lado esquerdo da declaração.
```
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}"
```
O modelo de parâmetro gerado:
```
{
// 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
}
}
```
#### Parâmetros aninhados
Ambos `nextflow_schema.json` e `nextflow.config` permitem parâmetros aninhados. No entanto, o modelo de HealthOmics parâmetros requer somente os parâmetros de nível superior. Se seu fluxo de trabalho usa um parâmetro aninhado, você deve fornecer um objeto JSON como entrada para esse parâmetro.
##### Parâmetros aninhados em arquivos de esquema
HealthOmics pula aninhado **params** ao analisar um arquivo. `nextflow_schema.json` Por exemplo, se você definir o seguinte `nextflow_schema.json` arquivo:
```
{
"properties": {
"input": {
"properties": {
"input_file": { ... },
"input_num": { ... }
}
},
"input_bool": { ... }
}
}
```
HealthOmics ignora `input_file` e `input_num` quando gera o modelo de parâmetro:
```
{
"input": {
"description": None,
"optional": True
},
"input_bool": {
"description": None,
"optional": True
}
}
```
Quando você executa esse fluxo de trabalho, HealthOmics espera um `input.json` arquivo semelhante ao seguinte:
```
{
"input": {
"input_file": "s3://bucket/obj",
"input_num": 2
},
"input_bool": false
}
```
##### Parâmetros aninhados em arquivos de configuração
HealthOmics não coleta aninhados **params** em um `nextflow.config` arquivo e os ignora durante a análise. Por exemplo, se você definir o seguinte `nextflow.config` arquivo:
```
params.alpha = "alpha"
params.nested.beta = "beta"
params {
gamma = "gamma"
group {
delta = "delta"
}
}
```
HealthOmics ignora `params.nested.beta` e `params.group.delta` quando gera o modelo de parâmetro:
```
{
"alpha": {
"description": None,
"optional": True
},
"gamma": {
"description": None,
"optional": True
}
}
```
#### Exemplos de interpolação Nextflow
A tabela a seguir mostra exemplos de interpolação do Nextflow para parâmetros no arquivo principal.
| Parâmetros | Obrigatório |
| --- | --- |
| params.input\$1file | Sim |
| params.input\$1file = "s3://bucket/data.json” | Não |
| params.nested.input\$1file | N/D |
| params.nested.input\$1file = "s3://bucket/data.json” | N/D |
A tabela a seguir mostra exemplos de interpolação do Nextflow para parâmetros no arquivo. `nextflow.config`
| Parâmetros | Obrigatório |
| --- | --- |
| params.input_file = "s3://bucket/data.json"
| Não |
| params {
input_file = "s3://bucket/data.json"
} | Não |
| params {
nested {
input_file = "s3://bucket/data.json"
}
} | N/D |
| input_file = params.input_file
| N/D |
# Imagens de contêiner para fluxos de trabalho privados
HealthOmics oferece suporte a imagens de contêineres hospedadas em repositórios privados do Amazon ECR. Você pode criar imagens de contêiner e enviá-las para o repositório privado. Você também pode usar seu registro privado do Amazon ECR como um cache para sincronizar o conteúdo dos registros upstream.
Seu repositório Amazon ECR deve residir na mesma AWS região da conta que está chamando o serviço. Uma pessoa diferente Conta da AWS pode possuir a imagem do contêiner, desde que o repositório de imagens de origem forneça as permissões apropriadas. Para obter mais informações, consulte [Políticas para acesso entre contas ao Amazon ECR](permissions-ecr.md#permissions-cross-account).
Recomendamos que você defina a imagem do contêiner do Amazon ECR URIs como parâmetros em seu fluxo de trabalho para que o acesso possa ser verificado antes do início da execução. Também facilita a execução de um fluxo de trabalho em uma nova região alterando o parâmetro Região.
**nota**
HealthOmics não oferece suporte a contêineres ARM e não oferece suporte ao acesso a repositórios públicos.
Para obter informações sobre como configurar as permissões do IAM HealthOmics para acessar o Amazon ECR, consulte. [HealthOmics Permissões de recursos](permissions-resource.md)
**Topics**
+ [Sincronização com registros de contêineres de terceiros](#ecr-pull-through)
+ [Considerações gerais sobre imagens de contêineres do Amazon ECR](#ecr-considerations)
+ [Variáveis de ambiente para HealthOmics fluxos de trabalho](#ecr-env-vars)
+ [Usando Java em imagens de contêiner do Amazon ECR](#ecr-java-considerations)
+ [Adicionar entradas de tarefas a uma imagem de contêiner do Amazon ECR](#ecr-tasks)
## Sincronização com registros de contêineres de terceiros
Você pode usar as regras de cache pull through do Amazon ECR para sincronizar repositórios em um registro upstream compatível com seus repositórios privados do Amazon ECR. Para obter mais informações, consulte [Sincronizar um registro upstream](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html) no Guia do *usuário do Amazon ECR.*
O cache de extração cria automaticamente o repositório de imagens em seu registro privado quando você cria o cache e sincroniza automaticamente com a imagem em cache quando há alterações na imagem upstream.
HealthOmics suporta cache pull through para os seguintes registros upstream:
+ Amazon ECR Public
+ Registro de imagens de contêineres do Kubernetes
+ Quay
+ Docker Hub
+ Microsoft Azure Container Registry
+ GitHub Registro de contêiner
+ GitLab Registro de contêiner
HealthOmics não suporta cache pull through para um repositório privado upstream do Amazon ECR.
Os benefícios de usar o cache pull through do Amazon ECR incluem:
1. Você evita ter que migrar manualmente as imagens do contêiner para o Amazon ECR ou sincronizar atualizações do repositório de terceiros.
1. Os fluxos de trabalho acessam as imagens sincronizadas do contêiner em seu repositório privado, o que é mais confiável do que baixar conteúdo em tempo de execução de um registro público.
1. Como os caches pull through do Amazon ECR usam uma estrutura de URI previsível, o HealthOmics serviço pode mapear automaticamente o URI privado do Amazon ECR com o URI do registro upstream. Você não precisa atualizar e substituir os valores de URI na definição do fluxo de trabalho.
**Topics**
+ [Configurando o cache pull through](#ecr-pull-through-configure)
+ [Mapeamentos de registro](#ecr-pull-through-registry-mapping)
+ [Mapeamentos de imagens](#ecr-pull-through-mapping-format)
### Configurando o cache pull through
O Amazon ECR fornece um registro para você Conta da AWS em cada região. Certifique-se de criar a configuração do Amazon ECR na mesma região em que planeja executar o fluxo de trabalho.
As seções a seguir descrevem as tarefas de configuração do cache pull through.
**Topics**
+ [Crie uma regra de cache de pull through](#create-ecr-ptc)
+ [Permissões de registro para registro upstream](#reg-ecr-ptc)
+ [Modelos de criação de repositório](#repo-create-templates-ptc)
+ [Criação do fluxo de trabalho](#reg-mapping-ecr-ptc)
#### Crie uma regra de cache de pull through
Crie uma regra de cache pull through do Amazon ECR para cada registro upstream que tenha imagens que você deseja armazenar em cache. Uma regra especifica um mapeamento entre um registro upstream e o repositório privado do Amazon ECR.
Para um registro upstream que exija autenticação, você fornece suas credenciais usando o AWS Secrets Manager.
**nota**
Não altere uma regra de cache de pull through enquanto uma execução ativa estiver usando o repositório privado. A execução pode falhar ou, mais criticamente, fazer com que seu pipeline use imagens inesperadas.
Para obter mais informações, consulte [Criação de uma regra de cache pull through](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) no *Guia do usuário do Amazon Elastic Container Registry*.
##### Crie uma regra de cache de pull through usando o console
Para configurar o cache pull through, siga estas etapas usando o console do Amazon ECR:
1. Abra o console do Amazon ECR: https://console.aws.amazon.com /ecr
1. No menu à esquerda, em **Registro privado**, expanda **Recursos e configurações**. Em seguida, escolha **Extrair pelo cache**.
1. Na página **Pull through cache**, escolha **Adicionar regra**.
1. **No painel **Registro upstream, escolha o registro** upstream para sincronizar com seu registro privado e, em seguida, escolha Avançar.**
1. Se o registro upstream exigir autenticação, o console abrirá uma nova página na qual você especifica o segredo de SageMaker IA que contém suas credenciais. Escolha **Próximo**.
1. Em **Especificar namespaces**, no painel **Namespace Cache**, escolha se deseja criar os repositórios privados usando um prefixo de repositório específico ou sem prefixo. Se você optar por usar um prefixo, especifique o nome do prefixo em Prefixo do **repositório de cache**.
1. No painel do **namespace Upstream**, escolha se deseja extrair dos repositórios upstream usando um prefixo de repositório específico ou sem prefixo. Se você optar por usar um prefixo, especifique o nome do prefixo no prefixo do repositório **Upstream**.
O painel de **exemplo de Namespace** mostra um exemplo de pull request, URL upstream e a URL do repositório de cache criado.
1. Escolha **Próximo**.
1. Revise a configuração e escolha **Criar** para criar a regra.
Para obter mais informações, consulte [Criar uma regra de cache de pull through (AWS Management Console)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-console).
##### Crie uma regra de cache de pull through usando a CLI
Use o **create-pull-through-cache-rule** comando Amazon ECR para criar uma regra de cache pull through. Para registros upstream que exigem autenticação, armazene as credenciais em um segredo do Secrets Manager.
As seções a seguir fornecem exemplos para cada registro upstream compatível.
##### Para o Amazon ECR Public
O exemplo a seguir cria uma regra de cache de pull-through para o registro público do Amazon ECR. Ele especifica um prefixo de repositório de `ecr-public`, o que faz com que cada repositório criado usando a regra de cache de pull-through receba o esquema de nomes 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
```
##### Para registro de contêineres Kubernetes
O exemplo a seguir cria uma regra de cache de pull-through para o registro público do Kubernetes. Ele especifica um prefixo de repositório de `kubernetes`, o que faz com que cada repositório criado usando a regra de cache de pull-through receba o esquema de nomes 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
```
##### Para Quay
O exemplo a seguir cria uma regra de cache de pull-through para o registro público do Quay. Ele especifica um prefixo de repositório de `quay`, o que faz com que cada repositório criado usando a regra de cache de pull-through receba o esquema de nomes 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
```
##### Para o Docker Hub
O exemplo a seguir cria uma regra de cache de pull-through para o registro do Docker Hub. Ele especifica um prefixo de repositório de `docker-hub`, o que faz com que cada repositório criado usando a regra de cache de pull-through receba o esquema de nomes de `docker-hub/upstream-repository-name`. É necessário especificar o nome completo do Amazon Resource Name (ARN) do segredo que contém suas credenciais do 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
```
##### Para GitHub Container Registry
O exemplo a seguir cria uma regra de cache pull through para o GitHub Container Registry. Ele especifica um prefixo de repositório de `github`, o que faz com que cada repositório criado usando a regra de cache de pull-through receba o esquema de nomes de `github/upstream-repository-name`. Você deve especificar o Amazon Resource Name (ARN) completo do segredo que contém suas credenciais do 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
```
##### Para o Registro de Contêiner do Microsoft Azure
O exemplo a seguir cria uma regra de cache de pull-through para o Microsoft Azure Container Registry. Ele especifica um prefixo de repositório de `azure`, o que faz com que cada repositório criado usando a regra de cache de pull-through receba o esquema de nomes de `azure/upstream-repository-name`. É necessário especificar o nome completo do Amazon Resource Name (ARN) do segredo que contém suas credenciais do Docker Hub.
```
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
```
##### Para GitLab Container Registry
O exemplo a seguir cria uma regra de cache pull through para o GitLab Container Registry. Ele especifica um prefixo de repositório de `gitlab`, o que faz com que cada repositório criado usando a regra de cache de pull-through receba o esquema de nomes de `gitlab/upstream-repository-name`. Você deve especificar o Amazon Resource Name (ARN) completo do segredo que contém suas credenciais do 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
```
Para obter mais informações, consulte [Criar uma regra de cache pull through (CLI)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-cli) no Guia do usuário do *Amazon ECR.*
Você pode usar o comando **get-run-task** CLI para recuperar informações sobre a imagem do contêiner usada para uma tarefa específica:
```
aws omics get-run-task --id 1234567 --task-id
```
A saída inclui as seguintes informações sobre a imagem do contêiner:
```
"imageDetails": {
"image": "string",
"imageDigest": "string",
"sourceImage": "string",
...
}
```
#### Permissões de registro para registro upstream
Use as permissões de registro HealthOmics para permitir o uso do cache de extração e a inserção das imagens do contêiner no registro privado do Amazon ECR. Adicione uma política de registro do Amazon ECR ao registro que fornece os contêineres usados nas execuções.
A política a seguir concede permissão para que o HealthOmics serviço crie repositórios com os prefixos de cache pull through especificados e inicie pulls upstream nesses repositórios.
1. No console do Amazon ECR, abra o menu à esquerda, em **Registro privado**, expanda **Permissões do registro**. Em seguida, escolha **Gerar declaração**.
1. No canto superior direito, escolha JSON. Insira uma política semelhante à seguinte:
------
#### [ 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/*"
]
}
]
}
```
------
#### Modelos de criação de repositório
Para usar o cache pull through HealthOmics, o repositório Amazon ECR deve ter um modelo de criação de repositório. O modelo define as configurações para quando você ou o Amazon ECR criam um repositório privado para um registro upstream.
Cada modelo contém um prefixo de namespace de repositório, que o Amazon ECR usa para combinar novos repositórios com um modelo específico. Os modelos especificam a configuração de todas as configurações do repositório, incluindo políticas de acesso baseadas em recursos, imutabilidade de tags, criptografia e políticas de ciclo de vida.
Para obter mais informações, consulte [Modelos de criação de repositórios](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) no *Guia do usuário do Amazon Elastic Container Registry*.
Como criar um modelo de criação de repositório:
1. No console do Amazon ECR, abra o menu à esquerda, em **Registro privado**, expanda **Recursos e configurações**. Em seguida, escolha Modelos de **criação de repositório**.
1. Selecione **Criar modelo**.
1. Em **Detalhes do modelo**, escolha **Extrair cache**.
1. Escolha se deseja aplicar esse modelo a um prefixo específico ou a todos os repositórios que não correspondam a outro modelo.
**Se você escolher **Um prefixo específico, insira o valor do prefixo** do namespace em Prefixo.** Você especificou esse prefixo ao criar a regra PTC.
1. Escolha **Próximo**.
1. Na página **Adicionar configuração de criação de repositório**, insira Permissões do **repositório.** Use um dos exemplos de declarações de política ou insira um semelhante ao exemplo a seguir:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PTCRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
1. Opcionalmente, você pode adicionar configurações do repositório, como políticas de ciclo de vida e tags. O Amazon ECR aplica essas regras a todas as imagens de contêiner criadas para o cache pull through que usam o prefixo especificado.
1. Escolha **Próximo**.
1. Revise a configuração e escolha **Avançar**.
#### Criação do fluxo de trabalho
Ao criar um novo fluxo de trabalho ou versão do fluxo de trabalho, revise os mapeamentos do registro e atualize-os, se necessário. Para obter detalhes, consulte [Crie um fluxo de trabalho privado](create-private-workflow.md).
### Mapeamentos de registro
Você define mapeamentos de registro para mapear entre prefixos em seu registro privado do Amazon ECR e os nomes de registro upstream.
Para obter mais informações sobre mapeamentos de registro do Amazon ECR, consulte [Criação de uma regra de cache pull through no Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) ECR.
O exemplo a seguir mostra mapeamentos de registro para 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"
}
]
}
```
### Mapeamentos de imagens
Você define mapeamentos de imagem para mapear entre os nomes das imagens, conforme definido em seus fluxos de trabalho privados do Amazon ECR, e os nomes das imagens no registro upstream.
Você pode usar mapeamentos de imagem com registros que oferecem suporte ao cache pull through. Você também pode usar mapeamentos de imagem com registros upstream que HealthOmics não oferecem suporte para pull through cache. Você precisa sincronizar manualmente o registro upstream com seu repositório privado.
Para obter mais informações sobre mapeamentos de imagens do Amazon ECR, consulte [Criação de uma regra de cache pull through no Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) ECR.
O exemplo a seguir mostra mapeamentos de imagens privadas do Amazon ECR para uma imagem genômica pública e a imagem mais recente do 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",
}
]
}
```
## Considerações gerais sobre imagens de contêineres do Amazon ECR
+ Arquitetura
HealthOmics suporta contêineres x86\$164. Se sua máquina local for baseada em ARM, como o Apple Mac, use um comando como o seguinte para criar uma imagem de contêiner x86\$164:
```
docker build --platform amd64 -t my_tool:latest .
```
+ Ponto de entrada e concha
HealthOmics os mecanismos de fluxo de trabalho injetam scripts bash como uma substituição de comando nas imagens de contêiner usadas pelas tarefas do fluxo de trabalho. Portanto, as imagens de contêiner devem ser criadas sem um ENTRYPOINT especificado, de forma que um shell bash seja o padrão.
+ Caminhos montados
Um sistema de arquivos compartilhado é montado nas tarefas do contêiner em /tmp. Todos os dados ou ferramentas incorporados à imagem do contêiner nesse local serão substituídos.
A definição do fluxo de trabalho está disponível para tarefas por meio de uma montagem somente para leitura em /mnt/workflow.
+ Tamanho da imagem
Consulte [HealthOmics cotas de tamanho fixo do fluxo de trabalho](fixed-quotas.md#fixed-quotas-workflows) os tamanhos máximos de imagem do contêiner.
## Variáveis de ambiente para HealthOmics fluxos de trabalho
HealthOmics fornece variáveis de ambiente que têm informações sobre o fluxo de trabalho em execução no contêiner. Você pode usar os valores dessas variáveis na lógica das tarefas do seu fluxo de trabalho.
Todas as variáveis do HealthOmics fluxo de trabalho começam com o `AWS_WORKFLOW_` prefixo. Esse prefixo é um prefixo de variável de ambiente protegido. Não use esse prefixo para suas próprias variáveis em contêineres de fluxo de trabalho.
HealthOmics fornece as seguintes variáveis de ambiente de fluxo de trabalho:
**AWS\$1REGION**
Essa variável é a região em que o contêiner está sendo executado.
**AWS\$1WORKFLOW\$1EXECUTAR**
Essa variável é o nome da execução atual.
**AWS\$1WORKFLOW\$1ID DE EXECUÇÃO**
Essa variável é o identificador da execução atual.
**AWS\$1WORKFLOW\$1EXECUTAR UUID**
Essa variável é o UUID de execução da execução atual.
**AWS\$1WORKFLOW\$1TAREFA**
Essa variável é o nome da tarefa atual.
**AWS\$1WORKFLOW\$1ID DA TAREFA**
Essa variável é o identificador da tarefa atual.
**AWS\$1WORKFLOW\$1TASK\$1UUID**
Essa variável é o UUID da tarefa atual.
O exemplo a seguir mostra valores típicos para cada variável de 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
```
## Usando Java em imagens de contêiner do Amazon ECR
Se uma tarefa de fluxo de trabalho usa um aplicativo Java, como o GATK, considere os seguintes requisitos de memória para o contêiner:
+ Os aplicativos Java usam memória de pilha e memória de pilha. Por padrão, a memória máxima da pilha é uma porcentagem da memória total disponível no contêiner. Esse padrão depende da distribuição específica da JVM e da versão da JVM, portanto, consulte a documentação relevante da sua JVM ou defina explicitamente o máximo de memória do heap usando as opções da linha de comando Java (como `-Xmx`).
+ Não defina a memória máxima do heap como 100% da alocação de memória do contêiner, pois a pilha da JVM também requer memória. A memória também é necessária para o coletor de lixo da JVM e para qualquer outro processo do sistema operacional em execução no contêiner.
+ Alguns aplicativos Java, como o GATK, podem usar invocações de métodos nativos ou outras otimizações, como arquivos de mapeamento de memória. Essas técnicas exigem alocações de memória executadas “fora da pilha”, que não são controladas pelo parâmetro máximo de pilha da JVM.
Se você sabe (ou suspeita) que seu aplicativo Java aloca memória fora da pilha, certifique-se de que sua alocação de memória de tarefas inclua os requisitos de memória fora da pilha.
Se essas alocações fora do heap fizerem com que o contêiner fique sem memória, você normalmente não verá um **OutOfMemory** erro de Java, porque a JVM não controla essa memória.
## Adicionar entradas de tarefas a uma imagem de contêiner do Amazon ECR
Adicione todos os executáveis, bibliotecas e scripts necessários para executar uma tarefa de fluxo de trabalho na imagem do Amazon ECR usada para executar a tarefa.
É uma prática recomendada evitar o uso de scripts, binários e bibliotecas externos à imagem do contêiner de tarefas. Isso é especialmente importante ao usar `nf-core` fluxos de trabalho que usam um `bin` diretório como parte do pacote de fluxo de trabalho. Embora esse diretório esteja disponível para a tarefa do fluxo de trabalho, ele é montado como um diretório somente para leitura. Os recursos necessários nesse diretório devem ser copiados na imagem da tarefa e disponibilizados em tempo de execução ou ao criar a imagem do contêiner usada para a tarefa.
Consulte [HealthOmics cotas de tamanho fixo do fluxo de trabalho](fixed-quotas.md#fixed-quotas-workflows) o tamanho máximo da imagem do contêiner HealthOmics compatível.
# HealthOmics Arquivos README do fluxo de trabalho
Você pode carregar um arquivo README.md contendo instruções, diagramas e informações essenciais para seu fluxo de trabalho. Cada versão do fluxo de trabalho oferece suporte a um arquivo README, que você pode atualizar a qualquer momento.
**Os requisitos do README incluem:**
+ O arquivo README deve estar no formato markdown (.md)
+ Tamanho máximo do arquivo: 500 KiB
**Topics**
+ [Use um README existente](#workflows-add-readme)
+ [Condições de renderização](#workflows-rendering-readme)
## Use um README existente
READMEs exportados dos repositórios Git contêm links relativos que normalmente não funcionam fora do repositório. HealthOmics A integração com o Git os converte automaticamente em links absolutos para uma renderização adequada no console, eliminando a necessidade de atualizações manuais de URL.
Para READMEs importados do Amazon S3 ou de unidades locais, as imagens e os links devem ser públicos URLs ou ter seus caminhos relativos atualizados para uma renderização adequada.
**nota**
As imagens devem ser hospedadas publicamente para serem exibidas no HealthOmics console. Imagens armazenadas em repositórios GitHub Enterprise Server ou GitLab Self-Managed repositórios não podem ser renderizadas.
## Condições de renderização
O HealthOmics console interpola imagens e links acessíveis ao público usando caminhos absolutos. Para renderizar URLs a partir de repositórios privados, o usuário deve ter acesso ao repositório. GitLab Self-ManagedOs repositórios for GitHub Enterprise Server or, que usam domínios personalizados, HealthOmics não conseguem resolver links relativos nem renderizar imagens armazenadas nesses repositórios privados.
A tabela a seguir mostra os elementos de marcação que são compatíveis com a visualização README do AWS console.
| Elemento | AWS console |
| --- | --- |
| Alertas | Sim, mas sem ícones |
| Distintivos | Sim |
| Formatação básica de texto | Sim |
| [Blocos de código](https://www.markdownguide.org/basic-syntax/#code-blocks) | Sim, mas não tem a funcionalidade de [realce de sintaxe](https://www.markdownguide.org/extended-syntax/#syntax-highlighting) e botão de cópia |
| Seções dobráveis | Sim |
| [Cabeçalhos](https://www.markdownguide.org/basic-syntax/#headings) | Sim |
| [Formatos de imagem](https://www.markdownguide.org/basic-syntax/#images-1) | Sim |
| [Imagem (clicável)](https://www.markdownguide.org/basic-syntax/#linking-images) | Sim |
| [Quebras de linha](https://www.markdownguide.org/basic-syntax/#line-breaks) | Sim |
| Diagrama de sereia | Só pode abrir o gráfico, mover a posição do gráfico e copiar o código |
| Cotações | Sim |
| [https://www.markdownguide.org/extended-syntax/#subscript](https://www.markdownguide.org/extended-syntax/#subscript) | Sim |
| [Tabelas](https://www.markdownguide.org/extended-syntax/#tables) | Sim, mas não suporta alinhamento de texto |
| Alinhamento de texto | Sim |
### Usando imagem e link URLs
Dependendo do seu provedor de origem, estruture sua base URLs para páginas e imagens nos seguintes formatos.
+ `{username}`: o nome de usuário em que o repositório está hospedado.
+ `{repo}`: O nome do repositório.
+ `{ref}`: a referência da fonte (ramificação, tag e ID do commit).
+ `{path}`: o caminho do arquivo para a página ou imagem no repositório.
| Provedor de origem | URL da página | URL da imagem |
| --- | --- | --- |
| GitHub | https://github.com/\$1username\$1/\$1repo\$1/blob/\$1ref\$1/\$1path\$1 | `https://github.com/{username}/{repo}/blob/{ref}/{path}?raw=true` `https://raw.githubusercontent.com/{username}/{repo}/{ref}/{path}` |
| GitLab | https://gitlab.com/\$1username\$1/\$1repo\$1/-/blob/\$1ref\$1/\$1path\$1 | https://gitlab.com/\$1username\$1/\$1repo\$1/-/raw/\$1ref\$1/\$1path\$1 |
| Bitbucket | https://bitbucket.org/\$1username\$1/\$1repo\$1/src/\$1ref\$1/\$1path\$1 | https://bitbucket.org/\$1username\$1/\$1repo\$1/raw/\$1ref\$1/\$1path\$1 |
GitHub,GitLab, e Bitbucket suportam páginas e imagens URLs vinculadas a um repositório público. A tabela a seguir mostra o suporte de cada provedor de origem para renderizar imagens e links URLs para repositórios privados.
| Suporte a repositórios privados | Provedor de origem | URL da página | URL da imagem |
| --- | --- | --- | --- |
| GitHub | Somente com acesso ao repositório | Não |
| GitLab | Somente com acesso ao repositório | Não |
| Bitbucket | Somente com acesso ao repositório | Não |
# Solicitando licenças Sentieon para fluxos de trabalho privados
Se seu fluxo de trabalho privado usa o software Sentieon, você precisa de uma licença Senieon. Siga estas etapas para solicitar e configurar uma licença para o software Sentieon:
+ Solicite uma licença Sentieon
+ Envie um e-mail para o grupo de suporte da Sentieon (support@sentieon.com) para solicitar uma licença de software.
+ Forneça seu ID de usuário AWS canônico no e-mail.
+ Encontre sua ID de usuário da AWS Canonical seguindo [estas](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId) instruções.
+ Atualize sua função HealthOmics de serviço para conceder acesso ao proxy do servidor de licenciamento Sentieon e ao bucket do Sentieon Omics em sua região. O exemplo a seguir concede acesso em`us-east-1`. Se necessário, substitua esse texto pela sua região.
------
#### [ 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/*"
]
}
]
}
```
------
+ Gere um caso de AWS suporte para obter acesso ao proxy do servidor de licenças Sentieon.
+ Para criar um caso de suporte, navegue até [support.console.aws.amazon.com](https://support.console.aws.amazon.com).
+ Forneça sua região Conta da AWS e sua região no caso de suporte. Sua conta é adicionada à lista de permissões do proxy do servidor de licenciamento.
+ Crie seu fluxo de trabalho privado usando o contêiner Sentieon e o script de licença Sentieon.
+ Para obter instruções adicionais sobre o uso das ferramentas Sentieon em fluxos de trabalho privados, consulte [Sentieon-Amazon-Omics](https://github.com/Sentieon/sentieon-amazon-omics) em. GitHub
+ A versão 202112.07 e superior do software Sentieon oferece suporte ao proxy do HealthOmics servidor de licenciamento. Para usar as versões do software Sentieon anteriores a 202112.07, entre em contato com o suporte da Sentieon.
# Impressoras de fluxo de trabalho em HealthOmics
Depois de criar um fluxo de trabalho, recomendamos que você execute um linter no fluxo de trabalho antes de iniciar a primeira execução. O linter detecta erros que podem fazer com que a execução falhe.
Para a WDL, executa HealthOmics automaticamente um linter quando você cria o fluxo de trabalho. A saída do linter está disponível no `statusMessage` campo da **get-workflow** resposta. Use o seguinte comando da CLI para recuperar a saída de status (use a ID do fluxo de trabalho do fluxo de trabalho da WDL que você criou):
```
aws omics get-workflow
—id 123456
—query 'statusMessage'
```
HealthOmics fornece ponteiros que você pode executar na definição do fluxo de trabalho antes de criar o fluxo de trabalho. Execute esses linters nos pipelines existentes para os quais você está migrando. HealthOmics
+ **WDL**— Uma imagem pública do Amazon ECR para executar um linter [WDL](https://gallery.ecr.aws/aws-genomics/healthomics-linter).
+ **Nextflow**— Uma imagem pública do Amazon ECR para executar as [regras do Linter]( https://gallery.ecr.aws/aws-genomics/linter-rules-for-nextflow) para o Nextflow. Você pode acessar o código-fonte desse linter em. [GitHub](https://github.com/awslabs/linter-rules-for-nextflow)
+ **CWL**— não disponível
# HealthOmics operações de fluxo de trabalho
Para criar um fluxo de trabalho privado, você precisa:
+ **Workflow definition file:**Um arquivo de definição de fluxo de trabalho escrito em WDLNextflow, ouCWL. A definição do fluxo de trabalho especifica as entradas e saídas para execuções que usam o fluxo de trabalho. Também inclui especificações para as execuções e tarefas de execução do seu fluxo de trabalho, incluindo requisitos de computação e memória. O arquivo de definição do fluxo de trabalho deve estar no `.zip` formato. Para obter mais informações, consulte [Arquivos de definição de fluxo](workflow-definition-files.md) de trabalho em HealthOmics.
+ Você pode usar o [Amazon Q CLI](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) para criar e validar seus arquivos de definição de fluxo de trabalho em WDL, Nextflow e CWL. Para obter mais informações, consulte [Exemplos de solicitações para a Amazon Q CLI](getting-started.md#omics-q-prompts) e [HealthOmics o tutorial de IA generativa da Agentic](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) sobre. GitHub
+ **(Optional) Parameter template file:**Um arquivo de modelo de parâmetro escrito emJSON. Crie o arquivo para definir os parâmetros de execução ou HealthOmics gere o modelo de parâmetro para você. Para obter mais informações, consulte [Arquivos de modelo de parâmetros para HealthOmics fluxos de trabalho](parameter-templates.md).
+ **Amazon ECR container images:**Crie repositórios privados do Amazon ECR para cada contêiner usado no fluxo de trabalho. Crie imagens de contêiner para o fluxo de trabalho e armazene-as em um repositório privado ou sincronize o conteúdo de um registro upstream compatível com seu repositório privado ECR.
+ **(Optional) Sentieon licenses:**Solicite uma Sentieon licença para usar o Sentieon software em fluxos de trabalho privados.
Para arquivos de definição de fluxo de trabalho maiores que 4 MiB (zipados), escolha uma dessas opções durante a criação do fluxo de trabalho:
+ Faça o upload para uma pasta do Amazon Simple Storage Service e especifique a localização.
+ Faça o upload para um repositório externo (tamanho máximo de 1 GiB) e especifique os detalhes do repositório.
Depois de criar um fluxo de trabalho, você pode atualizar as seguintes informações do fluxo de trabalho com a `UpdateWorkflow` operação:
+ Name (Nome)
+ Description
+ Tipo de armazenamento padrão
+ Capacidade de armazenamento padrão (com ID do fluxo de trabalho)
+ Arquivo README.md
Para alterar outras informações no fluxo de trabalho, crie um novo fluxo de trabalho ou uma nova versão do fluxo de trabalho.
Use o controle de versão do fluxo de trabalho para organizar e estruturar seus fluxos de trabalho. As versões também ajudam você a gerenciar a introdução de atualizações iterativas do fluxo de trabalho. Para obter mais informações sobre versões, consulte [Crie uma versão do fluxo de trabalho](workflows-version-create.md).
**Topics**
+ [Crie um fluxo de trabalho privado](create-private-workflow.md)
+ [Atualizar um fluxo de trabalho privado](update-private-workflow.md)
+ [Excluir um fluxo de trabalho privado](delete-private-workflow.md)
+ [Verifique o status do fluxo de trabalho](using-get-workflow.md)
+ [Referenciando arquivos de genoma a partir de uma definição de fluxo de trabalho](create-ref-files.md)
# Crie um fluxo de trabalho privado
Crie um fluxo de trabalho usando o HealthOmics console, os comandos da AWS CLI ou um dos. AWS SDKs
**nota**
Não inclua nenhuma informação de identificação pessoal (PII) nos nomes dos fluxos de trabalho. Esses nomes são visíveis nos CloudWatch registros.
Ao criar um fluxo de trabalho, HealthOmics atribui um identificador exclusivo universal (UUID) ao fluxo de trabalho. O UUID do fluxo de trabalho é um identificador global exclusivo (guid) exclusivo em todos os fluxos de trabalho e versões do fluxo de trabalho. Para fins de proveniência de dados, recomendamos que você use o UUID do fluxo de trabalho para identificar fluxos de trabalho de forma exclusiva.
Se suas tarefas de fluxo de trabalho usarem ferramentas externas (executáveis, bibliotecas ou scripts), você cria essas ferramentas em uma imagem de contêiner. Você tem as seguintes opções para hospedar a imagem do contêiner:
+ Hospede a imagem do contêiner no registro privado do ECR. Pré-requisitos para essa opção:
+ Crie um repositório privado ECR ou escolha um repositório existente.
+ Configure a política de recursos do ECR conforme descrito em[Permissões do Amazon ECR](permissions-ecr.md).
+ Faça upload da imagem do contêiner para o repositório privado.
+ Sincronize a imagem do contêiner com o conteúdo de um registro de terceiros compatível. Pré-requisitos para essa opção:
+ No registro privado do ECR, configure uma regra de cache pull through para cada registro upstream. Para obter mais informações, consulte [Mapeamentos de imagens](workflows-ecr.md#ecr-pull-through-mapping-format).
+ Configure a política de recursos do ECR conforme descrito em[Permissões do Amazon ECR](permissions-ecr.md).
+ Crie modelos de criação de repositórios. O modelo define as configurações para quando o Amazon ECR cria o repositório privado para um registro upstream.
+ Crie mapeamentos de prefixo para remapear referências de imagem de contêiner na definição do fluxo de trabalho para namespaces de cache do ECR.
Ao criar um fluxo de trabalho, você fornece uma definição de fluxo de trabalho que contém informações sobre o fluxo de trabalho, as execuções e as tarefas. HealthOmics pode recuperar a definição do fluxo de trabalho como um arquivo.zip armazenado localmente ou em um bucket do Amazon S3, ou de um repositório compatível baseado em Git.
**Topics**
+ [Criando um fluxo de trabalho usando o console](#console-create-workflows)
+ [Criação de um fluxo de trabalho usando a CLI](#api-create-workflows)
+ [Criação de um fluxo de trabalho usando um SDK](#sdk-create-workflows)
## Criando um fluxo de trabalho usando o console
**Etapas para criar um fluxo de trabalho**
1. Abra o [console do HealthOmics ](https://console.aws.amazon.com/omics/).
1. Se necessário, abra o painel de navegação esquerdo (≡). Escolha **fluxos de trabalho privados**.
1. Na página **Fluxos de trabalho privados**, escolha **Criar fluxo de trabalho**.
1. Na página **Definir fluxo de trabalho**, forneça as seguintes informações:
1. **Nome do fluxo de trabalho**: um nome distinto para esse fluxo de trabalho. Recomendamos definir nomes de fluxo de trabalho para organizar suas execuções no AWS HealthOmics console e nos CloudWatch registros.
1. **Descrição** (opcional): uma descrição desse fluxo de trabalho.
1. No painel **Definição do fluxo** de trabalho, forneça as seguintes informações:
1. **Idioma do fluxo** de trabalho (opcional): selecione o idioma de especificação do fluxo de trabalho. Caso contrário, HealthOmics determina o idioma a partir da definição do fluxo de trabalho.
1. Para a **fonte de definição do fluxo** de trabalho, escolha importar a pasta de definição de um repositório baseado em Git, de um local do Amazon S3 ou de uma unidade local.
1. Para **importar de um serviço de repositório**:
**nota**
HealthOmics suporta repositórios públicos e privados paraGitHub,,GitLab, BitbucketGitHub self-managed,GitLab self-managed.
1. Escolha uma **Conexão** para conectar seus AWS recursos ao repositório externo. Para criar uma conexão, consulte[Conecte-se com repositórios de código externos](setting-up-new.md#setting-up-omics-repository).
**nota**
Os clientes da TLV região precisam criar uma conexão na região IAD (us-east-1) para criar um fluxo de trabalho.
1. Em ID **completa do repositório, insira sua ID do** repositório como nome de usuário/nome do repositório. Verifique se você tem acesso aos arquivos neste repositório.
1. Em **Referência da fonte** (opcional), insira uma referência da fonte do repositório (ramificação, tag ou ID do commit). HealthOmics usa a ramificação padrão se nenhuma referência de origem for especificada.
1. Em **Excluir padrões de arquivo**, insira os padrões de arquivo para excluir pastas, arquivos ou extensões específicas. Isso ajuda a gerenciar o tamanho dos dados ao importar arquivos do repositório. Há no máximo 50 padrões, e os padrões devem seguir a sintaxe do [padrão global](https://fossil-scm.org/home/doc/tip/www/globs.md). Por exemplo:
1. `tests/`
1. `*.jpeg`
1. `large_data.zip`
1. Para **Selecionar pasta de definição do S3:**
1. Insira a localização do Amazon S3 que contém a pasta de definição de fluxo de trabalho compactada. O bucket do Amazon S3 deve estar na mesma região do fluxo de trabalho.
1. Se sua conta não for proprietária do bucket do Amazon S3, insira o ID da AWS conta do proprietário do bucket no ID da conta do **proprietário do bucket do S3**. Essas informações são necessárias para que HealthOmics possamos verificar a propriedade do bucket.
1. Para **Selecionar pasta de definição de uma fonte local**:
1. Insira a localização da unidade local da pasta de definição de fluxo de trabalho compactada.
1. **Caminho do arquivo de definição do fluxo de trabalho principal** (opcional): insira o caminho do arquivo da pasta de definição do fluxo de trabalho compactado ou do repositório para o `main` arquivo. Esse parâmetro não é necessário se houver somente um arquivo na pasta de definição do fluxo de trabalho ou se o arquivo principal tiver o nome “principal”.
1. No painel **Arquivo README** (opcional), selecione a **Fonte do arquivo README** e forneça as seguintes informações:
+ Em **Importar de um serviço de repositório**, em **Caminho do arquivo README**, insira o caminho para o arquivo README dentro do repositório.
+ Em **Selecionar arquivo do S3**, em Arquivo **README no S3, insira o URI do Amazon S3 para o arquivo** README.
+ Em **Selecionar arquivo de uma fonte local**: em **README - opcional**, **escolha Escolher arquivo** para selecionar o arquivo markdown (.md) a ser carregado.
1. No painel **Configuração de armazenamento de execução padrão**, forneça o tipo de armazenamento de execução padrão e a capacidade para execuções que usam esse fluxo de trabalho:
1. **Tipo de execução de armazenamento**: escolha se deseja usar armazenamento estático ou dinâmico como padrão para o armazenamento de execução temporária. O padrão é armazenamento estático.
1. **Capacidade de armazenamento de execução** (opcional): para o tipo de armazenamento de execução estática, você pode inserir a quantidade padrão de armazenamento de execução necessária para esse fluxo de trabalho. O valor padrão para esse parâmetro é 1200 GiB. Você pode substituir esses valores padrão ao iniciar uma execução.
1. **Tags** (opcional): você pode associar até 50 tags a esse fluxo de trabalho.
1. Escolha **Próximo**.
1. Na página **Adicionar parâmetros de fluxo** de trabalho (opcional), selecione a **fonte do parâmetro**:
1. Para **Analisar do arquivo de definição do fluxo de trabalho**, HealthOmics analisará automaticamente os parâmetros do fluxo de trabalho do arquivo de definição do fluxo de trabalho.
1. Para **Fornecer modelo de parâmetro do repositório Git**, use o caminho para o arquivo de modelo de parâmetro do seu repositório.
1. Em **Selecionar arquivo JSON da fonte local**, faça upload de um JSON arquivo de uma fonte local que especifique os parâmetros.
1. Em **Inserir manualmente os parâmetros do fluxo de trabalho**, insira manualmente os nomes e as descrições dos parâmetros.
1. No painel de **visualização de parâmetros**, você pode revisar ou alterar os parâmetros dessa versão do fluxo de trabalho. Se você restaurar o JSON arquivo, perderá todas as alterações locais feitas.
1. Escolha **Próximo**.
1. Na página de **remapeamento de URI de contêiner**, no painel **Regras de mapeamento**, você pode definir regras de mapeamento de URI para seu fluxo de trabalho.
Em **Fonte do arquivo de mapeamento**, selecione uma das seguintes opções:
+ **Nenhuma** — Não são necessárias regras de mapeamento.
+ **Selecione o arquivo JSON do S3** — Especifique a localização do arquivo de mapeamento no S3.
+ **Selecione o arquivo JSON de uma fonte local** — Especifique a localização do arquivo de mapeamento em seu dispositivo local.
+ **Inserir mapeamentos manualmente** **— insira os mapeamentos do registro e os mapeamentos de imagem no painel Mapeamentos.**
1. O console exibe o painel **Mapeamentos.** Se você escolher um arquivo de origem de mapeamento, o console exibirá os valores do arquivo.
1. Em **Mapeamentos do registro**, você pode editar os mapeamentos ou adicionar mapeamentos (máximo de 20 mapeamentos do registro).
Cada mapeamento do registro contém os seguintes campos:
+ **URL do registro upstream** — O URI do registro upstream.
+ Prefixo **do repositório ECR — O prefixo** do repositório a ser usado no repositório privado do Amazon ECR.
+ (Opcional) **Prefixo do repositório upstream** — O prefixo do repositório no registro upstream.
+ (Opcional) **ID da conta ECR** — ID da conta que possui a imagem do contêiner upstream.
1. Em **Mapeamentos de imagem**, você pode editar os mapeamentos de imagem ou adicionar mapeamentos (máximo de 100 mapeamentos de imagem).
Cada mapeamento de imagem contém os seguintes campos:
+ **Imagem de origem** — especifica o URI da imagem de origem no registro upstream.
+ **Imagem de destino** — Especifica o URI da imagem correspondente no registro privado do Amazon ECR.
1. Escolha **Próximo**.
1. Revise a configuração do fluxo de trabalho e escolha **Criar fluxo de trabalho**.
## Criação de um fluxo de trabalho usando a CLI
Se seus arquivos de fluxo de trabalho e o arquivo de modelo de parâmetros estiverem em sua máquina local, você poderá criar um fluxo de trabalho usando o seguinte comando da CLI.
```
aws omics create-workflow \
--name "my_workflow" \
--definition-zip fileb://my-definition.zip \
--parameter-template file://my-parameter-template.json
```
A `create-workflow` operação retorna a seguinte resposta:
```
{
"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"
}
```
### Parâmetros opcionais a serem usados ao criar um fluxo de trabalho
Você pode especificar qualquer um dos parâmetros opcionais ao criar um fluxo de trabalho. Para obter detalhes de sintaxe, consulte [CreateWorkflow](https://docs.aws.amazon.com/omics/latest/api/API_CreateWorkflow.html)a Referência da HealthOmics API da AWS.
**Topics**
+ [Especifique a definição do fluxo de trabalho (localização do Amazon S3)](#create-defn-uri-parameter)
+ [Use a definição de fluxo de trabalho de um repositório baseado em Git](#create-defn-uri-git)
+ [Especificar um arquivo Readme](#specify-readme-file)
+ [Especifique o arquivo **main** de definição](#create-main-parameter)
+ [Especifique o tipo de armazenamento de execução](#create-run-storage-parameter)
+ [Especifique a configuração da GPU](#create-accelerator-parameter)
+ [Configurar parâmetros de mapeamento de cache pull through](#create-prefix-mapping-parameters)
#### Especifique a definição do fluxo de trabalho (localização do Amazon S3)
Se seu arquivo de definição de fluxo de trabalho estiver localizado em uma pasta do Amazon S3, especifique a localização usando o `definition-uri` parâmetro, conforme mostrado no exemplo a seguir. Se sua conta não for proprietária do bucket Amazon S3, forneça o ID do Conta da AWS proprietário.
```
aws omics create-workflow \
--name Test \
--definition-uri s3://omics-bucket/workflow-definition/ \
--owner-id 123456789012
...
```
#### Use a definição de fluxo de trabalho de um repositório baseado em Git
Para usar a definição de fluxo de trabalho de um repositório compatível baseado em Git, use o `definition-repository` parâmetro em sua solicitação. Não forneça nenhum outro `definition` parâmetro, pois uma solicitação falhará se incluir mais de uma fonte de entrada.
O `definition-respository` parâmetro contém os seguintes campos:
+ **connectionArn**— ARN da conexão de código que conecta seus recursos da AWS ao repositório externo.
+ **fullRepositoryId**— Insira o ID do repositório como`owner-name/repo-name`. Verifique se você tem acesso aos arquivos neste repositório.
+ **sourceReference**(Opcional) — Insira um tipo de referência do repositório (BRANCH, TAG ou COMMIT) e um valor.
HealthOmics usa a confirmação mais recente na ramificação padrão se você não especificar uma referência de origem.
+ **excludeFilePatterns**(Opcional) — Insira os padrões de arquivo para excluir pastas, arquivos ou extensões específicas. Isso ajuda a gerenciar o tamanho dos dados ao importar arquivos do repositório. Forneça no máximo 50 padrões. Os padrões devem seguir a sintaxe do padrão [global.](https://fossil-scm.org/home/doc/tip/www/globs.md) Por exemplo:
+ `tests/`
+ `*.jpeg`
+ `large_data.zip`
Ao especificar a definição do fluxo de trabalho em um repositório baseado em Git, use `parameter-template-path` para especificar o arquivo de modelo de parâmetros. Se você não fornecer esse parâmetro, HealthOmics cria o fluxo de trabalho sem um modelo de parâmetro.
O exemplo a seguir mostra os parâmetros relacionados ao conteúdo de um repositório privado baseado em 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" \
```
Para ver mais exemplos, consulte a postagem do blog [Como criar HealthOmics fluxos de trabalho da AWS a partir de conteúdo no Git](https://repost.aws/articles/ARCEN7AjhaRSmteczRoc_QsA/how-to-create-an-aws-healthomics-workflows-from-content-in-git).
#### Especificar um arquivo Readme
Você pode especificar a localização do arquivo README usando um dos seguintes parâmetros:
+ **readme-markdown**— Entrada de string ou um arquivo em sua máquina local.
+ **readme-uri**— O URI de um arquivo armazenado no S3.
+ **readme-path **— O caminho para o arquivo README no repositório.
**Use readme-path somente em conjunto com definition-respository.** Se você não especificar nenhum parâmetro README, HealthOmics importe o arquivo README.md de nível raiz no repositório (se ele existir).
Os exemplos a seguir mostram como especificar a localização do arquivo README usando 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"
```
Para obter mais informações, consulte [HealthOmics Arquivos README do fluxo de trabalho](workflows-readme.md).
#### Especifique o arquivo **main** de definição
Se você estiver incluindo vários arquivos de definição de fluxo de trabalho, use o `main` parâmetro para especificar o arquivo de definição principal para seu fluxo de trabalho.
```
aws omics create-workflow \
--name Test \
--main multi_workflow/workflow2.wdl \
...
```
#### Especifique o tipo de armazenamento de execução
Você pode especificar o tipo de armazenamento de execução padrão (DINÂMICO ou ESTÁTICO) e a capacidade de armazenamento de execução (necessária para armazenamento estático). Para obter mais informações sobre como executar tipos de armazenamento, consulte[Execute tipos de armazenamento em HealthOmics fluxos de trabalho](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 \
```
#### Especifique a configuração da GPU
Use o parâmetro accelerators para criar um fluxo de trabalho executado em uma instância de computação acelerada. O exemplo a seguir mostra como usar o `accelerators` parâmetro. Você especifica a configuração da GPU na definição do fluxo de trabalho. Consulte [Instâncias de computação acelerada](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
```
#### Configurar parâmetros de mapeamento de cache pull through
Se você estiver usando o recurso de mapeamento de cache pull through do Amazon ECR, poderá substituir os mapeamentos padrão. Para obter mais informações sobre os parâmetros de configuração do contêiner, consulte[Imagens de contêiner para fluxos de trabalho privados](workflows-ecr.md).
No exemplo a seguir, o arquivo `mappings.json` contém esse conteúdo:
```
{
"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"
}
]
}
```
Especifique os parâmetros de mapeamento no comando create-workflow:
```
aws omics create-workflow \
...
--container-registry-map-file file://mappings.json
...
```
Você também pode especificar a localização do arquivo de parâmetros de mapeamento no S3:
```
aws omics create-workflow \
...
--container-registry-map-uri s3://amzn-s3-demo-bucket1/test.zip
...
```
## Criação de um fluxo de trabalho usando um SDK
Você pode criar um fluxo de trabalho usando um dos SDKs. O exemplo a seguir mostra como criar um fluxo de trabalho usando o SDK do 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={ ... }
)
```
# Atualizar um fluxo de trabalho privado
Você pode atualizar um fluxo de trabalho usando o HealthOmics console, os comandos da AWS CLI ou um dos. AWS SDKs
**nota**
Não inclua nenhuma informação de identificação pessoal (PII) nos nomes dos fluxos de trabalho. Esses nomes são visíveis nos CloudWatch registros.
**Topics**
+ [Atualizando um fluxo de trabalho usando o console](#console-update-workflows)
+ [Atualizando um fluxo de trabalho usando a CLI](#api-update-workflows)
+ [Atualização de um fluxo de trabalho usando um SDK](#sdk-update-workflows)
## Atualizando um fluxo de trabalho usando o console
**Etapas para atualizar um fluxo de trabalho**
1. Abra o [console do HealthOmics ](https://console.aws.amazon.com/omics/).
1. Se necessário, abra o painel de navegação esquerdo (≡). Escolha **fluxos de trabalho privados**.
1. Na página **Fluxos de trabalho privados**, escolha o fluxo de trabalho a ser atualizado.
1. Na página **Fluxo de trabalho**:
+ Se o fluxo de trabalho tiver versões, certifique-se de selecionar a **versão padrão**.
+ Escolha **Editar selecionado** na lista **Ações**.
1. Na página **Editar fluxo de trabalho**, você pode alterar qualquer um dos seguintes valores:
+ **Nome do fluxo** de trabalho.
+ **Descrição do fluxo** de trabalho.
+ O **tipo padrão de armazenamento Executar** para o fluxo de trabalho.
+ A **capacidade de armazenamento de execução** padrão (se o tipo de armazenamento de execução for armazenamento estático). Para obter mais informações sobre a configuração padrão do armazenamento de execução, consulte[Criando um fluxo de trabalho usando o console](create-private-workflow.md#console-create-workflows).
1. Escolha **Salvar alterações** para aplicar as alterações.
## Atualizando um fluxo de trabalho usando a CLI
Conforme mostrado no exemplo a seguir, você pode atualizar o nome e a descrição do fluxo de trabalho. Você também pode alterar o tipo de armazenamento de execução padrão (ESTÁTICO ou DINÂMICO) e a capacidade de armazenamento de execução (para o tipo de armazenamento estático). Para obter mais informações sobre como executar tipos de armazenamento, consulte[Execute tipos de armazenamento em HealthOmics fluxos de trabalho](workflows-run-types.md).
```
aws omics update-workflow \
--id 1234567 \
--name my_workflow \
--description "updated workflow" \
--storage-type 'STATIC' \
--storage-capacity 1200
```
Você não recebe uma resposta à `update-workflow` solicitação.
## Atualização de um fluxo de trabalho usando um SDK
Você pode atualizar um fluxo de trabalho usando um dos SDKs.
O exemplo a seguir mostra como atualizar um fluxo de trabalho usando o SDK do Python.
```
import boto3
omics = boto3.client('omics')
response = omics.update_workflow(
name='my_workflow',
description='updated workflow'
)
```
# Excluir um fluxo de trabalho privado
Quando você não precisar mais de um fluxo de trabalho, poderá excluí-lo usando o HealthOmics console, os comandos da AWS CLI ou um dos. AWS SDKs Você pode excluir um fluxo de trabalho que atenda aos seguintes critérios:
+ Seu status é ATIVO ou FALHA.
+ Não tem compartilhamentos ativos.
+ Você excluiu todas as versões do fluxo de trabalho.
A exclusão de um fluxo de trabalho não afeta nenhuma execução em andamento que esteja usando o fluxo de trabalho.
**Topics**
+ [Excluindo um fluxo de trabalho usando o console](#console-delete-workflows)
+ [Excluindo um fluxo de trabalho usando a CLI](#api-delete-workflows)
+ [Excluindo um fluxo de trabalho usando um SDK](#sdk-delete-workflows)
## Excluindo um fluxo de trabalho usando o console
**Para excluir um fluxo de trabalho**
1. Abra o [console de HealthOmics ](https://console.aws.amazon.com/omics/).
1. Se necessário, abra o painel de navegação esquerdo (≡). Escolha **fluxos de trabalho privados**.
1. Na página **Fluxos de trabalho privados**, escolha o fluxo de trabalho a ser excluído.
1. Na página **Fluxo de trabalho**, escolha **Excluir selecionado** na lista **Ações**.
1. No modal **Excluir fluxo** de trabalho, insira “confirmar” para confirmar a exclusão.
1. Escolha **Excluir**.
## Excluindo um fluxo de trabalho usando a CLI
O exemplo a seguir mostra como você pode usar o AWS CLI comando para excluir um fluxo de trabalho. Para executar o exemplo, `workflow id` substitua o pelo ID do fluxo de trabalho que você deseja excluir.
```
aws omics delete-workflow
--id workflow id
```
HealthOmics não envia uma resposta à `delete-workflow` solicitação.
## Excluindo um fluxo de trabalho usando um SDK
Você pode excluir um fluxo de trabalho usando um dos SDKs.
O exemplo a seguir mostra como excluir um fluxo de trabalho usando o SDK do Python.
```
import boto3
omics = boto3.client('omics')
response = omics.delete_workflow(
id='1234567'
)
```
# Verifique o status do fluxo de trabalho
Depois de criar seu fluxo de trabalho, você pode verificar o status e visualizar outros detalhes do fluxo de trabalho usando **get-workflow**, conforme mostrado.
```
aws omics get-workflow --id 1234567
```
A resposta inclui detalhes do fluxo de trabalho, incluindo o status, conforme mostrado.
```
{
"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"
}
```
Você pode iniciar uma execução usando esse fluxo de trabalho após a transição do status para`ACTIVE`.
# Referenciando arquivos de genoma a partir de uma definição de fluxo de trabalho
Um objeto de armazenamento de HealthOmics referência pode ser referenciado com um URI como o seguinte. Use o seu próprio `account ID` e `reference ID` onde indicado. `reference store ID`
```
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id
```
Alguns fluxos de trabalho exigirão `INDEX` arquivos `SOURCE` e para o genoma de referência. O URI anterior é o formato abreviado padrão e usará como padrão o arquivo SOURCE. Para especificar qualquer um dos arquivos, você pode usar o formulário URI longo, da seguinte forma.
```
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
```
Usar um conjunto de leitura de sequência teria um padrão semelhante, conforme mostrado.
```
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
```
Alguns conjuntos de leitura, como os baseados no FASTQ, podem conter leituras emparelhadas. Nos exemplos a seguir, eles são chamados de SOURCE1 SOURCE2 e. Formatos como BAM e CRAM terão apenas um SOURCE1 arquivo. Alguns conjuntos de leitura conterão arquivos INDEX, como `crai` arquivos `bai` ou. O URI anterior é o formato abreviado padrão e usará o SOURCE1 arquivo como padrão. Para especificar o arquivo ou índice exato, você pode usar o formato URI longo, da seguinte forma.
```
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
```
Veja a seguir um exemplo de um arquivo JSON de entrada que usa dois 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/"
}
```
Faça referência ao arquivo JSON de entrada no AWS CLI adicionando `--inputs file://` à sua solicitação de **início de execução**.