Ta strona została przetłumaczona przez Cloud Translation API.

Korzystanie z interfejsu wiersza poleceń TFX

Interfejs wiersza poleceń TFX (CLI) wykonuje pełen zakres działań potokowych przy użyciu koordynatorów potoków, takich jak Kubeflow Pipelines, Vertex Pipelines. Lokalnego koordynatora można również używać do szybszego programowania lub debugowania. Apache Beam i przepływ powietrza Apache są obsługiwane jako funkcje eksperymentalne. Za pomocą interfejsu CLI możesz na przykład:

Twórz, aktualizuj i usuwaj potoki.
Uruchom potok i monitoruj jego działanie w różnych koordynatorach.
Wymień rurociągi i przebiegi rurociągów.

Informacje o interfejsie wiersza polecenia TFX

Interfejs TFX CLI jest instalowany jako część pakietu TFX. Wszystkie polecenia CLI mają poniższą strukturę:

tfx command-group command flags

Obecnie obsługiwane są następujące opcje command-group :

Potok TFX - Twórz potoki TFX i zarządzaj nimi.
tfx run — Twórz i zarządzaj uruchomieniami potoków TFX na różnych platformach orkiestracyjnych.
tfx template — eksperymentalne polecenia służące do wyświetlania i kopiowania szablonów potoków TFX.

Każda grupa poleceń udostępnia zestaw commands . Postępuj zgodnie z instrukcjami zawartymi w sekcjach poleceń potoku , poleceń uruchamiania i poleceń szablonów , aby dowiedzieć się więcej na temat korzystania z tych poleceń.

Flagi umożliwiają przekazywanie argumentów do poleceń CLI. Słowa we flagach oddzielane są łącznikiem ( - ) lub podkreśleniem ( _ ). Na przykład flagę nazwy potoku można określić jako --pipeline-name lub --pipeline_name . W tym dokumencie określono flagi z podkreśleniami dla zwięzłości. Dowiedz się więcej o flags używanych w TFX CLI .

potok tfx

Struktura poleceń w grupie poleceń tfx pipeline jest następująca:

tfx pipeline command required-flags [optional-flags]

Skorzystaj z poniższych sekcji, aby dowiedzieć się więcej o poleceniach w grupie poleceń tfx pipeline .

tworzyć

Tworzy nowy potok w danym orkiestratorze.

Stosowanie:

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

Ścieżka do pliku konfiguracyjnego potoku.

--punkt końcowy= endpoint

(Opcjonalnie.) Punkt końcowy usługi Kubeflow Pipelines API. Punkt końcowy usługi API Kubeflow Pipelines jest taki sam, jak adres URL pulpitu nawigacyjnego Kubeflow Pipelines. Wartość punktu końcowego powinna wyglądać mniej więcej tak:

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

Jeśli opcja --endpoint nie zostanie określona, jako wartość domyślna zostanie użyta nazwa DNS usługi klastrowej. Ta nazwa działa tylko wtedy, gdy polecenie CLI jest wykonywane w zasobniku w klastrze Kubeflow Pipelines, takim jak instancja notatników Kubeflow Jupyter .

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow
local : ustawia silnik na lokalnego orkiestratora
vertex : ustawia silnik na Vertex Pipelines
airflow : (eksperymentalnie) ustawia silnik na Apache Airflow
belka : (eksperymentalnie) ustawia silnik na Apache Beam

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

** Ważna uwaga: Orchestrator wymagany przez DagRunner w pliku konfiguracyjnym potoku musi odpowiadać wybranemu lub automatycznie wykrytemu silnikowi. Automatyczne wykrywanie silnika opiera się na środowisku użytkownika. Jeśli Apache Airflow i Kubeflow Pipelines nie są zainstalowane, domyślnie używany jest lokalny koordynator.

--iap_client_id= iap-client-id

(Opcjonalnie.) Identyfikator klienta dla punktu końcowego chronionego przez IAP podczas korzystania z Kubeflow Pipelines.

--namespace= namespace

(Opcjonalnie.) Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

--obraz_kompilacji

(Opcjonalnie). Jeśli engine jest kubeflow lub vertex , TFX tworzy obraz kontenera dla Twojego potoku, jeśli został określony. Zostanie użyty plik „Dockerfile” w bieżącym katalogu, a TFX automatycznie go wygeneruje, jeśli nie istnieje.

Zbudowany obraz zostanie przesłany do zdalnego rejestru określonego w `KubeflowDagRunnerConfig` lub `KubeflowV2DagRunnerConfig`.

--build_base_image= build-base-image

(Opcjonalnie). Gdy engine jest kubeflow , TFX tworzy obraz kontenera dla Twojego potoku. Podstawowy obraz kompilacji określa podstawowy obraz kontenera, który ma być używany podczas kompilowania obrazu kontenera potoku.

Przykłady:

Kubeflow:

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

Lokalny:

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

Wierzchołek:

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

Aby automatycznie wykryć silnik ze środowiska użytkownika, po prostu unikaj używania flagi silnika, jak w przykładzie poniżej. Więcej szczegółów znajdziesz w sekcji flagi.

tfx pipeline create --pipeline_path=pipeline-path

aktualizacja

Aktualizuje istniejący potok w danym koordynatorze.

Stosowanie:

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

Ścieżka do pliku konfiguracyjnego potoku.

--punkt końcowy= endpoint

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow
local : ustawia silnik na lokalnego orkiestratora
vertex : ustawia silnik na Vertex Pipelines
airflow : (eksperymentalnie) ustawia silnik na Apache Airflow
belka : (eksperymentalnie) ustawia silnik na Apache Beam

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

--iap_client_id= iap-client-id

(Opcjonalnie). Identyfikator klienta punktu końcowego chronionego przez IAP.

--namespace= namespace

(Opcjonalnie.) Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

--obraz_kompilacji

(Opcjonalnie). Jeśli engine jest kubeflow lub vertex , TFX tworzy obraz kontenera dla Twojego potoku, jeśli został określony. Zostanie użyty `Dockerfile` w bieżącym katalogu.

Zbudowany obraz zostanie przesłany do zdalnego rejestru określonego w `KubeflowDagRunnerConfig` lub `KubeflowV2DagRunnerConfig`.

Przykłady:

Kubeflow:

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

Lokalny:

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

Wierzchołek:

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

skompilować

Kompiluje plik konfiguracyjny potoku, aby utworzyć plik przepływu pracy w Kubeflow i podczas kompilacji wykonuje następujące kontrole:

Sprawdza, czy ścieżka potoku jest prawidłowa.
Sprawdza, czy szczegóły potoku zostały pomyślnie wyodrębnione z pliku konfiguracyjnego potoku.
Sprawdza, czy DagRunner w konfiguracji potoku pasuje do silnika.
Sprawdza, czy plik przepływu pracy został pomyślnie utworzony w podanej ścieżce pakietu (tylko dla Kubeflow).

Zalecane do użycia przed utworzeniem lub aktualizacją potoku.

Stosowanie:

tfx pipeline compile --pipeline_path=pipeline-path [--engine=engine]

--pipeline_path= pipeline-path

Ścieżka do pliku konfiguracyjnego potoku.

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow
local : ustawia silnik na lokalnego orkiestratora
vertex : ustawia silnik na Vertex Pipelines
airflow : (eksperymentalnie) ustawia silnik na Apache Airflow
belka : (eksperymentalnie) ustawia silnik na Apache Beam

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

Przykłady:

Kubeflow:

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

Lokalny:

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

Wierzchołek:

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

usuwać

Usuwa potok z danego koordynatora.

Stosowanie:

tfx pipeline delete --pipeline_path=pipeline-path [--endpoint=endpoint --engine=engine \
--iap_client_id=iap-client-id --namespace=namespace]

--pipeline_path= pipeline-path

Ścieżka do pliku konfiguracyjnego potoku.

--punkt końcowy= endpoint

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow
local : ustawia silnik na lokalnego orkiestratora
vertex : ustawia silnik na Vertex Pipelines
airflow : (eksperymentalnie) ustawia silnik na Apache Airflow
belka : (eksperymentalnie) ustawia silnik na Apache Beam

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

--iap_client_id= iap-client-id

(Opcjonalnie). Identyfikator klienta punktu końcowego chronionego przez IAP.

--namespace= namespace

(Opcjonalnie.) Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

Przykłady:

Kubeflow:

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

Lokalny:

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

Wierzchołek:

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

lista

Wyświetla listę wszystkich potoków w danym orkiestratorze.

Stosowanie:

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

--punkt końcowy= endpoint

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow
local : ustawia silnik na lokalnego orkiestratora
vertex : ustawia silnik na Vertex Pipelines
airflow : (eksperymentalnie) ustawia silnik na Apache Airflow
belka : (eksperymentalnie) ustawia silnik na Apache Beam

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

--iap_client_id= iap-client-id

(Opcjonalnie). Identyfikator klienta punktu końcowego chronionego przez IAP.

--namespace= namespace

(Opcjonalnie.) Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

Przykłady:

Kubeflow:

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

Lokalny:

tfx pipeline list --engine=local

Wierzchołek:

tfx pipeline list --engine=vertex

bieg tfx

Struktura poleceń w grupie poleceń tfx run jest następująca:

tfx run command required-flags [optional-flags]

Skorzystaj z poniższych sekcji, aby dowiedzieć się więcej o poleceniach w grupie poleceń tfx run .

tworzyć

Tworzy nowe wystąpienie uruchomieniowe dla potoku w programie Orchestrator. W przypadku Kubeflow używana jest najnowsza wersja potoku w klastrze.

Stosowanie:

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

--nazwa_potoku= pipeline-name

Nazwa rurociągu.

--punkt końcowy= endpoint

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow
local : ustawia silnik na lokalnego orkiestratora
vertex : ustawia silnik na Vertex Pipelines
airflow : (eksperymentalnie) ustawia silnik na Apache Airflow
belka : (eksperymentalnie) ustawia silnik na Apache Beam

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

--runtime_parameter= parameter-name = parameter-value

(Opcjonalnie). Ustawia wartość parametru środowiska wykonawczego. Można ustawić wiele razy, aby ustawić wartości wielu zmiennych. Dotyczy tylko silników „airflow”, „kubeflow” i „vertex”.

--iap_client_id= iap-client-id

(Opcjonalnie). Identyfikator klienta punktu końcowego chronionego przez IAP.

--namespace= namespace

(Opcjonalnie.) Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

--project= GCP-project-id

(Wymagany w przypadku wierzchołka). Identyfikator projektu GCP dla potoku wierzchołkowego.

--region= GCP-region

(Wymagane dla Vertex.) Nazwa regionu GCP, np. us-central1. Zobacz [dokumentację Vertex](https://cloud.google.com/vertex-ai/docs/general/locations), aby poznać dostępne regiony.

Przykłady:

Kubeflow:

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

Lokalny:

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

Wierzchołek:

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

zakończyć

Zatrzymuje działanie danego potoku.

** Ważna uwaga: obecnie obsługiwane tylko w Kubeflow.

Stosowanie:

tfx run terminate --run_id=run-id [--endpoint=endpoint --engine=engine \
--iap_client_id=iap-client-id --namespace=namespace]

--run_id= run-id

Unikalny identyfikator uruchomienia potoku.

--punkt końcowy= endpoint

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

--iap_client_id= iap-client-id

(Opcjonalnie). Identyfikator klienta punktu końcowego chronionego przez IAP.

--namespace= namespace

(Opcjonalnie.) Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

Przykłady:

Kubeflow:

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

lista

Wyświetla listę wszystkich przebiegów potoku.

** Ważna uwaga: obecnie nie jest obsługiwana w trybie lokalnym i Apache Beam.

Stosowanie:

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

--nazwa_potoku= pipeline-name

Nazwa rurociągu.

--punkt końcowy= endpoint

(Opcjonalnie.) Punkt końcowy usługi API Kubeflow Pipelines. Punkt końcowy usługi API Kubeflow Pipelines jest taki sam, jak adres URL pulpitu nawigacyjnego Kubeflow Pipelines. Wartość punktu końcowego powinna wyglądać mniej więcej tak:

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow
airflow : (eksperymentalnie) ustawia silnik na Apache Airflow

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

--iap_client_id= iap-client-id

(Opcjonalnie). Identyfikator klienta punktu końcowego chronionego przez IAP.

--namespace= namespace

(Opcjonalnie.) Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

Przykłady:

Kubeflow:

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

status

Zwraca bieżący stan przebiegu.

** Ważna uwaga: obecnie nie jest obsługiwana w trybie lokalnym i Apache Beam.

Stosowanie:

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

--nazwa_potoku= pipeline-name

Nazwa rurociągu.

--run_id= run-id

Unikalny identyfikator uruchomienia potoku.

--punkt końcowy= endpoint

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow
airflow : (eksperymentalnie) ustawia silnik na Apache Airflow

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

--iap_client_id= iap-client-id

(Opcjonalnie). Identyfikator klienta punktu końcowego chronionego przez IAP.

--namespace= namespace

(Opcjonalnie.) Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

Przykłady:

Kubeflow:

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

usuwać

Usuwa przebieg danego potoku.

** Ważna uwaga: obecnie obsługiwane tylko w Kubeflow

Stosowanie:

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

--run_id= run-id

Unikalny identyfikator uruchomienia potoku.

--punkt końcowy= endpoint

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

--silnik= engine

(Opcjonalnie). Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

--iap_client_id= iap-client-id

(Opcjonalnie). Identyfikator klienta punktu końcowego chronionego przez IAP.

--namespace= namespace

(Opcjonalnie.) Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

Przykłady:

Kubeflow:

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

szablon tfx [eksperymentalny]

Struktura poleceń w grupie poleceń tfx template jest następująca:

tfx template command required-flags [optional-flags]

Skorzystaj z poniższych sekcji, aby dowiedzieć się więcej o poleceniach w grupie poleceń tfx template . Szablon jest funkcją eksperymentalną i może ulec zmianie w dowolnym momencie.

lista

Lista dostępnych szablonów potoków TFX.

Stosowanie:

tfx template list

kopia

Skopiuj szablon do katalogu docelowego.

Stosowanie:

tfx template copy --model=model --pipeline_name=pipeline-name \
--destination_path=destination-path

--model= model: Nazwa modelu zbudowanego przez szablon potoku.
--nazwa_potoku= pipeline-name: Nazwa rurociągu.
--destination_path= destination-path: Ścieżka, do której ma zostać skopiowany szablon.

Zrozumienie flag TFX CLI

Wspólne flagi

--silnik= engine

Koordynator, który ma być używany dla potoku. Wartość silnika musi odpowiadać jednej z następujących wartości:

kubeflow : ustawia silnik na Kubeflow
local : ustawia silnik na lokalnego orkiestratora
vertex : ustawia silnik na Vertex Pipelines
airflow : (eksperymentalnie) ustawia silnik na Apache Airflow
belka : (eksperymentalnie) ustawia silnik na Apache Beam

Jeżeli silnik nie jest ustawiony, zostanie on automatycznie wykryty na podstawie środowiska.

--nazwa_potoku= pipeline-name

Nazwa rurociągu.

--pipeline_path= pipeline-path

Ścieżka do pliku konfiguracyjnego potoku.

--run_id= run-id

Unikalny identyfikator uruchomienia potoku.

Flagi specyficzne dla Kubeflow

--punkt końcowy= endpoint

Punkt końcowy usługi API Kubeflow Pipelines. Punkt końcowy usługi API Kubeflow Pipelines jest taki sam, jak adres URL pulpitu nawigacyjnego Kubeflow Pipelines. Wartość punktu końcowego powinna wyglądać mniej więcej tak:

https://host-name/pipeline

Jeśli nie znasz punktu końcowego klastra Kubeflow Pipelines, skontaktuj się z administratorem klastra.

--iap_client_id= iap-client-id

Identyfikator klienta punktu końcowego chronionego przez IAP.

--namespace= namespace

Przestrzeń nazw Kubernetes do połączenia z interfejsem API Kubeflow Pipelines. Jeśli przestrzeń nazw nie zostanie określona, wartość domyślna to kubeflow .

Pliki wygenerowane przez TFX CLI

Podczas tworzenia i uruchamiania potoków generowanych jest kilka plików do zarządzania potokami.

${HOME}/tfx/local, wiązka, przepływ powietrza, wierzchołek
- Metadane potoku odczytane z konfiguracji są przechowywane w ${HOME}/tfx/${ORCHESTRATION_ENGINE}/${PIPELINE_NAME} . Tę lokalizację można dostosować, ustawiając zmienną środowiskową, taką jak AIRFLOW_HOME lub KUBEFLOW_HOME . To zachowanie może zostać zmienione w przyszłych wersjach. Ten katalog służy do przechowywania informacji o potokach, w tym identyfikatorów potoków, w klastrze Kubeflow Pipelines, które są potrzebne do tworzenia uruchomień lub aktualizacji potoków.
- Przed TFX 0.25 pliki te znajdowały się w ${HOME}/${ORCHESTRATION_ENGINE} . W TFX 0.25 pliki ze starej lokalizacji zostaną automatycznie przeniesione do nowej lokalizacji, aby migracja przebiegała sprawnie.
- Od wersji TFX 0.27 kubeflow nie tworzy tych plików metadanych w lokalnym systemie plików. Jednak poniżej znajdziesz inne pliki tworzone przez kubeflow.
(Tylko Kubeflow) Plik Docker i obraz kontenera
- Kubeflow Pipelines wymaga dwóch rodzajów danych wejściowych dla potoku. Pliki te są generowane przez TFX w bieżącym katalogu.
- Jednym z nich jest obraz kontenera, który będzie używany do uruchamiania komponentów w potoku. Ten obraz kontenera jest tworzony podczas tworzenia lub aktualizowania potoku dla Kubeflow Pipelines za pomocą flagi --build-image . TFX CLI wygeneruje Dockerfile jeśli nie istnieje, oraz zbuduje i wypchnie obraz kontenera do rejestru określonego w KubeflowDagRunnerConfig.