DXC Data&AIPublicationへの投稿
🔥

OpenShift上でLangflowをデプロイしてみた-HelmとYAMLを使った最小構成の構築

long
に公開
OpenShift
Langflow
tech

1. はじめに

本記事は、Langflow を OpenShift 上にデプロイするための実践的なガイドです。
OpenShift 環境上で、Langflow を次の 2 つの方法でデプロイする手順について解説します。

  • Helm を用いた迅速なデプロイ
  • Helm が生成したマニフェスト（YAML）を参考にした、YAML を手動で作成するデプロイ

本記事は、読者が「簡単に Langflow をデプロイできる」だけでなく、「なぜその設定が必要なのか」「OpenShift 固有の制約にどのように対応するのか」まで含めて理解を深めることを目指しています。

2. 対象と目的

2.1 対象読者

本記事は、次のような方を読者として想定しています。

  • Langflow を OpenShift 上で動かしたい方
  • Pod / Deployment / Service など、基本的な Kubernetes リソースの概念と openshift 特有の制限について知りたい方
  • Helm が利用できる環境・利用できない環境の両方を想定しておきたい方
  • 既存の Helm Chart を「そのまま使う」のではなく、自分の環境に合わせて読み替え・カスタマイズしたい方

2.2 この記事で目指すゴール

本記事を通じて、読者が次のことができるようになることを目標とします。

  • Helm を用いて Langflow を OpenShift 上にデプロイし、動作を確認できること
  • helm get manifest で取得したマニフェスト（YAML）の構造を読み解けること
  • Backend / Frontend の各リソース（StatefulSet / Deployment / Service / Route）の YAML を作成し、デプロイできること
  • OpenShift 固有の制約（Security Context Constraints（SCC）/ UID / securityContext / Route termination など）を踏まえた設定に書き換えられること

2.3 スコープ

本記事で扱うスコープは、次のとおりです。

  • Langflow の最小構成（Backend + Frontend）を OpenShift 上で動かすこと
  • 1 Pod の Backend（StatefulSet）と、1 Pod の Frontend（Deployment）によるシンプルな構成
  • SQLite を前提としたローカルデータベース（Database, DB）の利用

一方で、次のトピックはスコープ外とします。

  • 外部データベース（PostgreSQL など）との連携・マイグレーション設計
  • 複雑なネットワーク構成（Service Mesh、NetworkPolicy の詳細など）
  • 他サービスとの連携方法

3. 基本概念

本章では、この後の手順を理解するために必要となる、Langflow と OpenShift の基本概念を整理します。

3.1 Langflow の概要

Langflow は、AI アプリケーションを構築するための、Python ベースの高い拡張性を備えたオープンソースフレームワークです。
Langflow を使用することで、ノーコード／ローコードで視覚的に AI ワークフローを作成できます。
LLM やデータベースを組み合わせた AI アプリケーションを、素早く構築・実行できるのが特徴です。

Langflow は、大きく分けて次の 2 つのコンポーネントから構成されます。

  • Backend（API / フロー実行）
    • フローの実行や大規模言語モデル（Large Language Model, LLM）の呼び出しを担当します。
    • データベース（デフォルトでは SQLite）へのアクセスを行います。
    • デフォルトの待ち受けポートは 7860 です。
  • Frontend（GUI）
    • ブラウザから操作するための Web GUI を提供します。
    • Backend の API エンドポイントに HTTP でアクセスします。
    • デフォルトの待ち受けポートは 8080 です。

3.2 Kubernetes / OpenShift に関する基本概念

Langflow のデプロイに関わる主要な基本概念を、簡単に整理します。

  • StatefulSet
    • 固定された Pod 名（例：langflow-0）で起動するコントローラーです。
    • ログの追跡や、将来的な永続ボリューム（PersistentVolumeClaim）利用と相性が良いため、Langflow の Backend に使われています。
  • Deployment
    • Stateless なアプリケーションを管理するためのコントローラーです。
    • Replica 数の増減やローリングアップデートなどに適しており、Frontend 用に採用します。
  • Service
    • 複数の Pod を 1 つの仮想エンドポイント（DNS 名）としてまとめるリソースです。
    • spec.selector に一致する Pod にトラフィックを振り分けます。
    • Backend / Frontend で selector をきちんと分けることで、誤った Pod にトラフィックが流れないようにします。
  • Route（OpenShift 固有）
    • クラスター外から HTTP(S) でアクセスするためのエントリポイントです。
    • termination の設定により、http / edge / reencrypt などのモードを選択できます。
    • 本記事の最小構成では、シンプルな HTTP を前提とします。

3.3 OpenShift 固有の制約（Security Context Constraints（SCC）/ UID / securityContext）

OpenShift には、Security Context Constraints（SCC）と呼ばれる仕組みがあり、コンテナが使用できる UID（ユーザー ID）や権限が制限されています。

多くの Helm Chart では、次のような securityContext がデフォルトで定義されています。

  • runAsUser: 1000 など、固定 UID を指定する設定

このような設定は、OpenShift のデフォルト SCC では許可されておらず、そのまま適用すると「許可されていない UID」として Pod が起動できない場合があります。

本記事では、こうした問題を避けるために次の方針を取ります。

  • YAML を手動で作成する際は、明示的な securityContext（runAsUser など）を記述しないこと
  • OpenShift 側で自動的に割り当てられる UID を前提とすること
  • 書き込みが必要なパス（SQLite の DB ファイル、ログディレクトリなど）は、/tmp や emptyDir ボリュームに配置すること

この方針により、OpenShift 固有の UID 制約と衝突しない形で Langflow を動作させることができます。
後続の章では、この構成を実際の YAML とコマンドに落とし込みながら、Helm デプロイと YAML によるデプロイの両方を段階的に確認していきます。

4. 事前準備

Langflow を OpenShift 上にデプロイする前に、事前に確認しておくべきポイントがあります。

4.1 使用環境の確認

本記事に記載の手順は、次の環境で動作確認を行っています。

OpenShift

  • Client Version：4.18.0-202509100344.p2.g4fcb2d0.assembly.stream.el9
  • Server Version：4.18.27
  • Kubernetes Version：v1.31.13

Helm

  • Version：v3.17.1+64.el9
  • Go Version：go1.24.4

Langflow

  • コンテナイメージ：langflowai/langflow:latest
  • バージョン：1.6.8（Pod 内で langflow --version により確認）

4.2 OpenShift CLI（oc）のインストールとログイン確認

OpenShift の CLI である oc コマンドが利用可能であることを確認します。
次のコマンドで CLI とログイン状態をチェックできます。

  • oc version
  • oc whoami

oc version がバージョン情報を返せば、CLI は正しくインストールされています。
oc whoami がユーザー名を返せば、クラスターにログイン済みです。

どちらかが正常に動作していない場合、後続のデプロイ手順を進めることはできません。
先に oc のセットアップとログイン設定を完了させてください。

4.3 Helm CLI のインストール確認

本記事では Helm を使用するため、事前に helm コマンドが利用可能であることを確認します。

  • helm version

バージョン情報が表示されれば問題ありません。
インストールされていない場合は、OpenShift コンソールなどのガイドに従ってセットアップしてください。

4.4 Namespace（Project）の確認

本記事の Helm 手順では --create-namespace オプションを使用します。
このオプションにより、Helm が Namespace（OpenShift の Project）を自動作成します。

そのため、事前に Namespace を手動で作成する必要はありません。
ただし、現在どの Namespace（Project）を操作対象としているかは確認しておくことを推奨します。

  • oc project

意図しない Namespace にリソースを作成すると、原因の切り分けが難しくなります。
現在の Project を把握しておくことで、こうした問題を避けることができます。

5. デプロイ手順

ここから実際のデプロイ手順に入ります。
本章では、次の流れで進めます。

  1. まず 5.3 の Helm 手順で Langflow をデプロイし、動作する状態を一度作る。
  2. 次に、helm get manifest で生成されたマニフェスト（YAML）を確認する。
  3. その内容を踏まえたうえで、5.4 以降で YAML を手動で作成するデプロイに取り組む。

5.1 デプロイ方法

本記事で扱うデプロイ手法は、次の 2 つです。

  • Helm を用いた最短デプロイ
  • Helm が生成したマニフェストを参考にして YAML を作成するデプロイ

Helm によるデプロイは、少ないコマンドで Langflow を簡単にデプロイすることができるのがメリットです。
一方で、Helm のマニフェストを読み解きながら YAML を作成することで、OpenShift 上で Langflow をどのようなリソース構成で動かしているかを詳細に理解できます。
両方の方法を理解しておくことで、Helm が利用できる環境・利用できない環境のどちらにも対応しやすくなります。

5.2 全体構成イメージ

ここで、本記事で構築する全体構成を文章で整理しておきます。

  • ユーザーのブラウザから、Langflow Frontend 用の Route に HTTP でアクセスします。
  • Route から Frontend 用 Service 経由で、Frontend Pod にリクエストが転送されます。
  • Frontend Pod から、Backend 用 Service を通じて Backend Pod の API にアクセスします。
  • Backend Pod は、コンテナ内の SQLite（ローカルファイル）や LLM にアクセスし、フローを実行します。

5.3 Helm を使った Langflow のデプロイ

ここでは、Helm Chart を利用して Langflow を最短手順で OpenShift にデプロイする方法を紹介します。
各コマンドの役割についても簡単に説明します。

5.3.1 Helm リポジトリの追加

まず、Langflow の Helm Chart が置かれているリポジトリを Helm に登録します。

helm repo add langflow https://langflow-ai.github.io/langflow-helm-charts

このコマンドで、Helm に「Langflow の Chart はここにある」と URL を教えます。
GitHub Pages 上にある Chart を、ローカル環境から参照できるようにする操作です。

続いて、以下のコマンドでリポジトリ情報（Chart の一覧）を最新状態に更新します。

helm repo update

5.3.2 Langflow のインストール

次のコマンドで Langflow（IDE 版）を OpenShift にインストールします。

helm install langflow-ide langflow/langflow-ide -n langflow --create-namespace

このコマンドで起こることは、次のとおりです。

  • langflow-ide というリリース名でデプロイされる。
  • langflow/langflow-ide（Helm Chart 名）を使用する。
  • -n langflow → langflow という Namespace にデプロイする。
  • --create-namespace → Namespace がなければ自動作成する。

5.3.3 Pod / Service の状態を確認

まず、次のコマンドで Pod の一覧を取得します。

oc get pods -n langflow

実行結果の例：

NAME                                      READY   STATUS    RESTARTS   AGE
langflow-service-0                        1/1     Running   1          44m
langflow-service-frontend-9d47787dc-zzdnv 1/1     Running   0          44m

両方とも STATUS が Running であれば、正常に動作しています。

次に、Service の一覧を取得します。

oc get svc -n langflow

実行結果の例：

NAME                     TYPE        CLUSTER-IP       PORT(S)
langflow-service         ClusterIP   172.30.xxx.xxx   8080/TCP
langflow-service-backend ClusterIP   172.30.xxx.xxx   7860/TCP
  • langflow-service → Frontend 用の Service（ポート 8080）
  • langflow-service-backend → Backend 用の Service（ポート 7860）

Frontend と Backend の接続は、この Service 経由で行われます。

5.3.4 Route の作成

OpenShift では、外部アクセスに Route を利用します。
まず、以下のコマンドで Frontend（GUI）を公開します。

oc expose svc/langflow-service -n langflow

次に、Backend 用の Route を公開します。

oc expose svc/langflow-service-backend -n langflow

5.3.5 Route の確認

次のコマンドで、作成された Route を確認します。

oc get route -n langflow

実行結果の例（実際の URL はマスク）：

NAME                     HOST/PORT                     SERVICES                   PORT
langflow-service         <frontend-route>.example.com  langflow-service           http
langflow-service-backend <backend-route>.example.com   langflow-service-backend   http
  • HOST/PORT が、ブラウザからアクセスする URL になります。
  • Frontend の URL にブラウザからアクセスすれば、GUI が表示されます。
    例：http://<frontend-route>.example.com

Route の termination を特に設定していない場合、デフォルトでは HTTP で公開されます。
この状態で https:// でアクセスすると、接続できないことがあります。

  • oc get route の出力で PORT が http の場合は、http://<route-host> でアクセスする必要があります。

5.3.6 Helm が生成したマニフェスト（YAML）を取得する

後述の YAML によるデプロイ手順を理解するために、Helm が実際に生成した YAML を確認しておくと便利です。

次のコマンドで、Helm が生成した YAML を取得します。

helm get manifest langflow-ide -n langflow > langflow-working.yaml

このコマンドで、Helm が内部でテンプレート展開した YAML を一括取得できます。

5.4 YAML を用いた Langflow のデプロイ

この節では、Helm が生成したマニフェストを参考にしながら、Langflow を YAML を手動で作成してデプロイする方法を説明します。

5.4.1 Helm が生成した YAML の確認

5.3.6 で取得した langflow-working.yaml をもとに、主要なリソース構成を確認します。
このファイルには、次のようなリソースが含まれています。

  • Backend 用 StatefulSet
  • Frontend 用 Deployment
  • Backend / Frontend 用 Service
  • ConfigMap やボリューム設定など

YAML を読む際は、主に次の点を意識しておくと整理しやすくなります。

  1. StatefulSet / Deployment の役割
    Backend は StatefulSet として定義されています。
    Pod 名が固定されるため、ログ確認や将来の永続ボリューム利用と相性が良い構成です。
    Frontend は Deployment として定義されています。
    Stateless な Web フロントエンドとして一般的な構成です。

  2. コンテナ仕様（containers セクション）
    spec.template.spec.containers の中では、以下の項目を中心に確認します。

    • image：使用するコンテナイメージ
    • ports：アプリケーションが待ち受けるポート
    • env：ポート番号・DB・設定パスなどの環境変数
    • volumeMounts：書き込み先パスのマウント
    • livenessProbe / readinessProbe：ヘルスチェック

    Backend では、ログや SQLite など書き込みが必要な処理があるため、/tmp や emptyDir を使っている点が重要になります。

  3. securityContext の扱い
    Helm のマニフェストに runAsUser: 1000 などの securityContext が含まれている場合、OpenShift の SCC 設定によっては「許可されていない UID」としてエラーになることがあります。
    そのため、本記事で作成する YAML では securityContext は明示的に指定せず、OpenShift に UID を自動割り当てさせる構成とします。

  4. Service と selector の確認
    Service の spec.selector が、Backend と Frontend をきちんと分けているかも重要です。

    例：

    selector:
  app: langflow
  component: backend

    このように component: backend を含めることで、後から app: langflow, component: frontend の Pod を追加しても、Endpoints が混ざらないようにできます。

以上を踏まえたうえで、以降では Backend / Frontend を YAML で構成していきます。

5.4.2 プロジェクトの作成

まず、検証用のプロジェクト（Namespace）を作成します。

oc new-project yaml-test

以降は、この yaml-test プロジェクトを前提に説明します。

5.4.3 Backend 用 StatefulSet

以下は、実際に OpenShift 上で動作確認できた最小構成の例です。

langflow-backend.yaml：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: langflow
  labels:
    app: langflow
    component: backend
spec:
  serviceName: langflow
  replicas: 1
  selector:
    matchLabels:
      app: langflow
      component: backend
  template:
    metadata:
      labels:
        app: langflow
        component: backend
    spec:
      containers:
        - name: langflow
          image: langflowai/langflow:latest
          ports:
            - containerPort: 7860
          env:
            - name: LANGFLOW_BACKEND_ONLY
              value: "true"
            - name: LANGFLOW_PORT
              value: "7860"
            - name: LANGFLOW_DATABASE_URL
              value: "sqlite:////data/langflow.db"
            - name: LANGFLOW_CONFIG_DIR
              value: "/tmp/langflow"
            - name: LANGFLOW_ALEMBIC_LOG_FILE
              value: "/tmp/alembic.log"
            - name: HOME
              value: "/tmp"
            - name: MEM0_DIR
              value: "/tmp/.mem0"
            - name: LANGFLOW_UPDATE_STARTER_PROJECTS
              value: "false"
          volumeMounts:
            - name: data
              mountPath: /data
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: data
          emptyDir: {}
        - name: tmp
          emptyDir: {}

主なポイントは次のとおりです。

  • metadata.labels と spec.template.metadata.labels に
    app: langflow, component: backend を付与しています（後述の Service の selector で利用します）。
  • 書き込みが発生するパス（Alembic ログ、mem0 ディレクトリなど）は /tmp または emptyDir に向けています。
  • securityContext は指定していません。OpenShift の SCC に合わせて UID を自動割り当てさせる想定です。

5.4.4 Backend 用 Service

Backend をクラスター内から名前解決できるように、Service を作成します。

langflow-backend-service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: langflow
  labels:
    app: langflow
    component: backend
spec:
  selector:
    app: langflow
    component: backend
  ports:
    - port: 80
      targetPort: 7860
  • selector は app: langflow だけでなく component: backend も指定しています。
    これにより、Frontend の Pod が追加されても Backend 用 Service の Endpoints に混ざらないようにできます。
  • port: 80 は Service の仮想ポート、targetPort: 7860 はコンテナ側の実ポートです。

5.4.5 Backend リソースの適用と起動確認

作成した YAML を適用します。

oc apply -f langflow-backend.yaml -n yaml-test
oc apply -f langflow-backend-service.yaml -n yaml-test

Pod の状態を確認します。

oc get pods -n yaml-test

実行結果例：

NAME        READY   STATUS    RESTARTS   AGE
langflow-0  1/1     Running   0          5m

langflow-0 が Running になっていれば、Backend は正常に起動しています。

5.4.6 Frontend 用 Deployment

Backend が動作していることを確認できたら、次に GUI を提供する Frontend をデプロイします。

langflow-frontend.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: langflow-frontend
  labels:
    app: langflow
    component: frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: langflow
      component: frontend
  template:
    metadata:
      labels:
        app: langflow
        component: frontend
    spec:
      containers:
        - name: langflow-frontend
          image: langflowai/langflow-frontend:latest
          ports:
            - containerPort: 8080
          env:
            - name: BACKEND_URL
              value: "http://langflow:80"
            - name: FRONTEND_PORT
              value: "8080"
  • Backend とラベルを分けるために、component: frontend を付けています。
  • BACKEND_URL に http://langflow:80 を指定しています。
    • langflow は Backend Service の metadata.name
    • 80 は Backend Service の spec.ports[0].port です。

5.4.7 Frontend 用 Service

ブラウザからアクセスしやすくするため、Frontend 用 Service を作成します。

langflow-frontend-service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: langflow-frontend
  labels:
    app: langflow
    component: frontend
spec:
  selector:
    app: langflow
    component: frontend
  ports:
    - port: 80
      targetPort: 8080

これにより、クラスター内からは http://langflow-frontend:80 で Frontend にアクセスできるようになります。
後ほど作成する Route も、この Service を公開対象として利用します。

5.4.8 Frontend リソースの適用と起動確認

作成した YAML を適用します。

oc apply -f langflow-frontend.yaml -n yaml-test
oc apply -f langflow-frontend-service.yaml -n yaml-test

Pod の状態を確認します。

oc get pods -n yaml-test

実行結果例：

NAME                               READY   STATUS    RESTARTS   AGE
langflow-0                         1/1     Running   0          10m
langflow-frontend-5bf8d6c95b-rxxm5 1/1     Running   0          2m

Backend / Frontend 両方の Pod が Running であれば、アプリケーションは正常に起動しています。

5.4.9 Route の作成と動作確認

最後に、クラスター外からアクセスするための Route を作成します。
5.3 での Helm を使ったデプロイと同様に、Route を作成します。

oc expose svc/langflow -n yaml-test
oc expose svc/langflow-frontend -n yaml-test

作成された Route は、次のコマンドで確認できます。

oc get route -n yaml-test

実行結果例（URL はマスク）：

NAME              HOST/PORT                       SERVICES          PORT  TERMINATION
langflow          <backend-route>.example.com     langflow          http  edge
langflow-frontend <frontend-route>.example.com    langflow-frontend http  edge
  • HOST/PORT が、ブラウザからアクセスする URL になります。
  • langflow-frontend の URL にブラウザからアクセスすれば、GUI が表示されます。

TERMINATION の値（http / edge など）は、環境や設定によって異なる場合があります。
PORT が http の場合は、http://<route-host> でアクセスする必要があります。

6. よくある問題と解決策

ここでは、OpenShift 上で Langflow をデプロイする際によくある問題と、その原因・解決策について代表的なものを紹介します。

  • Pod が起動しない（SCC / UID 関連）
  • Frontend から Backend / Route に接続できない

6.1 Pod が起動しない（SCC / UID 関連）

【問題】

  • Pod の STATUS がいつまでも Pending / CrashLoopBackOff のまま変わらない。
  • oc describe pod / oc describe statefulset で、UID や fsGroup に関するエラーが表示される。

例：

  • .spec.securityContext.fsGroup: Invalid value: 1000: 1000 is not an allowed group
  • .containers[0].runAsUser: Invalid value: 1000: must be in the ranges: [1000870000, 1000879999]

【原因】

OpenShift の Security Context Constraints（SCC）によって使用可能な UID / GID が制限されているにもかかわらず、securityContext で許可されていない UID（例：runAsUser: 1000, fsGroup: 1000）を固定指定しているため、Pod の作成が拒否されています。

【解決策】

  1. 対象リソースの securityContext を確認します。

    • Backend 用 StatefulSet / Frontend 用 Deployment の
      • spec.securityContext
      • spec.template.spec.containers[].securityContext
        を確認します。

  2. 次のような項目を削除します。

    • runAsUser / runAsGroup / fsGroup など UID / GID を固定する設定
    • OpenShift の restricted 系 SCC と衝突する可能性が高い securityContext 一式

    例：

    spec:
  securityContext:
    fsGroup: 1000
    runAsUser: 1000

  3. 修正した YAML を再適用します。

    oc apply -f langflow-backend.yaml -n <namespace>
oc apply -f langflow-frontend.yaml -n <namespace>

    そのうえで、次のコマンドで Pod が Running になることを確認します。

    oc get pods -n <namespace>

6.2 Frontend から Backend / Route に接続できない

【問題】

  • Frontend の Pod は Running だが、ブラウザで Langflow の画面を開くとエラーになる。
  • /flows 画面が表示されない、あるいは HTTP 499 / 5xx が返ってくる。
  • port-forward や Backend Pod への直接 curl では /health が取得できるが、Service や Route 経由では失敗する。

【原因】

  1. Backend Service の selector が広すぎる
    spec.selector が app: langflow のみとなっており、Frontend Pod まで Endpoints に含まれている。

    • oc get endpoints <service> で、Backend Pod 数より多くの IP が登録されている。

  2. Route のプロトコルとアクセス方法が一致していない
    Route の PORT が http にもかかわらず、ブラウザから https:// でアクセスしている。

【解決策】

  1. ラベルと Service selector の見直し

    Backend / Frontend でラベルを分け、Backend 用 Service の selector を適切に絞り込みます。

    Backend 用 StatefulSet / Pod：

    labels:
  app: langflow
  component: backend

    Frontend 用 Deployment / Pod：

    labels:
  app: langflow
  component: frontend

    Backend 用 Service：

    apiVersion: v1
kind: Service
metadata:
  name: langflow
spec:
  selector:
    app: langflow
    component: backend
  ports:
    - port: 80
      targetPort: 7860

    この構成にすることで、Backend Service の Endpoints には Backend Pod のみが登録されるようになります。
    必要に応じて、次のコマンドで確認します。

    oc get endpoints langflow -n <namespace>
oc get pods -o wide -n <namespace>

  2. Route の設定とアクセスプロトコルの確認

    Route 経由でのみアクセスできない場合は、最初に Route の設定を確認します。

    oc get route -n <namespace>

    PORT が http または数値ポートで、TERMINATION が空もしくは edge の場合、基本的には http://<route-host> でアクセスする必要があります。

    検証環境では、https:// でアクセスしてしまっていたことが原因で、Route 自体は正しく作成されているにもかかわらず「Application is not available」と表示されるケースがありました。
    まず http:// でのアクセスを試し、それでも問題が解消しない場合は Service のポート定義との整合性を確認します。

6.3 トラブルシューティングでよく使う oc コマンド

最後に、トラブルシューティングの際によく利用するコマンドを整理します。

  • oc describe pod <pod> -n <namespace>
    Pod のイベントや、SCC / UID に関するエラー内容を確認する際に使用します。

  • oc logs <pod> -n <namespace>
    アプリケーション側で発生している PermissionError や RuntimeError などを確認します。

  • oc get endpoints <service> -n <namespace>
    Service がどの Pod の IP を Endpoints として認識しているかを確認します。
    selector の設定ミスが疑われる場合に有効です。

  • oc exec -it <pod> -n <namespace> -- sh
    Pod 内から curl などを用いて、Service 名や Route に対して直接接続テストを行う際に使用します。

  • oc get pods -o wide -n <namespace>
    各 Pod の IP アドレスや配置ノードを確認し、Endpoints の情報と突き合わせる際に利用します。

7. まとめ

この記事では、Langflow を OpenShift 上でデプロイするために、次の内容を一通り確認してきました。

  • Helm を使ってシンプルに Langflow をデプロイする方法
  • Helm が生成するマニフェスト（YAML）の読み解き方
  • Backend / Frontend の YAML を作成して Langflow をデプロイする方法
  • Security Context Constraints（SCC）/ UID / Route など、OpenShift 固有の制約への対応
  • よくある問題の例と、それらを調査する際によく使う oc コマンド

これで、Helm が使える環境でも、Helm が使えない環境でも Langflow をデプロイできるようになります。
また、Langflow をデプロイできるだけでなく、OpenShift 上でアプリケーションをデプロイするための基礎知識も身につくはずです。

DXC Data&AI
DXC Data&AIPublication

Discussion