Uso de la interfaz de línea de comandos TFX

La interfaz de línea de comandos (CLI) de TFX realiza una gama completa de acciones de canalización utilizando orquestadores de canalización, como Kubeflow Pipelines, Vertex Pipelines. El orquestador local también se puede usar para acelerar el desarrollo o la depuración. Apache Beam y Apache airflow son compatibles como características experimentales. Por ejemplo, puede utilizar la CLI para:

  • Crear, actualizar y eliminar canalizaciones.
  • Ejecute una canalización y supervise la ejecución en varios orquestadores.
  • Enumerar canalizaciones y ejecuciones de canalizaciones.

Acerca de la CLI de TFX

La CLI de TFX se instala como parte del paquete TFX. Todos los comandos CLI siguen la siguiente estructura:

tfx command-group command flags

Actualmente se admiten las siguientes opciones command-group comandos:

  • canalización tfx : cree y administre canalizaciones TFX.
  • tfx run : cree y administre ejecuciones de canalizaciones TFX en varias plataformas de orquestación.
  • Plantilla tfx : comandos experimentales para enumerar y copiar plantillas de canalización TFX.

Cada grupo de comandos proporciona un conjunto de commands . Siga las instrucciones en las secciones comandos de canalización, comandos de ejecución y comandos de plantilla para obtener más información sobre el uso de estos comandos.

Las banderas le permiten pasar argumentos a los comandos CLI. Las palabras en las banderas se separan con un guión ( - ) o un guión bajo ( _ ). Por ejemplo, el indicador de nombre de canalización se puede especificar como --pipeline-name o --pipeline_name . Este documento especifica banderas con guiones bajos para mayor brevedad. Obtenga más información sobre flags utilizadas en TFX CLI .

canalización de tfx

La estructura de los comandos en el grupo de comandos de tfx pipeline es la siguiente:

tfx pipeline command required-flags [optional-flags]

Utilice las siguientes secciones para obtener más información sobre los comandos en el grupo de comandos de tfx pipeline .

crear

Crea una nueva canalización en el orquestador dado.

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
La ruta al archivo de configuración de canalización.
--endpoint= endpoint

(Opcional). Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vertex : establece el motor en Vertex Pipelines
  • flujo de aire: (experimental) establece el motor en Apache Airflow
  • beam : (experimental) establece el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de manera predeterminada.

--iap_client_id= iap-client-id
(Opcional). Id. de cliente para punto final protegido por IAP cuando se utilizan Kubeflow Pipelines.
--namespace= espacio de namespace
(Opcional). Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .
--build_image

(Opcional). Cuando el engine es kubeflow o vertex , TFX crea una imagen de contenedor para su canalización, si se especifica. Se usará `Dockerfile` en el directorio actual, y TFX generará uno automáticamente si no existe.

La imagen creada se enviará al registro remoto que se especifica en `KubeflowDagRunnerConfig` o `KubeflowV2DagRunnerConfig`.

--build_base_image= build-base-image

(Opcional). Cuando el engine es kubeflow , TFX crea una imagen de contenedor para su canalización. La imagen base de compilación especifica la imagen del contenedor base que se usará al crear la imagen del contenedor de canalización.

Ejemplos:

Flujo de Kube:

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 automáticamente el motor desde el entorno del usuario, simplemente evite usar el indicador del motor como en el ejemplo a continuación. Para más detalles, consulta la sección de banderas.

tfx pipeline create --pipeline_path=pipeline-path

actualizar

Actualiza una canalización existente en el orquestador dado.

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
La ruta al archivo de configuración de canalización.
--endpoint= endpoint

(Opcional). Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vertex : establece el motor en Vertex Pipelines
  • flujo de aire: (experimental) establece el motor en Apache Airflow
  • beam : (experimental) establece el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de manera predeterminada.

--iap_client_id= iap-client-id
(Opcional). Id. de cliente para punto final protegido por IAP.
--namespace= espacio de namespace
(Opcional). Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .
--build_image

(Opcional). Cuando el engine es kubeflow o vertex , TFX crea una imagen de contenedor para su canalización, si se especifica. Se utilizará `Dockerfile` en el directorio actual.

La imagen creada se enviará al registro remoto que se especifica en `KubeflowDagRunnerConfig` o `KubeflowV2DagRunnerConfig`.

Ejemplos:

Flujo de Kube:

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 el archivo de configuración de la canalización para crear un archivo de flujo de trabajo en Kubeflow y realiza las siguientes comprobaciones durante la compilación:

  1. Comprueba si la ruta de la canalización es válida.
  2. Comprueba si los detalles de la canalización se extraen correctamente del archivo de configuración de la canalización.
  3. Comprueba si el DagRunner en la configuración de la canalización coincide con el motor.
  4. Comprueba si el archivo de flujo de trabajo se creó correctamente en la ruta del paquete proporcionada (solo para Kubeflow).

Recomendado para usar antes de crear o actualizar una canalización.

Uso:

tfx pipeline compile --pipeline_path=pipeline-path [--engine=engine]
--pipeline_path= pipeline-path
La ruta al archivo de configuración de canalización.
--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vertex : establece el motor en Vertex Pipelines
  • flujo de aire: (experimental) establece el motor en Apache Airflow
  • beam : (experimental) establece el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de forma predeterminada.

Ejemplos:

Flujo de Kube:

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

Eliminar

Elimina una canalización del orquestador dado.

Uso:

tfx pipeline delete --pipeline_path=pipeline-path [--endpoint=endpoint --engine=engine \
--iap_client_id=iap-client-id --namespace=namespace]
--pipeline_path= pipeline-path
La ruta al archivo de configuración de canalización.
--endpoint= endpoint

(Opcional). Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vertex : establece el motor en Vertex Pipelines
  • flujo de aire: (experimental) establece el motor en Apache Airflow
  • beam : (experimental) establece el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de forma predeterminada.

--iap_client_id= iap-client-id
(Opcional). Id. de cliente para punto final protegido por IAP.
--namespace= espacio de namespace
(Opcional). Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .

Ejemplos:

Flujo de Kube:

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

Enumera todas las canalizaciones en el orquestador dado.

Uso:

tfx pipeline list [--endpoint=endpoint --engine=engine \
--iap_client_id=iap-client-id --namespace=namespace]
--endpoint= endpoint

(Opcional). Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vertex : establece el motor en Vertex Pipelines
  • flujo de aire: (experimental) establece el motor en Apache Airflow
  • beam : (experimental) establece el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de manera predeterminada.

--iap_client_id= iap-client-id
(Opcional). Id. de cliente para punto final protegido por IAP.
--namespace= espacio de namespace
(Opcional). Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .

Ejemplos:

Flujo de Kube:

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

ejecutar

La estructura de los comandos en el grupo de comandos tfx run es la siguiente:

tfx run command required-flags [optional-flags]

Utilice las siguientes secciones para obtener más información sobre los comandos en el grupo de comandos de tfx run .

crear

Crea una nueva instancia de ejecución para una canalización en el orquestador. Para Kubeflow, se usa la versión de canalización más reciente de la canalización en el clúster.

Uso:

tfx run create --pipeline_name=pipeline-name [--endpoint=endpoint \
--engine=engine --iap_client_id=iap-client-id --namespace=namespace]
--pipeline_name= pipeline-name
El nombre de la tubería.
--endpoint= endpoint

(Opcional). Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vertex : establece el motor en Vertex Pipelines
  • flujo de aire: (experimental) establece el motor en Apache Airflow
  • beam : (experimental) establece el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de manera predeterminada.

--runtime_parameter= parameter-name parameter-value
(Opcional). Establece un valor de parámetro de tiempo de ejecución. Se puede configurar varias veces para establecer valores de múltiples variables. Solo aplicable a los motores `airflow`, `kubeflow` y `vertex`.
--iap_client_id= iap-client-id
(Opcional). Id. de cliente para punto final protegido por IAP.
--namespace= espacio de namespace
(Opcional). Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .
--project= GCP-project-id
(Obligatorio para Vertex). Id. de proyecto de GCP para la canalización de Vertex.
--region= GCP-region
(Obligatorio para Vertex). Nombre de región de GCP como us-central1. Consulte la [documentación de Vertex](https://cloud.google.com/vertex-ai/docs/general/locations) para conocer las regiones disponibles.

Ejemplos:

Flujo de Kube:

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

Detiene una ejecución de una canalización determinada.

** Nota importante: actualmente solo se admite en 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 único para una ejecución de canalización.
--endpoint= endpoint

(Opcional). Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de manera predeterminada.

--iap_client_id= iap-client-id
(Opcional). Id. de cliente para punto final protegido por IAP.
--namespace= espacio de namespace
(Opcional). Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .

Ejemplos:

Flujo de Kube:

tfx run delete --engine=kubeflow --run_id=run-id --iap_client_id=iap-client-id \
--namespace=namespace --endpoint=endpoint

lista

Enumera todas las ejecuciones de una canalización.

** Nota importante: actualmente no se admite en Local y 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
El nombre de la tubería.
--endpoint= endpoint

(Opcional). Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow
  • flujo de aire: (experimental) establece el motor en Apache Airflow

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de manera predeterminada.

--iap_client_id= iap-client-id
(Opcional). Id. de cliente para punto final protegido por IAP.
--namespace= espacio de namespace
(Opcional). Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .

Ejemplos:

Flujo de Kube:

tfx run list --engine=kubeflow --pipeline_name=pipeline-name --iap_client_id=iap-client-id \
--namespace=namespace --endpoint=endpoint

estado

Devuelve el estado actual de una ejecución.

** Nota importante: actualmente no se admite en Local y 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
El nombre de la tubería.
--run_id= run-id
Identificador único para una ejecución de canalización.
--endpoint= endpoint

(Opcional). Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow
  • flujo de aire: (experimental) establece el motor en Apache Airflow

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de manera predeterminada.

--iap_client_id= iap-client-id
(Opcional). Id. de cliente para punto final protegido por IAP.
--namespace= espacio de namespace
(Opcional). Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .

Ejemplos:

Flujo de Kube:

tfx run status --engine=kubeflow --run_id=run-id --pipeline_name=pipeline-name \
--iap_client_id=iap-client-id --namespace=namespace --endpoint=endpoint

Eliminar

Elimina una ejecución de una canalización determinada.

** Nota importante: actualmente solo se admite en 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 único para una ejecución de canalización.
--endpoint= endpoint

(Opcional). Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--motor= engine

(Opcional). El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de manera predeterminada.

--iap_client_id= iap-client-id
(Opcional). Id. de cliente para punto final protegido por IAP.
--namespace= espacio de namespace
(Opcional). Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .

Ejemplos:

Flujo de Kube:

tfx run delete --engine=kubeflow --run_id=run-id --iap_client_id=iap-client-id \
--namespace=namespace --endpoint=endpoint

plantilla tfx [Experimental]

La estructura de los comandos en el grupo de comandos de la tfx template es la siguiente:

tfx template command required-flags [optional-flags]

Utilice las siguientes secciones para obtener más información sobre los comandos del grupo de comandos de la tfx template . La plantilla es una característica experimental y está sujeta a cambios en cualquier momento.

lista

Enumere las plantillas de canalización TFX disponibles.

Uso:

tfx template list

Copiar

Copie una plantilla en el directorio de destino.

Uso:

tfx template copy --model=model --pipeline_name=pipeline-name \
--destination_path=destination-path
--modelo= model
El nombre del modelo creado por la plantilla de canalización.
--pipeline_name= pipeline-name
El nombre de la tubería.
--destination_path= destination-path
La ruta para copiar la plantilla.

Comprensión de las banderas de la CLI de TFX

Banderas comunes

--motor= engine

El orquestador que se usará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : establece el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vertex : establece el motor en Vertex Pipelines
  • flujo de aire: (experimental) establece el motor en Apache Airflow
  • beam : (experimental) establece el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente en función del entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de canalización debe coincidir con el motor seleccionado o detectado automáticamente. La detección automática del motor se basa en el entorno del usuario. Si Apache Airflow y Kubeflow Pipelines no están instalados, el orquestador local se usa de manera predeterminada.

--pipeline_name= pipeline-name
El nombre de la tubería.
--pipeline_path= pipeline-path
La ruta al archivo de configuración de canalización.
--run_id= run-id
Identificador único para una ejecución de canalización.

Indicadores específicos de Kubeflow

--endpoint= endpoint

Extremo del servicio API de Kubeflow Pipelines. El punto final de su servicio API de Kubeflow Pipelines es el mismo que la URL del panel de control de Kubeflow Pipelines. Su valor de punto final debe ser algo como:

https://host-name/pipeline

Si no conoce el punto final de su clúster de Kubeflow Pipelines, comuníquese con el administrador del clúster.

Si no se especifica --endpoint , el nombre DNS del servicio en clúster se utiliza como valor predeterminado. Este nombre solo funciona si el comando CLI se ejecuta en un pod en el clúster de Kubeflow Pipelines, como una instancia de cuadernos Kubeflow Jupyter .

--iap_client_id= iap-client-id
ID de cliente para punto final protegido por IAP.
--namespace= espacio de namespace
Espacio de nombres de Kubernetes para conectarse a la API de Kubeflow Pipelines. Si no se especifica el espacio de nombres, el valor predeterminado es kubeflow .

Archivos generados por TFX CLI

Cuando se crean y ejecutan canalizaciones, se generan varios archivos para la administración de canalizaciones.

  • ${HOME}/tfx/local, haz, flujo de aire, vértice
    • Los metadatos de canalización leídos de la configuración se almacenan en ${HOME}/tfx/${ORCHESTRATION_ENGINE}/${PIPELINE_NAME} . Esta ubicación se puede personalizar configurando una variable de entorno como AIRFLOW_HOME o KUBEFLOW_HOME . Es posible que este comportamiento cambie en versiones futuras. Este directorio se usa para almacenar información de canalización, incluidos los ID de canalización en el clúster de canalizaciones de Kubeflow, que se necesita para crear ejecuciones o actualizar canalizaciones.
    • Antes de TFX 0.25, estos archivos se ubicaban en ${HOME}/${ORCHESTRATION_ENGINE} . En TFX 0.25, los archivos en la ubicación anterior se moverán a la nueva ubicación automáticamente para una migración sin problemas.
    • Desde TFX 0.27, kubeflow no crea estos archivos de metadatos en el sistema de archivos local. Sin embargo, consulte a continuación otros archivos que crea kubeflow.
  • (Solo Kubeflow) Dockerfile y una imagen de contenedor
    • Kubeflow Pipelines requiere dos tipos de entrada para una canalización. Estos archivos son generados por TFX en el directorio actual.
    • Una es una imagen de contenedor que se usará para ejecutar componentes en la canalización. Esta imagen de contenedor se crea cuando se crea o actualiza una canalización para Kubeflow Pipelines con --build-image . TFX CLI generará Dockerfile si no existe, y creará y enviará una imagen de contenedor al registro especificado en KubeflowDagRunnerConfig.