fixpoint / ke-docker Goto Github PK

View Code? Open in Web Editor NEW

0.0 3.0 0.0 150 KB

Shell 100.00%

ke-docker's Introduction

Kompira Enterprise: シンプルで軽量な次世代運用自動化プラットフォーム

1. Kompira Enterprise とは

Kompira Enterprise は IT 運用管理業務の自動化を支援するための基盤システムです。ジョブフローを記述することで、様々な運用業務、管理業務、さらには障害の復旧処理まで自動化することができます。

2. Kompira Enteprise Docker Compose ファイル

このリポジトリには、以下の各種デプロイの構成に対応した Kompira Enterprise の Docker Compose ファイル が含まれています。

オンプレシングル
- 標準シングル構成
- 外部DBシングル構成
オンプレクラスタ
- Swarmクラスタ構成
クラウド
- AzureCI構成

3. クイックスタート

Docker エンジンと git コマンドがインストールされているサーバであれば、以下のコマンドを実行することですぐに使い始めることができます。

$ git clone https://github.com/fixpoint/ke2-docker.git
$ cd ke2-docker/ke2/single/basic
$ docker compose pull
$ ../../../scripts/create-cert.sh
$ docker compose up -d

ブラウザから Docker エンジンが動作しているサーバにアクセス (https://<サーバのアドレス>/.login) するとログイン画面が表示されます。以下のアカウントでログインして Kompira をはじめることができます。

ユーザ名: root
パスワード: root

ログイン後の画面の右上にある「ヘルプ」をクリックすると、オンラインマニュアルが表示されますので使い方の参考にしてください。

※ なお、上記手順の create-cert.sh では自己署名 SSL 証明書を生成しています。その SSL 証明書をコンテナ起動時に HTTPS および AMQPS に適用していますので、ブラウザでアクセスする際にセキュリティの警告が表示されます。

4. 準備と設定

4.1. Docker エンジンの準備

Docker エンジンのインストール手順と起動方法については以下を参考にしてください。

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

4.2. 環境変数の設定

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

環境変数	意味	デフォルト値	備考
`TZ`	タイムゾーン	"Asia/Tokyo"	画面やログで表示される時刻のタイムゾーンを指定します
`LANGUAGE_CODE`	言語コード ("ja" or "en")	"ja"	初回起動時にインポートする初期データの言語を指定します
`KOMPIRA_IMAGE_NAME`	Kompira イメージ	"kompira.azurecr.io/kompira-enterprise"	デプロイする Kompira コンテナのイメージを指定します
`KOMPIRA_IMAGE_TAG`	Kompira タグ	"latest"	デプロイする Kompira コンテナのタグを指定します

5. Kompira ライセンス

Kompira Enterprise ライセンス利用規約に同意の上、ダウンロードページからダウンロードして下さい。

Kompira の使用には、ライセンス登録が必要です。詳しくは [email protected] までご連絡ください。

※ ご利用の Kompira のバージョンに依らず、最新のライセンス利用規約が適用されます。

6. Kompira 関連の情報

6.1. Kompira 運用自動化コラム

Kompira の実践的な使い方やジョブフローの書き方については運用自動化コラムを参考にしてみてください。

6.2. Kompira コミュニティサイト

Kompira の使い方が分からない場合などは、コミュニティ> KompiraEnterprise関連を参考にしてみてください。同じような質問や回答が見つからない場合は、新たに投稿してみてください。

ke-docker's People

Contributors

Watchers

ke-docker's Issues

kompira 以外のコンテナイメージのバージョンを最新にする

https://fixpoint.slack.com/archives/C05M1B75QJ0/p1721956164633989

以下の2つについてバージョン指定を上げる

postgresql: 16.3-alpine
nginx: 1.27-alpine

また合わせて、postgresql コンテナのメジャーバージョンごとに PGDATA 領域のボリューム名を分けるようにしておく。
これはメジャーアップデート時に PGDATA 領域のボリュームを残してマイグレーションするための準備で、実際の移行手順については別途調査する。

setup_pgpool.sh での pgdg-redhat-all.repo の更新方法を見直す

現状は pgdg-redhat-all.repo の設定変更を patch ファイルの適用で行っているが、以下で同じことができるはず

dnf config-manager --setopt 'pgdg*.exclude=pgpool*' --save

nginx -> uwsgi のタイムアウト値を長くする

https://fixpoint.slack.com/archives/C02TEND3J56/p1721622877514149

redis で起動時警告が出ないようにカーネルパラメータを調整する

https://fixpoint.backlog.jp/view/QA_KE-126

コンテナ起動時に sysctl で以下カーネルパラメータを設定するようにする。

net.core.somaxconn=512
vm.overcommit_memory=1

※ net.core.somaxconn は docker compose でパラメータ設定できるが、vm.overcommit_memory は対応していないため、起動スクリプトで設定するようにするなど方式を検討する。

Swarmクラスタ構成でコンテナ間の AMQP をノード内で接続するようにする

現状 AMQP_URL のデフォルトはノード名 rabbitmq になっているため、接続ごとに docker による振り分けがされ、ノードをまたいだコネクションになっています。短期間のコネクションであれば、これは負荷分散として機能してよいと思いますが、AMQP に関しては基本的に接続しっぱなしです。

これは、ノード単位で障害があったときに、別ノードの接続にも影響が波及してしまい、悪影響が大きくなりやすいのではないかと懸念しています。（あと、そもそもログの追跡がとても面倒）

最近のアップデートで各 rabbitmq コンテナにはホスト名 mq-<ノード名> を付けるようにしていて、AMQP の接続先も AMQP_URL 環境変数で指定できるようにしていますので、AMQP_URL のデフォルトを例えば AMQP_URL="amqp://guest:guest@mq-{{.Node.Hostname}}:5672" とすることで、kompira ,kengine ,jobmngrd から rabbitmq への接続を同じノード内にまとめることができます（swarm 構成で実験済み）。

フロントエンドでの操作や、rabbitmq をまたいだインターフェース（kengine -> jobmngrd など）については、rabbitmq でノードをまたいで負荷分散（というかラウンドロビン？）されると思いますが、kompira, kengine, jobmngrd と rabbitmq の間の接続はノードに閉じてもよい、障害時や調査を考えるとむしろ適切だと考えています。

※ 実際に適切に負荷分散されるかは評価が必要

各サービスを最低限の権限を持つユーザで動作させるようにする

現状各サービスは基本的にコンテナでデフォルト指定されたユーザで実行しており、いくつかのサービスは root で実行している。セキュリティ的には各サービスは最低限の権限で動作させることが望ましいと考えられ、以下のような対策を検討したい。

各サービスを動作させるユーザを指定できるようにする。
最低限の権限を持つユーザを簡単に準備できるようにする。

swarm 構成で再起動または再構成した rabbitmq コンテナがクラスタに再加入できるようにする

現在 rabbitmq の /var/lib/rabbitmq は名前無しボリュームで bind しているが、swarm 構成ではノードを再起動したときにコンテナとともにボリュームが再構成されて動作中のクラスタに参加できない問題が生じる。
https://fixpoint.slack.com/archives/C05M1B75QJ0/p1722222537022709

/var/lib/rabbitmq を名前付きボリュームにすることで、再起動時も mnesia が保持されてクラスタに参加できるようになる。

この場合でも以下について注意または検討する必要がある。

docker stack rm してもボリュームが残ること。（マニュアルに記載する）
サーバをリプレイスするような場合にも同様の問題が起きる可能性がある。（環境回復手順を整理する）

環境変数でロギング設定を指定できるようにする

https://fixpoint.backlog.jp/view/QA_KE-93

ホスト名が FQDN でなくても rabbitmq-server が動作するようにする

現状ホスト名が FQDN でないと rabbitmq-server が正常に動作しない。
RABBITMQ_USE_LONGNAME=true 指定を廃して、ホスト名が FQDN でない環境でも動作するようにする。
※ ホスト名が FQDN の環境であっても正常に動作することを確認する。

postgresql.conf の archive_mode をoff にする

setup_pgpool.sh 内で archive_mode を on にしているが、そうすると、/var/lib/pgsql/archivedir に WAL が溜まっていき、DISK領域を圧迫する。
PITR（ポイントインタイムリカバリ）を行わないのであれば、この設定は不要なので、デフォルトのセットアップでは、 archive_mode を off （postgresql のデフォルト）のままにしておく。

pgpool.conf の process_management_mode を dynamic にする

現状の、process_management_mode = static で num_init_chidren =64 だと、
pgpool 起動時に、必要以上に子プロセスを生成してしまう。

これを避けるために、デフォルトでは、 process_management_mode = dynamic にする。
これによって、num_init_children は 128 まで上げて良いかもしれない。

rabbitmq イメージとして 3.13.x を利用するようにする

rabbitmq-server 3.12 から 3.13 系へローリングアップデートしようとすると incompatible_feature_flags 問題があるため、ke2 系では最初から rabbitmq-server 3.13 系を利用するようにする。

parameters.py をコンテナ共通で編集できるようにする

非公開ながら settings.py や parameters.py を編集することで kompira/django パラメータを調整できるが、現状では kompira/kengine コンテナで別々になっているため、それぞれのコンテナで編集する必要がある。
コンテナで共通にパラメータ調整できるように、docker volumes または docker configs とすることを検討する。

動作要件に docker-compose-plugin が 2.24.6 以上であることを追記する

https://fixpoint.backlog.jp/view/QA_KE-123

docker-compose-plugin が 2.24.5 未満だと、compose ファイルの互換性がなくエラーになる。

create-cert.sh を実行したあとにコンテナが残らないようにする

現状 scripts/create-cert.sh を実行したあとにコンテナが残ってしまっているので、これを残らないようにする。

$ ./scripts/create-cert.sh 
Create local CA certificate: /home/takahashi/ke-docker/ssl/local-ca.crt
..+............+++++++++++++++++++++++++++++++++++++++*....+............+....+...+.....+...+............+++++++++++++++++++++++++++++++++++++++*...+...+.....+.......+........+...+.+...+...............+...+........+.+...........+...+....+..+.........+......+....+.........
...+..+.+......+.....+....+......+......+.....+....+...+......+.................+...+.+...............+...+........+.........+..........+...+..+....+.........+...+..............+.........+......+......+...+.......+...............+...+..++++++
......+++++++++++++++++++++++++++++++++++++++*....+..+....+++++++++++++++++++++++++++++++++++++++*.+.........+.....+.++++++
-----
Create SSL (self-signed) certificate: /home/takahashi/ke-docker/ssl/server.crt
.......+....+...+..+...+....+...+........+....+......+........+......+.........+.+........+.+.....+.+......+++++++++++++++++++++++++++++++++++++++*.+...+...+...........+...+...+............+.+..+...+..........+.....+.+....................+.+..+.+.....+....+..+.+.........
...+......+..+...+.......+...+......+++++++++++++++++++++++++++++++++++++++*.....+...................................+....+..+...+....+..+...+...+....+...........+.......+.....+.......+...+......+.....+............+...+......+.+.....+...+....+......+............+...+....
.....+..+...+.......+......+.........+.....+...+.+.................+.........+.+........+.+.....+......+.......+.....+.......+...+......+..+..........+...+..+...+.+.....+...+......+...............+.+...+...+.....+..........+...+..+..........+..............+......+...+...
.........+...+.+...+...........+.........+......+.+...+.....+..........++++++
....+...+..+++++++++++++++++++++++++++++++++++++++*.+.+..+................+......+........+.+.....+..........+.....+++++++++++++++++++++++++++++++++++++++*.......+.......+..............+.......+...+..+.......+...+..+...............+.+......+......+..+.+..+....+...+......
+.................+.........+.+.........+.....+....+...........+....+......+..............+....+.....+.+..+...+.+...+.....+.+..............+...+..........+..+.......+...........+...+......+.+...+..............+...+..........+...+.....+.+......+..................+......+.
....+......+...+.+.....+......+.........+.+.....+.........+......+...+................+...+..+..........+.....+.+.....+............+......+......+.............+..+.+..+.+..+............+.+......+...+.....+.+...............+.....+.+...........+...+....+..+.........+....+.
..............+.....+.......++++++
-----
Certificate request self-signature ok
subject=CN = takahashi-devel4.dev.fixpoint.co.jp

$ docker container ls -a
CONTAINER ID   IMAGE          COMMAND                   CREATED          STATUS                      PORTS     NAMES
7ac96ec7aeda   0cf5e36d9d33   "docker-entrypoint.s…"   1 second ago     Exited (0) 1 second ago               angry_pare
11dea654d7e7   0cf5e36d9d33   "docker-entrypoint.s…"   1 second ago     Exited (0) 1 second ago               mystifying_nightingale
e98a26fca4ad   0cf5e36d9d33   "docker-entrypoint.s…"   2 seconds ago    Exited (0) 1 second ago               nervous_ride
9790a065cf15   0cf5e36d9d33   "docker-entrypoint.s…"   2 seconds ago    Exited (0) 2 seconds ago              peaceful_babbage
f5d8f20182ce   0cf5e36d9d33   "docker-entrypoint.s…"   15 minutes ago   Exited (0) 15 minutes ago             focused_feistel
f5a129595276   0cf5e36d9d33   "docker-entrypoint.s…"   15 minutes ago   Exited (0) 15 minutes ago             upbeat_diffie
d362c670df80   0cf5e36d9d33   "docker-entrypoint.s…"   15 minutes ago   Exited (0) 15 minutes ago             jolly_vaughan
6a492d82e2fe   0cf5e36d9d33   "docker-entrypoint.s…"   15 minutes ago   Exited (0) 15 minutes ago             heuristic_mestorf
5ca34d34c348   0cf5e36d9d33   "docker-entrypoint.s…"   16 minutes ago   Exited (0) 16 minutes ago             romantic_noether
3600cc1f118e   0cf5e36d9d33   "docker-entrypoint.s…"   16 minutes ago   Exited (0) 16 minutes ago             determined_hertz
ec9465198ffb   0cf5e36d9d33   "docker-entrypoint.s…"   16 minutes ago   Exited (0) 16 minutes ago             serene_heisenberg
1761324e866b   0cf5e36d9d33   "docker-entrypoint.s…"   16 minutes ago   Exited (0) 16 minutes ago             angry_hugle
690b186027b8   0cf5e36d9d33   "docker-entrypoint.s…"   16 minutes ago   Exited (0) 16 minutes ago             cool_feynman

ディレクトリ構成を見直す

現在4つの構成に対応するディレクトリがフラットに並んでいますが、「シングル構成 (single)」「クラスタ構成 (cluster)」「クラウド構成 (cloud)」という分類に分けて再整理します。

現パス	現構成名	新パス	新構成名
/allinone	オンプレシングル(オールインワン)構成	/ke2/single/basic	シングル標準構成
/withoutdb	オンプレシングル(DB 外部接続)構成	/ke2/single/extdb	シングル外部DB構成
/swarm	クラスタ構成	/ke2/cluster/swarm	クラスタ構成(Swarm)
/azureci	Azure Container Instances 構成	/ke2/cloud/azureci	AzureCI構成

Kubernetes によるクラスタ構成をサポートする場合は /cluster/kubernetes を追加するとか、
AWS や GCP でのクラウド構成をサポートする場合は /cloud/hoge を追加する、などの拡張性を考えています。

setup_pgpool.sh での pgpool.conf の設定方法を見直す

現在 setup_pgpool.sh では /etc/pgpool-II/pgpool.conf に対する設定を、長い patch ファイルを .sh 上で持って適用しているが、オリジナルの pgpool.conf がもともとサイズが大きいため、独自に設定している部分が分かりにくい。

pgpool.conf は include 文が使えるので、例えばオリジナルの pgpool.conf には以下の一行を加えるだけにして、

include 'ke2-pgpool.conf'

include する設定ファイルで、KE2 としての設定を並べるほうが扱いやすいと思われる。
（自分自身で手作業で pgpool を構築したときは、include で対処した）

フロントエンドの手前にリバースプロキシを配置してSSLアクセスするとアクセス禁止になる

クラスタ構成でフロントエンドの手前にリバースプロキシとして HAProxy を配置して SSL アクセスさせようとしたところ、CSRF検証エラーでアクセス禁止(403) になった。

なお、HTTP アクセスの場合は問題なくアクセス振り分けができる（ただし nginx.conf で HTTP -> HTTPS のリダイレクトの無効化は必要）。

HAProxy 側の設定に不備がある可能性も、Django 側の設定に不備がある可能性があるが、原因の調査と対策の検討を行なう。

監査ログ(audit.log)についても環境変数でロギング設定できるようにする

kompira 本体側は環境変数 KOMPIRA_AUDIT_LOGGING_LEVEL で監査ログの「記録レベル値」を指定できる
kompira コンテナおよび kengine コンテナのデプロイ時に環境変数を指定できるようにする

デフォルトでは fluentd でのロギングを廃止してローカルに記録する

kompira-v2 本体のロギング方針変更に伴い、デフォルトでは fluentd によるログ集約を廃止して、ログは docker 標準ドライバによりローカルに記録する。
https://fixpoint.slack.com/archives/C05M1B75QJ0/p1720694991100669

標準デプロイで SSL 構成になるようにする

現状では付属の docker-compose.yml でデプロイすると非 SSL 構成になり、SSL 構成では証明書の準備と docker-compose.override.yml の準備が必要になる。

これを標準のデプロイ手順で（少なくとも HTTP は）SSL 構成になるようにしたい（非 SSL 構成がオプション）。
合わせて、証明書の自動生成なども合わせて検討する。

そのためには、オレオレ証明書でも良いので、証明書一式を自動で作成できるようにしておきたい。(ssl証明書を置くディレクトリを証明書作成用の一時的なコンテナからマウントして、スクリプト起動して生成、みたいなことはできそうだけど)

https://fixpoint.slack.com/archives/C05M1B75QJ0/p1707285013365149?thread_ts=1707267203.613079&cid=C05M1B75QJ0

クラスタ構成で nginx -> kompira を同じノード上で接続するようにする

nginx -> kompira の接続設定はデフォルト kompira:8000 となっていて、ホスト名 kompira は docker によるコンテナ名前解決によって行われる。そのためクラスタ構成ではあるノードの nginx から別のノードの kompira コンテナに接続する場合もある。

一方でクラスタ構成においては、ノード単位での内部連携をさせノード単位での正常性確認をとれるようにしておきたいため、nginx -> kompira を同じノード上で接続するような設定にしたい。

具体的には nginx から kompira の接続先を ap-{{.Node.Hostname}} となるようにする。

nginx の設定ファイルで環境変数を展開できるようにする

nginx の設定ファイルで環境変数を参照できるようにしたい。具体的には upstream django のサーバ指定を例えば以下のように環境変数で指定しておきたい。（クラスタ構成で同じノードの kompira コンテナに接続するようにしたいが、これは別課題で扱う予定）

upstream django {
    server ${KOMPIRA_HOST}:${KOMPIRA_PORT};
}

nginx の設定ファイル上では直接環境変数を参照するような記述はできないが、docker-nginx では起動時に envsubst コマンドを用いてテンプレートを環境変数展開して設定ファイルを出力する機構が備わっており、これを利用できるようにする。

https://github.com/nginxinc/docker-nginx/blob/master/entrypoint/20-envsubst-on-templates.sh

これはテンプレートとなる設定ファイルを /etc/nginx/templates/*.template として配置しておけば、環境変数を展開して /etc/nginx/conf.d/* に設定ファイルを書き出してくれる。