Red Hat Developer Hub の Orchestrator


Red Hat Developer Hub 1.7

Orchestrator を使用すると、Red Hat Developer Hub でのクラウド移行、オンボーディング、およびカスタマイズのサーバーレスワークフローが可能になります。

Red Hat Customer Content Services

概要

管理者は、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 プラグインのバージョンと、それに対応する互換性のあるインフラストラクチャーのバージョンを示しています。

Expand

Orchestrator プラグインのバージョン

Red Hat Developer Hub (RHDH) のバージョン

OpenShift のバージョン

OpenShift Serverless Logic (OSL) のバージョン

OpenShift Serverless のバージョン

Orchestrator 1.5

1.5

4.14 - 4.18

OSL 1.35

1.35

Orchestrator 1.6

1.6

4.14 - 4.18

OSL 1.36

1.36

Orchestrator 1.7.1

1.7

4.16 - 4.19

OSL 1.36

1.36

注記

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 によって次の必要な依存関係が自動的にプロビジョニングされます。

  • SonataflowPlatform CR
  • インフラストラクチャーリソース (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

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 を編集または作成できる。

手順

  1. デフォルト設定で 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

  2. 次の例に示すように、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"
  3. 次の例のように、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 フロントエンドおよびバックエンド機能が利用可能であることを確認します。

Red Hat Developer Hub Helm チャートを使用して、Orchestrator で Red Hat Developer Hub をインストールできます。

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 プラグインを有効にする前に完了する必要があります。

手順

  1. Operator のインストール計画を手動で承認します。インストールを承認するには、出力に示された oc patch installplan コマンドを実行する必要があります。
重要

デフォルトでは、Red Hat Developer Hub Helm チャートの Orchestrator Infrastructure は、必要な Serverless Operator を自動的に 表示しません。インストール計画を手動で承認する必要があります。

  1. 管理者として、関連するクラスター全体のリソースをインストールします。

    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-infra Helm チャートは追加のクラスタースコープの OpenShift Serverless および OpenShift Serverless Logic Operator をデプロイするため、これをインストールするには管理者である必要があります。管理者は、OpenShift Serverless および Serverless Logic Operator のインストールプランを手動で承認する必要があります。

  2. 以下の例のように、オーケストレーターを有効にして Backstage チャートをインストールします。

    $ helm install <release_name> openshift-helm-charts/redhat-developer-hub --version 1.7.3 \
      --set orchestrator.enabled=true
  3. (オプション) 次の例に示すように、values.yaml ファイルの global.dynamic.plugins リストに NotificationsSignals プラグインを追加して有効にします。

    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"
  4. (オプション) 次の例に示すように、値を 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
  5. (オプション) 外部データベースを使用している場合は、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 インスタンスを設定する の手順に従います。

検証

  1. Orchestrator プラグインが Red Hat Developer Hub UI に表示されていることを確認します。
  2. サンプルワークフローを作成して実行し、オーケストレーションが正しく機能していることを確認します。

(OpenShift Container Platform) Web コンソールを使用して、Orchestrator とともに Red Hat Developer Hub (RHDH) をインストールできます。この方法は、グラフィカルインターフェイスを好む場合や、Helm CLI を使用せずにクラスター全体のリソースをデプロイする場合に便利です。

前提条件

  • 管理者として OpenShift Container Platform Web コンソールにログインしている。
  • Red Hat Developer Hub Helm チャートリポジトリーにアクセスできる。
  • クラスターはインターネットにアクセスできる、または Helm チャートは非接続環境にミラーリングされている。

手順

  1. OpenShift Container Platform Web コンソールで、Helm Charts に移動し、Red Hat Developer Hub Helm チャートリポジトリーが利用可能であることを確認します。
  2. 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 はデプロイされません。

  3. 正常にデプロイされるまで待ちます。
  4. Pod またはリリースに移動してデプロイメントステータスを監視します。

検証

デプロイメントの完了後:

  • オーケストレーター関連の Pod は、選択した namespace で実行されます。
  • クラスター全体のリソースが存在します。
  • オーケストレーターの Red Hat Developer Hub UI への接続を開始できます。

Helm を使用して Orchestrator プラグインとともに Red Hat Developer Hub (RHDH) をインストールする場合、チャートは SonataFlowPlatform コンポーネントのデフォルトの CPU およびメモリー制限を定義します。

これらの制限は、Pod が割り当てられたリソースを超えないようにクラスターによって適用されます。

  1. デフォルトのリソース制限
Expand
Resourceデフォルト値

CPU 上限

500m

メモリー上限

1Gi

  1. これらの値は、以下のいずれかの方法でオーバーライドできます。

    • values.yaml の使用
    • --set フラグの使用
  2. オーバーライドは、次の例に示すように、values.yaml をデフォルトとします。

    orchestrator:
      enabled: true
      sonataflowPlatform:
      resources:
          limits:
            cpu: "500m"
            memory: "1Gi"
  3. 次の例に示すように、--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.enabledtrue の場合にのみ適用されます。デフォルトでは false に設定されます。

4.4. OpenShift Container Platform への Orchestrator コンポーネントの手動インストール

セットアッププロセスとコンポーネントのバージョンを完全に制御する場合は、手動インストールを使用します。手動のインストール方法は、基礎となるインフラストラクチャーの設定に重点を置いています。

手順

  1. Red Hat OpenShift Serverless ドキュメント の手順に従って、OpenShift Serverless コンポーネントを手動でインストールします。
  2. また、Pod の再起動時にワークフローのコンテキストが失われないように、ワークフローの永続性を設定する必要もあります。この設定は、SonataFlowPlatform または SonataFlow カスタムリソース (CR) を使用して namespace レベルで実行できます。SonataFlowPlatform または SonataFlow カスタムリソースを使用して永続性を設定する詳細な手順は、ワークフローの永続性の管理 を参照してください。
  3. (オプション) 必要に応じて、カスタム PostgreSQL データベースをデプロイします。

第5章 Operator を使用してエアギャップ環境に Orchestrator プラグインをインストールする

Operator を使用すると、完全にまたは部分的な非接続環境において Orchestrator プラグインで Red Hat Developer Hub (RHDH) を設定できます。

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 ツールがインストールされている。

手順

  1. oc-mirrorImageSetConfiguration ファイルを作成します。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.yaml
  2. oc-mirror コマンドを実行して、ImageSetConfiguration.yaml ファイル内のイメージをミラーリングします。以下に例を示します。

    oc-mirror --config=ImageSetConfiguration.yaml file:///path/to/mirror-archive --authfile /path/to/authfile  --v2
    注記

    oc-mirror コマンドは、ミラーアーカイブファイルと必要なクラスターマニフェストを含むローカルワークスペースを生成します。

  3. /path/to/mirror-archive で指定されたディレクトリーを、非接続環境内の踏み台ホストに転送します。
  4. ミラーレジストリーにアクセスできる踏み台ホストから、ディスクディレクトリーのイメージをターゲットレジストリーにミラーリングします。以下に例を示します。

    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)。
  5. 次の例に示すように、プッシュステップ中に生成されたクラスター全体のリソースを適用して、すべてのイメージプルをローカルレジストリーにリダイレクトします。

    cd <workspace folder>/working-dir/cluster-resources/
    oc apply -f .
  6. 以下のいずれかの方法を使用して、オーケストレーター 1.7.1 の Node Package Manager (NPM)パッケージをダウンロードします。

  7. 次の例に示すように、ダウンロードした 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
  8. OperatorHub を使用して OpenShift Serverless Operator と OpenShift Serverless Logic Operator をインストールします。
  9. Backstage カスタムリソース (CR) を作成します。
  10. Operator インストールの Orchestrator プラグインの依存関係 の説明に従って、Orchestrator の Backstage CR を設定します。

    すべてのリソースを作成し、それに応じて Backstage インスタンスを設定します。RHDH でカスタム NPM レジストリーを参照する方法は、カスタム NPM レジストリーの設定 を参照してください。

検証

  • RHDH Pod を再起動し、コンポーネントが適切にデプロイされるまで待ちます。
  • 安定したら、RHDH UI に移動し、Orchestrator UI にアクセスでき、正しく機能していることを確認します。
注記

Orchestrator UI へのアクセスが成功すれば、基盤となるコンポーネントが実行されており、クラスターがプラグインを認識していることがわかります。

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 ツールがインストールされている。

手順

  1. oc-mirrorImageSetConfiguration ファイルを作成します。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.yaml
  2. oc-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 .
  3. 以下のいずれかの方法を使用して、オーケストレーター 1.7.1 の Node Package Manager (NPM)パッケージをダウンロードします。

  4. 次の例に示すように、ダウンロードした 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
  5. OperatorHub を使用して OpenShift Serverless Operator と OpenShift Serverless Logic Operator をインストールします。
  6. Backstage カスタムリソース (CR) を作成します。
  7. 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) を設定できます。

Helm チャートを使用して、完全にエアギャップ化された OpenShift Container Platform 環境に Orchestrator プラグインを備えた Red Hat Developer Hub (RHDH) をインストールできます。

イメージを中間ディスクにミラーリングし、そのディスクからターゲットのローカルレジストリーにミラーリングして、生成されたクラスターリソースを適用できます。

前提条件

  • ローカルレジストリーを使用して非接続環境が設定されている。
  • 制限のあるネットワーク内で利用可能な NPM サーバーに NPM パッケージをプッシュする権限がある。
  • OpenShift Container Platform クラスターのバージョンに対応するバージョンの oc-mirror ツールがインストールされている。

手順

  1. 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.yaml
  2. oc-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 アーカイブとして使用できるようにします。

  3. 次の例に示すように、プッシュステップ中に生成されたクラスター全体のリソースを適用して、すべてのイメージプルをローカルレジストリーにリダイレクトします。

    cd <workspace folder>/working-dir/cluster-resources/
    oc apply -f .
  4. 生成されたミラーアーカイブファイル (例: /path/to/mirror-archive/mirror_000001.tar) を、非接続環境内の踏み台ホストに転送します。
  5. ミラーレジストリーにアクセスできる、非接続環境の踏み台ホストから、アーカイブファイルのイメージをターゲットレジストリーにミラーリングします。以下に例を示します。

    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)。
  6. 以下のいずれかの方法を使用して、オーケストレーター 1.7.1 の Node Package Manager (NPM)パッケージをダウンロードします。

  7. 次の例に示すように、ダウンロードした 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
  8. redhat-developer-hub-orchestrator-infra Helm チャートを適用し、インストールプランを承認します。詳細は、Helm チャートを使用したエアギャップインストールの手順 を参照してください。
  9. RHDH 1.7 Helm チャートを適用します。以下の例のように、バージョン 1.7.3 を含め、Orchestrator プラグインを有効にします。

    orchestrator.enabled=true
  10. RHDH 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 へのアクセスが成功すれば、基盤となるコンポーネントが実行されており、クラスターがプラグインを認識していることがわかります。

Helm チャートを使用して、部分的な OpenShift Container Platform 環境に Orchestrator プラグインを備えた Red Hat Developer Hub (RHDH) をインストールできます。

非接続インストールを使用することで、不正なアクセス、データ転送、または外部ソースとの通信を防止できます。

oc-mirror コマンドを使用すると、アクセス可能なローカルレジストリーにリソースを直接ミラーリングし、生成されたクラスターリソースを適用できます。

前提条件

  • ローカルレジストリーを使用して非接続環境が設定されている。
  • 制限のあるネットワーク内で利用可能な NPM サーバーに NPM パッケージをプッシュする権限がある。
  • OpenShift Container Platform クラスターのバージョンに対応するバージョンの oc-mirror ツールがインストールされている。

手順

  1. oc-mirrorImageSetConfiguration ファイルを作成します。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.1
  2. oc-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 アーカイブとして使用できるようにします。

  3. 生成されたクラスターリソースを非接続クラスターに適用します。以下に例を示します。

    cd <workspace folder>/working-dir/cluster-resources/
    oc apply -f .
  4. 以下のいずれかの方法を使用して、オーケストレーター 1.7.1 の Node Package Manager (NPM)パッケージをダウンロードします。

  5. 次の例に示すように、ダウンロードした 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
  6. redhat-developer-hub-orchestrator-infra Helm チャートを適用し、インストールプランを承認します。詳細は、Helm チャートを使用したエアギャップインストールの手順 を参照してください。
  7. RHDH 1.7 Helm チャートを適用します。以下の例のように、バージョン 1.7.3 を含め、Orchestrator プラグインを有効にします。

    orchestrator.enabled=true
  8. RHDH 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 は、ワークフローマニフェストとプロジェクト構造を生成する重要なツールです。開発を成功させ、すぐにテストするには、次のステップを実行して、新しいサーバーレスワークフローの開発をローカルで開始します。

手順

  1. 次の例に示すように、kn-workflow CLI を使用して Quarkus 構造に準拠した新しいワークフロープロジェクトを作成します。

    kn-workflow quarkus create --name <specify project name, for example ,00_new_project>
  2. 次の例に示すように、ワークフローを編集し、スキーマと特定のファイルを追加して、プロジェクトフォルダーからローカルで実行します。

    kn-workflow quarkus run
  3. 次のイメージをプルする kn-workflow run を使用して、ワークフローをローカルで実行します。

    registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:1.36.0
  4. ワークフローイメージをビルドするために、kn-workflow CLI は次のイメージをプルします。

    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) を使用してワークフローイメージをビルドできます。それを、ローカルでもコンテナー内でも実行できます。このセクションでは、ワークフローイメージをローカルでビルドする方法について説明します。

手順

  1. 次の例に示すように、プロジェクトを複製します。

    git clone git@github.com:rhdhorchestrator/orchestrator-demo.git
    cd orchestrator-demo
  2. スクリプトのヘルプメニューを確認します。

    ./scripts/build.sh --help
  3. イメージパス (-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-workflow CLI を使用してワークフローマニフェストを生成します。
  • podman または docker を使用してワークフローイメージをビルドします。
  • オプション: スクリプトはイメージをイメージレジストリーにプッシュし、kubectl を使用してワークフローをデプロイします。

ヘルプメニューにアクセスして、スクリプトの設定オプションを確認し、使用可能なフラグとその機能を確認できます。

./scripts/build.sh [flags]

スクリプトを実行するには、次のフラグが必須です。

Expand
フラグ説明

-i--image

必須: 完全なイメージパス (例: quay.io/orchestrator/demo:latest)

-w--workflow-directory

ワークフローソースディレクトリー (デフォルトはカレントディレクトリー)

-m--manifests-directory

生成されたマニフェストを保存する場所

--push

イメージをレジストリーにプッシュします

--deploy

ワークフローをデプロイします

-h--help

ヘルプメッセージを表示します

ヒント

このスクリプトは、ビルダーとランタイムイメージのオーバーライド、namespace のターゲット設定、永続フラグもサポートします。

7.2.2. ビルドスクリプトでサポートされる環境変数

build-sh スクリプトは、スクリプト自体を変更せずにワークフロービルドプロセスをカスタマイズするために、次の環境変数をサポートしています。

QUARKUS_EXTENSIONS

QUARKUS_EXTENSIONS 変数は、ワークフローに必要な追加の Quarkus エクステンションを指定します。この変数の形式は、次の例に示す完全修飾拡張 ID のコンマ区切りリストです。

export QUARKUS_EXTENSIONS="io.quarkus:quarkus-smallrye-reactive-messaging-kafka"

ビルド時に Kafka メッセージングサポートまたはその他の統合を追加します。

MAVEN_ARGS_APPEND

MAVEN_ARGS_APPEND 変数は、Maven build コマンドに引数を追加します。この変数の形式は、次の例に示す Maven CLI 引数の文字列です。

export MAVEN_ARGS_APPEND="-DmaxYamlCodePoints=35000000"

ビルド動作を制御します。たとえば、YAML 入力ファイルの最大入力サイズを制御する maxYamlCodePoints パラメーターを 35000000 文字 (UTF-8 では ~33MB) に設定します。

7.2.3. 必要なツール

build-sh スクリプトをローカルで実行してワークフローのライフサイクルを管理するには、次のコマンドラインツールをインストールする必要があります。

Expand
ツール概念的な目的

podman または docker

ワークフローイメージのビルドに必要なコンテナーランタイム。

kubectl

Kubernetes CLI。

yq

YAML プロセッサー。

jq

JSON プロセッサー。

curlgitfindwhich

シェルユーティリティー。

kn-workflow

ワークフローマニフェストを生成するための CLI。

7.2.4. 01_basic ワークフローのビルド

リポジトリーのルートディレクトリーからスクリプトを実行するには、-w フラグを使用してワークフローディレクトリーを指す必要があります。さらに、-m フラグを使用して出力ディレクトリーを指定します。

前提条件

  • タグを使用してターゲットイメージを指定した。

手順

  1. 以下のコマンドを実行します。

    ./scripts/build.sh --image=quay.io/orchestrator/demo-basic:test -w 01_basic/ -m 01_basic/manifests

    このビルドコマンドは、次の 2 つのアーティファクトを生成します。

    • ワークフローイメージと Kubernetes マニフェスト: quay.io/orchestrator/demo-basic:testlatest としてタグ付け。
    • Kubernetes マニフェストの配置場所: 01_basic/manifests/
  2. オプション: --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.yaml

src/main/resources/schemas からの JSON スキーマが含まれます。

注記

GitOps プロファイルを使用する場合、特定の設定リソースのデプロイは必要ありません。

03-sonataflow_basic.yaml

ワークフローを定義する SonataFlow カスタムリソース (CR)。

podTemplate:
  container:
    image: quay.io/orchestrator/demo-basic
    resources: {}
    envFrom:
      - secretRef:
          name: basic-secrets
persistence:
  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

デプロイメントのサービス名を入力します。

外部データベースに接続する必要がある場合は、serviceRefjdbcUrl に置き換えます。ワークフローの永続性の管理 を参照してください。

デフォルトでは、スクリプトは namespace なしですべてのマニフェストを生成します。事前にターゲット namespace がわかっている場合は、--namespace フラグを使用してスクリプトに namespace を指定できます。そうでない場合は、マニフェストをクラスターに適用するときに namespace を指定する必要があります。ワークフローサービスの設定 を参照してください。

7.4. クラスターへのワークフローのデプロイ

イメージがイメージレジストリーにプッシュされ、デプロイメントマニフェストが使用可能になっているため、ワークフローをクラスターにデプロイできます。

前提条件

  • 次のバージョンのコンポーネントがインストールされた OpenShift Container Platform クラスターがあります。

  • サポートサービス を管理する SonataflowPlatform カスタムリソース (CR) が含まれる namespace にワークフローマニフェストを適用する必要があります。

手順

  1. 次の例に示すように、ターゲット namespace を指定して kubectl create コマンドを使用し、Kubernetes マニフェストを適用します。

    kubectl create -n <your_namespace> -f ./01_basic/manifests/.
  2. デプロイ後、次の例に示すようにワークフロー Pod のステータスを監視します。

    kubectl get pods -n <your_namespace> -l app=basic

    Secret または ConfigMap の設定が欠落しているか不完全であるため、Pod の状態が最初は Error になる場合があります。

  3. 次の例に示すように、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 プロパティーが欠落していることを示しています。

  4. ログに 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 を使用して提供された値でプレースホルダーを解決します。

  5. 次の例に示すように、対応する Secret を編集し、適切な base64 エンコード値を指定して、application.properties 内のプレースホルダーを解決する必要があります。

    kubectl edit secrets -n <your_namespace> basic-secrets
  6. ワークフロー Pod を再起動して、OpenShift Serverless Logic v1.36 で Secret の変更を有効にします。

検証

  1. 次の例に示すように、Pod を再度確認して、デプロイメントのステータスを検証します。

    oc get pods -n <your_namespace> -l app=basic

    正常にデプロイされたワークフロー Pod では、次の例のようなステータスが期待されます。

    NAME                    READY   STATUS    RESTARTS   AGE
    basic-f7c6ff455-grkxd   1/1     Running   0          47s
  2. 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 の順番です。
言語の流暢さと明瞭さ
  • CallEmitForForkRaiseRunSetSwitchWait などの命令形の動詞を使用します。このように、シンプルで普遍的に理解されている用語を使用することで、ワークフローが簡単に読み、理解できるようになります。
構造と拡張性
  • 暗黙のデフォルト動作を使用して冗長性を減らします。
  • コンポーネントが再利用できない場合は、定義を自己完結させるようにコンポーネントをインラインで宣言します。
  • 外部参照を使用して共有コンポーネントをインポートおよび再利用し、モジュール設計を促進します。
  • 厳密な列挙よりも柔軟性を優先して、さまざまなランタイム環境にわたる拡張性と適応性を確保します。
データフローとランタイム管理
効率的なワークフローには、データフローの制御が重要です。タスクはワークフローの基本的な計算単位です。ドメイン固有言語 (DSL) は、ランタイムが実行すべきデフォルトのタスクタイプを複数定義します。これらには、DoListenRaiseRunTryWait が含まれます。
セキュリティーとエラー処理
シークレット
シークレットは注意して使用してください。機密情報が公開される可能性があるため、呼び出し入力で直接渡すことは避けてください。
フォールトトレランスとエラー処理
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 を使用しないでください。

手順

  1. 以下の例のように 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
  2. スクリプトを実行します。

    $ ./plugin-infra.sh

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る