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 :
Kubeflow :
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 :
- Vérifie si le chemin du pipeline est valide.
- Vérifie si les détails du pipeline sont extraits avec succès du fichier de configuration du pipeline.
- Vérifie si le DagRunner dans la configuration du pipeline correspond au moteur.
- 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 :
Kubeflow :
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 :
Kubeflow :
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 :
Kubeflow :
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 pipeline dans le 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 :
Kubeflow :
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 :
Kubeflow :
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 :
Kubeflow :
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 :
Kubeflow :
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 commeAIRFLOW_HOME
ouKUBEFLOW_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.
- Les métadonnées du pipeline lues à partir de la configuration sont stockées sous
- (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éreraDockerfile
s'il n'existe pas, et créera et transmettra une image de conteneur vers le registre spécifié dans KubeflowDagRunnerConfig.