コンテナ仮想化の何が良いかわからない人集まれ!

　「最近、流行のコンテナ仮想化について仕組みは理解したけど、何がうれしいのかわからない」と思っている、そこのあなた!

　私もよくわからなかったけど、今日これは便利かもしれないと思ったので、その事を書いてみようと思いますよ。

bashの変更をなんで覚えてくれないの?

　「コンテナ仮想化を理解しようと思ってDockerとか使ってみた。確かに軽いけど、いちいちコマンド打たないとbashでサーバー設定変更した内容覚えてくれないし何が良いの?」と思ってました(笑)。でも、これがDockerの思想につながってるんですね。

　何かサーバーの構成を変更する時ってどうしてますか?　おそらく以下のようなことをされているのではないでしょうか。

　ここにはいくつか「めんどくさい」ことがあります。

　一つは「テスト環境を元の状態に戻して」というところです。環境が整っているところならば、設定変更前にVMのバックアップ取っておいて戻すということが出来るでしょう。

　VMのバックアップを容易に戻せないとかなると、変更した内容を手動で一つずつ戻すという効率の悪いことをしないといけないかもしれません。

　もう一つは、本番環境で冗長構成にしている場合、複数のサーバーに同じ設定をしないといけないということです。

　コンテナ仮想化を実現するDockerには、Dockerfileというものがあります。Dockerfileはサーバーの構築手順を示したテキストファイルです。

　Dockerfileには、ベースとなるOSイメージを指定したり、ディレクトリを作ったりという環境構築の手順を書いておきます。

　このDockerfileを作っておくことで、Dockerが一からサーバーを自動で構築してくれます。あとは環境を変更する場合に、手順書の代わりにDockerfileをメンテしていくことで、いつでも簡単に環境を構築しなおしできるようになるわけです。

　こうしておけば、テスト環境を元に戻す場合もVMのバックアップから戻したりせずに、Dockerfileを使ってサーバーを一から作り直させるということができます。

　もっと言うと、本番環境にリリースする際も既にあるサーバーに設定変更をする必要はありません。設定変更内容をDockerfileに追記してしまって、Dockerfileから本番サーバーを新たに構築してしまえばいいのです。

　サーバーが冗長構成で複数台あっても、一つずつ地道に設定をしていく必要もなくなります。「設定変更済み」のサーバーを新規に複数構築してしまえばいいのです。

　新しい本番サーバーの動作確認が終わったら、古い本番サーバーの環境は削除してしまってもかまいません。

　システムを運用していくと、いろんな要因でサーバーの設定変更が必要になってくることがあります。普通はその都度、設定変更の手順書のみを作る事が多いのではないかと思います。

　変更の度に作られる手順書をかき集めれば、一からサーバー構築することはできるはずですが、設定変更の度に実際に一からサーバーを構築できるかを確認するようなことまではやっていないのではないでしょうか。

　常にDockerfileを使ってサーバーを構築していく運用にすることで、確実に一からサーバー構築できる手順書が自ずとメンテされ続けられるというのもメリットです。

　Immutable Infrastructure(不変のインフラ)とか言葉だけは良く聞こえてきますが、こういうことなんですね。手順書を元に勝手に環境作ってくれるから、元ある環境に手を入るのではなく毎回新規に作ってしまえ、と。

　そう考えると、Dockerで起動したサーバーに対して直接シェルでログインして設定を変更していくということは、テストでいろいろ試行錯誤する時以外は、Dockerの思想としては「ない」ということになります。だから、わざわざコミットコマンドを打たないと、変更が反映されないんですね。

　サーバー環境を育てるというより、手順書を育てるというイメージ。おもしろいですね。