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:
- Comprueba si la ruta de la tubería 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 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 comoAIRFLOW_HOME
oKUBEFLOW_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.
- Los metadatos de canalización leídos desde la configuración se almacenan en
- (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.