オンプレおじさんのコンテナちゃれんじ(その1. 机上調査編)

# おじさんスペック

- 全盛期使っていたのはRHEL4～6時代
- KVMでホストOSに仮想マシンを4～10台立てて別のホストとPacemakerで冗長化したことある
- 各仮想マシンの中でもPacemakerでApp起動順序制御やリソース監視したことある
- 触ったことがあるPamcemakerは`crm_mon`時代

# 何をやるのか

## 現状の構成

![構成図_現状 copy.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/259373/8041efb5-5382-9d97-e225-dca3851bf77c.png)

- 1台のWindows Serverに以下の3つのコンポーネントが存在
    - `Node.js`で作成したメインApp。RestAPI。
    - `PostgreSQL Server`
    - `Flask(Python)`で作成した管理画面 on `venv`

## こうしたい

![構成図_草案1 copy.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/259373/f8806bea-2306-9d07-de50-4674bc1768be.png)

※まだ`Docker`とか何も学んでいないので正しい構成であるかは不明

- ホストOSは`Ubuntu`。いずれ`Ubuntu`向けにしか提供されていないOSSを使う可能性があり、不慣れだがいまのうちから利用しておく
- `PostgreSQL Server`はレプリケーションで同期する
- 2つのホストは`IPaddr2`で論理IPをつけ外しする
- ホストのIFは2～3
    - 業務NW
    - データ同期NW
    - ハートビートNW
- いずれ他拠点にDRを構築し2:1構成もあり得るのでデータ同期NWは業務NWに乗せることも考えている。
    - 業務NWは既設だが、データ同期NWは新規に作るためDR先まで伸ばすのしんどい

# 知識を身につけよう

## k8sを知ろう

本当に`Pacemaker`使わなきゃいかんのか。`Kubernetes`はクラスタリングソフトになる？`Docker Engine`と`Container`の間のコントローラ？

を、ここ2～3日ずっと悩んでいた。調べるとクラスタソフトぽく見えるが、`Kubernetes`自身の冗長化が考慮されていない。ただのコントローラなのか？コントローラであれば、使うべきなのか。

というのが記載されていると期待する資料がこちら。
[コンテナを止めるな! PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとは](https://www.slideshare.net/ksk_ha/pacemakerhakubernetes-121194991)

読んだ感想は以下
- `Kubernetes` は安全な場所 `master` で稼働させる必要がある
- `Kubernetes` は DB のような `Stateful` なものを複数ノード上で `ACT/SBY` 制御させるのに一工夫必要そう
- `DB` など `Stateful` なコンポーネントがクラウドのサービスで起動しているシステムであれば良さそう

つーことで、草案の `Pacemaker + Docker` は概ねあってそう。

## PacemakerによるDockerの制御サポート状況を知ろう

`Pacemaker`はデフォルトで様々なOSSを制御するコントローラ(`Resource Agent`とか呼ばれているやつ。IPアドレスの着け外しをする`IPaddr2`もその1つ)を持っている。きっと`Docker`サポートもしてるんだろう、という予測を立ててそのあたり調べていく。

そして見つけたのがこちら。あ、`Pacemaker`が`Docker`をサポートするんじゃなくて、`Docker`が`Pacemaker`をサポートするんだ？ｗ
[9.5. Docker コンテナーの Pacemaker サポート (テクノロジープレビュー)](https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-containers-haar)

読み始めると記憶にない`PacemakerのBundle`という単語。なんだっけこれ。

- [Pacemaker1.1.17新機能(bundle)](https://qiita.com/HideoYamauchi/items/7527eba39f4331fdc9df)
- [Pacemakerのbundle機能](https://www.designet.co.jp/mailmagazine/201904/)
- [4.1. リソースバンドルとコンテナー](https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.0/html/high_availability_deployment_and_usage/assembly_pacemaker#concept_pacemaker-bundles)

いままさに知りたい情報だった。Pacemakerがコンテナを制御するためのツールキットで、内部的には`IPaddr2`など既存のリソースの寄せ鍋のようだ。

1点、コンテナの中に`pacemaker_remote`なるものを入れないといけないらしい。これは`Bundle`を試すうちに通る道のようなのでいまはスルー。

## PostgreSQL ServerのDBは何処に置く？

コンテナの中に入れてたんじゃ停止/起動で情報が消失してしまう認識。たぶんホストの指定したディレクトリをコンテナがマウントしてDBのデータ部分を置くんだろうな。と予想しながら調べていく。

- [【PostgreSQL】docker-composeで起動と初期データ投入](https://qiita.com/ke_suke0215/items/90deba2bf484293000fc)
- [【すぐに使える！】DockerでPostgreSQLを環境構築する手順](https://www.kzo-tech-blog.com/docker-environment-postgresql/)

もやぁ～んと見えてきたイメージは以下のとおり

- `docker`の種ディレクトリをホストOS上に作成
- `docker-compose.yml`というコンテナのレシピ帳をディレクトリに配置
- ディレクトリ内にコンテナがマウントしてデータを置くディレクトリを作る
- `Dockerfile`というものがある。使わなくてもいい

やっぱりホストの一部をマウントするんだね。じゃあホストOSインストール時にパーティション構成は真面目に考えておいたほうが良さそうだな。あんまり設定ファイル類とDB領域を同じパーティションに置きたくないんだけどなぁ。

## docker-compose.ymlとは、Dockerfileとは

- [Dockerfile と docker-compose を利用すると何がうれしいのか？](https://qiita.com/sugurutakahashi12345/items/0b1ceb92c9240aacca02)
- [Dockerファイルとdocker-compose.ymlの違い](https://zenn.dev/mom/articles/519466e9c7a22d)

1つ目の参考URLがとてつもなくわかりやすいのでオススメ。今回、`Node.js App`や`Flask App`をコンテナ化する必要があるが、一度やりゃいいわけではなく継続して何度もコンテナ再構築が必要。なのでコンテナレシピ帳である`Dockerfile`は絶対的に必要。

`docker-compose.yml`は作成したコンテナのイメージをどう活用するか(環境設定など)なのでこれまた必要。どちらかではなく両方とも必要。

## (再度)PacemakerによるDockerの制御サポート状況を知ろう

コンテナを`Pacemaker`で使う上では`Bundle`というものを使うことはわかった。それはいつどうやって使う？コンテナに組み込む？

何やら`Pacemaker bundle`で扱う`Docker`イメージには`pacemaker-remote`というもののを詰め込む必要があるらしい。ので、これについて調べる。

- [他ノードリソース制御機能「pacemaker_remote」とは？](https://bcblog.sios.jp/brbd-what-is-pacemaker-remote/)
- [9.4. pacemaker_remote サービス](https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/pacemaker_remote)
- [30.3. Pacemaker リモートノードの設定](https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/proc_configuring-remote-nodes-remote-node-management)
- [第30章 corosync 以外のノードのクラスターへの統合: pacemaker_remote サービス](https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_remote-node-management-configuring-and-managing-high-availability-clusters)
- [How to install pacemaker-remote on Ubuntu](https://howtoinstall.co/en/pacemaker-remote)

私が現場で`Pacemaker`を扱っていた際は冒頭の自己紹介に書いたとおり、`Pacemaker`をホストOS, ゲストOS両方に入れて、ホストOSがゲストOSのリソースを制御できるようリソースアダプタを自作していた(先輩が)。これがもう公式サポートされているようだ。ありがたい。

ホストOSとコンテナ(`pacemaker_remote`が導入されている)の通信は`/etc/pacemaker/authkey`に格納した情報をもとにTLS通信されるらしい。これらがセットアップされなければ通信はできないということ。

## Ubuntuを知る

- [Server Worldさん](https://www.server-world.info/query?os=Ubuntu_22.04&p=download)

インフラ系で検索しているとよくヒットする。綺麗に中級～上級向けに書いていただいているので私にはピッタリ。らぶ。

# 作業計画を立てる

必要なアクションは見えてきた。これらを整理すると以下の検証が必要そうだ。

- Dockerイメージの作成
    - Dockerイメージ作成環境の構築
    - Dockerイメージ作成
        - PostgreSQL Server
        - Node.js App
        - Flask App
        - pacemaker_remote インストール
    - Dockerイメージ起動検証
- Pacemakerホストの作成
    - Ubuntuインストール
    - Pacemakerインストール
    - Dummyリソースで操作検証
- Bundleの作成
- 動作検証

後半の解像度が低いがだいたいこんなの。目安として2日ぐらいでなんとか片付けたい。