索引

  • Dockerとは
  • Dockerの環境
  • 開発環境と実行環境のパッケージ化
  • 異なるOS環境の実現
  • レジストリの提供
  • ITインフラへの移行
  • 個別システムの弊害
  • イミュータブル・インフラストラクチャとは
  • イミュータブル・インフラストラクチャの構成
  • イミュータブル・インフラストラクチャとコンテナの必要性
  • イミュータブル・インフラストラクチャにおけるコンテナの利用
  • コンテナによる多様な環境への迅速な対応
  • 新たなDocker イメージの作成
  • 異なる OS 環境の管理
  • Docker の課題

Docker とは

Docker とは、ソフトウェア開発や IT 部門の管理者をターゲットとした、アプリケーションや OS の開発・配備を行う為の「コンテナ」を利用した基盤ソフトウェアです。コンテナとは、ホスト OS 上で独立したプロセスとして実行されるアプリケーション環境であり、OS の基本コマンドや、アプリケーションの実行バイナリ、ライブラリなどの実行環境全体をパッケージ化し、それらを OS の分離された空間で実行する技術です。

Docker は、コンテナ技術の採用により、ハイパーバイザー型の仮想化ソフトウェアに比べ、極めて集約度の高い IT システムを実現できます。しかし、Docker が注目される理由は、仮想環境における性能面の優位性では無く、昨今の急速なビジネス変化に対応する道具として、IT 技術者にその有用性が認められた為だと言えます。

ソフトウェア開発者の観点で見た場合、インターネットで提供されるサービスの迅速な開発や柔軟な対応を行うためには、ソフトウェア開発の本質的な部分に注力する必要があります。ソフトウェア開発が、ハードウェア環境の確保や開発環境のインストールといった煩わしい作業から解放され、アプリケーション開発に集中できれば、作業工数が削減され、開発した成果物の単価を引き下げ、さらにはソフトウェアの価格競争力を高めることも可能です。

このようなアプリケーション開発者の要望を実現するには、アプリケーション単位での分離、開発環境の作成と廃棄を容易に行える仕組みが必要です。そのためには、アプリケーションメンテナンスの簡素化をより一層押し進める必要があります。もちろん、従来の KVM などによるハイパーバイザー型の仮想環境やパブリッククラウドのサービスでも、ソフトウェア開発者への効率向上の手段を提供していますが、Docker 独自のパッケージングやリポジトリの機能により、さらに利便性の高い開発環境を作ります。

IT システムが支える企業のビジネスが、グローバル化とともに多様化し、その対応を迫られる IT 管理者にとって、仮想化ソフトウェアの普及やクラウドサービスにおける IaaS や PaaS をはじめとする多様なサービスの登場は、メリットの非常に多いものでした。それが Docker の登場により、さらに推し進められようとしています。IT インフラの現場では、Docker の運用により、アプリケーションの開発を実環境への素早い展開と運用の両立が可能となり、「DevOps 環境」や「イミュータブル・インフラストラクチャ」の実現に大きく貢献することになるでしょう。ソフトウェア開発者や IT 部門の管理者にとって、ハードウェア資源を意識せずに、運用、廃棄などを迅速に行える環境が、Docker によって手に入れることができるのです。

Docker の環境

Docker は、OS 環境を簡単に構築・集約して利用することが可能であり、複数の OS 環境とアプリケーション環境をパッケージ化します。さらにインターネットを通じて世界中の開発者や IT 部門のメンバーが作った OS / アプリケーション環境を、即座に利用することが可能です。Docker のもたらす環境がどのようなものなのか、見ていきます。

開発環境と実行環境のパッケージ化

ネットワークを通じて、IT 部門が用意した環境をすぐに利用できる環境といえば、クラウドコンピューティングにおける IaaS や PaaS を想起するかもしれません。しかし、パブリッククラウドが迅速にサービスを利用者に提供したとしても、それら基盤上で動くアプリケーションの開発環境や実行環境の使い勝手が良く、カスタマイズの自由度が高くないと、IT システム全体としてあまり意味がありません。Docker が注目される理由の一つには、この「アプリケーションが開発環境を実行環境をパッケージ化」し、迅速な配備や廃棄が可能である点が挙げられます。

例えば、開発者が複数の LinuxOS 上で稼働する、複数バージョンの開発環境をゼロから用意するとなれば、開発環境の入手、構築、利用、廃棄といった作業は無視できない工数になります。それが Docker では、先に述べた「アプリケーション環境と実行環境をパッケージ化」した「Docker イメージ」を利用することで、多様な開発環境を構築できます。

Docker イメージとは、Docker コンテナの生成に必要なファイルシステムであり、イメージないには、実行ファイル、ライブラリ、Docker コンテナの実行の際に起動させたいコマンドなどが含まれています。Docker イメージを基にして、コンテナが起動すると、内蔵されているアプリケーションの初期設定が自動的に行われ、基本機能をすぐに利用できる状態になるものも少なくありません。このように、Docker イメージさえ入手すれば、すぐにアプリケーションを利用できる仕組みが、開発者の工数を大幅に削減します。

異種 OS 環境の実現

IaaS のようなクラウド基盤を構築できなくても、異種 OS 環境を手軽に作ることができる点は、Docker 納期な魅力の一つと言えるでしょう。アプリケーションの開発と実行環境を、クラウドソフトウェア二依存せずに簡単に配備できれば、初期投資が限られた IT システムに携わる開発者と管理者の双方にとって大きなメリットがあります。ここでいう「異種 OS 」というのは、Linux 環境であれば、異なる種類の Linux ディストリビューションを意味します。例えば、CentOS 用の Docker イメージ、Ubuntu 用の Docker イメージ、SUSE ベースの Docker イメージ、さらには、Debian ベースの web アプリケーション入りの Docker イメージなど、様々な種類の Docker イメージが存在します。

レジストリの提供

Docker は、高性能なアプリケーションの開発・時刻環境の提供だけでなく、それらの OS やアプリケーションを世界中で共有し、IT システムが目的を達成するために必要な工程を自動化する Web サービスを提供する点が革新的であるといえます。この Web サービスは、Docker Hub を呼ばれるクラウド上の Docker イメージのレジストリサービスです。アプリケーションやサービスコンテナの構築と配信を行う、いわゆる、Docker イメージのパブリッククラウドサービスです。

レジストリサーバーでは、リポジトリが保管されており、ユーザーは、Docker Hub に保管されている Docker イメージの検索、変更管理、取得が可能です。また、手元にある Docker イメージを Docker Hub にアップロードすることもできます。

世界中の開発者や IT 部門のシステム管理者が共通して理解できる同い IT システムを使えば、他社が作成したシステムをそのまま、あるいは多少手を加えて利用することで、開発、システムテスト、実システムへの配備の工数を大幅に削減できるようになります。具体的な例を挙げれば、Web アプリケーションの開発において、その動作に必要となるライブラリや、起動、停止、監視用のスクリプトを新たに調査したり、別途開発したりといった追加の作業を大幅に抑えることができます。

IT インフラへの移行

次に、実際の IT インフラの運用面から、Docker の有用性を考えてみます。冒頭でも「急速なビジネス変化に IT システムを対応させる」ための道具として、Docker の有用性について述べましたが、その背景には、「寿命が来るまで目的を固定化して IT システムを設計・利用する」といった旧来の個別システムの考え方では、対応できない課題が IT 現場で多発しているという状況があります。そのため、革新的なビジネスを生み出すために必要な、「柔軟でかつ安定的に作成・変更・廃棄できる」新しい IT システムを取り入れる、という考え方に注目が集まっています。システムの開発者と運用管理者の双方が連携して IT システム全体の開発を行う、いわゆる DevOps (Development : 開発、Operation : 運用) の考え方です。また、それに伴いシステムの開発においても、何もかも要件に応じて、ある程度短い期間で部分的に開発・テストを行なったものをリリースし、追加の開発や外部にある既存の OS とアプリケーションがパッケージ化されたものを必要に応じて調達するといった、いわゆる「アジャイル開発」の必要性も同時に高まっています。

個別システムの弊害

急速なビジネス変化への対応は、新たな IT システムに求められる大きな役割ではありますが、もう一つの役割として、旧来のシステムの課題解決といった側面があります。日本の場合は、物理基盤や仮想化基盤のどちらにおいても、欧米に比べて、業務要件ごとの個別最適化を行う傾向があるため、どうしても IT システムを固定的に構築してしまい、柔軟性に欠ける傾向があります。逆にビジネス要件の変化に伴って、IT システムの柔軟性を維持・拡大するために、システムの更新、改良を行う必要性を認識できたとしても、様々な技術的課題に直面します。特に問題視されているのが、OS の更新作業や現行システムへのバグ修正バッチなどの適用、ミドルウェアやアプリケーション、スクリプトの更新などを行うと、現行のオープンソースソフトウェア群の連携が崩れてしまい、結果的に業務アプリケーションがうまく動作しなくなる恐れがあるという点です。

イミュータブル・インフラストラクチャとは

イミュータブル・インフラストラクチャとは、サービスプロバイダなどで導入されている IT 基盤のアーキテクチャのことです。本番用のシステムには一切手を加えず「不変の状態である」ということから、イミュータブルと言われています。

イミュータブル・インフラストラクチャのシステム構成

イミュータブル・インフラストラクチャは、本番システムと開発系システムの合計2系統のシステムを持ちます。開発用のシステム上でソフトウェアを開発したあと、負荷分散装置から急システムを切り離し、開発システムを負荷分散装置と接続し、新たな本番環境として運用します。イミュータブル・インフラストラクチャでは、開発系システムに対して、新しい用件が加わるなどの理由により、サービスやアプリケーションが新たに必要になった場合は、サーバーを新規に作成し、不要となった既存のシステムを廃棄します。この廃棄される、旧システムのことを、イミュータブル・インフラストラクチャではディスポーザブル・コンポーネントと呼びます。例えば、アプリケーションの動作テストを繰り返すたびに新しいサーバーを作成し、すべてのテストが終了したら、途中で作ったサーバーは廃棄するといった方法が採られます。

従来の固定的な個別最適化されたシステムの場合、導入当初は安定的に稼働していたものであっても、パッチの適用や機能追加を施すと、そのシステムは、大量のパッチが適用された状態になってしまいます。管理者が厳密に大量のパッチ適用や変更履歴を追跡できたとしても、システムが正常に稼働できるかどうかの判断もあやふやになり、誰もそのシステムの挙動を正確に把握できなくなる恐れがあります。そこで、パッチの適用状況の把握といったサーバー環境の現在の状態管理が非常に煩雑になるならば、「サーバーの状態を管理しない運用方法」を採ることで、開発者も管理者も煩雑なシステム管理から解放されるべきであるというのが、このイミュータブル・インフラストラクチャの考え方です。

イミュータブル・インフラストラクチャとコンテナの必要性

イミュータブル・インフラストラクチャの場合、アプリケーションの開発が進んだ時や、新しいバージョンの OS.やアプリケーションなどがリリースされるたびに、開発系のサーバー環境でそれらを準備する必要があります。仮に、この作業を物理サーバーにおいて構築しようとすれば、ハードウェア機器自体の調達とサーバーのファームウェアや OS のベアメタル配備が頻繁に発生し、それがデータセンターのスペースの圧迫と消費電力の増加につながるため、非効率な運用になります。また、従来のハイパーバイザー型の仮想基板を使っても、仮想マシンの作成、仮想マシン上でのゲスト OS のインストール作業、ゲスト OS の起動、停止、そしてゲスト OS 自体の管理が煩雑になるのは避けられません。加えて仮想基盤の場合、OS 上に導入された開発環境の入手、構築、利用、そして、破棄の各ステップにおいて、どうしても開発とは無関係なインフラの管理の手間が入り込み、負荷が増大してしまいます。

イミュータブル・インフラストラクチャにおけるコンテナ利用

開発系で頻繁に更新やテストが発生する為、開発環境のベースとなる OS の更新作業や、複数バージョンのミドルウェアや開発環境の配備の種類と量が膨大です。従来のインフラ環境であれば、複数の異種 LinuxOS やアプリケーションのインストール作業をその都度手動で行う為、インフラ管理者にとって非常に苦痛な作業です。これがコンテナを利用した場合には、どのようになるでしょうか。以下に、異なるバージョンの OS やアプリケーション配備を例に説明しています。

コンテナによる多様な環境への迅速な対応

最初に、アプリケーションの要件として現行バージョンの CentOS 7.6.1810 とそれに付随する開発ライブラリが必要な場合を想定します。新しいコンテナを作る作業は、CentOS 7.6.1810 で作られた Docker イメージをレジストリから入手するだけです。すぐにその OS 環境をコンテナとして起動し、作業を開始できます。最新の OS 環境として CentOS 8.x が必要になった場合でも、その Docker イメージを入手し、CentOS 7.6.1810 とCentOS 8.x の両方を同時にすぐに利用できます。この時、CentOS 7.6.1810 や、CentOS 8.x の DVD インストールメディアを使ってインストーラを起動させる必要も一切ありません。Docker イメージさえ入手できれば、すぐに OS 環境で作業ができる点が重要です。また、ミドルウェアやアプリケーションの構築作業でも、レジストリから入手した Docker イメージを利用できます。

新たな Docker イメージの作成

次に、様々な OS バージョン環境でミドルウェアやアプリケーションを組み合わせたコンテナ環境を構築する場合を例に見てみましょう。この場合は、最初に CentOS 8.x の Docker イメージを入手します。その入手済みの Docker イメージをコンテナとして起動し、PostgreSQL データベースをコンテナ上にインストールします。PostgreSQL がインストール済みの CentOS 8.x のコンテナは、PostgreSQL 入りの CentOS 8.x の Docker イメージとして保管できます。

この時、PostgreSQL が入っていない素の状態の CentOS 8.x の Docker イメージと、PostgreSQL 入りの CentOS 8.x の Docker イメージの二つが存在しますが、Docker 環境においては、変更箇所の差分が記録されることで、ディスクを二倍消費せずに済む仕組みや、Docker イメージをスリム化する機能が内蔵されており、従来のハイパーバイザー型の仮想化基盤に比べて、開発ハードウェア基盤の大幅な節約が期待できます。また、PostgreSQL 入りの、CentOS 8.x の Docker イメージは、社内、あるいは、社外の Docker コミュニティに共有しておくと、別の開発者は、その PostgreSQL 入りの CentOS 8.x の Docker イメージさえ入手すれば、PostgreSQL を使ったアプリケーション開発環境をすぐに利用できます。

異なる OS 環境の管理

上記と同様の手順で、パッチ適用済みの業務アプリを含んだ Docker イメージなどを作って、社内、あるいは、社外の Docker イメージの共有保管庫にアップロードしておけば、次からは、別の開発者が利用する場合でも、パッチ適用済み環境を簡単に起動し、すぐにテスト作業に入れます。さらに、Docker コンテナは、起動だけでなく破棄も素早く行えます。例えば、PostgreSQL データベースの稼働する CentOS 8.x のコンテナがあり、そこに β版の BI ツールを入れたとします。β版の BI ツールに何か不具合が発生した場合、その BI ツールをアンインストールするといった作業などを行わなくても、Docker エンジンが提供する削除コマンドを使って、コンテナを破棄するだけで良いのです。再び、BI ツールが入っていない Docker イメージをすぐに呼び出してコンテナを起動し、別のバージョンの BI ツールを入れられます。

ハイパーバイザー型の仮想化基板に比べると、元となる Docker イメージに影響を与えることなく、アプリ入りの OS 環境の破棄とアプリの再構築が容易に行える点は、次々と個別のバージョンの OS 環境と開発環境を用意しては破棄するといった開発者にとって非常に使い勝手のいいシステムです。このような OS 環境とアプリケーションの入手、構築、利用、破棄が素早く行える環境は、まさにイミュータブルインフラストラクチャの開発に有用です。

また、イミュータブルインフラでは、本番系と開発系を同一種類のハードウェアで構成しますが、徐々に開発系に新型のハードウェア機器を導入する場合も少なくありません。そのような場合でも、Docker 環境であれば、Docker イメージを旧式のハードウェアから新型のハードウェアへの移行も、非常に容易です。

Docker の課題

Docker は、先進的なソフトウェアであるがゆえに、いまだ進化の途上にあり、利用上の課題も内包しています。いずれは解決される課題かもしれませんが、少なくとも現時点では、Docker の課題として、以下に述べる点については把握しておく必要があります。

Docker は、先進的な企業において次々と導入されており、事例も次第に公開され始めていますが、多くのユーザーは大量の Docker コンテナの管理工数の軽減を課題に挙げています。Docker は、シンプルなコマンドラインを提供していますが、GUI 管理ツールや、Docker コンテナの自動配備、資源管理ツールなども提供されています。すなわち、Docker 単体だけでシステムが全て完結することはなく効率化のための周辺ソフトウェアの整備をある程度視野に入れなければなりません。海外などの Docker 事例では、開発部門や IT 部門の簡素化が Docker によって達成できたことが紹介されていますが、実際には、大量のコンテナを正常に稼働させるシステムにするためには、Linux コンテナや、チューニングを含めた LinuxOS 上のプロセスの挙動に関する知識、コンテナの自動配備、資源管理ソフトウェアなどが必要になります。

次回があれば…

次回

  • コンテナ毎に分離された空間
  • ハイパーバイザー型の仮想環境とコンテナの違い
  • 名前空間
  • ファイルシステム
  • cgroups

林 裕大Hayashi Yuto
麻雀 / コーディング / 東方 / V-Tuber / 書道 /
  • CentOS
  • AmazonWebServices
  • SQLite
  • Docker
  • Python
  • Ruby
  • PHP
  • Laravel
  • WordPress
  • Nodejs
  • JavaScript
  • Sass
  • HTML5
  • Bootstrap
  • adobe Illustrator
  • adobe Photoshop
お問い合わせ

大変申し訳ありませんが、現在お問い合わせフォームは機能しておりません。お手数ですが、お問い合わせの際は、下記アドレスまでよろしくお願いいたします。

h3yukomah1y1k1m@gmail.com