動機
以前こんな記事
を書いたんですが、もっと簡単に何でコンテナを採用すべきなのかを書きます。
状況
テーブルの上に牛乳とか、フォークとか、ご飯とか色々のっていたとしましょう。
ここでそれぞれが何のメタファーなのかというと下表のようになります。
| 上の絵にあるやつ | 何？ |
|---|---|
| テーブル | サーバー |
| 牛乳 | Nginx |
| フォーク | Node.js 8.x |
| ごはん | 自分の書いたプログラム |
| おかず | 設定ファイル |
| コップ | 特定のなんかyumパッケージ |
お母さんがやってきた
「あんた、ちょっとテーブル変えるから上の物を新しいテーブルに移して！」
牛乳、フォーク、ごはん、おかず、コップ、それぞれを移すことになりますよね。
システムに例えると、新しいサーバー上でミドルウェアをセットアップするということになります。
コンテナ is お盆
8月のナスに割り箸刺す時期じゃないです。トレーの方です。
最初からテーブルに直接物を置かずに、トレーの上に置いてあったらどうでしょう？
お盆ごと持ち上げて、新しいテーブルに配置！ オレ、有能！
※画像はあくまでイメージです。実際の動作とは異なることがあります。
少し捕捉
昼休みに雑に書いた絵で済ませようと思っていましたが「わかんねーよ」と怒られそうなのですこし真面目に。
ディスポーザブル
この絵は「可搬性」について書いています。実際にコンテナ化をするとコンテナを新しいサーバーに移すというのは若干ウソです。（export/importでできますけど）
本当は、
- 古いサーバーは無慈悲に捨てる
- 新しいサーバーで「イメージファイル」を「リポジトリ」から取ってきて（pull）くる
- そのイメージファイルを元に「コンテナ」を実行（run）
ということになります。細かいことは、なぜコンテナが期待されるかを読んで下さいね。
ステートレス
ここで、コンテナ自身は「ステートレス（状態を持たない）」設計にすることがポイントです。コンテナ自体は状態を持つことも出来ますが、無慈悲に捨てられないと「まぁ、新しいコンテナをイメージから作ればいいや」という気持ちになれないのです。
具体的には、
- ログはsplunkやcloudwatch logsなどの外部ログストレージに出す
- データはデータベースなどに持つ
ということです。
と、いうことでサーバーに直接物を置かずに、お盆の上に置きましょうというお話でした。