第8回 “紙の手順書”をなくす!? 「Dockerfile」とは何か：古賀政純の「攻めのITのためのDocker塾」（1/2 ページ）

“攻めのIT”を考える情シスリーダーが今後知っておくべき注目の技術「Docker」を基本から応用まで解説します。今回のテーマは「Dockerfileとその意味を知る」です。

[古賀政純（日本ヒューレット・パッカード），ITmedia]

　今回は、Dockerのキモともいうべき「Dockerfile」に迫ります。IT基盤の構築作業の効率化に大きく貢献するDockerfileが一体どのようなものなのかを解説していきます。

　その前に、Dockerがなかった時代を振り返り、システムの構築・運用の問題点と課題を明らかにしておきましょう。そして、それらの問題点や課題を踏まえた上で、Dockerfileの特徴、メリットを紹介します。

　さらに、近年話題の「インフラストラクチャ・アズ・コード」との関係性をひも解き、Dockerが攻めのITを実現する武器として利用できるかどうかを考えてみましょう。

古くからよく見かける3層構成

　みなさんは、インターネット百科事典の「ウィキペディア」のWebサイトがどのように作られているかをご存じですか。

　ウィキペディアを構成するシステムの裏側では、Webコンテンツを表示するソフトウェアだけでなく、閲覧者がストレスなく表示できるようにするために、Webコンテンツをキャッシュするソフトウェアやコンテンツを格納するデータベースなどが組み込まれています。その中でも、大きな柱となるソフトウェアは、アプリケーションサーバとデータベースサーバです。

　アプリケーションサーバとは、その名の通り、サーバ上でアプリケーションが動きます。アプリケーションサーバは、ユーザーに画面などを提供するWebサーバと、データを格納するデータベースサーバの間に位置します。ウィキペディアは、Mediawiki（メディアウィキ）と呼ぶオープンソースソフトウェアで実現でき、誰もが入手してウィキペディアと全く同じWebサイトを作ることができます。ちなみに、筆者も最新のHP ProLiant Gen9サーバに最新のCentOS 7.1とDockerをインストールし、Mediawikiを使って社内ウィキサイトを構築・利用しています。

日本ヒューレット・パッカードの大島本社にあるDocker環境で構築されたウィキサイト

　一般的に、ウィキペディアのようなウィキサイトを構築する場合、以下のような3種類のサーバーで構成されるのが一般的です。

• Webサーバ
  • クライアントのWebブラウザへ表示させるのに必要なWebサービスを提供
  • オープンソースソフトウェアのApache（アパッチ）やNginx（エンジンエックス）が代表的
• アプリケーションサーバ
  • データの加工処理などを行い、データベースに格納　またはウェブサーバーに提供
  • ビジネスロジックが稼働する
  • ウィキサイトの場合は、オープンソースソフトウェアのMediawikiやPukiwikiが代表的
• データベースサーバー
  • ユーザのコンテンツを格納
  • オープンソースソフトウェアのMySQL（マイ・エスキューエル）やPostgreSQL（ポストグレスキューエル）が代表的

古くからよく見かける典型的な3層構成。これ自体に問題があるわけではない

　このようなデータベース、アプリケーションサーバ、Webサーバからなるシステムは、一般的に「3層構成」と呼ばれます。物理サーバだけで構成することもあれば、従来のハイパーバイザー型の仮想化環境に構築する場合もあります。また、3層構成全てをDockerコンテナで構築する場合もあります。

A社にとっての常識は、B社にとっての非常識

　現実のITシステムの導入では、この3層構成の導入を1社で全て行う場合もあれば、データベース、アプリケーションサーバ、Webサーバ、チューニングを別々の会社で行う場合や、一部をユーザーのIT部門で行う場合もあります。

　「MySQLもMediawikiもApache Webサーバも、有名なオープンソースソフトウェアだし、トラブルなんて起きないでしょう？」

　と思われるかもしれません。確かに、1社ですべてを担当する場合や小規模なサイトを構築する場合ならば、あまりトラブルに遭遇しないかもしれません。

　問題は、ソフトウェアそのものの機能不足や不具合でもなく、大規模システムにおいて、複数のベンダーの技術者でシステムを構築する際の人間側の体制や熟練技術者の暗黙知に落とし穴があることなのです。

　例として、A社が先にハードウェアの導入・設定、MySQLの構築・チューニング、データベースの性能試験を行い、その後でB社がアプリケーションサーバのMediawikiや各種カスタムアプリケーションの開発、Webサーバの構築を行うとします。ウィキサイトを構築するB社の技術者は、すでにA社が構築・設定済みのデータベースの構築手順書や運用手順書を見ながら、ソフトウェアの連携動作に不整合が発生しないように作業を行います。しかし、ここで、B社の技術者にとって面倒な事態に陥ることがあります。例えば、以下のような状況です。

紙の手順書がもたらす問題点

• MySQLを構築したA社の技術者が書いた紙の構築手順書や運用手順書の内容が不明瞭のため、A社に問い合わせが頻繁に起こり、構築日数に遅れが生じる
• 手順書に記載されているソフトウェアの設定と、実際のシステムに設定されているものが異なる箇所が散見されるため、期待する動作が再現できない
• 構築手順を少しでも更新すると、また一から環境を構築しなおして、挙動をテストする必要があり、非常に手間がかかる

　このような状況になると、B社の作業工数はどんどん膨らんでいきます。そして、仕方なく両社の技術者が顔を合わせて同席して状況を確認してみると、手順書に書かれていないA社の暗黙知が次々と浮かびあがり、手順書や顧客へ提出する運用の手引きなどを書き換えなければならないといった事態に陥ります。A社の中では技術者の誰もが分かる暗黙知が、B社で全く通用しないなどもサーバシステム構築の工数削減の足かせになってしまうのです。

　このように、紙の手順書は、内容の正確さ、人間の文章力、経験則や暗黙知による記述の省略など、人間の能力に依存する問題が常に付きまといます。複数の会社・組織体による協同作業が行われる際の人間の介在が、スムーズなプロジェクト進行を阻む大きな障害になる場合もあるのです。

　では、このような事態に陥ることをできるだけ避けるには、どうすればよいのでしょう。例えば、以下のような問題解決への取り組みが課題として思い浮かぶかもしれません。

紙の手順書の課題（問題解決への取り組み）の例

• プロジェクト開始時からA社とB社で手順書を共有し、変更履歴を管理する
• 手順書のフォーマットをA社とB社で標準化する

　手順書のレビューなどをA社とB社で行い、情報共有し、変更履歴を管理しても、結局はA社、B社の手順書のチェックを人間が目視で行わなければならず、手間もかかります。また、フォーマットを標準化しても、結局、構築作業は人間が行うため、その人のくせやミスが入り込む可能性があります。

　このような課題に対し、古くから存在する（枯れた）「コンテナ技術」を組み合わせることにより、画期的な方法を思いついた人々がいます。米国Docker社の開発者達です。彼らが思いついた方法は、どのようなものだと思いますか？　まさに「コロンブスの卵」のような発想なのです。彼らの行き着いた答えは、「紙の手順書をなくす」です。