コンテナ型アプリケーション実行環境
最近話題の技術のコンテナ型アプリケーション実行環境。オープンソースの Docker が注目を浴びている。
従来は自分でサーバーを走らせるとすると、自分でコンピューターとネットワーク回線を用意していた。しかしそうすると、物理的なマシンにネットワーク回線、更にOSからサーバーソフトウェアまでを自分で管理しなければならない。
最近では Amazon EC2、Google Compute Engine、日本だとさくらのVPSのように、仮想マシンを貸してくれるサービス、いわゆる IaaS（Infrastructure as a Service）が出てきている。仮想マシンの利点は、物理的なマシンや回線の管理はプロバイダーに任せる事ができること。ユーザーはOSから上だけを管理すればいい。
しかし仮想マシンも万能ではない。例えばサーバーの数を増やしたいときには新たに仮想マシンを作成して起動、設定しないといけないので、例えば負荷が増えたからすぐに増やすというわけにはいかない。これを解決する、Google AppEngine や Heroku などの PaaS（Platform as a Service）と呼ばれる環境は存在する。PaaS を使えば OS の管理もプロバイダーに任せられるので、ユーザーは純粋に自分のロジックだけを考えていれば良い。しかし PaaS は往々にして環境が Web アプリケーションに制限されており、自分の好きなサーバーを走らせることはできない。
そこで出てくるのがコンテナ型アプリケーション実行環境。コンテナ型では OS の機能をほぼ全て利用できるため、任意のソフトを走らせることができる。ホスト OS をそのまま利用するため、仮想マシンに比べるとオーバーヘッドが少ない。各コンテナは同じホスト OS 上で動いていながら隔離された環境になっているため、コンテナは他のコンテナに影響を与えない。新たにサーバーを立ち上げる時はコンテナごと増やす。不要になった場合はコンテナごと廃棄する。
（写真はコンテナ型についての記事より）
というわけでコンテナ型は利点が多いテクノロジーではあるが、もちろん万能ではない。以前自分がコンテナ型の環境をデバッグした経験から問題点をいくつか挙げていきたい。
コンテナの見分け
上の写真のように、基本的にすべてのコンテナは外見が似ている。以前現場でデバッグした時は最初間違ったコンテナに入り込んでだいぶ時間を無駄にした。最初にちゃんと確認すればよかっただけの話ではあるが…居住性
コンテナ内部はソフトウェア（特にサーバー）を走らせる環境なので、人間に対する居住性は考慮されていない。春先であったにもかかわらず、内部はかなり暑かった。温度計はなかったので正確な温度は分からないが体感では40度以上。大量集積
効率を考慮してコンテナが大量に集積されている場合が多い。船が揺れた際に崩れるんじゃないかと心配になる。実際にコンテナが崩れたという事故はたまにしか聞かないが、自分が中に入っている時は本当にかんべんしてほしいと思う。また自分のコンテナは下から２段目だったのでまだよかったが、上のほうに積まれたコンテナだと山登りかボルダリングかやってる人じゃないと登っていけないと思う。コンテナ自体のメンテナンス
サーバーが壊れた場合はすぐに分かる（そして私のようにデバッグに行かされたりする）が、コンテナ自体はあまりメンテナンスされていない場合がある。私が入ったコンテナも入り口の立て付けが悪くなっていた。入るときは強引に入ったが、作業が終わって出ようとしてドアが開かなかったときはかなり焦った。
結論としては、コンテナ型だけではなくどんな技術にも当てはまると思うが、特に新しい技術は利点、欠点を見極めた上で適切な状況で利用することが肝要だと思う。