docker

コンテナ(Docker)の何が嬉しいのかがすぐに分かる雑なお絵かき

動機

以前こんな記事

を書いたんですが、もっと簡単に何でコンテナを採用すべきなのかを書きます。

状況

テーブルの上に牛乳とか、フォークとか、ご飯とか色々のっていたとしましょう。

ここでそれぞれが何のメタファーなのかというと下表のようになります。

上の絵にあるやつ 何?
テーブル サーバー
牛乳 Nginx
フォーク Node.js 8.x
ごはん 自分の書いたプログラム
おかず 設定ファイル
コップ 特定のなんかyumパッケージ

お母さんがやってきた

「あんた、ちょっとテーブル変えるから上の物を新しいテーブルに移して!」

2018_01_31 14_00 Office Lens.jpg

牛乳、フォーク、ごはん、おかず、コップ、それぞれを移すことになりますよね。
システムに例えると、新しいサーバー上でミドルウェアをセットアップするということになります。

コンテナ is お盆

8月のナスに割り箸刺す時期じゃないです。トレーの方です。
最初からテーブルに直接物を置かずに、トレーの上に置いてあったらどうでしょう?

2018_01_31 14_03 Office Lens.jpg

お盆ごと持ち上げて、新しいテーブルに配置! オレ、有能!

※画像はあくまでイメージです。実際の動作とは異なることがあります。

少し捕捉

昼休みに雑に書いた絵で済ませようと思っていましたが「わかんねーよ」と怒られそうなのですこし真面目に。

ディスポーザブル

この絵は「可搬性」について書いています。実際にコンテナ化をするとコンテナを新しいサーバーに移すというのは若干ウソです。(export/importでできますけど)

本当は、

  1. 古いサーバーは無慈悲に捨てる
  2. 新しいサーバーで「イメージファイル」を「リポジトリ」から取ってきて(pull)くる
  3. そのイメージファイルを元に「コンテナ」を実行(run)

ということになります。細かいことは、なぜコンテナが期待されるかを読んで下さいね。

ステートレス

ここで、コンテナ自身は「ステートレス(状態を持たない)」設計にすることがポイントです。コンテナ自体は状態を持つことも出来ますが、無慈悲に捨てられないと「まぁ、新しいコンテナをイメージから作ればいいや」という気持ちになれないのです。
具体的には、

  • ログはsplunkやcloudwatch logsなどの外部ログストレージに出す
  • データはデータベースなどに持つ

ということです。

と、いうことでサーバーに直接物を置かずに、お盆の上に置きましょうというお話でした。