Dockerをシステム運用目線で再勉強

システム運用要素

• ライブラリー管理
• 監視
  • 死活監視
  • 性能監視
  • セキュリティ監視
• キャパシティ管理
• ログ管理
• セキュリティログ
• 業務アプリケーションログ
• バックアップ管理
• ジョブ運用

運用要素だが今回は含めない内容

• バッチ運用
• インシデント管理
• パッチやバージョン管理
• セキュリティ統制

Dcokerの抑えるべき基本

先にここで抑えるべき２点を書いておきます。

• コンテナは停止するとデータ全部消えるよ
• n+でコンテナ増減させたり、大量のシステムを同時運用する場合、コンテナの見分け方の整理が必要ですよ

DockerImageの作成

DockerImageと呼ばれる物を作成します。基本的にすべてDockerFileと呼ばれるコードで記載されます。
通常のOSのセットアップのように、インストール後に色々と変更はしません。
すべてコードで記載します。

正確にはコンテナ起動時にも、修正を入れる事ができますし、多くの場合変更を入れますが、まずは簡単に説明するため上記で記載

コンテナ作成と稼働

DockerImageと呼ばれる物をベースに、DockerContenaが起動してアプリケーションが稼働する。
稼働中のコンテナは基本的に通常のLinuxと変わらない。

実際には別OSのように動いて見えるように、ごにょごにょしているだけなので、コンテナ側のOSはカーネル関係やハード関係に制約がでますが、今回の話題には関係ないので省力します。簡単に説明するために、ベースOSが動いているぞ！！として話を進めます。

稼働中のコンテナにはtelnetやsshでログインして、コマンドラインでコマンドを打ったり、プログラムを実行したりできる。
Imageを作成する場合、必ずベースOSと呼ばれる物を選択するため、そのベースOS Linuxが稼働している。

コンテナ起動時にネットワークの設定や、ドライブのマウント等のカスタマイズが可能です。

コンテナの停止

稼働が終了した場合、コンテナを停止させます。
通常この場合、ログ等を含むコンテナ内のすべてのデータは消去されます。

正確にはコンテナ作成時に、ファイルシステムのマウントができます。Windowsでネットワークドライブを使うイメージです。そのようにマウントした場合はコンテナが停止しても、マウント元にデータが残っています。

システム運用目線での一つ一つの問題点と対応方法

ライブラリー管理

ライブラリーをコンテナにリリースしても、コンテナ停止時にファイルはすべて消えます。
次回はDckerImageの状態から0起動します。

以下の対応種類があります

1. リリース毎にImageを作り直し、プログラムを入れなおす。
2. コンテナ起動時に最新のプログラムがあるファイル領域をマウントしうて起動する
3. コンテナ起動後に最新のプログラムをコンテナにリリースする

複数案記載しましたが、運用観点あまり下２つにメリットもないため、１を採用します。
個人で開発段階でDocker使う場合は２が便利なため、個人では２を採用しています。

ただ、開発環境から本番環境へのリリースをImage単位にするのか、個別のプリグラム単位にするかは検討の余地があります。

1. 開発環境でImageまで作成して、Imageごと本番環境にリリースする
2. 開発環境から本番環境へプログラムだけ移動し、本番環境側でImageを作成する

どちらが良いんでしょうかね。。。。。

監視

起動時は普通のLinuxですので、オンプレと同様に監視可能です。
ただし、コンテナは複数起動できるのが売りですので、n+起動時の個別コンテナをどのように識別して監視するかは検討が必要です。
必ず起動数を固定するとすれば、コンテナの優位性下がりますが、今まで通りの監視も可能です。

n+で可変でコンテナを起動する場合、個別コンテナの識別は、監視マネージャーへ自己申告名で連携を行う事で識別します。
どのような自己申告名を使うかの命名規則設計が必要です。

死活監視

以下の対応種類があります

1. 各コンテナ内にエージェントを入れ、エージェントに各種情報を出させて監視
2. 多くのコンテナ管理ソフトがでているので、それらを通して監視

オンプレ環境と平行対応しないといけない環境だと、上記双方の組み合せ対応になるかと思われます。
１だけだとコンテナ固有の情報がとれず、２だけだと既存のオンプレ取得情報との間で不足がでる事があります。

性能監視

以下の対応種類があります

1. 各コンテナ内にエージェントを入れ、エージェントに各種情報を出させて監視
2. 多くのコンテナ管理ソフトがでているので、それらを通して監視

オンプレ環境と平行対応しないといけない環境だと、上記双方の組み合せ対応になるかと思われます。
１だけだとコンテナ固有の情報がとれず、２だけだと既存のインプレ取得情報との間で過不足がでる事があります。

また、死活監視と違いログの保管が必要です。コンテナは停止するとデータがすべて消えますので、
外部にデータ送信し保管しておく事が必須になります。

セキュリティ監視

通常のセキュリティはLinuxOSと同様になりますので、ここでは特に
OSのセキュリティログ(ログイン/ログアウトログ)について記載します。

ここまでと基本は同じです。起動時は普通のLinuxですので、オンプレと同様にログのチェックが可能です。
そして同様にコンテナは停止するとデータがすべて消えますので、外部にデータ送信し保管しておく事が必須になります。

ただし、注意として今までは怪しいセキュリティ違反があった場合、
基本のセキュリティログをベースに、OS内の各種ログを調べたりして
総合的に調査してきたと思いますが、コンテナの場合明示的にコンテナ外に
ログを保管しておかないと、すべて消えてしまいます。

バックアップ管理

Imageがバックアップファイルに相当します。

あとはImageファイル自体に加えて、Imageファイルの作成に使用した、
DockerFileのソースコードや、コンテナ起動時に使用するファイル(docker-compose.yml等)もバックアップします。

ジョブ運用

起動時は普通のLinuxですので、オンプレと同様にログインして、
ジョブの実行等の操作が可能です。

ただし、どのコンテナに入るか？を判断できるようにコンテナの起動状況と識別をサポートする仕組みが必要です。

これらはコンテナ管理ソフトがサポートする範囲ですが以外に難しそうです。
個別アプリの開発者は、俺のシステムアプリのｘｘｘジョブって言いますが、
オペレーション担当者の前には無数のコンテナが存在し、どれがアプリ担当者が言っているの物が判断が難しいです。
またアプリ担当者は、自分以外のコンテナがどんな形で動いているかなんで知りません。

あれ？これどうやって解決するんだ？？？
1～2個の開発部隊ならいいが、数十の開発部隊が作った、数百のシステム数で、
コンテナ数が数千のオーダーになった場合どうなるんだ？？
コンテナ起動時の命名規則とかがっちりしないと、識別が難しくなりそう。。。。
違反者の早期発見も必要だし。。。。。

設計について確認が必要なこと

• 個別コンテナの識別方法とその仕組みの理解
• 個別コンテナへのアクセス方法、特にIPならそのIP配布方法、コンテナ名(やホスト名)ならその命名規則