Dockerの導入前に知っておくべきこと
IT部門は、現在よりも柔軟性の高い効率的なITシステムにするために、開発部門と協調し、自社のシステムにDockerを採用すべきかどうかの妥当な判断をしなければなりません。このDockerの採用可否に関する「妥当は判断」は、短時間で結論が出るものではありません。ベンダーや自社の有識者が集い、導入目的、採用可否、設計指針などをある程度具体的に検討しなければなりません。本章では、Dockerの導入を検討する場合に知っておくべき前提知識、検討項目を述べます。さらに、実際にDockerを導入時する際に知っておくべき項目を述べ、最後に、導入手順と注意点について述べます。
Docker導入前の検討事項
Dockerを導入する上で、検討しなければならない項目としては、まず、「そもそもDockerが自社に必要なのか？」ということです。Dockerは、コンテナを管理するためのソフトウェアであり、非常に優れた機能を提供しますが、優れた機能だけでなく、既存の仮想化環境などに比べてのメリット、デメリットを把握しておく必要があります。例えば、多くのハイパーバイザー型の仮想化ソフトウェアでは、ライブマイグレーションの機能を提供しており、ゲストOSを稼働させたまま、別の物理マシンに移動させることが可能ですが、Dockerにおいては、ライブマイグレーションの機能が提供されていないため、ライブマイグレーションによる運用を行うことはできません。仮想化ソフトウェアを完全に置き換えることはできない点に注意すべきです。また、Dockerコンテナの高可用性を考える場合は、HAクラスタのサポート状況がまだ不明確になっており、Dockerコンテナで、プロセス監視のためのHAクラスタを構成したとしても、共有ディスクの論理ボリュームの切り替えをどのように行うかなどの課題も残っています。現時点で、ベストプラクティスが明確に定められているわけではありませんが、CRIUプロジェクト、共有ディスクを持たない「DRBD＋Corosync＋Pacemaker」でのHAクラスタ構成、Keepalivedとソフトウェアベースの負荷分散機能を実現するLinux Virtual Server（LVS）の組み合わせ、さらに、MESOSなどのプロジェクトや利用経験者のコミュニティが、Dockerにおける高可用性実現に向けて、実証実験や研究を行っています。
図1：従来環境とDockerにおける可用性の実現方法
Docker は、誰もが無償で入手できるオープンソースソフトウェアですが、実は、稼働するOS環境の違いによって、分類することができます。まず一つ目は、コミュニティ版のサーバーOSで稼働するDockerと商用Linuxで稼働するDockerでの分類です。コミュニティ版のサーバーOSで稼働するDockerのことを本連載では、「コミュニティ版のDocker」と呼ぶことにします。このコミュニティ版のDockerが稼働するOSとしては、Fedora、CentOS、Ubuntu Serverなどがあげられます。当然、コミュニティ版のサーバーOSは、ベンダーの保守サポートを受けることができませんので、その上で稼働するDockerもベンダーの保守サポートを受けることができません。Docker自体に問題があるのか、サーバーOS側に問題があるのか等の切り分け作業をユーザー自身で行う必要があります。一方、商用LinuxであるRed Hat Enterprise Linux（RHEL）やSUSE Linux Enterprise Server（SLES）でもDockerを稼働させることができます。
Ubuntu ServerもベンダーがOEM提供するLTS版の場合は、OS自体の保守サポートをベンダーから受けることが可能ですが、2015年の8月下旬現在、ベンダーが提供するOEM版のUbuntu Serverにおいては、Dockerそのものに関するOEMベンダーの保守サポートが提供されているかどうかを確認する必要があります。Dockerの保守サポートを重視する場合には、この点に注意が必要です。RHELやSLESなどの商用Linuxで稼働するDockerについては、そのサブスクリプション契約の範囲内でのサポートが受けられます。例えば、ハードウェアとドライバーや監視エージェント類、ミドルウェア、そして、Dockerの問題の切り分け作業をベンダーに依頼できます。Dockerに関するある程度の技術面でのサポートが必要となる場合は、ベンダーサポートが得られる商用Linuxで稼働するDockerの導入を検討すべきです。特に、Dockerのような現在も発展途上の先進的なソフトウェアを本番系システムに実戦投入する場合、動作の安定性や機能的な側面だけでなく、Docker自体の不具合や障害発生時の回避策、解決策の情報入手の容易さがシステムの安定稼働において重要な意味を持つ場合が少なくありません。
逆に、商用Linuxのサブスクリプション契約による手厚いベンダー保守サポートが不要と判断するためには、ユーザー部門（導入を検討しているIT部門と開発部門）において、Dockerに関する十分な知識、さらに、IT技術者と開発者双方がDockerとコミュニティ版のサーバーOSに関する十分な現場経験と技能、問題解決能力を有していることが必要です。例えば、システムに目立った障害が発生しなくても、ある一定の操作を施すと、Dockerコンテナのネットワーク性能が著しく劣化するような問題が発生した場合、それが高負荷時にのみ発生するのか、カーネルパラメータの設定に問題があるのか、Dockerの設計上の潜在的な問題なのか等の切り分け作業が必要であり、膨大な工数を伴う場合があります。それらの問題をどのような体制でどのように解決するのかといった組織能力を踏まえた上での導入が必要です。
Dockerの導入を検討する上での主なチェックポイント
- そもそもDockerが自社に必要なのか？
- 既存の仮想化環境における課題は何か？
- 既存の仮想化環境をコンテナ型の環境に置き換えることが可能か？
- 自社へのDockerの適用の最大の障害は何か？
- 現在のシステムのどの部分にDockerを採用するのか？
- 物理環境の高可用性に関するSLA（Service Level Agreement）をDockerでも実現できそうか？
Docker導入決定後、サーバーOS選定における主なチェックポイント
- Dockerを稼働させるOS環境は、コミュニティ版OSでよいのか？商用Linuxにすべきか？
- コミュニティ版OSにする場合、どのディストリビューションを採用するのか？
- 商用Linuxの場合、どのディストリビューションを採用するのか？
- OEMベンダーからOSとDockerの保守サポートを同時に受けられるか？
- OEMベンダーからの保守サポートが受けられない場合、問題切り分け作業を自社で行えるか？
コンテナ専用OSの現状を把握する
2つ目は、通常のサーバーOSで稼働するDockerと、Docker向けに開発された専用OSでの分類です。本連載では、Dockerなどのコンテナ利用に特化して開発された専用OS のことを「コンテナ専用OS」と呼ぶことにします。このコンテナ専用OSは、普段使い慣れたCentOSやRHELの上で稼働させるDockerとは異なり、コンテナを稼働させることに目的を絞ったアプライアンスOSであり、専用OS自体の管理方法も、CentOS等の使い慣れた一般的なLinux OSとは異なります。コンテナ専用OSは、アプリケーションや稼働するデーモン、パッケージ管理マネージャなどが削られており、コンテナの稼働に必要最低限のコンポーネントで構成されています。コンテナ専用OSでは、コンテナに無関係なデーモンやアプリケーションなどが稼働することを極力排除しているため、一般的なサーバーOSに比べてより強固なセキュリティ、性能面での優位性、高い保守性を確保できるとされています。コンテナ専用OSとして有名なものとしては、Project Atomic、Snappy Ubuntu Core、そして、CoreOS（コアオーエス）があげられます。Project Atomicは、コンテナの配備や管理などを効率化したDocker専用OSの発展を目指すコミュニティベースのプロジェクトです。Project Atomicでは、主に2つのDocker専用OSの開発が行われており、Fedoraベースの「Fedora Atomic Cloud」とCentOSベースの「CentOS Atomic Host」があります。現在はまだ開発段階のレベルであり商用利用には向けいていませんが、無償で入手することができ、Docker専用OSを体験することができます。
さらに、商用製品としては、Red Hat社がリリースしている「Red Hat Enterprise Linux Atomic Host」があります。RHEL Atomic Hostは、Project Atomicの成果物を商用化しつつも、管理ツールなどを搭載した製品です。Canonical社が提供するSnappy Ubuntu Coreも、Dockerのようなコンテナの利用を目的とした軽量OSであり、Project Atomicと同様、必要最小限のコンポーネントで構成されています。さらに、CoreOSと呼ばれるコミュニティのプロジェクトは、Dockerやそれとよく似たrktと呼ばれるコンテナに最適化された軽量OSにGUI管理ツールを同梱しており、簡単にコンテナを管理・利用することができるように設計されています。
サーバーOS vs. コンテナ専用OS
使い慣れたサーバーOSの上でDockerを稼働させるメリットとしては、Docker以外の非コンテナ環境のサーバーOS環境と同様のOS管理が行えるため、既存のOS管理用のツールなどを使用でき、新しく導入するDocker環境においてもサーバーOSの標準化を図ることができる点にあります。今まで使い慣れたOS管理手法をDockerが稼働するサーバーOSでも活用できるため、新しい管理手法を習得する工数を削減することができます。しかし、Dockerについては、GUI管理ツールやオーケストレーション等の周辺ソフトウェアをユーザー自身で構築、整備する必要があります。一方、コンテナ専用OSは、今までのサーバーOSの管理手法とは異なるため、コンテナ専用OS自体の作法を一から学ぶ必要があります。例えば、Atomic Hostでは、CentOSやRHELで有名やパッケージ管理用のyumコマンドの利用ができないため、OS環境全体を新しく切り替えやロールバックなどの新しい仕組み（rpm-ostreeと呼ばれる仕組みが有名です）を理解する必要があります。また、サーバーOS用に開発されたサードパーティ製のアプリケーションが稼働しない場合もあるため、アプライアンスとしてコンテナ専用OSをどこまで割り切って利用するかを検討する必要があります。以下に、サーバーOS及びコンテナ専用OSの採用に関する主なチェックポイントを掲載しておきます。
サーバーOS及びコンテナ専用OSの採用に関する主なチェックポイント
- 使い慣れたLinuxサーバーOSからコンテナ専用のアプライアンスの利用に切り替えてもよいか？
- ホストOS上で、サードパーティ製のアプリケーションを稼働させる必要性があるか？
- OSとDockerのインストールに際し、手順書や人員のスキルセットを確保しているか？
- サーバーOSの管理は、従来と同等の手法が必要か？新たな管理手法でも問題がないか？
- Dockerコンテナは、GUIによる管理が必須か？
- 外部ストレージの利用はあるか？
- ハードウェアベンダーやミドルウェアベンダーが提供する監視エージェント類は必要か？
[補足]
2015年現在、Fedora Atomic Cloudについては、ベアメタル環境に直接インストールすることができるisoイメージが提供されています。一方、CentOS Atomic Hostは、KVMをベースとした仮想環境上で稼働が可能なqcow2形式のイメージファイルが提供されており、Docker専用OSをすぐに試すことが可能です。
Docker導入を目的とした場合のサーバーOSの注意事項
Dockerは、CentOS、RHEL、Fedora、Ubuntu Server、Debian、Oracle Linux、SLES、openSUSEなどに対応していますが、OS毎に注意すべき点が異なります。以下では、Docker導入の際のOS毎の注意点をいくつか簡単にあげておきます。
CentOS
- CentOS 6系とCentOS 7系の両方でサポートされています。しかしその他のRHEL互換OS（例えば、Scientific Linux等）はテストされていません
- CentOS 6系でDockerを稼働させる場合は、Linuxカーネルバージョンが2.6.32-431以上であることが条件です
- Dockerサービスを起動する前にfirewalldを起動させた場合は、Dockerサービスを再起動する必要があります
参照すべきURL：
https://docs.docker.com/installation/centos/
RHEL
- RHEL7系において、Dockerをインストールするには、Red Hat社が提供しているextraチャネルまたは、EPELリポジトリを有効にする必要があります
- RHEL 6系においてDockerを稼働させるためには、EPELのyumリポジトリを有効にする必要があります
- RHEL 6系においてEPELで導入したパッケージについては使用者の自己責任での利用になります
参照すべきURL：
https://access.redhat.com/articles/881893
https://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.html
Fedora
- 現時点で、ディストリビューションで配布されている標準カーネルのみをサポートします。それ以外のカーネルではDockerの動作上問題が発生する場合があります
- dockerグループの作成、/var/run/docker.sockファイルのユーザーIDとグループIDを変更する必要があります
参照すべきURL：
https://docs.docker.com/installation/fedora/
Ubuntu Server
- Linuxカーネルバージョンが3.10より新しいバージョンにする必要があります
- Ubuntu 12.04 LTSでは、Linuxカーネルバージョンが3.13以上である必要があります
- メモリとスワップに関するGRUBのブートパラメータの追加が必要です
- Ubuntuで実装されているファイヤウォールUFW（Uncomplicated Firewall）を利用する場合は、ファイヤウォールに関するパラメータの設定が必要です
参照すべきURL：
https://docs.docker.com/installation/ubuntulinux/
Debian
- Debian 7系にバックポートされたLinuxカーネルバージョンの3.16が必要です
- Debian 7系では、get.docker.comとcurlコマンドを使ってDockerのインストールを行う必要があります
- dockerグループを作成する必要があります
参照すべきURL:
https://docs.docker.com/installation/debian/
https://packages.debian.org/search?suite=wheezy-backports§ion=all&arch=any&searchon=names&keywords=linux-image-amd64
Oracle Linux
- Unbreakable Enterprise Kernelのバージョン3.8.13以上である必要があります
- Unbreakable Linux Network経由のアドオンのチャネルとOracle Public Yumのアドオンチャネルを有効にする必要があります
- OSシャットダウン時に、btrfsファイルシステムをアンマウントする既知の問題に対応するために、Oracle Linux 7では、systemdによるDockerのサービスの制御のための設定ファイルを編集する必要があります
- Oracle Linux 7において、SELinuxはPermissiveまたはDisabledにしなくてはなりません
参照すべきURL:
https://docs.docker.com/installation/oracle/
http://docs.oracle.com/cd/E52668_01/E39381/html/index.html
http://public-yum.oracle.com/
SLES
- SLES 12以上でサポートされます
- Dockerを利用するユーザーは、dockerグループに所属している必要があります
- 外部ネットワークへの通信のため、IPv4フォワーディングの設定が必要です
参照すべきURL：
https://docs.docker.com/installation/SUSE/
https://www.suse.com/documentation/sles-12/pdfdoc/dockerquick/dockerquick.pdf
OpenSUSE
- openSUSE 12.3以上でサポートされます
- openSUSE 13.1までは、仮想化に関する追加のリポジトリの設定が必要です
参照すべきURL：
https://docs.docker.com/installation/SUSE/
Dockerのバージョンが更新される度に、サポートされるOSのバージョンも変更になりますが、注意点及び既知の問題については、OS毎にDockerのインストール手順と注意点が記されたWebページ（https://docs.docker.com/installation/）を参照するようにしてください。特に、商用Linuxを使用している場合は、DockerのWebサイトだけでなく、ベンダーが提供しているDockerに関する公式のドキュメントを合わせて参照するようにしてください。
図2：Dockerの動作OSバージョンとDocker導入の注意点
Dockerにおけるドライバー
Dockerで利用されるバックエンドの仕組みには、大きく分けて、コンテナの制御（Linuxカーネルのコンテナに関連するAPIの呼び出し等）を行う実行ドライバー（Execution Driver）と、ファイルシステム関連の制御を行うストレージドライバーの2種類があげられます。実行ドライバーは、cgroupなどの資源管理の仕組み、名前空間、SELinuxやAppArmorで提供されるセキュリティの仕組みなど、Linuxカーネルが提供する機能をDockerから利用する場合に実行ドライバーが必要となります。一般的に、ユーザーの利便性を意識した使い勝手に直接影響を与える管理ツール群は、フロントエンドと呼ばれ、一方、実際の動作を担うドライバーなどは、バックエンドと呼ばれます。Dockerにおけるバックエンドの実行ドライバーとしては、LXC、libcontainer、libvirt-lxcなどがあり、いずれもDockerから利用可能です。Docker 0.9からは、libcontainerがビルトインされており、libvirtやLXCなどのDocker以外のコンポーネントに依存することなくLinuxカーネルのコンテナAPIにアクセスすることができるようになりました。一方、Dockerは、ファイルシステムレベルのストレージバックエンド（ストレージドライバーとも呼ばれます）として、btrfs、AUFS、vfs、overlayfsがサポートされています。また、通常のファイルシステム上で利用されるブロックデバイスレベルでのストレージバックエンドとしては、devicemapperがサポートされています。Dockerのファイルシステムの利用の指針は、OSの種類によって異なりますが、ファイルシステムの特性をある程度知っておくことが必要です。以下では、Dockerでサポートされているいくつかのファイルシステムの概要と指針について、一般的なCentOS 7.xでDockerを利用することを前提に説明します。
図3：libcontainer
Btrfs（B-tree File System）
Btrfsは、バータエフエスやB木ファイルシステムとも呼ばれ、大規模のストレージシステムでの利用を念頭において設計されたコピーオンライトのファイルシステムです。オラクル社の技術者が多く開発に携わっています。Btrfsは、過去の状態に戻すことができるロールバックの機能や、ある時点での状態を保持することができるスナップショット機能、ファイルシステムの圧縮機能、I/O性能向上を目的としたデフラグの機能、さらに、メタデータを複製する耐障害性の機能も有しています。最大ファイルサイズ、及び、ファイルシステムの最大サイズは、16エクサバイトになります。
Btrfsを利用する場合は、ホストOS上の/var/lib/dockerディレクトリをBtrfsでフォーマットする必要があります。このBtrfsを使うことで、Dockerにおけるファイルシステムレベルでのスナップショットが可能となります。CentOS 7.1では、標準でBtrfsを利用することが可能です。ただし、Btrfsは、CentOS 7.1のアップストリームOSであるRHEL 7.1において、テクノロジープレビューに位置づけられている点に注意すべきです。2015年現在、RHEL 7.1におけるBtrfsは、ベンダーの保守が得られないファイルシステムとして位置づけられています。そのため、RHEL 7.1互換のCentOS 7.1におけるBtrfsでの利用においても、RHEL 7.1におけるテクノロジープレビューの機能を利用するという覚悟が必要です。逆に、安定稼働をある程度無視できる開発系システムでは、Docker自体も、まだ商用レベルに向けて発展途上であるという位置づけから、Btrfsなどの先進のファイルシステムも積極的に利用されています。
Btrfsについては、以下のURLが参考になります。
- https://btrfs.wiki.kernel.org/index.php/Main_Page
- https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-btrfs.html
- http://www.projectatomic.io/docs/filesystems/
- https://docs.oracle.com/cd/E39368_01/b71105/ol_btrfs.html
[補足] コピーオンライトとは？
コピーオンライト（Copy on Write：COW）は、ファイルへの書き込み発生時にオリジナルのデータを上書きしない仕組みを提供します。現在のデータの上書きはしない代わりに、ディスク上にある未使用のブロックを使うことで更新を行います。コピーオンライトではないファイルシステムとしては、vfsやext4などがあります。ext4などの一般的なファイルシステムでは、例えばユーザーが作成した新しいコンテナイメージなどのデータが作成されると、もし既存にその当該データが存在する場合は、上書きされ、新しいコピーが作成されます。一方、FreeBSDなどのBSD系OSで利用が進んでいるZFSやDockerなどで利用されるBtrfsは、アプリケーションが、コンテナイメージなどのデータを要求すると、データはメモリ及びキャッシュ上に転送されます。複数のアプリケーションが同時にこの要求を行った場合、通常は、アプリケーション毎に紐づいたメモリ空間を保持しますが、コピーオンライトの場合は、複数のアプリケーションが一つのデータを要求すると、一つのメモリ空間ですみます。データの変更を行っているアプリケーションには、更新された情報を含むメモリ空間が付与され、データの更新を行っていないその他の複数のアプリケーションは、オリジナルのデータを使います。コピーオンライトの利点に、ディスクのスペース効率があげられます。オリジナルのデータがいくら巨大なものでも、スナップショットに消費されるディスク容量は非常にわずかであり、スナップショットの生成に関するディスクのI/O性能に関する劣化も無視できる程度です。また、オリジナルのデータからスナップショットを生成する場合にディスクへの書き込み要求が発生しますが、データが更新されていない状態では、読み込み要求は、オリジナルのデータを使って行われます。コピーオンライトは、書き込み失敗によるデータの破損のリスクを回避することができるため、複数のアプリケーションがデータを更新・参照する際の信頼性を確保することができます。
AUFS（Advanced Multi Layered Unification File System）
AUFSは、PaaSプラットフォームであるdotCloudにおいて利用されていたファイルシステムです。AUFSにより、複数のコンテナに跨ってOSのイメージやライブラリ等のコンポーネントを共有（差分で管理）することができます。2015年5月現在、最新のUbuntu Server 15.04において、Dockerをインストールすると、標準でAUFSが利用されます。DebianとUbuntu Serverについては、デフォルトのカーネルで利用することが可能となっています。有名なものとしては、Knoppixと呼ばれるHDDを使わないLiveCDのディストリビューションでAUFSが採用されています。ただし、AUFSは、Linuxのアップストリームカーネルに標準で含まれておらず、RHELやSLES等の主要な商用Linuxディストリビューションにおいてサポートされていません。こんため、現時点で、AUFS含むカーネルを標準で利用できるUbuntuやDebianにおけるDockerでのみ利用することになります。
AUFSについては、以下のURLが参考になります。
overlayfs
overlayfsは、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.txt
- https://lwn.net/Articles/627232/
devicemapper
devicemapperは、Linuxカーネルに含まれるドライバーとツール類からなり、ブロックデバイスと上位の仮想ブロックデバイスを紐づけます。Docker以外でも、FCストレージの冗長経路を実現するdm-multipathや、ソフトウェアRAIDを実現するdm-raidなどのモジュールにおいて、devicemapperが広く利用されています。また、devicemapperは、ブロックレベルでのコピーオンライトを実現します。Device Mapper Think-Provisioning（通称dm-thinやdm-thinpと呼ばれます）と呼ばれるストレージのシンプロビジョニングやスナップショットの機能があります。これにより、Dockerイメージの複数世代のスナップショットの作成が可能です。Fedora、CentOS 7系、RHEL 7系のOSでは、Dockerのディスクイメージ管理にdevicemapperが標準で使われます。
Docker環境でのdevicemapperの利用については、以下のURLが参考になります。
[補足]
Device Mapper Thin-Provisioningは、Linuxで提供されるLVMと組み合わせて使用することができますが、Dockerにおいては、LVMを使わずにDevice Mapper Thin-ProvisioningによりDockerのコンテナイメージを生成します。
以上で、Dockerを導入する前に知っておくべき内容を紹介しました。Dockerは非常に簡単に導入できますが、本番系システムと開発系システムを2系統持つようなイミュータブルインフラをうまく実現させるには、導入前に採用すべきソフトウェアについて様々な情報収集と検討が必要になります。本連載で記載した内容をもとに、自社内で、Dockerの適用範囲を一度考えてみてください。
