はじめに

これは Kompira Enterprise 2.0 (KE2.0) の管理者マニュアルです。

システム管理以外の Kompira Enterprise の一般的な使用方法などについては、システム構築後に Kompira Enterprise のオンラインマニュアルを参照してください。

仕様情報や活用事例については、Kompiraシリーズ製品情報サイト を参照してください。

最終更新日: 2024/12/06

改版履歴

2024/12/03 (2.0.2)

変更

• 保守ガイド/シングル構成の保守を更新しました。
• 保守ガイド/外部DBシングル構成の保守を追加しました。
• 管理ガイド/ログ管理/コンテナログ管理を更新しました。
• 管理ガイド/ログ管理/サービスログ管理を追加しました。
• トラブルシュートガイドを追加しました。

2024/10/16 (2.0.2)

コンテナイメージ

• KOMPIRA_IMAGE_TAG=2.0.2 に対応しました。

変更

• 暗号化秘密鍵の手順を更新しました。
• システム管理/システムステータスの確認を追加しました。
• クラスタ構成のアップデート手順を更新しました。
• クラスタ構成の保守ガイドを追加しました。
• ke2-docker に合わせて環境変数の説明を更新しました。
• 環境変数によるロギング設定について追記しました。
• pip install するときの kompira-sendevt のバージョン指定を更新しました。
• docker-compose-plugin について v2.24.6 以上が必要であることをシステム要件に追記しました。

2024/08/01 (2.0.0)

• KE2.0.0 リリース

用語

本マニュアルで登場する用語について説明します。

ライセンス

Kompira Enterprise を利用される場合は、必ず Kompira Enterprise ライセンス利用規約 をよくお読みください。

Kompira Enterprise を継続して利用される場合はライセンス登録が必要になります。詳しくは license@kompira.jp までご連絡ください。

システム概要

KE2.0 のシステム概要について示します。

システム要件

KE2.0 のシステム要件について記載します。

ホストのシステム要件

• 必要なスペックは Kompira 上で動作するジョブフロー規模、自動化の処理要件によって異なります。
• 記載要件は最低レベルで記載しております。お客様の運用環境によっては異なる場合がございますのでご了承ください。

動作確認済みホストOS一覧

• Rocky Linux 8.10 (x86_64)
• Rocky Linux 9.4 (x86_64)

コンテナ構成

KE2.0 のコンテナ構成を以下に示します。

コンテナ一覧

※ 実際のコンテナ名は構成によって ke2- とプレフィックスが付くなど多少異なります。

コンテナレジストリ

KE2.0 のコンテナイメージ自体は、Azure Container Registry 上で以下の名称で公開されます。

fixpoint.azurecr.io/kompira-enterprise

イメージにはバージョン（2.0.0 など）がタグ付けされます。また、最新バージョンのイメージには latest というタグが別名として付与されます。

ネットワーク構成

公開ポート一覧

Kompira システムをセットアップしたサーバ上では、以下のポートがデフォルトで外部から接続可能になります。

コンテナ間の連携に用いているポートは外部公開にならないため、ここでは省略しています。

ke2-docker

KE2.0 のデプロイに必要になるファイル一式をまとめた ke2-docker パッケージについて示します。

ke2-docker パッケージ

KE2.0 をデプロイするためには docker compose ファイルや各種設定ファイルなどが必要になります。 ke2-docker パッケージは、こうしたファイルのサンプルを含んでおり以下で公開しています。

https://github.com/fixpoint/ke2-docker

デプロイするサーバー上に上記リポジトリを git clone するか、あるいは ZIP ダウンロードして展開することで、KE 2.0 のデプロイができるようになります。

ke2-docker の内容

ke2-docker パッケージには以下のものが含まれます。

README.md
configs/             # 設定ファイル
ke2/                 # KE2 各構成ファイル
  single/            # シングル構成用のファイル一式
    basic/           #  - 標準シングル構成
    extdb/           #  - 外部DBシングル構成
  cluster/           # クラスタ構成用のファイル一式
    swarm/           #  - Swarmクラスタ構成
  cloud/             # クラウド構成用のファイル一式
    azureci/         #  - AzureCIクラウド構成
scripts/             # スクリプトファイル
ssl/                 # SSL 証明書配置ディレクトリ

本マニュアルでは、この ke2-docker パッケージを利用した手順を説明します。 ke2-docker パッケージは KE 自体のバージョンとは独立してバージョン管理されます。基本的には最新版をご利用ください。

構築ガイド

ここでは KE2.0 の標準的なシステム構成についての概要および構築手順を示します。

標準構成一覧

Docker Engine のインストール

いずれの構成でも Docker を用いますので、クラウド以外ではサーバに Docker Engine のインストールが必要になります。 以下の公式サイトを参考に構築環境に合わせて Docker Engine をインストールしてください。

• https://docs.docker.com/engine/install/

参考までに RHEL 環境では以下のような手順になります。

$ sudo yum install -y yum-utils
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
$ sudo yum install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
$ sudo systemctl enable --now docker

Proxy の設定

プロキシ環境化における Docker イメージのプル

Docker daemon がイメージを pull する際に、以下に示す方法によってプロキシの設定が必要となります。 (/etc/systemd/system/docker.service.d/http-proxy.conf に HTTP_PROXY, HTTPS_PROXYの設定を行う)

https://docs.docker.jp/config/daemon/systemd.html#systemd-httphttps-proxy

設定が正しくなされているかどうかは、docker info コマンドで確認することができる。

さらに、DOCKER_BUILDKIT が有効だとビルドに失敗するため、以下のようにDOCKER_BUILDKIT環境変数に 0 をセットしてビルドする。

$ DOCKER_BUILDKIT=0 docker compose -f <Docker compose ファイル> build

プロキシ環境下におけるDocker クライアントの設定

Kompira 実行時にコンテナ内からプロキシ接続する場合、以下にあるように Docker クライアントの設定を行う必要がある。

https://docs.docker.jp/network/proxy.html#proxy-configure-the-docker-client

オンプレシングル構成

オンプレシングル構成では簡単に KE2.0 システムを構築することが出来ます。

本ガイドでは以下の構成について、その構築手順を紹介します。

• 標準シングル構成
• 外部DBシングル構成

標準シングル構成 (ke2/single/basic)

もっともシンプルな標準シングル構成について説明します。

以下のような場合には、この構成が便利です。

• とにかく簡単に KE2.0 環境をセットアップしたい。
• 処理負荷の分散などよりも、単純なシステム構成で使いたい。

構成図

本構成では、1 つの Docker ホストに全てのコンテナを配置して動作させます。

特徴

本構成には、以下の通り構成上の特徴があります。

• nginx, kompira, kengine, jobmngrd の各コンテナは、docker ボリューム kompira_var をコンテナ内の /var/opt/kompira ディレクトリに共有でバインドします。静的ファイルや Python ライブラリなどを共有します。
• postgresql コンテナは、docker ボリューム kompira_db をコンテナ内の /var/lib/postgresql/data ディレクトリにバインドします。postgresql コンテナを新たに作成しても、当該ボリュームが残されていればデータを引き継ぐことができます。

セットアップの流れ

本構成のセットアップの流れは以下のようになります。詳細については各ページを参照してください。

• サーバの準備
• KE2 のセットアップ

サーバーの準備

オンプレ環境に KE2.0 を動作させるサーバーを準備します。

サーバーの準備

システム要件 を参考に、Linux など対応するサーバーを1台用意してください。 以後の手順ではサーバーに対する root 権限が必要になりますのでご注意ください。

Docker Engine の準備

https://docs.docker.com/engine/install/ を参考に環境に合わせて Docker Engine をインストールして、Docker を起動してください。たとえば RHEL 環境では以下のような手順になります。

$ sudo yum install -y yum-utils
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
$ sudo yum install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
$ sudo systemctl enable --now docker

KE2 のセットアップ

標準シングル構成 (ke2/single/basic) の基本的なセットアップ手順を説明します。

ke2-docker パッケージの準備

KE2.0 の構築に必要な docker compose ファイルなどを含む ke2-docker パッケージを用意してください。 ke2-docker リポジトリ から、以下のいずれかの方法でサーバー上に展開してください。

• 以下のコマンドを実行して git リポジトリをクローンしてください。(git コマンドが必要です)
  • $ git clone https://github.com/fixpoint/ke2-docker.git
• ZIP ファイルとしてダウンロードし、用意したサーバー上に配置して展開してください。(unzip コマンドが必要です)

ke2-docker パッケージを展開できたら、標準シングル構成用の docker-compose.yml ファイルを含むディレクトリに移動します。

$ cd ke2/single/basic

コンテナイメージの取得

以下のコマンドを実行してコンテナイメージを取得してください。

$ docker compose pull

※ インターネットに接続できない環境の場合は「オフライン環境での構築」を参考にしてください。

SSL 証明書の生成

以下のコマンドを実行して自己署名 SSL 証明書を生成してください。

$ ../../../scripts/create-cert.sh

コンテナの作成と開始

以下のコマンドを実行してコンテナを作成および開始を行なってください。

$ docker compose up -d

セットアップ後の動作確認

セットアップが完了したら、KE2.0 システムが正常に動作しているかを確認してください。 ブラウザで以下のアドレスにアクセスします。

https://<サーバーのアドレス>/.login

ログイン画面が表示されるため、以下の通り入力してログインしてください。

• ユーザ名：root
• パスワード：root

ログインが確認できたら、動作確認は完了です。

KE2 のアップデート

標準シングル構成 (ke2/single/basic) の基本的なアップデート手順を説明します。

リリースによっては特別なアップデート手順が指定される場合がありますので、アップデート作業前には必ずリリースノートを確認するようにしてください。

ke2-docker パッケージの更新

システム構築に用いた ke2-docker パッケージが改版されている場合は、基本的には事前に更新しておいてください。

• github からクローンしている場合は、git pull コマンドで更新してください。
• ZIP ファイルから展開している場合は、改めてダウンロードしなおして展開してください。

システム構築時に docker-compose.yml ファイルや各種設定ファイルなどをカスタマイズしている場合は、更新後に改めてカスタマイズしなおしてください。

ke2-docker ディレクトリへの移動

システム構築に用いた docker-compose.yml ファイルを含むディレクトリに移動してください。

$ cd ke2/single/basic

コンテナの削除

以下のコマンドを実行してコンテナを削除してください。

$ docker compose down

このときボリュームは削除しない（-v オプションは付けない）ことに注意してください。 これによりデータベースの内容などはアップデート後も引き継がれます。

コンテナイメージの更新

以下のコマンドを実行してコンテナイメージを更新してください。

$ docker compose pull

※ インターネットに接続できない環境の場合は「オフライン環境での構築」を参考にしてください。

コンテナの作成と開始

以下のコマンドを実行してコンテナを作成および開始を行なってください。

$ docker compose up -d

外部DBシングル構成 (ke2/single/extdb)

先の標準シングル構成では 1 つの Docker ホスト上にすべてのコンテナを配置して動作させていましたが、 この外部DBシングル構成はそこからデータベースのコンテナを除外したような構成になっています。 データベースについてはコンテナ外部に別途用意して、コンテナ内部の各機能からアクセスするようにセットアップします。

以下のような場合には、この構成が便利です。

• 別環境に独自にデータベースを構築したい
• 既存のデータベースと連携した構成をとりたい
• データベース処理の負荷をオフロードしたい

構成図

本構成では、1 つの Docker ホストにデータベース以外のコンテナを配置して動作させます。

前提条件

本構成を利用するには以下のような前提条件があります。

• 外部データベースとして連携できるのは PostgreSQL 12 以上となります。
• コンテナ環境から外部データベースまでネットワーク的に直接到達できる必要があります。
• 外部データベースには、ホスト名、ポート番号、ユーザ名、パスワード、データベース名の指定だけで接続できる必要があります。
• Kompira のデータベースでは拡張モジュール pgcrypto を利用しますので、外部配置の PostgreSQL に拡張モジュールを追加する機能と権限が必要になります。

セットアップの流れ

本構成のセットアップの流れは以下のようになります。詳細については各ページを参照してください。

• サーバの準備
• データベースの準備
• KE2 のセットアップ

サーバーの準備

オンプレ環境に KE2.0 を動作させるサーバーを準備します。

サーバーの準備

システム要件 を参考に、Linux など対応するサーバーを1台用意してください。 以後の手順ではサーバーに対する root 権限が必要になりますのでご注意ください。

Docker Engine の準備

https://docs.docker.com/engine/install/ を参考に環境に合わせて Docker Engine をインストールして、Docker を起動してください。たとえば RHEL 環境では以下のような手順になります。

$ sudo yum install -y yum-utils
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
$ sudo yum install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
$ sudo systemctl enable --now docker

データベースの準備

この構成では、外部データベースとして以下の要件を満たす PostgreSQL が必要になります。

• バージョン: 12 以上
• その他: 拡張モジュール pgcrypto がインストールされていること (RHEL系 であれば、postgresql-contrib パッケージをインストールしておく必要があります)

Docker が動作しているホストサーバ、あるいは別のサーバ上に要件を満たす PostgreSQL を準備してください。

接続仕様の準備

この構成では、Docker コンテナで動作するサービスからデータベースに接続するための情報を、環境変数 DATABASE_URL で指定する必要があります。

DATABASE_URL=pgsql://<ユーザ名>:<パスワード>@<アドレス>:<ポート番号>/<データベース名>

たとえば外部データベースの接続に必要なパラメータが以下のような場合を考えます。

この場合、環境変数 DATABASE_URL は次のように指定することになります。

DATABASE_URL=pgsql://kompira:kompira@10.20.0.XXX:5432/kompira

実際に準備した、またはこれから準備する PostgreSQL サーバの構成に合わせて、DATABASE_URL に指定する値を準備しておいてください。

PostgreSQL の準備

PostgreSQL のインストールについては準備する環境に合わせて、OS のマニュアルなどを参考にして実施してください。

以下では、PostgreSQL の最低限必要になる設定手順について記述しますので、用意した PostgreSQL サーバ上で実施してください。 詳細な設定方法については PostgreSQL のホームページや公式ドキュメントを参照してください。

(1) kompira ユーザーとデータベースの作成

ユーザを作成します。ここではデフォルトの "kompira" という名前で作成します。パスワードの設定も求められるのでこれもデフォルトの "kompira" と入力してください。

$ sudo -i -u postgres createuser -d -P "kompira"

上で作成したユーザをオーナーとするデータベースを作成します。ここではデフォルトの "kompira" という名前で作成します。

$ sudo -i -u postgres createdb --owner="kompira" --encoding=utf8 "kompira"

(2) PostgreSQL サーバの接続設定

ローカルホスト以外からも PostgreSQL サーバに接続できるように設定します。 postgresql.conf (RHEL系標準パッケージをインストールした場合は /var/lib/pgsql/data/postgresql.conf) の listen_address を以下のように設定してください。

listen_address = '*'

(3) PostgreSQL のクライアント認証の設定

手順 (1) で作成したユーザからパスワード接続できるように、pg_hba.conf (RHEL系標準パッケージをインストールした場合は /var/lib/pgsql/data/pg_hba.conf) に host 設定を追加してください。 たとえば Docker が動作しているホストが PostgreSQL サーバと同じネットワークに配置している場合は、以下のような行を追加してください。

host    kompira         kompira         samenet             scram-sha-256

あるいは、Docker が異なるネットワークに配置されている場合は、"samenet" の部分を CIDR 形式などで指定するようにしてください。

host    kompira         kompira         10.10.0.0/16        scram-sha-256

(4) PostgreSQL の再起動

これらの設定を行なった後は、一度 postgresql サービスを再起動してください。

$ sudo systemctl restart postgresql-<バージョン番号>

KE2 のセットアップ

外部DBシングル構成 (ke2/single/extdb) の基本的なセットアップ手順を説明します。

ke2-docker パッケージの準備

KE2.0 の構築に必要な docker compose ファイルなどを含む ke2-docker パッケージを用意してください。 ke2-docker リポジトリ から、以下のいずれかの方法でサーバー上に展開してください。

• 以下のコマンドを実行して git リポジトリをクローンしてください。(git コマンドが必要です)
  • $ git clone https://github.com/fixpoint/ke2-docker.git
• ZIP ファイルとしてダウンロードし、用意したサーバー上に配置して展開してください。(unzip コマンドが必要です)

ke2-docker パッケージを展開できたら、外部 DB シングル構成用の docker-compose.yml ファイルを含むディレクトリに移動します。

$ cd ke2/single/extdb

コンテナイメージの取得

以下のコマンドを実行してコンテナイメージを取得してください。

$ docker compose pull

※ インターネットに接続できない環境の場合は「オフライン環境での構築」を参考にしてください。

SSL 証明書の生成

以下のコマンドを実行して自己署名 SSL 証明書を生成してください。

$ ../../../scripts/create-cert.sh

秘密鍵ファイルの準備

データベース上でのパスワード情報などの暗号化に用いる秘密鍵をファイル .secret_key に準備します。 Kompira 用データベースを新規に構築する場合は、たとえば以下のようにして空のファイルを用意してください。

$ touch .secret_key

※ 外部データベースとして既に構築されている Kompira データベースを用いる場合は、そのデータベースにおける秘密鍵を .secret_key に書き込んでおいてください。

$ echo -n 'xxxxxxxxxxxxxxxx' > .secret_key

コンテナの作成と開始

以下のコマンドを実行してコンテナを作成および開始を行なってください。 このとき先に準備した環境変数 DATABASE_URL を指定するようにしてください。

$ DATABASE_URL=pgsql://... docker compose up -d

セットアップ後の動作確認

セットアップが完了したら、KE2.0 システムが正常に動作しているかを確認してください。 ブラウザで以下のアドレスにアクセスします。

https://<サーバーのアドレス>/.login

ログイン画面が表示されるため、以下の通り入力してログインしてください。

• ユーザ名：root
• パスワード：root

ログインが確認できたら、動作確認は完了です。

KE2 のアップデート

外部DBシングル構成 (ke2/single/extdb) の基本的なアップデート手順を説明します。

リリースによっては特別なアップデート手順が指定される場合がありますので、アップデート作業前には必ずリリースノートを確認するようにしてください。

ke2-docker パッケージの更新

システム構築に用いた ke2-docker パッケージが改版されている場合は、基本的には事前に更新しておいてください。

• github からクローンしている場合は、git pull コマンドで更新してください。
• ZIP ファイルから展開している場合は、改めてダウンロードしなおして展開してください。

システム構築時に docker-compose.yml ファイルや各種設定ファイルなどをカスタマイズしている場合は、更新後に改めてカスタマイズしなおしてください。

ke2-docker ディレクトリへの移動

システム構築に用いた docker-compose.yml ファイルを含むディレクトリに移動してください。

$ cd ke2/single/extdb

コンテナの削除

以下のコマンドを実行してコンテナを削除してください。

$ docker compose down

このときボリュームは削除しない（-v オプションは付けない）ことに注意してください。 これによりデータベースの内容などはアップデート後も引き継がれます。

コンテナイメージの更新

以下のコマンドを実行してコンテナイメージを更新してください。

$ docker compose pull

※ インターネットに接続できない環境の場合は「オフライン環境での構築」を参考にしてください。

コンテナの作成と開始

以下のコマンドを実行してコンテナを作成および開始を行なってください。

$ docker compose up -d

オンプレクラスタ構成

オンプレクラスタ構成では Kompira エンジンなどのコンテナを複数のノードで動作させることで、可用性の向上やジョブフローの並列実行によるスループット向上が狙えます。

本ガイドでは以下の構成について、その構築手順を紹介します。

• Swarmクラスタ構成

Swarmクラスタ構成

この Swarm クラスタ構成では、クラスタ管理に Docker Swarm を採用しており、シングル構成同様に docker compose ファイルによってクラスタ構成を定義します。

前提条件

Swarm クラスタ構成には、以下の前提条件があります。

• 同一 LAN 上に配置するホスト（Linux サーバ）が最小で3台必要になります。
  • この 3台のホスト上にそれぞれ Docker Swarm のマネージャノードを起動してクラスタを構成します。
• 外部データベース構成を取る必要があります。
  • 外部DBシングル構成と同様に PostgreSQL データベースを準備する必要があります。
• 各ホストでディレクトリを共通出来るように、ネットワークファイルシステムを用意する必要があります。

セットアップの流れ

ここでは、以下のようなシステム構成をセットアップする手順を紹介します。

• 3台のサーバーによる Docker Swram クラスタ構成
• GlusterFS による共有ファイルシステム
• PostgreSQL/Pgpool-II によるクラスタ型外部データベース

上記条件での本構成のセットアップの流れは以下のようになります。詳細については各ページを参照してください。

• サーバーの準備
• Swarm クラスタの準備
• GlusterFS の準備
• Pgpool-II の準備
• KE2 のセットアップ

なお、以降の説明では、ホストとして RHEL 9 系 (CentOS Stream 9、AlmaLinux 9、RockyLinux 9も含む) サーバの利用を想定しています。 Ubuntu など別のディストリビューションを利用する場合は、適宜、コマンド等を読み替えてください。

コマンド実行手順表示について

本構成のセットアップ手順では、すべてのホストサーバ上でコマンドを実行する場合や、あるいは特定のホストサーバ上でだけコマンドを実行する場合などがあります。

以後の手順説明において、以下のように表示されている手順はすべてのホストサーバ上でコマンドを実行するようにしてください。とくに指定がない場合は実行順は問いません。

[全ホスト]$ command ...

以下のように表示されている手順については、[ホスト名] に記されたホストサーバ上でコマンドを実行するようにしてください。

[ホスト名]$ command ...

サーバーの準備

Docker Swarm (24.0以降) が動作する Linux サーバ 3台を準備します。

以降の構築手順では、3台のホストのホスト名と IP アドレスを以下のように想定しています。

• ke2-server1: 10.20.0.1
• ke2-server2: 10.20.0.2
• ke2-server3: 10.20.0.3

また、Pgpool-II クラスタに設定する仮想 IP アドレスとしては 10.20.0.100 を使用します。

名前解決の準備

各サーバはお互いにホスト名で名前解決できる必要があります。 DNS サーバに名前登録するか、各サーバ上の /etc/hosts に設定を追加してください。

Swarm クラスタの準備

Docker CE のインストール

Docker の公式リポジトリを追加し、Docker CE を各ホストにインストールしてください。 各ホスト上で以下のコマンドを実行します。

[全ホスト]$ sudo dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo
[全ホスト]$ sudo dnf install docker-ce

次に、Docker サービスの有効化と起動を行います。

[全ホスト]$ sudo systemctl enable --now docker

ユーザの docker グループへの追加

現在のユーザーが sudo せずに dockerコマンドを実行できるように、現在のユーザを docker グループに所属させます。(本手順は省略してもかまいません）

[全ホスト]$ sudo usermod -aG docker $USER

なお、上記の設定を反映させるには、一度ログアウトしてから、再度ログインし直す必要があります。

ファイアウォールの設定

本構成では以下のポートを用いた通信ができるようにする必要があります。

• TCP ポートの 2377: クラスター管理における通信のため
• TCP および UDP ポートの 7946: ノード間の通信のため
• UDP ポートの 4789: オーバーレイネットワークのトラフィックのため

各ホスト上で、以下のコマンドを実行してポートを開放してください（システムによってはデフォルトで開放されている場合もあります）。

[全ホスト]$ sudo firewall-cmd --permanent --add-port=2377/tcp
[全ホスト]$ sudo firewall-cmd --permanent --add-port=7946/tcp --add-port=7946/udp
[全ホスト]$ sudo firewall-cmd --permanent --add-port=4789/udp
[全ホスト]$ sudo firewall-cmd --reload

ただし、VMWare 環境で構築する場合は、注意事項があります。

Docker Swarm クラスタの初期化

最初のマネージャノード（ここでは ke2-server1 を想定します）となる Docker ホスト上で以下を実行してください。

[ke2-server1]$ docker swarm init

ただし、VMWare 環境で構築する場合や、サーバが複数ネットワークに属する場合には、以下の注意事項があります。

VMWare 環境での注意事項

VMWare の仮想サーバでネットワークインタフェースに vmxnet3 を利用している場合、 Swarm のオーバーレイネットワークが利用する 4789 番ポートと衝突し、Swarm ノード間の TCP 通信ができない問題が報告されています。 これを回避するためには、docker swarm init に --data-path-port オプションで 4789 以外のポート番号を指定する必要があります。 合わせて、ファイアウォールの設定も、ここで指定したポートでノード間の通信を許可するように追加します。

標準の 4789 ポートではなく例えば 14789 ポートを利用する場合は、docker swarm init 時に以下のように --data-path-port オプションで指定してください。

[ke2-server1]$ docker swarm init --data-path-port=14789

標準ではないポートを --data-path-port に指定した場合は、そのポートでノード間通信が出来るようにファイアウォールの設定も加えて実施してください。

[全ホスト]$ sudo firewall-cmd --permanent --add-port=14789/udp
[全ホスト]$ sudo firewall-cmd --reload

複数ネットワーク環境での注意事項

サーバが複数の IP アドレスを持つような環境では、docker swarm init コマンド実行時に --advertise-addr オプションの指定を求められる場合があります。 クラスタ構成を組む（すべてのノードが属している）ネットワークの IP アドレスを --advertise-addr オプションで指定するようにしてください。

[ke2-server1]$ docker swarm init --advertise-addr=10.20.0.1

※ VMWare 環境では --data-path-port オプションも合わせて指定するようにしてください。

マネージャノードの追加

続いて、以下のコマンドを実行して、マネージャノードを追加するコマンドを取得します。

[ke2-server1]$ docker swarm join-token manager

このコマンドを実行すると、次のような表示があるはずです。

To add a manager to this swarm, run the following command:

    docker swarm join \
    --token <トークン> \
    <IPアドレス>:2377

ここに表示されているコマンドを次の手順で、他のホスト上で実行することになります。

マネージャノードの追加

先の手順を実行したときに表示された docker swarm join コマンドを、2つ目、3つ目の Docker ホスト上でそれぞれ実行してください。

[ke2-server{2,3}]$ docker swarm join --token <トークン> <IPアドレス>:2377

ノード一覧の確認

任意の Docker ホスト上で以下のコマンドを実行すると、Swarmクラスタに参加しているノード一覧を表示することができます。

[ke2-server1]$ docker node ls
ID                            HOSTNAME        STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
ee5c0f5j5dt1m2x6vemrz7dxy *   ke2-server1     Ready     Active         Reachable        25.0.4
ypqsarfbtuwrit9hekiqac03u     ke2-server2     Ready     Active         Reachable        25.0.4
t8zhg0ez1xezj0942d7zb4u6h     ke2-server3     Ready     Active         Leader           25.0.4

3台のノードの STATUS が Ready になっていること、いずれかのノードの MANAGER STATUS が Leader になっていることを確認してください。

GlusterFS の準備

クラスタ構成では Docker Swarm 上で動作する各ホスト上の Kompira のコンテナからアクセス可能な共有ディレクトリが必要になります。 すでに、利用可能な共有ファイルサーバがある場合は、そのサーバ上のディレクトリを Docker Swarm の各ホストからマウントして利用することもできます。

ここでは、GlusterFS 分散ファイルシステムを用いて共有ディレクトリを準備します。

GlusterFS インストールと設定

各ホスト上で以下のコマンドを実行して、GlusterFS をインストールします。

[全ホスト]$ sudo dnf install centos-release-gluster10
[全ホスト]$ sudo dnf install glusterfs-server

次に、GlusterFS サービスの有効化と起動を行います。

[全ホスト]$ sudo systemctl enable --now glusterd

ファイアウォールの設定

各ホスト上で、以下のコマンドを実行してポートを開放します。

[全ホスト]$ sudo firewall-cmd --add-service=glusterfs --permanent
[全ホスト]$ sudo firewall-cmd --reload

プールの構築

どれか1つのノードで、gluster peer probe コマンドを実行し、他のサーバをプールに追加します。

ke2-server1 上で実行する場合：

[ke2-server1]$ sudo gluster peer probe ke2-server2
[ke2-server1]$ sudo gluster peer probe ke2-server3

プールを構成するサーバの一覧は、以下のコマンドで確認することができます。

[ke2-server1]$ sudo gluster pool list
UUID                                    Hostname        State
9d593742-d630-48b0-8570-066d15822c4d    ke2-server2     Connected
9b7f2c39-a0ce-498f-9939-4fcf55a36fac    ke2-server3     Connected
d47ce78a-0ffd-468f-9218-32fa2d97c431    localhost       Connected

GlusterFS ボリュームの作成

ボリューム gvol0 を作成してスタートします。 GlusterFS クラスタ内のどれか1つのノード上で（以下の例では ke2-server1 を想定）以下を実行します。 (ここでは root パーティションに作成しているため、force オプションが必要です)

[ke2-server1]$ sudo gluster vol create gvol0 replica 3 ke2-server1:/var/glustervol0 ke2-server2:/var/glustervol0 ke2-server3:/var/glustervol0 force
[ke2-server1]$ sudo gluster vol start gvol0

ボリュームの マウント

作成した gvol0 ボリュームを各ノード上でマウントします。

[全ホスト]$ sudo mkdir /mnt/gluster
[全ホスト]$ sudo mount -t glusterfs localhost:/gvol0 /mnt/gluster

再起動時に自動的にマウントされるように以下を /etc/fstab に追加しておきます。

localhost:/gvol0 /mnt/gluster glusterfs _netdev,defaults 0 0

Pgpool-II の準備

各 Swarm ノード上で実行している Kompira エンジンや Kompira アプリケーションサーバのコンテナからアクセス可能なデータベースとして、 PostgreSQL/Pgpool-II クラスタを構築する手順について説明します。

Pgpool-II を用いたデータベースクラスタには最低で 3台 のホストが必要となります。

ここでは、Docker Swarm クラスタのホスト上にデータベースクラスタを同居した形で構築していますが、Docker Swarm クラスタとは別にデータベースクラスタを構築しても構いません。

PostgreSQL/Pgpool-II のセットアップ

ここでは、ke2-docker パッケージに附属するセットアップ用のスクリプトを用いて構築する手順を示します。 このスクリプトは RHEL 9系 (CentOS Stream 9、Rocky Linux 9、AlmaLinux 9など互換 OS を含む) のサーバを対象としています。 その他の OS 上にセットアップする場合は、スクリプトの内容を参考にして構築してください。

なお、本セットアップスクリプトでは、PostgreSQL/Pgpool-II の各ユーザーとパスワードをデフォルトで以下のように設定します。

(1) 各ホストへのスクリプトファイル転送

ke2-docker パッケージの ke2/cluster/swarm ディレクトリに含まれる以下のスクリプトファイルを、クラスタを構成する各ホストに転送してください。

• setup_pgpool.sh
• setup_pgssh.sh

(2) PostgreSQL/Pgpool-II のインストール

各ホストで setup_pgpool.sh スクリプトを実行します。 このスクリプトでは、PostgreSQL 16、および、Pgpool-II のインストールと初期設定を行います。 setup_pgpool.sh 起動時には以下の環境変数を指定する必要があります。

• CLUSTER_VIP: Pgpool-II で使用する仮想IPアドレス
• CLUSTER_HOSTS: クラスタを構成するホスト名（空白区切り）

CLUSTER_HOSTS の最初のホストを「プライマリサーバ」として、残りのホストを「セカンダリサーバ」としてセットアップします。 また CLUSTER_HOSTS の順番に Pgpool-II 上でのノード ID を 0, 1, 2,... と割り当てます。 したがって、各ホスト上で setup_pgpool.sh を実行する際に、CLUSTER_HOSTS のホスト順序は同一にする必要があることに注意してください。

以下に実行例を示します。

[全ホスト]$ CLUSTER_VIP=10.20.0.100 CLUSTER_HOSTS='ke2-server1 ke2-server2 ke2-server3' ./setup_pgpool.sh

一般ユーザで実行する場合、起動後に sudo のパスワードを入力を求められます。

(3) Pgpool-II 用の SSH 接続設定

各ホストで setup_pgssh.sh スクリプトを実行します。 このスクリプトでは Pgpool-II の自動フェイルオーバおよびオンラインリカバリ機能を利用するため、各ノード間で postgres ユーザが公開鍵認証で SSH 接続できるように設定します。 先ほどの手順と同様に CLUSTER_HOSTS 環境変数を指定して setup_pgssh.sh スクリプトを実行してください。

[全ホスト]$ CLUSTER_HOSTS='ke2-server1 ke2-server2 ke2-server3' ./setup_pgssh.sh

setup_pgssh.sh は postgres ユーザーの SSH 鍵ファイルを作成し、公開鍵ファイルを CLUSTER_HOSTS で指定された各ホストの ~postgres/.ssh/authorized_keys に追加することで、パスワード無しで SSH 接続できるようにします。 一般ユーザで実行する場合、起動後に sudo のパスワードを入力、および、実行ユーザがクラスタを構成する各リモートホストにログインするためのパスワードとリモートホストでの sudo パスワードの入力を求められます。

パスワード入力を間違えるなどで公開鍵の転送に失敗していると、Pgppol-II が正常に機能しなくなるので注意してください。

Pgpool-II の起動とオンラインリカバリ

ここでは、Pgpool-II を起動して PostgreSQL のクラスタ構成を行ないます。

(1) Pgpool-II の起動

プライマリサーバ（ここでは ke2-server1 を想定）から順番に、各ホスト上で以下のコマンドを実行して Pgpool-II を起動してください。

[全ホスト]$ sudo systemctl start pgpool

(2) プライマリサーバの状態確認

プライマリサーバでは setup_pgpool.sh の実行によって、既に PostgreSQL サーバが起動しています。 いずれかのホスト上で以下のコマンドを実行して、プライマリサーバで PostgreSQL がプライマリモードで動作していることを確認してください。

[任意のホスト]$ psql -h $CLUSTER_VIP -p 9999 -U pgpool postgres -c "show pool_nodes"

$CLUSTER_VIP の部分は Pgpool-II で使用する仮想IPアドレスに置き換えるか、シェル変数 CLUSTER_VIP としてそのアドレスを設定しておいてください。 下記の例では、プライマリサーバである ke2-server1 で PostgreSQL がプライマリモードで起動しており（pg_status が "up"、pg_role が "primary"）、ke2-server2 と ke2-server3 では PostgreSQL がまだ起動していないこと（pg_status が "down"）が分かります。

[ke2-server1]$ psql -h 10.20.0.100 -p 9999 -U pgpool postgres -c "show pool_nodes"
ユーザー pgpool のパスワード: 
 node_id |   hostname  | port | status | pg_status | lb_weight |  role   | pg_role | select_cnt | load_balance_node | replication_delay | replication_state | replication_sync_state | last_status_change  
---------+-------------+------+--------+-----------+-----------+---------+---------+------------+-------------------+-------------------+-------------------+------------------------+---------------------
 0       | ke2-server1 | 5432 | up     | up        | 0.333333  | primary | primary | 0          | true              | 0                 |                   |                        | 2024-06-11 18:18:20
 1       | ke2-server2 | 5432 | down   | down      | 0.333333  | standby | unknown | 0          | false             | 0                 |                   |                        | 2024-06-11 18:16:06
 2       | ke2-server3 | 5432 | down   | down      | 0.333333  | standby | unknown | 0          | false             | 0                 |                   |                        | 2024-06-11 18:16:06
(3 行)

(3) スタンバイサーバのオンラインリカバリ

Pgpool-II のオンラインリカバリ機能を利用し、ke2-server2 と ke2-server3 をスタンバイサーバとして起動させて、Pgpool-II 管理下に追加します。

オンラインリカバリさせるには、以下のように pcp_recovery_node コマンドを実行してください。

[任意のホスト]$ pcp_recovery_node -h $CLUSTER_VIP -p 9898 -U pgpool -n {ノードID} -W

{ノードID} の部分はオンラインリカバリさせるノード ID に置き換えてください。 上で確認したとおり ke2-server1 がノードID 0 でプライマリサーバとして動作していますので、ここではノード ID に 1 および 2 を指定して ke2-server2 と ke2-server3 をオンラインリカバリさせています。

[ke2-server1]$ pcp_recovery_node -h 10.20.0.100 -p 9898 -U pgpool -n 1 -W
Password:
pcp_recovery_node -- Command Successful

[ke2-server1]$ pcp_recovery_node -h 10.20.0.100 -p 9898 -U pgpool -n 2 -W
Password:
pcp_recovery_node -- Command Successful

(4) スタンバイサーバの状態確認

オンラインリカバリによって PostgreSQL のスタンバイサーバが起動していることを、再び以下のコマンドで確認してください。

[任意のホスト]$ psql -h $CLUSTER_VIP -p 9999 -U pgpool postgres -c "show pool_nodes"

以下の例では、ke2-server2 と ke2-server3 で PostgreSQL がスタンバイサーバとして起動していること（pg_status が "up"、pg_role が "standby"）が分かります。

[ke2-server1]$ psql -h 10.20.0.100 -p 9999 -U pgpool postgres -c "show pool_nodes"
ユーザー pgpool のパスワード: 
 node_id |   hostname  | port | status | pg_status | lb_weight |  role   | pg_role | select_cnt | load_balance_node | replication_delay | replication_state | replication_sync_state | last_status_change  
---------+-------------+------+--------+-----------+-----------+---------+---------+------------+-------------------+-------------------+-------------------+------------------------+---------------------
 0       | ke2-server1 | 5432 | up     | up        | 0.333333  | primary | primary | 0          | false             | 0                 |                   |                        | 2024-06-11 18:18:20
 1       | ke2-server2 | 5432 | up     | up        | 0.333333  | standby | standby | 0          | true              | 0                 | streaming         | async                  | 2024-06-11 18:22:54
 2       | ke2-server3 | 5432 | up     | up        | 0.333333  | standby | standby | 0          | false             | 0                 | streaming         | async                  | 2024-06-11 18:22:54
(3 行)

セットアップ手順

Swarm クラスタ構成 (ke2/cluster/swarm) の基本的なセットアップ手順を説明します。

本ページの手順は Docker Swarm クラスタを構成するいずれかのマネージャノード上で実行してください。

デプロイの準備

クラスタ構成の KE2.0 を開始するための準備を行ないます。 ke2-docker パッケージの、Swarm クラスタ構成用のディレクトリに移動します。

[ke2-server1]$ cd ke2/cluster/swarm

コンテナイメージの取得

以下のコマンドを実行してコンテナイメージを取得してください。

[ke2-server1]$ docker compose pull

※ インターネットに接続できない環境の場合は「オフライン環境での構築」を参考にしてください。

SSL 証明書の生成

以下のコマンドを実行して自己署名 SSL 証明書を生成してください。

[ke2-server1]$ ../../../scripts/create-cert.sh

共有ディレクトリの作成

ネットワークファイルシステム上に共有ディレクトリ (SHARED_DIR) と以下に示すサブディレクトリを作成してください。

- ${SHARED_DIR}/
	- log/
	- var/
	- ssl/

SHARED_DIR を /mnt/gluster とする場合は、例えば以下のようにディレクトリを作成できます。

[ke2-server1]$ mkdir -p /mnt/gluster/{log,var,ssl}

秘密鍵ファイルの準備

データベース上でのパスワード情報などの暗号化に用いる秘密鍵をファイル ${SHARED_DIR}/var/.secret_key に準備します。 Kompira 用データベースを新規に構築する場合は、たとえば以下のようにして空のファイルを用意してください。

[ke2-server1]$ touch /mnt/gluster/var/.secret_key

※ 外部データベースとして既に構築されている Kompira データベースを用いる場合は、そのデータベースにおける秘密鍵を ${SHARED_DIR}/var/.secret_key に書き込んでおいてください。

[ke2-server1]$ echo -n 'xxxxxxxxxxxxxxxx' > .secret_key

docker-swarm.yml の生成

docker-swarm.yml を生成するために、以下のコマンドを実行してください。 このとき少なくとも環境変数 SHARED_DIR で共有ディレクトリを指定するようにしてください。

[ke2-server1]$ SHARED_DIR=/mnt/gluster ./setup_stack.sh

Swarm クラスタの開始

エラーが無ければ docker-swarm.yml というファイルが生成されているはずです。 これでシステムを開始する準備ができました。以下のコマンドを実行して Kompira Enterprise 開始をします。

[ke2-server1]$ docker stack deploy -c docker-swarm.yml ke2

正常に動作しない場合は、以下のコマンドでクラスタを停止させて、設定を見直してみてください。

[ke2-server1]$ docker stack rm ke2

セットアップ後の動作確認

セットアップが完了したら、KE2.0 システムが正常に動作しているかを確認してください。 ブラウザで以下のアドレスにアクセスします。

https://<サーバーのアドレス>/.login

ログイン画面が表示されるため、以下の通り入力してログインしてください。

• ユーザ名：root
• パスワード：root

ログインが確認できたら、動作確認は完了です。

カスタマイズ

環境変数によるカスタマイズ

setup_stack.sh を実行するときに環境変数を指定することで、簡易的なカスタマイズを行なうことができます。

[ke2-server1]$ 環境変数=値... ./setup_stack.sh

カスタマイズ例:

[ke2-server1]$ DATABASE_URL="pgsql://kompira:kompira@10.20.0.100:9999/kompira" SHARED_DIR=/mnt/gluster ./setup_stack.sh

詳細なカスタマイズ

コンテナ構成などを詳細にカスタマイズしたい場合は、setup_stack.sh スクリプトで生成された docker-swarm.yml ファイルを、目的に合わせてカスタマイズしてください。

アップデート手順

Swarm クラスタ構成 (ke2/cluster/swarm) の基本的なアップデート手順を示します。

リリースによっては特別なアップデート手順が指定される場合がありますので、アップデート作業前には必ずリリースノートを確認するようにしてください。

ここでは GlusterFS や Pgpool-II/PostgreSQL のアップデートについては対象外としています。

注意事項

クラスタ構成を部分的に順次アップデートしていくローリングアップデートには対応していません。 システム全体を停止させてアップデートを行なう手順をとるため、アップデート作業中はサービス停止状態になりますのでご注意ください。

また、実行中のジョブフロープロセスが存在すると強制的に異常終了となります。 可能であれば、すべてのジョブフロープロセスを適切に停止させてから、アップデート手順を実施することをお勧めします。

クラスタシステムの削除

Swarm クラスタのいずれかのマネージャーノード上（以下の例では ke2-server1）で、docker stack rm ke2 コマンドを実行してください。

[ke2-server1]$ docker stack rm ke2
Removing service ke2_jobmngrd
Removing service ke2_kengine
Removing service ke2_kompira
Removing service ke2_nginx
Removing service ke2_rabbitmq
Removing service ke2_redis
Removing config swarm_rabbitmq-config-cluster
Removing config swarm_kompira-config
Removing config swarm_rabbitmq-config-auth
Removing config swarm_kompira-audit
Removing config swarm_rabbitmq-config-ssl
Removing config swarm_bootstrap-rabbitmq
Removing config swarm_nginx-config
Removing network swarm_default

このコマンドを実行すると、クラスタで動作している全てのコンテナが停止して、クラスタスタックと構成サービスの定義などが削除されます。

この時点で、ノードの再起動や docker サービスの再起動を行なっても Kompira サービスは起動しない状態になっています。そのため以後の手順に進む前に、GlusterFS や Pgpool-II/PostgreSQL など Kompira 以外のミドルウェアのアップデートを実施することも可能です。ただし、その場合は、次の手順に進む前に、手を加えたシステム・ミドルウェアなどが再び正常に動作していることを確認するようにしてください。

ke2-docker パッケージの更新

システム構築に用いた ke2-docker パッケージが改版されている場合は、基本的には事前に更新しておいてください。

• github からクローンしている場合は、git pull コマンドで更新してください。
• ZIP ファイルから展開している場合は、改めてダウンロードしなおして展開してください。

システム構築時に docker-compose.yml ファイルや各種設定ファイルなどをカスタマイズしている場合は、更新後に改めてカスタマイズしなおしてください。

ke2-docker ディレクトリへの移動

システム構築に用いた docker-compose.yml ファイルを含むディレクトリに移動してください。

[ke2-server1]$ cd ke2/cluster/swarm

クラスタ構成の再セットアップ

ke2-docker パッケージにアップデート/変更点がなかった場合は、この手順はスキップすることができます。

ke2-docker にアップデートがある場合、セットアップ手順 を注意深く確認してください。

• セットアップ手順の「Swarm クラスタの開始」の一つ手前の手順までを、必要に応じて実施してください。
• すでに同じ内容で実施済みの手順についてはスキップすることができます。
  • 例えば「共有ディレクトリの作成」という手順の場合、作成すべきディレクトリ構成が同じであり、すでに作成済みであればスキップできます。
• ただし「アップデート時の注意点」といった記述がある場合は、それに従ってください。

※ docker-swarm.yml を生成しなおしていてカスタマイズが必要な場合は、この段階で改めてカスタマイズを適用してください。

Swarm クラスタの開始

以前生成した／または新たに生成した docker-swarm.yml ファイルを指定して、Swarm クラスタを開始してください。

[ke2-server1]$ docker stack deploy -c docker-swarm.yml ke2

問題なければ、アップデートした Kompira が起動しているはずです。

クラウド構成

クラウド構成の構築ガイドについては準備中です。

外部連携構成

いずれかの構成でセットアップした KE2.0 システムの外部に、ジョブマネージャを単体で配置したり、kompira_sendevt をインストールしてメッセージ送信に利用したい場合があります。ここでは、こうした外部連携の構成について説明します。

KE2.0 側での準備

外部にジョブマネージャや kompira_sendevt を配置して、KE2.0 システムと連携させたい場合、KE2.0 システム側で以下の準備が事前に必要になります。

• AMQPS 接続を許可するファイヤーウォールの設定
• rabbitmq に外部接続用のユーザの追加とパーミッションの設定

AMQPS の接続許可

まず OS ごとの手順で AMQPS (5671番ポート) の許可設定を行なってください。firewall-cmd を使う場合の例は以下のようになります。KE2.0 がクラスタ構成の場合は全てのノードで許可設定を行なってください。

$ sudo firewall-cmd --add-service=amqps --permanent
$ sudo firewall-cmd --reload

rabbitmq へのユーザ追加

続けて rabbitmq に外部から接続するためのユーザーを追加し、パーミッションを設定してください。 ここでは、ユーザ名 kompira / パスワード kompira で設定する場合の例を以下に示します。

$ docker exec $(docker ps -q -f name=rabbitmq) rabbitmqctl add_user kompira kompira
$ docker exec $(docker ps -q -f name=rabbitmq) rabbitmqctl set_permissions --vhost / kompira '.*' '.*' '.*'

外部 jobmngrd 構成

サーバ上でジョブマネージャだけをコンテナで動作させる構成について示します。

外部 jobmngrd の動作環境

動作環境の要件については KE2.0 本体と同様ですが、リソース要件については以下のように緩和します。

コンテナとして動作させるため、ホストサーバ上に事前に Docker のインストールは行なっておいてください。

外部 jobmngrd のセットアップ

外部 jobmngrd 構成をセットアップする手順について説明します。

KE2.0 システム側の事前準備については、KE2.0 側での準備 を参考に実施しておいてください。

ke2-docker パッケージの準備

KE2.0 の構築に必要な docker compose ファイルなどを含む ke2-docker パッケージを用意してください。 ke2-docker リポジトリ から、以下のいずれかの方法でサーバー上に展開してください。

• 以下のコマンドを実行して git リポジトリをクローンしてください。(git コマンドが必要です)
  • $ git clone https://github.com/fixpoint/ke2-docker.git
• ZIP ファイルとしてダウンロードし、用意したサーバー上に配置して展開してください。(unzip コマンドが必要です)

ke2-docker パッケージを展開できたら、外部 jobmngrd 構成用の docker-compose.yml ファイルを含むディレクトリに移動します。

$ cd ke2/extra/jobmngrd

コンテナイメージの取得

以下のコマンドを実行してコンテナイメージを取得してください。

$ docker compose pull

※ インターネットに接続できない環境の場合は「オフライン環境での構築」を参考にしてください。

コンテナの作成と開始

以下のコマンドを実行してコンテナを作成および開始を行なってください。

$ AMQP_URL=... docker compose up -d

このとき KE2.0 が動作しているシステムの rabbitmq に接続できるように、rabbitmq に追加したユーザやパスワードに合わせて AMQP_URL を指定してください。

$ AMQP_URL=amqps://kompira:kompira@{{rabbitmqのアドレス}}:5671 docker compose up -d

セットアップ後の動作確認

ブラウザで KE2.0 の「管理領域設定 > デフォルト」 (/config/realms/default) を確認して、「ジョブマネージャ状態」一覧にこのホストがステータス「動作中」として表示されていれば、外部 jobmngrd 構成のセットアップは成功です。

外部 kompira_sendevt

KE2.0 に対して外部からメッセージを送信するために、kompira_sendevt を使う方法について説明します。

Kompira-sendevt パッケージ

kompira_sendevt コマンドを含む Python パッケージ Kompira-sendevt は pypi.org で公開しています。

https://pypi.org/project/Kompira-sendevt/

なお、kompira_sendevt 専用の Docker イメージを配布する予定はありません。

Python のインストール

Python パッケージ Kompira-sendevt をインストールするには、インストール先に Python 自体がインストールされている必要があります。

そのため、まずはインストール先のサーバに Python をインストールしておいてください。Python のインストール方法については Python の公式ページを参照してください。

Python の対応バージョンは 3.8 以上とします。

外部 kompira_sendevt のインストール

Linux 環境へのインストール

Kompira-sendevt 用の独立した Python 仮想環境 (venv) を作成します。 ここでは /opt/kompira に作成する前提で説明します。

$ python -m venv /opt/kompira

ログファイルの出力先としてディレクトリ /var/log/kompira を作成します。

$ mkdir -p /var/log/kompira

pip コマンドで Kompira-sendevt パッケージをインストールしてください。

$ /opt/kompira/bin/pip install Kompira-sendevt~=2.0

kompira_sendevt コマンドは /opt/kompira/bin にインストールされますので、 次のように kompira_sendevt コマンドを実行してみてください。

$ /opt/kompira/bin/kompira_sendevt --version
kompira_sendevt (Kompira version 2.0.0)

正しくインストールされていれば、バージョン番号が出力されます。

Windows 環境へのインストール

Kompira-sendevt 用の独立した Python 仮想環境 (venv) を作成します。 ここでは C:\Kompira に作成する前提で説明します。

C:\> python -m venv C:\Kompira

ログファイルの出力先としてディレクトリ C:\Kompira\Log を作成します。

C:\> mkdir C:\Kompira\Log

pip コマンドで Kompira-sendevt パッケージをインストールしてください。

C:\> C:\Kompira\Scripts\pip.exe install Kompira-sendevt~=2.0

kompira_sendevt コマンドは C:\Kompira\Scripts にインストールされますので、 次のように kompira_sendevt コマンドを実行してみてください。

C:\> C:\Kompira\Scripts\kompira_sendevt.exe --version
kompira_sendevt (Kompira version 2.0.0)

正しくインストールされていれば、バージョン番号が出力されます。

オフライン環境での構築

インターネットに接続できない環境で KE2.0 をセットアップする必要がある場合、次のような手順が必要になります。

• オンライン環境でコンテナイメージを pull してファイルにセーブする
• オフライン環境のサーバにセーブファイルを転送してロードする

コンテナイメージのセーブ

オンライン環境で ke2-docker パッケージのいずれかの構成のディレクトリで、docker compose pull を実行してコンテナイメージを取得してください。

$ docker compose pull

docker images コマンドでいくつかのイメージが存在していることを確認してください。

$ docker images

docker save コマンドでコンテナイメージをセーブしてください。ファイルサイズが大きくなるのでここでは gzip で圧縮しています。

$ docker save $(docker images --format "{{.Repository}}") | gzip > ke2-docker-images.gz

このときコマンドを実行した docker 環境に存在する全てのコンテナイメージがセーブされます。 不要なコンテナイメージが含まれている場合は不要なイメージを削除してから実行するか、 docker save コマンドのオプションに必要なコンテナイメージだけを指定するようにしてください。

$ docker save kompira.azurecr.io/kompira-enterprise registry.hub.docker.com/library/{rabbitmq,postgres,redis,nginx} | gzip > ke2-docker-images.gz

イメージファイルの転送

インストール先となるオフライン環境のサーバに、上でセーブした ke2-docker-images.gz ファイルを転送してください。

コンテナイメージのロード

ke2-docker-images.gz ファイルを転送したサーバ上で docker load コマンドを実行して、コンテナイメージをロードしてください。

$ zcat ke2-docker-images.gz | docker load

docker images コマンドでいくつかのイメージが存在していることを確認してください。

$ docker images

この環境で各構成のセットアップ手順を実施するとき、docker compose pull 手順はスキップできるようになります。

設定ガイド

ここに設定ガイドを書きます。

システム設定

環境変数

デプロイ時に環境変数を設定しておくことで、Kompira の動作環境を指定することが出来ます。 以下では各構成で共通的な環境変数について示します。 各構成で独自の環境変数が定義されている場合もありますので、それぞれの説明を参照してください。

HOSTNAME

デプロイする各コンテナには、ホストサーバのホスト名をベースにしたホスト名を内部的に付与するようにしています。 そのため、デプロイ時にホストサーバのホスト名を環境変数 HOSTNAME で参照しています。

環境変数 HOSTNAME でホストサーバのホスト名を参照できない環境の場合は、デプロイ前に環境変数 HOSTNAME を設定するようにしてください。

KOMPIRA_IMAGE_NAME / KOMPIRA_IMAGE_TAG

デプロイする Kompira コンテナのイメージとタグを指定します。 独自に用意したコンテナイメージや、特定のバージョンのコンテナイメージを利用したい場合にこの環境変数で指定することができます。

KOMPIRA_IMAGE_TAG のデフォルト値は ke2-docker 更新時点で公開されていた最新の kompira コンテナイメージを示しています（例えば "2.0.2" など）。KOMPIRA_IMAGE_TAG に "latest" と指定すると、デプロイ時に公開されている最新の kompira コンテナイメージを利用することができます。

DATABASE_URL / AMQP_URL / CACHE_URL

Kompira に必要なサブシステムである、データベースやメッセージキューおよびキャッシュへの接続先を URL 形式で指定します。 デフォルト値ではそれぞれ以下のように接続します。

• データベース: 同じサーバ上の PostgreSQL に Unix ドメインソケットで接続します。
• メッセージキュー: 同じサーバ上の RabbitMQ に TCP 接続します。
• キャッシュ: 同じサーバ上の Redis に TCP 接続します。

参考: https://django-environ.readthedocs.io/en/latest/types.html#environ-env-db-url

TZ / LANGUAGE_CODE

各コンテナのタイムゾーンと言語コードを設定します。

• タイムゾーンは、画面やログで表示される時刻のタイムゾーンの指定になります。
• 言語コードは "ja" (日本語) または "en" (英語) が指定できます。この値は、初回起動時にインポートする初期データの言語の指定になります。

MAX_EXECUTOR_NUM

Kompira エンジン上で動作する Executor プロセスの最大数を指定します。 未設定または 0 を指定した場合は kengine コンテナの CPUコア数だけ Executor プロセスを起動します。 なお、MAX_EXECUTOR_NUM を CPU コア数より多くしても、実行する Executor プロセス数は CPU コア数で抑えられます。

プロセス数＝min(CPUコア数、MAX_EXECUTOR_NUM)

また、導入されているライセンスによっても実際に動作する Executor のプロセス数は制限されます。

LOGGING_XXX / AUDIT_LOGGING_XXX

Kompira コンテナイメージにおけるプロセスログおよび監査ログの設定について指定します。

• LOGGING_LEVEL: プロセスログの記録レベルを指定します。
  • デフォルトは "INFO" です。
• AUDIT_LOGGING_LEVEL: 監査ログの記録レベルを指定します。
  • デフォルトは 2 です。
• LOGGING_DIR / AUDIT_LOGGING_DIR: ログの出力先ディレクトリを指定します。
  • デフォルトは "/var/log/kompira" です。標準的なデプロイ手順ではこのディレクトリはホストの kompira_log ボリュームにマウントされます。
• LOGGING_BACKUP: ログローテート時に保存されるバックアップ数を指定します。
  • LOGGING_BACKUP のデフォルトは 7 です。
  • AUDIT_LOGGING_BACKUP のデフォルトは 365 です。
• LOGGING_WHEN / AUDIT_LOGGING_WHEN: ログローテートのタイミングを指定します。デフォルトは "MIDNIGHT" です。
• LOGGING_INTERVAL / AUDIT_LOGGING_INTERVAL: ログローテートのインターバルを指定します。デフォルトは 1 です。

ログのローテーションは LOGGING_WHEN および LOGGING_INTERVAL の積に基づいて行います。 LOGGING_WHEN は LOGGING_INTERVAL の単位を指定するために使います。使える値は下表の通りです。大小文字の区別は行いません。

kompira.conf

AMQP 接続やジョブマネージャの動作に関する設定を行なう設定ファイルで、コンテナ内の /opt/kompira/kompira.conf に配置されます。 ke2-docker パッケージで KE2.0 システムを構築する場合、同パッケージの configs/ ディレクトリに含まれる kompira.conf が /opt/kompira/kompira.conf にバインドされます。

kompira.conf ファイル形式

kompira.conf は以下のようなファイル形式で、Windows における INI ファイル形式に近いものになっています。

[セクション名A]
項目名A1 = 値1
項目名A2 = 値2

[セクション名B]
項目名B1 = 値1
項目名B2 = 値2

kompira.conf セクション一覧

kompira.conf には以下のセクションがあります。

• [kompira]: Kompiraシステム関連の設定
• [logging]: ログ出力関連の設定
• [amqp-connection]: RabbitMQ の接続情報関連の設定
• [agent]: ジョブマネージャの動作に関する設定
• [event]: イベント送信の設定

kompira.conf 項目一覧

kompira.conf で設定できる項目を以下に示します。

なお、Windows 環境では以下のようにデフォルト値が変化します。

• [logging] logdir: C:\Kompira\Log

注釈: リモート接続キャッシュは、リモートコマンド実行時のリモート接続を再利用することで、同一ノード、同一アカウントでの連続するリモートコマンド実行の処理を高速化する機能です。ただし、WinRS 接続では高速化の効果が得られないため、disable_cache の設定にかかわらずリモート接続キャッシュは使用しません。

監査ログの設定 (kompira_audit.yaml)

監査ログに関する設定を行なう設定ファイルで、コンテナ内の /opt/kompira/kompira_audit.yaml に配置されます。

ke2-docker パッケージで KE2.0 システムを構築する場合、同パッケージの configs/ ディレクトリに含まれる kompira_audit.yaml が /opt/kompira/kompira_audit.yaml にバインドされます。

kompira_audit.yaml の形式

設定ファイルは kompira_audit.yaml は YAML 形式で記述します。全体としては辞書構造で、以下の設定項目が必要になります。

環境変数による記録レベル値の設定

ke2-docker パッケージでデプロイ時に環境変数 AUDIT_LOGGING_LEVEL を指定すると、その値が監査ログの記録レベル値 (logging_level) として適用されます。これは設定ファイル kompira_audit.yaml での設定より優先します。

kompira_audit.yaml の自動再読み込み

監査ログの設定ファイルをサーバー上で更新すると、次の監査ログ記録のタイミングで自動的に再読み込みされます。サービスの再起動などは不要です。

デフォルトの kompira_audit.yaml

#--------------------------------------------------------------------
# kompira_audit.yaml
#
# Configuration file to control audit log output.
#--------------------------------------------------------------------
#
# logging_level: recording level value
#
# If the calculated operation level value is less than the recording
# level value, no audit log will be recorded.
#
logging_level: 2

#
# operation_levels: basic operation level table
#
# Table of operation level reference values for each operation.
# The operation level value for an operation is the maximum of
# several operation level criteria values.
#
operation_levels:
interface:
    web: 1
    api: 1
    mng: 2
class:
    session: 3
    user: 3
    group: 3
    object: 1
    task: 1
    incident: 1
    process: 1
    schedule: 1
    packages: 1
type:
    login: 3
    logout: 3
    create: 3
    rename: 3
    copy: 3
    move: 3
    export: 3
    import: 3
    execute: 3
    suspend: 3
    resume: 3
    terminate: 3
    read: 1
    list: 1
    search: 1
    edit: 1
    confirm: 1
    update: 2
    clear: 2
    recv: 2
    send: 2
    delete: 3
permit:
    allowed: 1
    denied: 3
result:
    succeeded: 1
    failed: 1

#
# target_levels: operation level table for object operation
#
# Operation level reference value to be applied to each target
# during object manipulation.
#
target_levels:
  - {path: '/config/*', type: null, level: 2}
  - {path: '/system/*', type: '/system/types/Config', level: 2}

Kompira 画像

ブラウザ画面で表示される画像は kompira コンテナ内の以下に配置されています。

/var/opt/kompira/html/kompira/img/

ここに配置されている画像ファイルは以下の通りです。画像ファイルを直接置き換えることで、画面の見た目を変更することができます。

サイズは一般的な解像度のディスプレイで表示される時のピクセル数を参考値として示しています。

nginx 設定

nginx-default.conf

nginx のコンフィグファイル。

ホスト側で設定した nginx-default.conf を kompira-web (nginx) コンテナの /etc/nginx/conf.d/default.conf にバインドされるように docker-compose.yml の設定を行う。

ロギング設定

デフォルトのログ出力

KE2.0 はデフォルトでは以下のようなログ出力の構成になっています。

• 各コンテナのメインログは docker のコンテナログとして記録されます。
  • 【要確認】コンテナログはデフォルトでは、20MB ごと 5世代分が保持されます。
  • コンテナログの確認方法については コンテナログ管理 を参照してください。
• プロセスログおよび監査ログについては、docker の kompira_log ボリュームにファイルとして記録されます。
  • ボリュームに記録されるログの確認方法については ボリュームログ管理 を参照してください。
  • プロセスログおよび監査ログのログ設定については 環境変数 で行なうことができます。

docker 外部でのログ記録

(WIP) fluentd などを用いて docker 外部でログを記録する設定方法について記載します。

管理ガイド

ここに運用ガイドを書きます。

管理コマンド

運用ガイドの説明において管理コマンド manage.py を実行する場面がたびたび登場します。 KE2.0 では基本的に manage.py は kompira コンテナ内部で実行する必要があるため、動作中の kompira コンテナのコンテナ ID を知る必要があります。

なお、docker コマンドはコンテナ ID でなくコンテナ名を指定して実行することもできますが、構成によってコンテナ名が変わるため本マニュアルではコンテナ ID を指定して実行する手順で説明を共通化しています。

コンテナID とコンテナ名

コンテナ ID とコンテナ名は例えば以下のように docker ps コマンドで確認できます。

$ docker ps --format "{{.ID}} {{.Names}}"
aa5314b683e1 ke2-nginx-1
38dac7c77f60 ke2-kompira-1
a5caf7bd1ab6 ke2-kengine-1
dcadb5893a30 ke2-jobmngrd-1
bbdf0ed2bf9f ke2-postgres-1
2825a9737c12 ke2-rabbitmq-1
865c495d50b6 ke2-redis-1

上の結果では ke2-kompira-1 が該当して、コンテナ ID が 38dac7c77f60 であることが分かります。

kompira コンテナの実際のコンテナ名はシステム構成や構築した手順によって変わりますが、以下のように docker ps コマンドを使って名前に "kompira" という文字列を含むコンテナのコンテナIDを知ることができます。

$ docker ps -q -f name=kompira
38dac7c77f60

この手法を用いて、kompira コンテナ内部で manage.py コマンドを実行したい場合は以下のように行ないます。

$ docker exec $(docker ps -q -f name=kompira) manage.py <subcommand> ...

クラスタ構成での管理コマンドの実行

【要確認】 クラスタ構成の場合は、どのノード上で管理コマンドを実行するべきかという疑問が生じますが、対象とするコンテナが正常に動作しているノードであればどこで実行しても問題ありません。

ライセンス管理

KE2.0 におけるライセンス管理について示します。

ライセンス情報

Kompira のライセンス情報にはいくつかのフィールドが含まれています。 ライセンス管理画面で確認できる項目の一覧を以下に示します。

ここの「システムID」がライセンスを管理する上でのシステム固有IDとなっており、ライセンス申請する際に必要な情報となります。 また発行されたライセンスファイルにもシステムIDが含まれており、システムIDが一致していないとライセンスを更新することができません。

KE2.0 のライセンス情報では、v1.6 までのライセンス情報から以下の変更があります。

• ライセンス管理がノード単位からシステム単位に変更になり、ライセンス対象を特定する情報が「ノードID」から「システムID」に変更になりました。
• ジョブフローの並列実行が可能になり、「エグゼキュータ数」フィールドが追加になりました。

ライセンスの管理

ライセンスの確認、申請、および更新の手順については以下のページを参照してください。

• ライセンスの確認
• ライセンスの申請
• ライセンスの更新

ライセンスの確認

ブラウザまたは管理コマンドでライセンスの確認を行なうことができます。

ライセンス管理ページ

ブラウザでライセンス管理ページ (/config/license) を開くと、ライセンス情報を確認することができます。

license_info 管理コマンド

kompira コンテナで license_info 管理コマンドを用いて Kompira のライセンス状態を確認することもできます。

docker exec $(docker ps -q -f name=kompira) manage.py license_info

以下はライセンスが登録されている場合の実行例です。

*** Kompira License Information ***
License ID:     KE2-0000XXXX
Edition:        Development
System ID:      XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Expire date:    2025-12-31
The number of registered nodes: 2 / 100
The number of registered executors:     2 / 2
The number of registered jobflows:      3
The number of registered scripts:       0
Licensee:       kompira@example.co.jp
Signature:      XXXXXXXXXXXXXXXX....XXXXXXXXXXXXXXXX

ライセンスが登録されていない場合は、仮ライセンス情報が表示されます。

*** Kompira License Information ***
License ID:     KP-TEMP-0000000000
Edition:        temporary
System ID:      XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Expire date:    2024-07-07
The number of registered nodes: 0 / 100
The number of registered executors:     2 / 2
The number of registered jobflows:      2 / 100
The number of registered scripts:       0 / 100
Licensee:
Signature:      None

Kompira is running with temporary license.

ライセンスの申請

Kompira Enterprise を継続して利用される場合はライセンス登録が必要になります。 詳しくは license@kompira.jp までご連絡ください。

その際、ライセンスの確認 で表示されたシステム ID (System ID) をお伝えください。

ライセンスの更新

ブラウザまたは管理コマンドでライセンスの更新を行なうことができます。

ライセンス管理ページ

ライセンス管理ページ (/config/license) で「編集」ボタンを押下すると、ライセンスファイルを登録する画面に遷移します。 発行されたライセンスファイルを選択して「保存」を押下すると、ライセンス情報を更新することができます。

license_update 管理コマンド

ライセンスファイルをコマンドから更新する場合、ライセンスファイルをコンテナのファイルシステム上にコピーしてから、update_license コマンドを実行する。

$ docker cp <ライセンスファイル名> $(docker ps -q -f name=kompira):/tmp/
$ docker exec $(docker ps -q -f name=kompira) manage.py license_update /tmp/<ライセンスファイル名>

license_update コマンドのオプション

license_update コマンドには以下のオプションがあります。

なお、KE2.0 ではライセンス情報はデータベース上で管理されています。 KE1.6 までのようにファイルコピー操作でライセンスを適用することは出来ないのでご注意ください。 また、license_update コマンドにおける --no-backup オプションは廃止されています。

システム管理

KE 2.0 におけるシステム管理について示します。

• システムステータスの確認

システムステータスの確認

エンドポイント /.status に HTTP/HTTPS アクセスすることで、システムを構成する各コンテナのステータスを確認することができます。

監視システムで Kompira の状態を監視したい、また、クラスタ構成で前段でロードバランサーを設定してステータスによって振り分けたい、といった場合に利用することができます。

注意: このエンドポイントは認証無しにアクセスすることができるようになっています。外部からのアクセスを防ぐ必要がある場合は、Kompira システムの外部のファイアーウォールなどでブロックするようにしてください。

※ システムステータスの確認は KE v2.0.1 から対応しました。

ステータスコード

システムステータス /.status にアクセスすると、レスポンスのステータスコードでシステムの全体的な状況を示します。

• 200 OK: 正常
• 503 Service Unavailable: 重要なコンテナ (redis, postgreqsl) が動作していない。
• 504 Gateway Timeout: kompira コンテナが動作していない、または、ステータス取得にタイムアウトした。

※ kompira コンテナより前段のコンポーネントが上記以外のエラーコードを返す場合も考えられます。

応答がない場合は、Kompira システムのホストサーバがダウンしている、ネットワークが導通していない、Docker およびコンテナが正常に動作していない、といった障害が発生していることが考えられます。

システムステータスが異常を示している、またはシステムステータスが取得できない、といった場合は、システムに何らかの問題が生じていると考えられます。トラブルシュートを参考にして、システムの診断を行なって回復手順を試してみてください。

ブラウザアクセス時のシステムステータス

エンドポイント /.status にブラウザでアクセスすると、以下のような画面が表示されます。

これは、全てのコンテナが正常に動作しているときの表示になります。

一方で、異常や警告が発生しているコンテナがあると、以下のように当該コンテナが赤(異状)や黄色(警告)の表示になります。

各コンテナの領域をクリックすると以下のように詳細な情報が表示されますが、その内容は次に示す API アクセス時のレスポンスと同じです。

ここまではステータスコードとしては 200 となる例を示していました。重要なコンテナ (redis, postgreqsl) が動作していない場合はステータスコードが 503 となり、以下のように画面の表示上でもステータスコードを確認することができます。

API アクセス時のシステムステータス

エンドポイント /.status に API アクセスすると、JSON 形式のレスポンスを得ることができます。 API アクセスするには、リクエストのヘッダに Accept: application/json を含めてください。または、クエリ文字列に format=json を含めて /.status?format=json にアクセスする方法もあります。

API アクセスでは、各コンテナのステータスを含む情報を以下のような辞書形式で返します。

{
    "redis": {
        "status": <Status of Redis: "OK"|"NG"|"ERROR">
    },
    "postgres": {
        "status": <Status of PostgreSQL: "OK"|"NG"|"ERROR">
    },
    "rabbitmq": {
        "status": <Status of RabbitMQ: "OK"|"NG"|"ERROR">
    },
    "kompira": {
        "status": <Status of Kompira server: "OK"|"WARNING"|"ERROR">
        "detail": {
            "version": <Version of kompira>,
            "hostname": <Hostname of kompira>,
            "proc_id": <process id>,
            "started_datetime": <Date and time the kompira server started>,
            "license_expire": <Date the license expires>,
            "license_error": <License error> or null
        }
    },
    "kengine": {
        "status": <Status of Kompira engine: "OK"|"NG"|"ERROR">
        "total_num": <Total number of kompira engines>,
        "running_num": <Number of running kompira engines>,
        "executor_num": <Number of active executors>,
        "detail": [
            {
                "engine_id": <Engine ID>,
                "status": <Status of engine: "STARTED"|"RUNNING"|"UNKNOWN">,
                "role": <Role of engine: "leader"|"follower">,
                "hostname": <Hostname of kengine>,
                "executor_num": <Number of executor>,
                "started_datetime": <Date and time the kompira engine started>,
                "proc_id": <process id>
            },
            ...
        ]
    },
    "jobmngrd": {
        "status": <Status of Kompira jobmngrd: "OK"|"NG"|"ERROR">
        "total_num": <Total number of jobmngrd>,
        "active_num": <Number of active jobmngrd>,
        "detail": [
            {
                "realm_name": <Realm name>,
                "status": <Status of jobmngrd: "RUNNING"|"UNKNOWN">,
                "hostname": <Hostname of jobmngrd>,
                "version": <Version of jobmngrd>,
                "ssl": <SSL version>,
                "pid": <process id>
            },
            ...
        ]
    }
}

レスポンス辞書の、コンテナごとのステータス値 (.status) は、以下のような状態を示しています。

• "OK": 正常
• "WARNING": 正常（ただし警告を示す情報がある）
  • kompira: ライセンスエラーが生じている。
• "NG": 異状（対象コンテナにアクセスできるが、正常性を示していない）
  • redis: PING 要求に応答しない。
  • postgres: クエリ "SELECT 1" に応答しない。
  • rabbitmq: 接続後に内部で例外が発生している。
  • kengine: 実行状態のエンジンが 1 つも存在しない、または、アクティブなエグゼキュータが 1 つも存在しない。
  • jobmngrd: アクティブなジョブマネージャが 1 つも存在しない。
• "ERROR": エラー
  • 対象コンテナが動作していない、または、アクセスできない。

データ管理

ここではデータ管理の手法について示します。

• データのエクスポート
• データのインポート
• オブジェクトのコンパイル
• チャネルオブジェクトの操作
• プロセスオブジェクト管理
• バックアップとリストア

データのエクスポート

export_data 管理コマンドによるエクスポート

export_data 管理コマンドを用いると、指定したパス配下の Kompira オブジェクトを JSON 形式でエクスポートすることができます。 KE2.0 では kompira コンテナ上で export_data 管理コマンドを実行させるために、ホスト上では以下のように実行してください。

$ docker exec $(docker ps -q -f name=kompira) manage.py export_data [options...] <オブジェクトパス>

デフォルトではエクスポートデータは標準出力に出力されるので、ファイルに書き出したい場合はリダイレクトを利用するなどしてください。

$ docker exec $(docker ps -q -f name=kompira) manage.py export_data <オブジェクトパス> > exported_data.json

export_data 管理コマンドで --zip-mode オプションを指定した場合は、エクスポートデータはコンテナ側に ZIP ファイルとして書き出されることに注意してください。 エクスポートされた ZIP ファイルをホスト側で利用するには、例えば以下のようにエクスポート後にホスト側にコピーしてください。

$ docker exec $(docker ps -q -f name=kompira) manage.py export_data --zip-mode <オブジェクトパス>
$ docker exec $(docker ps -q -f name=kompira) ls  # 出力された zip ファイル名を確認
$ docker cp $(docker ps -q -f name=kompira):/opt/kompira/<zipファイル名> .

export_data 管理コマンドのオプション

export_data 管理コマンドには以下のオプションがあります。

1. --directory オプションを指定していない場合は / がエクスポートの起点となります。
2. 所有者であるユーザオブジェクトおよびその所属グループオブジェクトが追加で出力されます。

export_dir 管理コマンドによるエクスポート

export_dir 管理コマンドを用いると、指定したパス配下の Kompira オブジェクトをオブジェクト毎に YAML ファイルとしてエクスポートすることができます。 なお、以下の型を持つオブジェクトの場合は、代表するフィールドのデータのみがファイルとして出力され、 残りのフィールドは、.<オブジェクト名> という名前の YAML ファイルとして、プロパティ情報とともに出力されます。

KE2.0 では kompira コンテナ上で export_dir 管理コマンドを実行させるために、ホスト上では以下のように実行してください。

$ docker exec $(docker ps -q -f name=kompira) manage.py export_dir [options...] <オブジェクトパス>

export_dir 管理コマンドではコンテナ上のファイルシステムにファイルを書き出すことに注意してください。 エクスポートされたデータをホスト側で利用するには、例えば以下のようにエクスポート後にホスト側にコピーしてください。

$ docker exec $(docker ps -q -f name=kompira) manage.py export_dir --current /tmp <オブジェクトパス>
$ docker exec $(docker ps -q -f name=kompira) ls /tmp/  # 出力されたディレクトリ名を確認
$ docker cp $(docker ps -q -f name=kompira):/tmp/<エクスポートされたディレクトリ名> .

ここでは、コンテナ上の /tmp ディレクトリにエクスポートしたのちに、ディレクトリ一式をホスト上の指定したディレクトリ (.) にコピーしています。

export_dir 管理コマンドのオプション

export_dir 管理コマンドには以下のオプションがあります。

1. --directory オプションを指定していない場合は / がエクスポートの起点となります。
2. LINESEP には os_linesep, lf, crlf, no_change のいずれかを指定できます。os_linesep では OS 標準の改行コードに、lf では \n に、crlf では \r\n に変換します。no_change を指定したときは改行コードを変更しません。デフォルトでは os_linesep です

注釈: --linesep は :ref:テキスト形式 <data_export> のファイルにのみ影響します。

データのインポート

import_data 管理コマンドによるインポート

import_data 管理コマンドを用いると、export_data 管理コマンドでエクスポートしたファイルからデータを取り込むことができます。 KE2.0 では kompira コンテナ上で import_data 管理コマンドを実行させるために、ホスト上からは以下のように実行してください。

$ docker exec $(docker ps -q -f name=kompira) manage.py import_data [options...] <filename>...

ホスト上にあるエクスポートデータをインポートするには、例えば以下のようにインポート前にホスト側からコピーしてください。

$ docker cp <ファイル名> $(docker ps -q -f name=kompira):/tmp/
$ docker exec $(docker ps -q -f name=kompira) manage.py import_data /tmp/<ファイル名>

ここでは、コンテナ上の /tmp ディレクトリにエクスポートデータをコピーしてから、import_data 管理コマンドでインポートしています。

import_data 管理コマンドのオプション

import_data 管理コマンドには以下のオプションがあります。

1. --directory オプションを指定していない場合は / がインポートの起点となります。
2. --overwrite-mode オプションを指定していない場合、インポートデータに既存のオブジェクトが含まれていてもインポートされずにスキップします。
3. --update-config-mode オプションを指定するときは、--overwrite-mode オプションも同時に指定する必要があります

import_dir 管理コマンドによるインポート

import_dir 管理コマンドを用いると、export_dir 管理コマンドでエクスポートしたディレクトリ一式からデータを取り込むことができます。 KE2.0 では kompira コンテナ上で import_dir 管理コマンドを実行させるために、ホスト上からは以下のように実行してください。

$ docker exec $(docker ps -q -f name=kompira) manage.py import_dir [options...] <filename>...

ホスト上にあるエクスポートデータをインポートするには、例えば以下のようにインポート前にホスト側からコピーしてください。

$ docker cp <エクスポートしたディレクトリ名> $(docker ps -q -f name=kompira):/tmp/
$ docker exec $(docker ps -q -f name=kompira) manage.py import_dir /tmp/<エクスポートしたディレクトリ名>

ここでは、コンテナ上の /tmp ディレクトリにエクスポートデータをコピーしてから、import_dir 管理コマンドでインポートしています。

import_dir 管理コマンドのオプション

import_dir 管理コマンドには以下のオプションがあります。

1. --directory オプションを指定していない場合は / がインポートの起点となります。
2. --overwrite-mode オプションを指定していない場合、インポートデータに既存のオブジェクトが含まれていてもインポートされずにスキップします。
3. --update-config-mode オプションを指定するときは、--overwrite-mode オプションも同時に指定する必要があります
4. LINESEP には os_linesep, lf, crlf, no_change のいずれかを指定できます。os_linesep では OS 標準の改行コードに、lf では \n に、crlf では \r\n に変換します。no_change を指定したときは改行コードを変更しません。デフォルトでは crlf です。

注釈: --linesep は :ref:テキスト形式 <data_export> のファイルにのみ影響します。

オブジェクトのコンパイル

ジョブフローオブジェクトのコンパイル

以下のコマンドを実行する。

$ docker exec $(docker ps -q -f name=kompira) manage.py compile_jobflow [options...] <ジョブフロ―オブジェクトのパス>

オプションの詳細については、従来と同様 --help オプションで表示される。

ライブラリオブジェクトのコンパイル

以下のコマンドを実行する。

$ docker exec $(docker ps -q -f name=kompira) manage.py compile_library [options...] <ライブラリオブジェクトのパス>

オプションの詳細については、従来と同様 --help オプションで表示される。

チャネルオブジェクトの操作

チャネルオブジェクトのメッセージを見る

以下のコマンドを実行する。

$ docker exec $(docker ps -q -f name=kompira) manage.py peek_channel [options...] <チャネルオブジェクトのパス>

オプションの詳細については、従来と同様 --help オプションで表示される。

チャネルオブジェクトからメッセージを取り出す

以下のコマンドを実行する。

$ docker exec $(docker ps -q -f name=kompira) manage.py pop_channel [options...] <チャネルオブジェクトのパス>

オプションの詳細については、従来と同様 --help オプションで表示される。

プロセスオブジェクト管理

manage.py process 管理コマンドを用いて、Kompira プロセスオブジェクトに対して以下のような操作を行なうことができます。

• プロセスの一覧表示
• プロセスの個数表示
• プロセスの削除
• プロセスの中止
• プロセスの停止
• プロセスの続行

このとき、操作の対象とするプロセスを絞り込む条件を指定することができます。

• プロセスの状態
• 実行しているジョブフロー
• スケジュール起動のプロセスかどうか
• 起動オブジェクトが指定されたプロセスかどうか
• 実行したユーザ
• 開始日時および終了日時
• 実行時間
• コンソール出力に含まれる文字列

process 管理コマンドの実行

process 管理コマンドは以下のように kompira コンテナで実行してください。

$ docker exec $(docker ps -q -f name=kompira) manage.py process [options...]

プロセス操作オプション

Kompira プロセスに対して行う操作を指定するオプションを以下に示します。

操作を指定するオプションはいずれか1つのみ指定可能で、複数指定した場合は最後のオプションが適用されます。 上記のいずれも指定しなかった場合は、プロセスの一覧表示を行ないます。

大量のプロセスが処理対象となるような場合に、メモリや CPU などのリソース負荷が大きくなる場合がありますのでご注意ください。

プロセス情報の変更を伴う操作（削除、中止、停止、続行）が指定された場合は、実際に制御を適用するかの確認（yes/no の入力）が行なわれます。 制御前の確認を行なわずに適用したい場合は -y オプションを指定してください。制御を適用せずに動作を確認したい場合は --dry-run オプションを指定してください。

プロセス絞り込みオプション

操作対象とする Kompira プロセスを絞り込む条件を指定するオプションを以下に示します。

• 複数指定可能な絞り込みオプションを複数回指定した場合は、それらを OR 条件として絞り込みます。
• 異なる種類の絞り込みオプションを複数指定した場合は、それらを AND 条件として絞り込みます。
• オプションの日時はジョブフローの datetime() 組み込み関数が認識できる形式で指定できます。

その他のオプション

バックアップとリストア

【1.6】バックアップ

Kompiraの全てのデータをバックアップするための手順について説明します。

Kompiraはデータベース上以外に、サーバ上の :ref:file_hierarchy に挙げられているパスのデータを使用します。 Kompiraのデータをバックアップする際は、export_dataコマンドによるKompiraオブジェクトのバックアップに 加えて、必要に応じてサーバ上のファイルバックアップも行う必要があります。

Kompiraオブジェクトとライセンスファイルのバックアップを行う場合の例を以下に示します。

$ mkdir -p /tmp/kompira_backup
$ cd /tmp/kompira_backup
$ /opt/kompira/bin/manage.py export_data / --virtual-mode > backup.json
$ cp /var/opt/kompira/kompira.lic ./
$ cd /tmp
$ tar zcf kompira_backup.tar.gz ./kompira_backup

アカウント管理

ここではアカウント管理について示します。

• アカウントロックの解除

アカウントロック

アカウントがロックされるとロックされたユーザの情報表示画面の下部に警告メッセージとともにアクセス元のIPアドレスの一覧が表示されます。 ユーザの情報表示画面に表示されるロック解除ボタンを押すことで、当該ユーザのアカウントロックを解除することができます。

また、管理コマンドを用いることで履歴の確認やロックの解除を行なうこともできます。

アカウントロックの履歴表示

axes_list_attempts 管理コマンドを実行するとログインに失敗した履歴の一覧が表示されます。

docker exec $(docker ps -q -f name=kompira) manage.py axes_list_attempts

なお、ロックを解除すると該当する履歴は削除されます。

アカウントロックの解除

以下の管理コマンドを実行してロック解除することができます。

axes_reset 管理コマンドで全てのアカウントロックを一斉に削除します。

docker exec $(docker ps -q -f name=kompira) manage.py axes_reset

axes_reset_ip 管理コマンドは指定した IP アドレスからのアカウントロックを解除します。

docker exec $(docker ps -q -f name=kompira) manage.py axes_reset_ip [ip ...]

axes_reset_username 管理コマンドは指定したユーザのアカウントロックを解除します。

docker exec $(docker ps -q -f name=kompira) manage.py axes_reset_username [username ...]

ログ管理

コンテナログ管理

各コンテナのメインのログは docker 標準のロギング機構によって、コンテナごとにホスト上のボリューム内に記録されます。

動作中コンテナのログの確認

docker により記録されているコンテナごとのログは docker logs コマンドで確認することができます。 たとえば動作中の kengine コンテナのログは以下のようにコマンドを実行するとコンソールに表示されます。

$ docker logs $(docker ps -q -f name=kengine) 

コンテナの標準出力と標準エラー出力はそれぞれ記録されていて、docker logs コマンドではその出力が再現されます。 less コマンドなどで両方のログ出力を確認したい場合は、標準エラー出力を標準出力にリダイレクトして出力させると確認しやすくなります。

$ docker logs $(docker ps -q -f name=kengine) 2>&1 | less -RS

ログの分量が多いようなときに、最新 N 行分のログだけ確認したい場合は -n オプションで取得する行数を指定できます。

$ docker logs $(docker ps -q -f name=kengine) -n 10

動作中コンテナのログ出力を継続的に確認したい場合は、-f オプションをつけて実行してみてください。

$ docker logs $(docker ps -q -f name=kengine) -n 10 -f
...
...
※ CTRL+C で中止できます

タイムスタンプを指定することで、過去の特定時間帯のログを取得することができます。

# [特定のノード] docker logs 091f0c3802a2 --since <timestamp> --until <timestamp>
# --since: Show logs since timestamp (e.g. "2013-01-02T13:23:37Z") or relative (e.g. "42m" for 42 minutes)
# --until: Show logs before a timestamp (e.g. "2013-01-02T13:23:37Z") or relative (e.g. "42m" for 42 minutes)

$ docker logs 091f0c3802a2 --since 10m --until 5m

停止中コンテナのログの確認

停止中のコンテナのログを確認したい場合は、docker ps コマンドではコンテナ ID が取得できないので、別の手法を用いる必要があります。

別の方法としては例えば docker container ls -a コマンドで、停止中のコンテナも含めてその一覧を得る方法があります。

$ docker container ls -a -f name=kengine
CONTAINER ID   IMAGE                                 COMMAND                   CREATED         STATUS                          PORTS     NAMES
31fc2ccc0c5f   kompira-enterprise:2.0.0b1_31f7c1f2   "docker-entrypoint.s…"   2 minutes ago   Exited (0) About a minute ago             ke2-kengine-1

これを利用すれば停止中のコンテナのログを確認することもできます。

$ docker logs $(docker container ls -a -q -f name=kengine)

なお、コンテナが削除されるとログも削除されて確認できなくなるので注意してください。 コンテナの状態に関わらずログを確認できるようにしたい場合は、ログを docker 外部で記録することを検討してください。

コンテナログの一括取得

すべてのコンテナの最近の一定期間分のログを取得してファイルに書き出したいという場合は、例えば以下のように docker container コマンドの結果をもとにコンテナごとに docker logs コマンドでログを取得してファイルに出力してください。

$ docker container ls -a --format '{{.ID}} {{.Names}}' | while read id name; do docker logs --since "24h" --timestamps $id 2>&1 | gzip > "${name%.*}-${id}.log.gz"; done

この例では docker container ls コマンドに -a オプションを付けることで停止中のコンテナも対象にしています。また、docker logs コマンドに --since オプションで最近 24 時間分のログを取得対象にしているのと、--timestamps オプションでタイムスタンプを出力するようにしています。取得したログは gzip コマンドで圧縮して、{コンテナ名}-{ID}.log.gz というファイル名で書き出しています。

これを実行すると、例えば以下のように複数の圧縮ログファイルが得られます。

$ ls -l *.log.gz
-rw-r--r--. 1 root root   887 Aug  1 10:22 ke2_jobmngrd.2-34f59028949c.log.gz
-rw-r--r--. 1 root root  1558 Aug  1 10:22 ke2_kengine.2-188b800bdd72.log.gz
-rw-r--r--. 1 root root  1554 Aug  1 10:22 ke2_kengine.2-d84d727936cf.log.gz
-rw-r--r--. 1 root root  1561 Aug  1 10:22 ke2_kengine.2-eb46166069dc.log.gz
-rw-r--r--. 1 root root  1770 Aug  1 10:22 ke2_kengine.2-f5e6171597bd.log.gz
-rw-r--r--. 1 root root  1555 Aug  1 10:22 ke2_kengine.2-f7af3854014b.log.gz
-rw-r--r--. 1 root root 10798 Aug  1 10:22 ke2_kompira.1-01971df8db91.log.gz
-rw-r--r--. 1 root root  3655 Aug  1 10:22 ke2_nginx.1-6b9aa454d7d6.log.gz
-rw-r--r--. 1 root root  7815 Aug  1 10:22 ke2_rabbitmq.1-2704436f57df.log.gz

※ コンテナ名の部分はシステム構成によって変わります。また、kompira 以外のコンテナを動作させている場合は、そのログも出力されることに注意してください。

サービスログ管理

Docker Swarm クラスタ構成では docker service logs コマンドを用いることで、全てのノードからサービス単位（同じコンテナの集まり）のログをまとめて確認することができます。

$ docker service logs [OPTIONS] サービス名

このときサービス名を指定する必要がありますが、以下のコマンドでサービス名の一覧を確認することができます。

# コマンド形式: [いずれかのホスト]$ docker service ls --format "{{.Name}}"

$ docker service ls --format "{{.Name}}"
ke2_jobmngrd
ke2_kengine
ke2_kompira
ke2_nginx
ke2_rabbitmq
ke2_redis

サービスのログ表示コマンドの使い方についてはマニュアルを参照してください。

$ man docker-service-logs

以下では、よくある使い方をいくつか紹介します。

最新 N 行分のログ確認

サービス名を指定すると全てのノードのログを取得できますが、分量が多すぎる場合があります。 最新のいくつかのログだけ確認したい場合は、-n オプションで各ノードから取得する行数を指定することができます。

# コマンド形式: [いずれかのホスト]$ docker service logs <サービス名> -n <行数>
# <サービス名> : 対象のサービス名
# <行数>: 取得したい最新のログの行数

$ docker service logs ke2_rabbitmq -n 5
ke2_rabbitmq.2.b609jwku5xyf@ke2-rhel89-swarm-3    | 2024-10-10 08:53:47.285515+09:00 [notice] <0.86.0>     alarm_handler: {set,{system_memory_high_watermark,[]}}
ke2_rabbitmq.1.5p18r2gjy2go@ke2-rhel89-swarm-2    | 2024-10-08 15:50:27.468114+09:00 [info] <0.369961.0> closing AMQP connection <0.369961.0> (10.0.1.24:37178 -> 10.0.1.9:5672, vhost: '/', user: 'guest')
ke2_rabbitmq.1.5p18r2gjy2go@ke2-rhel89-swarm-1    | 2024-10-08 15:50:39.421148+09:00 [info] <0.370010.0> accepting AMQP connection <0.370010.0> (10.0.1.24:57152 -> 10.0.1.9:5672)
ke2_rabbitmq.1.5p18r2gjy2go@ke2-rhel89-swarm-2    | 2024-10-08 15:50:39.466520+09:00 [info] <0.370010.0> closing AMQP connection <0.370010.0> (10.0.1.24:57152 -> 10.0.1.9:5672, vhost: '/', user: 'guest')
ke2_rabbitmq.2.b609jwku5xyf@ke2-rhel89-swarm-3    | 2024-10-10 08:57:47.297798+09:00 [notice] <0.86.0>     alarm_handler: {clear,system_memory_high_watermark}
ke2_rabbitmq.2.b609jwku5xyf@ke2-rhel89-swarm-3    | 2024-10-10 08:59:47.304665+09:00 [notice] <0.86.0>     alarm_handler: {set,{system_memory_high_watermark,[]}}

継続したログ確認

動作中のサービスのログを継続的に確認したい場合は、-f オプションを指定してみてください。

# [いずれかのホスト]$ docker service logs <サービス名> -n <行数> -f
# 例： docker service logs ke2_rabbitmq -f
# 例： docker service logs ke2_rabbitmq -n 10 -f

$ docker service logs ke2_rabbitmq -n 5 -f
ke2_rabbitmq.2.b609jwku5xyf@ke2-rhel89-swarm-3    | 2024-10-10 08:53:47.285515+09:00 [notice] <0.86.0>     alarm_handler: {set,{system_memory_high_watermark,[]}}
ke2_rabbitmq.1.5p18r2gjy2go@ke2-rhel89-swarm-2    | 2024-10-08 15:50:27.468114+09:00 [info] <0.369961.0> closing AMQP connection <0.369961.0> (10.0.1.24:37178 -> 10.0.1.9:5672, vhost: '/', user: 'guest')
ke2_rabbitmq.1.5p18r2gjy2go@ke2-rhel89-swarm-1    | 2024-10-08 15:50:39.421148+09:00 [info] <0.370010.0> accepting AMQP connection <0.370010.0> (10.0.1.24:57152 -> 10.0.1.9:5672)
ke2_rabbitmq.1.5p18r2gjy2go@ke2-rhel89-swarm-2    | 2024-10-08 15:50:39.466520+09:00 [info] <0.370010.0> closing AMQP connection <0.370010.0> (10.0.1.24:57152 -> 10.0.1.9:5672, vhost: '/', user: 'guest')
ke2_rabbitmq.2.b609jwku5xyf@ke2-rhel89-swarm-3    | 2024-10-10 08:57:47.297798+09:00 [notice] <0.86.0>     alarm_handler: {clear,system_memory_high_watermark}
ke2_rabbitmq.2.b609jwku5xyf@ke2-rhel89-swarm-3    | 2024-10-10 08:59:47.304665+09:00 [notice] <0.86.0>     alarm_handler: {set,{system_memory_high_watermark,[]}}
.....
.....
.....

※ CTRL+C で中止できます

タイムスタンプを指定したログ確認

過去の特定時間帯のログを確認したい場合は、タイムスタンプを指定してログを取得することもできます。

# [いずれかのホスト]$ docker service logs <サービス名> --since <timestamp>
# <timestamp>: Show logs since timestamp (e.g. "2013-01-02T13:23:37Z") or relative (e.g. "42m" for 42 minutes)

$ docker service logs ke2_kengine --since 1m
ke2_kengine.1.md96z16qsvx2@ke2-rhel89-swarm-2    | [2024-10-10 10:46:00,005:ke-ke2-rhel89-swarm-2:kompirad:ThreadPoolExecutor-1_1] INFO: [Engine-4705] scheduled job 'プロセス生死監視' starting ...
ke2_kengine.1.md96z16qsvx2@ke2-rhel89-swarm-2    | [2024-10-10 10:46:00,015:ke-ke2-rhel89-swarm-2:Executor-0:ActorHandler] INFO: [Executor-0] execute jobflow "/user/app/AlertAutomatic/Definitions/Jobflows/SystemCtrl/MonitoringProcess" by user "root"
ke2_kengine.1.md96z16qsvx2@ke2-rhel89-swarm-2    | [2024-10-10 10:46:00,028:ke-ke2-rhel89-swarm-2:Executor-0:ActorHandler] INFO: Process(90175).start: started /user/app/AlertAutomatic/Definitions/Jobflows/SystemCtrl/MonitoringProcess (invoker=None)
ke2_kengine.1.md96z16qsvx2@ke2-rhel89-swarm-2    | [2024-10-10 10:46:00,931:ke-ke2-rhel89-swarm-2:Executor-0:MainThread] INFO: Process(90175).done: finished /user/app/AlertAutomatic/Definitions/Jobflows/SystemCtrl/MonitoringProcess [DONE] elapsed=0:00:00.902761
ke2_kengine.1.md96z16qsvx2@ke2-rhel89-swarm-2    | [2024-10-10 10:46:00,947:ke-ke2-rhel89-swarm-2:Executor-0:MainThread] WARNING: /process/id_90175.monitor: could not send mail: recipient email is not specified

ボリュームログ管理

docker はボリュームという機能でホストとコンテナ間でファイルを共有することができます。 KE2.0 ではこれを利用して、一部のコンテナでログをボリュームに記録している場合があります。

プロセスログおよび監査ログの記録場所

シングル構成ではプロセスログおよび監査ログは docker の kompira_log ボリュームに記録されます。

docker ボリュームがホスト上のどこに配置されているかは、docker volume ls コマンドで知ることができます。 例えば以下のようにコマンドを実行することで kompira_log のサーバ上での場所が分かります。

$ docker volume ls -f name=kompira_log --format="{{.Mountpoint}}"
/var/lib/docker/volumes/ke2_kompira_log/_data

docker volume コマンドで表示されたディレクトリを確認すると、プロセスログおよび監査ログが記録されているはずです。

$ sudo ls -l /var/lib/docker/volumes/ke2_kompira_log/_data
合計 4
-rw-r--r--. 1 root root    0  7月 24 11:44 audit-ap-ke2-server1.log
-rw-r--r--. 1 root root 3668  7月 24 11:44 audit-ke-ke2-server1.log
-rw-r--r--. 1 root root    0  7月 24 11:44 process-ke-ke2-server1-0.log
-rw-r--r--. 1 root root    0  7月 24 11:44 process-ke-ke2-server1-1.log

ただし、デプロイ時に環境変数 KOMPIRA_LOG_DIR でログの出力先を指定している場合は、kompira_log ボリュームではなく指定したディレクトリに記録されます。

また、Swarm クラスタ構成では setup_stack.sh 実行時に指定した共有ディレクトリ (SHARED_DIR) 配下の $SHARED_DIR/log がデフォルトの KOMPIRA_LOG_DIR となり、そこにログが記録されます。

プロセスログ管理

ジョブフロー実行時のプロセスログは、kengine コンテナが直接ログファイルとして記録を行なっています。

プロセスログは Docker のデフォルトでは kompira_log ボリュームに記録されます。 または、デプロイ時に環境変数 KOMPIRA_LOG_DIR が指定されていれば、ホスト上のそのディレクトリに記録されます。

作成されるログファイル名は以下のようになります。

proces-${CONTAINERNAME}-${EXECUTORID}.log

• ${CONTAINERNAME} の部分はログを記録するコンテナの名称に展開されます。
• ${EXECUTORID} の部分は kengine 内部で動作しているエグゼキュータの ID に展開されます。

kompira_log ボリュームに記録されたプロセスログファイルの確認方法については、ボリュームログ管理 を参照してください。

監査ログ管理

ユーザが Kompira に対して各種操作をしたときに、その操作の種類や、認可されたかどうか、また成功したかどうか、といった情報をログに記録します。

実際に記録される監査ログファイルの仕様については 監査ログファイル を参照してください。

監査ログの対象となる操作

ブラウザでの操作や API を用いた連携操作、サーバ上の管理コマンドによる操作などが監査ログの記録対象となります。

一方で、以下については、監査ログの記録対象となりません。

• ジョブフロー動作によるデータ操作やプロセス操作
• Kompira システム外部での操作（DB管理コマンドを用いた直接的なデータ操作など）
• static コンテンツへのアクセス

操作レベルと記録レベル

ある記録対象の操作が監査ログに実際に記録されるかどうかは、その操作の種類や結果から算出される「操作レベル値」と、設定項目である「記録レベル値」によって決まります。算出された操作レベル値が設定項目の記録レベル値以上のとき、監査ログに当該エントリが出力されます。

監査ログの記録条件： 操作レベル値 ≧ 記録レベル値

操作レベル値は操作における複数の項目から算出します。いくつかの項目ごとに設定された操作レベルの基準値が決まり、その最大値が最終的な操作レベル値となります。通常この値は 1 から 3 の間の数値となります。各項目の操作レベル基準値のデフォルトについては 監査ログの項目詳細 を参照してください。

たとえば、「ブラウザ上で既存のジョブフローオブジェクトを編集した（許可され、成功した）」という場合、以下のような項目ごとの操作レベル基準値が適用されて、最終的な操作レベル値は 2 となります。

記録レベル値のデフォルトは 2 です。詳細については 監査ログの設定 を参照してください。

監査ログファイル

ここでは監査ログファイルの仕様について示します。

監査ログの記録先

ke2-docker パッケージで KE2.0 システムを構築する場合、監査ログファイルは Docker の kompira_log ボリュームに記録されます。 または、デプロイ時に環境変数 KOMPIRA_LOG_DIR が指定されていれば、ホスト上のそのディレクトリに記録されます。

作成されるログファイル名は以下のようになります。

audit-${CONTAINERNAME}.log

• ${CONTAINERNAME} の部分はログを記録するコンテナの名称に展開されます。

kompira_log ボリュームに記録された監査ログファイルの確認方法については、ボリュームログ管理 を参照してください。

監査ログのファイル形式

監査ログは UTF-8 でエンコードされたテキストファイルで、1エントリを1行の JSON 形式で出力します。

監査ログの記録項目

監査ログのサンプル

以下にブラウザで操作したときの監査ログファイル /var/log/kompira/audit-apache.log のサンプルを示します。ログは1エントリ1行で出力されていますが、ここでは分かりやすく整形して表示しています。

{
    "level": 3,
    "started": "2021-10-05T15:51:31.403016+09:00",
    "finished": "2021-10-05T15:51:31.452097+09:00",
    "exec": {
    "pid": 1286192,
    "name": "/usr/sbin/httpd",
    "user": "apache",
    "remote": "10.10.0.110"
    },
    "user": "root",
    "interface": "web",
    "class": "session",
    "target_path": null,
    "target_type": null,
    "type": "login",
    "permit": "allowed",
    "result": "succeeded",
    "reason": null,
    "detail": {
    "next_page": "/"
    }
}
{
    "level": 2,
    "started": "2021-10-05T15:51:43.447941+09:00",
    "finished": "2021-10-05T15:51:43.486984+09:00",
    "exec": {
    "pid": 1285426,
    "name": "/usr/sbin/httpd",
    "user": "apache",
    "remote": "10.10.0.110"
    },
    "user": "root",
    "interface": "web",
    "class": "object",
    "target_path": "/config/license",
    "target_type": "/system/types/License",
    "type": "read",
    "permit": "allowed",
    "result": "succeeded",
    "reason": null,
    "detail": {
    "http_method": "GET",
    "http_status": 200
    }
}

監査ログの項目詳細

ここでは、監査ログに記録される項目についての詳細を示します。 以下の節におけるテーブルで「操作レベル」は、操作レベル基準値のデフォルトを示しています。

操作レベル (level)

操作の内容や結果によって算出された操作レベルを数値で示します。この操作レベル値が設定項目の記録レベル値以上のとき、監査ログに当該エントリが出力されます。

操作日時 (started, finished)

項目 started は操作の開始日時を、項目 finished は操作の終了日時を示します。 これらは以下のように、ローカルタイムで ISO8601 形式で記録されます。

"2021-10-01T11:45:08.977356+09:00"

操作元情報 (exec)

操作元を示す辞書には以下のような情報が記録されます。

操作ユーザ (user)

操作を行った Kompira ユーザ名を記録します。ブラウザ上で Kompira にログインして操作をした場合は、そのログインユーザ名となります。サーバのコンソール上で管理コマンドによる操作を行なった場合などでは、Kompira の認証を伴っていないため空文字列になります。

操作方式 (interface)

どのような方式を用いて操作したのかの区分を記録します。

操作分類 (class)

何を操作したのか、その分類を示します。

操作対象 (target_path, target_type)

何を操作したのか、その具体的な対象を示します。

操作分類が session 以外のときは、操作対象をそのパスで識別することができます。以下のようにパスを項目 target_path として記録します。

"/system/user/id_1"

さらに、オブジェクト操作の場合では、その型オブジェクトのパスを項目 target_type に記録します。

"/system/types/Directory"

操作種別 (type)

どのような操作をしたのかという種類を記録します。

いくつかの操作種別は特定の操作分類でのみ利用されます。たとえばログインやログアウトは操作分類が session のときだけです。

ある操作種別が複数の操作分類で利用される場合はありますが、操作分類ごとに異なる操作レベル基準値を設定することはできません。

操作の結果 (permit, result)

操作の結果としてその認否と成否が記録されます。

項目 permit は操作が許可されたかどうかを示します。例えばオブジェクト操作では設定されたパーミッションによって、操作が許可されたり拒否されたりします。

項目 result は操作に成功したかどうかを示します。

詳細情報 (detail)

操作ごとに追加の詳細情報を辞書形式で記録します。

※ 詳細情報については、監査ログ機能がリリースされた後も仕様が調整される可能性がありますのでご注意ください。

ログイン

REST-API

エクスポート

インポート

オブジェクトの検索

オブジェクトの新規作成

ジョブフローやスクリプトジョブの実行

オブジェクトの名称変更

オブジェクトのコピー

オブジェクトの移動

オブジェクトの削除

チャネルへのメッセージ送信

管理コマンド: compile_jobflow / compile_library

管理コマンド: license_info / license_update

管理コマンド: process

その他の詳細情報

セキュリティ管理

• SSL証明書の管理
• 暗号化秘密鍵の管理

SSL 証明書管理

KE 2.0 システムでは HTTPS 接続および AMQPS 接続を行なうために、SSL 証明書が必要になります。 ke2-docker パッケージのデプロイ手順では、自己署名 SSL 証明書を作成しています。

SSL 証明書ファイルの作成

ke2-docker パッケージに付属の create-cert.sh スクリプトを実行すると、ssl ディレクトリに以下のファイルが生成されます。

• local-ca.crt: 作成する SSL 証明書に署名する CA 証明書
• local-ca.key: local-ca.crt の秘密鍵ファイル
• local-ca.srl: local-ca.crt で発行済みシリアル番号を保存するファイル
• server.crt: nginx/rabbitmq コンテナが利用するサーバ SSL 証明書（local-ca.crt によって署名されています）
• server.csr: server.crt を生成する時の CSR ファイル
• server.ext: server.crt に設定する拡張情報ファイル
• server.key: server.crt の秘密鍵ファイル

サーバ証明書 server.crt には create-cert.sh スクリプトを実行したホストのホスト名を元にサブジェクトが設定されます。

各コンテナでの SSL 証明書の適用

ke2-docker でデプロイした各コンテナでは、作成した SSL 証明書を適用するための設定を行なっています。

nginx コンテナ

nginx コンテナでは、SSL 証明書を利用した HTTPS 接続ができるように、以下のような設定を行なっています。

• SSL証明書ファイル一式を nginx コンテナの /etc/nginx/ssl ディレクトリにバインドするようにしています。
• /etc/nginx/ssl に配置された SSL 証明書を利用するように、ke2-docker 付属の nginx.conf で設定しています。

rabbitmq コンテナ

rabbitmq コンテナでは、SSL 証明書を利用した AMQPS 接続ができるように、以下のような設定を行なっています。

• SSL証明書ファイル一式を rabbitmq コンテナの /etc/rabbitmq/ssl ディレクトリにコピーするようにしています。
• /etc/rabbitmq/ssl に配置された SSL 証明書を利用するように、ke2-docker 付属の rabbitmq-ssl.conf で設定しています。
• rabbitmq-server で SSL 証明書による認証ができるように rabbitmq_auth_mechanism_ssl プラグインを有効化しています。

正式な SSL 証明書の適用方法

(WIP)

暗号化秘密鍵の管理

パスワードフィールドの暗号化には暗号化秘密鍵が必要になります。 この暗号化秘密鍵はシステムの初回起動時にランダムに自動生成されて秘密鍵ファイルに記録されています。

ここでは、この秘密鍵の管理手順について示します。

秘密鍵の変更

パスワードフィールドの暗号化に使用する秘密鍵を変更するには、管理コマンド manage.py change_secretkey を実行したあとに、kompira および kengine コンテナを再起動します。

注意: 秘密鍵を変更した後は kompira および kengine コンテナを再起動する必要があります。そのため、実行中のジョブフローがある場合は全て異常終了することに注意してください。可能であれば実行中のジョブフローが存在しないときに実施するようにしてください。

change_secretkey の実行

change_secretkey を実行すると、データベースに暗号化されて保存されている全てのパスワードデータを、新しい秘密鍵で再暗号化して保存し直します。

change_secretkey コマンドの形式は以下の通りです。新しい秘密鍵は文字列で <new_secretkey> の部分に指定してください。

$ docker exec $(docker ps -q -f name=kompira) manage.py change_secretkey [options...] <new_secretkey>

change_secretkey コマンドには以下のオプションがあります。

注釈: 秘密鍵の文字列はコンテナから見える /var/opt/kompira/.secret_key に保存されますが、ホスト上では構成によって異なるパスに存在することになります。

秘密鍵変更後のコンテナ再起動

秘密鍵を変更した後は、kompira および kengine コンテナを再起動してください。 この手順を実行すると kengine コンテナが再起動するため、実行中のジョブフローは全て異常終了することに注意してください。

シングル構成の場合

シングル構成においては、以下の手順で kompira, kengine コンテナを再起動してください。

$ docker restart $(docker ps -q -f name=kompira -f name=kengine)

クラスタ構成の場合

Swarm クラスタ構成においては、いずれかの Swarm マネージャノード上で、以下の手順で全ノードの kompira, kengine コンテナを再起動してください。

[ke2-server1]$ docker service update --force ke2_kompira
[ke2-server1]$ docker service update --force ke2_kengine

システムパッケージ管理

Kompira 環境にインストールされている Python や Web 用のパッケージの情報が以下で閲覧できます。 各パッケージ種別ごとにインストールされているパッケージのバージョンやライセンスに関する情報を確認することができます。

注釈: システムパッケージ情報は Kompira をインストールまたはアップデートした後に kompirad が起動したタイミングで自動的に収集および更新されます。

パッケージ情報の管理

Kompira サーバ上で以下のコマンドを利用することでパッケージ情報を管理することができます。

$ docker exec $(docker ps -q -f name=kompira) manage.py packages_info [options...]

パッケージ情報の表示

オプションを省略または --show オプションを指定した場合、すでに収集されているパッケージ情報をコンソールに一覧表示します。

$ docker exec $(docker ps -q -f name=kompira) manage.py packages_info --show

パッケージ情報の一覧表示の例を以下に示します。

+------+----------------------+-----------+----------+-----------------+
| Type | Name                 | Installed | Latest   | License         |
+------+----------------------+-----------+----------+-----------------+
| pip  | AMQPStorm            | 2.10.8    | None     | MIT License     |
| pip  | APScheduler          | 3.10.4    | None     | MIT License     |
| pip  | Creoleparser         | 0.7.5     | None     | MIT License     |
| pip  | Django               | 4.2.14    | 5.0.7    | BSD License     |
| pip  | Genshi               | 0.7.9     | None     | BSD License     |
| pip  | GitPython            | 3.1.43    | None     | BSD License     |
| pip  | Jinja2               | 3.1.4     | None     | BSD License     |
    :         :                    :           :            :

パッケージ情報の収集

--collect オプションを指定した場合、インストールされているパッケージ情報を収集します。

$ docker exec $(docker ps -q -f name=kompira) manage.py packages_info --collect

このとき、各パッケージの最新バージョン情報を収集するためにインターネット接続が必要になります。 プロキシ接続が必要な場合は --proxy オプション（または https_proxy 環境変数）で指定してください。

インターネットに接続できないなど、最新バージョン情報の収集を行わない場合は --no-collect-latest オプションを追加で指定してください。 あるいは、明示的に最新バージョン情報の収集を行なうことを指定したい場合は --collect-latest オプションを追加で指定してください。

注釈: なお、収集されたパッケージ情報はコンテナ上の /var/opt/kompira/packages/ 配下に保存されます。

パッケージ情報の更新

--update オプションを指定した場合、収集済みパッケージ情報をもとに Kompira 上のシステムパッケージ情報オブジェクト（Wiki 型）を更新します。

$ docker exec $(docker ps -q -f name=kompira) manage.py packages_info --update

--update オプションと --collect オプションを併用した場合は、パッケージ情報の収集に続けてシステムパッケージ情報オブジェクトの更新を行ないます。

Python パッケージ管理

Python パッケージ (pip)のインストール先

KE2.0 では Python パッケージの参照先が、各コンテナで個別な場所と kompira および kengine コンテナ間で共有する場所があります。

• コンテナ個別: /usr/local/lib/python3.11/site-packages/
• コンテナ共有: /var/opt/kompira/lib/python3.11/site-packages/

ユーザーが作成するライブラリオブジェクトから参照する Python パッケージを追加する場合は、コンテナ共有な場所に配置する必要があります。 kompira コンテナの pip コマンドでインストールすると、デフォルトでコンテナ共有な場所にインストールするように構成しています。

docker exec $(docker ps -q -f name=kompira) pip install some-package

コンテナ共有ディレクトリは、kompira と kengine コンテナの両方から共有されているボリューム上にあるため、同じパッケージを両コンテナにインストールする必要はありません。

KE2.0 コンテナイメージでは、あらかじめ /usr/local/lib/python3.11/site-packages/.pth ファイルを作成してあり、そのファイルで上記パスを参照するように指定しています。

保守ガイド

ここに保守ガイドを書きます。

シングル構成の保守

以後の節では、シングル構成を保守する手順などについて示します。

各手順では共通的な準備やオプションの指定方法がありますので、以下を参考にしてください。

docker compose ファイルの指定

以後の説明ではシステム構築に用いた docker-compose.yml ファイルがあるディレクトリで docker compose コマンドを実行する前提になっています。 別のディレクトリで docker compose コマンドを実行する場合、または docker-compose.yml 以外の docker compose ファイルでシステムを構築している場合は、各 docker compose コマンドに -f <docker compose ファイル> オプションを付けて実行するようにしてください。

例:

$ docker compose -f /foo/bar/docker-compose-custom.yml start

システムの起動

シングル構成の起動および停止の手順について示します。

システムの起動手順

システム構築に用いた docker-compose.yml ファイルがあるディレクトリで、以下のコマンドを実行します。

$ docker compose start

なお、初回起動時には docker compose start ではなく docker compose up -d コマンドを実行しますが、これは各構成の構築手順で実施済みである前提です。

また、docker-compose.yml に restart: always という設定がある場合は、サーバ起動時に自動起動するようになっています。

全体のステータスを確認

VM 上の Docker で各コンテナが正常に動作しているか確認してください。

• ブラウザで /.status 画面を開いて全てのコンテナが正常を示している（赤い表示になっていない）ことを確認してください。
• ブラウザで Kompira にログインできることを確認してください。
• 自動起動または自動再起動するジョブフローが存在する場合は、期待通りにプロセスが開始しているかを確認してください。

システムの停止

シングル構成の停止の手順について示します。

システムの停止手順

システム構築に用いた docker-compose.yml ファイルがあるディレクトリで、以下のコマンドを実行します。

$ docker compose stop

システムの削除

シングル構成のシステムを削除する手順について示します。

コンテナの削除

以下のコマンドを実行すると、システムが停止するとともにすべてのコンテナが削除されます。

$ docker compose down

この状態ではデータ領域となるボリュームは残っていますので、再び docker compose up -d コマンドでシステムを開始すると、以前のデータにアクセスすることができます。

コンテナとボリュームの削除

以下のように -v オプションを指定して down した場合は、コンテナだけでなくボリュームも削除されます。

$ docker compose down -v

この場合は、以前のデータにアクセスすることは出来なくなりますので注意してください。

外部DBシングル構成の保守

以後の節では、シングル構成を保守する手順などについて示します。

各手順では共通的な準備やオプションの指定方法がありますので、以下を参考にしてください。

docker compose ファイルの指定

以後の説明ではシステム構築に用いた docker-compose.yml ファイルがあるディレクトリで docker compose コマンドを実行する前提になっています。 別のディレクトリで docker compose コマンドを実行する場合、または docker-compose.yml 以外の docker compose ファイルでシステムを構築している場合は、各 docker compose コマンドに -f <docker compose ファイル> オプションを付けて実行するようにしてください。

例:

$ docker compose -f /foo/bar/docker-compose-custom.yml start

システムの起動

外部DBシングル構成の起動および停止の手順について示します。

システムの起動手順

システム構築に用いた docker-compose.yml ファイルがあるディレクトリで、以下のコマンドを実行します。

$ docker compose start

なお、初回起動時には docker compose start ではなく docker compose up -d コマンドを実行しますが、これは各構成の構築手順で実施済みである前提です。

また、docker-compose.yml に restart: always という設定がある場合は、サーバ起動時に自動起動するようになっています。

全体のステータスを確認

VM 上の Docker で各コンテナが正常に動作しているか確認してください。

• ブラウザで /.status 画面を開いて全てのコンテナが正常を示している（赤い表示になっていない）ことを確認してください。
• ブラウザで Kompira にログインできることを確認してください。
• 自動起動または自動再起動するジョブフローが存在する場合は、期待通りにプロセスが開始しているかを確認してください。

システムの停止

シングル構成の停止の手順について示します。

システムの停止手順

システム構築に用いた docker-compose.yml ファイルがあるディレクトリで、以下のコマンドを実行します。

$ docker compose stop

システムの削除

シングル構成のシステムを削除する手順について示します。

コンテナの削除

以下のコマンドを実行すると、システムが停止するとともにすべてのコンテナが削除されます。

$ docker compose down

この状態ではデータ領域となるボリュームは残っていますので、再び docker compose up -d コマンドでシステムを開始すると、以前のデータにアクセスすることができます。

コンテナとボリュームの削除

以下のように -v オプションを指定して down した場合は、コンテナだけでなくボリュームも削除されます。

$ docker compose down -v

この場合は、以前のデータにアクセスすることは出来なくなりますので注意してください。

クラスタ構成の保守

以後の節では、クラスタ構成を保守する手順などについて示します。

• クラスタの停止
• クラスタの開始
• ノードの停止
• ノードの起動
• コンテナの移動
• システムの削除

クラスタの停止

クラスタ構成のシステム全体を停止させる場合の手順を示します。

注意事項

システム全体を停止する手順を実行すると以下のような影響があります。

• 実行中のジョブフローはすべて異常終了になります。自動再起動が有効なプロセスについては、システム全体を再開させた時に自動的に再起動します。

  補足: 実行中のジョブフロープロセスに自動再起動が有効と設定されている場合、そのプロセスを実行中の kengine が動作しているノードを停止すると、別の動作中のノードで同じジョブフローを自動的に再起動するという動きをとります。そのため、システム全体を停止する手順としてノードを順番に停止させていく過程で、1台の停止ごとに時間があくと、ジョブフロープロセスの強制終了と自動再起動が短時間に繰り返される場合があることに注意してください。そうした振る舞いが好ましくない場合は、クラスタを停止させる前に、当該ジョブフロープロセスを手動で中止しておいてください。手動で中止したプロセスは自動再起動の対象外となります。ただし、システム全体を再開させた場合の自動的な再起動も行われませんので、必要に応じて手動で起動するようにしてください。

• 停止期間中に実行予定となっていたスケジュールは（再起動後も）実行されません。

3台構成のクラスタでは2台目のノードを停止した時点で、クラスタ構成メンバーが過半数を割るため、システムとしては正常に動作しなくなりはじめます（なお、過半数ノード停止状態でのシステム正常動作はサポート範囲外です）。ブラウザでアクセスしても「502 Bad Gateway」などのエラーになったり、docker コマンドでノード一覧を確認しようとしても以下のようにエラーになります。

$ docker node ls
Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader.
It's possible that too few managers are online. Make sure more than half of the managers are online.

こうしたエラーは想定通りとなりますので、残ったノードについても続けて停止してください。

クラスタ停止手順

クラスタを構成するノードを順番に停止させてください。

基本的に停止させるノードの順番は問いませんが、クラスタを再開するときは「ノードを停止させた逆順に開始する」ことが望ましいため、停止させたノードの順番は記録しておいてください。

各ノードを、例えば ke2-server3, ke2-server2, ke2-server1 の順で停止させた場合、クラスタを再開するときは ke2-server1, ke2-server2, ke2-server3 の順で起動することを推奨します。

各ノードの停止

クラスタを構成するホストサーバを順番にシャットダウンしてください。

$ sudo poweroff

※ poweroff コマンドが存在しないホストサーバの場合、shutdown -h now など代替のコマンドを利用してください。

または、対象ホストサーバ上で docker.socket を停止させることで、ホストサーバを停止させずにノード停止と同様の状態にすることができます。 （docker.service を停止させても、docker.socket を停止させていないと自動的に再起動することに注意してください）

$ sudo systemctl stop docker.socket

注意事項に記載のとおり、あるノードを停止したあとに過半数のノードが残っていない場合、例えば3台構成で1台になった時点で、docker node コマンドによる構成ノードの確認や、docker service ps コマンドによるコンテナの状態確認などは行えなくなりますので、ご注意ください。

必須ではありませんが、あるノードを停止したあとに、2台以上のノードが残っている段階では、停止したノードが docker node ls コマンドで STATUS が "Down" になったのを確認してから、次のノードの停止手順に進むことを推奨します。通常であればサーバをシャットダウンして数十秒程度以内に Down 状態になります。

以下の例ではノード ke2-server3 が Down 状態になっていることが分かります。

$ docker node ls
ID                            HOSTNAME      STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
l96i39jjjq8ntkzu2p2vvejvf     ke2-server1   Ready     Active         Reachable        26.1.4
sw6kopnwous6gfz0zg1qcp1ho *   ke2-server2   Ready     Active         Leader           26.1.4
0i62egrvpwj0lpittkx9dw9na     ke2-server3   Down      Active         Unreachable      26.1.4

クラスタの開始

全体を停止させていたクラスタ構成のシステムを開始する手順を示します。

なお、ここではノードやコンテナの構成および設定などについて、停止前から変更を加えていないことを前提としています。

注意事項

3台数構成の swarm クラスタでは2台以上のノードで docker が開始しないと、クラスタノードの構成と各コンテナの起動は始まりません。 以下に説明する手順においても、途中までは各コンテナの動作は始まりませんので注意してください。

また、いくつかのコンテナには以下のような依存関係があり、依存するコンテナが正常に動作していないと起動しないようになっています。

たとえば、kompira や kengine コンテナは redis, postgres, rabbitmq コンテナに依存していますので、それらが正常に動作するまで起動に時間がかかったり、状況によってはコンテナの再起動を自動的に何度か繰り返す場合があります。通常であれば数分程度で安定しますので、一時的なコンテナの再起動などがあっても静観するようにしてください。

開始失敗時の対策

全てのノードを起動してから、5分以上経過してもいずれかのコンテナが正常に起動していない（コンテナの起動に失敗する、コンテナが再起動を繰り返す）ような場合は、システムに何らかの異常をきたしている可能性があります。そのような場合、以下を参考に対策してみてください。

• 一度クラスタ全体を停止させてから、クラスタ全体の開始を再度試してみてください。
• それでも状況が改善しない場合は、トラブルシュートを参考にして、システムの診断を行なって回復手順を試してみてください。
• それでも状況が改善しない場合は、サポート窓口またはコミュニティサイトにお問い合わせください。

クラスタ開始手順

クラスタを構成するノードを順番に起動させてください。

【要確認】このとき、可能であれば最後に停止させたノードから起動させてください。

【要確認】なお、各ミドルウェア (glusterfs, docker など) がすべて自動起動するように構成されている場合は、クラスタを構成する全てのノードを一度に起動させても問題ありませんが、各ノード起動による状態の変遷を確認しながらクラスタを開始することを推奨します。

各ノードを、ここでは ke2-server1, ke2-server2, ke2-server3 の順で起動するとした場合、以下のような流れになります。

• ke2-server1 起動:
  • ノードの正常起動を確認
  • ※ Pgpool-II/PostgreSQL の起動とオンラインリカバリ (primary ノードの起動)
• ke2-server2 起動:
  • ノードの正常起動を確認
  • 共有ファイルシステムのマウント
  • ※ Pgpool-II/PostgreSQL の起動とオンラインリカバリ (standby ノードの起動)
  • docker の起動 (共有ファイルシステムとデータベースを確認してから、ke2-server1 もここで起動します)
  • クラスタノードのステータスを確認 (2台が Ready になっている)
  • コンテナの開始を確認 (2台のノードでコンテナが開始している)
• ke2-server3 起動:
  • ノードの正常起動を確認
  • 共有ファイルシステムのマウント
  • ※ Pgpool-II/PostgreSQL の起動とオンラインリカバリ (standby ノードの起動)
  • docker の起動
  • クラスタノードのステータスを確認 (3台が Ready になっている)
  • コンテナの開始を確認 (全てのノードでコンテナが開始している)
  • 全体のステータスを確認

※ 手順「pgpool-II/PostgreSQL の起動とオンラインリカバリ」は、外部データベースを利用した構成では不要です。

ノードの正常起動を確認

クラスタを構成するノードが正常に起動していることを、必要に応じて確認してください。

• SSH またはコンソールで対象ノードにログインできる。
• ホスト名およびネットワークアドレスが正しく構成されている。
• 所属ネットワークへの導通（例えばデフォルトゲートウェイへの ping）が確認できる。
• 2台目以降のノードを起動した場合は、クラスタを構成するノード間の導通についても確認する。

共有ファイルシステムのマウント

Kompira クラスタが利用している共有ファイルシステムをマウントしてください。 ここでは glusterfs を利用して構成している場合の例を示します。

ただし、起動ノードが 1 台の段階ではマウント処理はできません。2台のノード起動後にマウントするようにしてください。

• glusterd サービスを起動してください。

  • glusterd サービスの起動自体はノードが 1 台の段階でも実施することができます。

    $ sudo systemctl start glusterd
    

  • なお GlusterFS の準備 を参考に glusterfs を構築している場合は自動起動しているはずです。

• glusterfs ボリュームをマウントしてください。

  • 自動マウントする設定をしている場合でも、マウントされていることを必ず確認してください。
  • マウントされていない場合は、例えば mount コマンドを用いて手動でマウントしてください（マウントポイントは構成に合わせてください）。

    $ sudo mount /mnt/gluster
    

少なくとも 2台の glusterfs ノードが起動していない段階では、マウントに失敗することに注意してください。

$ sudo mount /mnt/gluster
Mount failed. Check the log file  for more details.

Pgpool-II/PostgreSQL の起動とオンラインリカバリ

注意: 外部データベースを利用してシステムを構成している場合は、この手順はスキップしてください。ただし、クラスタを開始するときは、事前に外部データベースが正常に動作していて接続可能な状態であることを確認するようにしてください。

Kompira クラスタを構成しているノード上で（docker コンテナ外部で） Pgpool-II/PostgreSQL クラスタも構成している場合は、docker を起動する前に Pgpool-II/PostgreSQL の起動とオンラインリカバリを実施してください。

• 1台目のノードを起動した段階:
  • postgreSQL を起動してください。
    • 【重要】postgresql が primary となるノード（例えば最後に停止したノード）を、1台目のノードとして起動してください。
    • または、このノードの postgresql が primary になるように起動してください。
      • 例えば、pgsql12 以降では $PGDATA/standby.signal を削除してから起動してください。
  • Pgpool-II を起動してください。

    $ sudo systemctl start pgpool
    

  • 詳細については Pgpool-II の準備 の「Pgpool-II の起動」を参考にしてください。
• 2台目以降のノードを起動した段階:

  • Pgpool-II を起動してください。

    $ sudo systemctl start pgpool
    

  • Pgpool-II で当該ノードの postgresql に対するオンラインリカバリを実施してください。ここで、$CLUSTER_VIP は Pgpool-II で使用する仮想IPアドレスを、{ノードID} はオンラインリカバリする対象のノードIDを指定してください。

    $ pcp_recovery_node -h $CLUSTER_VIP -p 9898 -U pgpool -n {ノードID} -W
    

  • 詳細については Pgpool-II の準備 の「スタンバイサーバのオンラインリカバリ」を参考にしてください。

docker の起動

起動したノードで docker が起動していない場合（または自動起動しないように設定している）は、以下のように開始してください。 なお、Swarm クラスタの準備 を参考にクラスタを構築している場合は、docker は自動起動するようになっています。

$ sudo systemctl start docker

共有ファイルシステムやデータベースが外部構成でも自動起動する設定にもなっていない（自動起動しないようにしている）場合は、docker についても自動起動しないように構成することも検討してみてください。docker を含めて2台以上のノードが起動してから正常なクラスタ動作を開始できるサービスが多いので、2台のノードを起動してから各サービスを手動で開始する手順をとることで、各手順ごとに状態を確認しながら作業することが出来るようになります。

クラスタノードのステータスを確認

2台以上のノードを起動して docker を開始したら、docker node ls コマンドを用いてクラスタノードの状態を確認してください。 ただし、ステータスが取得できるようになるのに、ノード起動後少し時間がかかる場合があるので注意してください。

例えば、2台目のノードを起動したあと以下のように 2 台の STATUS が "Ready" になり、そのうち一台の MANAGER STATUS が "Leader" になるはずです。 また、まだ起動していない3台目のノードについては、STATUS が "Down" となり MANAGER STATUS が "Unreachable" となっていることが分かります。

$ docker node ls
ID                            HOSTNAME      STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
l96i39jjjq8ntkzu2p2vvejvf *   ke2-server1   Ready     Active         Reachable        26.1.4
sw6kopnwous6gfz0zg1qcp1ho     ke2-server2   Ready     Active         Leader           26.1.4
0i62egrvpwj0lpittkx9dw9na     ke2-server3   Down      Active         Unreachable      26.1.4

3台目のノードを起動したあとであれば、以下のようにすべてのノードの STATUS が "Ready" になるはずです。

$ docker node ls
ID                            HOSTNAME      STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
l96i39jjjq8ntkzu2p2vvejvf *   ke2-server1   Ready     Active         Reachable        26.1.4
sw6kopnwous6gfz0zg1qcp1ho     ke2-server2   Ready     Active         Leader           26.1.4
0i62egrvpwj0lpittkx9dw9na     ke2-server3   Ready     Active         Reachable        26.1.4

なお、1台目のノードを起動しただけの時点では、マネージャノード数が足りずに以下のようにエラーになります。

$ docker node ls
Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader.
It's possible that too few managers are online. Make sure more than half of the managers are online.

コンテナの開始を確認

各ノードでクラスタノードの状態を確認できたら、docker service ps コマンドを用いてコンテナの開始状況を確認してください。このコマンドは終了しているコンテナの情報も表示するため、ここでは以下のように実行中となるはずのコンテナだけを表示して確認しています。

$ docker service ps -f desired-state=running $(docker service ls -q)

なお、このコマンドは docker が正常に開始している任意のノードで実行できます。

例えば、2台目のノードを起動したあとにコンテナが正常に起動を開始している状況の例を以下に示します。 3台目のノードが起動していないために、NODE は空欄になっており（当該コンテナがどこでも起動していない）、ERROR には "no suitable node" などのエラーが表示されていることがわかります。

$ docker service ps -f desired-state=running $(docker service ls -q)
ID             NAME             IMAGE                                                  NODE          DESIRED STATE   CURRENT STATE           ERROR                              PORTS
i85kdpqhato3   ke2_jobmngrd.1   kompira.azurecr.io/kompira-enterprise:latest                         Running         Pending 3 minutes ago   "no suitable node (max replica…"
24z2rcnhc4ll   ke2_jobmngrd.2   kompira.azurecr.io/kompira-enterprise:latest           ke2-server2   Running         Running 3 minutes ago
2xo9xug784u3   ke2_jobmngrd.3   kompira.azurecr.io/kompira-enterprise:latest           ke2-server1   Running         Running 3 minutes ago
vg0zk3qsc446   ke2_kengine.1    kompira.azurecr.io/kompira-enterprise:latest                         Running         Pending 3 minutes ago   "no suitable node (max replica…"
gdvrufzwbov5   ke2_kengine.2    kompira.azurecr.io/kompira-enterprise:latest           ke2-server1   Running         Running 3 minutes ago
v5cewfo0ewme   ke2_kengine.3    kompira.azurecr.io/kompira-enterprise:latest           ke2-server2   Running         Running 3 minutes ago
bs2c7tfddwy7   ke2_kompira.1    kompira.azurecr.io/kompira-enterprise:latest           ke2-server2   Running         Running 3 minutes ago
g2cp91cwhxd3   ke2_kompira.2    kompira.azurecr.io/kompira-enterprise:latest           ke2-server1   Running         Running 3 minutes ago
mc45a9ilfmg6   ke2_kompira.3    kompira.azurecr.io/kompira-enterprise:latest                         Running         Pending 3 minutes ago   "no suitable node (max replica…"
j47uexpxtz8k   ke2_nginx.1      registry.hub.docker.com/library/nginx:1.27-alpine                    Running         Pending 3 minutes ago   "no suitable node (host-mode p…"
szgmu5n2f3t7   ke2_nginx.2      registry.hub.docker.com/library/nginx:1.27-alpine      ke2-server2   Running         Running 2 minutes ago                                      *:443->443/tcp,*:443->443/tcp,*:80->80/tcp,*:80->80/tcp
k32ba9qgcuyj   ke2_nginx.3      registry.hub.docker.com/library/nginx:1.27-alpine      ke2-server1   Running         Running 3 minutes ago                                      *:80->80/tcp,*:80->80/tcp,*:443->443/tcp,*:443->443/tcp
zeazgzl9ch9w   ke2_rabbitmq.1   registry.hub.docker.com/library/rabbitmq:3.13-alpine                 Running         Pending 3 minutes ago   "no suitable node (max replica…"
yfvlqgh9urr2   ke2_rabbitmq.2   registry.hub.docker.com/library/rabbitmq:3.13-alpine   ke2-server2   Running         Running 3 minutes ago
khp2uezdem9z   ke2_rabbitmq.3   registry.hub.docker.com/library/rabbitmq:3.13-alpine   ke2-server1   Running         Running 3 minutes ago
s7c9pqm0gf7g   ke2_redis.1      registry.hub.docker.com/library/redis:7.2-alpine       ke2-server1   Running         Running 3 minutes ago

2台目のクラスタが正常に起動したとしても各コンテナは順次起動していきます。 そのため早すぎる段階でコマンドを実行しても、すべてのコンテナが開始していない場合があります（コマンド実行結果の一覧に表示されない）ので注意してください。

$ docker service ps -f desired-state=running $(docker service ls -q)
ID             NAME             IMAGE                                                  NODE          DESIRED STATE   CURRENT STATE                    ERROR                              PORTS
i85kdpqhato3   ke2_jobmngrd.1   kompira.azurecr.io/kompira-enterprise:latest                         Running         Pending 2 seconds ago            "no suitable node (max replica…"
v5cewfo0ewme   ke2_kengine.3    kompira.azurecr.io/kompira-enterprise:latest           ke2-server2   Running         Running less than a second ago
mc45a9ilfmg6   ke2_kompira.3    kompira.azurecr.io/kompira-enterprise:latest                         Running         Pending 2 seconds ago            "no suitable node (max replica…"
yfvlqgh9urr2   ke2_rabbitmq.2   registry.hub.docker.com/library/rabbitmq:3.13-alpine   ke2-server2   Running         Running less than a second ago

3台目のノードを起動したあとに全てのコンテナが起動を開始している状況の例を以下に示します。 全てのコンテナの行で NODE がいずれかのノードのホスト名を示していて、ERROR 列はすべて空欄になっていることが分かります。

$ docker service ps -f desired-state=running $(docker service ls -q)
ID             NAME             IMAGE                                                  NODE          DESIRED STATE   CURRENT STATE            ERROR     PORTS
3ruhydde239r   ke2_jobmngrd.1   kompira.azurecr.io/kompira-enterprise:latest           ke2-server3   Running         Running 31 seconds ago
24z2rcnhc4ll   ke2_jobmngrd.2   kompira.azurecr.io/kompira-enterprise:latest           ke2-server2   Running         Running 4 minutes ago
2xo9xug784u3   ke2_jobmngrd.3   kompira.azurecr.io/kompira-enterprise:latest           ke2-server1   Running         Running 4 minutes ago
zl3f74s8xtfh   ke2_kengine.1    kompira.azurecr.io/kompira-enterprise:latest           ke2-server3   Running         Running 31 seconds ago
gdvrufzwbov5   ke2_kengine.2    kompira.azurecr.io/kompira-enterprise:latest           ke2-server1   Running         Running 4 minutes ago
v5cewfo0ewme   ke2_kengine.3    kompira.azurecr.io/kompira-enterprise:latest           ke2-server2   Running         Running 4 minutes ago
bs2c7tfddwy7   ke2_kompira.1    kompira.azurecr.io/kompira-enterprise:latest           ke2-server2   Running         Running 4 minutes ago
g2cp91cwhxd3   ke2_kompira.2    kompira.azurecr.io/kompira-enterprise:latest           ke2-server1   Running         Running 4 minutes ago
2kiwn6dvorv5   ke2_kompira.3    kompira.azurecr.io/kompira-enterprise:latest           ke2-server3   Running         Running 31 seconds ago
mqod5o21dvrp   ke2_nginx.1      registry.hub.docker.com/library/nginx:1.27-alpine      ke2-server3   Running         Running 28 seconds ago             *:443->443/tcp,*:443->443/tcp,*:80->80/tcp,*:80->80/tcp
szgmu5n2f3t7   ke2_nginx.2      registry.hub.docker.com/library/nginx:1.27-alpine      ke2-server2   Running         Running 4 minutes ago              *:443->443/tcp,*:443->443/tcp,*:80->80/tcp,*:80->80/tcp
k32ba9qgcuyj   ke2_nginx.3      registry.hub.docker.com/library/nginx:1.27-alpine      ke2-server1   Running         Running 4 minutes ago              *:80->80/tcp,*:80->80/tcp,*:443->443/tcp,*:443->443/tcp
q007y2p80gs8   ke2_rabbitmq.1   registry.hub.docker.com/library/rabbitmq:3.13-alpine   ke2-server3   Running         Running 31 seconds ago
yfvlqgh9urr2   ke2_rabbitmq.2   registry.hub.docker.com/library/rabbitmq:3.13-alpine   ke2-server2   Running         Running 4 minutes ago
khp2uezdem9z   ke2_rabbitmq.3   registry.hub.docker.com/library/rabbitmq:3.13-alpine   ke2-server1   Running         Running 4 minutes ago
s7c9pqm0gf7g   ke2_redis.1      registry.hub.docker.com/library/redis:7.2-alpine       ke2-server1   Running         Running 4 minutes ago

なお、1台目のノードを起動しただけの時点では、マネージャノード数が足りずに以下のようにエラーになります。

$ docker service ps -f desired-state=running $(docker service ls -q)
Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader. It's possible that too few managers are online. Make sure more than half of the managers are online.
"docker service ps" requires at least 1 argument.
See 'docker service ps --help'.

Usage:  docker service ps [OPTIONS] SERVICE [SERVICE...]

List the tasks of one or more services

全体のステータスを確認

全てのノードが起動できたら、クラスタを構成する各コンテナが正常に動作しているか確認してください。

• ブラウザで /.status 画面を開いて全てのコンテナが正常を示している（赤い表示になっていない）ことを確認してください。
• ブラウザで Kompira にログインできることを確認してください。
• 自動起動または自動再起動するジョブフローが存在する場合は、期待通りにプロセスが開始しているかを確認してください。なお、システムが正常な場合、(3台構成の場合) 2台目のノードを起動した時点で、このプロセスの自動起動処理は開始しています。

全てのノードが正常起動して、全てのコンテナが正常に動作していれば、クラスタ開始の成功となります。

ノードの停止

クラスタ構成において運用状態のまま一部のノードを停止させる手順を示します。

なお、ここでは一部のノードを停止する前は、全てのノード・全てのコンテナが正常に動作していることを前提としています。

制限事項

クラスタ構成においてシステムの運用を継続しつつ一部のノードを停止させたい場合、「停止させるノードは1台まで」 にしてください。

※ 5台以上の多ノード構成場合は2台まで停止できる可能性がありますが、現時点でサポート対象となるのは1台までの停止です。

注意事項

ノードを停止させると、実行中のジョブフローの動作などに影響を与える場合があります。 可能であればジョブフローが全て停止している状態で実施されることをお勧めします。

• 【重要】当該ノードで redis コンテナが動作していた場合、ノードを停止させると redis コンテナが別のノードに移動します。このとき一時的に redis がダウン状態になるため、以下のような影響があります。システム影響が大きいため redis コンテナが動作しているノードの停止は十分注意して実施してください。
  • ブラウザアクセスや REST-API アクセスが一時的にエラーになる場合があります。
  • 実行中のジョブフロープロセスが異常終了する場合があります。
• 当該ノードの kengine コンテナ上の Executor で実行中のジョブフローは強制終了されます。
  • 当該のジョブフロープロセスに「自動再起動」フラグが設定されている場合は、別のノード上で同じジョブフローが同じパラメータで新たに再起動されます。
• 【要確認】当該ノードの kengine が leader として動作 (role="leader") していた場合、ノードを停止させると leader が別のノードに移動します。

ノードの停止手順

停止対象のホストサーバをシャットダウンしてください。

$ sudo poweroff

※ poweroff コマンドが存在しないホストサーバの場合、shutdown -h now など代替のコマンドを利用してください。

または、対象ホストサーバ上で docker.socket を停止させることで、ホストサーバを停止させずにノード停止と同様の状態にすることができます。 （docker.service を停止させても、docker.socket を停止させていないと自動的に再起動することに注意してください）

$ sudo systemctl stop docker.socket

確認手順

クラスタの過半数のノードが正常に動作している場合、システムとしては正常に動作します。 一部のノードを停止したあとに、残ったノードでシステムが正常に動作しているかを確認してください。

• ブラウザで /.status 画面を開いて全てのコンテナが正常を示している（赤い表示になっていない）ことを確認してください。
• ブラウザで Kompira にログインできることを確認してください。
• 自動再起動が有効に設定されたジョブフロープロセスが実行中であった場合、別のノードで同じジョブフローが新たに開始していることを確認してください。

注意事項にあるように redis コンテナが移動するケースなどで、一時的にエラーが発生することがありますが、通常であれば時間経過とともに安定します。

停止失敗時の対策

一部のノードを停止したあとにエラーが発生するようになり、5分以上経過してもシステムが正常な状況に回復しないような場合は、システムに何らかの異常をきたしている可能性があります。そのような場合、以下を参考に対策してみてください。

• トラブルシュートを参考にして、システムの診断を行なって回復手順を試してみてください。
• それでも状況が改善しない場合は、サポート窓口またはコミュニティサイトにお問い合わせください。

ノードの起動

クラスタ構成において運用状態のまま停止させていた一部ノードを起動する手順を示します。

なお、ここではクラスタを構成する過半数のノードが起動していて、全てのコンテナが正常に動作していることを前提としています。

起動手順

前提条件から、3台構成のクラスタで言えば2台のノードでシステムが正常動作中で、最後の3台目を起動するのと同じ状況ですので、クラスタの開始 の3台目のノードの開始と同様の手順になります。

• ke2-server3 起動:
  • ノードの正常起動を確認
  • 共有ファイルシステムのマウント
  • ※ Pgpool-II/PostgreSQL の起動とオンラインリカバリ (standby ノードの起動)
  • docker の起動
  • クラスタノードのステータスを確認 (3台が Ready になっている)
  • コンテナの開始を確認 (全てのノードでコンテナが開始している)
  • 全体のステータスを確認

ここでは簡略化した説明に留めますので、詳しくは クラスタの開始 を参照してください。

ホストサーバの起動

停止させていたホストサーバを起動してください。

共有ファイルシステムのマウント

Kompira クラスタが利用している共有ファイルシステム (glusterfs など) をマウントしてください。 ここでは glusterfs を利用して構成している場合の例を示します。

glusterd サービスを起動して、glusterfs ボリュームをマウントしてください（マウントポイントは構成に合わせてください）。

$ sudo systemctl start glusterd
$ sudo mount /mnt/gluster

pgpool-II/PostgreSQL の起動とオンラインリカバリ

注意: 外部データベースを利用してシステムを構成している場合は、この手順はスキップしてください。

pgpool サービスを起動して、起動したノードの postgresql に対するオンラインリカバリを実施してください。ここで、$CLUSTER_VIP は Pgpool-II で使用する仮想IPアドレスを、{ノードID} はオンラインリカバリする対象のノードIDを指定してください。

$ sudo systemctl start pgpool
$ pcp_recovery_node -h $CLUSTER_VIP -p 9898 -U pgpool -n {ノードID} -W

docker の起動

docker サービスを起動してください。

$ sudo systemctl start docker

クラスタノードのステータスを確認 (3台が Ready になっている)

docker node ls コマンドを用いてクラスタノードの状態を確認してください。

$ docker node ls
ID                            HOSTNAME      STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
l96i39jjjq8ntkzu2p2vvejvf *   ke2-server1   Ready     Active         Reachable        26.1.4
sw6kopnwous6gfz0zg1qcp1ho     ke2-server2   Ready     Active         Leader           26.1.4
0i62egrvpwj0lpittkx9dw9na     ke2-server3   Ready     Active         Reachable        26.1.4

コンテナの開始を確認 (全てのノードでコンテナが開始している)

docker service ps コマンドを用いて全てのノードで全てのコンテナの開始していることを確認してください。

$ docker service ps -f desired-state=running $(docker service ls -q)

全体のステータスを確認

ノードが起動できたら、クラスタを構成する各コンテナが正常に動作しているか確認してください。

• ブラウザで /.status 画面を開いて全てのコンテナが正常を示している（赤い表示になっていない）ことを確認してください。
• ブラウザで Kompira にログインできることを確認してください。

コンテナの移動

ke2-docker を用いた構成した Docker swarm クラスタ構成では、明示的にコンテナを移動する操作を行なう必要はありません。 まず、ほとんどのコンテナは全てのノードでレプリカされて、全てがアクティブとして動作するため、コンテナを移動する意味はありません。

KE2.0 の時点では唯一、redis コンテナについては 単一のノードでのみ動作するように構成されています。 そのため redis コンテナについてはどのノードで動作しているのか、動作するノードが移動するケースについて、また、強制的に動作ノードを移動させたい場合の手法について説明します。

redis コンテナを実行しているノードの確認

現在どのノードで redis コンテナが動作しているかについては、docker service ps コマンドを用いて確認することができます。

$ docker service ps ke2_redis
ID             NAME              IMAGE                                              NODE          DESIRED STATE   CURRENT STATE          ERROR                              PORTS
j002f9kno7ma   ke2_redis.1       registry.hub.docker.com/library/redis:7.2-alpine   ke2-server1   Running         Running 25 hours ago
g7lg28hnfupv    \_ ke2_redis.1   registry.hub.docker.com/library/redis:7.2-alpine   ke2-server1   Shutdown        Failed 25 hours ago    "No such container: ke2_redis.…"
ngwsnwc20fqk    \_ ke2_redis.1   registry.hub.docker.com/library/redis:7.2-alpine   ke2-server1   Shutdown        Failed 25 hours ago    "No such container: ke2_redis.…"

コマンドを実行して表示される結果の DESIRED STATE が "Running" となっている行の NODE で、現在 redis コンテナを実行しているノードが確認できます。 以下のようにいくつかオプションを付けて実行すると、当該するノードの情報だけ表示することができます。

$ docker service ps -f desired-state=running --format "{{.Node}}" ke2_redis
ke2-server1

redis コンテナが移動するタイミング

クラスタが開始したとき（2台目のノードが開始したとき）いずれかのノードで redis コンテナが起動します。 基本的に redis コンテナはそのノードから移動せずに動作しつづけますが、以下のようなときには別のノードに移動して動作を再開する場合があります。

• redis コンテナがダウンしたとき（移動せず同じノードで再起動となる場合もあります）
• redis コンテナが動作しているノードがダウンしたとき
• 強制的に redis コンテナを移動させたとき

redis コンテナの移動方法【非推奨】

Docker swarm クラスタにおいて、あるコンテナを指定したノードに移動させる決まった手順はありません。 以下のように docker service update コマンドを用いることで、redis コンテナの状態更新が行なわれて、その結果として別のノードに移動する場合があります（同じノードでの再起動となる場合もあります）。

$ docker service update --force ke2_redis

ただし、redis コンテナが移動（もしくは再起動）すると動作中のジョブフローが異常終了するなどの影響が起きる場合がありますので、特別な理由がない限り redis コンテナの移動は控えることを推奨します。

システムの削除

クラスタ構成のシステムを削除する手順について示します。

クラスタの削除手順

Swarm クラスタのいずれかのマネージャーノード上（以下の例では ke2-server1）で、docker stack rm ke2 コマンドを実行してください。

[ke2-server1]$ docker stack rm ke2
Removing service ke2_jobmngrd
Removing service ke2_kengine
Removing service ke2_kompira
Removing service ke2_nginx
Removing service ke2_rabbitmq
Removing service ke2_redis
Removing config swarm_rabbitmq-config-cluster
Removing config swarm_kompira-config
Removing config swarm_rabbitmq-config-auth
Removing config swarm_kompira-audit
Removing config swarm_rabbitmq-config-ssl
Removing config swarm_bootstrap-rabbitmq
Removing config swarm_nginx-config
Removing network swarm_default

このコマンドを実行すると、クラスタで動作している全てのコンテナが停止して、クラスタスタックと構成サービスの定義などが削除されます。 停止したあとに docker stack ls, docker service ls, docker config ls コマンドを実行すると、いずれも空になっているはずです。

$ docker stack ls
NAME      SERVICES
$ docker service ls
ID        NAME      MODE      REPLICAS   IMAGE     PORTS
$ docker config ls
ID        NAME      CREATED   UPDATED

この状態になると、ノードを再起動したり docker サービスを再起動しても、Kompira サービスは起動しません。

なお、この時点では Swarm クラスタ構成自体は残っています。

$ docker node ls
ID                            HOSTNAME      STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
l96i39jjjq8ntkzu2p2vvejvf *   ke2-server1   Ready     Active         Reachable        26.1.4
sw6kopnwous6gfz0zg1qcp1ho     ke2-server2   Ready     Active         Leader           26.1.4
0i62egrvpwj0lpittkx9dw9na     ke2-server3   Ready     Active         Reachable        26.1.4

そのため、Swarm クラスタ構成の セットアップ手順 からデプロイしなおすことが出来ます。

コンテナの削除手順

クラスタが停止してもコンテナが残っている場合があります。 docker container ls -a コマンドで停止したものも含めてコンテナの一覧を確認できます。

$ docker container ls -a
CONTAINER ID   IMAGE                                          COMMAND                  CREATED      STATUS    PORTS     NAMES
059775d2d864   kompira.azurecr.io/kompira-enterprise:latest   "docker-entrypoint.s…"   5 days ago   Dead                ke2_kompira.3.chic2oqd0l46t6c6i3q1yd5rk

残っているコンテナを削除したい場合は、docker container prune コマンドで一括削除できます。 本当に削除するか確認されるので、実行する場合は y を入力してください。

$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
059775d2d864483ba451d268b41e70c8761c9efaf559e7979e65253e91568926

Total reclaimed space: 803.1kB

この手順は、クラスタを構成する各ノードで実施してください。

イメージの削除手順

クラスタを停止してもコンテナイメージは残っています。 docker image ls -a コマンドで全てのコンテナイメージの一覧を確認できます。

$ docker image ls -a
REPOSITORY                                 TAG                IMAGE ID       CREATED        SIZE
kompira.azurecr.io/kompira-enterprise      <none>             95fb2b1e3ef0   7 days ago     503MB
kompira.azurecr.io/kompira-enterprise      <none>             2fc0e8aea9b4   7 days ago     503MB
kompira-enterprise                         2.0.1a1_62f84257   f60f16a921fb   7 days ago     503MB
kompira-enterprise                         2.0.1a1_66ee42a9   c702af2baab6   7 days ago     503MB
kompira.azurecr.io/kompira-enterprise      <none>             3efb4ead515c   8 days ago     503MB
kompira-enterprise                         2.0.0_a4071bf5     eac7265ec11b   2 weeks ago    503MB
kompira-enterprise                         2.0.0_8875d278     75f9622860d7   2 weeks ago    503MB
registry.hub.docker.com/library/rabbitmq   <none>             0ca98669e517   2 weeks ago    141MB
kompira-enterprise                         2.0.0_a3309cf7     0d540ff81113   3 weeks ago    503MB
registry.hub.docker.com/library/rabbitmq   <none>             2262fa9f479a   4 weeks ago    141MB
registry.hub.docker.com/library/rabbitmq   <none>             4083c19b838f   5 weeks ago    141MB
kompira-enterprise                         2.0.0_56cb960d     868774a8f9bf   5 weeks ago    504MB
registry.hub.docker.com/library/nginx      <none>             c7b4f26a7d93   6 weeks ago    43.2MB
registry.hub.docker.com/library/nginx      <none>             0f0eda053dc5   6 weeks ago    43.3MB
kompira.azurecr.io/kompira-enterprise      <none>             de61c5570c0d   7 weeks ago    504MB
registry.hub.docker.com/library/rabbitmq   <none>             5d6e30bc0bea   8 weeks ago    141MB
registry.hub.docker.com/library/nginx      <none>             1ae23480369f   3 months ago   43.2MB
registry.hub.docker.com/library/redis      <none>             ab3bbb60f1b6   4 months ago   40.7MB
registry.hub.docker.com/library/redis      <none>             97ed3031282d   4 months ago   40.7MB

残っているコンテナイメージを削除したい場合は、docker image prune -a コマンドで一括削除できます。 本当に削除するか確認されるので、実行する場合は y を入力してください。

$ docker image prune -a
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: registry.hub.docker.com/library/nginx@sha256:a5127daff3d6f4606be3100a252419bfa84fd6ee5cd74d0feaca1a5068f97dcf
deleted: sha256:c7b4f26a7d93f4f1f276c51adb03ef0df54a82de89f254a9aec5c18bf0e45ee9
deleted: sha256:df45629925efee5af98c24cd09fa6eb06f53bf8a31eb6255e25efd729c902e1e
deleted: sha256:e9d09343f346fd7a1ae6dde03c9d2a948dba60c99be0083f703c10acb691a29b
    :
untagged: kompira.azurecr.io/kompira-enterprise@sha256:c40e73309d67cf98eedd111ef783e1350379c280440718b1ec57de8c4e8839a2
deleted: sha256:2fc0e8aea9b48d0f98b64480eb13792baa3da0cddb3716e676a04e0b5f274923
deleted: sha256:27161d5e2678b37f620e2273bdefd619791dc937b711a03c163f6e8fd4a37155
deleted: sha256:d940d53c7b474ee3fdbcc9f1830eb2bb0a2d69f3c35511e491b1228a47c4fe9e
    :

Total reclaimed space: 5.414GB

この手順は、クラスタを構成する各ノードで実施してください。

ボリュームの削除手順

クラスタを停止しても名前付きボリュームは残っています。 docker voluems ls コマンドでボリュームの一覧を確認できます。

$ docker volume ls
DRIVER    VOLUME NAME
local     swarm_kompira_rmq

残っているボリュームを削除したい場合は、docker volume prune -a コマンドで一括削除できます。 本当に削除するか確認されるので、実行する場合は y を入力してください。

$ docker volume prune -a
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
swarm_kompira_rmq

Total reclaimed space: 1.141MB

この手順は、クラスタを構成する各ノードで実施してください。

ネットワークの削除

クラスタを停止しても Docker のネットワーク定義は残っています。 docker network ls コマンドでネットワークの一覧を確認できます。

$ docker network ls
NETWORK ID     NAME              DRIVER    SCOPE
d43ebc7d365d   bridge            bridge    local
937af22066a7   docker_gwbridge   bridge    local
a2a80d3dca46   host              host      local
uswsxaj23dbt   ingress           overlay   swarm
c0fa71959a20   none              null      local

docker network prune コマンドで、カスタム定義されたネットワークを削除することができます。 ただし Kompira 2.0 ではカスタム定義しているネットワークはありませんので、通常は実際に削除されるネットワークはないはずです。

$ docker network prune
WARNING! This will remove all custom networks not used by at least one container.
Are you sure you want to continue? [y/N] y

トラブルシュートガイド

Kompira 2.0 システムが正常に動作していないと考えられるときに、正常な状態に回復させるためには問題の原因を特定する必要があります。

その前提として、システムを構成する各コンテナがどのような役割を担っていて、他のコンテナとどのような連携を行なっているか、また、それぞれのコンテナで障害が生じた時の影響範囲などを理解しておくことが重要になります。

• 各コンテナの障害時の影響範囲

Kompira システムに問題があった場合にトラブルシュートを実施することに備えて、事前に各コンテナの役割や障害時の主な影響範囲について理解を深めておくことをお勧めします。

障害時の初期診断手順

ここでは障害時における基本的な初期診断の手順について示します。ただし、複雑な状況においては問題の原因を特定することは容易ではなく、ここに示した手順であらゆる状況に対応できるわけではないことに注意してください。

• ブラウザによる診断手順
• コマンドによる診断手順
• 障害パターンごとの調査手順と対策

ログの調査手順

様々な状況において、原因を特定するために各コンポーネントのログを調査する場面は多いです。各種ログの調査手順については、以下を参考にしてみてください。

• ログの調査

各コンテナの役割と障害時の影響範囲

Kompira 2.0 システムはいくつかのコンテナで構成されていて、それらが協調動作することでシステムとして正常に動作することができます。 コンテナはそれぞれ役割を持っており、コンテナに障害が起きたときはそれぞれ異なる影響を受けることになります。 また、いくつかのコンテナは他のコンテナに依存しているものもあり、そうしたコンテナでは依存先コンテナで障害があるとその影響を受ける場合もあります。

Kompira を構成する各コンテナについて、その依存するコンテナおよび障害時の主な影響について以下にまとめます。

影響範囲となっている役割や機能に関して、正常に動作していないと考えられるような場合は、当該のコンテナに何らかの問題が生じているという推測はできます。 Kompira システムに問題があった場合にトラブルシュートを実施することに備えて、事前に各コンテナの役割や障害時の主な影響範囲について理解を深めておくことをお勧めします。

以下に各コンテナの役割と障害時の典型的な影響範囲について示しますが、実際にはある状況が複数の障害や影響を同時に引き起こすようなことも多いです。 トラブルシュートにあたってはこれらは基本的な情報としてとらえて、個別には複雑な状況が起きうることを想定しておいてください。

redis の役割と影響範囲

Kompira オブジェクトアクセスなど各種データ処理のキャッシュ機構を担うため、redis コンテナの正常性は非常に重要です。 redis がダウンしている、または、他コンテナからアクセスできない状態になると、システム全体に影響があります。

• ブラウザ操作時に応答が返らなくなる、または内部処理エラーになります。
• ジョブフローの動作が停止する、または内部処理エラーになります。

postgresql の役割と影響範囲

全ての Kompira オブジェクトの保存先となるため、postgres コンテナの正常性は非常に重要です。 postgres がダウンしている、または、他コンテナからアクセスできない状態になると、redis 同様にシステム全体に影響があります。

nginx の役割と影響範囲

nginx コンテナは外部からの HTTP/HTTPS アクセスを受け付ける役割を担います。 nginx の障害時には、以下のような影響があります。

• 外部から HTTP/HTTPS アクセスが出来なくなります。
  • 外部からの HTTP/HTTPS アクセスは接続エラーや接続タイムアウトなどになります。

rabbitmq の役割と影響範囲

rabbitmq は各コンテナ間の連携動作をサポートするため、障害時の影響は以下のように多岐にわたります。

• kompira と kengine の連携が出来なくなります。
  • ブラウザ操作からジョブフローの実行など、kengine に対する処理指示ができなくなります。
  • Kompira オブジェクト更新時にそれに伴う kengine との連携処理ができなくなります。
• kengine と jobmngrd の連携ができなくなります。
  • ジョブフローによるリモートジョブなどの実行ができなくなります。
  • 外部に配置した kompira_jobmngrd とも連携できなくなります。
• kompira_sendevt からのメッセージを受信できなくなります。

kompira の役割と影響範囲

kompira コンテナは外部インターフェース経由のアプリケーション処理を担います。

• nginx が受け付けた HTTP/HTTPS リクエストに応じた、ブラウザ操作および REST-API アクセスが出来なくなります。
  • 外部からの HTTP/HTTPS アクセスは 50x エラーやレスポンスタイムアウトになります。
• kompira コンテナ上での manage.py 管理コマンドの実行ができなくなります。

kengine の役割と影響範囲

kengine コンテナはジョブフローなどプロセスの動作を担います。 kengine の障害時には以下のような影響があります。

• ジョブフローおよびスクリプトジョブの実行ができなくなります。
• kompira_sendevt からのメッセージを受信できなくなります。

ただしジョブフローの実行などは、実際には kengine 上で動作する Executor がその役割を担っています。 Executor はライセンスやシステム構成によって、一つの kengine 上で複数の Executor が動作する場合があります。 これは、一部の Executor のみで障害が発生しているようなケースでは、一部のジョブフローは実行できているが、別の一部のジョブフローの実行が出来なくなる、といった状況を生み出す可能性もあることに注意してください。

また kengine には "leader" または "follower" という役割があり、システム全体で一つの kengine だけが leader となります。 leader となる kengine が存在しないような状況では、さらに以下のような影響があります。

• 不要になったプロセス情報の回収されずに残り続けます。
• スケジュールやメールチャネルの再割り当てがなされずに、正常に機能しなくなります。
• ジョブマネージャ情報が更新されなくなります。

jobmngrd の役割と影響範囲

jobmngrd コンテナはリモートジョブの実行を担うため、障害時には以下のような影響があります。

• 実行ジョブを用いた ["command args..."] などのコマンド実行ができなくなります。
• スクリプトジョブの実行ができなくなります。
• その他のリモートジョブである、セッションジョブ、ファイル転送ジョブなども実行できなくなります。

クラスタ構成など jobmngrd が複数存在するような構成で一部の jobmngrd で障害が発生しているようなケースでは、一部のリモートジョブは実行できるが、別の一部のリモートジョブが実行できない、といった状況を生み出す可能性もあることに注意してください。

ブラウザによる診断手順

ユーザによるブラウザ操作で実施できる基本的な診断手順を以下に示します。

参考: 各診断手順について、状況によってはその結果が成功と失敗を繰り返すような場合も想定されます。システムとしては正常に動作していないと考えられる場合は、診断結果の１回の成功だけで問題ないとは判断せずに、何度か試すようにしてみてください。

• システムステータスによる診断手順
• ブラウザでの基本操作による診断手順
• ジョブフローの動作確認による診断手順

これらの診断で問題や原因箇所が見いだせない場合は、ブラウザ操作だけでは診断では判断がつきません。 次の、コマンドによる診断手順に進んでください。

DIAG-U1: システムステータスによる診断手順

ブラウザで Kompira の /.status にアクセスしてシステムステータスの確認してください。

このシステムステータスのエンドポイントは KE v2.0.1 以降で利用できます。

なお、/.status エンドポイントは API アクセスにも対応しています。簡単には format=json というパラメータを付けて /.status?format=json にアクセスすることで、結果を JSON 形式で得ることもできます。

ステータスコードが 200 (NG のコンテナがない場合)

この場合、ホストサーバおよび各コンテナは外形的には正常に動作していると考えられます。

クラスタ構成の場合、kengine と jobmngrd を拡張し、3台が正常に動作しているか確認することをおすすめします。

項目に問題があれば、項目の色が変わり、ステータスは WARNING や ERROR などで表示されます。

ステータスコードが 200 (NG のコンテナがある場合)

システムステータス画面で1つ以上のコンテナが NG として赤く表示される場合があります。

一部のコンテナで異常が発生していてもシステムとしては正常動作が期待できる場合は、HTTP ステータスは 200 となります。 たとえばクラスタ構成において、冗長化されている kengine や rabbitmq は一部で異常が発生していても、過半数で動作している場合はシステム全体としては正常であるとみなします。

(例1) rabbitmq と kengine に何らかの異常が生じている場合

(例2) rabbitmq と kengine と jobmngrd に何らかの異常が生じている場合

(例3) 赤く異状を示している箇所をクリックすると詳細情報が表示されます

異状を示しているコンテナがある場合は、それぞれのコンテナごとに調査を行なってみてください。

• postgres コンテナに異状が生じている
• redis コンテナに異状が生じている
• rabbitmq コンテナに異状が生じている

ディスクかメモリなどのリソースが不足しているときなど、rabbitmq がアラームを発している場合は、外部的には kengine と jobmngrd がエラーとして表示される場合があります。このときは以下について調査を行なってみてください。

• rabbitmq のアラームログ調査

ステータスコードが 502 となる場合

システムステータス画面のステータスコードが 502 となる場合があります。

kompira コンテナに異状が生じている場合、このような状況になる可能性があります。以下の確認を行なってみてください。

• ホストサーバのリソース状況
• kompira 停止

ステータスコードが 503 となる場合

システムステータス画面のステータスコードが 503 となる場合があります。

redis に障害が生じている場合

redis コンテナに異状が生じている場合に、このような状況になる可能性があります。以下の調査を行なってみてください。

• redis コンテナに異状が生じている

postgres に障害が生じている場合

postgres コンテナに異状が生じている場合に、このような状況になる可能性があります。以下の調査を行なってみてください。

• postgres コンテナに異状が生じている

ブラウザでの基本操作による診断手順

DIAG-U2: ログインできるかの確認

ブラウザで Kompira にログインできるかを確認してください。

成功する場合

ログインに成功する場合は、nginx, redis, postgres, kompira コンテナは正常に動作していると考えられます。

⇒ 次の診断に進んでください。

失敗する場合

⇒ 応答がない場合 (This site can't be reached)に進んでください。

⇒ ステータスコードが 502 となる場合

ログインに失敗する場合（ただし、パスワード間違いによるログイン失敗は除きます）は、DB 障害が起きている可能性があります。

• postgres コンテナに異状が生じている

まだ、解決できない場合は、以下の調査も行ってみてください。

• コンテナの診断手順

正常に画面表示ができるかの確認

ウェブサイトのUIが崩れている、またはリソースアクセスが 500 エラーとなる場合

クラスタ構成においては、以下について確認してみてください。

• 共有ファイルシステム (glusterfs)の正常性

DB write operation failing

KE2 APP にアクセスはできますが、DBを更新しようとすると頻繁に操作が失敗します。このような異常は、ジョブフローの操作時に発生することがあります。これは、DBセッションが中断されたり、DB内で何らかの問題が発生したことが原因です。

以下の調査手順を確認してみてください。

• 外部 DB 操作・セッション問題

ブラウザ画面表示の応答性が悪い場合

ブラウザでの画面表示の応答性が悪く時間がかかる場合は、以下について確認してみてください。

• ホストサーバのリソース状況の確認
• ネットワーク導通の確認
• Docker コンテナで利用のリソース状況の確認

外部 DB として Pgpool を利用している場合は、以下についても確認してみてください。

• Pgpoolをご利用場合、 Pgpool-IIノード間のネットワーク遅延確認

応答がない場合 (This site can't be reached)

この場合は様々な要因が考えられますので、以下のような調査を実施してみてください。

• ホストサーバの正常性の確認
• ホストサーバのリソース状況の確認
• ネットワーク導通の確認
• docker の正常動作の確認
• クラスタ構成の場合、swarm ノードのステータスの正常性確認
• Docker コンテナで利用のリソース状況の確認
• nginx コンテナが正常に動作しているか確認してください。

ジョブフローの動作確認による診断手順

DIAG-U3: ジョブフローを実行できるかの確認

ブラウザから以下のようなジョブフローを実行できるか、ジョブフローが成功するかを確認してください。

• 基本的には常に成功するジョブフロー
• リモートジョブを含まない ジョブフロー
• 既存の Kompria オブジェクトに影響を与えないジョブフロー

もっとも単純には、次のようなジョブフローを用意して実行してみてください。

print('OK')

ジョブフローが実行できない場合

ジョブフローが実行できない場合はいくつかの要因が考えられますので、以下のような調査を実施してみてください。

• ライセンスが有効であるか、また、期限内であるかを確認してください。
  • 適正なライセンスを更新してください。
• 実行中プロセス数が制限を超えていないか確認してください。
  • 自動起動などですでにジョブフロープロセスが多数動作している状況であれば、ジョブフローの実行自体は出来ていることになりますので、次の診断に進んでください。
  • ただし、ジョブフロープロセスが多数動作していること自体が想定外であれば、ジョブフローの設計や実装に問題がある可能性があります。ジョブフロー実行に関する設計や実装に問題がないか確認してください。

上記に該当しない場合は、rabbitmq や kengine コンテナで障害が起きている可能性があります。

• rabbitmq コンテナに異状が生じている

ジョブフローの実行はできるがジョブフローが異常終了する場合

この場合は、まずジョブフロー自体に問題がないか確認してください。

• プロセスログを確認して想定外のエラーなどが記録されていないか確認してください。
• ジョブフローの実装としてエラーになる状況になっていないか確認してください。

上記に該当しない場合は、rabbitmq, kengine コンテナのいずれかで障害が起きている可能性があります。

クラスタ構成場合は、以下に該当するか調査してみてください。

• rabbitmq コンテナが再起動を繰り返す
• kengine コンテナが再起動を繰り返す

ジョブフローが正常終了する場合

この場合は、rabbitmq, kengine コンテナは正常に動作していると考えられます。

⇒ 次の診断に進んでください。

失敗する場合、または成否が安定しない場合

この場合は、rabbitmq, kengine コンテナのいずれかで障害が起きている可能性があります。

⇒ コンテナの診断手順を進んでください。

DIAG-U4: リモートジョブが実行できるかの確認

ブラウザから以下のようなリモートジョブを実行できるか、ジョブフローが成功するかを確認してください。

• 基本的には常に成功するジョブフロー
• リモートジョブを含む ジョブフロー
• 既存の Kompria オブジェクトに影響を与えないジョブフロー

もっとも単純には、次のようなジョブフローを用意して実行してみてください。

['echo OK']

成功する場合

ジョブフローが正常終了する場合、

• rabbitmq, kengine, jobmngrd コンテナは正常に動作していると考えられます。
  • ⇒ 次の診断に進んでください。

失敗する場合、または成否が安定しない場合

• ジョブフロー自体に問題がないか確認してください。
• rabbitmq, kengine, jobmngrd コンテナのいずれかで障害が起きている可能性があります。
  • rabbitmq コンテナに異状が生じている
  • コンテナの診断手順

コマンド操作による診断手順

管理者によるコマンド操作によって実施できる診断手順を以下に示します。 この診断手順ではホストサーバに SSH でログインして操作する必要があります。

一部は「ブラウザ操作による診断手順」と診断内容が重複しているものもあります。 また診断手順によっては管理者権限が必要になりますのでご注意ください。

問題箇所の推定が出来ていない場合は、上から順次実施してみてください。

• ホストサーバの調査
• クラスタ構成場合、クラスタ構成に関するのサービスの調査
• コンテナの診断手順

ホストサーバの診断手順

システム操作によって実施できる診断手順を以下に示します。 一部は「ユーザ操作による診断手順」と診断内容が重複しているものもあります。

なお、この診断手順ではホストサーバに SSH でログインして操作する必要があります。 また診断手順によっては管理者権限が必要になりますのでご注意ください。

DIAG-A1: ホストサーバの正常性の確認

システムのホストサーバが正常に動作していることを、以下のような観点で確認してください。 クラスタ構成の場合は全てのノードの状態を確認するようにしてください。

• SSH またはコンソールで対象ノードにログインできる。
• ホスト名およびネットワークアドレスが正しく構成されている。
• 所属ネットワークへの導通（例えばデフォルトゲートウェイへの ping）が確認できる。

いずれかの確認で問題があるような場合は、Kompira システム以前にまずご利用になっているホストサーバについて、適切な保守対応を実施して正常化を行なってください。

ホストサーバの保守手順については、本マニュアルの範囲外になります。

クラスタ構成の場合は、さらに以下のような観点でも確認を行なってください。

• 2台目以上のノードを起動している場合は、クラスタを構成するノード間の導通についても確認してください。
  • ノード間の導通が確認できないような場合はクラスタが正常に動作しませんので、ネットワークの状態の確認と正常化を行なってください。
    • ネットワークの保守対応はこちらのマニュアルの範囲外となります。
• クラスタを構成する半数以下のノードしか起動していない場合は、クラスタとして開始できません。
  • クラスタの開始 を参考に適切にクラスタの開始を行なってください。

シングル構成でホストサーバに問題が無い場合、または、クラスタ構成で過半数のノードが正常に動作している場合は、次の診断に進んでください。

DIAG-A2: ホストサーバのリソース状況の確認

KE2 APP にパフォーマンスの低下が見られる場合（例えば、KE2 APP が遅くなったり、エラーが頻発したりする場合）、KE2 APP のホストサーバーのリソースが過負荷になっている可能性があります。そのような場合には、ホストサーバーのリソース状況を確認することが重要です。 クラスタ構成の場合は全てのノードの状態を確認するようにしてください。

• CPU 使用率
• メモリ使用率
• ディスク使用率

とくにディスク使用率については、空き容量が少なくなるとシステムが正常に動作できなくなる場合があります。 例えば rabbitmq コンテナは自身でディスクの空き容量をモニタリングしていて、空き容量が一定以下（デフォルトでは 50MB 以下）になると一部の動作を停止するようになっています。この状況になると Kompira システムとしても正常に動作できなくなりますので、注意してください。

参考: 目安としては、常に 200MB 以上の空き容量がある状況を維持するようにしてください。

ホストサーバの保守手順については、本マニュアルの範囲外になります。

リソース使用率が常に高く、例えば90%以上であるか、増加し続けて下がらない場合、リソース不足の状況が発生し、DockerやKE2 APPでさまざまなエラーが発生する可能性があります。

システム運用中のリソース状況を確認できるようにすることは重要になりますが、KE2 の標準のデプロイ手順では過去のリソース状況を確認するシステムなどは導入されません。

以下では Linux サーバ自身で簡単にリソース状況を確認できる sysstat を用いた手法を紹介しますが、監視システムを導入して本格的にリソース監視を行なうことも検討してください。

sar コマンドが利用できない場合は、sysstat パッケージをインストールしてください。

• CPU 使用率を確認する

  ホストサーバの CPU 負荷の履歴を確認するために、以下のコマンドを実行して数日の平均CPU使用量を確認します。

  数日前に、sysstat パッケージがインストールされていたと仮定します

  $ sar -u -f /var/log/sa/sa$(date --date="3 days ago" +%d)
  $ sar -u -f /var/log/sa/sa$(date --date="2 days ago" +%d)
  $ sar -u -f /var/log/sa/sa$(date --date="1 days ago" +%d)
  $ sar -u -f /var/log/sa/sa$(date --date="today" +%d)
  

  上の各コマンドで以下のような結果が表示されます。

  08:50:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
  09:00:01 PM     all      2.44      1.37      1.82      0.01      0.00     94.37
  09:10:21 PM     all      2.28      1.31      1.80      0.01      0.00     94.60
  09:20:01 PM     all      2.34      1.53      1.73      0.01      0.00     94.40
  09:30:15 PM     all      1.93      1.09      1.37      0.01      0.00     95.60
  09:40:01 PM     all      1.79      0.84      1.29      0.01      0.00     96.08
  09:50:00 PM     all      1.92      1.03      1.36      0.01      0.00     95.69
  10:00:31 PM     all      1.88      1.07      1.38      0.01      0.00     95.67
  10:10:31 PM     all      1.85      0.78      1.36      0.01      0.00     96.01
  10:20:01 PM     all      1.96      0.99      1.41      0.01      0.00     95.63
  10:30:01 PM     all      2.12      1.26      1.48      0.01      0.00     95.14
  10:40:08 PM     all      1.95      1.02      1.43      0.01      0.00     95.59
  10:50:01 PM     all      2.12      1.29      1.47      0.01      0.00     95.12
  11:00:11 PM     all      1.87      0.91      1.41      0.01      0.00     95.81
  11:10:21 PM     all      2.09      1.42      1.51      0.03      0.00     94.95
  11:20:31 PM     all      1.99      1.08      1.50      0.01      0.00     95.41
  11:30:05 PM     all      1.92      1.03      1.49      0.01      0.00     95.55
  11:40:00 PM     all      2.08      1.20      1.56      0.01      0.00     95.15
  11:50:31 PM     all      1.95      1.09      1.50      0.01      0.00     95.46
  Average:        all      2.34      1.60      1.81      0.01      0.00     94.24
  

  ホストサーバに sysstat パッケージが以前からインストールされていなかった場合は、以下のコマンドで最新の状況を確認してください。

  $ sar -u 2 30
  

  結果の各行にご注意ください。特に %user または %system 使用率が高いか常に90%を超えている場合、CPU コア数を増やすことをお勧めします。

  定常的に %user または %system の使用率が増加し続けて下がらない場合、何らかの処理が CPU を大量に消費している可能性があります。以下のコマンドで CPU を多く消費しているプロセスを一覧表示します。

  $ ps aux --sort=-%cpu | head
  
  USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  setroub+ 3196005 26.1  1.7 748920 139356 ?       SNsl 08:24   0:01 /usr/libexec/platform-python -Es /usr/sbin/setroubleshootd -f
  root     3196021 18.2  1.0 585332 86228 ?        Sl   08:24   0:00 /usr/libexec/platform-python /usr/share/setroubleshoot/SetroubleshootPrivileged.py
  root     2956484  1.3  1.0 108636 84416 ?        Sl   Oct29  18:29 kompirad: [Engine-5931] started
  root     2957605  1.3  1.1 113892 94288 ?        Sl   Oct29  18:38 kompirad: [Executor-1] started
  root     2957588  0.7  1.0 103240 86180 ?        Sl   Oct29   9:58 kompirad: [Executor-0] started
  root     2957623  0.7  1.0 102208 84336 ?        Sl   Oct29  10:15 kompirad: [Executor-2] started
  root     2957645  0.7  1.0  97256 80736 ?        Sl   Oct29  10:07 kompirad: [Executor-3] started
  root     4041128  0.7  3.8 2974996 299280 ?      Ssl  Oct27  31:20 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
  root     2957285  0.6  0.5  56088 43292 ?        Sl   Oct29   9:50 kompira_jobmngrd: [JobManager] started
  

  上記のコマンドを毎回実行し、高いリソース使用率が増加し続けて下がらないプロセスを調査します。 KE2 APP に関係がある処理 (たとえあば kompirad や kompira_jobmngrd や dockerd など) で高いリソースを消費している場合、Docker コンテナでご利用リソースの状況をご確認ください。

  特に、kompirad:Executor の CPU 使用量が急増し、非常に高い場合は、ジョブフローの設計や実装を見直してください。

  それ以外の処理で高いリソースを消費している場合、システム管理者と連携して、リソースを解放するために必要な手順を講じてください。必要ならサーバスペック、コア数を増やしてください。ホストサーバーの再起動は、一時的な解決策かもしれません。

• メモリ使用率を確認する

  ホストサーバのメモリ負荷の履歴を確認するために、以下のコマンドを実行して数日の平均メモリ使用量を確認します。

  数日前に、sysstat パッケージがインストールされていたと仮定します

  $ sar -r -f /var/log/sa/sa$(date --date="3 days ago" +%d)
  $ sar -r -f /var/log/sa/sa$(date --date="2 days ago" +%d)
  $ sar -r -f /var/log/sa/sa$(date --date="yesterday" +%d)
  $ sar -r -f /var/log/sa/sa$(date --date="today" +%d)
  

  上記の各コマンド実行すると以下のような結果が表示されます。

  08:50:04 PM kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
  09:00:00 PM   1499600   2776648   6369344     80.94       132   1455240   8134220     55.78   1025128   4286144      1364
  09:10:14 PM   1515532   2775416   6353412     80.74       132   1438076   8137516     55.80   1025540   4270032      1352
  09:20:02 PM   1516612   2778204   6352332     80.73       132   1439784   8136328     55.80   1025964   4268600        92
  09:30:13 PM   1511668   2775028   6357276     80.79       132   1441556   8129160     55.75   1026384   4272116      1360
  09:40:07 PM   1505828   2770888   6363116     80.86       132   1451448   8143276     55.84   1026792   4279196        88
  09:50:07 PM   1503888   2770660   6365056     80.89       132   1453160   8144972     55.86   1027216   4280068      1408
  10:00:08 PM   1499524   2768044   6369420     80.94       132   1454908   8144748     55.85   1027640   4283828      1368
  10:10:20 PM   1618340   2888632   6250604     79.43       132   1456668   8024212     55.03   1028060   4164820       120
  10:20:00 PM   1425136   2697108   6443808     81.89       132   1458360   8367948     57.38   1028472   4355864      1388
  10:30:19 PM   1492616   2766388   6376328     81.03       132   1460160   8138932     55.81   1028908   4288252      1352
  10:40:00 PM   1492240   2767680   6376704     81.04       132   1461832   8144272     55.85   1029316   4289300       104
  10:50:07 PM   1609696   2886836   6259248     79.54       132   1463512   8018288     54.99   1029720   4172520        88
  11:00:09 PM   1606720   2885612   6262224     79.58       132   1465280   8022040     55.01   1030156   4174036        44
  11:10:00 PM   1606476   2887048   6262468     79.58       132   1466952   8001308     54.87   1030560   4174380        64
  11:20:09 PM   1602572   2884868   6266372     79.63       132   1468684   8030580     55.07   1030980   4177176        44
  11:30:31 PM   1411720   2695804   6457224     82.06       132   1470476   8231824     56.45   1031420   4366480       100
  11:40:07 PM   1589248   2874944   6279696     79.80       132   1480260   8035704     55.11   1031788   4189460        12
  11:50:04 PM   1470172   2757572   6398772     81.32       132   1481984   8151500     55.90   1032192   4307644      1400
  Average:      1193391   2697519   6675553     84.83       132   1564541   8103370     55.57    999682   4408849       892
  

  ホストサーバに sysstat パッケージが以前からインストールされていなかった場合は、以下のコマンドで最新の状況を確認してください。

  $ sar -r 2 30
  

  結果の各行にご注意ください。特にに %user または %memused の使用率が高いか常に90%を超えている場合、メモリを増やすことをお勧めします。

  定常的に %memused の使用率が増加し続けて下がらない場合、何らかの処理がメモリを大量に消費している可能性があります。以下のコマンドでメモリを多く消費しているプロセスを特定します。

  $ ps aux --sort=-%mem | head
  
  USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  root     4041128  0.7  3.8 2974996 299280 ?      Ssl  Oct27  31:28 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
  root        3021  0.0  2.6 1010536 212360 ?      Ssl  Oct03   2:19 /usr/libexec/packagekitd
  root     2957006  0.5  2.6 1344704 204640 ?      Sl   Oct29   7:29 /opt/erlang/lib/erlang/erts-14.2.5.4/bin/beam.smp -W w -MBas ageffcbf -MHas ageffcbf -MBlmbcs 512 -MHlmbcs 512 -MMmcs 30 -pc unicode -P 1048576 -t 5000000 -stbt db -zdbbl 128000 -sbwt none -sbwtdcpu none -sbwtdio none -B i -- -root /opt/erlang/lib/erlang -bindir /opt/erlang/lib/erlang/erts-14.2.5.4/bin -progname erl -- -home /var/lib/rabbitmq -- -pa  -noshell -noinput -s rabbit boot -boot start_sasl -syslog logger [] -syslog syslog_error_logger false -kernel prevent_overlapping_partitions false
  root         746  0.0  2.3 317296 183364 ?       Ss   Oct03   8:20 /usr/lib/systemd/systemd-journald
  setroub+ 3201072 19.3  1.7 749188 141352 ?       SNsl 08:53   0:01 /usr/libexec/platform-python -Es /usr/sbin/setroubleshootd -f
  root     3188193  0.1  1.6 11859744 126852 ?     Sl   07:39   0:07 /root/.vscode-server/cli/servers/Stable-4849ca9bdf9666755eb463db297b69e5385090e3/server/node --dns-result-order=ipv4first /root/.vscode-server/cli/servers/Stable-4849ca9bdf9666755eb463db297b69e5385090e3/server/out/bootstrap-fork --type=extensionHost --transformURIs --useHostProxy=false
  root     2957605  1.3  1.1 113492 93920 ?        Sl   Oct29  19:00 kompirad: [Executor-1] started
  root     2957395  0.6  1.1 108984 88792 ?        Sl   Oct29   8:58 uwsgi --module=kompira_site.wsgi:application --env DJANGO_SETTINGS_MODULE=kompira_site.settings --master --pidfile=/tmp/kompira-master.pid --processes=5 --socket=0.0.0.0:8000 --enable-threads
  root     3188153  0.0  1.0 1332228 86480 ?       Sl   07:39   0:04 /root/.vscode-server/cli/servers/Stable-4849ca9bdf9666755eb463db297b69e5385090e3/server/node /root/.vscode-server/cli/servers/Stable-4849ca9bdf9666755eb463db297b69e5385090e3/server/out/server-main.js --connection-token=remotessh --accept-server-license-terms --start-server --enable-remote-auto-shutdown --socket-path=/tmp/code-84732503-7e19-4e61-9cec-d73ea5bb62ee
  

  上記のコマンドを毎回実行し、高いリソース使用率が増加し続けて下がらないプロセスを調査します。 KE2 APP に関係がある処理 (たとえあば kompirad や kompira_jobmngrd や uwsgi や dockerd など) で高いリソースを消費している場合、Docker コンテナでご利用リソースの状況をご確認ください。

  特に Executor のメモリ使用量が急増するようであればジョブフローの設計や実装を見直してください。

  それ以外の処理で高いリソースを消費している場合、システム管理者と連携して、リソースを解放するために必要な手順を講じてください。必要ならサーバスペック、メモリを増やしてください。ホストサーバーの再起動は、一時的な解決策かもしれません。

• VM で利用可能なディスクスペースを確認する:

  [ke2-rhel89-swarm-1]$ df -h
  
  Filesystem             Size  Used Avail Use% Mounted on
  devtmpfs               3.8G     0  3.8G   0% /dev
  tmpfs                  3.8G     0  3.8G   0% /dev/shm
  tmpfs                  3.8G  426M  3.4G  12% /run
  tmpfs                  3.8G     0  3.8G   0% /sys/fs/cgroup
  /dev/mapper/rhel-root   38G   13G   25G  34% /
  /dev/sda2             1014M  267M  748M  27% /boot
  /dev/sda1              599M  5.8M  594M   1% /boot/efi
  /dev/mapper/rhel-home   19G  180M   19G   1% /home
  tmpfs                  769M   12K  769M   1% /run/user/42
  tmpfs                  769M     0  769M   0% /run/user/0
  localhost:/gvol0        38G   14G   25G  36% /mnt/gluster
  

  空きディスクスペースが十分にあるか確認します。空きスペースが不足している場合は不要なファイルを削除します。

ホストサーバーが高いリソースを使用している場合、Dockerデーモンが不安定になる可能性があります。その際、Dockerのログには以下のようなエラーが表示される可能性があります。

クラスタ構成の場合、

• Docker 不安定性
• docker ログに「error while reading from stream」というエラーが記録されている

シングル構成の場合、

• docker デーモン不安定

DIAG-A3: docker の正常動作の確認

全てのノードで docker が正常に動作していることを確認してください。

• docker が実行中場合

  以下のコマンドで Active: active (running) と表示されていれば、Docker は実行中です。

  $ systemctl status docker.service
  
  docker.service - Docker Application Container Engine
  Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
  Active: active (running) since Tue 2024-10-01 14:53:15 JST; 1 weeks 2 days ago
      Docs: https://docs.docker.com
  Main PID: 1489 (dockerd)
      Tasks: 15
  Memory: 563.4M
  CGroup: /system.slice/docker.service
          └─1489 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
  

• docker が停止している場合

  以下のコマンドで Active: inactive (dead) と表示されている場合は、Docker は何らかの異常が発生して停止しています。

  $ systemctl status docker.service
  
  docker.service - Docker Application Container Engine
  Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
  Active: inactive (dead) since Thu 2024-10-10 16:57:52 JST; 2s ago
      Docs: https://docs.docker.com
  Process: 1489 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=0/SUCCESS)
  Main PID: 1489 (code=exited, status=0/SUCCESS)
  

  停止してしまった場合、まず、以下のコマンドで Docker を起動し、再度ステータスを確認します。

  $ systemctl start docker.service
  

  何らかの異常が残っている場合は、docker を起動しても安定して動作できないこともあります。そうしたときは docker のログを確認してみてください。

  クラスタ構成の場合、

  • Docker 不安定性

  シングル構成の場合、

  • docker デーモン不安定

  ＊ Docker デーモンの不安定はさまざまな原因で発生する可能性がありますが、通常はサーバーリソースが原因です。

  • ホストサーバのリソース状況の確認

DIAG-A4: ネットワーク導通の確認

• クライアントとホスト間のネットワーク導通を確認してください。

  # [クライアント]$ ping -c 5 <KE2 APP ホストサーバ IP>
  # 例: 
  $ ping -c 5 10.20.47.12
  
  PING 10.20.47.12 (10.20.47.12) 56(84) bytes of data.
  64 bytes from 10.20.47.12: icmp_seq=1 ttl=64 time=0.041 ms
  64 bytes from 10.20.47.12: icmp_seq=2 ttl=64 time=0.028 ms
  64 bytes from 10.20.47.12: icmp_seq=3 ttl=64 time=0.036 ms
  64 bytes from 10.20.47.12: icmp_seq=4 ttl=64 time=0.032 ms
  64 bytes from 10.20.47.12: icmp_seq=5 ttl=64 time=0.032 ms
  
  --- 10.20.47.12 ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4103ms
  rtt min/avg/max/mdev = 0.028/0.033/0.041/0.008 ms
  

  応答があることを確認してください。答えがない場合以下ような結果が表示される。

  # [クライアント]$ ping -c 5 <KE2 APP ホストサーバ IP>
  # 例：
  $ ping -c 5 10.20.47.12
  
  PING 10.20.47.12 (10.20.47.12) 56(84) bytes of data.
  From 10.20.47.12 icmp_seq=1 Destination Host Unreachable
  From 10.20.47.12 icmp_seq=2 Destination Host Unreachable
  From 10.20.47.12 icmp_seq=3 Destination Host Unreachable
  From 10.20.47.12 icmp_seq=4 Destination Host Unreachable
  From 10.20.47.12 icmp_seq=5 Destination Host Unreachable
  
  --- 10.20.47.12 ping statistics ---
  5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4094ms
  pipe 3
  

  様々な理由でこのようなこのような状況発生される可能性があります。

  • ホストサーバの正常性の確認
  • KE2 APP ホストサーバのネットワークインターフェイスの状態を確認してください
  • KE2 APP ホストサーバの Network 設定確認してください。

  ＊ クラスタ構成の場合、上と同じようにクライアントと各ホスト間のネットワーク導通を確認してください。

• クラスタ構成の場合、KE2 APP ホストサーバの全てのノード間のネットワーク導通を確認してください。

  • ping コマンドで応答があることを確認してください。応答がない場合は、以下のような調査をしてみてください。

    • ホストサーバの正常性の確認
    • KE2 APP ホストサーバのネットワークインターフェイスの状態を確認してください
    • KE2 APP ホストサーバの Network 設定確認してください。

    ノード間のネットワーク導通に問題があるときは、docker ログにエラーが記録されている場合がありますので、以下について確認してみてください。

    • ネットワークの問題または特定ノードのインターフェイスのダウン
    • 特定 Swarm ノードダウン・VMダウン・ネットワーク障害

  • ping が成功になっていますが高い遅延の可能性もあります。

    $ ping -c 10 -i 2 10.20.47.11
    PING 10.20.47.11 (10.20.47.11) 56(84) bytes of data.
    Request timeout for icmp_seq 1
    Request timeout for icmp_seq 2
    Request timeout for icmp_seq 3
    64 bytes from 10.20.47.11: icmp_seq=4 ttl=57 time=2002 ms
    Request timeout for icmp_seq 5
    Request timeout for icmp_seq 6
    64 bytes from 10.20.47.11: icmp_seq=7 ttl=57 time=2003 ms
    Request timeout for icmp_seq 8
    Request timeout for icmp_seq 9
    64 bytes from 10.20.47.11: icmp_seq=10 ttl=57 time=2001 ms
    
    --- 10.20.47.11 ping statistics ---
    10 packets transmitted, 3 received, 70% packet loss, time 18003ms
    rtt min/avg/max/mdev = 2001/2002/2003/0.5 ms
    

    高いネットワーク遅延またはパケットロス場合、docker ログ見ると以下ようなエラー表示される可能性です。

    • 外部データベースまたはSwarmノードとの高いネットワーク遅延
    • Swarmノードとの高いネットワーク遅延

ネットワークの保守手順については、本マニュアルの範囲外になります。

DIAG-A5: KE2 APP ホストサーバと外部データベース間のネットワーク導通の確認

外部 DB がシングル構成またはクラスタ構成の場合、外部 DB が使用されています。KE2 APP ホストサーバーと外部データベース間のネットワーク接続に問題があると、Docker で操作中の kompira コンテナや kengine コンテナに直接影響を及ぼします。

KE2 APP ホストサーバから DB サーバに ping 失敗

外部 DB サーバが ping に応答する構成の場合は、様々な原因で KE2 APP ホストサーバから外部 DB ホストサーバに ping しても答えがない可能性があります。以下の確認を行なってみてください。

• 外部 DB ホストサーバの正常性をご確認ください。
• 外部 DB ホストサーバのネットワークインターフェイスの状態を確認してください。
• 外部 DB ホストサーバの Network 設定を確認してください。

KE2 のログ分析すると以下ようなログ表示される可能性があります。

docker ログ:

• 外部データベースまたはSwarmノードとの高いネットワーク遅延

kompira コンテナログ:

• 外部 DB がシングル構成場合、kengine ログに「Is the server running on that host and accepting TCP/IP connections? Host is unreachable」というエラーが記録されている
• クラスタ構成場合、kengine ログに「Is the server running on that host and accepting TCP/IP connections? Host is unreachable」というエラーが記録されている

KE2 APP ホストサーバーから DB サーバーに ping を実行し、ネットワークに高い遅延の確認。

ping が成功になっていますが高い遅延の可能性もあります。

$ ping -c 10 -i 2 10.20.47.20
PING 10.20.47.20 (10.20.47.20) 56(84) bytes of data.
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 10.20.47.20: icmp_seq=4 ttl=57 time=2002 ms
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
64 bytes from 10.20.47.20: icmp_seq=7 ttl=57 time=2003 ms
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
64 bytes from 10.20.47.20: icmp_seq=10 ttl=57 time=2001 ms

--- 10.20.47.20 ping statistics ---
10 packets transmitted, 3 received, 70% packet loss, time 18003ms
rtt min/avg/max/mdev = 2001/2002/2003/0.5 ms

高いネットワーク遅延またはパケットロスがあれば解決してください。

ネットワークの保守手順については、本マニュアルの範囲外になります。

外部 DB Pgpool ご利用場合、 Pgpool のノード間のネットワーク遅延確認

Pgpool のノード間のネットワーク遅延を確認してください。Pgpool のノード間のネットワークの問題があればKE2 に影響を及ぼします。

KE2 ログ見ると以下ような情報表示だれます。

• クラスタ場合、kengine ログに「ERROR: unable to read message kind DETAIL: kind does not match between main(4e) slot[1] (53)」というエラーが記録されている
• 外部 DB がシングル構成場合、kengine ログに「ERROR: unable to read message kind DETAIL: kind does not match between main(4e) slot[1] (53)」というエラーが記録されている

ネットワークの保守手順については、本マニュアルの範囲外になります。

DIAG-A6: 外部データベースへのアクセス確認

KE2 APP のホストサーバから外部 DB にアクセスの確認

psql コマンドが利用できない場合は、CentOS/RHEL: postgresql、Debian/Ubuntu: postgresql-client をインストールしてください

外部 DB にアクセスの確認

以下のコマンド実行します。アクセスが成功になると以下ような情報見ることができます

# ベーシックコマンド: psql -h <DB IP> -p <DB PORT> -U <USER> -d <DATABASE>
# pgpool場合、DB IP は Virtual IP です。DB PORT は defaultでは 9999 です。
# postgres場合、DB IP は DB サーバ IP です。DB PORT は defaultでは 5432 です。
# USER は postgres です。
# DATABASE は kompira です。
# 例：
$ psql -h 10.20.47.20 -p 9999 -U postgres -d kompira -c "SELECT 1;"

Password for user postgres: ****
 ?column? 
----------
        1
(1 row)

アクセス失敗場合、以下のような情報表示されます

$ psql -h 10.20.47.20 -p 9999 -U postgres -d kompira -c "SELECT 1;"

psql: could not connect to server: No route to host
	Is the server running on host "10.20.47.20" and accepting
	TCP/IP connections on port 9999?

DB サーバダウンかネットワークに到達できない場合このような状況発生されます。

KE2 のログに以下のようなエラーが記録されている場合があります。

• 外部 DB がシングル構成場合、kengine ログに「Is the server running on that host and accepting TCP/IP connections? Connection refused」というエラーが記録されている
• クラスタ構成場合、kengine ログに「Is the server running on that host and accepting TCP/IP connections? Connection refused」というエラーが記録されている

DB 操作の確認

# ベーシックコマンド: psql -h <DB IP> -p <DB PORT> -U <USER> -d <DATABASE>
# pgpool場合、DB IP は Virtual IP です。DB PORT は defaultでは 9999 です。
# postgres場合、DB IP は DB サーバ IP です。DB PORT は defaultでは 5432 です。
# USER は postgres です。
# DATABASE は kompira です。
# 例：
$ psql -h 10.20.47.20 -p 9999 -U postgres -d kompira -c "CREATE TEMP TABLE pg_temp.test_table (value TEXT); INSERT INTO pg_temp.test_table (value) VALUES ('Dummy Test Value'); SELECT * FROM pg_temp.test_table;"

Password for user postgres: *****
      value       
------------------
 Dummy Test Value
(1 row)

問題があれば、外部 DB 管理者に連絡してください。

KE2 のログに以下のようなエラーが記録されている場合がありますので、ログを確認してみてください。

• クラスタ構成場合、kengine ログに「database error: cannot execute UPDATE in a read-only transaction」というエラーが記録されている
• 外部 DB がシングル構成場合、kengine ログに「database error: cannot execute UPDATE in a read-only transaction」というエラーが記録されている

外部 DB の保守手順については、本マニュアルの範囲外になります。

DIAG-A7: クラスタ構成における共有ファイルシステム glusterd の正常動作の確認

全てのノードで glusterd が正常に動作していることを確認してください。

• glusterd が実行中場合

  以下のコマンドで Active: active (running) と表示されていれば、 glusterd は実行中です。

  $ systemctl status glusterd
  
  glusterd.service - GlusterFS, a clustered file-system server
  Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
  Active: active (running) since Mon 2024-09-23 19:31:39 JST; 3 weeks 3 days ago
   Docs: man:glusterd(8)
  Process: 1168 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited,>
  Main PID: 1192 (glusterd)
  Tasks: 39 (limit: 48801)
  Memory: 136.4M
  CGroup: /system.slice/glusterd.service
         ├─   1192 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO
  

• glusterd が停止した場合

  以下のコマンドで Active: inactive (dead) と表示されていれば、Docker は停止してしまった。

  $ systemctl status docker.service
  
  glusterd.service - GlusterFS, a clustered file-system server
  Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
  Active: inactive (dead) since Fri 2024-10-18 09:08:46 JST; 1s ago
   Docs: man:glusterd(8)
  Process: 1168 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited,>
   Main PID: 1192 (code=exited, status=15)
  Tasks: 31 (limit: 48801)
  Memory: 126.3M
  CGroup: /system.slice/glusterd.service
  

  停止してしまった場合、以下のコマンドで glusterd を起動し、再度ステータスを確認します。

  $ systemctl start glusterd
  

  glusterd を起動しても glusterd の不安定の可能性もあります。ざまざまな原因でこのような状況発生するの可能性があります。 主にホストサーバのリソース正常にあるかどうかご確認ください。

  • ホストサーバのリソース状況の確認

クラスタノードの診断手順

共有ファイルシステム (glusterfs)の正常性確認

glusterd の正常性確認

すべての glusterd ノードの `State` が `Connected` であることを確認してください。

```bash
$ gluster pool list

UUID					Hostname          	State
448d38ce-bc9c-4bca-ae77-8876cbb4ab32	ke2-rhel89-swarm-1	Connected 
28cdd9bc-4a49-48ac-a7ab-635f35e90bda	ke2-rhel89-swarm-3	Connected 
0760ce31-9b1e-4697-980e-721bbd0f4862	localhost         	Connected 
```

- いずれかの gluster ノードの State が Disconnected 状態になっている場合は、そのホストの glusterd サービスが正常に動作していなかったり、ネットワークに問題が生じているといった可能性があります。
    ```bash
    $ gluster pool list

    UUID					Hostname          	State
    448d38ce-bc9c-4bca-ae77-8876cbb4ab32	ke2-rhel89-swarm-1	Disconnected 
    28cdd9bc-4a49-48ac-a7ab-635f35e90bda	ke2-rhel89-swarm-3	Connected 
    0760ce31-9b1e-4697-980e-721bbd0f4862	localhost         	Connected
    ```

    このような状況の場合、以下の確認を行なってみてください。
    - [ホストサーバの正常性の確認](./host-server-diag.html#diag-a1-ホストサーバの正常性の確認)
    - [クラスタ構成における共有ファイルシステム glusterd の正常動作の確認](./host-server-diag.html#diag-a7-クラスタ構成における共有ファイルシステム-glusterd-の正常動作の確認)
    - [ネットワーク導通の確認](./host-server-diag.html#diag-a4-ネットワーク導通の確認)

    上記の対策を行なっても回復しない場合は、サポートまでお問い合わせください

gluster ボリューム の正常性確認

すべてのノードの gluster ボリューム状態 `Status` が `Started` であることを確認してください。
```bash
$ gluster volume info

Volume Name: gvol0
Type: Replicate
Volume ID: 71d358be-7b95-4c03-a528-9cb15d37a3c3
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: ke2-rhel89-swarm-1:/var/glustervol0
Brick2: ke2-rhel89-swarm-2:/var/glustervol0
Brick3: ke2-rhel89-swarm-3:/var/glustervol0
Options Reconfigured:
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off
```

- ボリューム `Status` が `Stopped` になっている場合、 そのノードのボリュームが停止されてしまったの可能性があります。
    ```bash
    $ gluster volume info

    Volume Name: gvol0
    Type: Replicate
    Volume ID: 71d358be-7b95-4c03-a528-9cb15d37a3c3
    Status: Stopped
    Snapshot Count: 0
    Number of Bricks: 1 x 3 = 3
    Transport-type: tcp
    Bricks:
    Brick1: ke2-rhel89-swarm-1:/var/glustervol0
    Brick2: ke2-rhel89-swarm-2:/var/glustervol0
    Brick3: ke2-rhel89-swarm-3:/var/glustervol0
    Options Reconfigured:
    cluster.granular-entry-heal: on
    storage.fips-mode-rchecksum: on
    transport.address-family: inet
    nfs.disable: on
    performance.client-io-threads: off
    ```

    この状況なら以下のコマンドでボリュームを起動してください。
    ```bash
    $ gluster volume start <volume-name>

    volume start: <volume-name>: success
    ```  

gluster ボリュームのマウントの正常性確認

すべての glusterd ノードにおいて gluster ボリュームがマウントされていることを確認してください。mount コマンドを実行すると `localhost:/gvol0 on /mnt/gluster` という表示があるはずです
```bash
$ mount | grep gluster

localhost:/gvol0 on /mnt/gluster type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)
```

gluster ボリュームがマウントされていない場合は、以下のコマンドでマウントしてください。
 ```bash
 $ mount -t glusterfs localhost:/gvol0 /mnt/gluster
 ```

＊ 特定のノードで gluster ボリュームが正しくマウントされない場合は、kompira コンテナのログで以下のようなエラーが記録されることがあります。

• kompira ログに「KeyError: 'staticfiles'」というエラーが記録されている

swarm ノードのステータスの正常性確認

swarm ノードの正常性については、docker node ls コマンドの結果から以下を確認してください。

• すべてのノードの STATUS が Ready であること。
• すべてのノードの Availability が Active であること。
• MANAGER STATUS については、1 台が Leader であり、残りのノードが Reachable であること。
• すべてのノードの ENGINE VERSION が同一であること。

$ docker node ls

ID                            HOSTNAME             STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
fki8ndj78y2khgyt7j6xn2duf     ke2-rhel89-swarm-1   Ready     Active         Reachable        26.1.3
ly4ik4v3pw9rgom0htt281aus *   ke2-rhel89-swarm-2   Ready     Active         Reachable        26.1.3
if1r8znj7v7dsym4r9ya26gmt     ke2-rhel89-swarm-3   Ready     Active         Leader           26.1.3

• マネージャーの半数以上がオンラインでない、または正常でない場合、次のエラーが発生します。

  $ docker node ls
  
  Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader.
  It's possible that too few managers are online. Make sure more than half of the managers are online.
  

  このような状況の場合、全てのノードで以下の診断手順を行なってみてください。

  • ホストサーバの正常性の確認
  • ネットワーク導通の確認
  • docker の正常動作の確認

  上記の調査で問題を見つけて修正した場合、あらためて docker node ls コマンドを実行して Swarm ノードの状況を確認してください。STATUS、AVAILABILITY、MANAGER STATUS などが正常であれば、KE2 クラスタは正常であると言えます。

  まだ、swarm クラスタは正常ではない場合、必要なポートが開いていない可能性があります。この場合、ファイアウォールの設定 を見てください。

  それでも swarm クラスタが正常に戻らない場合は、各 VM を一度再起動してみてください。Docker の自動起動設定が有効であれば、swarm クラスタは正常に戻るはずです。

  swarm クラスタが正常に戻っても KE2 APP が全体的に操作しない可能性があります。

  その時、まずはすべてのノードの gluster ボリュームの正常性確認を行ってください。そして、KE2 APPを以下の手順で再デプロイしてください。

  [いずれかのノード]$ docker stack rm ke2
  [いずれかのノード]$ cd ke2/cluster/swarm
  [いずれかのノード]$ docker stack deploy -c docker-swarm.yml ke2
  

  最後に、KE2 APP の全体ステータスをご確認ください。

• もしいずれかのノードの MANAGER STATUS が Unreachable と STATUS が Down 状態になっている場合、 そのノードが止めされてしまったの可能性があります。

  $ docker node ls
  
  ID                            HOSTNAME             STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
  fki8ndj78y2khgyt7j6xn2duf     ke2-rhel89-swarm-1   Down      Active         Unreachable      26.1.3
  ly4ik4v3pw9rgom0htt281aus *   ke2-rhel89-swarm-2   Ready     Active         Reachable        26.1.3
  if1r8znj7v7dsym4r9ya26gmt     ke2-rhel89-swarm-3   Ready     Active         Leader           26.1.3
  

  上の状況が起きた場合、問題があるノードで以下の分析を行ってください。

  • ホストサーバの正常性の確認
  • docker の正常動作の確認
  • ネットワーク導通の確認

  問題が解決できない場合、必要なポートが開いていない可能性があります。この場合、ファイアウォールの設定 を見てください。

  それでも問題が解決しない場合は、問題があるノードを再起動してください。docker と glusterfs 自動起動設定があれば特定の ホストの swarm node と 関係があるコンテナが自動回復になります。

  そして、KE2 APP の全体ステータスをみてください。

上記の対策を行なっても回復しない場合は、サポートまでお問い合わせください。

コンテナの診断手順

DIAG-C1: Docker コンテナで利用のリソース状況の確認

Docker コンテナのリソース状況を確認してください。 クラスタ構成の場合は全てのノードの状態を確認するようにしてください。

• CPU 使用率
• メモリ使用率
• PID 処理が多くすぎて

以下のコマンド Docker で操作中コンテナご利用のリソース状況を見ることができます。

$ docker stats --no-stream

CONTAINER ID   NAME                                       CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
b2bf672eee1e   ke2_jobmngrd.3.0h8v6lwpw3oh87wg07n09jrvc   0.20%     36.84MiB / 7.504GiB   0.48%     6.98kB / 6.99kB   0B / 0B           8
3da2cfa36197   ke2_rabbitmq.3.y8sg4tdm469ik51w2kw915psm   0.36%     130.7MiB / 7.504GiB   1.70%     19.4MB / 20.5MB   0B / 9.08MB       33
6f1befa797c4   ke2_kengine.2.dt80bscpolhaa2t4fk8x3410l    3.04%     392.7MiB / 7.504GiB   5.11%     264kB / 236kB     16.4kB / 0B       43
dfc85d84573f   ke2_nginx.2.3q62nqjhlkz6jnmudx0dk6vsv      0.00%     5.406MiB / 7.504GiB   0.07%     437kB / 1.44MB    8.19kB / 55.3kB   5
31d90be86621   ke2_kompira.2.ocsgjfl315v3yrkjqcr1tg2uo    1.57%     220.6MiB / 7.504GiB   2.87%     458kB / 520kB     328kB / 0B        16

1. いずれかのコンテナのCPU、メモリ、またはI/O使用率がたとえば95％を超えている場合、KE2 APP ご利用時に、速度が非常に遅いか異常の可能性があります。その時に特定のコンテナを再起動し、また KE2 APP の状況をご確認ください。

   $ docker restart <コンテナ ID>
   

2. 複数コンテナのCPU、メモリ、またはI/O使用率がたとえば95％を超えている場合、KE2 APP ご利用時に、速度が非常に遅いか異常の可能性があります。その時に KE2 APP を再起動してください。

DIAG-C2: Docker コンテナの正常性の確認

Dockerコンテナはさまざまな理由で異常になる可能性があります。

• 高いリソース利用率により、時々コンテナが停止してしまうことがありますが、正常化してもコンテナが復旧しない場合があります。
• コンテナ内部でエラーが発生し、停止してしまった可能性があります。
• 外部データベースを使用している場合、DBアクセスの問題でもコンテナが停止・再起動を繰り返す可能性があります。

シングル構成におけるコンテナの正常性の確認

シングル構成では、1台のVM上のDockerで以下の7個のコンテナが動かします。

• nginx
• redis
• kompira
• kengine
• postgresql
• rabbitmq
• jobmngrd

実行中コンテナの確認

実行中コンテナの一覧以下のコマンドで確認ことができます。

$ docker container ls

CONTAINER ID   IMAGE                                                  COMMAND                  CREATED      STATUS               PORTS                                                                                       NAMES
32fe4cedfab3   registry.hub.docker.com/library/nginx:1.27-alpine      "/docker-entrypoint.…"   6 days ago   Up 6 days            0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp                    ke2-nginx-1
6d63244c268c   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   6 days ago   Up 6 days                                                                                                        ke2-kompira-1
5a8808b6f97b   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   6 days ago   Up 6 days                                                                                                        ke2-kengine-1
c2a13a549267   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   6 days ago   Up 6 days                                                                                                        ke2-jobmngrd-1
9af8671ec4b8   registry.hub.docker.com/library/rabbitmq:3.13-alpine   "docker-entrypoint.s…"   6 days ago   Up 6 days            4369/tcp, 5672/tcp, 15691-15692/tcp, 25672/tcp, 0.0.0.0:5671->5671/tcp, :::5671->5671/tcp   ke2-rabbitmq-1
c53e47ff9826   registry.hub.docker.com/library/redis:7.2-alpine       "docker-entrypoint.s…"   6 days ago   Up 6 days            6379/tcp                                                                                    ke2-redis-1
35f1ae144b49   registry.hub.docker.com/library/postgres:16.3-alpine   "docker-entrypoint.s…"   6 days ago   Up 6 days            5432/tcp                                                                                    ke2-postgres-1

上の結果見ると7個コンテナのステータスは UP になるべきです。さらに 手動で再起動されていない場合、 CREATED と UP 期間が大体同じであるべきです。

手動で再起動していないにもかかわらず、UP と CREATED の期間が大体同じでない場合は、途中で何か問題が発生し、再起動された可能性があります。その場合、UP 期間が長い場合は、特定のコンテナが再起動されたものの、安定して実行中であることを意味します。以下のコマンドを使用して再起動回数を確認できます。

# コマンド形式: docker inspect --format='{{.RestartCount}}' <コンテナ ID>
# 例
$ docker inspect --format='{{.RestartCount}}' 060dca0960a9

3

このような場合は、サポートまでお問い合わせください。

UP 期間が短い場合は、docker container ls コマンドを定期的に実行して、UP 期間が頻繁に変わっているかどうかを確認してください。頻繁に変わっている場合は、以下の調査を進めてください。

• コンテナが操作中ですが異常か再起度を繰り返す

一覧で7個コンテナがない場合、以下の調査を進んでください。

• 特定のコンテナが停止

外部 DB シングル構成におけるコンテナの正常性の確認

外部 DB シングル構成では、1台のVM上のDockerで以下の6個のコンテナが動かします。

• nginx
• redis
• kompira
• kengine
• rabbitmq
• jobmngrd

実行中コンテナの確認

実行中コンテナの一覧以下のコマンドで確認ことができます。

$ docker container ls

CONTAINER ID   IMAGE                                                  COMMAND                  CREATED      STATUS               PORTS                                                                                       NAMES
32fe4cedfab3   registry.hub.docker.com/library/nginx:1.27-alpine      "/docker-entrypoint.…"   6 days ago   Up 6 days            0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp                    ke2-nginx-1
6d63244c268c   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   6 days ago   Up 6 days                                                                                                        ke2-kompira-1
5a8808b6f97b   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   6 days ago   Up 6 days                                                                                                        ke2-kengine-1
c2a13a549267   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   6 days ago   Up 6 days                                                                                                        ke2-jobmngrd-1
9af8671ec4b8   registry.hub.docker.com/library/rabbitmq:3.13-alpine   "docker-entrypoint.s…"   6 days ago   Up 6 days            4369/tcp, 5672/tcp, 15691-15692/tcp, 25672/tcp, 0.0.0.0:5671->5671/tcp, :::5671->5671/tcp   ke2-rabbitmq-1
c53e47ff9826   registry.hub.docker.com/library/redis:7.2-alpine       "docker-entrypoint.s…"   6 days ago   Up 6 days            6379/tcp                                                                                    ke2-redis-1

上の結果見ると6個コンテナのステータスは UP になるべきです。さらに 手動で再起動されていない場合、 CREATED と UP 期間が大体同じであるべきです。

手動で再起動していないにもかかわらず、UP と CREATED の期間が大体同じでない場合は、途中で何か問題が発生し、再起動された可能性があります。その場合、UP 期間が長い場合は、特定のコンテナが再起動されたものの、安定して実行中であることを意味します。以下のコマンドを使用して再起動回数を確認できます。

# コマンド形式: docker inspect --format='{{.RestartCount}}' <コンテナ ID>
# 例
$ docker inspect --format='{{.RestartCount}}' 060dca0960a9

3

このような場合は、サポートまでお問い合わせください。

UP 期間が短い場合は、docker container ls コマンドを定期的に実行して、UP 期間が頻繁に変わっているかどうかを確認してください。頻繁に変わっている場合は、以下の調査を進めてください。

• コンテナが操作中ですが異常か再起度を繰り返す

一覧で6個コンテナがない場合、以下の調査を進んでください。

• 特定のコンテナが停止

クラスタ構成におけるコンテナの正常性の確認

クラスタ構成では、3台のVM上にそれぞれ1つのDockerが動かします。各 Docker で以下の5個のコンテナが動かします。

• nginx
• kompira
• kengine
• rabbitmq
• jobmngrd

そして、いずれかの Docker で redis コンテナが動かします。

まとめると、2つの Docker で5個のコンテナが動かし、いずれかの1つの Docker で6個のコンテナが動かします。

次のコマンドを使用して要約を確認できます。

$ docker service ls

ID             NAME           MODE         REPLICAS               IMAGE                                                  PORTS
rurnpyfpcktj   ke2_jobmngrd   replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
tnu0hcrabygs   ke2_kengine    replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
sdbpxueuch8b   ke2_kompira    replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
k5oo0qcki35j   ke2_nginx      replicated   3/3 (max 1 per node)   registry.hub.docker.com/library/nginx:1.27-alpine      *:80->80/tcp, *:443->443/tcp
0hcwtac3ode7   ke2_rabbitmq   replicated   3/3 (max 1 per node)   registry.hub.docker.com/library/rabbitmq:3.13-alpine   *:5671->5671/tcp
ccind6pgdon6   ke2_redis      replicated   1/1                    registry.hub.docker.com/library/redis:7.2-alpine  

上の結果見ると、5個のコンテナに対して5個サービスの REPLICAS は 3/3 であり、redis サービスの REPLICAS は 1/1 であるべきです。

特定のサービスの REPLICAS は上の通りではないと以下のコマンドで特定のサービスの詳細を見てください。

# コマンドの形式: docker service ps <サービス名>
# 例
$ docker service ps ke2_kengine

ID             NAME                IMAGE                                          NODE                 DESIRED STATE   CURRENT STATE          ERROR                         PORTS
w9qmsxko0tax   ke2_kengine.1       kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Running         Running 2 weeks ago                                  
rclffpisgc4z    \_ ke2_kengine.1   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Shutdown        Shutdown 2 weeks ago                                 
24rkaui1m3n4    \_ ke2_kengine.1   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
bkx5pswzwzf3    \_ ke2_kengine.1   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
s60vnnmd81jq    \_ ke2_kengine.1   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
ybtuiii4nfuu   ke2_kengine.2       kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Running         Running 2 weeks ago                                  
lf9am9v6ekus    \_ ke2_kengine.2   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
l42bxx6bj6oy    \_ ke2_kengine.2   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
wtbtanje9kxd    \_ ke2_kengine.2   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
v8qlsqyy2fpi    \_ ke2_kengine.2   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
vi28sw06hx55   ke2_kengine.3       kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Running         Running 2 weeks ago                                  
yld6w5fljlp4    \_ ke2_kengine.3   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Shutdown        Shutdown 2 weeks ago                                 
yp1ckgfg4we6    \_ ke2_kengine.3   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Shutdown        Shutdown 2 weeks ago                                 
0mywy77r4b29    \_ ke2_kengine.3   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
pdwyb8o5wrvx    \_ ke2_kengine.3   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   

特定のノード上のコンテナの CURRENT STATE が Running であっても、実行中の期間が短く、さらに Running 以外のステータス（例えば、Shutdown や Failed など）が多いと期間が短く場合、そのコンテナは不安定な状態にあると言えます。この場合、特定のノードで以下の調査を進めてください。

• コンテナが操作中ですが異常か再起度を繰り返す

特定のノード上のコンテナの CURRENT STATE が Running ではない場合、特定のノードで以下の調査を進めてください。

• 特定のコンテナが停止

KE2 APP を再起動する

様々な調査でも KE2 APP が正常に戻らないの可能性があります。その時に以下の方法で再起動してください。

シングル構成場合

まずは、以下のコマンで docker サービスを再起動して KE2 APP の状況をみてください。

$ systemctl restart docker.service

そして、KE2 APP の全体ステータスをご確認ください。

まだ、KE2 APP が正常に戻らない場合、ホストサーバを再起動してみてください。

外部 DB シングル構成場合

まずは、以下のコマンで docker サービスを再起動して KE2 APP の状況をみてください。

$ systemctl restart docker.service

そして、KE2 APP の全体ステータスご確認ください。

まだ、KE2 APP が正常に戻らない場合、ホストサーバを再起動してみてください。

クラスタ構成場合

3台の VM のうち1台で KE2 APP の操作が停止

まずは、エラーが発生されている VM の上以下のコマンドを実行して docker サービスを再起動します。

$ systemctl restart docker.service

Docker が起動できたら、ノードの KE2 APP のステータスをご確認ください。

KE2 APP が正常に戻らない場合、エラーが発生されている特定の VM を再起動してみてください。

docker と glusterfs 自動起動設定があれば特定のノードと関係があるコンテナが自動回復になります。

VM が起動できたら、ノードの KE2 APP のステータスをご確認ください。

KE2 APP 操作が全体的に停止

まずは、一つ術各 VM の上以下のコマンを実行して docker サービスを再起動して KE2 APP の全体ステータスをみてください。

$ systemctl restart docker.service

まだ、KE2 APP が正常に戻らない場合、一つ術すべての VM を再起動してみてください。

docker と glusterfs 自動起動設定があれば再起動されたノードと関係があるコンテナが自動回復になります。

それでも、KE2 APP が正常に戻らない場合、クラスタを再起動しててみてください。以下の手順に従ってください。

[いずれかのノード]$ docker stack rm ke2
[いずれかのノード]$ cd ke2/cluster/swarm
[いずれかのノード]$ docker stack deploy -c docker-swarm.yml ke2

そして、KE2 APP の全体ステータスをみてください。

RabbitMQのボリュームが破損し、KE2 APPの操作が全体的に異常になる場合があります。 クラスタ構成における障害を回復させる手順のひとつとして、rabbitmq が利用しているボリュームを削除してからクラスタを再デプロイさせるというものがあります。

ここでは rabbitmq のボリュームを削除する手順について示します。

rabbitmq のボリュームを削除する手順

推奨がない場合は、この手順を実行しないでください

rabbitmq のボリュームを削除する前に、いったんクラスタを削除する必要があります。クラスタを削除しない場合は、Swarmクラスタのいずれかのノード上で以下のコマンドを実行してください

[いずれかのノード]$ docker stack rm ke2

docker ボリューム削除時にボリュームの名前必要です。以下のコマンドで docker ボリューム一覧を見てください。

[いずれかのノード]$ docker volume ls

DRIVER    VOLUME NAME
local     swarm_kompira_rmq

そして、全てのノードで以下のコマンド実行して rabbitmq ボリュームを削除してください。

[すべてのノード]$ docker volume rm swarm_kompira_rmq

そして、以下の手順で KE2 APP を再デプロイしてください。

[いずれかのノード]$ cd ke2/cluster/swarm
[いずれかのノード]$ docker stack deploy -c docker-swarm.yml ke2

コンテナ特有の調査

構成毎に各 VM の上 Docker で実行中コンテナ数が変わるの可能性があります。KE2 構成に基づいてコンテナ配置は以下の通りです。

特定のコンテナが停止

以下のコマンドで停止・実行中全てのコンテナを見ることができます。

$ docker ps --all

CONTAINER ID   IMAGE                                                  COMMAND                  CREATED         STATUS                     PORTS                                                                                       NAMES
40891df54a19   registry.hub.docker.com/library/nginx:1.27-alpine      "/docker-entrypoint.…"   8 minutes ago   Up 8 minutes               0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp                    ke2-nginx-1
7fb7a27751e8   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   8 minutes ago   Up 8 minutes                                                                                                           ke2-kompira-1
f56618dfc99b   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   8 minutes ago   Up 8 minutes                                                                                                           ke2-kengine-1
8b589b774d51   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   8 minutes ago   Up 8 minutes                                                                                                           ke2-jobmngrd-1
3238e086adf2   registry.hub.docker.com/library/rabbitmq:3.13-alpine   "docker-entrypoint.s…"   8 minutes ago   Up 8 minutes               4369/tcp, 5672/tcp, 15691-15692/tcp, 25672/tcp, 0.0.0.0:5671->5671/tcp, :::5671->5671/tcp   ke2-rabbitmq-1
9a5667fc5efa   registry.hub.docker.com/library/postgres:16.3-alpine   "docker-entrypoint.s…"   8 minutes ago   Up 8 minutes               5432/tcp                                                                                    ke2-postgres-1
8934b6f15223   registry.hub.docker.com/library/redis:7.2-alpine       "docker-entrypoint.s…"   8 minutes ago   Exited (0) 2 seconds ago                                                                                               ke2-redis-1

コンテナが異常な場合、STATUS は UP 以外になります。コンテナは1つだけ停止してしまった場合、全体的にKE2 APP に影響の可能性があります。各コンテナの役割と障害時の影響範囲 を見てください。

KE2 構成に関係があるコンテナのスタータスは Exited 場合、コンテナが停止してしまった。

postgres 停止 (シングル構成のみ）

postgresが停止してしまった場合、全体 KE2 APP に影響があります。この場合、KE2 APP にログインできなくなります。 以下のコマンドで postgres の状況を確認できます。

$ docker ps -a -f name=postgres

CONTAINER ID   IMAGE                                                  COMMAND                  CREATED              STATUS                      PORTS     NAMES
b2e7fb6724af   registry.hub.docker.com/library/postgres:16.3-alpine   "docker-entrypoint.s…"   About a minute ago   Exited (0) 12 seconds ago             ke2-postgres-1

以下の調査をしてください。

• postgres コンテナに異状が生じている

rabbitmq 停止

以下のコマンドで rabbitmq の状況を確認できます。

$ docker ps -a -f name=rabbitmq

CONTAINER ID   IMAGE                                                  COMMAND                  CREATED          STATUS                      PORTS     NAMES
c85f45c64789   registry.hub.docker.com/library/rabbitmq:3.13-alpine   "docker-entrypoint.s…"   12 minutes ago   Exited (1) 10 seconds ago             ke2-rabbitmq-1

以下の調査をしてください。

• rabbitmq コンテナに異状が生じている

redis 停止

• シングル構成場合、以下のコマンド確認できます。

  $ docker ps -a -f name=redis
  
  CONTAINER ID   IMAGE                                              COMMAND                  CREATED             STATUS                     PORTS     NAMES
  ffc36609e02f   registry.hub.docker.com/library/redis:7.2-alpine   "docker-entrypoint.s…"   About an hour ago   Exited (1) 7 seconds ago             ke2-redis-1
  

• クラスタ構成場合、3台ノードのいずれかのノードで実行中なので、以下のコマンドで redis の状況確認できます。

  $ docker service ls
  
  ID             NAME           MODE         REPLICAS               IMAGE                                                  PORTS
  j82svpetkj10   ke2_jobmngrd   replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
  8nmuory1g71d   ke2_kengine    replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
  nfjkex57y4il   ke2_kompira    replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
  jgfdapwajjat   ke2_nginx      replicated   3/3 (max 1 per node)   registry.hub.docker.com/library/nginx:1.27-alpine      *:80->80/tcp, *:443->443/tcp
  qf169f0k9idj   ke2_rabbitmq   replicated   3/3 (max 1 per node)   registry.hub.docker.com/library/rabbitmq:3.13-alpine   *:5671->5671/tcp
  l76bm4t1wf6n   ke2_redis      replicated   1/1                    registry.hub.docker.com/library/redis:7.2-alpine     
  

  上の結果見ると ke2_redis は replicated 1/1 なるべきです。 問題があれば replicated 0/1 になります。

  以下のコマンドで詳しく見ることができます。

  $ docker service ps ke2_redis
  
  ID             NAME              IMAGE                                              NODE                 DESIRED STATE   CURRENT STATE         ERROR     PORTS
  9woomxrgevcr   ke2_redis.1       registry.hub.docker.com/library/redis:7.2-alpine   ke2-rhel89-swarm-3   Running         Running 3 days ago              
  7n8gvrf52yzk    \_ ke2_redis.1   registry.hub.docker.com/library/redis:7.2-alpine   ke2-rhel89-swarm-1   Shutdown        Shutdown 2 days ago             
  zfafc7cs4q00    \_ ke2_redis.1   registry.hub.docker.com/library/redis:7.2-alpine   ke2-rhel89-swarm-2   Shutdown        Shutdown 3 days ago  
  

Running redis がない場合、以下の調査をしてください。

• redis コンテナに異状が生じている

kompira 停止

kompira が停止してしまった場合、特定のホストサーバで KE2 APP にアクセスすると 「502 Bad Gateway」 が表示されます。 以下のコマンドで kompira の状況を確認できます。

$ docker ps -a -f name=kompira

CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                      PORTS     NAMES
4d8f2e81eb86   kompira.azurecr.io/kompira-enterprise:latest   "docker-entrypoint.s…"   16 minutes ago   Exited (1) 12 seconds ago             ke2-kompira-1

高いリソース利用率やネットワークや内部異常などの問題で停止されたコンテナが問題を回復してもコンテナが正常のスタータス に戻らない可能性もあります。ステータスが Exited 場合、簡単に停止されたコンテナの最新の CONTAINER ID を利用して再起動してください。

$ docker restart <コンテナ ID>

KE2 APP が正常に戻らない場合、KE2 APP を再起してください。

nginx 停止

nginx が停止してしまった場合、特定のホストサーバで KE2 APP にアクセスすると 「This site can't be reached」 が表示されます。 以下のコマンドで nginx の状況を確認できます。

$ docker ps -a -f name=nginx

CONTAINER ID   IMAGE                                               COMMAND                  CREATED          STATUS                     PORTS     NAMES
b1d653d23f68   registry.hub.docker.com/library/nginx:1.27-alpine   "/docker-entrypoint.…"   18 minutes ago   Exited (1) 6 seconds ago             ke2-nginx-1

リソース利用率やネットワーク不具合などの問題で停止されたコンテナが問題を回復してもコンテナが正常のスタータス に戻らない可能性もあります。ステータスが Exited 場合、簡単に停止されたコンテナの最新の ID を利用して再起動してください。

$ docker restart <コンテナ ID>

KE2 APP が正常に戻らない場合、KE2 APP を再起してください。

コンテナが操作中ですが異常か再起度を繰り返す

KE2 構成に関係があるコンテナが異常・再起動を繰り返すの可能性もあります。 以下のコマンドを数回実行して、いくつかのコンテナの STATUS が UP 期間と一致せず、頻繁に変わっている場合、そのコンテナは頻繁に再起動されていることを示しています。時々 STATUS に Restarting と表示される可能性もあります。

$ docker ps

CONTAINER ID   IMAGE                                                  COMMAND                  CREATED          STATUS                                    PORTS                                                                      NAMES
e01b0c097596   registry.hub.docker.com/library/nginx:1.27-alpine      "/docker-entrypoint.…"   23 minutes ago   Up 23 minutes                             0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   ke2-nginx-1
f1528cf202e2   kompira.azurecr.io/kompira-enterprise:2.0.2            "docker-entrypoint.s…"   23 minutes ago   Up 23 minutes                                                                                                        ke2-kompira-1
c097c9248af5   kompira.azurecr.io/kompira-enterprise:2.0.2            "docker-entrypoint.s…"   23 minutes ago   Up 37 seconds                                                                                                        ke2-jobmngrd-1
808da5651244   kompira.azurecr.io/kompira-enterprise:2.0.2            "docker-entrypoint.s…"   23 minutes ago   Restarting (143) Less than a second ago                                                                              ke2-kengine-1
8647ed1d6105   registry.hub.docker.com/library/redis:7.2-alpine       "docker-entrypoint.s…"   23 minutes ago   Up 23 minutes                             6379/tcp                                                                   ke2-redis-1

rabbitmq 異常・再起度を繰り返す

• シングル構成
  • TODO: とりあえず、サポートまでお問い合わせください
• クラスタ構成
  • rabbitmq が再起動を繰り返す

redis 異常・再起度を繰り返す

• シングル構成

  • TODO: とりあえず、サポートまでお問い合わせください

• クラスタ構成場合、3台ノードのいずれかのノードで実行中なので、以下のコマンドで redis の状況確認できます。

  $ docker service ls
  
  ID             NAME           MODE         REPLICAS               IMAGE                                                  PORTS
  j82svpetkj10   ke2_jobmngrd   replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
  8nmuory1g71d   ke2_kengine    replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
  nfjkex57y4il   ke2_kompira    replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
  jgfdapwajjat   ke2_nginx      replicated   3/3 (max 1 per node)   registry.hub.docker.com/library/nginx:1.27-alpine      *:80->80/tcp, *:443->443/tcp
  qf169f0k9idj   ke2_rabbitmq   replicated   3/3 (max 1 per node)   registry.hub.docker.com/library/rabbitmq:3.13-alpine   *:5671->5671/tcp
  l76bm4t1wf6n   ke2_redis      replicated   1/1                    registry.hub.docker.com/library/redis:7.2-alpine     
  

  上の結果見ると ke2_redis は replicated 1/1 なるべきです。でも問題があれば上のコマンド数回実行すると replicated 0/1, 1/1, 0/1 に切り替えます。以下のコマンドで詳細も見ることができます。

  $ docker service ps ke2_redis
  
  ID             NAME              IMAGE                                              NODE                 DESIRED STATE   CURRENT STATE                 ERROR     PORTS
  k5oa1w93z9me   ke2_redis.1       registry.hub.docker.com/library/redis:7.2-alpine   ke2-rhel89-swarm-3   Running         Running about a minute ago              
  jyc5pxewoedb    \_ ke2_redis.1   registry.hub.docker.com/library/redis:7.2-alpine   ke2-rhel89-swarm-1   Shutdown        Complete about a minute ago             
  g2eryw4fug4f    \_ ke2_redis.1   registry.hub.docker.com/library/redis:7.2-alpine   ke2-rhel89-swarm-1   Shutdown        Complete about a minute ago  
  

  redis がよく再起度を繰り返すと上の通り結果項目が多くなります。そして CURRENT STATE 見ると短い期間で Shutdown になっていることがわかります。

  以下の調査をしてください。

  • TODO: とりあえず、サポートまでお問い合わせください

kompira 異常・再起度を繰り返す

TODO: とりあえず、サポートまでお問い合わせください

nginx 異常・再起度を繰り返す

TODO: とりあえず、サポートまでお問い合わせください

kengine 異常・再起度を繰り返す

• シングル構成
  • TODO: とりあえず、サポートまでお問い合わせください
• クラスタ構成
  • kengine が再起動を繰り返す

jobmngrd 異常・再起度を繰り返す

• シングル構成
  • jobmngrd ログ調査
• クラスタ構成
  • TODO: とりあえず、サポートまでお問い合わせください

障害パターンごとの調査手順と対策

ここでは障害のパターンごとに着手するべき調査手順を示します。

コンテナに異状が生じている

起動したコンテナで異常が生じている場合は、以下の手順で調査してみてください。

• postgres コンテナに異状が生じている
• redis コンテナに異状が生じている
• rabbitmq コンテナに異状が生じている

コンテナが再起動を繰り返す

コンテナが再起動を繰り返す場合は、以下の手順で調査してみてください。

• kengine コンテナが再起動を繰り返す
• rabbitmq コンテナが再起動を繰り返す

postgres コンテナに異状が生じている

postgres 自体または postgres へのアクセスに問題がある場合、以下のような障害パターンが見られることがあります。

標準シングル構成

postgres コンテナが停止している

NG サービスの内容：

postgres status: ERROR "could not translate host name \"postgres\" to address: Name does not resolve\n"
kompira status: ERROR "Dependent services (postgres) are not running"
kengine status: ERROR "Dependent services (postgres) are not running"   
jobmngrd status: ERROR "Dependent services (postgres) are not running"

kengine ログに「nc: bad address 'postgres'」というエラーが記録されているをご覧ください。

外部 DB シングル構成

外部 DB アクセス問題

NG サービスの内容：

postgres status: ERROR "connection to server at <ip, port> failed: timeout expired\n"
kompira status: ERROR "Dependent services (postgres) are not running"
kengine status: ERROR "Dependent services (postgres) are not running"   
jobmngrd status: ERROR "Dependent services (postgres) are not running"

以下のログを調査してください

• kengine ログに「Is the server running on that host and accepting TCP/IP connections? Host is unreachable」というエラーが記録されている
• kengine ログに「Is the server running on that host and accepting TCP/IP connections? Connection refused」というエラーが記録されている

外部 DB 異常

外部 DB を利用する構成では、以下ようなエラーが生じることがあります。

• kengine ログに「database error: cannot execute UPDATE in a read-only transaction」というエラーが記録されている

pgpool を外部 DB として利用している構成では、以下ようなエラーが生じることもあります。

• kengine ログに「ERROR: unable to read message kind DETAIL: kind does not match between main(4e) slot[1] (53)」というエラーが記録されている

クラスタ構成

外部 DB アクセス問題

NG サービスの内容：

postgres status: ERROR "connection to server at <ip, port> failed: timeout expired\n"
kompira status: ERROR "Dependent services (postgres) are not running"
kengine status: ERROR "Dependent services (postgres) are not running"   
jobmngrd status: ERROR "Dependent services (postgres) are not running"

以下の分析行ってください

• kengine ログに「Is the server running on that host and accepting TCP/IP connections? Host is unreachable」というエラーが記録されている
• kengine ログに「Is the server running on that host and accepting TCP/IP connections? Connection refused」というエラーが記録されている

外部 DB 異常

外部 DB を利用する構成では、以下ようなエラーが生じることがあります。

• kengine ログに「database error: cannot execute UPDATE in a read-only transaction」というエラーが記録されている

pgpool を外部 DB として利用している構成では、以下ようなエラーが生じることもあります。

• kengine ログに「ERROR: unable to read message kind DETAIL: kind does not match between main(4e) slot[1] (53)」というエラーが記録されている

redis コンテナに異状が生じている

redis 自体または redis へのアクセスに問題がある場合、以下のような障害パターンが見られることがあります。

標準シングル構成・外部DBシングル構成

redis コンテナが停止している

NG サービスの内容：

redis status: ERROR "Error -2 connecting to redis:6379. Name does not resolve."
kompira status: ERROR "Dependent services (redis) are not running"
kengine status: ERROR "Dependent services (redis) are not running"   
jobmngrd status: ERROR "Dependent services (redis) are not running"

redis が停止してしまった場合、全体的にKE2 APP にアクセスできなくなります。

以下の調査を進んでください

• kengine ログに「Error -2 connecting to redis:6379. Name does not resolve」というエラーが記録されている

クラスタ構成

redis コンテナが停止している

クラスタ構成では、Redis サービスが停止された場合、自動的に再起動が行われます。ノードに問題がある場合は、別のノードに切り替えて Redis が起動します。そして、アプリケーションは正常に戻ります。

Redis が停止してしまった場合は、以下の状況が表示されます。

NG サービスの内容：

redis status: ERROR "Error -2 connecting to redis:6379. Name does not resolve."
kompira status: ERROR "Dependent services (redis) are not running"
kengine status: ERROR "Dependent services (redis) are not running"   
jobmngrd status: ERROR "Dependent services (redis) are not running"

以下の調査を進んでください。

• kengine ログに「Error -2 connecting to redis:6379. Name does not resolve」というエラーが記録されている

rabbitmq コンテナに異状が生じている

rabbitmq コンテナに異状が生じていると、ブラウザ操作は出来てもジョブフローやリモートジョブの実行ができなくなります。 このような状況の場合、以下のような調査を行なってみてください。

標準シングル構成・外部 DB シングル構成

rabbitmq コンテナが停止してしまった

NG サービスの内容：

rabbitmq status: ERROR "[Errno -2] Name does not resolve"
kengine status: ERROR "[Errno -2] Name does not resolve" 

以下のログを調査してください

• kengine ログに「nc: bad address 'rabbitmq'」というエラーが記録されている

rabbitmq 接続がタイムアウトしました。

rabbitmq サービスの応答がない場合、kengine、jobmngrd コンテナが再起動しを振り返します。

NG サービスの内容：

redis status: ERROR "connection timed out"
kengine status: ERROR "connection timed out"
jobmngrd status: NG/Down

様々な原因でこのような状況発生されるの可能性があります。以下のコマンドで rabbitmq コンテナのステータスを確認してください。

$ docker ps -a -f name=rabbitmq

CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                      PORTS     NAMES
4d8f2e81eb86   kompira.azurecr.io/kompira-enterprise:latest   "docker-entrypoint.s…"   16 minutes ago   Exited (1) 12 seconds ago             ke2-rabbitmq-1

ステータスが UP 以外の場合、簡単に停止されたコンテナの最新の ID を利用して再起動してください。

$ docker restart <rabbitmq コンテナ ID>

KE2 APP が正常に戻らない場合、KE2 APP を再起してください。

クラスタ構成

rabbitmq 停止

NG サービスの内容：

rabbitmq status: ERROR "Could not connect to mq-ke2-rhel89-swarm-1:5672 error: connection refused"
kengine status: ERROR 

以下のコマンドで rabbitmq コンテナのステータスを確認してみてください。

$ docker ps -a -f name=rabbitmq

CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                      PORTS     NAMES
4d8f2e81eb86   kompira.azurecr.io/kompira-enterprise:latest   "docker-entrypoint.s…"   16 minutes ago   Exited (1) 12 seconds ago             ke2-rabbitmq-1

ステータスが UP 以外の場合、簡単に停止されたコンテナの最新の ID を利用して再起動してください。

$ docker restart <rabbitmq コンテナ ID>

rabbitmq が正常に戻らない場合、docker サービス を再起してください。

$ systemctl restart docker.service

kengine コンテナが再起動を繰り返す

クラスタ構成

以下のコマンドを数回実行して、kengine コンテナの STATUS が UP 期間と一致せず、頻繁に変わっている場合、そのコンテナは頻繁に再起動されていることを示しています。時々 STATUS に Restarting と表示される可能性もあります。

$ docker ps
CONTAINER ID   IMAGE                                                  COMMAND                  CREATED          STATUS          PORTS                                                 NAMES
2ffa9132b693   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   20 seconds ago    Up 1 second                                                           ke2_kengine.1.omizpboyhn5tpx82xuco6m4xz
148289b7d3b8   registry.hub.docker.com/library/rabbitmq:3.13-alpine   "docker-entrypoint.s…"   17 minutes ago   Up 17 minutes   4369/tcp, 5671-5672/tcp, 15691-15692/tcp, 25672/tcp   ke2_rabbitmq.3.h89fr1zvis1mdzc1kfiqc98qc
ec0dd234fec1   registry.hub.docker.com/library/nginx:1.27-alpine      "/docker-entrypoint.…"   17 minutes ago   Up 17 minutes   80/tcp                                                ke2_nginx.3.7yk7iq7llghsa5npk47swh3dt
6803dc2b6181   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   17 minutes ago   Up 17 minutes                                                         ke2_kompira.3.wlywfduedgt0joxbm9mpk8gz9
cbf49609d34f   kompira.azurecr.io/kompira-enterprise:latest           "docker-entrypoint.s…"   17 minutes ago   Up 17 minutes                                                         ke2_jobmngrd.3.w9im9yziam3blrtctm182j19q
99abcdd16419   registry.hub.docker.com/library/redis:7.2-alpine       "docker-entrypoint.s…"   17 minutes ago   Up 17 minutes   6379/tcp                                              ke2_redis.1.p65rvw4apkbvl8fga1ph04mwx

/system/info を確認すると、kengine のステータスが unknown と表示され、engine 毎に変わってしまいます。一方で、/.status を確認するとnormal と表示されます。

しかし、ジョブフローを実行するとエラーが発生します。

上の状況で kengine ログチェックすると以下の通りになるの可能性があります。

 [2024-10-31 08:50:46,101:ke-ke2-rhel89-swarm-1:kompirad:MainThread] INFO: [Engine-5960] started.
[2024-10-31 08:50:49,114:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5947' from exchange ''
[2024-10-31 08:50:49,127:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5948' from exchange ''
[2024-10-31 08:50:59,105:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5948' from exchange ''
[2024-10-31 08:50:59,117:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5947' from exchange ''
[2024-10-31 08:51:09,106:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5948' from exchange ''
[2024-10-31 08:51:09,119:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5947' from exchange ''
[2024-10-31 08:51:19,106:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5948' from exchange ''
[2024-10-31 08:51:19,119:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5947' from exchange ''
[2024-10-31 08:51:29,106:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5948' from exchange ''
[2024-10-31 08:51:29,119:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5947' from exchange ''
[2024-10-31 08:51:39,105:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5948' from exchange ''
[2024-10-31 08:51:39,117:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5947' from exchange ''
[2024-10-31 08:51:49,105:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5948' from exchange ''
[2024-10-31 08:51:49,117:ke-ke2-rhel89-swarm-1:kompirad:Thread-2 (_loop)] WARNING: [EngineClient] failed to consuming: Message not delivered: NO_ROUTE (312) to queue 'engine_queue_5947' from exchange ''
[2024-10-31 08:51:59,106:ke-ke2-rhel89-swarm-1:kompirad:QueueManager] ERROR: [AMQPConnector] AMQP connection error: connection closed
[2024-10-31 08:51:59,126:ke-ke2-rhel89-swarm-1:Executor-0:MainThread] INFO: [Executor-0] received stop message
[2024-10-31 08:51:59,126:ke-ke2-rhel89-swarm-1:Executor-0:MainThread] INFO: [Executor-0] finally
[2024-10-31 08:51:59,330:ke-ke2-rhel89-swarm-1:Executor-0:ResultHandlerThread] INFO: result handler: finished
[2024-10-31 08:51:59,336:ke-ke2-rhel89-swarm-1:Executor-0:CommandManager] ERROR: [AMQPConnector] AMQP connection error: connection closed
[2024-10-31 08:51:59,497:ke-ke2-rhel89-swarm-1:Executor-1:MainThread] INFO: [Executor-1] received stop message
[2024-10-31 08:51:59,497:ke-ke2-rhel89-swarm-1:Executor-1:MainThread] INFO: [Executor-1] finally
[2024-10-31 08:51:59,702:ke-ke2-rhel89-swarm-1:Executor-1:ResultHandlerThread] INFO: result handler: finished
[2024-10-31 08:51:59,706:ke-ke2-rhel89-swarm-1:Executor-1:CommandManager] ERROR: [AMQPConnector] AMQP connection error: connection closed
[2024-10-31 08:51:59,879:ke-ke2-rhel89-swarm-1:Executor-2:MainThread] INFO: [Executor-2] received stop message
[2024-10-31 08:51:59,879:ke-ke2-rhel89-swarm-1:Executor-2:MainThread] INFO: [Executor-2] finally
[2024-10-31 08:52:00,083:ke-ke2-rhel89-swarm-1:Executor-2:ResultHandlerThread] INFO: result handler: finished
[2024-10-31 08:52:00,282:ke-ke2-rhel89-swarm-1:Executor-3:MainThread] INFO: [Executor-3] received stop message
[2024-10-31 08:52:00,282:ke-ke2-rhel89-swarm-1:Executor-3:MainThread] INFO: [Executor-3] finally
[2024-10-31 08:52:00,487:ke-ke2-rhel89-swarm-1:Executor-3:ResultHandlerThread] INFO: result handler: finished
[2024-10-31 08:52:00,501:ke-ke2-rhel89-swarm-1:Executor-3:CommandManager] ERROR: [AMQPConnector] AMQP connection error: connection closed
[2024-10-31 08:52:00,662:ke-ke2-rhel89-swarm-1:kompirad:MainThread] INFO: [Engine-5960] finished.
[2024-10-31 08:52:00,662:ke-ke2-rhel89-swarm-1:kompirad:MainThread] INFO: kompirad: going to terminate engine_server
[2024-10-31 08:52:00,662:ke-ke2-rhel89-swarm-1:kompirad:MainThread] INFO: kompirad: bye

何か原因で RabbitMQ クラスタの設定が変わってしまった。RabbitMQ クラスタ全体が不安定になりました。

RabbitMQ に関する以下の所を進んでください。

• RabbitMQ の Mnesia データベースが破損している
• Rabbitmq ログに「Partial partition detected」というエラーが記録されている
• Rabbitmq ログに「Waiting for Mnesia tables」というエラーが記録されている
• Rabbitmq ログに「erl_crash」というエラーが記録されている
• Rabbitmq ログに「leader saw pre_vote_rpc for unknown peer」という警告が記録されている

rabbitmq コンテナが再起動を繰り返す

クラスタ構成

様々な理由で rabbitmq が再起動を繰り返して、正常に動作できなくなる場合があります。

ブラウザで画面アクセスすると以下のようにエンジンとジョブマネージャが共に停止しているエラーが表示される場合があります。

この場合は、以下のいずれであると考えられます。

• rabbitmq が正常に動作できていないために、両コンテナがともに正常に起動できなくなっている
• rabbitmq は正常に動作しているが、kengine コンテナと jobmngrd コンテナがそれぞれに問題があって両方とも停止している

こうしたときは、kengine や jobmngrd が依存している rabbitmq が正常に動作しているかを先に確認してみてください。

rabbitmq に何らかの問題が生じていないかについては、以下を参考に調査してみてください。

• RabbitMQ の Mnesia データベースが破損している
• Rabbitmq ログに「Partial partition detected」というエラーが記録されている
• Rabbitmq ログに「Waiting for Mnesia tables」というエラーが記録されている
• Rabbitmq ログに「erl_crash」というエラーが記録されている
• Rabbitmq ログに「leader saw pre_vote_rpc for unknown peer」という警告が記録されている

rabbitmq が正常に動作しているようであれば、kengine コンテナや jobmngrd コンテナに異状が生じていないかを確認するようにしてみてください。

ログの調査

様々な状況において、原因の特定と対策の検討のための各コンポーネントのログの調査について説明します。

ここではまず各種ログを確認する手順について説明します。

Docker コンテナのログ確認手順

Docker コンテナのログを確認する手順については、以下を参照してください。

• コンテナログ管理

Docker Swarm 構成でサービス単位のログを確認する手順については、以下を参照してください。

• サービスログ管理

なお、このログ調査のドキュメントに記載したログのサンプルは、以下のようなホスト構成で取得したものになります。

その他サービスのログ確認手順

コンテナ以外の各サービスのログを確認する方法については、OS ごとのログ管理の手順を確認してください。

以下では Linux システムで一般的な journalctl コマンドによる確認手順の例を示します。

journalctl コマンドの使い方についてはマニュアルを参照してください。

$ man journalctl

docker サービスのログ確認

docker サービスのログを journalctl コマンドで確認します。

$ journalctl -u docker
# or
$ journalctl -u docker.service

最新 N 行のログだけを確認したい場合は、-n オプションで指定します。

# $ journalctl -u docker -n <行数>
# 例: 
$ journalctl -u docker -n 10

glusterfs サービスのログ確認

glusterfs サービスのログを journalctl コマンドで確認します。

# 例：
$ journalctl -u glusterd
# 例：
$ journalctl -u glusterd -n 10
# 例：
$ journalctl -u glusterd --since today

いずれかの構成： nignx ログ調査

INS-N1: Nginx ログに「upstream timed out」というエラーが記録されている

Kompiraサービスがダウンしているか応答がない場合、Nginxがこの種のエラーを発生させる可能性があります。nginx のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

2024/09/11 20:01:43 [error] 23#23: *870 upstream timed out (110: Operation timed out) while reading response header from upstream, client: 10.0.0.2, server: 0.0.0.0, request: "GET /process?is_active=True&attrs=id&attrs=abspath&attrs=status&attrs=suspended&attrs=current_job&attrs=started_time&attrs=finished_time&attrs=elapsed_time&attrs=user&timestamp=1726052203654 HTTP/1.1", upstream: "uwsgi://10.0.2.29:8000", host: "10.20.47.11", referrer: "https://10.20.47.11/process?is_active=True"
10.0.0.2 - - [11/Sep/2024:20:01:43 +0900] "GET /process?is_active=True&attrs=id&attrs=abspath&attrs=status&attrs=suspended&attrs=current_job&attrs=started_time&attrs=finished_time&attrs=elapsed_time&attrs=user&timestamp=1726052203654 HTTP/1.1" 504 569 "https://10.20.47.11/process?is_active=True" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36" "-"

解決策

1. 特定のコンテナ（kompira）によるリソースの過剰使用:

   kompira コンテナで利用のリソース状況をご確認ください。

2. 特定のコンテナ（kompira）が停止されたの可能性があります。

   kompira コンテナの正常性をご確認ください。

いずれかの構成： rabbitmq ログ調査

INS-R1: RabbitMQ でのディスクリソース制限アラーム

RabbitMQは、ノード上の空きディスクスペースが設定されたthreshold値（デフォルトでは50MB）を下回った場合にディスクリソース制限アラームを発生させます。これは、ディスクスペースが解放されるまでパブリッシャーをブロックします。RabbitMQ のログを確認すると、特定のノードで「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

2024-09-05 12:42:41.882617+09:00 [info] <0.3194.0> accepting AMQP connection <0.3194.0> (10.0.2.58:43344 -> 10.0.2.54:5672)
2024-09-05 12:42:41.925986+09:00 [info] <0.3194.0> connection <0.3194.0> (10.0.2.58:43344 -> 10.0.2.54:5672): user 'guest' authenticated and granted access to vhost '/'
2024-09-05 12:42:47.408871+09:00 [info] <0.3222.0> accepting AMQP connection <0.3222.0> (10.0.2.58:53238 -> 10.0.2.54:5672)
2024-09-05 12:42:47.451867+09:00 [info] <0.3222.0> connection <0.3222.0> (10.0.2.58:53238 -> 10.0.2.54:5672): user 'guest' authenticated and granted access to vhost '/'
2024-09-05 12:53:39.878680+09:00 [notice] <0.86.0>     alarm_handler: {set,{system_memory_high_watermark,[]}}
2024-09-05 12:54:04.298460+09:00 [info] <0.476.0> Free disk space is insufficient. Free bytes: 647168. Limit: 50000000
2024-09-05 12:54:04.298588+09:00 [warning] <0.472.0> disk resource limit alarm set on node 'rabbit@mq-ke2-rhel89-swarm-1'.
2024-09-05 12:54:04.298588+09:00 [warning] <0.472.0> 
2024-09-05 12:54:04.298588+09:00 [warning] <0.472.0> **********************************************************
2024-09-05 12:54:04.298588+09:00 [warning] <0.472.0> *** Publishers will be blocked until this alarm clears ***
2024-09-05 12:54:04.298588+09:00 [warning] <0.472.0> **********************************************************
2024-09-05 12:54:04.298588+09:00 [warning] <0.472.0> 
2024-09-05 12:57:16.350956+09:00 [info] <0.4716.0> accepting AMQP connection <0.4716.0> (10.0.2.58:33252 -> 10.0.2.54:5672)
2024-09-05 12:57:16.406858+09:00 [info] <0.4716.0> connection <0.4716.0> (10.0.2.58:33252 -> 10.0.2.54:5672): user 'guest' authenticated and granted access to vhost '/'
2024-09-05 12:57:50.860279+09:00 [info] <0.4787.0> accepting AMQP connection <0.4787.0> (10.0.2.55:48046 -> 10.0.2.54:5672)  

解決策

以下の手順に従ってさらなる分析を行います:

1. 以下のコマンドでRabbitMQのAlarmsステータスを確認します。

   [ke2-rhel89-swarm-1]$ docker exec $(docker ps -q -f name=rabbitmq) rabbitmqctl status
   

   Alarmsが残っている場合以下のように表示される

   Alarms
   
   Free disk space alarm on node rabbit@mq-ke2-rhel89-swarm-1
   

2. VMで利用可能なディスクスペースを確認する:

   [ke2-rhel89-swarm-1]$ df -h
   

   上のコマンドで空きディスクスペースが十分にあるか確認します。空きスペースが不足している場合は不要なファイルを削除します。そして、RabbitMQのAlarmsステータスを再確認してディスクアラームが解除されたことを確認します。

   Alarms が (none) になり、RabbitMQが自動的に正常になるべきです。

3. 正常に戻らない場合、rabbitmq コンテナを再起動してください

   # CONTAINER ID を取得
   $ docker ps -f name=rabbitmq
   
   # rabbitmq コンテナを再起動
   $ docker restart < rabbitmq コンテナ ID>
   

4. KE2 APP が正常に戻らない場合、KE2 APP を再起してください。

INS-R2: Rabbitmq ログに「memory resource limit alarm set on node 」というエラーが記録されている

Rabbitmqため十分なメモリが空いていない場合、特定のノードで RabbitMQ のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

2024-09-25 21:42:10.868015+09:00 [warning] <0.475.0> memory resource limit alarm set on node 'rabbit@mq-ke2-rhel89-swarm-1'.
2024-09-25 21:42:10.868015+09:00 [warning] <0.475.0> 
2024-09-25 21:42:10.868015+09:00 [warning] <0.475.0> **********************************************************
2024-09-25 21:42:10.868015+09:00 [warning] <0.475.0> *** Publishers will be blocked until this alarm clears ***
2024-09-25 21:42:10.868015+09:00 [warning] <0.475.0> **********************************************************
2024-09-25 21:42:10.868015+09:00 [warning] <0.475.0> 

解決策

1. 以下のコマンドでRabbitMQのAlarmsステータスを確認します。

   [ke2-rhel89-swarm-1]$ docker exec $(docker ps -q -f name=rabbitmq) rabbitmqctl status
   

   Alarmsが残っている場合以下のように表示される

   Alarms
   
   Memory alarm on node rabbit@mq-ke2-rhel89-swarm-1
   

2. ホストサーバで高いメモリ使用率

   ホストサーバのリソース状況を確認してください。 メモリ使用率が高い場合は、メモリを解放してください。

   そしてまた、rabbitmq の状況をチェックすると Alarms が (none) になり、RabbitMQが正常に戻るはずです。

3. 正常に戻らない場合、rabbitmq コンテナを再起動してください

   # CONTAINER ID を取得
   $ docker ps -f name=rabbitmq
   
   # rabbitmq コンテナを再起動
   $ docker restart < rabbitmq コンテナ ID>
   

4. KE2 APP が正常に戻らない場合、KE2 APP を再起してください。

クラスタ構成固有サービスのログの調査

クラスタ構成の kengine ログ調査

INS-CK1: kengine ログに「Is the server running on that host and accepting TCP/IP connections? Host is unreachable」というエラーが記録されている

KE2 APP とデータベースサーバー間でネットワーク接続の問題が発生している場合、kengine のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django_dbconn_retry/apps.py", line 51, in ensure_connection_with_retries
    self.connect()
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/base/base.py", line 270, in connect
    self.connection = self.get_new_connection(conn_params)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/postgresql/base.py", line 275, in get_new_connection
    connection = self.Database.connect(**conn_params)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.OperationalError: connection to server at "10.20.47.20", port 9999 failed: Host is unreachable
	Is the server running on that host and accepting TCP/IP connections?

解決策

KE2 APP から外部 DB ホストサーバに ping して答えがない原因でこのような状況発生されます。この場合、以下の調査してください。

• 外部 DB ホストサーバの正常性をご確認ください。
• 外部 DB ホストサーバのネットワークインターフェイスの状態を確認してください。
• 外部 DB ホストサーバの Network 設定を確認してください。

外部 DB ホストサーバやネットワークなどの保守手順については、本マニュアルの範囲外になります。

INS-CK2: kengine ログに「ERROR: unable to read message kind DETAIL: kind does not match between main(4e) slot[1] (53)」というエラーが記録されている

DB クラスタ(pgpool)利用すると、DB ノード間のネットワーク遅延・DB サーバリソース使用率が高い場合、kengine のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Node: ke2-rhel89-swarm-3

[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-3:docker-entrypoint.sh] INFO: Starting docker-entrypoint(kompirad) [KOMPIRA_VERSION=2.0.0, LANGUAGE_CODE=ja]
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-3:docker-entrypoint.sh] INFO: Wait for Cache: redis:6379 -t 15
wait-for-it.sh: waiting 15 seconds for redis:6379
wait-for-it.sh: redis:6379 is available after 0 seconds
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-3:docker-entrypoint.sh] INFO: Cache is ready
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-3:docker-entrypoint.sh] INFO: Wait for Database: 10.20.47.20:9999 -t 30
wait-for-it.sh: waiting 30 seconds for 10.20.47.20:9999
wait-for-it.sh: 10.20.47.20:9999 is available after 0 seconds
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-3:docker-entrypoint.sh] INFO: Database is ready
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-3:docker-entrypoint.sh] INFO: Wait for flock: /var/opt/kompira/.flock_init_data
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-3:docker-entrypoint.sh] INFO: flock is acquired
[2024-09-11 08:57:55,634:ke-ke2-rhel89-swarm-3:MainProcess:MainThread] INFO: AXES: BEGIN version 6.0.5, blocking by combination of username and ip_address
Reconnecting to the database didn't help connection to server at "10.20.47.20", port 9999 failed: ERROR:  unable to read message kind
DETAIL:  kind does not match between main(4e) slot[1] (53)

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django_dbconn_retry/apps.py", line 51, in ensure_connection_with_retries
    self.connect()
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/base/base.py", line 270, in connect
    self.connection = self.get_new_connection(conn_params)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/postgresql/base.py", line 275, in get_new_connection
    connection = self.Database.connect(**conn_params)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.OperationalError: connection to server at "10.20.47.20", port 9999 failed: ERROR:  unable to read message kind
DETAIL:  kind does not match between main(4e) slot[1] (53)

解決策

1. pgpoolノード間の通信問題

   ネットワークの問題により、pgpoolノード間で適切な調整ができず、ノード間でデータは同期が取れない場合があります。

2. pgpoolノードのリソース使用率が高い

   pgpool VMでCPU、メモリ、I/Oの使用率が高い場合、データベース操作が遅くなり、DB ノード間でデータは同期が取れない場合があります。

外部 DB ホストサーバやネットワークなどの保守手順については、本マニュアルの範囲外になります。

INS-CK3: kengine ログに「database error: cannot execute UPDATE in a read-only transaction」というエラーが記録されている

データベースの不整合やDB クラスタなら、DB クラスタ(pgpool)がフェイルオーバーを実行し、アプリケーションが依然として古いプライマリノード（現在は読み取り専用モード）に接続されている可能性もあります。この状況で kengine のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Node: ke-ke2-rhel89-swarm-2

[2024-09-25 10:48:17,034:ke-ke2-rhel89-swarm-2:kompirad:MainThread] ERROR: Failed to start due to database error: cannot execute UPDATE in a read-only transaction

解決策

1. 以下のコマンドで外部 DB 操作をご確認ください。

# ベーシックコマンド: psql -h <DB IP> -p <DB PORT> -U <USER> -d <DATABASE>
# pgpool場合、DB IP は Virtual IP です。DB PORT は defaultでは 9999 です。
# postgres場合、DB IP は DB サーバ IP です。DB PORT は defaultでは 5432 です。
# USER は postgres です。
# DATABASE は kompira です。
# 例：
$ psql -h 10.20.47.20 -p 9999 -U postgres -d kompira -c "CREATE TEMP TABLE pg_temp.test_table (value TEXT); INSERT INTO pg_temp.test_table (value) VALUES ('Dummy Test Value'); SELECT * FROM pg_temp.test_table;"

Password for user postgres: *****
      value       
------------------
Dummy Test Value
(1 row)

上のコマンドで問題があれば、外部 DB 管理者に連絡してください。

psql コマンドが利用できない場合は、CentOS/RHEL: postgresql、Debian/Ubuntu: postgresql-client をインストールしてください。

2. 外部 DB 操作に問題がなければ、KE2 APP 側での DB 接続セッションの問題の可能性があります。この場合、kengine サービスを再起動してください。

$ docker service update --force $(docker service ls | grep kengine | awk '{print $2}')

INS-CK4: kengine ログに「Error -2 connecting to redis:6379. Name does not resolve」というエラーが記録されている

クラスタ構成場合、redis は3台ノードのいずれかのノードで実行中の可能です。実行中ノードで以下ような問題が発生すると redis が別のノードに切り替えて起動します。

• 実行中ノードがダウン・再起動
• 実行中ノードのリソース利用率が高い
• swarm ノード間のネットワーク導通の問題
• 実行中ノードの docker 停止・再起動

切り替えると kengine で「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

redis.exceptions.ConnectionError: Error -2 connecting to redis:6379. Name does not resolve.

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

  File "/usr/local/lib/python3.11/site-packages/kompira/core/cache.py", line 55, in get_object
    cache.touch(key)
  File "/usr/local/lib/python3.11/site-packages/django/core/cache/backends/redis.py", line 195, in touch
    return self._cache.touch(key, self.get_backend_timeout(timeout))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/cache/backends/redis.py", line 115, in touch
    return bool(client.expire(key, timeout))
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/redis/commands/core.py", line 1762, in expire
    return self.execute_command("EXPIRE", name, time, *exp_option)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 1266, in execute_command
    conn = self.connection or pool.get_connection(command_name, **options)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/redis/connection.py", line 1461, in get_connection
    connection.connect()
  File "/usr/local/lib/python3.11/site-packages/redis/connection.py", line 713, in connect
    raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error -2 connecting to redis:6379. Name does not resolve.

解決策

redis が不安定かどうか確認してください。

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

$ docker service ls

ID             NAME           MODE         REPLICAS               IMAGE                                                  PORTS
j82svpetkj10   ke2_jobmngrd   replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
8nmuory1g71d   ke2_kengine    replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
nfjkex57y4il   ke2_kompira    replicated   3/3 (max 1 per node)   kompira.azurecr.io/kompira-enterprise:latest           
jgfdapwajjat   ke2_nginx      replicated   3/3 (max 1 per node)   registry.hub.docker.com/library/nginx:1.27-alpine      *:80->80/tcp, *:443->443/tcp
qf169f0k9idj   ke2_rabbitmq   replicated   3/3 (max 1 per node)   registry.hub.docker.com/library/rabbitmq:3.13-alpine   *:5671->5671/tcp
l76bm4t1wf6n   ke2_redis      replicated   1/1                    registry.hub.docker.com/library/redis:7.2-alpine     

上の結果見ると ke2_redis は replicated 1/1 なるべきです。でも不安定場合、上ののコマンド数回実行すると replicated 0/1, 1/1, 0/1 に変わってしまいます。以下のコマンドで詳細も見ることができます。

$ docker service ps ke2_redis

ID             NAME              IMAGE                                              NODE                 DESIRED STATE   CURRENT STATE                 ERROR     PORTS
k5oa1w93z9me   ke2_redis.1       registry.hub.docker.com/library/redis:7.2-alpine   ke2-rhel89-swarm-3   Running         Running about a minute ago              
jyc5pxewoedb    \_ ke2_redis.1   registry.hub.docker.com/library/redis:7.2-alpine   ke2-rhel89-swarm-1   Shutdown        Complete about a minute ago             
g2eryw4fug4f    \_ ke2_redis.1   registry.hub.docker.com/library/redis:7.2-alpine   ke2-rhel89-swarm-1   Shutdown        Complete about a minute ago  

redis がよく再起度を繰り返すと上の通り結果項目が多くなります。そして CURRENT STATE 見ると短い期間で Shutdown になっていることがわかります。

redis が不安定場合、以下の手順を進んでください。

1. swarm ノードのステータスをご確認ください。

   • swarm ノードのステータスの正常性確認

   swarm ノードの状況が異常場合、解決してください。

2. swarm ノードのステータスは正常の場合、 redis を再起動してください。 redis サービス名で再起動してください。

   $ docker service --force update ke2_redis
   
   ke2_redis
   overall progress: 1 out of 1 tasks 
   1/1: running   [==================================================>] 
   verify: Service ke2_redis converged
   

INS-CK5: kengine ログに「Is the server running on that host and accepting TCP/IP connections? Connection refused」というエラーが記録されている

データベースが停止されてしまった場合、kengine のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Reconnecting to the database didn't help connection to server at "10.20.47.20", port 9999 failed: Connection refused
  Is the server running on that host and accepting TCP/IP connections?

解決策

• 外部データベースへのアクセスを確認してみてください。

クラスタ構成の kompira ログ調査

INS-CKO1: kompira ログに「KeyError: 'staticfiles'」というエラーが記録されている

GlusterFS ボリュームが停止したりクラッシュした場合、kompira のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

• KeyError: 'staticfiles'
• OSError: [Errno 107] Socket not connected: '/var/opt/kompira/html/staticfiles.json'

ログのサンプルエントリ

Node: ke2-rhel89-swarm-2

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django/core/handlers/base.py", line 220, in _get_response
    response = response.render()
               ^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/response.py", line 114, in render
    self.content = self.rendered_content
                   ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/response.py", line 92, in rendered_content
    return template.render(context, self._request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/backends/django.py", line 61, in render
    return self.template.render(context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 175, in render
    return self._render(context)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 167, in _render
    return self.nodelist.render(context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in render
    return SafeString("".join([node.render_annotated(context) for node in self]))
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in <listcomp>
    return SafeString("".join([node.render_annotated(context) for node in self]))
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 966, in render_annotated
    return self.render(context)
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/loader_tags.py", line 157, in render
    return compiled_parent._render(context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 167, in _render
    return self.nodelist.render(context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in render
    return SafeString("".join([node.render_annotated(context) for node in self]))
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in <listcomp>
    return SafeString("".join([node.render_annotated(context) for node in self]))
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 966, in render_annotated
    return self.render(context)
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/loader_tags.py", line 157, in render
    return compiled_parent._render(context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 167, in _render
    return self.nodelist.render(context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in render
    return SafeString("".join([node.render_annotated(context) for node in self]))
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in <listcomp>
    return SafeString("".join([node.render_annotated(context) for node in self]))
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 966, in render_annotated
    return self.render(context)
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/loader_tags.py", line 157, in render
    return compiled_parent._render(context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 167, in _render
    return self.nodelist.render(context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in render
    return SafeString("".join([node.render_annotated(context) for node in self]))
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in <listcomp>
    return SafeString("".join([node.render_annotated(context) for node in self]))
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 966, in render_annotated
    return self.render(context)
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/defaulttags.py", line 321, in render
    return nodelist.render(context)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in render
    return SafeString("".join([node.render_annotated(context) for node in self]))
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 1005, in <listcomp>
    return SafeString("".join([node.render_annotated(context) for node in self]))
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/template/base.py", line 966, in render_annotated
    return self.render(context)
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/templatetags/static.py", line 116, in render
    url = self.url(context)
          ^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/templatetags/static.py", line 113, in url
    return self.handle_simple(path)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/templatetags/static.py", line 129, in handle_simple
    return staticfiles_storage.url(path)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/utils/functional.py", line 266, in inner
    self._setup()
  File "/usr/local/lib/python3.11/site-packages/django/contrib/staticfiles/storage.py", line 537, in _setup
    self._wrapped = storages[STATICFILES_STORAGE_ALIAS]
                    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/files/storage/handler.py", line 43, in __getitem__
    storage = self.create_storage(params)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/files/storage/handler.py", line 55, in create_storage
    return storage_cls(**options)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/contrib/staticfiles/storage.py", line 460, in __init__
    self.hashed_files, self.manifest_hash = self.load_manifest()
                                            ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/contrib/staticfiles/storage.py", line 470, in load_manifest
    content = self.read_manifest()
              ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/contrib/staticfiles/storage.py", line 464, in read_manifest
    with self.manifest_storage.open(self.manifest_name) as manifest:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/files/storage/base.py", line 22, in open
    return self._open(name, mode)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/files/storage/filesystem.py", line 68, in _open
    return File(open(self.path(name), mode))
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 107] Socket not connected: '/var/opt/kompira/html/staticfiles.json'
[2024-08-14 12:52:10,444:ap-ke2-rhel89-swarm-3:MainProcess:uWSGIWorker5Core0] ERROR: database error: [Errno 107] Socket not connected: '/var/opt/kompira/html/staticfiles.json'(OSError(107, 'Socket not connected'))
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django/core/files/storage/handler.py", line 35, in __getitem__
    return self._storages[alias]
           ~~~~~~~~~~~~~~^^^^^^^
KeyError: 'staticfiles'

原因

このエラーは、静的ファイルを提供するために使用されているGlusterFSボリュームが利用できない、またはクラッシュした場合に発生することが多いです。KompiraのDjangoアプリケーションは、このボリュームに格納された静的ファイルにアクセスしようとしますが、ボリュームがダウンしている場合、接続できず、エラーが発生します。それによりブラウザ画面も崩れる可能性があります。

解決策

1. KE2 APP ホストサーバでリソース使用率が高い場合

   ホストサーバのリソース状況をご確認ください。

2. glusterfs のボリュームアクセスの問題

   共有ファイルシステム (glusterfs)の正常性をご確認ください。

3. 正常に戻らない場合、kompira コンテナを再起動してください

   # kompira コンテナ ID: $ docker ps -q -f name=kompira を実行してコンテナ ID を取得できます。
   $ docker restart < kompira コンテナ ID>
   

クラスタ固有の Docker ログ調査

INS-CD1: ネットワークの問題または特定ノードのインターフェイスのダウン

特定のノードにネットワークの問題またはインターフェイスのダウン場合、さまざまなエラーが発生する可能性があります。特に、特定のノードで Docker のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

• msg="error receiving response" error="rpc error: code = Canceled desc = context canceled"
• msg="memberlist: Failed to send UDP ping: write udp [::]:7946->10.20.47.12:7946: sendto: network is unreachable"
• level=warning msg="bulk sync to node 26b516451957 failed: failed to send a TCP message during bulk sync: dial tcp 10.20.47.12:7946: connect: network is unreachable"
• level=error msg="error receiving response" error="rpc error: code = Canceled desc = context canceled"

ログのサンプルエントリ

Node: ke2-rhel89-swarm-3

Sep  9 13:24:53 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:53.660104866+09:00" level=warning msg="memberlist: Failed to send UDP ping: write udp [::]:7946->10.20.47.12:7946: sendto: network is unreachable"
Sep  9 13:24:53 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:53.660393049+09:00" level=warning msg="memberlist: Failed to send indirect UDP ping: write udp [::]:7946->10.20.47.11:7946: sendto: network is unreachable"
Sep  9 13:24:53 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:53.660411484+09:00" level=warning msg="bulk sync to node d7dbb1513873 failed: failed to send a TCP message during bulk sync: dial tcp 10.20.47.11:7946: connect: network is unreachable"
Sep  9 13:24:53 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:53.660646948+09:00" level=warning msg="bulk sync to node 26b516451957 failed: failed to send a TCP message during bulk sync: dial tcp 10.20.47.12:7946: connect: network is unreachable"
Sep  9 13:24:53 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:53.660658881+09:00" level=error msg="periodic bulk sync failure for network wxpj9trr7nqzfxyf5jo20o04d: bulk sync to node 26b516451957 failed: failed to send a TCP message during bulk sync: dial tcp 10.20.47.12:7946: connect: network is unreachable"
Sep  9 13:24:53 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:53.660757727+09:00" level=warning msg="bulk sync to node 26b516451957 failed: failed to send a TCP message during bulk sync: dial tcp 10.20.47.12:7946: connect: network is unreachable"
Sep  9 13:24:53 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:53.660866121+09:00" level=warning msg="bulk sync to node d7dbb1513873 failed: failed to send a TCP message during bulk sync: dial tcp 10.20.47.11:7946: connect: network is unreachable"
Sep  9 13:24:53 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:53.660881811+09:00" level=error msg="periodic bulk sync failure for network wgjapriy9ytdcbrd2z42isy9w: bulk sync to node d7dbb1513873 failed: failed to send a TCP message during bulk sync: dial tcp 10.20.47.11:7946: connect: network is unreachable"
Sep  9 13:24:54 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:54.660523142+09:00" level=info msg="memberlist: Suspect 26b516451957 has failed, no acks received"
Sep  9 13:24:54 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:54.661032423+09:00" level=warning msg="memberlist: Failed to send UDP compound ping and suspect message to 10.20.47.12:7946: write udp [::]:7946->10.20.47.12:7946: sendto: network is unreachable"
Sep  9 13:24:54 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:54.661122262+09:00" level=warning msg="memberlist: Failed to send indirect UDP ping: write udp [::]:7946->10.20.47.11:7946: sendto: network is unreachable"
Sep  9 13:24:54 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:54.859948875+09:00" level=warning msg="memberlist: Failed to send gossip to 10.20.47.11:7946: write udp [::]:7946->10.20.47.11:7946: sendto: network is unreachable"
Sep  9 13:24:54 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:54.860013167+09:00" level=warning msg="memberlist: Failed to send gossip to 10.20.47.12:7946: write udp [::]:7946->10.20.47.12:7946: sendto: network is unreachable"
Sep  9 13:24:55 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:55.060338976+09:00" level=warning msg="memberlist: Failed to send gossip to 10.20.47.12:7946: write udp [::]:7946->10.20.47.12:7946: sendto: network is unreachable"
Sep  9 13:24:56 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:56.661696183+09:00" level=info msg="memberlist: Suspect 26b516451957 has failed, no acks received"
Sep  9 13:24:56 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:56.661843631+09:00" level=warning msg="memberlist: Failed to send UDP ping: write udp [::]:7946->10.20.47.11:7946: sendto: network is unreachable"
Sep  9 13:24:58 ke2-rhel89-swarm-3 dockerd[1441]: time="2024-09-09T13:24:58.661028298+09:00" level=info msg="memberlist: Marking 26b516451957 as failed, suspect timeout reached (0 peer confirmations)"

解決策

ネットワークの問題が解決されると、Docker Swarmノードは通常、自動的に回復します。ただし、回復になってない場合は、ノード間通信をご確認ください。ノード間通信が正常に戻っても、特定のノードでKE2 APPが正常に動作していない場合は、Dockerサービスを再起動してください。

$ systemctl restart docker.service

INS-CD2: 外部データベースまたはSwarmノードとの高いネットワーク遅延

外部データベースやSwarmノードとの間で高いネットワーク遅延や高いパケットロスが発生する場合、さまざまなエラーが発生する可能性があります。特に、特定ノードの Docker のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

• level=error msg="fatal task error" error="task: non-zero exit (1)"
• level=warning msg="failed to deactivate service binding for container ke2_kengine.2.s9jv96yf2uw0k88omd8y11erw" error="No such container: ke2_kengine.2.s9jv96yf2uw0k88omd8y11erw"
• level=warning msg="NetworkDB stats ke2-rhel89-swarm-2(a6a2e4038ef8) - healthscore:1 (connectivity issues)"

ログのサンプルエントリ

Node: ke2-rhel89-swarm-2

Sep 11 18:32:17 ke2-rhel89-swarm-2 dockerd[785695]: time="2024-09-02T08:47:39.509568544+09:00" level=warning msg="NetworkDB stats ke2-rhel89-swarm-2(a6a2e4038ef8) - healthscore:1 (connectivity issues)"
Sep 11 18:32:17 ke2-rhel89-swarm-2 dockerd[785695]: time="2024-09-11T18:32:17.192989709+09:00" level=info msg="NetworkDB stats ke2-rhel89-swarm-2(05360ec70c80) - netID:rk6harno4s00l98f6ho4rdb7p leaving:false netPeers:3 entries:37 Queue qLen:0 netMsg/s:0"
Sep 11 18:32:17 ke2-rhel89-swarm-2 dockerd[785695]: time="2024-09-11T18:32:17.193462600+09:00" level=info msg="NetworkDB stats ke2-rhel89-swarm-2(05360ec70c80) - netID:wxpj9trr7nqzfxyf5jo20o04d leaving:false netPeers:3 entries:15 Queue qLen:0 netMsg/s:0"
Sep 11 18:37:17 ke2-rhel89-swarm-2 dockerd[785695]: time="2024-09-11T18:37:17.392411952+09:00" level=info msg="NetworkDB stats ke2-rhel89-swarm-2(05360ec70c80) - netID:rk6harno4s00l98f6ho4rdb7p leaving:false netPeers:3 entries:35 Queue qLen:0 netMsg/s:0"
Sep 11 18:37:17 ke2-rhel89-swarm-2 dockerd[785695]: time="2024-09-11T18:37:17.393110199+09:00" level=info msg="NetworkDB stats ke2-rhel89-swarm-2(05360ec70c80) - netID:wxpj9trr7nqzfxyf5jo20o04d leaving:false netPeers:3 entries:15 Queue qLen:0 netMsg/s:0"
Sep 11 18:39:58 ke2-rhel89-swarm-2 dockerd[785695]: time="2024-09-11T18:39:58.069328404+09:00" level=info msg="ignoring event" container=e0a3465370bbeb20eb84952344933a158fe9665b295653591774b5df8e5a489a module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Sep 11 18:39:58 ke2-rhel89-swarm-2 dockerd[785695]: [2024-09-11T18:39:58+09:00] Discarding queued events...
Sep 11 18:39:58 ke2-rhel89-swarm-2 dockerd[785695]: time="2024-09-11T18:39:58.185132146+09:00" level=error msg="fatal task error" error="task: non-zero exit (1)" module=node/agent/taskmanager node.id=ly4ik4v3pw9rgom0htt281aus service.id=2gjb1rv9xn4i9hlydsmt15nio task.id=cnstkeybneberx2tcloc0r3t1
Sep 11 18:39:58 ke2-rhel89-swarm-2 dockerd[785695]: time="2024-09-11T18:39:58.607441058+09:00" level=warning msg="failed to deactivate service binding for container ke2_kengine.2.s9jv96yf2uw0k88omd8y11erw" error="No such container: ke2_kengine.2.s9jv96yf2uw0k88omd8y11erw" module=node/agent node.id=ly4ik4v3pw9rgom0htt281aus

解決策

外部データベースやSwarmノードとの間でネットワークの問題が解決されると、KE2 APP が自動的に回復します。ただし、問題が回復にならない場合は、以下の状況を見てください。

• ノード間通信をご確認ください。
• KE2 APP ホストサーバと外部データベース間のネットワーク導通をご確認ください。
• 外部データベース間のネットワーク導通に問題があれば kengine が不安定の可能性があります。

  • kengine の状況をご確認ください。

    docker ps -a -f name=kengine
    

    kengine が再起動を繰り返す場合、kengine コンテナを再起動してください。

    # kengine コンテナ ID: $ docker ps -q -f name=kengine を実行してコンテナ ID を取得できます。
    $ docker restart < kengine コンテナ ID>
    

  • 特定ノードの KE2 APP が正常に戻らな場合 docker サービスを再起度してください。

    $ systemctl restart docker.service
    

INS-CD3: Docker 不安定性

特定のノードにネットワークの問題、またはノードにリソース使用率が高い場合、さまざまなエラーが発生する可能性があります。特に、特定のノードで以下のコマンドで Docker のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

• underweighting node <node-id> for service <service-id> because it experienced 5 failures or rejections within 5m0s
• Could not parse VIP address while releasing
• error deallocating vip error="invalid CIDR address: " vip.addr= vip.network=<network-id>
• Failed to allocate network resources for node <node-id> error="could not find network allocator state for network <network-id>"

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

Sep 19 14:37:21 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:21.482572833+09:00" level=warning msg="underweighting node sw16fqkz94al7qwwqeksgtzeh for service m23oykzvchn3nc6n6cvsyebso because it experienced 5 failures or rejections within 5m0s" module=scheduler node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:21 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:21.482965448+09:00" level=error msg="Could not parse VIP address  while releasing"
Sep 19 14:37:21 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:21.482987921+09:00" level=error msg="error deallocating vip" error="invalid CIDR address: " vip.addr= vip.network=ut2671phg9ixr96r49j1uambb
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.286255147+09:00" level=error msg="Could not parse VIP address  while releasing"
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.286490844+09:00" level=error msg="error deallocating vip" error="invalid CIDR address: " vip.addr= vip.network=ut2671phg9ixr96r49j1uambb
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.300954287+09:00" level=error msg="Could not parse VIP address  while releasing"
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.300982541+09:00" level=error msg="error deallocating vip" error="invalid CIDR address: " vip.addr= vip.network=ut2671phg9ixr96r49j1uambb
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.308515598+09:00" level=error msg="Could not parse VIP address  while releasing"
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.308531979+09:00" level=error msg="error deallocating vip" error="invalid CIDR address: " vip.addr= vip.network=ut2671phg9ixr96r49j1uambb
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.317007374+09:00" level=error msg="Event api.EventUpdateTask: Failed to get service z0hc7bmssm60q3i3th0bg3tpy for task qfg8afb4gmdo35qnr1aeiaxnw state NEW: could not find service z0hc7bmssm60q3i3th0bg3tpy" module=node node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.317044034+09:00" level=error msg="Event api.EventUpdateTask: Failed to get service z0hc7bmssm60q3i3th0bg3tpy for task uoqxq0l8yoy8sybeyakshu6ou state NEW: could not find service z0hc7bmssm60q3i3th0bg3tpy" module=node node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.317071836+09:00" level=error msg="Event api.EventUpdateTask: Failed to get service z0hc7bmssm60q3i3th0bg3tpy for task z5o1144xliwegvminmu6l017u state NEW: could not find service z0hc7bmssm60q3i3th0bg3tpy" module=node node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.323309366+09:00" level=error msg="Event api.EventUpdateTask: Failed to get service kiziizne7llebo4klwhnt2v1d for task il2yrfjr9xj60q48upezgu43g state NEW: could not find service kiziizne7llebo4klwhnt2v1d" module=node node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.323340395+09:00" level=error msg="Event api.EventUpdateTask: Failed to get service kiziizne7llebo4klwhnt2v1d for task qds3ohkgzl8xmbbuxi88jh7s9 state NEW: could not find service kiziizne7llebo4klwhnt2v1d" module=node node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.323360243+09:00" level=error msg="Event api.EventUpdateTask: Failed to get service kiziizne7llebo4klwhnt2v1d for task wh098t4mzlm8kl20rdrz5lpe6 state NEW: could not find service kiziizne7llebo4klwhnt2v1d" module=node node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.361772687+09:00" level=warning msg="network ofrqt0bvca0uddwrc4t23vkcg should be removed, but still has active attachments" module=node/agent node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.361858459+09:00" level=info msg="initialized VXLAN UDP port to 4790 " module=node node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.367768599+09:00" level=error msg="Failed to allocate network resources for node apy0tpjdo8njulc4kxkm6u53i" error="could not find network allocator state for network ofrqt0bvca0uddwrc4t23vkcg" module=node node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.367864079+09:00" level=error msg="Failed to allocate network resources for node lgwvkt31hp7iikk425s1hjbi6" error="could not find network allocator state for network ofrqt0bvca0uddwrc4t23vkcg" module=node node.id=apy0tpjdo8njulc4kxkm6u53i
Sep 19 14:37:47 ke2-rhel89-swarm-1 dockerd[1064]: time="2024-09-19T14:37:47.367947097+09:00" level=error msg="Failed to allocate network resources for node sw16fqkz94al7qwwqeksgtzeh" error="could not find network allocator state for network ofrqt0bvca0uddwrc4t23vkcg" module=node node.id=apy0tpjdo8njulc4kxkm6u53i

解決策

Node Underweighting: あるノードが短期間に複数回の失敗やタスク拒否を経験したため、Docker Swarmのスケジューリングアルゴリズムがこのノードの優先度を下げて、他のノードにタスクを振り分けようとしています。原因としては、ノードの過負荷やネットワークの問題が考えられます。

• 特定ホストサーバのリソース状況を確認確認してください。
• ネットワーク導通を確認してください。
• 特定ノードのコンテナで利用のリソース状況をご確認ください。
• 特定ノードの KE2 APP が正常に戻らな場合 docker サービスを再起度してください。

  $ systemctl restart docker.service
  

INS-CD4: Swarm ノードダウン・VMダウン・ネットワーク障害

VMダウン・ネットワーク障害・Dockerダウン場合、他のノードの docker でさまざまなエラーが発生する可能性があります。他のノード docker のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

• error sending message to peer
• rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host"

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

Sep 12 11:32:20 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:20.523563797+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:21 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:21.523164173+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:22 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:22.523003474+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:23 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:23.522837316+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:24 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:24.522786775+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:25 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:25.522822736+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:26 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:26.523336108+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:27 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:27.523037596+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:28 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:28.522947326+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:29 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:29.522647103+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:30 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:30.523393817+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:31 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:31.523423053+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:32 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:32.523047422+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""
Sep 12 11:32:33 ke2-rhel89-swarm-1 dockerd[1428]: time="2024-09-12T11:32:33.523162797+09:00" level=error msg="error sending message to peer" error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.20.47.12:2377: connect: no route to host\""

解決策

• ホストサーバの正常性をご確認ください。
• ネットワーク導通を確認してください。
• docker の正常動作をご確認ください

INS-CD5: Swarmノードとの高いネットワーク遅延

Swarmノードとの高いネットワーク遅延・高いパケットロス場合、さまざまなエラーが発生する可能性があります。dockerのログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

• i/o timeout
• Bulk sync to node 464a64613c02 timed out

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

Sep 24 09:23:31 ke2-rhel89-swarm-1 dockerd[1491]: time="2024-09-24T09:54:53.779568607+09:00" level=error msg="Bulk sync to node 464a64613c02 timed out"
Sep 24 09:23:31 ke2-rhel89-swarm-1 dockerd[1491]: time="2024-09-24T09:23:31.507549348+09:00" level=warning msg="memberlist: Failed fallback TCP ping: timeout 1s: read tcp 10.20.47.11:32850->10.20.47.13:7946: i/o timeout"
Sep 24 09:23:31 ke2-rhel89-swarm-1 dockerd[1491]: time="2024-09-24T09:23:31.507592099+09:00" level=info msg="memberlist: Suspect 464a64613c02 has failed, no acks received"
Sep 24 09:23:38 ke2-rhel89-swarm-1 dockerd[1491]: time="2024-09-24T09:23:38.508187215+09:00" level=warning msg="memberlist: Failed fallback TCP ping: timeout 1s: read tcp 10.20.47.11:52826->10.20.47.13:7946: i/o timeout"
Sep 24 09:23:38 ke2-rhel89-swarm-1 dockerd[1491]: time="2024-09-24T09:23:38.508220989+09:00" level=info msg="memberlist: Suspect 464a64613c02 has failed, no acks received"
Sep 24 09:23:53 ke2-rhel89-swarm-1 dockerd[1491]: time="2024-09-24T09:23:53.507787431+09:00" level=warning msg="memberlist: Failed fallback TCP ping: timeout 1s: read tcp 10.20.47.11:40330->10.20.47.13:7946: i/o timeout"
Sep 24 09:23:53 ke2-rhel89-swarm-1 dockerd[1491]: time="2024-09-24T09:23:53.507818329+09:00" level=info msg="memberlist: Suspect 464a64613c02 has failed, no acks received"

解決策

ネットワーク導通を確認してください。

DIAG-CD6: Gluster ボリュームが正しくマウントされてない

FAQ-21: Gluster ボリュームが正しくマウントされてない

Gluster ボリュームが正しくマウントされてない場合、docker のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

• invalid mount config for type \"bind\": bind source path does not exist: /mnt/gluster/var"

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.270116728+09:00" level=error msg="fatal task error" error="invalid mount config for type \"bind\": bind source path does not exist: /mnt/gluster/var" module=node/agent/taskmanager node.id=fki8ndj78y2khgyt7j6xn2duf service.id=sluwu58co2z03uda6c152n1zs task.id=7ju5umkdsfu4fmeftvx1fnnds
Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.270198833+09:00" level=error msg="fatal task error" error="invalid mount config for type \"bind\": bind source path does not exist: /mnt/gluster/var" module=node/agent/taskmanager node.id=fki8ndj78y2khgyt7j6xn2duf service.id=rm6u3rvx5ky7d338yzxweu3ld task.id=k42sbhn8l1jgsxk3tqbemluu6
Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.270116788+09:00" level=error msg="fatal task error" error="invalid mount config for type \"bind\": bind source path does not exist: /mnt/gluster/var" module=node/agent/taskmanager node.id=fki8ndj78y2khgyt7j6xn2duf service.id=sxiy4vyddfl0dj48ksnwkl3m3 task.id=08t2nbt92lty5q58mnpf03o61
Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.270134992+09:00" level=error msg="fatal task error" error="invalid mount config for type \"bind\": bind source path does not exist: /mnt/gluster/var" module=node/agent/taskmanager node.id=fki8ndj78y2khgyt7j6xn2duf service.id=ei4r6335y09ifqa32b1nx44pu task.id=qg2ybb4x35dvxsl5f6trd3r8q
Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.270342094+09:00" level=error msg="fatal task error" error="invalid mount config for type \"bind\": bind source path does not exist: /mnt/gluster/ssl" module=node/agent/taskmanager node.id=fki8ndj78y2khgyt7j6xn2duf service.id=g6e2w2pqhyq2czgk5dspmbzzg task.id=yl0eh4618ynufvqihtdm7yl0k
Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.382825963+09:00" level=warning msg="failed to deactivate service binding for container ke2_kompira.3.vmyc0f2y5pcafg7990hzdonkp" error="No such container: ke2_kompira.3.vmyc0f2y5pcafg7990hzdonkp" module=node/agent node.id=fki8ndj78y2khgyt7j6xn2duf
Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.382829870+09:00" level=warning msg="failed to deactivate service binding for container ke2_kengine.1.tgyt99r4jsnjucv6ap407l7l5" error="No such container: ke2_kengine.1.tgyt99r4jsnjucv6ap407l7l5" module=node/agent node.id=fki8ndj78y2khgyt7j6xn2duf
Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.382845971+09:00" level=warning msg="failed to deactivate service binding for container ke2_rabbitmq.3.vwaw3y3hfzvtzzgi1zvt4z3cr" error="No such container: ke2_rabbitmq.3.vwaw3y3hfzvtzzgi1zvt4z3cr" module=node/agent node.id=fki8ndj78y2khgyt7j6xn2duf
Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.382825853+09:00" level=warning msg="failed to deactivate service binding for container ke2_jobmngrd.2.m2r74rpixjnmbizghj3afry86" error="No such container: ke2_jobmngrd.2.m2r74rpixjnmbizghj3afry86" module=node/agent node.id=fki8ndj78y2khgyt7j6xn2duf
Sep 25 13:23:45 ke2-rhel89-swarm-1 dockerd[1444]: time="2024-09-25T13:23:45.382858785+09:00" level=warning msg="failed to deactivate service binding for container ke2_nginx.1.v59tx2b2tgvwg1hal4w7s58ar" error="No such container: ke2_nginx.1.v59tx2b2tgvwg1hal4w7s58ar" module=node/agent node.id=fki8ndj78y2khgyt7j6xn2duf

解決策

• 共有ファイルシステム (glusterfs)の正常性をご確認ください。

DIAG-DO7: docker ログに「error while reading from stream」というエラーが記録されている

特定ノードにリソース使用率が高い場合、さまざまなエラーが発生する可能性があります。docker のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

Sep  2 08:47:39 ke2-rhel89-swarm-1 dockerd[752072]: time="2024-09-02T08:47:39.284653297+09:00" level=warning msg="memberlist: Refuting a suspect message (from: a6a2e4038ef8)"
Sep  2 08:47:39 ke2-rhel89-swarm-1 dockerd[752072]: time="2024-09-02T08:47:39.509297932+09:00" level=error msg="error while reading from stream" error="rpc error: code = Canceled desc = context canceled"
Sep  2 08:51:09 ke2-rhel89-swarm-1 dockerd[752072]: time="2024-09-02T08:51:09.699574772+09:00" level=error msg="error while reading from stream" error="rpc error: code = Canceled desc = context canceled"
Sep  2 08:51:09 ke2-rhel89-swarm-1 dockerd[752072]: time="2024-09-02T08:51:09.700112278+09:00" level=warning msg="memberlist: Refuting a dead message (from: 0d7709ba92eb)"

解決策

リソース使用率が正常化すると、Docker で実行中コンテナは通常、自動的に回復します。ただし、回復になってない場合は、ホストサーバのリソース状況を確認確認してください。

クラスタ構成の rabbitmq ログ調査

INS-CR1: RabbitMQ の Mnesia データベースが破損している

長時間にわたってネットワーク分断やスプリットブレイン、このような状況が生じる可能性があります。RabbitMQ のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

• Mnesia function failed 99 times. Possibly an infinite retry loop; trying one last time
• reason: reached_max_restart_intensity

ログのサンプルエントリ

Node: ke2-rhel89-swarm-3

2024-09-05 17:57:59.080590+09:00 [info] <0.34211.0> accepting AMQP connection <0.34211.0> (10.0.2.125:56332 -> 10.0.2.54:5672)
2024-09-05 17:57:59.080977+09:00 [warning] <0.34211.0> Mnesia->Khepri fallback handling: Mnesia function failed 99 times. Possibly an infinite retry loop; trying one last time
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>   crasher:
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     initial call: rabbit_reader:init/3
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     pid: <0.34211.0>
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     registered_name: []
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     exception exit: {aborted,
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>                         {no_exists,[rabbit_runtime_parameters,cluster_name]}}
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>       in function  mnesia:abort/1 (mnesia.erl, line 362)
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>       in call from rabbit_db_rtparams:get_in_mnesia/1 (rabbit_db_rtparams.erl, line 148)
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>       in call from rabbit_runtime_parameters:lookup0/2 (rabbit_runtime_parameters.erl, line 362)
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>       in call from rabbit_runtime_parameters:value0/1 (rabbit_runtime_parameters.erl, line 356)
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>       in call from rabbit_nodes:cluster_name/0 (rabbit_nodes.erl, line 104)
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>       in call from rabbit_reader:server_properties/1 (rabbit_reader.erl, line 240)
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>       in call from rabbit_reader:start_connection/3 (rabbit_reader.erl, line 1131)
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>       in call from rabbit_reader:handle_input/3 (rabbit_reader.erl, line 1081)
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     ancestors: [<0.34209.0>,<0.710.0>,<0.709.0>,<0.708.0>,<0.706.0>,
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>                   <0.705.0>,rabbit_sup,<0.254.0>]
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     message_queue_len: 1
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     messages: [{'EXIT',#Port<0.1428>,normal}]
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     links: [<0.34209.0>]
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     dictionary: [{process_name,
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>                       {rabbit_reader,
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>                           <<"10.0.2.125:56332 -> 10.0.2.54:5672">>}}]
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     trap_exit: true
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     status: running
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     heap_size: 2586
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     stack_size: 28
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>     reductions: 10565
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0>   neighbours:
2024-09-05 17:57:59.081138+09:00 [error] <0.34211.0> 
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>     supervisor: {<0.34209.0>,rabbit_connection_sup}
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>     errorContext: child_terminated
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>     reason: {aborted,{no_exists,[rabbit_runtime_parameters,cluster_name]}}
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>     offender: [{pid,<0.34211.0>},
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>                {id,reader},
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>                {mfargs,{rabbit_reader,start_link,
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>                                       [<0.34210.0>,
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>                                        {acceptor,{0,0,0,0,0,0,0,0},5672}]}},
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>                {restart_type,transient},
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>                {significant,true},
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>                {shutdown,300000},
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0>                {child_type,worker}]
2024-09-05 17:57:59.081622+09:00 [error] <0.34209.0> 
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>     supervisor: {<0.34209.0>,rabbit_connection_sup}
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>     errorContext: shutdown
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>     reason: reached_max_restart_intensity
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>     offender: [{pid,<0.34211.0>},
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>                {id,reader},
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>                {mfargs,{rabbit_reader,start_link,
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>                                       [<0.34210.0>,
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>                                        {acceptor,{0,0,0,0,0,0,0,0},5672}]}},
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>                {restart_type,transient},
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>                {significant,true},
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>                {shutdown,300000},
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0>                {child_type,worker}]
2024-09-05 17:57:59.081788+09:00 [error] <0.34209.0> 
2024-09-05 17:58:36.651258+09:00 [info] <0.34270.0> accepting AMQP connection <0.34270.0> (10.0.2.132:49752 -> 10.0.2.54:5672)
2024-09-05 17:58:36.651753+09:00 [warning] <0.34270.0> Mnesia->Khepri fallback handling: Mnesia function failed 99 times. Possibly an infinite retry loop; trying one last time
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>   crasher:
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     initial call: rabbit_reader:init/3
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     pid: <0.34270.0>
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     registered_name: []
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     exception exit: {aborted,
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>                         {no_exists,[rabbit_runtime_parameters,cluster_name]}}
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>       in function  mnesia:abort/1 (mnesia.erl, line 362)
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>       in call from rabbit_db_rtparams:get_in_mnesia/1 (rabbit_db_rtparams.erl, line 148)
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>       in call from rabbit_runtime_parameters:lookup0/2 (rabbit_runtime_parameters.erl, line 362)
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>       in call from rabbit_runtime_parameters:value0/1 (rabbit_runtime_parameters.erl, line 356)
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>       in call from rabbit_nodes:cluster_name/0 (rabbit_nodes.erl, line 104)
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>       in call from rabbit_reader:server_properties/1 (rabbit_reader.erl, line 240)
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>       in call from rabbit_reader:start_connection/3 (rabbit_reader.erl, line 1131)
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>       in call from rabbit_reader:handle_input/3 (rabbit_reader.erl, line 1081)
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     ancestors: [<0.34268.0>,<0.710.0>,<0.709.0>,<0.708.0>,<0.706.0>,
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>                   <0.705.0>,rabbit_sup,<0.254.0>]
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     message_queue_len: 1
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     messages: [{'EXIT',#Port<0.1430>,normal}]
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     links: [<0.34268.0>]
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     dictionary: [{process_name,
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>                       {rabbit_reader,
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>                           <<"10.0.2.132:49752 -> 10.0.2.54:5672">>}}]
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     trap_exit: true
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     status: running
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     heap_size: 2586
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     stack_size: 28
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>     reductions: 10561
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0>   neighbours:
2024-09-05 17:58:36.652032+09:00 [error] <0.34270.0> 
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>     supervisor: {<0.34268.0>,rabbit_connection_sup}
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>     errorContext: child_terminated
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>     reason: {aborted,{no_exists,[rabbit_runtime_parameters,cluster_name]}}
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>     offender: [{pid,<0.34270.0>},
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>                {id,reader},
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>                {mfargs,{rabbit_reader,start_link,
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>                                       [<0.34269.0>,
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>                                        {acceptor,{0,0,0,0,0,0,0,0},5672}]}},
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>                {restart_type,transient},
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>                {significant,true},
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>                {shutdown,300000},
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0>                {child_type,worker}]
2024-09-05 17:58:36.652688+09:00 [error] <0.34268.0> 
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>     supervisor: {<0.34268.0>,rabbit_connection_sup}
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>     errorContext: shutdown
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>     reason: reached_max_restart_intensity
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>     offender: [{pid,<0.34270.0>},
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>                {id,reader},
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>                {mfargs,{rabbit_reader,start_link,
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>                                       [<0.34269.0>,
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>                                        {acceptor,{0,0,0,0,0,0,0,0},5672}]}},
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>                {restart_type,transient},
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>                {significant,true},
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>                {shutdown,300000},
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0>                {child_type,worker}]
2024-09-05 17:58:36.652820+09:00 [error] <0.34268.0> 
2024-09-05 17:58:37.987335+09:00 [info] <0.34280.0> accepting AMQP connection <0.34280.0> (10.0.2.131:36582 -> 10.0.2.54:5672)
2024-09-05 17:58:37.987755+09:00 [warning] <0.34280.0> Mnesia->Khepri fallback handling: Mnesia function failed 99 times. Possibly an infinite retry loop; trying one last time

解決策

1. rabbitmq クラスタ状況を確認してください

   $ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl cluster_status
   
   Basics
   
   Cluster name: rabbit@mq-ke2-rhel89-swarm-1
   Total CPU cores available cluster-wide: 12
   
   Disk Nodes
   
   rabbit@mq-ke2-rhel89-swarm-1
   rabbit@mq-ke2-rhel89-swarm-2
   rabbit@mq-ke2-rhel89-swarm-3
   
   Running Nodes
   
   rabbit@mq-ke2-rhel89-swarm-1
   rabbit@mq-ke2-rhel89-swarm-2
   rabbit@mq-ke2-rhel89-swarm-3
   
   Versions
   
   rabbit@mq-ke2-rhel89-swarm-1: RabbitMQ 3.13.7 on Erlang 26.2.5.5
   rabbit@mq-ke2-rhel89-swarm-2: RabbitMQ 3.13.7 on Erlang 26.2.5.5
   rabbit@mq-ke2-rhel89-swarm-3: RabbitMQ 3.13.7 on Erlang 26.2.5.5
   
   CPU Cores
   
   Node: rabbit@mq-ke2-rhel89-swarm-1, available CPU cores: 4
   Node: rabbit@mq-ke2-rhel89-swarm-2, available CPU cores: 4
   Node: rabbit@mq-ke2-rhel89-swarm-3, available CPU cores: 4
   
   Maintenance status
   
   Node: rabbit@mq-ke2-rhel89-swarm-1, status: not under maintenance
   Node: rabbit@mq-ke2-rhel89-swarm-2, status: not under maintenance
   Node: rabbit@mq-ke2-rhel89-swarm-3, status: not under maintenance
   
   Alarms
   
   (none)
   
   Network Partitions
   
   (none)
   
   Listeners
   
   Node: rabbit@mq-ke2-rhel89-swarm-1, interface: [::], port: 15692, protocol: http/prometheus, purpose: Prometheus exporter API over HTTP
   Node: rabbit@mq-ke2-rhel89-swarm-1, interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
   Node: rabbit@mq-ke2-rhel89-swarm-1, interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
   Node: rabbit@mq-ke2-rhel89-swarm-1, interface: [::], port: 5671, protocol: amqp/ssl, purpose: AMQP 0-9-1 and AMQP 1.0 over TLS
   Node: rabbit@mq-ke2-rhel89-swarm-2, interface: [::], port: 15692, protocol: http/prometheus, purpose: Prometheus exporter API over HTTP
   Node: rabbit@mq-ke2-rhel89-swarm-2, interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
   Node: rabbit@mq-ke2-rhel89-swarm-2, interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
   Node: rabbit@mq-ke2-rhel89-swarm-2, interface: [::], port: 5671, protocol: amqp/ssl, purpose: AMQP 0-9-1 and AMQP 1.0 over TLS
   Node: rabbit@mq-ke2-rhel89-swarm-3, interface: [::], port: 15692, protocol: http/prometheus, purpose: Prometheus exporter API over HTTP
   Node: rabbit@mq-ke2-rhel89-swarm-3, interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
   Node: rabbit@mq-ke2-rhel89-swarm-3, interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
   Node: rabbit@mq-ke2-rhel89-swarm-3, interface: [::], port: 5671, protocol: amqp/ssl, purpose: AMQP 0-9-1 and AMQP 1.0 over TLS
   
   Feature flags
   
   Flag: classic_mirrored_queue_version, state: enabled
   Flag: classic_queue_type_delivery_support, state: enabled
   Flag: direct_exchange_routing_v2, state: enabled
   Flag: drop_unroutable_metric, state: enabled
   Flag: empty_basic_get_metric, state: enabled
   Flag: feature_flags_v2, state: enabled
   Flag: implicit_default_bindings, state: enabled
   Flag: khepri_db, state: disabled
   Flag: listener_records_in_ets, state: enabled
   Flag: maintenance_mode_status, state: enabled
   Flag: message_containers, state: enabled
   Flag: message_containers_deaths_v2, state: enabled
   Flag: quorum_queue, state: enabled
   Flag: quorum_queue_non_voters, state: enabled
   Flag: restart_streams, state: enabled
   Flag: stream_filtering, state: enabled
   Flag: stream_queue, state: enabled
   Flag: stream_sac_coordinator_unblock_group, state: enabled
   Flag: stream_single_active_consumer, state: enabled
   Flag: stream_update_config_command, state: enabled
   Flag: tracking_records_in_ets, state: enabled
   Flag: user_limits, state: enabled
   Flag: virtual_host_metadata, state: enabled
   

   上の情報で Cluster name あることと Running Nodes 3台があることを確認します。

   なければノード間通信を確認します。

   ネットワーク導通をご確認ください。

2. rabbitmq をリセットしてください。

   $ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl stop_app
   $ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl reset
   $ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl start_app
   

3. 正常に戻らな場合、rabbitmq コンテナを再起動してください

   $ docker restart < rabbitmq コンテナ ID>
   

4. 解決できない場合は、各ノードの RabbitMQ の volumeを削除も必要です。

   Rabbitmq のボリュームを削除

INS-CR2: Rabbitmq ログに「Partial partition detected」というエラーが記録されている

RabbitMQクラスタ内で部分的なネットワーク分割（パーシャルパーティション）が検出されたために発生します。これは、ネットワークの不具合や一部のノード間で通信ができなくなったことにより、スプリットブレインの状態が引き起こされ、クラスタの一貫性が失われたことを意味します。rabbitmq のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

2024-09-10 11:59:17.509560+09:00 [error] <0.514.0> Partial partition detected:
2024-09-10 11:59:17.509560+09:00 [error] <0.514.0>  * We saw DOWN from rabbit@mq-ke2-rhel89-swarm-2
2024-09-10 11:59:17.509560+09:00 [error] <0.514.0>  * We can still see rabbit@mq-ke2-rhel89-swarm-3 which can see rabbit@mq-ke2-rhel89-swarm-2
2024-09-10 11:59:17.509560+09:00 [error] <0.514.0>  * pause_minority mode enabled
2024-09-10 11:59:17.509560+09:00 [error] <0.514.0> We will therefore pause until the *entire* cluster recovers
2024-09-10 11:59:17.509619+09:00 [warning] <0.514.0> Cluster minority/secondary status detected - awaiting recovery

解決策

1. ノード間通信を確認する:

   ネットワーク導通をご確認ください。

2. ネットワークパーティションの問題で RabbitMQ 停止の可能性があります。

   RabbitMQ のステータスを以下の通りに確認します

   実行中場合以下のように情報表示される

   $ docker exec $(docker ps -q -f name=rabbit) rabbitmq-diagnostics  -q check_running
   
   RabbitMQ on node rabbit@mq-<ホスト名> is fully booted and running
   # ex: RabbitMQ on node rabbit@mq-ke2-rhel89-swarm-1 is fully booted and running
   

   停止場合以下の情報表示されます。

   docker exec $(docker ps -q -f name=rabbit) rabbitmq-diagnostics  -q check_running
   
   Error:
   RabbitMQ on node rabbit@mq-ke2-rhel89-swarm-1 is not running or has not fully booted yet (check with is_booting)
   

3. ネットワークパーティションが解消されたが、少数派の特定のーどのRabbitmqがまだ一時停止状態の場合、止されてしまったノードのrabbitmq を起動します。

   $ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl start_app
   

   起動しても正常に戻らない場合、rabbitmq コンテナを再起動します。

   # rabbitmq コンテナ ID: $ docker ps -q -f name=rabbitmq を実行してコンテナ ID を取得できます
   $ docker restart <rabbitmq コンテナ ID>
   

   まだ異常なら docker を再起動してください

   $ systemctl restart docker.service
   

INS-CR3: Rabbitmq ログに「Waiting for Mnesia tables」というエラーが記録されている

ネットワークが30秒以上中断された・リモートのRabbitMQノードが30秒以上接続できない 場合、特定のノードの RabbitMQ ログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

主なエラーメッセージ

• Waiting for Mnesia tables for 30000 ms, 6 retries left
• Error while waiting for Mnesia tables

ログのサンプルエントリ

2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,
2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0>                                         ['rabbit@mq-ke2-rhel89-swarm-3',
2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-2',
2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-1'],
2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0>                                         [rabbit_user,rabbit_user_permission,
2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0>                                          rabbit_runtime_parameters,
2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0>                                          rabbit_topic_permission,rabbit_vhost,
2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0>                                          rabbit_durable_queue,
2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0>                                          rabbit_durable_exchange,
2024-09-25 11:56:47.952788+09:00 [warning] <0.254.0>                                          rabbit_durable_route]}
2024-09-25 11:56:47.952925+09:00 [info] <0.254.0> Waiting for Mnesia tables for 30000 ms, 8 retries left
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0>                                         ['rabbit@mq-ke2-rhel89-swarm-3',
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-2',
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-1'],
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0>                                         [rabbit_user,rabbit_user_permission,
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0>                                          rabbit_runtime_parameters,
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0>                                          rabbit_topic_permission,rabbit_vhost,
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0>                                          rabbit_durable_queue,
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0>                                          rabbit_durable_exchange,
2024-09-25 11:57:17.953785+09:00 [warning] <0.254.0>                                          rabbit_durable_route]}
2024-09-25 11:57:17.953907+09:00 [info] <0.254.0> Waiting for Mnesia tables for 30000 ms, 7 retries left
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0>                                         ['rabbit@mq-ke2-rhel89-swarm-3',
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-2',
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-1'],
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0>                                         [rabbit_user,rabbit_user_permission,
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0>                                          rabbit_runtime_parameters,
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0>                                          rabbit_topic_permission,rabbit_vhost,
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0>                                          rabbit_durable_queue,
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0>                                          rabbit_durable_exchange,
2024-09-25 11:57:47.954844+09:00 [warning] <0.254.0>                                          rabbit_durable_route]}
2024-09-25 11:57:47.955042+09:00 [info] <0.254.0> Waiting for Mnesia tables for 30000 ms, 6 retries left
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0>                                         ['rabbit@mq-ke2-rhel89-swarm-3',
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-2',
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-1'],
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0>                                         [rabbit_user,rabbit_user_permission,
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0>                                          rabbit_runtime_parameters,
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0>                                          rabbit_topic_permission,rabbit_vhost,
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0>                                          rabbit_durable_queue,
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0>                                          rabbit_durable_exchange,
2024-09-25 11:58:17.955866+09:00 [warning] <0.254.0>                                          rabbit_durable_route]}
2024-09-25 11:58:17.955997+09:00 [info] <0.254.0> Waiting for Mnesia tables for 30000 ms, 5 retries left
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0>                                         ['rabbit@mq-ke2-rhel89-swarm-3',
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-2',
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-1'],
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0>                                         [rabbit_user,rabbit_user_permission,
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0>                                          rabbit_runtime_parameters,
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0>                                          rabbit_topic_permission,rabbit_vhost,
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0>                                          rabbit_durable_queue,
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0>                                          rabbit_durable_exchange,
2024-09-25 11:58:47.956902+09:00 [warning] <0.254.0>                                          rabbit_durable_route]}
2024-09-25 11:58:47.957045+09:00 [info] <0.254.0> Waiting for Mnesia tables for 30000 ms, 4 retries left
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0>                                         ['rabbit@mq-ke2-rhel89-swarm-3',
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-2',
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-1'],
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0>                                         [rabbit_user,rabbit_user_permission,
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0>                                          rabbit_runtime_parameters,
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0>                                          rabbit_topic_permission,rabbit_vhost,
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0>                                          rabbit_durable_queue,
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0>                                          rabbit_durable_exchange,
2024-09-25 11:59:17.957855+09:00 [warning] <0.254.0>                                          rabbit_durable_route]}
2024-09-25 11:59:17.958001+09:00 [info] <0.254.0> Waiting for Mnesia tables for 30000 ms, 3 retries left
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0>                                         ['rabbit@mq-ke2-rhel89-swarm-3',
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-2',
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0>                                          'rabbit@mq-ke2-rhel89-swarm-1'],
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0>                                         [rabbit_user,rabbit_user_permission,
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0>                                          rabbit_runtime_parameters,
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0>                                          rabbit_topic_permission,rabbit_vhost,
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0>                                          rabbit_durable_queue,
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0>                                          rabbit_durable_exchange,
2024-09-25 11:59:47.958928+09:00 [warning] <0.254.0>                                          rabbit_durable_route]}
2024-09-25 11:59:47.959111+09:00 [info] <0.254.0> Waiting for Mnesia tables for 30000 ms, 2 retries left

解決策

ノード間通信に一時的な問題があっても、rabbitmq は内部的に再試行を行ない自動回復する場合があります。

などにこの状況になる可能性があります。 RabbitMQは約9回の再試行を行います（9回×30秒＝約5分）そして回復されます。 実はよく自動回復になりますがもしそれでも復旧しない場合以下の steps を進んでください。

1. ノード間通信を確認する:

ネットワーク導通をご確認ください。

2. ネットワークの問題で RabbitMQ 停止の可能性があります。

   RabbitMQ のステータスを以下の通りに確認します

   実行中場合以下のように情報表示される

   $ docker exec $(docker ps -q -f name=rabbit) rabbitmq-diagnostics  -q check_running
   
   RabbitMQ on node rabbit@mq-<ホスト名> is fully booted and running
   # ex: RabbitMQ on node rabbit@mq-ke2-rhel89-swarm-1 is fully booted and running
   

   停止場合以下の情報表示されます。

   docker exec $(docker ps -q -f name=rabbit) rabbitmq-diagnostics  -q check_running
   
   Error:
   RabbitMQ on node rabbit@mq-ke2-rhel89-swarm-1 is not running or has not fully booted yet (check with is_booting)
   

3. ネットワーク問題が解消されたが、少数派の特定ノードの Rabbitmq がまだ停止状態の場合、停止されてしまったノードのrabbitmq を起動します。

   $ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl start_app
   

   起動しても正常に戻らない場合、rabbitmq コンテナを再起動します。

   # rabbitmq コンテナ ID: $ docker ps -q -f name=rabbitmq を実行してコンテナ ID を取得できます
   $ docker restart <rabbitmq コンテナ ID>
   

   画面の ./status や /system/info などを見て rabbitmq まだ異常なら 全てのノードの rabbitmq を再起動してください

   $ docker service update --force ke2_rabbitmq
   

INS-CR4: Rabbitmq ログに「erl_crash」というエラーが記録されている

rabbitmq のログ見ると以下のようなエラーが記録されている場合があります。

ログのサンプルエントリ

Node: ke2-rhel89-swarm-1

Crash dump is being written to: /var/log/rabbitmq/erl_crash.dump...done
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
Enabling plugins on node rabbit@mq-ke2-rhel89-swarm-1:
rabbitmq_auth_mechanism_ssl
The following plugins have been configured:
  rabbitmq_auth_mechanism_ssl
  rabbitmq_federation
  rabbitmq_management_agent
  rabbitmq_prometheus
  rabbitmq_web_dispatch
Applying plugin configuration to rabbit@mq-ke2-rhel89-swarm-1...
The following plugins have been enabled:
  rabbitmq_auth_mechanism_ssl

set 5 plugins.
Offline change; changes will take effect at broker restart.
=INFO REPORT==== 28-Oct-2024::07:31:11.890366 ===
    alarm_handler: {set,{system_memory_high_watermark,[]}}
2024-10-28 07:31:12.531435+09:00 [warning] <0.156.0> Overriding Erlang cookie using the value set in the environment
2024-10-28 07:31:13.848732+09:00 [notice] <0.44.0> Application syslog exited with reason: stopped
2024-10-28 07:31:13.848786+09:00 [notice] <0.254.0> Logging: switching to configured handler(s); following messages may not be visible in this log output
2024-10-28 07:31:13.849152+09:00 [notice] <0.254.0> Logging: configured log handlers are now ACTIVE
2024-10-28 07:31:13.854554+09:00 [info] <0.254.0> ra: starting system quorum_queues
2024-10-28 07:31:13.854594+09:00 [info] <0.254.0> starting Ra system: quorum_queues in directory: /var/lib/rabbitmq/mnesia/rabbit@mq-ke2-rhel89-swarm-1/quorum/rabbit@mq-ke2-rhel89-swarm-1
2024-10-28 07:31:13.891668+09:00 [info] <0.268.0> ra system 'quorum_queues' running pre init for 7 registered servers
2024-10-28 07:31:13.911893+09:00 [info] <0.269.0> ra: meta data store initialised for system quorum_queues. 7 record(s) recovered
2024-10-28 07:31:13.921881+09:00 [notice] <0.274.0> WAL: ra_log_wal init, open tbls: ra_log_open_mem_tables, closed tbls: ra_log_closed_mem_tables
2024-10-28 07:31:13.931462+09:00 [info] <0.254.0> ra: starting system coordination
2024-10-28 07:31:13.931499+09:00 [info] <0.254.0> starting Ra system: coordination in directory: /var/lib/rabbitmq/mnesia/rabbit@mq-ke2-rhel89-swarm-1/coordination/rabbit@mq-ke2-rhel89-swarm-1
2024-10-28 07:31:13.932199+09:00 [info] <0.282.0> ra system 'coordination' running pre init for 1 registered servers
dets: file "/var/lib/rabbitmq/mnesia/rabbit@mq-ke2-rhel89-swarm-1/coordination/rabbit@mq-ke2-rhel89-swarm-1/meta.dets" not properly closed, repairing ...
2024-10-28 07:31:13.941100+09:00 [info] <0.283.0> ra: meta data store initialised for system coordination. 1 record(s) recovered
2024-10-28 07:31:13.941262+09:00 [notice] <0.288.0> WAL: ra_coordination_log_wal init, open tbls: ra_coordination_log_open_mem_tables, closed tbls: ra_coordination_log_closed_mem_tables
2024-10-28 07:31:13.943398+09:00 [info] <0.254.0> ra: starting system coordination
2024-10-28 07:31:13.943423+09:00 [info] <0.254.0> starting Ra system: coordination in directory: /var/lib/rabbitmq/mnesia/rabbit@mq-ke2-rhel89-swarm-1/coordination/rabbit@mq-ke2-rhel89-swarm-1
2024-10-28 07:31:14.068431+09:00 [info] <0.254.0> Waiting for Khepri leader for 30000 ms, 9 retries left
2024-10-28 07:31:14.141114+09:00 [info] <0.254.0> Khepri leader elected
2024-10-28 07:31:14.141167+09:00 [info] <0.254.0> Waiting for Khepri projections for 30000 ms, 9 retries left
2024-10-28 07:31:14.422786+09:00 [notice] <0.293.0> RabbitMQ metadata store: candidate -> leader in term: 6307 machine version: 1
2024-10-28 07:31:14.540727+09:00 [notice] <0.254.0> Feature flags: checking nodes `rabbit@mq-ke2-rhel89-swarm-1` and `rabbit@mq-ke2-rhel89-swarm-2` compatibility...
2024-10-28 07:31:14.548508+09:00 [notice] <0.254.0> Feature flags: nodes `rabbit@mq-ke2-rhel89-swarm-1` and `rabbit@mq-ke2-rhel89-swarm-2` are compatible
2024-10-28 07:31:14.710432+09:00 [notice] <0.44.0> Application mnesia exited with reason: stopped
2024-10-28 07:31:14.711298+09:00 [notice] <0.254.0> Feature flags: checking nodes `rabbit@mq-ke2-rhel89-swarm-1` and `rabbit@mq-ke2-rhel89-swarm-3` compatibility...
2024-10-28 07:31:14.714022+09:00 [notice] <0.254.0> Feature flags: nodes `rabbit@mq-ke2-rhel89-swarm-1` and `rabbit@mq-ke2-rhel89-swarm-3` are compatible
2024-10-28 07:31:14.716732+09:00 [notice] <0.44.0> Application mnesia exited with reason: stopped

BOOT FAILED
===========
Error during startup: {error,
                          {inconsistent_cluster,
2024-10-28 07:31:14.716907+09:00 [error] <0.254.0> 
                              "Mnesia: node 'rabbit@mq-ke2-rhel89-swarm-1' thinks it's clustered with node 'rabbit@mq-ke2-rhel89-swarm-3', but 'rabbit@mq-ke2-rhel89-swarm-3' disagrees"}}

2024-10-28 07:31:14.716907+09:00 [error] <0.254.0> BOOT FAILED
2024-10-28 07:31:14.716907+09:00 [error] <0.254.0> ===========
2024-10-28 07:31:14.716907+09:00 [error] <0.254.0> Error during startup: {error,
2024-10-28 07:31:14.716907+09:00 [error] <0.254.0>                           {inconsistent_cluster,
2024-10-28 07:31:14.716907+09:00 [error] <0.254.0>                               "Mnesia: node 'rabbit@mq-ke2-rhel89-swarm-1' thinks it's clustered with node 'rabbit@mq-ke2-rhel89-swarm-3', but 'rabbit@mq-ke2-rhel89-swarm-3' disagrees"}}
2024-10-28 07:31:14.716907+09:00 [error] <0.254.0> 
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>   crasher:
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     initial call: application_master:init/4
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     pid: <0.253.0>
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     registered_name: []
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     exception exit: {{inconsistent_cluster,
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>                          "Mnesia: node 'rabbit@mq-ke2-rhel89-swarm-1' thinks it's clustered with node 'rabbit@mq-ke2-rhel89-swarm-3', but 'rabbit@mq-ke2-rhel89-swarm-3' disagrees"},
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>                      {rabbit,start,[normal,[]]}}
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>       in function  application_master:init/4 (application_master.erl, line 142)
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     ancestors: [<0.252.0>]
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     message_queue_len: 1
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     messages: [{'EXIT',<0.254.0>,normal}]
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     links: [<0.252.0>,<0.44.0>]
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     dictionary: []
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     trap_exit: true
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     status: running
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     heap_size: 987
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     stack_size: 28
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>     reductions: 191
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0>   neighbours:
2024-10-28 07:31:15.717893+09:00 [error] <0.253.0> 
2024-10-28 07:31:15.724125+09:00 [notice] <0.44.0> Application rabbit exited with reason: {{inconsistent_cluster,"Mnesia: node 'rabbit@mq-ke2-rhel89-swarm-1' thinks it's clustered with node 'rabbit@mq-ke2-rhel89-swarm-3', but 'rabbit@mq-ke2-rhel89-swarm-3' disagrees"},{rabbit,start,[normal,[]]}}
Runtime terminating during boot (terminating)

解決策

1. ノード間通信を確認する

   ネットワーク導通をご確認ください。

2. 正常に戻らな場合、rabbitmq コンテナを再起動してください

   $ docker restart < rabbitmq コンテナ ID>
   

   まだ異常なら docker を再起動してください

   $ systemctl restart docker.service
   

3. 解決できない場合は、各ノードの RabbitMQ の ボリュームを削除も必要です。

   Rabbitmq のボリュームを削除

INS-CR5: Rabbitmq ログに「leader saw pre_vote_rpc for unknown peer」という警告が記録されている

RabbitMQのクラスタ設定は他のノードと同じ状態になってないとこのような状況発生される可能性があります。 rabbitmq のログ見ると以下ような情報が表示される可能性があります。

ログのサンプルエントリ

2024-10-31 09:17:36.242578+09:00 [info] <0.13048.0> closing AMQP connection <0.13048.0> (10.0.5.55:37762 -> 10.0.5.26:5672, vhost: '/', user: 'guest')
2024-10-31 09:17:36.588684+09:00 [warning] <0.12964.0> closing AMQP connection <0.12964.0> (10.0.5.55:37732 -> 10.0.5.26:5672, vhost: '/', user: 'guest'):
2024-10-31 09:17:36.588684+09:00 [warning] <0.12964.0> client unexpectedly closed TCP connection
2024-10-31 09:17:39.566677+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:17:44.715647+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:17:46.508294+09:00 [info] <0.13368.0> accepting AMQP connection <0.13368.0> (10.0.5.56:41862 -> 10.0.5.26:5672)
2024-10-31 09:17:46.550266+09:00 [info] <0.13368.0> connection <0.13368.0> (10.0.5.56:41862 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:17:47.222382+09:00 [info] <0.13389.0> accepting AMQP connection <0.13389.0> (10.0.5.56:41866 -> 10.0.5.26:5672)
2024-10-31 09:17:47.264270+09:00 [info] <0.13389.0> connection <0.13389.0> (10.0.5.56:41866 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:17:47.864849+09:00 [info] <0.13407.0> accepting AMQP connection <0.13407.0> (10.0.5.56:33694 -> 10.0.5.26:5672)
2024-10-31 09:17:47.907315+09:00 [info] <0.13407.0> connection <0.13407.0> (10.0.5.56:33694 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:17:48.506052+09:00 [info] <0.13425.0> accepting AMQP connection <0.13425.0> (10.0.5.56:33704 -> 10.0.5.26:5672)
2024-10-31 09:17:48.548373+09:00 [info] <0.13425.0> connection <0.13425.0> (10.0.5.56:33704 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:17:49.176771+09:00 [info] <0.13443.0> accepting AMQP connection <0.13443.0> (10.0.5.56:33718 -> 10.0.5.26:5672)
2024-10-31 09:17:49.219214+09:00 [info] <0.13443.0> connection <0.13443.0> (10.0.5.56:33718 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:17:49.258780+09:00 [info] <0.13461.0> accepting AMQP connection <0.13461.0> (10.0.5.56:33732 -> 10.0.5.26:5672)
2024-10-31 09:17:49.301266+09:00 [info] <0.13461.0> connection <0.13461.0> (10.0.5.56:33732 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:17:50.482669+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:17:55.794600+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:01.492628+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:07.175701+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:12.572585+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:17.895508+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:22.965648+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:28.798947+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:34.309611+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:40.272684+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:46.007727+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:51.897620+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:18:52.423122+09:00 [info] <0.13461.0> closing AMQP connection <0.13461.0> (10.0.5.56:33732 -> 10.0.5.26:5672, vhost: '/', user: 'guest')
2024-10-31 09:18:52.661815+09:00 [info] <0.13389.0> closing AMQP connection <0.13389.0> (10.0.5.56:41866 -> 10.0.5.26:5672, vhost: '/', user: 'guest')
2024-10-31 09:18:53.078702+09:00 [info] <0.13407.0> closing AMQP connection <0.13407.0> (10.0.5.56:33694 -> 10.0.5.26:5672, vhost: '/', user: 'guest')
2024-10-31 09:18:53.480129+09:00 [info] <0.13425.0> closing AMQP connection <0.13425.0> (10.0.5.56:33704 -> 10.0.5.26:5672, vhost: '/', user: 'guest')
2024-10-31 09:18:53.881663+09:00 [info] <0.13443.0> closing AMQP connection <0.13443.0> (10.0.5.56:33718 -> 10.0.5.26:5672, vhost: '/', user: 'guest')
2024-10-31 09:18:54.202519+09:00 [warning] <0.13368.0> closing AMQP connection <0.13368.0> (10.0.5.56:41862 -> 10.0.5.26:5672, vhost: '/', user: 'guest'):
2024-10-31 09:18:54.202519+09:00 [warning] <0.13368.0> client unexpectedly closed TCP connection
2024-10-31 09:18:57.255652+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:19:03.158772+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}
2024-10-31 09:19:04.172441+09:00 [info] <0.13730.0> accepting AMQP connection <0.13730.0> (10.0.5.57:43388 -> 10.0.5.26:5672)
2024-10-31 09:19:04.216282+09:00 [info] <0.13730.0> connection <0.13730.0> (10.0.5.57:43388 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:19:04.878854+09:00 [info] <0.13749.0> accepting AMQP connection <0.13749.0> (10.0.5.57:43394 -> 10.0.5.26:5672)
2024-10-31 09:19:04.921416+09:00 [info] <0.13749.0> connection <0.13749.0> (10.0.5.57:43394 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:19:05.512922+09:00 [info] <0.13767.0> accepting AMQP connection <0.13767.0> (10.0.5.57:43396 -> 10.0.5.26:5672)
2024-10-31 09:19:05.556265+09:00 [info] <0.13767.0> connection <0.13767.0> (10.0.5.57:43396 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:19:06.151074+09:00 [info] <0.13786.0> accepting AMQP connection <0.13786.0> (10.0.5.57:43398 -> 10.0.5.26:5672)
2024-10-31 09:19:06.193316+09:00 [info] <0.13786.0> connection <0.13786.0> (10.0.5.57:43398 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:19:06.754779+09:00 [info] <0.13816.0> accepting AMQP connection <0.13816.0> (10.0.5.57:43414 -> 10.0.5.26:5672)
2024-10-31 09:19:06.797260+09:00 [info] <0.13816.0> connection <0.13816.0> (10.0.5.57:43414 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:19:06.836767+09:00 [info] <0.13834.0> accepting AMQP connection <0.13834.0> (10.0.5.57:43430 -> 10.0.5.26:5672)
2024-10-31 09:19:06.879273+09:00 [info] <0.13834.0> connection <0.13834.0> (10.0.5.57:43430 -> 10.0.5.26:5672): user 'guest' authenticated and granted access to vhost '/'
2024-10-31 09:19:08.679523+09:00 [warning] <0.1454.0> queue 'default/rpc_queue' in vhost '/': leader saw pre_vote_rpc for unknown peer {'%2F_default/rpc_queue','rabbit@mq-ke2-rhel89-swarm-2'}

解決策

1. rabbitmq クラスタ状況を確認してください

   $ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl cluster_status
   
   Basics
   
   Cluster name: rabbit@mq-ke2-rhel89-swarm-1
   Total CPU cores available cluster-wide: 12
   
   Disk Nodes
   
   rabbit@mq-ke2-rhel89-swarm-1
   rabbit@mq-ke2-rhel89-swarm-2
   rabbit@mq-ke2-rhel89-swarm-3
   
   Running Nodes
   
   rabbit@mq-ke2-rhel89-swarm-1
   rabbit@mq-ke2-rhel89-swarm-2
   rabbit@mq-ke2-rhel89-swarm-3
   
   Versions
   
   rabbit@mq-ke2-rhel89-swarm-1: RabbitMQ 3.13.7 on Erlang 26.2.5.5
   rabbit@mq-ke2-rhel89-swarm-2: RabbitMQ 3.13.7 on Erlang 26.2.5.5
   rabbit@mq-ke2-rhel89-swarm-3: RabbitMQ 3.13.7 on Erlang 26.2.5.5
   
   CPU Cores
   
   Node: rabbit@mq-ke2-rhel89-swarm-1, available CPU cores: 4
   Node: rabbit@mq-ke2-rhel89-swarm-2, available CPU cores: 4
   Node: rabbit@mq-ke2-rhel89-swarm-3, available CPU cores: 4
   
   Maintenance status
   
   Node: rabbit@mq-ke2-rhel89-swarm-1, status: not under maintenance
   Node: rabbit@mq-ke2-rhel89-swarm-2, status: not under maintenance
   Node: rabbit@mq-ke2-rhel89-swarm-3, status: not under maintenance
   
   Alarms
   
   (none)
   
   Network Partitions
   
   (none)
   
   Listeners
   
   Node: rabbit@mq-ke2-rhel89-swarm-1, interface: [::], port: 15692, protocol: http/prometheus, purpose: Prometheus exporter API over HTTP
   Node: rabbit@mq-ke2-rhel89-swarm-1, interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
   Node: rabbit@mq-ke2-rhel89-swarm-1, interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
   Node: rabbit@mq-ke2-rhel89-swarm-1, interface: [::], port: 5671, protocol: amqp/ssl, purpose: AMQP 0-9-1 and AMQP 1.0 over TLS
   Node: rabbit@mq-ke2-rhel89-swarm-2, interface: [::], port: 15692, protocol: http/prometheus, purpose: Prometheus exporter API over HTTP
   Node: rabbit@mq-ke2-rhel89-swarm-2, interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
   Node: rabbit@mq-ke2-rhel89-swarm-2, interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
   Node: rabbit@mq-ke2-rhel89-swarm-2, interface: [::], port: 5671, protocol: amqp/ssl, purpose: AMQP 0-9-1 and AMQP 1.0 over TLS
   Node: rabbit@mq-ke2-rhel89-swarm-3, interface: [::], port: 15692, protocol: http/prometheus, purpose: Prometheus exporter API over HTTP
   Node: rabbit@mq-ke2-rhel89-swarm-3, interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
   Node: rabbit@mq-ke2-rhel89-swarm-3, interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
   Node: rabbit@mq-ke2-rhel89-swarm-3, interface: [::], port: 5671, protocol: amqp/ssl, purpose: AMQP 0-9-1 and AMQP 1.0 over TLS
   
   Feature flags
   
   Flag: classic_mirrored_queue_version, state: enabled
   Flag: classic_queue_type_delivery_support, state: enabled
   Flag: direct_exchange_routing_v2, state: enabled
   Flag: drop_unroutable_metric, state: enabled
   Flag: empty_basic_get_metric, state: enabled
   Flag: feature_flags_v2, state: enabled
   Flag: implicit_default_bindings, state: enabled
   Flag: khepri_db, state: disabled
   Flag: listener_records_in_ets, state: enabled
   Flag: maintenance_mode_status, state: enabled
   Flag: message_containers, state: enabled
   Flag: message_containers_deaths_v2, state: enabled
   Flag: quorum_queue, state: enabled
   Flag: quorum_queue_non_voters, state: enabled
   Flag: restart_streams, state: enabled
   Flag: stream_filtering, state: enabled
   Flag: stream_queue, state: enabled
   Flag: stream_sac_coordinator_unblock_group, state: enabled
   Flag: stream_single_active_consumer, state: enabled
   Flag: stream_update_config_command, state: enabled
   Flag: tracking_records_in_ets, state: enabled
   Flag: user_limits, state: enabled
   Flag: virtual_host_metadata, state: enabled
   

   上の情報で Cluster name あることと Running Nodes 3台があることを確認します。

   なければノード間通信を確認します。

   ネットワーク導通をご確認ください。

2. 全てのノードの rabbitmq を再起動してください

   $ docker service update --force ke2_rabbitmq
   

3. 解決できない場合は、各ノードの RabbitMQ の ボリュームを削除も必要です。

   Rabbitmq のボリュームを削除

オンプレシングル構成固有コンテナのログの調査

シングル構成・外部 DB シングル構成： kengine ログ調査

INS-SK1: kengine ログに「nc: bad address 'rabbitmq'」というエラーが記録されている

kengine のログに次のようなエラーが記録されている場合は、rabbitmq が停止している可能性が考えられます。

エラーログのサンプル

nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'
nc: bad address 'rabbitmq'

解決策

以下のコマンドで rabbitmq コンテナのステータスを確認してください。

$ docker ps -a -f name=rabbitmq

CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                      PORTS     NAMES
4d8f2e81eb86   kompira.azurecr.io/kompira-enterprise:latest   "docker-entrypoint.s…"   16 minutes ago   Exited (1) 12 seconds ago             ke2-rabbitmq-1

ステータスが UP である場合はコンテナとしては起動しているため、コンテナ停止以外の問題が起きていると考えられます。 ホストサーバや docker サービス、ネットワークなどの状態を確認してみてください。

ステータスが UP 以外の場合は、停止しているコンテナの最新の ID を指定して再起動してみてください。

$ docker restart <rabbitmq コンテナ ID>

再起動しても正常に戻らない場合は、rabbitmq コンテナ内部で動作している rabbitmq アプリをリセットしてみてください。

$ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl stop_app
$ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl reset
$ docker exec $(docker ps -q -f name=rabbit) rabbitmqctl start_app

この時点でも正常に戻らない場合は、KE2 APP の再起動を試してみてください。

INS-SK2: kengine ログに「Error -2 connecting to redis:6379. Name does not resolve」というエラーが記録されている

kengine のログに次のようなエラーが記録されている場合も、redis が停止している可能性が考えられます。

主なエラーメッセージ

redis.exceptions.ConnectionError: Error -2 connecting to redis:6379. Name does not resolve.

ログのサンプルエントリ

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/kompira/core/cache.py", line 55, in get_object
    cache.touch(key)
  File "/usr/local/lib/python3.11/site-packages/django/core/cache/backends/redis.py", line 195, in touch
    return self._cache.touch(key, self.get_backend_timeout(timeout))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/cache/backends/redis.py", line 115, in touch
    return bool(client.expire(key, timeout))
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/redis/commands/core.py", line 1762, in expire
    return self.execute_command("EXPIRE", name, time, *exp_option)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 1266, in execute_command
    conn = self.connection or pool.get_connection(command_name, **options)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/redis/connection.py", line 1461, in get_connection
    connection.connect()
  File "/usr/local/lib/python3.11/site-packages/redis/connection.py", line 713, in connect
    raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error -2 connecting to redis:6379. Name does not resolve.

解決策

以下のコマンドで redis コンテナのステータスを確認してください。

$ docker ps -a -f name=redis

CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                      PORTS     NAMES
4d8f2e81eb86   kompira.azurecr.io/kompira-enterprise:latest   "docker-entrypoint.s…"   16 minutes ago   Exited (1) 12 seconds ago             ke2-redis-1

ステータスが UP である場合はコンテナとしては起動しているため、コンテナ停止以外の問題が起きていると考えられます。 ホストサーバや docker サービス、ネットワークなどの状態を確認してみてください。

ステータスが UP 以外の場合は、停止しているコンテナの最新の ID を指定して再起動してみてください。

$ docker restart <redis コンテナ ID>

この時点でも正常に戻らない場合は、KE2 APP の再起動を試してみてください。

シングル構成・外部 DB シングル構成： jobmngrd ログ調査

INS-SJ1: RabbitMQ が応答していません

rabbitmq コンテナの応答がない場合、jobmngrd のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

[2024-10-27 11:59:36,322:jm-ke2-rhel89-swarm-1:kompira_jobmngrd:MainThread] ERROR: [AMQPConnector] AMQP connection error: connection timed out
[2024-10-27 11:59:36,323:jm-ke2-rhel89-swarm-1:kompira_jobmngrd:MainThread] INFO: [AMQPConnector] waiting 30 seconds for retry connection ...
[2024-10-27 12:00:06,323:jm-ke2-rhel89-swarm-1:kompira_jobmngrd:MainThread] INFO: [AMQPConnector] _connect start
[2024-10-27 12:00:36,325:jm-ke2-rhel89-swarm-1:kompira_jobmngrd:MainThread] ERROR: [AMQPConnector] AMQP connection error: connection timed out
[2024-10-27 12:00:36,325:jm-ke2-rhel89-swarm-1:kompira_jobmngrd:MainThread] INFO: [AMQPConnector] waiting 30 seconds for retry connection ...
[2024-10-27 12:01:06,325:jm-ke2-rhel89-swarm-1:kompira_jobmngrd:MainThread] INFO: [AMQPConnector] _connect start
[2024-10-27 12:01:36,328:jm-ke2-rhel89-swarm-1:kompira_jobmngrd:MainThread] ERROR: [AMQPConnector] AMQP connection error: connection timed out
[2024-10-27 12:01:36,328:jm-ke2-rhel89-swarm-1:kompira_jobmngrd:MainThread] INFO: [AMQPConnector] waiting 30 seconds for retry connection ...

解決策

以下のログを調査してください。

• kengine ログに「nc: bad address 'rabbitmq'」というエラーが記録されている

シングル構成・外部 DB シングル構成： docker ログ調査

INS-SD1: docker デーモン不安定

VM にリソース使用率が高い場合、さまざまなエラーが発生する可能性があります。特に、Docker のログを確認すると、「ログのサンプルエントリ」のようなログが頻繁に表示される可能性もあります。

ログのサンプルエントリ

Oct  4 13:59:23 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 13:59:23 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 13:59:25 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 13:59:25 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 13:59:25 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 13:59:25 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 13:59:25 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 13:59:25 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 13:59:25 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 13:59:25 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 14:20:37 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 14:20:37 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 14:20:38 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 14:20:38 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 14:20:38 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 14:20:38 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 14:20:38 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 14:20:38 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 14:20:38 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 14:20:38 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)
Oct  4 14:20:38 ke2-rhel89-swarm-1 dockerd[1512]: 2024/10/04 14:20:38 http: superfluous response.WriteHeader call from go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*respWriterWrapper).WriteHeader (wrap.go:98)

解決策

リソース使用率が正常化すると、Dockerで実行中コンテナは通常、自動的に回復します。ただし、問題が解決しない場合は、以下の手順に従ってさらなる分析を行ってください。

1. ホストサーバのリソース状況を確認してください。

2. Docker コンテナで利用のリソースを確認する

   Docker コンテナで利用のリソース状況をご確認ください。

シングル構成固有コンテナのログの調査

シングル構成の kengine ログ調査

INS-SAK1: kengine ログに「nc: bad address 'postgres'」というエラーが記録されている

kengine のログに次のようなエラーが記録されている場合は、postgres が停止している可能性が考えられます。

ログのサンプルエントリ

Job "Engine.monitor (trigger: interval[0:00:10], next run at: 2024-10-03 10:11:32 JST)" raised an exception
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django_dbconn_retry/apps.py", line 45, in ensure_connection_with_retries
    self.connect()
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/base/base.py", line 270, in connect
    self.connection = self.get_new_connection(conn_params)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/postgresql/base.py", line 275, in get_new_connection
    connection = self.Database.connect(**conn_params)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.OperationalError: could not translate host name "postgres" to address: Name does not resolve
nc: bad address 'postgres'
nc: bad address 'postgres'
nc: bad address 'postgres'

解決策

以下のコマンドで postgres コンテナのステータスを確認してください。

$ docker ps -a -f name=postgres

CONTAINER ID   IMAGE                                          COMMAND                  CREATED          STATUS                      PORTS     NAMES
4d8f2e81eb86   kompira.azurecr.io/kompira-enterprise:latest   "docker-entrypoint.s…"   16 minutes ago   Exited (1) 12 seconds ago             ke2-postgres-1

ステータスが UP である場合はコンテナとしては起動しているため、コンテナ停止以外の問題が起きていると考えられます。 ホストサーバや docker サービス、ネットワークなどの状態を確認してみてください。

ステータスが UP 以外の場合は、停止しているコンテナの最新の ID を指定して再起動してみてください。

$ docker restart <postgres コンテナ ID>

KE2 APP が正常に戻らない場合は、docker サービスを再起動してみてください。

$ systemctl restart docker.service

それでも正常に動作しない場合は、サポートまでお問い合わせください。

外部 DB シングル構成固有コンテナのログの調査

外部 DB シングル構成の kengine ログ調査

INS-SEK1: kengine ログに「Is the server running on that host and accepting TCP/IP connections? Host is unreachable」というエラーが記録されている

KE2 APP とデータベースサーバー間でネットワーク接続の問題が発生している場合、kengine のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django_dbconn_retry/apps.py", line 51, in ensure_connection_with_retries
    self.connect()
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/base/base.py", line 270, in connect
    self.connection = self.get_new_connection(conn_params)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/postgresql/base.py", line 275, in get_new_connection
    connection = self.Database.connect(**conn_params)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.OperationalError: connection to server at "10.20.47.20", port 9999 failed: Host is unreachable
	Is the server running on that host and accepting TCP/IP connections?

解決策

KE2 APP から外部 DB ホストサーバに ping して答えがない原因でこのような状況発生されます。この場合、以下の調査してください。

• 外部 DB ホストサーバの正常性をご確認ください。
• 外部 DB ホストサーバのネットワークインターフェイスの状態を確認してください。
• 外部 DB ホストサーバの Network 設定を確認してください。

外部 DB ホストサーバやネットワークなどの保守手順については、本マニュアルの範囲外になります。

INS-SEK2: kengine ログに「ERROR: unable to read message kind DETAIL: kind does not match between main(4e) slot[1] (53)」というエラーが記録されている

DB クラスタ(pgpool)利用すると、DB ノード間のネットワーク遅延・DB サーバリソース使用率が高い場合、kengine のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-1:docker-entrypoint.sh] INFO: Starting docker-entrypoint(kompirad) [KOMPIRA_VERSION=2.0.0, LANGUAGE_CODE=ja]
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-1:docker-entrypoint.sh] INFO: Wait for Cache: redis:6379 -t 15
wait-for-it.sh: waiting 15 seconds for redis:6379
wait-for-it.sh: redis:6379 is available after 0 seconds
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-1:docker-entrypoint.sh] INFO: Cache is ready
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-1:docker-entrypoint.sh] INFO: Wait for Database: 10.20.47.20:9999 -t 30
wait-for-it.sh: waiting 30 seconds for 10.20.47.20:9999
wait-for-it.sh: 10.20.47.20:9999 is available after 0 seconds
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-1:docker-entrypoint.sh] INFO: Database is ready
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-1:docker-entrypoint.sh] INFO: Wait for flock: /var/opt/kompira/.flock_init_data
[2024-09-11 08:57:54:ke-ke2-rhel89-swarm-1:docker-entrypoint.sh] INFO: flock is acquired
[2024-09-11 08:57:55,634:ke-ke2-rhel89-swarm-1:MainProcess:MainThread] INFO: AXES: BEGIN version 6.0.5, blocking by combination of username and ip_address
Reconnecting to the database didn't help connection to server at "10.20.47.20", port 9999 failed: ERROR:  unable to read message kind
DETAIL:  kind does not match between main(4e) slot[1] (53)

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/django_dbconn_retry/apps.py", line 51, in ensure_connection_with_retries
    self.connect()
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/base/base.py", line 270, in connect
    self.connection = self.get_new_connection(conn_params)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/db/backends/postgresql/base.py", line 275, in get_new_connection
    connection = self.Database.connect(**conn_params)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.OperationalError: connection to server at "10.20.47.20", port 9999 failed: ERROR:  unable to read message kind
DETAIL:  kind does not match between main(4e) slot[1] (53)

解決策

1. pgpoolノード間の通信問題

   ネットワークの問題により、pgpoolノード間で適切な調整ができず、ノード間でデータは同期が取れない場合があります。

2. pgpoolノードのリソース使用率が高い

   pgpool VMでCPU、メモリ、I/Oの使用率が高い場合、データベース操作が遅くなり、DB ノード間でデータは同期が取れない場合があります。

外部 DB ホストサーバやネットワークなどの保守手順については、本マニュアルの範囲外になります。

INS-SEK3: kengine ログに「database error: cannot execute UPDATE in a read-only transaction」というエラーが記録されている

データベースに不整合場合、kengine のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

[2024-09-25 10:48:17,034:ke-ke2-rhel89-swarm-1:kompirad:MainThread] ERROR: Failed to start due to database error: cannot execute UPDATE in a read-only transaction

解決策

1. 以下のコマンドで外部 DB 操作をご確認ください。

   # ベーシックコマンド: psql -h <DB IP> -p <DB PORT> -U <USER> -d <DATABASE>
   # pgpool場合、DB IP は Virtual IP です。DB PORT は defaultでは 9999 です。
   # postgres場合、DB IP は DB サーバ IP です。DB PORT は defaultでは 5432 です。
   # USER は postgres です。
   # DATABASE は kompira です。
   # 例：
   $ psql -h 10.20.47.20 -p 9999 -U postgres -d kompira -c "CREATE TEMP TABLE pg_temp.test_table (value TEXT); INSERT INTO pg_temp.test_table (value) VALUES ('Dummy Test Value'); SELECT * FROM pg_temp.test_table;"
   
   Password for user postgres: *****
         value       
   ------------------
   Dummy Test Value
   (1 row)
   

   上のコマンドで問題があれば、外部 DB 管理者に連絡してください。

   psql コマンドが利用できない場合は、CentOS/RHEL: postgresql、Debian/Ubuntu: postgresql-client をインストールしてください。

2. 外部 DB 操作に問題がなければ、KE2 APP 側での DB 接続セッションの問題の可能性があります。この場合、kengine サービスを再起動してください。

   # kengine コンテナ ID: $ docker ps -f name=kengine を実行してコンテナ ID を取得できます
   $ docker restart <kengine コンテナ ID>
   

3. 解決できない場合、docker サービスを再起動してください。

   $ systemctl restart docker.service
   

INS-SEK4: kengine ログに「Is the server running on that host and accepting TCP/IP connections? Connection refused」というエラーが記録されている

データベースが停止されてしまった場合、kengine のログを確認すると、「ログのサンプルエントリ」のようなログが表示される可能性があります。

ログのサンプルエントリ

Reconnecting to the database didn't help connection to server at "10.20.47.20", port 9999 failed: Connection refused
	Is the server running on that host and accepting TCP/IP connections?

解決策

• 外部データベースへのアクセスを確認してみてください。