COLUMN

1．dockerコンテナとは

dockerの全貌を理解するのは大変ですが、ざっくりと説明すると　

以上のような説明がされることが多いです。これらは概ね正しく、うまくdockerの特徴とメリットを説明していると思います。

上記の特徴に加えdockerに関して＋αでおさえておけば良いこと

dockerコンテナ導入のメリット

dockerコンテナへの基本的な理解がほしいと言う場合、これくらいで良いのかなと言ったところです。

以下はdockerコンテナについて少し深掘りしていくため、実務で導入を検討している人へ向けた内容となります。

dockerコンテナについてお悩みの方は、NTT東日本までお気軽にご相談ください。

2．dockerコンテナの特徴を整理

次にdockerの特徴とメリット・デメリットを整理したいと思います。

dockerの役割は大きく2点あります

[1]サンドボックスの提供

[2] IaC (Infrastructure as Code) を採用しインフラをコード化

[1]の特徴、コンテナ型仮想化の本質はサンドボックスの提供にあることを前回のコラム(コンテナ仮想化とは。誤解の多いコンテナに対する正しい理解)でお話しました。サンドボックスのメリットについてはこちらの記事を読んで頂ければと思います。

[2] dockerはサンドボックス環境を提供するだけではなく、IaC (Infrastructure as Code = インフラのコード化)の考え方を取り入れたソフトウェアです。インフラのコード化について説明しますと、従来はサーバーエンジニアやネットワークエンジニア(インフラ系SE)がコマンド操作によりOSやミドルウェア、ライブラリなどの環境設定、コンフィグの修正を行っていました。設計や処理内容が文字(暗号：Code)として残るプログラマの仕事に対して、サーバーやネットワーク機器に向かって黙々とキーボードを叩いているインフラ系SEの仕事は、同じIT業界・同じ会社の中の人々が見ても彼らが何をしているのかよくわからない複雑怪奇で謎の多い職務の一つでした。そのため、属人性が高く、作業を行うエンジニアによって品質にバラつきが多く、また、具体的に何をやっているのか見えにくいと言う課題がありました。そこでIaC（インフラのコード化：infrastructure as code）が提唱され、サーバーの操作、OSの設定変更など環境構築諸々を文字として残し、バージョン管理し、それらを再利用していこうという考え方が生まれました。

dockerはこのIaCを採用することで、サーバーの構築工程を可視化(見える化)しました。また、コード化されることで、サーバーを増やしたい時にはそのコードを再実行(再利用)するだけで、クローンを作ることができ、昨今の世界的で急速なIT化に伴うサーバーの需要増に対応できるようになりました。dockerではDockerfileと言うファイルにコマンドライン上で行う操作を記述してサーバー構築の工程を文書化(コード化)します。これらのコードをレシピと呼ぶ場合もありますが、料理のレシピと同じでサーバーの作り方のレシピです。

上記の[1][2]やその他仕様により次のようなメリット・特徴があるとされています。

これらのうち、下の6点はdockerやコンテナ仮想化のメリット・特徴として挙げられることもありますが実態はちょっとあやしい項目と感じているもの、もしくはdockerに対する大きな誤解と思われるものを挙げました。

冪等性

冪等性（べきとうせい）とは何度繰り返しても同じ結果が保証されることですが、サーバーもインフラもできればレシピ通りに実行したら同じものができ上がってほしいですよね。dockerの冪等性は、コンテナの仕上がりをある程度は保証しますが、完全な冪等性はありません。dockerコンテナはDockerfileと言うレシピに従ってビルドされますが、出来上がるコンテナの中身はしばしば一致しない場合があります。

具体例としてはDockerfile内でよく記述される RUN yum update や RUN yum -y install パッケージ名に関する部分です。おまじないのように、Dockerfileにはこの yum update を入れておくことが多いです。と言うことは、アップデートによりコンテナの中身は最新化されているということになります。ビルドしたタイミングによって出来上がるコンテナの中身は異なると言うことです。同様に yum -y install パッケージ名 もその時点でレポジトリに用意されているパッケージがインストールされますが、パッケージは更新されていくので細かな違いがでてきてしまいます。

私個人の体験としては、ある時点までは正常に動作していたコンテナが、あるタイミングでリビルドした際、コンテナが動かなくなったことがあります。原因を探るとyum installコマンドでインストールしていたパッケージの一つが最新版に差し替えられ、その最新版のコマンドのオプションが廃止され、その影響でコンテナ内部のシェルスクリプトが正しい値を取得できなくなっていたことが原因でした。これらを防止するためにはいくつかノウハウがあるのですが、詳しく書き出すときりがないので割愛したいと思います。

インフラの設計構築やメンテが不要になる

クラウドの普及でサーバーSEの仕事がなくなると言われることがあります。昔から出ては消えるこれらのIT技術者の失業問題ですが、コンテナ仮想化やIaCによるサーバー構築の自動化によりサーバーエンジニアが失業する、クラウドの普及でネットワークエンジニアが失業する、AIの登場でプログラマが失業するなどが有名です。これらはいずれも文字だけ読めばそんな気にもなりますが、現場の実態を知っていれば、単なるイメージ、なんとなくそんな雰囲気で空想できてしまい、それらがメディアやネット掲示板を一人歩きしていることが肌感でわかるはずです。

dockerコンテナは仮想サーバー環境を自動でビルドし、数分でデプロイされて使えるようになってしまうため「サーバーSEが失業してしまう！大変だ！」となるわけです。ですが、実際には大量のサーバーを設計し、自動化のためのレシピを書き、それらをルータやロードバランサー(負荷分散装置)などと組み合わせて有機的に統合し機能させ、運用に乗せる必要があるためサーバーエンジニアは日々大忙しです。一方、クラウドの普及でネットワークエンジニアの仕事もなくなると噂されています。クラウドが盛り上がることで、クラウドと拠点サーバールーム、ユーザーがいるオフィスや従業員宅(在宅ワーク)を接続するためにネットワークエンジニアも日々大忙しです。かつて、アセンブラやコンパイラが登場した際にプログラミングが自動化される、プログラマが失業すると騒がれた時代がありましたが、今でも要件を定め、設計し、処理内容を記述していく工程はなくなっていません。アセンブラやコンパイラが大量の工程を自動化してくれましたが、それによって合理化され減少する工数以上にIT需要が伸びているので、結局、今でもSEやPGは相変わらず人手不足のままです。この神話は何度も何度も繰り返すのですね。

環境構築の工数を削減できる

dockerコンテナはレシピのテキストファイル(Dockerfile)を読み込ませることで、半自動でコンテナを100個1000個と構築し本番環境に投入することができます。だから、構築の工数を減らせると言う理屈です。これは事実です。Googleのように世界中で同一のサービスを提供する企業の場合、コンテナ構築自動化はなくてはならないものでしょう。ですが、これは同一の機能を提供するサーバーが100台～100000台以上と言ったオーダーで必要な場合のお話です。

数個の個別のコンテナを起動するために一つ一つレシピを作っていくような案件ですとコンテナは役に立たないどころか、プロジェクトを効率的に進めるための足枷となってしまいさえします。

コンテナが乗るコンテナ基盤の設計・構築やコンテナと各拠点やユーザーとを接続するネットワーク機器(ロードバランサーやルーター、スイッチ、Firewallなど)の設計・構築などもあり、コンテナ以外の部分のインフラ業務も相変わらず日々増大していっています。インフラエンジニア、サーバーエンジニアなしで日々のシステムの導入や維持管理をしていくことはできません。

アプリの実行環境がひとまとめにされている

これはdockerコンテナに関して巷でささやかれる最も多い誤解かと思います。おそらくは物流のコンテナの印象に引っ張られた誤解の一つではないかと思います。ですが、多くのdockerコンテナはサービスごとにコンテナが分離されているものが一般的です。以下にdocker社のコンテナの設計原則を記載したいと思います。

docker社は、コンテナを使ってサービスやコンポーネントを分割しましょうと提案しています。「ひとまとめにする」という考えはdockerの推奨しているコンテナ設計の方針に反するものですので、注意してコンテナを設計する必要があります。

これはコンテナ仮想化の設計原則ではなく、dockerコンテナ設計の原則となります。コンテナ仮想化のコラムでもお話しました通り、コンテナ仮想化の本質はサンドボックスの提供ですから、その真髄は各種パーツやリソースの「セグメンテーション化＝分離分割」にあります。なお、dockerに限定せずにアプリのサンドボックスにまで広げるとiPhoneのアプリのようにワンパッケージにしてサンドボックス内で展開することもありますので、必ずしも間違いとは言えないかもしれません。そのサンドボックスさえ、本来の目的は「統合」ではなく「分離」です。

業務システム用コンポーネントの構成例

上記が一般的なコンテナなしのサーバー環境です。利用者やジョブ(アプリやサービス等のプロセス)は1台のユーザーランド(OSのカーネル以外の領域)に同居。CPU、メモリなどのハードウェアやライブラリ、設定ファイルなど共有しており、互いの操作が互いに影響しあいます。

MySQLをアンインストールするとpostfixが一緒に削除されてしまった、特定のアプリケーションをバージョンアップしたら別のプログラムが動作しなくなったなどの障害が発生するのはこういったライブラリの依存関係が原因の一つです。次にdockerにより各コンポーネントを分離・分割してしまった場合のイメージ図を見てみましょう。

それぞれのコンテナ領域は隔離され独立しているため、アプリケーションが依存しているライブラリを更新しても影響はそのコンテナ内のみとなります。

物理マシンや一般仮想化によるバーチャルマシンは、さまざまなパッケージやサービスをひとまとめにして提供可能ですし、機能別にサーバーを分離することも可能ですが物理マシンで分割する場合、予算、工数、設置場所などさまざまな障壁があります。dockerコンテナは容易に、１つのアプリケーションやサービスを構成するコンポーネントを多数の区画に分割して管理することができます。この分離分割によって、あるソフトウェアの変更・修正の影響はそのソフトウェア実行環境(サンドボックスやコンテナ)内に限定すると言う理想的な環境を実現します。

ずいぶん長い文章となってしまいましたので、最後の項目である「引っ越しやデータ移動が簡単（可搬性）」「ゲストOSがない、OSを選べない」は、次回以降とさせて頂きたいと思います。

本記事に記載されてる会社名、サービス名、商品名は、各社の商標または登録商標です。