A interface de linha de comando (CLI) do TFX executa uma gama completa de ações de pipeline usando orquestradores de pipeline, como Kubeflow Pipelines, Vertex Pipelines. O orquestrador local também pode ser usado para desenvolvimento ou depuração mais rápidos. Apache Beam e Apache Airflow são suportados como recursos experimentais. Por exemplo, você pode usar a CLI para:
- Crie, atualize e exclua pipelines.
- Execute um pipeline e monitore a execução em vários orquestradores.
- Listar pipelines e execuções de pipeline.
Sobre a CLI do TFX
A CLI do TFX é instalada como parte do pacote TFX. Todos os comandos CLI seguem a estrutura abaixo:
tfx command-group command flags
As seguintes opções command-group são atualmente suportadas:
- pipeline tfx - Crie e gerencie pipelines TFX.
- tfx run - Crie e gerencie execuções de pipelines TFX em várias plataformas de orquestração.
- modelo tfx - Comandos experimentais para listar e copiar modelos de pipeline TFX.
Cada grupo de comandos fornece um conjunto de commands . Siga as instruções nas seções comandos de pipeline , comandos de execução e comandos de modelo para saber mais sobre como usar esses comandos.
Os sinalizadores permitem passar argumentos para comandos CLI. As palavras nos sinalizadores são separadas por um hífen ( -
) ou sublinhado ( _
). Por exemplo, o sinalizador do nome do pipeline pode ser especificado como --pipeline-name
ou --pipeline_name
. Este documento especifica sinalizadores com sublinhados por questões de brevidade. Saiba mais sobre flags usados na CLI do TFX .
pipeline tfx
A estrutura dos comandos no grupo de comandos tfx pipeline
é a seguinte:
tfx pipeline command required-flags [optional-flags]
Use as seções a seguir para saber mais sobre os comandos no grupo de comandos tfx pipeline
.
criar
Cria um novo pipeline no orquestrador fornecido.
Uso:
tfx pipeline create --pipeline_path=pipeline-path [--endpoint=endpoint --engine=engine \ --iap_client_id=iap-client-id --namespace=namespace \ --build_image --build_base_image=build-base-image]
- --pipeline_path= pipeline-path
- O caminho para o arquivo de configuração do pipeline.
- --ponto final= endpoint
(Opcional.) Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
- local : define o mecanismo para o orquestrador local
- vertex : define o mecanismo para Vertex Pipelines
- airflow : (experimental) define o mecanismo para Apache Airflow
- beam : (experimental) define o mecanismo para Apache Beam
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --iap_client_id= iap-client-id
- (Opcional.) ID do cliente para endpoint protegido por IAP ao usar Kubeflow Pipelines.
- --namespace= namespace
- (Opcional.) Namespace Kubernetes para conectar-se à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
. - --build_image
(Opcional.) Quando o engine é kubeflow ou vertex , o TFX cria uma imagem de contêiner para seu pipeline, se especificado. `Dockerfile` no diretório atual será usado e o TFX irá gerar um automaticamente se não existir.
A imagem construída será enviada para o registro remoto especificado em `KubeflowDagRunnerConfig` ou `KubeflowV2DagRunnerConfig`.
- --build_base_image= build-base-image
(Opcional.) Quando o engine é kubeflow , o TFX cria uma imagem de contêiner para seu pipeline. A imagem base de build especifica a imagem de contêiner base a ser usada ao criar a imagem de contêiner de pipeline.
Exemplos:
Kubeflow:
tfx pipeline create --engine=kubeflow --pipeline_path=pipeline-path \ --iap_client_id=iap-client-id --namespace=namespace --endpoint=endpoint \ --build_image
Local:
tfx pipeline create --engine=local --pipeline_path=pipeline-path
Vértice:
tfx pipeline create --engine=vertex --pipeline_path=pipeline-path \ --build_image
Para detectar automaticamente o mecanismo do ambiente do usuário, simplesmente evite usar o sinalizador do mecanismo como no exemplo abaixo. Para mais detalhes, verifique a seção de sinalizadores.
tfx pipeline create --pipeline_path=pipeline-path
atualizar
Atualiza um pipeline existente no orquestrador determinado.
Uso:
tfx pipeline update --pipeline_path=pipeline-path [--endpoint=endpoint --engine=engine \ --iap_client_id=iap-client-id --namespace=namespace --build_image]
- --pipeline_path= pipeline-path
- O caminho para o arquivo de configuração do pipeline.
- --ponto final= endpoint
(Opcional.) Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
- local : define o mecanismo para o orquestrador local
- vertex : define o mecanismo para Vertex Pipelines
- airflow : (experimental) define o mecanismo para Apache Airflow
- beam : (experimental) define o mecanismo para Apache Beam
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --iap_client_id= iap-client-id
- (Opcional.) ID do cliente para endpoint protegido por IAP.
- --namespace= namespace
- (Opcional.) Namespace Kubernetes para conectar-se à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
. - --build_image
(Opcional.) Quando o engine é kubeflow ou vertex , o TFX cria uma imagem de contêiner para seu pipeline, se especificado. `Dockerfile` no diretório atual será usado.
A imagem construída será enviada para o registro remoto especificado em `KubeflowDagRunnerConfig` ou `KubeflowV2DagRunnerConfig`.
Exemplos:
Kubeflow:
tfx pipeline update --engine=kubeflow --pipeline_path=pipeline-path \ --iap_client_id=iap-client-id --namespace=namespace --endpoint=endpoint \ --build_image
Local:
tfx pipeline update --engine=local --pipeline_path=pipeline-path
Vértice:
tfx pipeline update --engine=vertex --pipeline_path=pipeline-path \ --build_image
compilar
Compila o arquivo de configuração do pipeline para criar um arquivo de fluxo de trabalho no Kubeflow e executa as seguintes verificações durante a compilação:
- Verifica se o caminho do pipeline é válido.
- Verifica se os detalhes do pipeline foram extraídos com sucesso do arquivo de configuração do pipeline.
- Verifica se o DagRunner na configuração do pipeline corresponde ao mecanismo.
- Verifica se o arquivo de fluxo de trabalho foi criado com sucesso no caminho do pacote fornecido (somente para Kubeflow).
Recomendado para uso antes de criar ou atualizar um pipeline.
Uso:
tfx pipeline compile --pipeline_path=pipeline-path [--engine=engine]
- --pipeline_path= pipeline-path
- O caminho para o arquivo de configuração do pipeline.
- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
- local : define o mecanismo para o orquestrador local
- vertex : define o mecanismo para Vertex Pipelines
- airflow : (experimental) define o mecanismo para Apache Airflow
- beam : (experimental) define o mecanismo para Apache Beam
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
Exemplos:
Kubeflow:
tfx pipeline compile --engine=kubeflow --pipeline_path=pipeline-path
Local:
tfx pipeline compile --engine=local --pipeline_path=pipeline-path
Vértice:
tfx pipeline compile --engine=vertex --pipeline_path=pipeline-path
excluir
Exclui um pipeline do orquestrador determinado.
Uso:
tfx pipeline delete --pipeline_path=pipeline-path [--endpoint=endpoint --engine=engine \ --iap_client_id=iap-client-id --namespace=namespace]
- --pipeline_path= pipeline-path
- O caminho para o arquivo de configuração do pipeline.
- --ponto final= endpoint
(Opcional.) Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
- local : define o mecanismo para o orquestrador local
- vertex : define o mecanismo para Vertex Pipelines
- airflow : (experimental) define o mecanismo para Apache Airflow
- beam : (experimental) define o mecanismo para Apache Beam
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --iap_client_id= iap-client-id
- (Opcional.) ID do cliente para endpoint protegido por IAP.
- --namespace= namespace
- (Opcional.) Namespace Kubernetes para conectar-se à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
.
Exemplos:
Kubeflow:
tfx pipeline delete --engine=kubeflow --pipeline_name=pipeline-name \ --iap_client_id=iap-client-id --namespace=namespace --endpoint=endpoint
Local:
tfx pipeline delete --engine=local --pipeline_name=pipeline-name
Vértice:
tfx pipeline delete --engine=vertex --pipeline_name=pipeline-name
lista
Lista todos os pipelines no orquestrador determinado.
Uso:
tfx pipeline list [--endpoint=endpoint --engine=engine \ --iap_client_id=iap-client-id --namespace=namespace]
- --ponto final= endpoint
(Opcional.) Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
- local : define o mecanismo para o orquestrador local
- vertex : define o mecanismo para Vertex Pipelines
- airflow : (experimental) define o mecanismo para Apache Airflow
- beam : (experimental) define o mecanismo para Apache Beam
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --iap_client_id= iap-client-id
- (Opcional.) ID do cliente para endpoint protegido por IAP.
- --namespace= namespace
- (Opcional.) Namespace Kubernetes para conectar-se à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
.
Exemplos:
Kubeflow:
tfx pipeline list --engine=kubeflow --iap_client_id=iap-client-id \ --namespace=namespace --endpoint=endpoint
Local:
tfx pipeline list --engine=local
Vértice:
tfx pipeline list --engine=vertex
corrida tfx
A estrutura dos comandos no grupo de comandos tfx run
é a seguinte:
tfx run command required-flags [optional-flags]
Use as seções a seguir para saber mais sobre os comandos do grupo de comandos tfx run
.
criar
Cria uma nova instância de execução para um pipeline no orquestrador. Para o Kubeflow, é usada a versão mais recente do pipeline no cluster.
Uso:
tfx run create --pipeline_name=pipeline-name [--endpoint=endpoint \ --engine=engine --iap_client_id=iap-client-id --namespace=namespace]
- --pipeline_name= pipeline-name
- O nome do pipeline.
- --ponto final= endpoint
(Opcional.) Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
- local : define o mecanismo para o orquestrador local
- vertex : define o mecanismo para Vertex Pipelines
- airflow : (experimental) define o mecanismo para Apache Airflow
- beam : (experimental) define o mecanismo para Apache Beam
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --runtime_parameter= parameter-name = parameter-value
- (Opcional.) Define um valor de parâmetro de tempo de execução. Pode ser definido várias vezes para definir valores de múltiplas variáveis. Aplicável apenas aos mecanismos `airflow`, `kubeflow` e `vertex`.
- --iap_client_id= iap-client-id
- (Opcional.) ID do cliente para endpoint protegido por IAP.
- --namespace= namespace
- (Opcional.) Namespace Kubernetes para conectar-se à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
. - --project= GCP-project-id
- (Obrigatório para Vertex.) ID do projeto GCP para o pipeline de vértice.
- --region= GCP-region
- (Obrigatório para Vertex.) Nome da região do GCP como us-central1. Consulte a [documentação da Vertex](https://cloud.google.com/vertex-ai/docs/general/locations) para ver as regiões disponíveis.
Exemplos:
Kubeflow:
tfx run create --engine=kubeflow --pipeline_name=pipeline-name --iap_client_id=iap-client-id \ --namespace=namespace --endpoint=endpoint
Local:
tfx run create --engine=local --pipeline_name=pipeline-name
Vértice:
tfx run create --engine=vertex --pipeline_name=pipeline-name \ --runtime_parameter=var_name=var_value \ --project=gcp-project-id --region=gcp-region
terminar
Interrompe a execução de um determinado pipeline.
** Observação importante: atualmente compatível apenas com Kubeflow.
Uso:
tfx run terminate --run_id=run-id [--endpoint=endpoint --engine=engine \ --iap_client_id=iap-client-id --namespace=namespace]
- --run_id= run-id
- Identificador exclusivo para uma execução de pipeline.
- --ponto final= endpoint
(Opcional.) Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --iap_client_id= iap-client-id
- (Opcional.) ID do cliente para endpoint protegido por IAP.
- --namespace= namespace
- (Opcional.) Namespace Kubernetes para conectar-se à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
.
Exemplos:
Kubeflow:
tfx run delete --engine=kubeflow --run_id=run-id --iap_client_id=iap-client-id \ --namespace=namespace --endpoint=endpoint
lista
Lista todas as execuções de um pipeline.
** Observação importante: atualmente não é compatível com Local e Apache Beam.
Uso:
tfx run list --pipeline_name=pipeline-name [--endpoint=endpoint \ --engine=engine --iap_client_id=iap-client-id --namespace=namespace]
- --pipeline_name= pipeline-name
- O nome do pipeline.
- --ponto final= endpoint
(Opcional.) Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
- airflow : (experimental) define o mecanismo para Apache Airflow
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --iap_client_id= iap-client-id
- (Opcional.) ID do cliente para endpoint protegido por IAP.
- --namespace= namespace
- (Opcional.) Namespace Kubernetes para conectar-se à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
.
Exemplos:
Kubeflow:
tfx run list --engine=kubeflow --pipeline_name=pipeline-name --iap_client_id=iap-client-id \ --namespace=namespace --endpoint=endpoint
status
Retorna o status atual de uma execução.
** Observação importante: atualmente não é compatível com Local e Apache Beam.
Uso:
tfx run status --pipeline_name=pipeline-name --run_id=run-id [--endpoint=endpoint \ --engine=engine --iap_client_id=iap-client-id --namespace=namespace]
- --pipeline_name= pipeline-name
- O nome do pipeline.
- --run_id= run-id
- Identificador exclusivo para uma execução de pipeline.
- --ponto final= endpoint
(Opcional.) Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
- airflow : (experimental) define o mecanismo para Apache Airflow
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --iap_client_id= iap-client-id
- (Opcional.) ID do cliente para endpoint protegido por IAP.
- --namespace= namespace
- (Opcional.) Namespace Kubernetes para conectar-se à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
.
Exemplos:
Kubeflow:
tfx run status --engine=kubeflow --run_id=run-id --pipeline_name=pipeline-name \ --iap_client_id=iap-client-id --namespace=namespace --endpoint=endpoint
excluir
Exclui uma execução de um determinado pipeline.
** Observação importante: atualmente compatível apenas com Kubeflow
Uso:
tfx run delete --run_id=run-id [--engine=engine --iap_client_id=iap-client-id \ --namespace=namespace --endpoint=endpoint]
- --run_id= run-id
- Identificador exclusivo para uma execução de pipeline.
- --ponto final= endpoint
(Opcional.) Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --motor= engine
(Opcional.) O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --iap_client_id= iap-client-id
- (Opcional.) ID do cliente para endpoint protegido por IAP.
- --namespace= namespace
- (Opcional.) Namespace Kubernetes para conectar-se à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
.
Exemplos:
Kubeflow:
tfx run delete --engine=kubeflow --run_id=run-id --iap_client_id=iap-client-id \ --namespace=namespace --endpoint=endpoint
modelo tfx [Experimental]
A estrutura dos comandos no grupo de comandos tfx template
é a seguinte:
tfx template command required-flags [optional-flags]
Use as seções a seguir para saber mais sobre os comandos no grupo de comandos tfx template
. O modelo é um recurso experimental e está sujeito a alterações a qualquer momento.
lista
Liste os modelos de pipeline do TFX disponíveis.
Uso:
tfx template list
cópia
Copie um modelo para o diretório de destino.
Uso:
tfx template copy --model=model --pipeline_name=pipeline-name \ --destination_path=destination-path
- --modelo= model
- O nome do modelo criado pelo modelo de pipeline.
- --pipeline_name= pipeline-name
- O nome do pipeline.
- --destination_path= destination-path
- O caminho para onde copiar o modelo.
Compreendendo os sinalizadores TFX CLI
Sinalizadores comuns
- --motor= engine
O orquestrador a ser usado para o pipeline. O valor do motor deve corresponder a um dos seguintes valores:
- kubeflow : define o mecanismo para Kubeflow
- local : define o mecanismo para o orquestrador local
- vertex : define o mecanismo para Vertex Pipelines
- airflow : (experimental) define o mecanismo para Apache Airflow
- beam : (experimental) define o mecanismo para Apache Beam
Se o mecanismo não estiver configurado, ele será detectado automaticamente com base no ambiente.
** Nota importante: O orquestrador exigido pelo DagRunner no arquivo de configuração do pipeline deve corresponder ao mecanismo selecionado ou detectado automaticamente. A detecção automática do mecanismo é baseada no ambiente do usuário. Se o Apache Airflow e o Kubeflow Pipelines não estiverem instalados, o orquestrador local será usado por padrão.
- --pipeline_name= pipeline-name
- O nome do pipeline.
- --pipeline_path= pipeline-path
- O caminho para o arquivo de configuração do pipeline.
- --run_id= run-id
- Identificador exclusivo para uma execução de pipeline.
Sinalizadores específicos do Kubeflow
- --ponto final= endpoint
Endpoint do serviço da API Kubeflow Pipelines. O endpoint do seu serviço de API do Kubeflow Pipelines é o mesmo que o URL do painel do Kubeflow Pipelines. O valor do seu endpoint deve ser algo como:
https://host-name/pipeline
Se você não conhece o endpoint do cluster do Kubeflow Pipelines, entre em contato com o administrador do cluster.
Se
--endpoint
não for especificado, o nome DNS do serviço no cluster será usado como valor padrão. Esse nome funciona apenas se o comando CLI for executado em um pod no cluster Kubeflow Pipelines, como uma instância de notebooks Kubeflow Jupyter .- --iap_client_id= iap-client-id
- ID do cliente para endpoint protegido por IAP.
- --namespace= namespace
- Namespace Kubernetes para se conectar à API Kubeflow Pipelines. Se o namespace não for especificado, o valor padrão será
kubeflow
.
Arquivos gerados pelo TFX CLI
Quando pipelines são criados e executados, vários arquivos são gerados para gerenciamento de pipeline.
- ${HOME}/tfx/local, feixe, fluxo de ar, vértice
- Os metadados do pipeline lidos da configuração são armazenados em
${HOME}/tfx/${ORCHESTRATION_ENGINE}/${PIPELINE_NAME}
. Este local pode ser personalizado definindo uma variável de ambiente comoAIRFLOW_HOME
ouKUBEFLOW_HOME
. Este comportamento poderá ser alterado em versões futuras. Este diretório é usado para armazenar informações de pipeline, incluindo IDs de pipeline no cluster Kubeflow Pipelines, que são necessários para criar execuções ou atualizar pipelines. - Antes do TFX 0.25, esses arquivos estavam localizados em
${HOME}/${ORCHESTRATION_ENGINE}
. No TFX 0.25, os arquivos no local antigo serão movidos automaticamente para o novo local para uma migração tranquila. - A partir do TFX 0.27, o kubeflow não cria esses arquivos de metadados no sistema de arquivos local. No entanto, veja abaixo outros arquivos que o kubeflow cria.
- Os metadados do pipeline lidos da configuração são armazenados em
- (somente Kubeflow) Dockerfile e uma imagem de contêiner
- O Kubeflow Pipelines requer dois tipos de entrada para um pipeline. Esses arquivos são gerados pelo TFX no diretório atual.
- Uma é uma imagem de contêiner que será usada para executar componentes no pipeline. Esta imagem de contêiner é criada quando um pipeline para Kubeflow Pipelines é criado ou atualizado com o sinalizador
--build-image
. A CLI do TFX geraráDockerfile
se não existir e criará e enviará uma imagem de contêiner para o registro especificado em KubeflowDagRunnerConfig.