Red Hat Developer Hub の Orchestrator
Orchestrator を使用すると、Red Hat Developer Hub でのクラウド移行、オンボーディング、およびカスタマイズのサーバーレスワークフローが可能になります。
概要
第1章 Red Hat Developer Hub の Orchestrator について リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Developer Hub で Orchestrator を使用すると、作業の効率化および自動化を実現できます。これにより、次のことが可能になります。
- ワークフローを設計、実行、監視して、アプリケーションとサービスにわたる複数ステップのプロセスを簡素化します。
- オンボーディング、移行、および統合ワークフローを標準化して、手動作業を削減し、一貫性を向上させます。
- エンタープライズグレードのオーケストレーション機能を使用して RHDH を拡張して、コラボレーションとスケーラビリティーをサポートします。
Orchestrator は現在、Red Hat OpenShift Container Platform (OpenShift Container Platform) のみをサポートしており、Microsoft Azure Kubernetes Service (AKS)、Amazon Elastic Kubernetes Service (EKS)、Google Kubernetes Engine (GKE) では利用できません。
1.1. Orchestrator の互換性ガイド リンクのコピーリンクがクリップボードにコピーされました!
次の表は、RHDH Orchestrator プラグインのバージョンと、それに対応する互換性のあるインフラストラクチャーのバージョンを示しています。
| Orchestrator プラグインのバージョン | Red Hat Developer Hub (RHDH) のバージョン | OpenShift のバージョン | OpenShift Serverless Logic (OSL) のバージョン | OpenShift Serverless のバージョン |
|
Orchestrator |
|
|
OSL |
|
|
Orchestrator |
|
|
OSL |
|
| Orchestrator 1.7.1 | 1.7 |
|
OSL |
|
Orchestrator プラグインは、RHDH と同じ OpenShift Container Platform バージョンをサポートします。ライフサイクル ページを参照してください。
1.2. Orchestrator アーキテクチャーとは リンクのコピーリンクがクリップボードにコピーされました!
Orchestrator アーキテクチャーは複数のコンポーネントで構成されており、各コンポーネントはワークフローの実行と管理に使用できます。
- Red Hat Developer Hub (RHDH)
プライマリーインターフェイスとして機能します。次のサブコンポーネントが含まれています。
- Orchestrator フロントエンドプラグイン
- RHDH 内でワークフローを実行および監視するためのインターフェイスをユーザーに提供します。
- Orchestrator バックエンドプラグイン
- ワークフローデータを Developer Hub に取り込みます。
- Notifications プラグイン
- ワークフローイベントについてユーザーに通知します。
- OpenShift Serverless Logic Operator
ワークフローエンジンとして機能し、そのサブコンポーネントはワークフローの実行、実行、および永続性の提供を処理します。Red Hat Developer Hub Operator および Red Hat Developer Hub Helm チャートは、これらのサブコンポーネントの以下のライフサイクルを管理します。
- Sonataflow ランタイム/ワークフローアプリケーション
- デプロイされたワークフローとして機能します。HTTP サーバーとして動作し、実行中のワークフローインスタンスの要求を処理します。これは、Openshift Serverless Logic Operator によって Kubernetes (K8s) デプロイメントとして管理されます。
- Data Index Service
- ワークフロー定義、インスタンス、および関連ジョブのリポジトリーとして機能します。Orchestrator バックエンドプラグインがワークフロー定義とインスタンスを取得するために使用する GraphQL API を公開します。
- Job Service
- ワークフローのスケジュールされたタスクを調整します。
- OpenShift Serverless
- ワークフロー通信に不可欠なサーバーレス機能を提供します。Knative イベント機能を使用して Data Index サービスと連携し、Knative 関数を使用してワークフローにさらに複雑なロジックを導入します。
- PostgreSQL Server
- Orchestrator エコシステム内でのデータの永続性に不可欠なデータベースソリューションを提供します。システムは、Sonataflow 情報と Developer Hub データの両方を保存するために PostgreSQL サーバーを使用します。
- OpenShift AMQ Streams (Strimzi/Kafka)
イベントシステムの信頼性が向上します。HTTP の直接呼び出しを使用することで、Kafka を使用せずにイベントを動作させることができますが、この方法は信頼できません。
オプション: 現在のデプロイメントイテレーションでは、AMQ Streams Operator がネイティブに統合されていないか、含まれていません。しかし、インストール後に、信頼性を高めるために必要に応じて Operator を追加できます。
1.3. Orchestrator の使用 リンクのコピーリンクがクリップボードにコピーされました!
RHDH で Orchestrator の使用を開始するには、次の手順を実行する必要があります。
- OpenShift Serverless Operator および OpenShift Serverless Logic Operator などの必要なインフラストラクチャーコンポーネントのインストール
- Orchestrator の Backstage カスタムリソース (CR) または Helm 値ファイルを設定する
RHDH Operator を使用する場合は、最初に必要なインフラストラクチャーコンポーネントをインストールする必要があります。その後、Operator は Backstage CR で Orchestrator プラグインが有効になると、依存する SonataFlow リソースをプロビジョニングします。
RHDH Helm チャートを使用する場合、メインの RHDH チャートでオーケストレータープラグインを有効にする前に、専用の redhat-developer-hub-orchestrator-infra Helm チャートを使用して必要なインフラストラクチャーコンポーネントが自動的にインストールされます。
1.4. Operator インストールの Orchestrator プラグインの依存関係 リンクのコピーリンクがクリップボードにコピーされました!
Backstage カスタムリソース (CR) で Orchestrator プラグインを有効にすると、Operator によって次の必要な依存関係が自動的にプロビジョニングされます。
-
SonataflowPlatformCR -
インフラストラクチャーリソース (Knative、Serverless Logic Operator) 間のトラフィック、監視トラフィック、および namespace 内トラフィックを許可する
NetworkPolicies
Orchestrator プラグインを実行するにはこれらのコンポーネントが必要です。たとえば、Orchestrator プラグインは、SonataFlow プラットフォームと通信するために、SonataFlowPlatform CR によって作成される sonataflow-platform-data-index-service を使用します。
SonataFlowPlatform CR には、次の例に示すように、PostgreSQL データベースを必要とするデータインデックスサービスが含まれています。
persistence:
postgresql:
secretRef:
name: backstage-psql-secret-{{backstage-name}}
userKey: POSTGRES_USER
passwordKey: POSTGRES_PASSWORD
serviceRef:
name: backstage-psql-{{backstage-name}} # # Namespace where the Backstage CR is created
namespace: {{backstage-ns}} # Namespace where the Backstage (CR) is created
databaseName: backstage_plugin_orchestrator
デフォルトでは、Orchestrator プラグインの依存関係は以下を使用します。
-
Backstage によって作成された
backstage_plugin_orchestratorという名前の PostgreSQL データベース -
Backstage CR namespace のデータベースクレデンシャルとして
POSTGRES_USERおよびPOSTGRES_PASSWORDキーを使用して PostgreSQL の Backstage Operator によって作成されたシークレット。 -
Backstage Operator によって、Backstage CR namespace の
backstage-psql-{{backstage-name}}という名前の PostgreSQL データベース用に作成されたサービス。
Backstage CR がクラスターに適用されたときにプラグイン依存関係が自動的に作成される方法の詳細は、Dynamic plugins dependency management を参照してください。
Backstage Operator が SonataFlow プラットフォームで動作できるようにするには、ServiceAccount に適切な権限が必要です。
Operator は profile/rhdh/plugin-rbac ディレクトリーに必要な Role および RoleBinding リソースを自動的に作成します。
第2章 Orchestrator プラグインコンポーネントの有効化 リンクのコピーリンクがクリップボードにコピーされました!
2.1. Orchestrator プラグインコンポーネントの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Orchestrator を使用するには、デフォルトで無効になっている Red Hat Developer Hub の以下の Orchestrator プラグインを有効にします。
- strator-frontend プラグイン
backstage-plugin-orchestrator- RHDH 内でワークフローを実行および監視するためのインターフェイスをユーザーに提供します。プロセスを実行し、その実行ステータスを追跡できます。
- strator-backend プラグイン
backstage-plugin-orchestrator-backend- ワークフローデータを Developer Hub に取得して、RHDH が重要なワークフローメタデータとランタイムステータスを処理し、可視性の必要性に対応するようにします。
- strator-form-widget
backstage-plugin-orchestrator-form-widgets- ワークフロー実行フォーム用のカスタムウィジェットを提供し、入力フィールドをカスタマイズしてワークフローの起動プロセスを合理化できます。
- strator-scaffolder-backend-module
scaffolder-backend-module-orchestrator-
Orchestrator:workflow:
run または Orchestrator:workflow:。get_params などの Scaffolder テンプレートから呼び出し可能なアクションを提供します
前提条件
Red Hat Developer Hub Helm チャートを使用している場合: 必要な OpenShift Serverless Operator がインストール済みである。
注記Red Hat Developer Hub Operator を使用する場合: Operator が必要な OpenShift Serverless Operator を自動的にインストールします。特定のユースケースでは、依存関係を手動でインストールするか、ヘルパーユーティリティーを使用します。
- (オプション) Orchestrator プロジェクトを管理する場合: クラスター内に Argo CD または Red Hat OpenShift GitOps のインスタンスがある。これはデフォルトでは無効になっています。
- (オプション) Tekton タスクとビルドパイプラインを使用する場合: クラスター内に Tekton または Red Hat OpenShift Pipeline のインスタンスがある。これらの機能は、デフォルトで無効になっています。
手順
Developer Hub 設定を見つけて、Orchestrator プラグインと、それをサポートする通知プラグインを有効にします。
plugins: - package: "@redhat/backstage-plugin-orchestrator@1.7.1" disabled: false - package: "@redhat/backstage-plugin-orchestrator-backend-dynamic@1.7.1" disabled: false - package: "@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic@1.7.1" disabled: false - package: "@redhat/backstage-plugin-orchestrator-form-widgets@1.7.1" disabled: false - package: "./dynamic-plugins/dist/backstage-plugin-notifications" disabled: false - package: "./dynamic-plugins/dist/backstage-plugin-signals" disabled: false - package: "./dynamic-plugins/dist/backstage-plugin-notifications-backend-dynamic" disabled: false - package: "./dynamic-plugins/dist/backstage-plugin-signals-backend-dynamic" disabled: false
第3章 Red Hat Developer Hub Operator を使用した Orchestrator を使用した Red Hat Developer Hub のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Developer Hub Operator を使用して、Orchestrator で Red Hat Developer Hub をインストールできます。
3.1. Operator を使用した Orchestrator プラグインの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Backstage カスタムリソース (CR) で動的プラグインを設定することにより、RHDH で Orchestrator プラグインを有効にできます。
前提条件
- OpenShift Container Platform に RHDH がインストールされている。
- Backstage CR がデプロイされている namespace で ConfigMap を編集または作成できる。
手順
デフォルト設定で Orchestrator プラグインを有効にするには、パッケージに
disabled: falseを設定します。たとえば、package: "@redhat/backstage-plugin-orchestrator@<plugin_version>がdisabled: falseに設定されている場合:- package: "@redhat/backstage-plugin-orchestrator@<plugin_version>" disabled: false注記プラグインを有効にすると、事前に読み込まれたプラグイン設定が使用されます。さらに、
ref: sonataflowフィールドは Openshift Serverless および Openshift Serverless Logic リソースをインストールします。これは、Operator の使用時に自動的に実行されます。例: Orchestrator プラグインの完全な設定
apiVersion: v1 kind: ConfigMap metadata: name: orchestrator-plugin data: dynamic-plugins.yaml: | includes: - dynamic-plugins.default.yaml plugins: - package: "@redhat/backstage-plugin-orchestrator@1.7.1" disabled: false pluginConfig: dynamicPlugins: frontend: red-hat-developer-hub.backstage-plugin-orchestrator: appIcons: - importName: OrchestratorIcon name: orchestratorIcon dynamicRoutes: - importName: OrchestratorPage menuItem: icon: orchestratorIcon text: Orchestrator path: /orchestrator entityTabs: - path: /workflows title: Workflows mountPoint: entity.page.workflows mountPoints: - mountPoint: entity.page.workflows/cards importName: OrchestratorCatalogTab config: layout: gridColumn: '1 / -1' if: anyOf: - IsOrchestratorCatalogTabAvailable - package: "@redhat/backstage-plugin-orchestrator-backend-dynamic@1.7.1" disabled: false pluginConfig: orchestrator: dataIndexService: url: http://sonataflow-platform-data-index-service dependencies: - ref: sonataflow - package: "@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic@1.7.1" disabled: false pluginConfig: orchestrator: dataIndexService: url: http://sonataflow-platform-data-index-service - package: "@redhat/backstage-plugin-orchestrator-form-widgets@1.7.1" disabled: false pluginConfig: dynamicPlugins: frontend: red-hat-developer-hub.backstage-plugin-orchestrator-form-widgets: { } --- apiVersion: rhdh.redhat.com/v1alpha3 kind: Backstage metadata: name: orchestrator spec: application: appConfig: configMaps: - name: app-config-rhdh dynamicPluginsConfigMapName: orchestrator-plugin次の例に示すように、
BACKEND_SECRET値を含むシークレットを作成します。apiVersion: v1 kind: ConfigMap metadata: name: app-config-rhdh data: app-config.yaml: |- auth: environment: development providers: guest: # using the guest user to query the '/api/dynamic-plugins-info/loaded-plugins' endpoint. dangerouslyAllowOutsideDevelopment: true backend: auth: externalAccess: - type: static options: token: ${BACKEND_SECRET} subject: orchestrator --- apiVersion: v1 kind: Secret metadata: name: backend-auth-secret stringData: # generated with the command below (from https://backstage.io/docs/auth/service-to-service-auth/#setup): # node -p 'require("crypto").randomBytes(24).toString("base64")' # notsecret BACKEND_SECRET: "R2FxRVNrcmwzYzhhN3l0V1VRcnQ3L1pLT09WaVhDNUEK"次の例のように、Backstage CR を設定して、
extraEnvsフィールドのシークレット名を更新します。apiVersion: rhdh.redhat.com/v1alpha4 kind: Backstage metadata: name: orchestrator spec: application: appConfig: configMaps: - name: app-config-rhdh dynamicPluginsConfigMapName: orchestrator-plugin extraEnvs: secrets: # secret that contains the BACKEND_SECRET key - name: backend-auth-secret
検証
- RHDH コンソールで、Orchestrator フロントエンドおよびバックエンド機能が利用可能であることを確認します。
第4章 Red Hat Developer Hub Helm チャートを使用した Orchestrator での Red Hat Developer Hub のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Developer Hub Helm チャートを使用して、Orchestrator で Red Hat Developer Hub をインストールできます。
4.1. Helm CLI を使用して Orchestrator で OpenShift Container Platform に Red Hat Developer Hub (RHDH) をインストールする リンクのコピーリンクがクリップボードにコピーされました!
Helm CLI を使用して、Orchestrator とともに OpenShift Container Platform に Red Hat Developer Hub (RHDH) をインストールできます。インストールにより、必要な動的プラグインが自動的に有効になり、ワークフローインフラストラクチャーが統合されます。
前提条件
- 管理者としてログインしており、Red Hat Developer Hub Helm チャートリポジトリーにアクセスできる。
他の Openshift Operator (OpenShift Serverless および OpenShift Serverless Logic)などの必要なインフラストラクチャーリソースを、同じ namespace の RHDH とともにインストールできます。
これは 1 回限りの要件であり、Orchestrator プラグインを有効にする前に完了する必要があります。
手順
-
Operator のインストール計画を手動で承認します。インストールを承認するには、出力に示された
oc patch installplanコマンドを実行する必要があります。
デフォルトでは、Red Hat Developer Hub Helm チャートの Orchestrator Infrastructure は、必要な Serverless Operator を自動的に 表示しません。インストール計画を手動で承認する必要があります。
管理者として、関連するクラスター全体のリソースをインストールします。
helm repo add openshift-helm-charts https://charts.openshift.io/ helm install <release_name> openshift-helm-charts/redhat-developer-hub-orchestrator-infra重要redhat-developer-hub-orchestrator-infraHelm チャートは追加のクラスタースコープの OpenShift Serverless および OpenShift Serverless Logic Operator をデプロイするため、これをインストールするには管理者である必要があります。管理者は、OpenShift Serverless および Serverless Logic Operator のインストールプランを手動で承認する必要があります。以下の例のように、オーケストレーターを有効にして Backstage チャートをインストールします。
$ helm install <release_name> openshift-helm-charts/redhat-developer-hub --version 1.7.3 \ --set orchestrator.enabled=true(オプション) 次の例に示すように、
values.yamlファイルのglobal.dynamic.pluginsリストに Notifications と Signals プラグインを追加して有効にします。global: dynamic: plugins: - disabled: false package: "./dynamic-plugins/dist/backstage-plugin-notifications" - disabled: false package: "./dynamic-plugins/dist/backstage-plugin-signals" - disabled: false package: "./dynamic-plugins/dist/backstage-plugin-notifications-backend-dynamic" - disabled: false package: "./dynamic-plugins/dist/backstage-plugin-signals-backend-dynamic"(オプション) 次の例に示すように、値を
falseに設定し、Serverless Logic と Serverless Operator を個別または一緒に無効にできます。helm install <release_name> openshift-helm-charts/redhat-developer-hub \ --version 1.7.3 \ --set orchestrator.enabled=true \ --set orchestrator.serverlessOperator=false \ --set orchestrator.serverlessLogicOperator=false(オプション) 外部データベースを使用している場合は、
values.yamlファイルのorchestrator.sonataflowPlatformの下に次の設定を追加します。orchestrator: sonataflowPlatform: externalDBsecretRef: "<cred-secret>" externalDBName: "<database_name>" # The name of the user-configured existing database (Not the database that the orchestrator and sonataflow resources use). externalDBHost: "<database_host>" externalDBPort: "<database_port>"注記この手順では、Orchestrator による外部データベースの使用のみを設定します。外部 PostgreSQL インスタンスを使用するように Red Hat Developer Hub を設定するには、Helm を使用して PostgreSQL インスタンスを設定する の手順に従います。
検証
- Orchestrator プラグインが Red Hat Developer Hub UI に表示されていることを確認します。
- サンプルワークフローを作成して実行し、オーケストレーションが正しく機能していることを確認します。
4.2. OpenShift Container Platform Web コンソールから Helm を使用して Red Hat Developer Hub (RHDH) をインストールする リンクのコピーリンクがクリップボードにコピーされました!
(OpenShift Container Platform) Web コンソールを使用して、Orchestrator とともに Red Hat Developer Hub (RHDH) をインストールできます。この方法は、グラフィカルインターフェイスを好む場合や、Helm CLI を使用せずにクラスター全体のリソースをデプロイする場合に便利です。
前提条件
- 管理者として OpenShift Container Platform Web コンソールにログインしている。
- Red Hat Developer Hub Helm チャートリポジトリーにアクセスできる。
- クラスターはインターネットにアクセスできる、または Helm チャートは非接続環境にミラーリングされている。
手順
- OpenShift Container Platform Web コンソールで、Helm Charts に移動し、Red Hat Developer Hub Helm チャートリポジトリーが利用可能であることを確認します。
Red Hat Developer Hub の Orchestrator インフラストラクチャーを検索し、Install を選択します。
重要Orchestrator Infrastructure for Red Hat Developer Hub Helm チャートはクラスタースコープのリソースをデプロイするため、インストールするには管理者である必要があります。管理者は、OpenShift Serverless および Serverless Logic Operator のインストールプランを手動で承認する必要があります。
通常のユーザーとして、Red Hat Developer Hub チャートを検索し、
orchestrator.enabledの値をtrueに設定してインストールします。それ以外の場合は、Orchestrator はデプロイされません。- 正常にデプロイされるまで待ちます。
- Pod またはリリースに移動してデプロイメントステータスを監視します。
検証
デプロイメントの完了後:
- オーケストレーター関連の Pod は、選択した namespace で実行されます。
- クラスター全体のリソースが存在します。
- オーケストレーターの Red Hat Developer Hub UI への接続を開始できます。
4.3. Helm を使用する場合に Orchestrator プラグインで Red Hat Developer Hub をインストールするリソース制限 リンクのコピーリンクがクリップボードにコピーされました!
Helm を使用して Orchestrator プラグインとともに Red Hat Developer Hub (RHDH) をインストールする場合、チャートは SonataFlowPlatform コンポーネントのデフォルトの CPU およびメモリー制限を定義します。
これらの制限は、Pod が割り当てられたリソースを超えないようにクラスターによって適用されます。
- デフォルトのリソース制限
| Resource | デフォルト値 |
|---|---|
| CPU 上限 |
|
| メモリー上限 |
|
これらの値は、以下のいずれかの方法でオーバーライドできます。
-
values.yamlの使用 -
--setフラグの使用
-
オーバーライドは、次の例に示すように、
values.yamlをデフォルトとします。orchestrator: enabled: true sonataflowPlatform: resources: limits: cpu: "500m" memory: "1Gi"次の例に示すように、
--setでオーバーライドします。helm upgrade --install <release_name> openshift-helm-charts/redhat-developer-hub \ --set orchestrator.enabled=true \ --set orchestrator.sonataflowPlatform.resources.requests.cpu=500m \ --set orchestrator.sonataflowPlatform.resources.requests.memory=128Mi \ --set orchestrator.sonataflowPlatform.resources.limits.cpu=1 \ --set orchestrator.sonataflowPlatform.resources.limits.memory=2Gi注記--set設定は、orchestrator.enabledがtrueの場合にのみ適用されます。デフォルトではfalseに設定されます。
4.4. OpenShift Container Platform への Orchestrator コンポーネントの手動インストール リンクのコピーリンクがクリップボードにコピーされました!
セットアッププロセスとコンポーネントのバージョンを完全に制御する場合は、手動インストールを使用します。手動のインストール方法は、基礎となるインフラストラクチャーの設定に重点を置いています。
手順
- Red Hat OpenShift Serverless ドキュメント の手順に従って、OpenShift Serverless コンポーネントを手動でインストールします。
-
また、Pod の再起動時にワークフローのコンテキストが失われないように、ワークフローの永続性を設定する必要もあります。この設定は、
SonataFlowPlatformまたはSonataFlowカスタムリソース (CR) を使用して namespace レベルで実行できます。SonataFlowPlatformまたはSonataFlowカスタムリソースを使用して永続性を設定する詳細な手順は、ワークフローの永続性の管理 を参照してください。 - (オプション) 必要に応じて、カスタム PostgreSQL データベースをデプロイします。
第5章 Operator を使用してエアギャップ環境に Orchestrator プラグインをインストールする リンクのコピーリンクがクリップボードにコピーされました!
Operator を使用すると、完全にまたは部分的な非接続環境において Orchestrator プラグインで Red Hat Developer Hub (RHDH) を設定できます。
5.1. Operator を使用して完全に非接続の OpenShift Container Platform 環境に Red Hat Developer Hub と Orchestrator をインストールする リンクのコピーリンクがクリップボードにコピーされました!
Operator を使用して、Orchestrator プラグインを備えた Red Hat Developer Hub を完全なエアギャップ環境にインストールできます。
非接続インストールを使用することで、不正なアクセス、データ転送、または外部ソースとの通信を防止できます。
ヘルパースクリプトを使用して、Operator 関連のイメージをディスクにミラーリングし、インターネットに接続していない非接続環境に転送することで、Red Hat Developer Hub をインストールできます。
前提条件
- RHDH ミラーリングスクリプトを使用して、Red Hat Developer Hub Operator イメージがローカルレジストリーにミラーリングされている。詳細は、Operator を使用した完全な非接続環境への Red Hat Developer Hub のインストール を参照してください。
- ローカルレジストリーを使用して非接続環境が設定されている。
- 制限のあるネットワーク内で利用可能な NPM サーバーに NPM パッケージをプッシュする権限がある。
-
OpenShift Container Platform クラスターのバージョンに対応するバージョンの
oc-mirrorツールがインストールされている。
手順
oc-mirrorのImageSetConfigurationファイルを作成します。oc-mirrorは、すべてのイメージを自動的にミラーリングしないため、Serverless Logic Operator に必要なイメージと Operator をImageSetConfigurationファイルに含める必要があります。次のサンプルを使用してください。apiVersion: mirror.openshift.io/v2alpha1 kind: ImageSetConfiguration mirror: additionalimages: - name: registry.redhat.io/openshift-serverless-1/logic-jobs-service-postgresql-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-jobs-service-ephemeral-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-data-index-ephemeral-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-db-migrator-tool-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:1.36.0 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:4.19 # For example: registry.redhat.io/redhat/redhat-operator-index:v4.19 packages: - name: logic-operator-rhel8 channels: - name: alpha minVersion: 1.36.0 maxVersion: 1.36.0 - name: serverless-operator channels: - name: stable minVersion: 1.36.0 maxVersion: 1.36.1または、
podmanコマンドを使用して、不足しているイメージを見つけて、バージョンが変更された場合はそのイメージをadditionalimagesリストに追加することもできます。IMG=registry.redhat.io/openshift-serverless-1/logic-operator-bundle:1.36 mkdir local-manifests-osl podman create --name temp-container "$IMG" -c "cat /manifests/logic-operator-rhel8.clusterserviceversion.yaml" podman cp temp-container:/manifests ./local-manifests-osl podman rm temp-container yq -r '.data."controllers_cfg.yaml" | from_yaml | .. | select(tag == "!!str") | select(test("^.\\/.:.*$"))' ./local-manifests-osl/manifests/logic-operator-rhel8-controllers-config_v1_configmap.yamloc-mirrorコマンドを実行して、ImageSetConfiguration.yamlファイル内のイメージをミラーリングします。以下に例を示します。oc-mirror --config=ImageSetConfiguration.yaml file:///path/to/mirror-archive --authfile /path/to/authfile --v2注記oc-mirrorコマンドは、ミラーアーカイブファイルと必要なクラスターマニフェストを含むローカルワークスペースを生成します。-
/path/to/mirror-archiveで指定されたディレクトリーを、非接続環境内の踏み台ホストに転送します。 ミラーレジストリーにアクセスできる踏み台ホストから、ディスクディレクトリーのイメージをターゲットレジストリーにミラーリングします。以下に例を示します。
oc-mirror --v2 --from <mirror-archive-file> docker://<target-registry-url:port> --workspace file://<workspace folder> --authfile /path/to/authfileここでは、以下のようになります。
<mirror-archive-file>-
転送された
tarファイルの名前を入力します。 <target-registry-url:port>-
ローカルレジストリーを入力します (例:
registry.localhost:5000)。
次の例に示すように、プッシュステップ中に生成されたクラスター全体のリソースを適用して、すべてのイメージプルをローカルレジストリーにリダイレクトします。
cd <workspace folder>/working-dir/cluster-resources/ oc apply -f .以下のいずれかの方法を使用して、オーケストレーター 1.7.1 の Node Package Manager (NPM)パッケージをダウンロードします。
次のレジストリーから
tgzファイルとしてダウンロードします。- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator/-/backstage-plugin-orchestrator-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator-backend-dynamic/-/backstage-plugin-orchestrator-backend-dynamic-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic/-/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator-form-widgets/-/backstage-plugin-orchestrator-form-widgets-1.7.1.tgz
または、次の例に示すように Red Hat NPM registry からの NPM パッケージを使用します。
npm pack "@redhat/backstage-plugin-orchestrator@1.7.1" --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-orchestrator-backend-dynamic@1.7.1" --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic@1.7.1 --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-orchestrator-form-widgets@1.7.1" --registry=https://npm.registry.redhat.com
次の例に示すように、ダウンロードした NPM パッケージを NPM サーバーにプッシュします。
npm publish backstage-plugin-orchestrator-1.7.1.tgz npm publish backstage-plugin-orchestrator-backend-dynamic-1.7.1.tgz npm publish backstage-plugin-orchestrator-form-widgets-1.7.1.tgz npm publish backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-1.7.1.tgz-
OperatorHubを使用して OpenShift Serverless Operator と OpenShift Serverless Logic Operator をインストールします。 - Backstage カスタムリソース (CR) を作成します。
Operator インストールの Orchestrator プラグインの依存関係 の説明に従って、Orchestrator の Backstage CR を設定します。
すべてのリソースを作成し、それに応じて Backstage インスタンスを設定します。RHDH でカスタム NPM レジストリーを参照する方法は、カスタム NPM レジストリーの設定 を参照してください。
検証
- RHDH Pod を再起動し、コンポーネントが適切にデプロイされるまで待ちます。
- 安定したら、RHDH UI に移動し、Orchestrator UI にアクセスでき、正しく機能していることを確認します。
Orchestrator UI へのアクセスが成功すれば、基盤となるコンポーネントが実行されており、クラスターがプラグインを認識していることがわかります。
5.2. Operator を使用して、部分的に非接続の OpenShift Container Platform 環境に Orchestrator を備えた Red Hat Developer Hub をインストールする リンクのコピーリンクがクリップボードにコピーされました!
Operator を使用して、Orchestrator プラグインを備えた Red Hat Developer Hub を部分的なエアギャップ環境にインストールできます。
非接続インストールを使用することで、不正なアクセス、データ転送、または外部ソースとの通信を防止できます。
oc-mirror コマンドを使用すると、アクセス可能なローカルミラーレジストリーにリソースを直接ミラーリングし、生成されたクラスターリソースを適用できます。
前提条件
- RHDH ミラーリングスクリプトを使用して、Red Hat Developer Hub Operator イメージがローカルレジストリーにミラーリングされている。詳細は、Operator を使用して部分的に非接続環境に Red Hat Developer Hub をインストールする を参照してください。
- ローカルレジストリーを使用して非接続環境が設定されている。
- 制限のあるネットワーク内で利用可能な NPM サーバーに NPM パッケージをプッシュする権限がある。
-
OpenShift Container Platform クラスターのバージョンに対応するバージョンの
oc-mirrorツールがインストールされている。
手順
oc-mirrorのImageSetConfigurationファイルを作成します。oc-mirrorは、すべてのイメージを自動的にミラーリングしないため、Serverless Logic Operator に必要なイメージと Operator をImageSetConfigurationファイルに含める必要があります。次のサンプルを使用してください。apiVersion: mirror.openshift.io/v2alpha1 kind: ImageSetConfiguration mirror: additionalimages: - name: registry.redhat.io/openshift-serverless-1/logic-jobs-service-postgresql-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-jobs-service-ephemeral-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-data-index-ephemeral-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-db-migrator-tool-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:1.36.0 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:4.19 # For example: registry.redhat.io/redhat/redhat-operator-index:v4.19 packages: - name: logic-operator-rhel8 channels: - name: alpha minVersion: 1.36.0 maxVersion: 1.36.0 - name: serverless-operator channels: - name: stable minVersion: 1.36.0 maxVersion: 1.36.1または、
podmanコマンドを使用して不足しているイメージを見つけ、バージョンが変更された場合はそのイメージをadditionalimagesリストに追加することもできます。IMG=registry.redhat.io/openshift-serverless-1/logic-operator-bundle:1.36.0-8 mkdir local-manifests-osl podman create --name temp-container "$IMG" -c "cat /manifests/logic-operator-rhel8.clusterserviceversion.yaml" podman cp temp-container:/manifests ./local-manifests-osl podman rm temp-container yq -r '.data."controllers_cfg.yaml" | from_yaml | .. | select(tag == "!!str") | select(test("^.\\/.:.*$"))' ./local-manifests-osl/manifests/logic-operator-rhel8-controllers-config_v1_configmap.yamloc-mirrorコマンドを実行して、ImageSetConfiguration.yamlファイル内のイメージをミラーリングします。以下に例を示します。oc-mirror --config=imagesetconfiguration.yaml docker://<registry URL:port> --workspace file://<workspace folder> --authfile /path/to/authfile --v2 cd <workspace folder>/working-dir/cluster-resources/ oc apply -f .以下のいずれかの方法を使用して、オーケストレーター 1.7.1 の Node Package Manager (NPM)パッケージをダウンロードします。
次のレジストリーから
tgzファイルとしてダウンロードします。- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator/-/backstage-plugin-orchestrator-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator-backend-dynamic/-/backstage-plugin-orchestrator-backend-dynamic-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic/-/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator-form-widgets/-/backstage-plugin-orchestrator-form-widgets-1.7.1.tgz
または、次の例に示すように Red Hat NPM registry からの NPM パッケージを使用します。
npm pack "@redhat/backstage-plugin-orchestrator@1.7.1" --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-orchestrator-backend-dynamic@1.7.1" --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic@1.7.1 --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-orchestrator-form-widgets@1.7.1" --registry=https://npm.registry.redhat.com
次の例に示すように、ダウンロードした NPM パッケージを NPM サーバーにプッシュします。
npm publish backstage-plugin-orchestrator-1.7.1.tgz npm publish backstage-plugin-orchestrator-backend-dynamic-1.7.1.tgz npm publish backstage-plugin-orchestrator-form-widgets-1.7.1.tgz npm publish backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-1.7.1.tgz-
OperatorHubを使用して OpenShift Serverless Operator と OpenShift Serverless Logic Operator をインストールします。 - Backstage カスタムリソース (CR) を作成します。
Operator インストールの Orchestrator プラグインの依存関係 の説明に従って、Orchestrator の Backstage CR を設定します。
すべてのリソースを作成し、それに応じて Backstage インスタンスを設定します。RHDH でカスタム NPM レジストリーを参照する方法は、カスタム NPM レジストリーの設定 を参照してください。
検証
- RHDH Pod を再起動し、コンポーネントが適切にデプロイされるまで待ちます。
- 安定したら、RHDH UI に移動し、Orchestrator UI にアクセスでき、正しく機能していることを確認します。
Orchestrator UI へのアクセスが成功すれば、基盤となるコンポーネントが実行されており、クラスターがプラグインを認識していることがわかります。
第6章 Helm チャートを使用してエアギャップ環境に Orchestrator プラグインをインストールする リンクのコピーリンクがクリップボードにコピーされました!
Helm チャートを使用して、完全または部分的な非接続環境で、Orchestrator プラグインを使用して Red Hat Developer Hub (RHDH) を設定できます。
6.1. Helm チャートを使用して、完全に非接続の OpenShift Container Platform 環境に Orchestrator を備えた Red Hat Developer Hub をインストールする リンクのコピーリンクがクリップボードにコピーされました!
Helm チャートを使用して、完全にエアギャップ化された OpenShift Container Platform 環境に Orchestrator プラグインを備えた Red Hat Developer Hub (RHDH) をインストールできます。
イメージを中間ディスクにミラーリングし、そのディスクからターゲットのローカルレジストリーにミラーリングして、生成されたクラスターリソースを適用できます。
前提条件
- ローカルレジストリーを使用して非接続環境が設定されている。
- 制限のあるネットワーク内で利用可能な NPM サーバーに NPM パッケージをプッシュする権限がある。
-
OpenShift Container Platform クラスターのバージョンに対応するバージョンの
oc-mirrorツールがインストールされている。
手順
oc-mirror用のImageSetConfiguration.yamlファイルを作成します。次の例に示すように、Serverless Logic Operator に必要なすべてのミラーリングされたイメージを含めるには、ImageSetConfigurationファイルを使用する必要があります。apiVersion: mirror.openshift.io/v2alpha1 kind: ImageSetConfiguration mirror: additionalimages: - name: registry.redhat.io/openshift-serverless-1/logic-jobs-service-postgresql-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-jobs-service-ephemeral-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-data-index-ephemeral-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-db-migrator-tool-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:1.36.0 helm: repositories: - name: openshift-charts url: https://charts.openshift.io charts: - name: redhat-developer-hub version: "1.7.3" - name: redhat-developer-hub-orchestrator-infra version: "1.7.3" operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:4.19 # For example: registry.redhat.io/redhat/redhat-operator-index:v4.19 packages: - name: logic-operator-rhel8 channels: - name: alpha minVersion: 1.36.0 maxVersion: 1.36.0 - name: serverless-operator channels: - name: stable minVersion: 1.36.0 maxVersion: 1.36.1または、
podmanコマンドを使用して、不足しているイメージを見つけて、バージョンが変更された場合はそのイメージをadditionalimagesリストに追加することもできます。IMG=registry.redhat.io/openshift-serverless-1/logic-operator-bundle:1.36 mkdir local-manifests-osl podman create --name temp-container "$IMG" -c "cat /manifests/logic-operator-rhel8.clusterserviceversion.yaml" podman cp temp-container:/manifests ./local-manifests-osl podman rm temp-container yq -r '.data."controllers_cfg.yaml" | from_yaml | .. | select(tag == "!!str") | select(test("^.\\/.:.*$"))' ./local-manifests-osl/manifests/logic-operator-rhel8-controllers-config_v1_configmap.yamloc-mirrorコマンドを実行して、ImageSetConfiguration.yamlファイル内のイメージをミラーリングします。以下に例を示します。oc-mirror --config=ImageSetConfiguration.yaml file:///path/to/mirror-archive --authfile /path/to/authfile --v2注記oc-mirrorコマンドは、ImageSetConfigurationファイルにリストされているチャートをプルし、/path/to/mirror-archiveディレクトリーの下のtgzアーカイブとして使用できるようにします。次の例に示すように、プッシュステップ中に生成されたクラスター全体のリソースを適用して、すべてのイメージプルをローカルレジストリーにリダイレクトします。
cd <workspace folder>/working-dir/cluster-resources/ oc apply -f .-
生成されたミラーアーカイブファイル (例:
/path/to/mirror-archive/mirror_000001.tar) を、非接続環境内の踏み台ホストに転送します。 ミラーレジストリーにアクセスできる、非接続環境の踏み台ホストから、アーカイブファイルのイメージをターゲットレジストリーにミラーリングします。以下に例を示します。
oc-mirror --v2 --from <mirror-archive-file> docker://<target-registry-url:port> --workspace file://<workspace folder> --authfile /path/to/authfileここでは、以下のようになります。
<mirror-archive-file>-
転送された
tarファイルの名前を入力します。 <target-registry-url:port>-
ローカルレジストリーを入力します (例:
registry.localhost:5000)。
以下のいずれかの方法を使用して、オーケストレーター 1.7.1 の Node Package Manager (NPM)パッケージをダウンロードします。
次のレジストリーから
tgzファイルとしてダウンロードします。- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator/-/backstage-plugin-orchestrator-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator-backend-dynamic/-/backstage-plugin-orchestrator-backend-dynamic-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic/-/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator-form-widgets/-/backstage-plugin-orchestrator-form-widgets-1.7.1.tgz
または、次の例に示すように Red Hat NPM registry からの NPM パッケージを使用します。
npm pack "@redhat/backstage-plugin-orchestrator@1.7.1" --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-orchestrator-backend-dynamic@1.7.1" --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic@1.7.1 --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-orchestrator-form-widgets@1.7.1" --registry=https://npm.registry.redhat.com
次の例に示すように、ダウンロードした NPM パッケージを NPM サーバーにプッシュします。
npm publish backstage-plugin-orchestrator-1.7.1.tgz npm publish backstage-plugin-orchestrator-backend-dynamic-1.7.1.tgz npm publish backstage-plugin-orchestrator-form-widgets-1.7.1.tgz npm publish backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-1.7.1.tgz-
redhat-developer-hub-orchestrator-infraHelm チャートを適用し、インストールプランを承認します。詳細は、Helm チャートを使用したエアギャップインストールの手順 を参照してください。 RHDH 1.7 Helm チャートを適用します。以下の例のように、バージョン 1.7.3 を含め、Orchestrator プラグインを有効にします。
orchestrator.enabled=trueRHDH 1.7 Helm チャートは、完全な URL 参照を使用して、公式の Red Hat NPM レジストリーから Orchestrator プラグインをプルすることをデフォルトとしています。ローカルレジストリーを指すようにこの動作をオーバーライドする必要があります。
カスタムレジストリーを使用するように Orchestrator プラグインを設定するには、次の手順を実行します。
-
values.yamlファイルを開きます。 Orchestrator.
plugins セクションで Orchestrator プラグインパッケージを一覧表示します。次の例に示すように、簡略化されたパッケージ参照を、カスタム NPM レジストリーを指す完全な URL に置き換える必要があります。orchestrator: plugins: - disabled: false package: <custom_NPM_registry_URL>[:<port>]/@redhat/backstage-plugin-orchestrator-backend-dynamic/-/backstage-plugin-orchestrator-backend-dynamic-{product-bundle-version}.tgz integrity: sha512-xxxxxx - disabled: false package: <custom_NPM_registry_URL>[:<port>]/@redhat/backstage-plugin-orchestrator/-/backstage-plugin-orchestrator-{product-bundle-version}.tgz integrity: sha512-xxxxxy - disabled: false package: <custom_NPM_registry_URL>[:<port>]/@redhat/backstage-plugin-orchestrator-form-widgets/-/backstage-plugin-orchestrator-form-widgets-{product-bundle-version}.tgz integrity: sha512-xxxxxz - disabled: false package: <custom_NPM_registry_URL>[:<port>]/@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic/-/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-{product-bundle-version}.tgz integrity: sha512-xxxx1ここでは、以下のようになります。
<custom_NPM_registry_URL>- カスタムレジストリーのアドレスを入力し、sha512-xxxxxx などの整合性チェックサムがレジストリー内のファイルと一致していることを確認します。
-
検証
- RHDH Pod を再起動し、コンポーネントが適切にデプロイされるまで待ちます。
- デプロイメントが完了したら、RHDH UI に移動し、Orchestrator UI にアクセスし、正常に機能していることを確認します。
Orchestrator UI へのアクセスが成功すれば、基盤となるコンポーネントが実行されており、クラスターがプラグインを認識していることがわかります。
6.2. Helm チャートを使用して、部分的に非接続の OpenShift Container Platform 環境に Orchestrator を備えた Red Hat Developer Hub をインストールする リンクのコピーリンクがクリップボードにコピーされました!
Helm チャートを使用して、部分的な OpenShift Container Platform 環境に Orchestrator プラグインを備えた Red Hat Developer Hub (RHDH) をインストールできます。
非接続インストールを使用することで、不正なアクセス、データ転送、または外部ソースとの通信を防止できます。
oc-mirror コマンドを使用すると、アクセス可能なローカルレジストリーにリソースを直接ミラーリングし、生成されたクラスターリソースを適用できます。
前提条件
- ローカルレジストリーを使用して非接続環境が設定されている。
- 制限のあるネットワーク内で利用可能な NPM サーバーに NPM パッケージをプッシュする権限がある。
-
OpenShift Container Platform クラスターのバージョンに対応するバージョンの
oc-mirrorツールがインストールされている。
手順
oc-mirrorのImageSetConfigurationファイルを作成します。oc-mirrorは、すべてのイメージを自動的にミラーリングしないため、Serverless Logic Operator に必要なイメージと Operator をImageSetConfigurationファイルに含める必要があります。次のサンプルを使用してください。apiVersion: mirror.openshift.io/v2alpha1 kind: ImageSetConfiguration mirror: additionalimages: - name: registry.redhat.io/openshift-serverless-1/logic-jobs-service-postgresql-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-jobs-service-ephemeral-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-data-index-ephemeral-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-db-migrator-tool-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.36.0 - name: registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:1.36.0 helm: repositories: - name: openshift-charts url: https://charts.openshift.io charts: - name: redhat-developer-hub version: "1.7.3" - name: redhat-developer-hub-orchestrator-infra version: "1.7.3" operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:4.19 # For example: registry.redhat.io/redhat/redhat-operator-index:v4.19 packages: - name: logic-operator-rhel8 channels: - name: alpha minVersion: 1.36.0 maxVersion: 1.36.0 - name: serverless-operator channels: - name: stable minVersion: 1.36.0 maxVersion: 1.36.1oc-mirrorコマンドを実行してイメージとチャートをプルし、イメージをターゲットレジストリーに直接プッシュすることで、ImageSetConfiguration.yamlファイル内のイメージをミラーリングします。以下に例を示します。oc-mirror --config=imagesetconfiguration.yaml docker://<registry URL:port> --workspace file://<workspace folder> --authfile /path/to/authfile --v2注記oc-mirrorコマンドは、ImageSetConfigurationファイルにリストされているチャートをプルし、<workspace folder>ディレクトリーの下にtgzアーカイブとして使用できるようにします。生成されたクラスターリソースを非接続クラスターに適用します。以下に例を示します。
cd <workspace folder>/working-dir/cluster-resources/ oc apply -f .以下のいずれかの方法を使用して、オーケストレーター 1.7.1 の Node Package Manager (NPM)パッケージをダウンロードします。
次のレジストリーから
tgzファイルとしてダウンロードします。- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator/-/backstage-plugin-orchestrator-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator-backend-dynamic/-/backstage-plugin-orchestrator-backend-dynamic-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic/-/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-1.7.1.tgz
- https://npm.registry.redhat.com/@redhat/backstage-plugin-orchestrator-form-widgets/-/backstage-plugin-orchestrator-form-widgets-1.7.1.tgz
または、次の例に示すように Red Hat NPM registry からの NPM パッケージを使用します。
npm pack "@redhat/backstage-plugin-orchestrator@1.7.1" --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-orchestrator-backend-dynamic@1.7.1" --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic@1.7.1 --registry=https://npm.registry.redhat.com npm pack "@redhat/backstage-plugin-orchestrator-form-widgets@1.7.1" --registry=https://npm.registry.redhat.com
次の例に示すように、ダウンロードした NPM パッケージを NPM サーバーにプッシュします。
npm publish backstage-plugin-orchestrator-1.7.1.tgz npm publish backstage-plugin-orchestrator-backend-dynamic-1.7.1.tgz npm publish backstage-plugin-orchestrator-form-widgets-1.7.1.tgz npm publish backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-1.7.1.tgz-
redhat-developer-hub-orchestrator-infraHelm チャートを適用し、インストールプランを承認します。詳細は、Helm チャートを使用したエアギャップインストールの手順 を参照してください。 RHDH 1.7 Helm チャートを適用します。以下の例のように、バージョン 1.7.3 を含め、Orchestrator プラグインを有効にします。
orchestrator.enabled=trueRHDH 1.7 Helm チャートは、完全な URL 参照を使用して、公式の Red Hat NPM レジストリーから Orchestrator プラグインをプルすることをデフォルトとしています。ローカルレジストリーを指すようにこの動作をオーバーライドする必要があります。
カスタムレジストリーを使用するように Orchestrator プラグインを設定するには、次の手順を実行します。
-
values.yamlファイルを開きます。 Orchestrator プラグインパッケージを、
orchestrator.pluginsセクションの下に明示的にリストします。次の例に示すように、簡略化されたパッケージ参照を、カスタム NPM レジストリーを指す完全な URL に置き換える必要があります。
orchestrator: plugins: - disabled: false package: <custom_NPM_registry_URL>[:<port>]/@redhat/backstage-plugin-orchestrator-backend-dynamic/-/backstage-plugin-orchestrator-backend-dynamic-{product-bundle-version}.tgz integrity: sha512-xxxxxx - disabled: false package: <custom_NPM_registry_URL>[:<port>]/@redhat/backstage-plugin-orchestrator/-/backstage-plugin-orchestrator-{product-bundle-version}.tgz integrity: sha512-xxxxxy - disabled: false package: <custom_NPM_registry_URL>[:<port>]/@redhat/backstage-plugin-orchestrator-form-widgets/-/backstage-plugin-orchestrator-form-widgets-{product-bundle-version}.tgz integrity: sha512-xxxxxz - disabled: false package: <custom_NPM_registry_URL>[:<port>]/@redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic/-/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic-{product-bundle-version}.tgz integrity: sha512-xxxx1ここでは、以下のようになります。
<custom_NPM_registry_URL>- カスタムレジストリーのアドレスを入力し、sha512-xxxxxx などの整合性チェックサムがレジストリー内のファイルと一致していることを確認します。
-
検証
- RHDH Pod を再起動し、コンポーネントが適切にデプロイされるまで待ちます。
- デプロイメントが完了したら、RHDH UI に移動し、Orchestrator UI にアクセスでき、正しく機能していることを確認します。
Orchestrator UI へのアクセスが成功すれば、基盤となるコンポーネントが実行されており、クラスターがプラグインを認識していることがわかります。
第7章 サーバーレスワークフローのビルドとデプロイ リンクのコピーリンクがクリップボードにコピーされました!
ワークフローをデプロイして Orchestrator プラグインで使用できるようにするには、次に示す主なステップに従います。
- ワークフローイメージのビルド
- ワークフローマニフェストの生成
- クラスターへのワークフローのデプロイ
このプロセスにより、ワークフローがローカルマシンからクラスター上のデプロイメントに移動します。
7.1. ワークフローイメージの利点 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic Operator はワークフローの動的ビルドをサポートしていますが、このアプローチは主に実験用です。実稼働環境でのデプロイメントでは、次の理由により、イメージをビルドする方法が推奨されます。
- 実稼働環境で運用するための準備: 事前にビルドされたイメージは、実稼働前にスキャン、保護、テストできます。
-
GitOps 互換性: Orchestrator は、ワークフローとその状態を追跡するために、中央の OpenShift Serverless Logic Operator インスタンスに依存します。この追跡サービスを使用するには、事前にビルドされたイメージを必要とする
gitopsプロファイルを使用してワークフローをデプロイしなければなりません。 - テストと品質: イメージをビルドすると、テストプロセスをより細かく制御できるようになります。
7.1.1. プロジェクト構造の概要 リンクのコピーリンクがクリップボードにコピーされました!
このプロジェクトでは、Quarkus プロジェクトレイアウト (Maven プロジェクト構造) を活用します。この構造は、次の 01_basic ワークフローの例で示されています。
01_basic
├── pom.xml
├── README.md
└── src
└── main
├── docker
│ ├── Dockerfile.jvm
│ ├── Dockerfile.legacy-jar
│ ├── Dockerfile.native
│ └── Dockerfile.native-micro
└── resources
├── application.properties
├── basic.svg
├── basic.sw.yaml
├── schemas
│ ├── basic__main-schema.json
│ └── workflow-output-schema.json
└── secret.properties
メインワークフローリソースは、src/main/resources/ ディレクトリーの下にあります。
このプロジェクト構造は、kn-workflow CLI によって生成されました。スタートガイド に従って、自分で構造を生成することもできます。Quarkus プロジェクトの詳細は、Creating your first application を参照してください。
7.1.2. サーバーレスワークフロープロジェクトをローカルで作成して実行する リンクのコピーリンクがクリップボードにコピーされました!
kn-workflow CLI は、ワークフローマニフェストとプロジェクト構造を生成する重要なツールです。開発を成功させ、すぐにテストするには、次のステップを実行して、新しいサーバーレスワークフローの開発をローカルで開始します。
手順
次の例に示すように、
kn-workflowCLI を使用して Quarkus 構造に準拠した新しいワークフロープロジェクトを作成します。kn-workflow quarkus create --name <specify project name, for example ,00_new_project>次の例に示すように、ワークフローを編集し、スキーマと特定のファイルを追加して、プロジェクトフォルダーからローカルで実行します。
kn-workflow quarkus run次のイメージをプルする
kn-workflow runを使用して、ワークフローをローカルで実行します。registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:1.36.0ワークフローイメージをビルドするために、
kn-workflowCLI は次のイメージをプルします。registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.36.0-8 registry.access.redhat.com/ubi9/openjdk-17:1.21-2
7.2. ワークフローイメージをローカルでビルドする リンクのコピーリンクがクリップボードにコピーされました!
ビルドスクリプト (build.sh) を使用してワークフローイメージをビルドできます。それを、ローカルでもコンテナー内でも実行できます。このセクションでは、ワークフローイメージをローカルでビルドする方法について説明します。
手順
次の例に示すように、プロジェクトを複製します。
git clone git@github.com:rhdhorchestrator/orchestrator-demo.git cd orchestrator-demoスクリプトのヘルプメニューを確認します。
./scripts/build.sh --helpイメージパス (
-i)、ワークフローソースディレクトリー (-w)、マニフェスト出力ディレクトリー (-m) などの必要なフラグを指定して、build.shスクリプトを実行します。重要次の例に示すように、タグを使用して完全なターゲットイメージパスを指定する必要があります。
./scripts/build.sh --image=quay.io/orchestrator/demo-basic:test -w 01_basic/ -m 01_basic/manifests
7.2.1. build-sh スクリプトの機能と重要なフラグ リンクのコピーリンクがクリップボードにコピーされました!
build-sh スクリプトは、次のタスクを順番に実行します。
-
kn-workflowCLI を使用してワークフローマニフェストを生成します。 -
podmanまたはdockerを使用してワークフローイメージをビルドします。 -
オプション: スクリプトはイメージをイメージレジストリーにプッシュし、
kubectlを使用してワークフローをデプロイします。
ヘルプメニューにアクセスして、スクリプトの設定オプションを確認し、使用可能なフラグとその機能を確認できます。
./scripts/build.sh [flags]
スクリプトを実行するには、次のフラグが必須です。
| フラグ | 説明 |
|---|---|
|
|
必須: 完全なイメージパス (例: |
|
| ワークフローソースディレクトリー (デフォルトはカレントディレクトリー) |
|
| 生成されたマニフェストを保存する場所 |
|
| イメージをレジストリーにプッシュします |
|
| ワークフローをデプロイします |
|
| ヘルプメッセージを表示します |
このスクリプトは、ビルダーとランタイムイメージのオーバーライド、namespace のターゲット設定、永続フラグもサポートします。
7.2.2. ビルドスクリプトでサポートされる環境変数 リンクのコピーリンクがクリップボードにコピーされました!
build-sh スクリプトは、スクリプト自体を変更せずにワークフロービルドプロセスをカスタマイズするために、次の環境変数をサポートしています。
QUARKUS_EXTENSIONSQUARKUS_EXTENSIONS変数は、ワークフローに必要な追加の Quarkus エクステンションを指定します。この変数の形式は、次の例に示す完全修飾拡張 ID のコンマ区切りリストです。export QUARKUS_EXTENSIONS="io.quarkus:quarkus-smallrye-reactive-messaging-kafka"ビルド時に Kafka メッセージングサポートまたはその他の統合を追加します。
MAVEN_ARGS_APPENDMAVEN_ARGS_APPEND変数は、Maven build コマンドに引数を追加します。この変数の形式は、次の例に示す Maven CLI 引数の文字列です。export MAVEN_ARGS_APPEND="-DmaxYamlCodePoints=35000000"ビルド動作を制御します。たとえば、YAML 入力ファイルの最大入力サイズを制御する
maxYamlCodePointsパラメーターを 35000000 文字 (UTF-8 では ~33MB) に設定します。
7.2.3. 必要なツール リンクのコピーリンクがクリップボードにコピーされました!
build-sh スクリプトをローカルで実行してワークフローのライフサイクルを管理するには、次のコマンドラインツールをインストールする必要があります。
| ツール | 概念的な目的 |
|---|---|
| podman または docker | ワークフローイメージのビルドに必要なコンテナーランタイム。 |
|
| Kubernetes CLI。 |
|
| YAML プロセッサー。 |
|
| JSON プロセッサー。 |
|
| シェルユーティリティー。 |
|
| ワークフローマニフェストを生成するための CLI。 |
7.2.4. 01_basic ワークフローのビルド リンクのコピーリンクがクリップボードにコピーされました!
リポジトリーのルートディレクトリーからスクリプトを実行するには、-w フラグを使用してワークフローディレクトリーを指す必要があります。さらに、-m フラグを使用して出力ディレクトリーを指定します。
前提条件
- タグを使用してターゲットイメージを指定した。
手順
以下のコマンドを実行します。
./scripts/build.sh --image=quay.io/orchestrator/demo-basic:test -w 01_basic/ -m 01_basic/manifestsこのビルドコマンドは、次の 2 つのアーティファクトを生成します。
-
ワークフローイメージと Kubernetes マニフェスト:
quay.io/orchestrator/demo-basic:test、latestとしてタグ付け。 -
Kubernetes マニフェストの配置場所:
01_basic/manifests/
-
ワークフローイメージと Kubernetes マニフェスト:
-
オプション:
--pushフラグを追加すると、ビルド後にイメージを自動的にプッシュできます。それ以外の場合は、デプロイする前に手動でプッシュする必要があります。
7.3. 生成されるワークフローマニフェスト リンクのコピーリンクがクリップボードにコピーされました!
次の例は、01_basic/manifests 配下に何が生成されるかを示しています。
01_basic/manifests
├── 00-secret_basic-secrets.yaml
├── 01-configmap_basic-props.yaml
├── 02-configmap_01-basic-resources-schemas.yaml
└── 03-sonataflow_basic.yaml
00-secret_basic-secrets.yaml-
01_basic/src/main/resources/secret.propertiesからのシークレットが含まれます。値は、CR を適用した後、または GitOps を使用するときに後で設定できるため、この段階では必要ありません。
OpenShift Serverless Logic v1.36 では、シークレットを更新した後に、ワークフロー Pod を手動で再起動して変更を適用する必要があります。
01-configmap_basic-props.yaml- application.properties からのアプリケーションプロパティーを保持します。この ConfigMap を変更すると、Pod の自動再起動がトリガーされます。
02-configmap_01-basic-resources-schemas.yamlsrc/main/resources/schemas からの JSON スキーマが含まれます。
注記GitOps プロファイルを使用する場合、特定の設定リソースのデプロイは必要ありません。
03-sonataflow_basic.yamlワークフローを定義する SonataFlow カスタムリソース (CR)。
podTemplate: container: image: quay.io/orchestrator/demo-basic resources: {} envFrom: - secretRef: name: basic-secretspersistence: postgresql: secretRef: name: sonataflow-psql-postgresql userKey: <your_postgres_username> passwordKey: <your_postgres_password> serviceRef: name: sonataflow-psql-postgresql port: 5432 databaseName: sonataflow databaseSchema: basicここでは、以下のようになります。
postgresql:secretRef:name- デプロイメントのシークレット名を入力します。
postgresql:secretRef:userKey- デプロイメントのキーを入力します。
postgresql:secretRef:passwordKey- デプロイメントのパスワードを入力します。
postgresql:serviceRef:nameデプロイメントのサービス名を入力します。
外部データベースに接続する必要がある場合は、
serviceRefをjdbcUrlに置き換えます。ワークフローの永続性の管理 を参照してください。
デフォルトでは、スクリプトは namespace なしですべてのマニフェストを生成します。事前にターゲット namespace がわかっている場合は、--namespace フラグを使用してスクリプトに namespace を指定できます。そうでない場合は、マニフェストをクラスターに適用するときに namespace を指定する必要があります。ワークフローサービスの設定 を参照してください。
7.4. クラスターへのワークフローのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
イメージがイメージレジストリーにプッシュされ、デプロイメントマニフェストが使用可能になっているため、ワークフローをクラスターにデプロイできます。
前提条件
次のバージョンのコンポーネントがインストールされた OpenShift Container Platform クラスターがあります。
- Red Hat Developer Hub (RHDH) 1.7
- Orchestrator プラグイン 1.7.1
-
OpenShift Serverless
v1.36 OpenShift Serverless Logic
v1.36これらのコンポーネントをインストールする方法については、OpenShift Container Platform の Orchestrator プラグインコンポーネント を参照してください。
-
サポートサービス を管理する
SonataflowPlatformカスタムリソース (CR) が含まれる namespace にワークフローマニフェストを適用する必要があります。
手順
次の例に示すように、ターゲット namespace を指定して
kubectl createコマンドを使用し、Kubernetes マニフェストを適用します。kubectl create -n <your_namespace> -f ./01_basic/manifests/.デプロイ後、次の例に示すようにワークフロー Pod のステータスを監視します。
kubectl get pods -n <your_namespace> -l app=basicSecret または ConfigMap の設定が欠落しているか不完全であるため、Pod の状態が最初は
Errorになる場合があります。次の例に示すように、Pod ログを検査します。
oc logs -n <your_namespace> basic-f7c6ff455-vwl56次のコードは出力例です。
SRCFG00040: The config property quarkus.openapi-generator.notifications.auth.BearerToken.bearer-token is defined as the empty String ("") which the following Converter considered to be null: io.smallrye.config.Converters$BuiltInConverter java.lang.RuntimeException: Failed to start quarkus ... Caused by: io.quarkus.runtime.configuration.ConfigurationException: Failed to read configuration propertiesこのエラーは、
quarkus.openapi-generator.notifications.auth.BearerToken.bearer-tokenプロパティーが欠落していることを示しています。ログに
ConfigurationException: Failed to read configuration propertiesエラーが表示されたり、値が欠落していることが示される場合は、次の例に示すように ConfigMap を取得します。oc get -n <your_namespace> configmaps basic-props -o yaml次のコードはサンプル出力の例です。
apiVersion: v1 data: application.properties: | # Backstage notifications service quarkus.rest-client.notifications.url=${BACKSTAGE_NOTIFICATIONS_URL} quarkus.openapi-generator.notifications.auth.BearerToken.bearer-token=${NOTIFICATIONS_BEARER_TOKEN} ...Secret を使用して提供された値でプレースホルダーを解決します。
次の例に示すように、対応する Secret を編集し、適切な base64 エンコード値を指定して、
application.properties内のプレースホルダーを解決する必要があります。kubectl edit secrets -n <your_namespace> basic-secrets-
ワークフロー Pod を再起動して、OpenShift Serverless Logic
v1.36で Secret の変更を有効にします。
検証
次の例に示すように、Pod を再度確認して、デプロイメントのステータスを検証します。
oc get pods -n <your_namespace> -l app=basic正常にデプロイされたワークフロー Pod では、次の例のようなステータスが期待されます。
NAME READY STATUS RESTARTS AGE basic-f7c6ff455-grkxd 1/1 Running 0 47s-
Pod が
Running状態になると、ワークフローが Red Hat Developer Hub 内の Orchestrator プラグインに表示されます。
次のステップ
- 提供されているビルドスクリプトを調べて実際のステップを抽出し、任意の CI/CD ツール (GitHub Actions、GitLab CI、Jenkins、Tekton など) に実装します。
7.5. サーバーレスワークフローを作成ときのベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
Serverless Workflow Domain Specific Language (DSL) の原則に基づくベストプラクティスに従って、設計、データの処理、エラーの管理に慎重なアプローチを採用し、効果的なサーバーレスワークフローを作成します。これらの原則は、堅牢なワークフローを構築する場合に役立ちます。
- ワークフロー設計の原則
Serverless Workflow DSL は、ワークフローの記述時に、明確さと使いやすさを重視します。
- 関係者の優先順位
- ワークフローまたは API を開発するときは、作成者 (ワークフロー作成者) のニーズが最優先されるようにしてください。関係者の優先順位は、Authors > Operators > Implementors > Specifications writers の順番です。
- 言語の流暢さと明瞭さ
-
Call、Emit、For、Fork、Raise、Run、Set、Switch、Waitなどの命令形の動詞を使用します。このように、シンプルで普遍的に理解されている用語を使用することで、ワークフローが簡単に読み、理解できるようになります。
-
- 構造と拡張性
- 暗黙のデフォルト動作を使用して冗長性を減らします。
- コンポーネントが再利用できない場合は、定義を自己完結させるようにコンポーネントをインラインで宣言します。
- 外部参照を使用して共有コンポーネントをインポートおよび再利用し、モジュール設計を促進します。
- 厳密な列挙よりも柔軟性を優先して、さまざまなランタイム環境にわたる拡張性と適応性を確保します。
- データフローとランタイム管理
-
効率的なワークフローには、データフローの制御が重要です。タスクはワークフローの基本的な計算単位です。ドメイン固有言語 (DSL) は、ランタイムが実行すべきデフォルトのタスクタイプを複数定義します。これらには、
Do、Listen、Raise、Run、Try、Waitが含まれます。 - セキュリティーとエラー処理
- シークレット
- シークレットは注意して使用してください。機密情報が公開される可能性があるため、呼び出し入力で直接渡すことは避けてください。
- フォールトトレランスとエラー処理
- Serverless Workflow は、障害からの回復力を考慮して設計されています。
- Orchestrator UI 統合のベストプラクティス
ワークフローの結果を Orchestrator UI に効果的に表示し、ワークフローのつながりを容易にするには、
WorkflowResultスキーマに従って出力データを構造化する必要があります。さらに、エラー情報をワークフロー出力の一部として含めることで、UI と後続のワークフローがその出力に応じて処理できるようになります。- ワークフロー出力スキーマ
- 結果の配置
-
後続の処理を目的とした主な出力は、
data.resultプロパティーの下に配置する必要があります。 - スキーマリファレンス
-
出力スキーマファイル (
schemas/workflow-output-schema.json) は、WorkflowResultスキーマを参照する必要があります。 - 出力の定義
ワークフロー定義に
outputsセクションを含めます。このセクションには、人が読めるキーと値のペアが含まれており、このペアが UI に表示されます。ワークフローの構造:
id: my-workflow version: "0.8" specVersion: "0.8" name: My Workflow start: ImmediatelyEnd dataInputSchema: schemas/basic__main-schema.json extensions: - extensionid: workflow-output-schema outputSchema: schemas/workflow-output-schema.json functions: - name: print type: custom operation: sysout - name: successResult type: expression operation: '{ "result": { "message": "Project " + .projectName + " active", "outputs":[] } }' start: "successResult" states: - name: successResult type: operation actions: - name: setOutput functionRef: refName: successResult end: true
第8章 テクニカル付録 リンクのコピーリンクがクリップボードにコピーされました!
以下の付録では、技術情報と、セットアップオプションやクイックテストを理解するのに役立つ RHDH ヘルパースクリプトなどの非実稼働ツールの詳細を説明します。
8.1. RHDH ヘルパースクリプトを使用したコンポーネントのインストール リンクのコピーリンクがクリップボードにコピーされました!
RHDH ヘルパースクリプト plugin-infra.sh を使用して、Orchestrator プラグインで必要な OpenShift Serverless インフラストラクチャーおよび Openshift Serverless Logic インフラストラクチャーを迅速にインストールできます。
実稼働環境で plugin-infra.sh を使用しないでください。
手順
以下の例のように
plugin-infra.shスクリプトをダウンロードします。curl -sSLO https://raw.githubusercontent.com/redhat-developer/rhdh-operator/refs/heads/release-1.7/config/profile/rhdh/plugin-infra/plugin-infra.sh # Specify the Red Hat Developer Hub version in the URL or use mainスクリプトを実行します。
$ ./plugin-infra.sh