以前に私が書いた「 Dockerの本番運用：失敗の歴史) 」という記事は、非常に多くの反響を呼びました。

その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。

この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。

免責事項：対象読者

たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。

1) アマチュア

実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。

注釈：書いたコードが動かない時もあるさ。でも俺のマシンでは動いたんだ

彼のマシンで動いたのなら、責められません。

2) プロ

実際のユーザを抱えていて、現実のビジネスで重要なシステムを運用している人々です。最終的な責任を背負っているので、何か問題が起きると苦情の電話を受けることになります。

注釈：「俺のマシンでは動いた」なんて簡単には口にしないよ

5億8600万人のユーザにサービスを提供するマシン上で動かなかったんですか？

あなたは一体どのタイプ？

これらの2つのタイプは紙一重ですが、両者は顔を合わせるたびに激しく対立します。それぞれの基準と期待するものは、明らかにかけ離れているのです。

私は財政学が大好きなのですが、その理由の1つとして、財政学は偉大なるリスクの文化であることが挙げられます。これは、一般的な通念に反してリスク回避の立場をとるという意味ではなく、潜在的なリスクと見込まれる収益を評価して天秤にかけるという意味です。

一度、自身の基準についてじっくりと考えてみてください。Dockerを使用して何を実現したいのか？　Dockerによって稼働中のシステム全体がクラッシュして、マウントされたボリュームが破壊された場合の損失はどれほどになるのか？　こうした要素は、決断を下す際の重要な決め手になります。

前回の記事を書いたきっかけは、行き当たりばったりの金融企業に勤める男性との会話でした。彼はDockerについて検討すべきか迷っていて、私に意見を求めてきたのです。とりわけ彼の会社、その中でも彼は特に、数百兆円という規模のシステムを扱っています。その中には、何百万人ものアメリカ人の年金を扱うシステムも含まれています。

現在のDockerで、私の母親の年金を処理するなんて到底無理です。どうしたら、そんな考えが浮かぶのでしょうか。恐らく、Dockerにまつわる体験談が十分に文書化されていないことが原因でしょう。

Dockerの運用に必要なもの

ご存知かと思いますが、Dockerは使用しているカーネルやホスト、ファイルシステムの影響を大きく受けます。そのため、ひとたび組み合わせを間違えると、カーネルパニックやファイルシステムの破損、Docker デーモンのロックダウンなどの問題が発生してしまいます。

私は時間をとって、さまざまな状況でDocker運用している人々からのフィードバックをまとめて、自分でもいくつかテストを実施しました。

その調査結果を元に、機能するもの、機能しないもの、間欠障害が発生するもの、全体に及ぶ大規模障害が発生するものなど、それぞれに登録された内容を見ていきましょう。

ネタバレ注意：Docker関連で機能すると保証されているものは何もありません。

免責事項：リスクと結果を理解する

私は（実際のお金を扱うプロとして）自分の基準に偏った考え方をしており、（現実世界のシステム運用で有名な信頼できるソースに偏りつつ）寄せられたフィードバックの内容に従っています。

例えば、あるOSとファイルシステムの組み合わせに対して 「禁止：全ボリュームデータの損失を伴う大規模なファイルシステムの障害が発生」 と記されていたらどうでしょう。その辺にある仮想マシンを使って学生が1度だけ練習目的で使用する程度なら問題はないでしょう。でも本番環境での使用は無理だと（私は）考えます。

上述の問題を実際に経験した方も、そうでない方もいると思います。いずれにせよ、これを取り上げたのは、こうした問題が今も発生しているということを、実際に被害を受けた人々が実証しているからです。彼らと同様の環境を使用すれば、次はあなたがこの問題に直面するでしょう。

Dockerでよくある最悪のケースは、コンセプトを検証した時点では問題がなかったのに、その先に進んだ際に問題が顕在化するパターンです。その問題に気付いて理解し始めた頃には、もう簡単には引き返せない状態になっているのです。

CoreOS

CoreOSは唯一コンテナを実行することが可能であり、コンテナの実行に特化したOSです。

前回の記事では、CoreOSがDockerを実行できる唯一のOSだろうと結論付けましたが、この真偽は定かではありません。

私たちはCoreOSを使用するという考えはやめました。

まず、Dockerの最大の利点は開発と運用を統合できることです。運用時に、コンテナのためだけに別のOSを使用するとなると、その利点が失われてしまいます。

次に、Debian（以前、私たちはDebianを使用していました）の次期メジャーリリースは2017年の第一四半期になると発表されています。全てを把握してCoreOSに移行するには大変な労力が要りますし、うまくいく保証もありません。よって、次のDebianをおとなしく待っていた方が賢明でしょう。

CentOS/RHEL

CentOS/RHEL 6

CentOS/RHEL 6ではDockerを使用しないでください ：既知のファイルシステムの不具合や全ボリュームデータの損失が発生します

1. devicemapperドライバに関するさまざまな既知の不具合があります。
2. LVMボリュームとdevicemapperドライバを併用した場合に、致命的な問題が発生します。これにより、データの破損、コンテナのクラッシュ、Dockerデーモンのフリーズなど、再起動しないと回復できない問題が生じます。
3. このディストリビューションではDockerパッケージがメンテナンスされていません。CentOS/RHEL 7では重大なバグがたくさん修正されていますが、それらの修正は旧バージョンであるCentOS/RHEL 6に移植されていません。

まだCentOS/RHEL 6を使用している大企業でDockerに移行する唯一の方法=>手遅れになる前に、直ちに移行計画を中止してください。

CentOS/RHEL 7

従来、RedHatではカーネル3を実行しており、そこにDockerの実行に不可欠なカーネル4の機能が移植されています。

この移植によって生じた問題があります。Dockerでカスタムのカーネルバージョンと利用可能な機能の検出に失敗するため、適切なシステム設定ができなくなり、いろいろと不可解なエラーが発生するようになったのです。この問題が発生するたびに、Dockerでは特定のカーネル用に機能検出の箇所に修正を加えたものをパブリッシュしなければなりません。このプロセスはタイムリーでもなければ計画的でもありません。

LVMボリュームを使用した場合は、バージョンに依存するさまざまな不具合が発生します。

ただし、これは複合的なバグであるため、実際の現象はそれぞれ異なる場合があります。

RedHatではCentOS 7.0の時点では、いくつかの設定を推奨していたのですが、現在はウェブサイトを探しても該当ページが見つかりません。いずれにしても、新しいバージョンになるほど重大なバグ修正が大量に入っているので、必ず最新バージョンに更新するようにしてください。

CentOS 7.2の時点では、RedHatは XFSのみを推奨およびサポートしており 、設定用の特別なフラグを提供しています。なお、AUFSは存在せず、OverlayFSは安定性が低いと見なされており、BTRFSはベータ版（技術プレビュー）です。

RedHatの社員ですら、適切な環境でDockerを機能させるのに相当苦戦していると認めています。OpenShiftの一部としてDockerを再販しなければならない彼らにとって、これは大問題です。試しに、不安定なコア上で製品を開発してみてください。

危険なことが好きな人にはとっては最適なOSでしょう。

これは、CentOSは要らないけれどもRHELがどうしても必要な場合、つまりタイムリーなアップデートと便利なサポートを自由に利用したい場合に限られるということに留意してください。

Debian

Debian 8 jessie（安定版）

私たちが直面する不具合の主な原因は、Debianの安定版をOSとして運用していることだと 前回の記事 で説明しました。

基本的にDabianが凍結したカーネルのバージョンでは、Dockerに必要なものが一切サポートされておらず、含まれている数少ないコンポーネントにはバグがあります。

Debian上では絶対にDockerを使わないでください ：AUFSドライバには、さまざまなバグがあります（このドライバに限ったことではありませんが）。頻繁にホストがクラッシュしたり、場合によってはデータが破損したり、その他にも大量のバグが潜んでいます。

Debian 8でDockerを使用するのは間違いなく自殺行為です。このことは数年前にDockerがリリースされてから今に至るまで変わりません。 この事実をもっと早く文書化して残してくれる人がいなかったことが悔やまれます。

ドミノのように倒れていくAWSインスタンスのグラフをお見せしましょう。適切な監視ツールと描画ツールがなかったので、楽譜のような感じで同等のものを描画してみました。

私たちのテストシステムで発生した典型的なカスケード故障。

私たちのテストシステムで発生した典型的なカスケード故障です。テスト用のスレーブがクラッシュして、その2分後に次のスレーブがリトライしますが、それも同様に失敗します。この連鎖では、6回リトライしてようやくバグを回避できました。通常よりもわずかに多い程度ですが、これが現実です。

CloudWatchのアラームを使用して、落ちてしまったホストを自動で再起動して、クラッシュの通知を送信する必要があります。

理想：同様にCloudWatchのアラームを使用して、問題が5分以上継続する場合は、必ずレギュレーターに問題のカスタムレポートを自動で送信します。

自慢するわけではありませんが、私たちはDockerの制御が非常に得意です。Chaos Monkeyみたいな子どもだましは忘れて、数千億円を扱う取引システムをDockerで運用しましょう[1]。

[1] とんでもない考えなので、絶対に実行しないでください。

Debian 9 Stretch

Debian Stretchは2017年に安定版になる予定です（注：この記事を書いて編集している間にリリースされるかもしれません）。

最新のカーネル4.9を対象にしているので、LTSカーネルにもなるでしょう。

Debian Stretchがリリースされると、その時点で最新の安定版OSになります。さらに聞くところによると、Dockerの実行に必要な優れた機能（Dockerの要件が再び変更になるまで）が全て含まれるようです。

これにより多くの不具合が解消されると同時に、新しい不具合も大量に発生する可能性があります。

どうなるのか、様子を見てみましょう。

Ubuntu

Ubuntuは、定期的なサーバのディストリビューションよりも常に最新になっています。

残念ながら、私はUbuntu上で運営されている本格的な企業を知りません。これが、Dockerコミュニティにおいてずっと大きな誤解が生じている理由です。開発者やアマチュアのブロガーは最新のUbuntu（LTSですらないもの※1）で、いろいろなことを試そうとします。でも、それは現実世界の稼働システム（RHEL、CentOS、Debian、または非標準的なUnix/BSD/Solarisのうちのいずれか）を代表するようなものでは決してありません。

LTS 16は使ったことがないのでコメントはできませんが、これは唯一Overlay2とZFSが備わっているディストリビューションです。他にも試用可能なオプションがいくつかあるので、何か役立つものが見つかるかもしれません。

LTS 14は最終的にちゃんと動作しません。古過ぎるので、必要なコンポーネントがありません。

※1: みなさんから、意見や最新のUbuntuベータ版を使うようにと” だけ “書かれた冷淡なメールを相当数受け取りました。まるで全ての稼働中のシステムをマイグレーションし、ディストリビューション変更し、その頃には存在すらしていなかったプラットホームのベータ版で実行することが、実際の解決策であるかのようでした。

アップデート：私は2度とDockerを使うことはないし、もちろんリファレンスを探し出すのに1時間かけることはないと言いました。しかし、素晴らしい方法で、私に引き渡されたので、やらなければならないと思っています。

明らかに素人と思われる男性から、非常に失敬な1通のメールを受け取りました。そこには” どんな大バカ者でもUbuntu上でDockerを実行することができる “と書かれており、さらにUbuntu上でDockerを実行するために必須のソフトウェアパッケージと高度なシステムの調整方法のリストが示されていました。彼のいうところによると” Googleを使って誰でも5秒で見つけ出せる “そうです。

彼のメッセージの核心は 次のバグレポートです。彼の言うとおり “Ubuntu Dockerは動かない” や “Ubuntu Dockerはクラッシュする” に対して、Googleの検索結果として最初に得られるものが該当します。 それは Docker 1.11.2のためのUbuntu 16.04 インストールが停止する です。

このバグレポートは、Ubuntuのインストーラがどうしても全く動かない、という2016年6月の重要事項として公開されました。 この理由は、実行の際にDockerが必要とする幾つかの依存パッケージがインストールされていないためだということです。 その後、コメントやユーザの回避策、Docker開発者によって、気にしないという意味の#WONTFIXラベルがつけられているのを目にしています。

5か月後、ある社員からインストーラの修正は行わないという最終的な回答がなされました。しかし、Dockerの次のメジャーバージョンでは、この問題の影響を受けない、全く違った何かを使うかもしれません。（レポートから8か月後に）リリースされましたが、バグにより影響を受けているかどうかは確認されていません（しかし、重要な変更があったことは確かです）。

Dockerから得られるだろう、かなり典型的なやりとりは、以下のとおりです。

• Dockerが全く動かなくなった時点で、全て破損しているか？ はい
• 全ユーザで、また主要なディストリビューションで破損しているか？　はい
• 適時、その問題に応じた回答があるか？　いいえ
• その問題は今起こっており、どれほど深刻か確認されているか？　いいえ
• 修正計画はあるか？　いいえ
• さまざまな危険や複雑さの回避策はたくさんあるのか？ はい
• そもそも修正されるのか？　誰にも分からない
• 修正するなら、いつか、バックポートされるのか？　いいえ、されません
• 全ての問題に対する最終的な回答は、最新版でアップデートするということなのか？　もちろんだ

アップデートのアップデート：（私は書くのが遅いので）アップデート中に、Tinder で2人から3つの待機メッセージを受け取りました。TinderはDockerよりもずっと良い結果を出してくれます。もう二度とDockerで夜の時間を無駄に過ごしたりしないでしょう。

AWSコンテナサービス

AWSはDockerの実行専用AMIを持っています。 これはUbuntuベースです。

内部情報で確認されたところによると、全ての適切な環境でDockerを実行させるために、かなりの苦労を経験したとのことです。

最終的に、カスタムバグフィックスとバックポートしたカスタムDockerパッケージを使ってカスタムOSを起動するような、Dockerの実行専用のAMIをリリースしました。彼らはやり遂げ、今もなお、多大なる苦労を重ね、一貫性を保つためのテストを行っています。

Dockerにロックインされてしまったり、AWS上で実行が止まったりしたら、AWSに任せてしまうのが、唯一の手段かもしれません。

Googleコンテナサービス

Googleはサービスとしてコンテナを提供します。しかし、内部情報によると、もっと重要なことに、提供内容は100パーセントDocker化されていないのです。

Googleは単にDockerのインターフェースを公開しただけです。コンテナは全て、内部のGoogleコンテナ化技術の上で実行されており、もしかするとDocker実装の欠陥の全てに悩まされることはないのかもしれません。

品質の大きなラベルが与えられるもの：それはDockerを使わないコンテナだ。

私のことを誤解しないでください。コンテナは、概念としては素晴らしいものです。問題は、理論的な側面ではなく、実際的な実装と、せいぜい実験的にしか使えない手持ちのツール（つまりDocker）なのです。

本当に、Docker（あるいはコンテナ）を取り扱おうとするなら、AWSの上で作業しないことです。すると、Googleは単独の最強の選択肢として残ります。さらに良いことには、オーケストレーションのためのKubernetesがついており、自社の製品群でまとめられています。

これは今でも実験的で、危険なものと考えられています。このサービスは唯一約束を果たせる見込みがあり、さらにコンテナとオーケストレーションが備わっているただ一つの手段だったということです。

OpenShift

破壊されたコア上で安定した製品を作ることは不可能ですが、RedHatはそれに挑んでいます。

私が受けたフィードバックでは、Dockerの問題を軽減させようと必死に取り組み、両者ともさまざまな成功を収めているようです。ただし、実際の効果はそれぞれ異なるでしょう。

両者とも失うものが多い大企業に訴えかけていることを考慮すると、その方法（つまり、Dockerをベースに構築されたもの）を選択することに強い疑問を感じます。

代わりに標準的なクラウドを試してみるべきでしょう。つまりAWS、GoogleまたはAzureのことです。 仮想マシンといくつかのホスティングサービスを使うと、Dockerが成すことの90%とDockerではできない90%のことを実現させることができ、信頼性もあるでしょう。また、より効果的な長期戦略でもあります。

恐らく、公開されたクラウドでは実現できないためOpenShiftを使いたいのでしょう。しかし、それは困難な状況ですね（うまくいくことを願っています。ブログの返信にあなたの経験をぜひ書いてください）。

要約

• CentOS/RHEL：ロシアンルーレットのようなもの
• Debian：裸で飛行機から飛び降りるようなもの
• Ubuntu：確信がありません アップデート：笑ってしまうレベル
• CoreOS：努力する価値が無い
• AWSコンテナ：DockerとAWEにロックインされてしまった場合の唯一の救い
• Googleコンテナ：完全にばかげてはいない、Dockerを実行するための唯一の実践的方法
• OpenShift：確信が持てないが、サポートの質とエンジニアの能力次第ではないか

ビジネスにおける視点

Dockerにはビジネスモデルが存在せず収益化する方法がありません。 Dockerは全てのプラットフォーム（Mac/Windows）に向けてリリースされており、次に述べるような無鉄砲な戦略で全ての種類の機能（Swarm）を統合していると言っても良いでしょう。1)どんな競合相手にも独特な機能は持たせない 2)全ての人にDockerとDockerのツールを使わせる 3)顧客を彼らのエコシステム内に完全にロックする 4)大量のニュースや記事を公開し、その途中でリリースすることで誇大に宣伝する 5)評価を正当化する

複数の製品とマーケットに対して、水平と垂直の両方向へ拡張を図ることは非常に困難です（適切、あるいは持続可能なビジネス上の決定かどうかという点については、異なる視点なので無視します）。

その間に、Amazon、Microsoft、Google、Pivotal、そしてRedHatなどの全ての競合企業がさまざまな方法で競争し、コンテナにおいてはDockerよりも儲けています。一方で、CoreOSはOS（CoreOS）を動かしており、（ Rocket のような）コンテナ技術で競争しています。

前述したのは、いずれもDockerに対して多くの武器で集中的そして圧倒的に張り合う大企業ばかりです。 彼らはDockerが誰をロックしようと関心のひとかけらもありません。関心があるとしたら、それは集団でも個人でも、Dockerの使用を中止し別の何かに置き換えるという点についてでしょう。

これをコンテナ戦争と名付けることにして、今後の展開を楽しみにしましょう。
現状ではGoogleが一歩先を行っています。既にDockerは使用しておらず（ GKE ）はDocker上ではなく内部のGoogle技術において実行されます）、すぐに使えるオーケストレーション（ Kubernetes ）を提供する唯一の企業です。

結論

私はDockerが不安定なおもちゃのようなプロジェクトだと言いましたか？

問題は存在していない、あるいは過去の事だと言う人は常にいるものですが、 課題と問題は確実に今現在も存在しています。Dockerには全ての主要なディストリビューションを全く使えなくするという致命的なバグがあり、それは長年にわたり広まって今日現在も存在しているという明白な証拠と資料があります。

Google上で”Docker + バージョン + ファイルシステム + OS”という文字列の組み合わせで検索すると、Dockerの誕生までずっとさかのぼり、さまざまな影響を及ぼす問題の痕跡を目にするでしょう。なぜそこまでひどく長期間にわたって失敗し、しかもそのことについて誰も掲載しなかったかは謎です（実際にいくつか記事は存在しているものの、大量の広告と迅速な評価に埋もれてしまっていました）。 その失敗のレベルでその期待値にかなう最後のソフトウェアがMongoDBでした。

Dockerを真剣に使い、成功し、さらに多くのトラブルに遭遇することもなかった人を、私は世界中で一人も見つけることができませんでした。この記事で書かれている経験談は、社員と企業がダウンタイム一秒毎に11万円を損失するという犠牲の上に得られたものです。

過去の教訓から同じ過ちが繰り返されないことを望んでいます。

注釈：過ち
あなたの生きる目的は、他人に警告するためだけにあるとも言える。

あなたがDockerを何年も前に採用すべきだっただろうかと思いを巡らせているとしたら、その答えは”そんなわけがありません”。あなたは惨事を免れたのです。上司にそのように伝えると良いでしょう（現状でも適切なオーケストレーションがなければあまり使いやすくないので、それ自体が実験的課題です）。

満足できるものを実行していて、あなたが品質を重んじている場合、今、Dockerを採用すべきかという問いに対しては、RHEL8とDebian10が出るまで待つべきだというのが妥当な答えです。 焦る必要はありません。
物事は成熟する必要があり、パッケージはあなたが実行するディストリビューションより早く動くことはありません。

危険な遊びに手を出したいならば、GoogleクラウドでGoogle Container Engineを完全に管理してみてください。決定的にハイリスクですが、ハイリターンを期待できるでしょう。

もしもこの記事で、多数のバグに関するレポート、カーネルのパニック画面のスクリーンショット、システムの障害が発生した日の個人的な図表、関連したフォーラムの投稿、そしてプライベートな会話の暴露などへのリンクを掲載したら、信憑性はもっと高まるのでしょうか。おそらく、そうでしょう。

しかし、私がさらに百時間もその事を深堀りするために時間を費やしたいかというと、答えは”ノー”です。Dockerを扱うよりはTinderと向き合って夜を過ごしたいものです。Dockerはもういりません。さようなら。

前進

私についての話題に戻ります。コンテナとクラウドにおいて先導するための私の行動計画には重大な欠陥があることを見落としていました。テクノロジーを提供する企業において平均保有期間はまだ「年」単位では考慮されていないため、2017年の初旬からぬかるみにはまってしまったのです。

悪いニュース：クラウドとDockerに関して、これ以上話すことはありません。つまり、これ以上の画期的なニュースはないということです。あなた自身で問題を解決してください。

良いニュース：これ以上、数千億円もの他人のお金を軽々しく扱わなくていいのです。なぜかというと、私は少なくとも3桁は昇給しているからです！　直近の新しい活動の場には、このブログを読んでいる大勢の人々も含めた、数百万人ものアメリカ人の年金も含まれていると、控えめに確信しています。

注釈：あなたの年金基金
100%Docker化されていないことを保証します

ご安心ください：あなたの年金は安泰です！