Utilisation de l'interface de ligne de commande TFX

L'interface de ligne de commande (CLI) TFX exécute une gamme complète d'actions de pipeline à l'aide d'orchestrateurs de pipeline, tels que Kubeflow Pipelines et Vertex Pipelines. L'orchestrateur local peut également être utilisé pour un développement ou un débogage plus rapide. Apache Beam et Apache airflow sont pris en charge en tant que fonctionnalités expérimentales. Par exemple, vous pouvez utiliser la CLI pour :

  • Créez, mettez à jour et supprimez des pipelines.
  • Exécutez un pipeline et surveillez l'exécution sur différents orchestrateurs.
  • Répertoriez les pipelines et les exécutions de pipeline.

À propos de la CLI TFX

La CLI TFX est installée dans le cadre du package TFX. Toutes les commandes CLI suivent la structure ci-dessous :

tfx command-group command flags

Les options command-group suivantes sont actuellement prises en charge :

  • pipeline tfx - Créez et gérez des pipelines TFX.
  • tfx run - Créez et gérez des exécutions de pipelines TFX sur diverses plates-formes d'orchestration.
  • tfx template - Commandes expérimentales pour répertorier et copier les modèles de pipeline TFX.

Chaque groupe de commandes fournit un ensemble de commands . Suivez les instructions des sections Commandes de pipeline , Commandes d'exécution et Commandes de modèle pour en savoir plus sur l'utilisation de ces commandes.

Les indicateurs vous permettent de transmettre des arguments aux commandes CLI. Les mots dans les drapeaux sont séparés par un trait d'union ( - ) ou un trait de soulignement ( _ ). Par exemple, l'indicateur de nom de pipeline peut être spécifié sous la forme --pipeline-name ou --pipeline_name . Ce document spécifie les indicateurs avec des traits de soulignement par souci de concision. En savoir plus sur flags utilisés dans la CLI TFX .

pipeline d'effets de change

La structure des commandes du groupe de commandes tfx pipeline est la suivante :

tfx pipeline command required-flags [optional-flags]

Utilisez les sections suivantes pour en savoir plus sur les commandes du groupe de commandes tfx pipeline .

créer

Crée un nouveau pipeline dans l'orchestrateur donné.

Usage:

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
Le chemin d'accès au fichier de configuration du pipeline.
--endpoint= endpoint

(Facultatif.) Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow
  • local : définit le moteur sur l'orchestrateur local
  • vertex : définit le moteur sur Vertex Pipelines
  • airflow : (expérimental) définit le moteur sur Apache Airflow
  • Beam : (expérimental) définit le moteur sur Apache Beam

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--iap_client_id = iap-client-id
(Facultatif.) ID client pour le point de terminaison protégé par IAP lors de l'utilisation de Kubeflow Pipelines.
--namespace= namespace
(Facultatif.) Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .
--build_image

(Facultatif.) Lorsque le engine est kubeflow ou vertex , TFX crée une image de conteneur pour votre pipeline si spécifié. `Dockerfile` dans le répertoire actuel sera utilisé et TFX en générera automatiquement un s'il n'existe pas.

L'image construite sera poussée vers le registre distant spécifié dans `KubeflowDagRunnerConfig` ou `KubeflowV2DagRunnerConfig`.

--build_base_image= build-base-image

(Facultatif.) Lorsque le engine est kubeflow , TFX crée une image de conteneur pour votre pipeline. L'image de base de construction spécifie l'image du conteneur de base à utiliser lors de la création de l'image du conteneur de pipeline.

Exemples:

Flux Kube :

tfx pipeline create --engine=kubeflow --pipeline_path=pipeline-path \
--iap_client_id=iap-client-id --namespace=namespace --endpoint=endpoint \
--build_image

Locale:

tfx pipeline create --engine=local --pipeline_path=pipeline-path

Sommet:

tfx pipeline create --engine=vertex --pipeline_path=pipeline-path \
--build_image

Pour détecter automatiquement le moteur de l'environnement utilisateur, évitez simplement d'utiliser l'indicateur de moteur comme dans l'exemple ci-dessous. Pour plus de détails, consultez la section drapeaux.

tfx pipeline create --pipeline_path=pipeline-path

mise à jour

Met à jour un pipeline existant dans l'orchestrateur donné.

Usage:

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
Le chemin d'accès au fichier de configuration du pipeline.
--endpoint= endpoint

(Facultatif.) Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow
  • local : définit le moteur sur l'orchestrateur local
  • vertex : définit le moteur sur Vertex Pipelines
  • airflow : (expérimental) définit le moteur sur Apache Airflow
  • Beam : (expérimental) définit le moteur sur Apache Beam

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--iap_client_id = iap-client-id
(Facultatif.) ID client pour le point de terminaison protégé par IAP.
--namespace= namespace
(Facultatif.) Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .
--build_image

(Facultatif.) Lorsque le engine est kubeflow ou vertex , TFX crée une image de conteneur pour votre pipeline si spécifié. `Dockerfile` dans le répertoire courant sera utilisé.

L'image construite sera poussée vers le registre distant spécifié dans `KubeflowDagRunnerConfig` ou `KubeflowV2DagRunnerConfig`.

Exemples:

Flux Kube :

tfx pipeline update --engine=kubeflow --pipeline_path=pipeline-path \
--iap_client_id=iap-client-id --namespace=namespace --endpoint=endpoint \
--build_image

Locale:

tfx pipeline update --engine=local --pipeline_path=pipeline-path

Sommet:

tfx pipeline update --engine=vertex --pipeline_path=pipeline-path \
--build_image

compiler

Compile le fichier de configuration du pipeline pour créer un fichier de workflow dans Kubeflow et effectue les vérifications suivantes lors de la compilation :

  1. Vérifie si le chemin du pipeline est valide.
  2. Vérifie si les détails du pipeline sont extraits avec succès du fichier de configuration du pipeline.
  3. Vérifie si le DagRunner dans la configuration du pipeline correspond au moteur.
  4. Vérifie si le fichier de workflow est créé avec succès dans le chemin du package fourni (uniquement pour Kubeflow).

Utilisation recommandée avant de créer ou de mettre à jour un pipeline.

Usage:

tfx pipeline compile --pipeline_path=pipeline-path [--engine=engine]
--pipeline_path= pipeline-path
Le chemin d'accès au fichier de configuration du pipeline.
--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow
  • local : définit le moteur sur l'orchestrateur local
  • vertex : définit le moteur sur Vertex Pipelines
  • airflow : (expérimental) définit le moteur sur Apache Airflow
  • Beam : (expérimental) définit le moteur sur Apache Beam

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

Exemples:

Flux Kube :

tfx pipeline compile --engine=kubeflow --pipeline_path=pipeline-path

Locale:

tfx pipeline compile --engine=local --pipeline_path=pipeline-path

Sommet:

tfx pipeline compile --engine=vertex --pipeline_path=pipeline-path

supprimer

Supprime un pipeline de l'orchestrateur donné.

Usage:

tfx pipeline delete --pipeline_path=pipeline-path [--endpoint=endpoint --engine=engine \
--iap_client_id=iap-client-id --namespace=namespace]
--pipeline_path= pipeline-path
Le chemin d'accès au fichier de configuration du pipeline.
--endpoint= endpoint

(Facultatif.) Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow
  • local : définit le moteur sur l'orchestrateur local
  • vertex : définit le moteur sur Vertex Pipelines
  • airflow : (expérimental) définit le moteur sur Apache Airflow
  • Beam : (expérimental) définit le moteur sur Apache Beam

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--iap_client_id = iap-client-id
(Facultatif.) ID client pour le point de terminaison protégé par IAP.
--namespace= namespace
(Facultatif.) Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .

Exemples:

Flux Kube :

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

Locale:

tfx pipeline delete --engine=local --pipeline_name=pipeline-name

Sommet:

tfx pipeline delete --engine=vertex --pipeline_name=pipeline-name

liste

Répertorie tous les pipelines de l'orchestrateur donné.

Usage:

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

(Facultatif.) Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow
  • local : définit le moteur sur l'orchestrateur local
  • vertex : définit le moteur sur Vertex Pipelines
  • airflow : (expérimental) définit le moteur sur Apache Airflow
  • Beam : (expérimental) définit le moteur sur Apache Beam

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--iap_client_id = iap-client-id
(Facultatif.) ID client pour le point de terminaison protégé par IAP.
--namespace= namespace
(Facultatif.) Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .

Exemples:

Flux Kube :

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

Locale:

tfx pipeline list --engine=local

Sommet:

tfx pipeline list --engine=vertex

exécution de tfx

La structure des commandes du groupe de commandes tfx run est la suivante :

tfx run command required-flags [optional-flags]

Utilisez les sections suivantes pour en savoir plus sur les commandes du groupe de commandes tfx run .

créer

Crée une nouvelle instance d'exécution pour un pipeline dans l'orchestrateur. Pour Kubeflow, la version de pipeline la plus récente du cluster est utilisée.

Usage:

tfx run create --pipeline_name=pipeline-name [--endpoint=endpoint \
--engine=engine --iap_client_id=iap-client-id --namespace=namespace]
--pipeline_name= pipeline-name
Le nom du pipeline.
--endpoint= endpoint

(Facultatif.) Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow
  • local : définit le moteur sur l'orchestrateur local
  • vertex : définit le moteur sur Vertex Pipelines
  • airflow : (expérimental) définit le moteur sur Apache Airflow
  • Beam : (expérimental) définit le moteur sur Apache Beam

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--runtime_parameter= parameter-name = parameter-value
(Facultatif.) Définit une valeur de paramètre d'exécution. Peut être défini plusieurs fois pour définir les valeurs de plusieurs variables. Applicable uniquement aux moteurs `airflow`, `kubeflow` et `vertex`.
--iap_client_id = iap-client-id
(Facultatif.) ID client pour le point de terminaison protégé par IAP.
--namespace= namespace
(Facultatif.) Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .
--project= GCP-project-id
(Obligatoire pour Vertex.) ID de projet GCP pour le pipeline de sommets.
--region= GCP-region
(Obligatoire pour Vertex.) Nom de la région GCP tel que us-central1. Consultez la [documentation Vertex](https://cloud.google.com/vertex-ai/docs/general/locations) pour connaître les régions disponibles.

Exemples:

Flux Kube :

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

Locale:

tfx run create --engine=local --pipeline_name=pipeline-name

Sommet:

tfx run create --engine=vertex --pipeline_name=pipeline-name \
  --runtime_parameter=var_name=var_value \
  --project=gcp-project-id --region=gcp-region

mettre fin

Arrête une exécution d'un pipeline donné.

** Remarque importante : actuellement pris en charge uniquement dans Kubeflow.

Usage:

tfx run terminate --run_id=run-id [--endpoint=endpoint --engine=engine \
--iap_client_id=iap-client-id --namespace=namespace]
--run_id= run-id
Identificateur unique pour une exécution de pipeline.
--endpoint= endpoint

(Facultatif.) Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--iap_client_id = iap-client-id
(Facultatif.) ID client pour le point de terminaison protégé par IAP.
--namespace= namespace
(Facultatif.) Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .

Exemples:

Flux Kube :

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

liste

Répertorie toutes les exécutions d'un pipeline.

** Remarque importante : actuellement non pris en charge dans Local et Apache Beam.

Usage:

tfx run list --pipeline_name=pipeline-name [--endpoint=endpoint \
--engine=engine --iap_client_id=iap-client-id --namespace=namespace]
--pipeline_name= pipeline-name
Le nom du pipeline.
--endpoint= endpoint

(Facultatif.) Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow
  • airflow : (expérimental) définit le moteur sur Apache Airflow

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--iap_client_id = iap-client-id
(Facultatif.) ID client pour le point de terminaison protégé par IAP.
--namespace= namespace
(Facultatif.) Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .

Exemples:

Flux Kube :

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

statut

Renvoie l'état actuel d'une exécution.

** Remarque importante : actuellement non pris en charge dans Local et Apache Beam.

Usage:

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
Le nom du pipeline.
--run_id= run-id
Identificateur unique pour une exécution de pipeline.
--endpoint= endpoint

(Facultatif.) Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow
  • airflow : (expérimental) définit le moteur sur Apache Airflow

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--iap_client_id = iap-client-id
(Facultatif.) ID client pour le point de terminaison protégé par IAP.
--namespace= namespace
(Facultatif.) Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .

Exemples:

Flux Kube :

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

supprimer

Supprime une exécution d'un pipeline donné.

** Remarque importante : actuellement pris en charge uniquement dans Kubeflow

Usage:

tfx run delete --run_id=run-id [--engine=engine --iap_client_id=iap-client-id \
--namespace=namespace --endpoint=endpoint]
--run_id= run-id
Identificateur unique pour une exécution de pipeline.
--endpoint= endpoint

(Facultatif.) Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--engine= engine

(Facultatif.) Orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--iap_client_id = iap-client-id
(Facultatif.) ID client pour le point de terminaison protégé par IAP.
--namespace= namespace
(Facultatif.) Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .

Exemples:

Flux Kube :

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

modèle tfx [expérimental]

La structure des commandes du groupe de commandes tfx template est la suivante :

tfx template command required-flags [optional-flags]

Utilisez les sections suivantes pour en savoir plus sur les commandes du groupe de commandes tfx template . Le modèle est une fonctionnalité expérimentale et peut être modifié à tout moment.

liste

Répertoriez les modèles de pipeline TFX disponibles.

Usage:

tfx template list

copie

Copiez un modèle dans le répertoire de destination.

Usage:

tfx template copy --model=model --pipeline_name=pipeline-name \
--destination_path=destination-path
--model= model
Le nom du modèle construit par le modèle de pipeline.
--pipeline_name= pipeline-name
Le nom du pipeline.
--destination_path= destination-path
Le chemin vers lequel copier le modèle.

Comprendre les indicateurs CLI TFX

Drapeaux communs

--engine= engine

L'orchestrateur à utiliser pour le pipeline. La valeur du moteur doit correspondre à l'une des valeurs suivantes :

  • kubeflow : définit le moteur sur Kubeflow
  • local : définit le moteur sur l'orchestrateur local
  • vertex : définit le moteur sur Vertex Pipelines
  • airflow : (expérimental) définit le moteur sur Apache Airflow
  • Beam : (expérimental) définit le moteur sur Apache Beam

Si le moteur n'est pas réglé, le moteur est automatiquement détecté en fonction de l'environnement.

** Remarque importante : l'orchestrateur requis par DagRunner dans le fichier de configuration du pipeline doit correspondre au moteur sélectionné ou détecté automatiquement. La détection automatique du moteur est basée sur l'environnement utilisateur. Si Apache Airflow et Kubeflow Pipelines ne sont pas installés, l'orchestrateur local est utilisé par défaut.

--pipeline_name= pipeline-name
Le nom du pipeline.
--pipeline_path= pipeline-path
Le chemin d'accès au fichier de configuration du pipeline.
--run_id= run-id
Identificateur unique pour une exécution de pipeline.

Indicateurs spécifiques à Kubeflow

--endpoint= endpoint

Point de terminaison du service API Kubeflow Pipelines. Le point de terminaison de votre service API Kubeflow Pipelines est le même que l'URL du tableau de bord Kubeflow Pipelines. La valeur de votre point de terminaison devrait ressembler à :

https://host-name/pipeline

Si vous ne connaissez pas le point de terminaison de votre cluster Kubeflow Pipelines, contactez l'administrateur de votre cluster.

Si le --endpoint n'est pas spécifié, le nom DNS du service du cluster est utilisé comme valeur par défaut. Ce nom ne fonctionne que si la commande CLI s'exécute dans un pod du cluster Kubeflow Pipelines, tel qu'une instance de notebooks Kubeflow Jupyter .

--iap_client_id = iap-client-id
ID client pour le point de terminaison protégé par IAP.
--namespace= namespace
Espace de noms Kubernetes pour se connecter à l'API Kubeflow Pipelines. Si l'espace de noms n'est pas spécifié, la valeur par défaut est kubeflow .

Fichiers générés par TFX CLI

Lorsque les pipelines sont créés et exécutés, plusieurs fichiers sont générés pour la gestion des pipelines.

  • ${HOME}/tfx/local, faisceau, flux d'air, sommet
    • Les métadonnées du pipeline lues à partir de la configuration sont stockées sous ${HOME}/tfx/${ORCHESTRATION_ENGINE}/${PIPELINE_NAME} . Cet emplacement peut être personnalisé en définissant une variable d'environnement comme AIRFLOW_HOME ou KUBEFLOW_HOME . Ce comportement pourrait être modifié dans les versions futures. Ce répertoire est utilisé pour stocker les informations sur le pipeline, y compris les identifiants de pipeline dans le cluster Kubeflow Pipelines, qui sont nécessaires pour créer des exécutions ou mettre à jour des pipelines.
    • Avant TFX 0.25, ces fichiers se trouvaient sous ${HOME}/${ORCHESTRATION_ENGINE} . Dans TFX 0.25, les fichiers de l'ancien emplacement seront automatiquement déplacés vers le nouvel emplacement pour une migration en douceur.
    • À partir de TFX 0.27, kubeflow ne crée pas ces fichiers de métadonnées dans le système de fichiers local. Cependant, voir ci-dessous pour les autres fichiers créés par kubeflow.
  • (Kubeflow uniquement) Dockerfile et une image de conteneur
    • Kubeflow Pipelines nécessite deux types d'entrées pour un pipeline. Ces fichiers sont générés par TFX dans le répertoire courant.
    • La première est une image de conteneur qui sera utilisée pour exécuter les composants dans le pipeline. Cette image de conteneur est créée lorsqu'un pipeline pour Kubeflow Pipelines est créé ou mis à jour avec l'indicateur --build-image . TFX CLI générera Dockerfile s'il n'existe pas, et créera et transmettra une image de conteneur vers le registre spécifié dans KubeflowDagRunnerConfig.