ke-docker's Issues
parameters.py をコンテナ共通で編集できるようにする
非公開ながら settings.py や parameters.py を編集することで kompira/django パラメータを調整できるが、現状では kompira/kengine コンテナで別々になっているため、それぞれのコンテナで編集する必要がある。
コンテナで共通にパラメータ調整できるように、docker volumes または docker configs とすることを検討する。
kompira 以外のコンテナイメージのバージョンを最新にする
https://fixpoint.slack.com/archives/C05M1B75QJ0/p1721956164633989
以下の2つについてバージョン指定を上げる
- postgresql: 16.3-alpine
- nginx: 1.27-alpine
また合わせて、postgresql コンテナのメジャーバージョンごとに PGDATA 領域のボリューム名を分けるようにしておく。
これはメジャーアップデート時に PGDATA 領域のボリュームを残してマイグレーションするための準備で、実際の移行手順については別途調査する。
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
フロントエンドの手前にリバースプロキシを配置してSSLアクセスするとアクセス禁止になる
動作要件に docker-compose-plugin が 2.24.6 以上であることを追記する
https://fixpoint.backlog.jp/view/QA_KE-123
docker-compose-plugin が 2.24.5 未満だと、compose ファイルの互換性がなくエラーになる。
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 は対応していないため、起動スクリプトで設定するようにするなど方式を検討する。
環境変数でロギング設定を指定できるようにする
ディレクトリ構成を見直す
現在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 を追加する、などの拡張性を考えています。
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 の間の接続はノードに閉じてもよい、障害時や調査を考えるとむしろ適切だと考えています。
※ 実際に適切に負荷分散されるかは評価が必要
swarm 構成で再起動または再構成した rabbitmq コンテナがクラスタに再加入できるようにする
現在 rabbitmq の /var/lib/rabbitmq は名前無しボリュームで bind しているが、swarm 構成ではノードを再起動したときにコンテナとともにボリュームが再構成されて動作中のクラスタに参加できない問題が生じる。
https://fixpoint.slack.com/archives/C05M1B75QJ0/p1722222537022709
/var/lib/rabbitmq を名前付きボリュームにすることで、再起動時も mnesia が保持されてクラスタに参加できるようになる。
この場合でも以下について注意または検討する必要がある。
- docker stack rm してもボリュームが残ること。(マニュアルに記載する)
- サーバをリプレイスするような場合にも同様の問題が起きる可能性がある。(環境回復手順を整理する)
クラスタ構成で nginx -> kompira を同じノード上で接続するようにする
nginx -> kompira の接続設定はデフォルト kompira:8000
となっていて、ホスト名 kompira は docker によるコンテナ名前解決によって行われる。そのためクラスタ構成ではあるノードの nginx から別のノードの kompira コンテナに接続する場合もある。
一方でクラスタ構成においては、ノード単位での内部連携をさせノード単位での正常性確認をとれるようにしておきたいため、nginx -> kompira を同じノード上で接続するような設定にしたい。
具体的には nginx から kompira の接続先を ap-{{.Node.Hostname}}
となるようにする。
postgresql.conf の archive_mode をoff にする
setup_pgpool.sh 内で archive_mode を on にしているが、そうすると、/var/lib/pgsql/archivedir に WAL が溜まっていき、DISK領域を圧迫する。
PITR(ポイントインタイムリカバリ)を行わないのであれば、この設定は不要なので、デフォルトのセットアップでは、 archive_mode を off (postgresql のデフォルト)のままにしておく。
nginx -> uwsgi のタイムアウト値を長くする
各サービスを最低限の権限を持つユーザで動作させるようにする
現状各サービスは基本的にコンテナでデフォルト指定されたユーザで実行しており、いくつかのサービスは root で実行している。セキュリティ的には各サービスは最低限の権限で動作させることが望ましいと考えられ、以下のような対策を検討したい。
- 各サービスを動作させるユーザを指定できるようにする。
- 最低限の権限を持つユーザを簡単に準備できるようにする。
監査ログ(audit.log)についても環境変数でロギング設定できるようにする
- kompira 本体側は環境変数
KOMPIRA_AUDIT_LOGGING_LEVEL
で監査ログの「記録レベル値」を指定できる - kompira コンテナおよび kengine コンテナのデプロイ時に環境変数を指定できるようにする
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 構成になるようにする
現状では付属の docker-compose.yml でデプロイすると非 SSL 構成になり、SSL 構成では証明書の準備と docker-compose.override.yml の準備が必要になる。
これを標準のデプロイ手順で(少なくとも HTTP は)SSL 構成になるようにしたい(非 SSL 構成がオプション)。
合わせて、証明書の自動生成なども合わせて検討する。
そのためには、オレオレ証明書でも良いので、証明書一式を自動で作成できるようにしておきたい。(ssl証明書を置くディレクトリを証明書作成用の一時的なコンテナからマウントして、スクリプト起動して生成、みたいなことはできそうだけど)
rabbitmq イメージとして 3.13.x を利用するようにする
rabbitmq-server 3.12 から 3.13 系へローリングアップデートしようとすると incompatible_feature_flags 問題があるため、ke2 系では 最初から rabbitmq-server 3.13 系を利用するようにする。
pgpool.conf の process_management_mode を dynamic にする
現状の、process_management_mode = static で num_init_chidren =64 だと、
pgpool 起動時に、必要以上に子プロセスを生成してしまう。
これを避けるために、デフォルトでは、 process_management_mode = dynamic にする。
これによって、num_init_children は 128 まで上げて良いかもしれない。
ホスト名が FQDN でなくても rabbitmq-server が動作するようにする
現状ホスト名が FQDN でないと rabbitmq-server が正常に動作しない。
RABBITMQ_USE_LONGNAME=true 指定を廃して、ホスト名が FQDN でない環境でも動作するようにする。
※ ホスト名が FQDN の環境であっても正常に動作することを確認する。
デフォルトでは fluentd でのロギングを廃止してローカルに記録する
kompira-v2 本体のロギング方針変更に伴い、デフォルトでは fluentd によるログ集約を廃止して、ログは docker 標準ドライバによりローカルに記録する。
https://fixpoint.slack.com/archives/C05M1B75QJ0/p1720694991100669
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/*
に設定ファイルを書き出してくれる。
setup_pgpool.sh での pgdg-redhat-all.repo の更新方法を見直す
現状は pgdg-redhat-all.repo の設定変更を patch ファイルの適用で行っているが、以下で同じことができるはず
dnf config-manager --setopt 'pgdg*.exclude=pgpool*' --save
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.