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:
- Comprueba si la ruta de la canalización es válida.
- Comprueba si los detalles de la canalización se extraen correctamente del archivo de configuración de la canalización.
- Comprueba si el DagRunner en la configuración de la canalización coincide con el motor.
- 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 comoAIRFLOW_HOME
oKUBEFLOW_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.
- Los metadatos de canalización leídos de la configuración se almacenan en
- (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.