おじさんスペック

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

何をやるのか

現状の構成

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

こうしたい

※まだ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との違いとは

読んだ感想は以下

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 サポート (テクノロジープレビュー)

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

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

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

PostgreSQL ServerのDBは何処に置く？

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

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

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

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

docker-compose.ymlとは、Dockerfileとは

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

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

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

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

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

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

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

Ubuntuを知る

Server Worldさん

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

作業計画を立てる

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

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

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

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