Usando a interface de linha de comando do TFX

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 se conectar à 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 se conectar à 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:

  1. Verifica se o caminho do pipeline é válido.
  2. Verifica se os detalhes do pipeline foram extraídos com sucesso do arquivo de configuração do pipeline.
  3. Verifica se o DagRunner na configuração do pipeline corresponde ao mecanismo.
  4. 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 se conectar à 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 se conectar à 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 se conectar à 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 se conectar à 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 se conectar à 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 se conectar à 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 se conectar à 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 como AIRFLOW_HOME ou KUBEFLOW_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.
  • (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.