政純TweetIT部門は、現在よりも柔軟性の高い効率的なITシステムにするために、開発部門と協調し、自社のシステムにDockerを採用すべきかどうかの妥当な判断をしなければなりません。このDockerの採用可否に関する「妥当は判断」は、短時間で結論が出るものではありません。ある程度具体的に検討しなければなりません。実際にDockerを導入時する際に知っておくべき項目を述べ、最後に、導入手順と注意点について述べます。Docker導入前の検討事項Dockerを導入する上で、検討しなければならない項目としては、まず、「そもそもDockerが自社に必要なのか?」ということです。Dockerは、コンテナを管理するためのソフトウェアであり、非常に優れた機能を提供しますが、優れた機能だけでなく、既存の仮想化環境などに比べてのメリット、デメリットを把握しておく必要があります。多くのハイパーバイザー型の仮想化ソフトウェアでは、ライブマイグレーションの機能を提供しており、ゲストOSを稼働させたまま、別の物理マシンに移動させることが可能ですが、Dockerにおいては、ライブマイグレーションの機能が提供されていないため、ライブマイグレーションによる運用を行うことはできません。仮想化ソフトウェアを完全に置き換えることはできない点に注意すべきです。Dockerコンテナの高可用性を考える場合は、HAクラスタのサポート状況がまだ不明確になっており、Dockerコンテナで、プロセス監視のためのHAクラスタを構成したとしても、共有ディスクの論理ボリュームの切り替えをどのように行うかなどの課題も残っています。Server(LVS)の組み合わせ、さらに、MESOSなどのプロジェクトや利用経験者のコミュニティが、Dockerにおける高可用性実現に向けて、実証実験や研究を行っています。誰もが無償で入手できるオープンソースソフトウェアですが、実は、稼働するOS環境の違いによって、分類することができます。一つ目は、コミュニティ版のサーバーOSで稼働するDockerと商用Linuxで稼働するDockerでの分類です。コミュニティ版のサーバーOSで稼働するDockerのことを本連載では、「コミュニティ版のDocker」と呼ぶことにします。Serverなどがあげられます。コミュニティ版のサーバーOSは、ベンダーの保守サポートを受けることができませんので、その上で稼働するDockerもベンダーの保守サポートを受けることができません。Docker自体に問題があるのか、サーバーOS側に問題があるのか等の切り分け作業をユーザー自身で行う必要があります。Server(SLES)でもDockerを稼働させることができます。Serverにおいては、Dockerそのものに関するOEMベンダーの保守サポートが提供されているかどうかを確認する必要があります。Dockerの保守サポートを重視する場合には、この点に注意が必要です。RHELやSLESなどの商用Linuxで稼働するDockerについては、そのサブスクリプション契約の範囲内でのサポートが受けられます。ハードウェアとドライバーや監視エージェント類、ミドルウェア、そして、Dockerの問題の切り分け作業をベンダーに依頼できます。Dockerに関するある程度の技術面でのサポートが必要となる場合は、ベンダーサポートが得られる商用Linuxで稼働するDockerの導入を検討すべきです。Dockerのような現在も発展途上の先進的なソフトウェアを本番系システムに実戦投入する場合、動作の安定性や機能的な側面だけでなく、Docker自体の不具合や障害発生時の回避策、解決策の情報入手の容易さがシステムの安定稼働において重要な意味を持つ場合が少なくありません。有していることが必要です。システムに目立った障害が発生しなくても、ある一定の操作を施すと、Dockerコンテナのネットワーク性能が著しく劣化するような問題が発生した場合、それが高負荷時にのみ発生するのか、カーネルパラメータの設定に問題があるのか、Dockerの設計上の潜在的な問題なのか等の切り分け作業が必要であり、膨大な工数を伴う場合があります。それらの問題をどのような体制でどのように解決するのかといった組織能力を踏まえた上での導入が必要です。Agreement)をDockerでも実現できそうか?Docker導入決定後、サーバーOS選定における主なチェックポイントDockerを稼働させるOS環境は、コミュニティ版OSでよいのか?商用Linuxにすべきか?コミュニティ版OSにする場合、どのディストリビューションを採用するのか?商用Linuxの場合、どのディストリビューションを採用するのか?OEMベンダーからOSとDockerの保守サポートを同時に受けられるか?OEMベンダーからの保守サポートが受けられない場合、問題切り分け作業を自社で行えるか?コンテナ専用OSの現状を把握する2つ目は、通常のサーバーOSで稼働するDockerと、Docker向けに開発された専用OSでの分類です。ことを「コンテナ専用OS」と呼ぶことにします。コンテナ専用OSは、アプリケーションや稼働するデーモン、パッケージ管理マネージャなどが削られており、コンテナの稼働に必要最低限のコンポーネントで構成されています。コンテナ専用OSでは、コンテナに無関係なデーモンやアプリケーションなどが稼働することを極力排除しているため、一般的なサーバーOSに比べてより強固なセキュリティ、性能面での優位性、高い保守性を確保できるとされています。Core、そして、CoreOS(コアオーエス)があげられます。Atomicは、コンテナの配備や管理などを効率化したDocker専用OSの発展を目指すコミュニティベースのプロジェクトです。Host」があります。現在はまだ開発段階のレベルであり商用利用には向けいていませんが、無償で入手することができ、Docker専用OSを体験することができます。Host」があります。Atomicの成果物を商用化しつつも、管理ツールなどを搭載した製品です。Atomicと同様、必要最小限のコンポーネントで構成されています。CoreOSと呼ばれるコミュニティのプロジェクトは、Dockerやそれとよく似たrktと呼ばれるコンテナに最適化された軽量OSにGUI管理ツールを同梱しており、簡単にコンテナを管理・利用することができるように設計されています。コンテナ専用OS使い慣れたサーバーOSの上でDockerを稼働させるメリットとしては、Docker以外の非コンテナ環境のサーバーOS環境と同様のOS管理が行えるため、既存のOS管理用のツールなどを使用でき、新しく導入するDocker環境においてもサーバーOSの標準化を図ることができる点にあります。今まで使い慣れたOS管理手法をDockerが稼働するサーバーOSでも活用できるため、新しい管理手法を習得する工数を削減することができます。Dockerについては、GUI管理ツールやオーケストレーション等の周辺ソフトウェアをユーザー自身で構築、整備する必要があります。コンテナ専用OSは、今までのサーバーOSの管理手法とは異なるため、コンテナ専用OS自体の作法を一から学ぶ必要があります。Hostでは、CentOSやRHELで有名やパッケージ管理用のyumコマンドの利用ができないため、OS環境全体を新しく切り替えやロールバックなどの新しい仕組み(rpm-ostreeと呼ばれる仕組みが有名です)を理解する必要があります。サーバーOS用に開発されたサードパーティ製のアプリケーションが稼働しない場合もあるため、アプライアンスとしてコンテナ専用OSをどこまで割り切って利用するかを検討する必要があります。以下に、サーバーOS及びコンテナ専用OSの採用に関する主なチェックポイントを掲載しておきます。Cloudについては、ベアメタル環境に直接インストールすることができるisoイメージが提供されています。Hostは、KVMをベースとした仮想環境上で稼働が可能なqcow2形式のイメージファイルが提供されており、Docker専用OSをすぐに試すことが可能です。Linux、SLES、openSUSEなどに対応していますが、OS毎に注意すべき点が異なります。以下では、Docker導入の際のOS毎の注意点をいくつか簡単にあげておきます。7系の両方でサポートされています。6系においてEPELで導入したパッケージについては使用者の自己責任での利用になります参照すべきURL:https://access.redhat.com/articles/881893https://docs.docker.com/installation/rhel/https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.1_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.1_Release_Notes-Linux_Containers_with_Docker_Format.htmlFedora現時点で、ディストリビューションで配布されている標準カーネルのみをサポートします。13.1までは、仮想化に関する追加のリポジトリの設定が必要です参照すべきURL:https://docs.docker.com/installation/SUSE/Dockerのバージョンが更新される度に、サポートされるOSのバージョンも変更になりますが、注意点及び既知の問題については、OS毎にDockerのインストール手順と注意点が記されたWebページ(https://docs.docker.com/installation/)を参照するようにしてください。商用Linuxを使用している場合は、DockerのWebサイトだけでなく、ベンダーが提供しているDockerに関する公式のドキュメントを合わせて参照するようにしてください。Driver)と、ファイルシステム関連の制御を行うストレージドライバーの2種類があげられます。実行ドライバーは、cgroupなどの資源管理の仕組み、名前空間、SELinuxやAppArmorで提供されるセキュリティの仕組みなど、Linuxカーネルが提供する機能をDockerから利用する場合に実行ドライバーが必要となります。一般的に、ユーザーの利便性を意識した使い勝手に直接影響を与える管理ツール群は、フロントエンドと呼ばれ、一方、実際の動作を担うドライバーなどは、バックエンドと呼ばれます。Dockerにおけるバックエンドの実行ドライバーとしては、LXC、libcontainer、libvirt-lxcなどがあり、いずれもDockerから利用可能です。0.9からは、libcontainerがビルトインされており、libvirtやLXCなどのDocker以外のコンポーネントに依存することなくLinuxカーネルのコンテナAPIにアクセスすることができるようになりました。Dockerは、ファイルシステムレベルのストレージバックエンド(ストレージドライバーとも呼ばれます)として、btrfs、AUFS、vfs、overlayfsがサポートされています。通常のファイルシステム上で利用されるブロックデバイスレベルでのストレージバックエンドとしては、devicemapperがサポートされています。Dockerのファイルシステムの利用の指針は、OSの種類によって異なりますが、ファイルシステムの特性をある程度知っておくことが必要です。7.xでDockerを利用することを前提に説明します。System)Btrfsは、バータエフエスやB木ファイルシステムとも呼ばれ、大規模のストレージシステムでの利用を念頭において設計されたコピーオンライトのファイルシステムです。オラクル社の技術者が多く開発に携わっています。Btrfsは、過去の状態に戻すことができるロールバックの機能や、ある時点での状態を保持することができるスナップショット機能、ファイルシステムの圧縮機能、I/O性能向上を目的としたデフラグの機能、さらに、メタデータを複製する耐障害性の機能も有しています。最大ファイルサイズ、及び、ファイルシステムの最大サイズは、16エクサバイトになります。Btrfsを利用する場合は、ホストOS上の/var/lib/dockerディレクトリをBtrfsでフォーマットする必要があります。このBtrfsを使うことで、Dockerにおけるファイルシステムレベルでのスナップショットが可能となります。7.1では、標準でBtrfsを利用することが可能です。7.1において、テクノロジープレビューに位置づけられている点に注意すべきです。7.1におけるBtrfsは、ベンダーの保守が得られないファイルシステムとして位置づけられています。7.1におけるテクノロジープレビューの機能を利用するという覚悟が必要です。逆に、安定稼働をある程度無視できる開発系システムでは、Docker自体も、まだ商用レベルに向けて発展途上であるという位置づけから、Btrfsなどの先進のファイルシステムも積極的に利用されています。Btrfsについては、以下のURLが参考になります。Write:COW)は、ファイルへの書き込み発生時にオリジナルのデータを上書きしない仕組みを提供します。現在のデータの上書きはしない代わりに、ディスク上にある未使用のブロックを使うことで更新を行います。コピーオンライトではないファイルシステムとしては、vfsやext4などがあります。ext4などの一般的なファイルシステムでは、例えばユーザーが作成した新しいコンテナイメージなどのデータが作成されると、もし既存にその当該データが存在する場合は、上書きされ、新しいコピーが作成されます。FreeBSDなどのBSD系OSで利用が進んでいるZFSやDockerなどで利用されるBtrfsは、アプリケーションが、コンテナイメージなどのデータを要求すると、データはメモリ及びキャッシュ上に転送されます。複数のアプリケーションが同時にこの要求を行った場合、通常は、アプリケーション毎に紐づいたメモリ空間を保持しますが、コピーオンライトの場合は、複数のアプリケーションが一つのデータを要求すると、一つのメモリ空間ですみます。データの変更を行っているアプリケーションには、更新された情報を含むメモリ空間が付与され、データの更新を行っていないその他の複数のアプリケーションは、オリジナルのデータを使います。コピーオンライトの利点に、ディスクのスペース効率があげられます。オリジナルのデータがいくら巨大なものでも、スナップショットに消費されるディスク容量は非常にわずかであり、スナップショットの生成に関するディスクのI/O性能に関する劣化も無視できる程度です。オリジナルのデータからスナップショットを生成する場合にディスクへの書き込み要求が発生しますが、データが更新されていない状態では、読み込み要求は、オリジナルのデータを使って行われます。コピーオンライトは、書き込み失敗によるデータの破損のリスクを回避することができるため、複数のアプリケーションがデータを更新・参照する際の信頼性を確保することができます。System)AUFSは、PaaSプラットフォームであるdotCloudにおいて利用されていたファイルシステムです。AUFSにより、複数のコンテナに跨ってOSのイメージやライブラリ等のコンポーネントを共有(差分で管理)することができます。15.04において、Dockerをインストールすると、標準でAUFSが利用されます。Serverについては、デフォルトのカーネルで利用することが可能となっています。有名なものとしては、Knoppixと呼ばれるHDDを使わないLiveCDのディストリビューションでAUFSが採用されています。AUFSは、Linuxのアップストリームカーネルに標準で含まれておらず、RHELやSLES等の主要な商用Linuxディストリビューションにおいてサポートされていません。こんため、現時点で、AUFS含むカーネルを標準で利用できるUbuntuやDebianにおけるDockerでのみ利用することになります。AUFSについては、以下のURLが参考になります。http://blog.dotcloud.com/kernel-secrets-from-the-paas-garage-part-34-aoverlayfsoverlayfsは、Linuxカーネルバージョン3.18以上で取り込まれ、最近話題となっているファイルシステムです。AUFSと同様に、コンテナイメージの差分を管理するために利用されるファイルシステムです。Linuxカーネルに取り込まれたことから、今後、どのLinuxディストリビューションでもoverlayfsを利用することが可能になるはずです。メモリ利用効率がよく、先述のAUFSよりも性能が良いとされています。コンテナ専用OSのCoreOSのコミュニティにおいても、btrfsに取って代わるファイルシステムとしてoverlayfsがあげられており、話題になっています。現状は、ext4ファイルシステム上にoverlayfsを作成する必要があるため、OSが正式にサポートするext4の最大ファイルシステムサイズに注意が必要です。Overlayについては、以下のURLが参考になります。https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/overlayfs.txthttps://lwn.net/Articles/627232/devicemapperdevicemapperは、Linuxカーネルに含まれるドライバーとツール類からなり、ブロックデバイスと上位の仮想ブロックデバイスを紐づけます。Docker以外でも、FCストレージの冗長経路を実現するdm-multipathや、ソフトウェアRAIDを実現するdm-raidなどのモジュールにおいて、devicemapperが広く利用されています。devicemapperは、ブロックレベルでのコピーオンライトを実現します。Think-Provisioning(通称dm-thinやdm-thinpと呼ばれます)と呼ばれるストレージのシンプロビジョニングやスナップショットの機能があります。これにより、Dockerイメージの複数世代のスナップショットの作成が可能です。7系のOSでは、Dockerのディスクイメージ管理にdevicemapperが標準で使われます。Docker環境でのdevicemapperの利用については、以下のURLが参考になります。Thin-ProvisioningによりDockerのコンテナイメージを生成します。以上で、Dockerを導入する前に知っておくべき内容を紹介しました。Dockerは非常に簡単に導入できますが、本番系システムと開発系システムを2系統持つようなイミュータブルインフラをうまく実現させるには、導入前に採用すべきソフトウェアについて様々な情報収集と検討が必要になります。本連載で記載した内容をもとに、自社内で、Dockerの適用範囲を一度考えてみてください。1996年頃からオープンソースに携わる。サーバーのSI経験も持つ。2005年、大手製造業向けLinuxサーバー提案で日本HP社長賞受賞。Fame」を2年連続受賞。日本HPプリセールスMVPを4度受賞。日本HPのオープンソース・Linuxテクノロジーエバンジェリストとして講演活動も行っている。Hadoop認定技術者。HP公式ブログ執筆者。ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。VeloCloudが選ばれる理由SD-WANとはなにか。Linuxエンジニア育成への思いF5とNGINXの組み合わせで、サービス公開をよりセキュアに。ITがお届けするポッドキャストです。