MSYS2 とは、Windows 上で POSIX シェル環境を実現するものだ。
32bit Windows 用と 64bit Windows 用の２つがあり、64bit の Windows には両方ともインストールし、実行することができるが、そうする意味はあまりなく、
64bit の MSYS2 だけインストールすればいい。32bit Windows 自体がもう時代遅れなので、MSYS2 でも 32bit バージョンはもう提供されていないようだ。MSYS2 の 64bit は
通常、C:\msys64 にインストールされる。
Kubernetes クラスタ上にデプロイしたアプリケーションを利用する場合、最終的には、Pod 内のコンテナが Listen するポートに対してリクエストすることになる。つまり、IP アドレスで Pod を指定し、ポート番号で Pod 内のコンテナを指定するわけだが、これらを直接指定するのでは管理しにくいし、スケールもしにくくなる。
そこで、Kubernetes では Service リソースオブジェクトによって、この問題、すなわちサービスディスカバリの問題を解決する。
ここでは、O'Reilly 『入門 Kubernetes』 の7章の内容を試してみる。
Kubernetes クラスタ上で稼働中のコンテナアプリケーションのヘルスチェックにはいくつかの方法がある。
コンテナのメインプロセスの死活監視 では、K8S クラスタのシステムが各 Pod 中の各コンテナのメインプロセスの死活監視を実施し、プロセスが終了してコンテナが終了し、破棄されたら、コンテナを再作成して起動する。これは、Pod の restartPolicy の設定にもよるが、いずれにしろ Pod はそのままであり、再作成はされない。これは、設定なしで勝手に K8S がやってくれるのだが、プロセスがデッドロックを起こしたりして、終了してはいないけれども、仕事をすることができない事態には対処できない。
Pod 内のコンテナから、ボリュームをマウントするには次の４つの方法がある。
ctypes モジュールを利用して C 言語のライブラリをロードし、そこで定義されている C の関数を
呼び出すことができる。
クライアントからの時間のかかるタスク処理要求を受け付けるサーバを、select モジュールによる入出力の多重化を利用して実装してみた。子プロセスの終了監視のために
signal モジュールも利用している。
最初の実装にはバグがあったので、それは failed_task_server.py というファイル名で残した。select モジュールの poll で書き込みを監視している子プロセスが終了した場合、パイプに書き込んで正常終了したときでも、たまに poll が書き込みを検出して戻る前にシグナルハンドラで割り込まれてしまうことがあるのが問題だった。修正したものをあらためて task_server.py とした。
シグナルハンドラは、コード中のどこでも呼び出される可能性があるので、例外を raise する場合には注意しなければならないことの確認のためにテスト用のスクリプト sig_handler_test.py を作った。