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 canalizaciones, como Kubeflow Pipelines y Vertex Pipelines. El orquestador local también se puede utilizar para un desarrollo o depuración más rápido. Apache Beam y Apache airflow son compatibles como funciones experimentales. Por ejemplo, puede utilizar la CLI para:

  • Cree, actualice y elimine 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 estructura siguiente:

tfx command-group command flags

Actualmente se admiten las siguientes opciones command-group :

  • tfx pipeline : 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 de 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 comandos CLI. Las palabras en banderas están separadas por un guión ( - ) o un guión bajo ( _ ). Por ejemplo, el indicador del nombre de la canalización se puede especificar como --pipeline-name o --pipeline_name . Este documento especifica marcas con guiones bajos para mayor brevedad. Obtenga más información sobre flags utilizadas en TFX CLI .

tubería tfx

La estructura de los comandos en el grupo de comandos 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 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 la canalización.
--endpoint= endpoint

(Opcional). Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 de Kubeflow Jupyter .

--motor= engine

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

  • kubeflow : configura el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vértice : establece el motor en Vertex Pipelines
  • flujo de aire : (experimental) configura el motor en Apache Airflow
  • haz : (experimental) configura el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma predeterminada.

--iap_client_id= iap-client-id
(Opcional.) ID de cliente para el punto final protegido por IAP cuando se utilizan Kubeflow Pipelines.
--namespace= 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 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 utilizará 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 la bandera del motor como en el ejemplo siguiente. 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 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
La ruta al archivo de configuración de la canalización.
--endpoint= endpoint

(Opcional). Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 de Kubeflow Jupyter .

--motor= engine

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

  • kubeflow : configura el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vértice : establece el motor en Vertex Pipelines
  • flujo de aire : (experimental) configura el motor en Apache Airflow
  • haz : (experimental) configura el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma predeterminada.

--iap_client_id= iap-client-id
(Opcional.) ID de cliente para el punto final protegido por IAP.
--namespace= 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 tubería 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 la canalización.
--motor= engine

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

  • kubeflow : configura el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vértice : establece el motor en Vertex Pipelines
  • flujo de aire : (experimental) configura el motor en Apache Airflow
  • haz : (experimental) configura el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local 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

borrar

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

(Opcional). Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 de Kubeflow Jupyter .

--motor= engine

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

  • kubeflow : configura el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vértice : establece el motor en Vertex Pipelines
  • flujo de aire : (experimental) configura el motor en Apache Airflow
  • haz : (experimental) configura el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma predeterminada.

--iap_client_id= iap-client-id
(Opcional.) ID de cliente para el punto final protegido por IAP.
--namespace= 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 determinado.

Uso:

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

(Opcional). Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 de Kubeflow Jupyter .

--motor= engine

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

  • kubeflow : configura el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vértice : establece el motor en Vertex Pipelines
  • flujo de aire : (experimental) configura el motor en Apache Airflow
  • haz : (experimental) configura el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma predeterminada.

--iap_client_id= iap-client-id
(Opcional.) ID de cliente para el punto final protegido por IAP.
--namespace= 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 tfx

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 tfx run .

crear

Crea una nueva instancia de ejecución para una canalización en el orquestador. Para Kubeflow, se utiliza la versió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 del oleoducto.
--endpoint= endpoint

(Opcional). Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 utilizará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : configura el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vértice : establece el motor en Vertex Pipelines
  • flujo de aire : (experimental) configura el motor en Apache Airflow
  • haz : (experimental) configura el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma 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 el punto final protegido por IAP.
--namespace= 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 del 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). Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 utilizará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : configura el motor en Kubeflow

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma predeterminada.

--iap_client_id= iap-client-id
(Opcional.) ID de cliente para el punto final protegido por IAP.
--namespace= 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 tubería.

** Nota importante: actualmente no es compatible con 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 del oleoducto.
--endpoint= endpoint

(Opcional). Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 utilizará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

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

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma predeterminada.

--iap_client_id= iap-client-id
(Opcional.) ID de cliente para el punto final protegido por IAP.
--namespace= 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 es compatible con 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 del oleoducto.
--run_id= run-id
Identificador único para una ejecución de canalización.
--endpoint= endpoint

(Opcional). Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 de Kubeflow Jupyter .

--motor= engine

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

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

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma predeterminada.

--iap_client_id= iap-client-id
(Opcional.) ID de cliente para el punto final protegido por IAP.
--namespace= 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

borrar

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). Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 utilizará para la canalización. El valor del motor debe coincidir con uno de los siguientes valores:

  • kubeflow : configura el motor en Kubeflow

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma predeterminada.

--iap_client_id= iap-client-id
(Opcional.) ID de cliente para el punto final protegido por IAP.
--namespace= 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 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 en el grupo de comandos tfx template . La plantilla es una función 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 del oleoducto.
--destination_path= destination-path
La ruta para copiar la plantilla.

Comprensión de los indicadores TFX CLI

Banderas comunes

--motor= engine

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

  • kubeflow : configura el motor en Kubeflow
  • local : establece el motor en el orquestador local
  • vértice : establece el motor en Vertex Pipelines
  • flujo de aire : (experimental) configura el motor en Apache Airflow
  • haz : (experimental) configura el motor en Apache Beam

Si el motor no está configurado, el motor se detecta automáticamente según el entorno.

** Nota importante: el orquestador requerido por DagRunner en el archivo de configuración de la 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, se utiliza el orquestador local de forma predeterminada.

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

Banderas específicas de Kubeflow

--endpoint= endpoint

Punto final 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 Kubeflow Pipelines. El valor de su punto final debería 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 el 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 el punto final protegido por IAP.
--namespace= 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 gestión de canalizaciones.

  • ${HOME}/tfx/local, haz, flujo de aire, vértice
    • Los metadatos de canalización leídos desde la configuración se almacenan en ${HOME}/tfx/${ORCHESTRATION_ENGINE}/${PIPELINE_NAME} . Esta ubicación se puede personalizar configurando variables de entorno como AIRFLOW_HOME o KUBEFLOW_HOME . Este comportamiento podría cambiar en versiones futuras. Este directorio se utiliza para almacenar información de canalizaciones, incluidos los ID de canalizaciones en el clúster de Kubeflow Pipelines, que se necesita para crear ejecuciones o actualizar canalizaciones.
    • Antes de TFX 0.25, estos archivos estaban ubicados en ${HOME}/${ORCHESTRATION_ENGINE} . En TFX 0.25, los archivos en la ubicación anterior se moverán automáticamente a la nueva ubicación 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 entradas para una canalización. Estos archivos son generados por TFX en el directorio actual.
    • Una es una imagen de contenedor que se utilizará 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 el indicador --build-image . TFX CLI generará Dockerfile si no existe y creará y enviará una imagen de contenedor al registro especificado en KubeflowDagRunnerConfig.