翻訳者からの説明：目の前に表示される翻訳は、実稼働中の元のMoby / Docker投稿に基づいて、2017年2月23日に作成されました。 失敗の物語 、その翻訳は（ オレグチャーの原作者による）ここハブレで、活発な議論を引き起こしました。 書いた日付に合わせて読んでください-元のテキストはほぼ1年前に書かれました！
テキストの扱いは異なります。 朝のコーヒーを楽しんで、著者の認識のプリズムを通して自分自身を見てみて、Dockerについてのアドバイスを聞いたときに、彼が彼の経験と仕事に対する態度でどのように反応するか考えてみてください。
本番環境での以前のMoby / Dockerの記事。 失敗話はヒットであることが判明しました。 今日、長い議論、数百件のレビュー、数千件のコメント、さまざまな人々との会議、大規模なプレーヤーとの会議、さらに多くの実験とより多くの失敗の後、写真の更新を公開する時が来ました。
すべての最新のコミュニケーションと記事から学んだ教訓を見ていきますが、まずは、明確化、リマインダー、および少しのコンテキストです。
免責事項：対象読者
多くのコメントは、世界はたった10種類の人々に分割されていることを示しました：
1）恋人たち
通常、実際のユーザーがいないテストまたは趣味のプロジェクトをサポートします。 彼らは、Ubuntuのベータ版を使用するのが普通であると信じるかもしれません、そして、彼らはすべてを「 安定 」時代遅れと呼びます。
彼を責めることはできません。彼のマシンではコードが機能します。
2）専門家
実際のユーザーとの実際のビジネスに不可欠なシステムをサポートします。 確かに彼の行動に責任がある。 たぶんファンに当たると電話がかかってきます。
...これは、別の5億8,600万人のユーザーが入力するシステムでは機能しない可能性があるためです。
どんなタイプの聴衆ですか？
これらの世界の境界は非常に薄いですが、明らかに、それらは非常に異なる基準と期待を持っています。
金融の分野が大好きな理由の1つは、金融文化が発達していることです。 一般的な信念に反して、これはリスク選好度の向上を意味するのではなく、可能性のあるリスクと潜在的な利益を検討し、それらを相互に比較する習慣です 。
自分の標準について少し考えてみてください。 Dockerに何を期待しますか？ 実行するすべてのシステムがクラッシュし、マウントされたストレージボリュームが破損した場合、何が失われますか？ これは、選択に影響する可能性がある重要な要素です。
最後の記事を公開するよう促されたのは、Dockerの使用を検討しているため、Dockerについてどう思うかを尋ねた金融会社の男との会話でした。 とりわけ、彼の会社、特にこの男は、何百万人ものアメリカ人の年金を含む数兆ドルを処理するシステムを運営しています。
Dockerは私の母の年金処理をサポートする準備が完全に整っていません。 Dockerでの蓄積された経験は十分に文書化されていなかったと思います。
Dockerの使用を開始するために確実にしたいことは何ですか？
この時点で知っていたはずですが、Dockerは選択したカーネル、ホスト、および実行中のファイルシステムに非常に敏感です。 間違った組み合わせを選択すると、カーネルパニック、ファイルシステムの破損、Dockerデーモンのブロックなどが発生します。
さまざまな労働条件に関するフィードバックを収集し、自分自身をさらに確認する時間がありました。
自信を持って動作していると考えられているもの、動作していない、断続的な障害を経験している、または単に失敗したという研究結果を調べます。
注意、ネタバレ：Dockerの場合、保証されるものは何もありません。
免責事項：リスクと結果を理解する
私は自分の基準を信頼し（本物のお金を処理しなければならない専門家として）、調査結果をフォローします（実世界のシステムで動作する信頼できるソースを信頼しているため）。
たとえば、OSとファイルシステムの組み合わせが「 不適切：ボリューム全体のデータ損失を伴うファイルシステムの壊滅的な障害が登録されている」とマークされている場合 、それは（私の観点から）本番環境での作業の準備ができていませんが、必要な学生による使用には適しています1回または2回、持ち上げた浮浪者の仮想で何かを開始します。
これらの問題が発生する場合と発生しない場合があります。 いずれにせよ、「自然」に存在することは、それらに出会った人々によって確認されるためです。 あなたの環境がこれらの人々が使用する環境に十分近い場合、あなたは次の証人になるための正しい軌道に乗っています。
Dockerで発生する可能性のある最悪の事態は、通常、テストベンチでのテスト中にすべてが正常であり、実装後にすべての変更をプルアンドロールバックできない場合に問題が発生する可能性があることです。 。
Coreos
CoreOSは、コンテナの実行方法のみを知っているOSであり、コンテナの実行専用に設計されています。
前回の記事で、Dockerが正常に使用できるシステムはCoreOSのみであると結論付けました。 この記述は真実である場合とそうでない場合があります。
CoreOSを使用するというアイデアを放棄しました。
まず、Dockerの主な利点は、開発環境と実稼働環境の統合です。 コンテナの操作専用の本番環境に別のOSが存在すると、この点は完全に破壊されます。
第二に、Debian（私たちはDebianに座っていました）が2017年の第1四半期に次のメジャーリリースを発表しました。 現在のシステムを把握し、すべてをCoreOSに移植するには（成功を保証することなく）多くの労力を要するため、次のDebianリリースを待つことを決定する方が賢明でした。
CentOS / RHEL
CentOS / RHEL 6
CentOS / RHEL 6上のDocker-「機能しません。データがボリューム上で完全に失われるまで、ファイルシステムに既知の問題があります」
- devicemapperドライバーに関するさまざまな既知の問題。
- devicemapperと連動したLVMボリュームの重大な問題。データの破損、コンテナーのクラッシュ、Dockerデーモンのフリーズにつながり、ハードリセットが必要です。
- このディストリビューションでは、Dockerパッケージはサポートされていません。 CentOS / RHEL 7パッケージでリリースされたが、CentOS / RHEL 6パッケージに移植（バックポート）されていない重大なバグ修正が多数あります。
まだRHEL 6で作業している大企業でDockerに切り替える唯一の正しい方法は、それを行わないことです！
CentOS / RHEL 7
最初は、ブランチ3のコアで作業し、RedHatはブランチ4のコアからDockerを実行するために必要な機能をバックポートしました。
これにより、Dockerがカーネルのカスタムバージョンとカーネル内の必要な機能の存在を正しく判断できないため、問題が発生する場合があります。 その結果、Dockerは正しいシステム設定を設定できず、何度も何度もクラッシュします。 これが起こるたびに、これは特定の兆候によって特定のカーネルを検出する修正を公開するDocker開発者自身によってのみ解決でき、これらの修正の外観は時間的または体系的に保証されません。
OSバージョンに応じて、LVMボリュームの使用にはさまざまな問題があります。
さもなければ、それは幸運かどうかであり、あなたにとっての結果は私とは異なるかもしれません。
CentOS 7.0以降、RedHatはいくつかの設定を推奨していましたが、今ではWebサイトでこのページを見つけることができません。 いずれにせよ、それ以降のバージョンには多くの重要な修正があるため、常に最新バージョンにアップグレードする必要があります。
CentOS 7.2以降、RedHatはXFSのみを推奨およびサポートし、特別な構成フラグを設定します。 AUFSはもはや存在せず、OverlayFSは公式には不安定であると見なされ、BTRFSはベータステータスです（テクノロジープレビュー）。
RedHatの従業員は、Dockerが動作するための適切な条件を作成することは非常に困難であり、OpenShiftソリューションの一部としてDockerを再販するため、これは深刻な問題です。 不安定なコアで製品を作ってみてください！
あなたが火で遊ぶのが好きなら、このOSはあなたのためのようです！
これは、CentOSではなくRHELを使用したい場合に当てはまることに注意してください。タイムリーな更新と有用なサポートを自由に利用できるためです。
Debian
Debian 8 jessie（安定版）
遭遇した問題の主な理由は、前の記事で説明したように、本番環境でDebian（安定版）を使用したことです。
大ざっぱに言えば、DebianはDockerが必要とするものを何もサポートしていないバージョンでカーネルを凍結し、存在するいくつかのコンポーネントにはエラーが含まれています。
Debian上のDocker-深刻な「機能しません。AUFSドライバー（だけでなく）には多くの問題があり、通常はホストがクラッシュし、データを破壊する可能性があります。これは氷山の一角にすぎません。
Debian 8でDockerを使用することは、100％自殺行為であることが保証されており、数年前にDockerが作成されて以来です。 誰もこれを今日まで記録したことがないと思うのは私を殺します。
ドミノのように落ちるAWSインスタンスのグラフを表示したかったのですが、モニタリングとレンダリングに適したツールがないため、代わりに似たようなピアノ図を提供します。
テストシステムでの典型的なDockerカスケード障害。
テストシステムでの典型的なDockerカスケード障害：テストスレーブ障害...次のテストでは、2分で負荷を取得しようとします...また、この特定のカスケードは、問題を回避するために6回試行しました。
デッドホストを自動的に再起動して障害通知を送信するには、CloudWatchでアラームを設定する必要があります。
ちなみに、CloudWatchでアラームを設定して、5分以上問題がハングアップするたびに、既成の問題レポートをレギュレーターに自動的に送信することもできます。
私は自慢しませんが、Dockerをうまくサポートしました。 Chaos Monkeyを忘れてください、これは子供向けのゲームです。Dockerで数十億ドルを処理する取引システムを立ち上げてみてください[1]。
[1]これをしないでください。 これはひどい考えです！
Debian 9ストレッチ
Debianストレッチは2017年に安定する予定です（注：この記事を書いて編集している間はリリースになるはずでした）。
それにはコア4.10が含まれ、それまでに公開されたLTSの最後であることが判明しました。
リリース時には、Debian Stretchは最新の安定したオペレーティングシステムになり、Dockerの実行に必要なすべての優れた機能を備えていると主張します（もちろん、Dockerの要件が変更されるまで）。
彼は多くの問題を解決でき、大量の新しい問題を作成できます。 どうして
Ubuntu
Ubuntuは常に、通常のサーバーディストリビューションよりも新しいものです。
残念ながら、Ubuntuで働いている深刻な企業は知りません。 開発者やアマチュアブロガーは最新のUbuntu（LTS [2]さえ）ですべてをテストするため、これはDocker愛好家のコミュニティで大きな誤解の原因となっていますが、実世界（RHEL、CentOS、DebianまたはこれらのエキゾチックなUnix / BSD / Solarisの一部）。
このリリースを使用していないため、LTS 16の状況についてコメントすることはできません。 これは、Overlay2とZFSが利用できる唯一のディストリビューションです。これにより、検証のためのオプションがいくつか追加され、おそらく何か機能するでしょうか？
LTS 14のリリースは最終的な「適合しない」ものです。古すぎるため、必要なコンポーネントがありません 。
[2] Ubuntuの最新ベータ版を使用することを「ただ」とアドバイスする人々から、多くのコメントと非友好的な手紙を受け取りました。 すべての動作中のシステムの移行、配布キットの変更、およびテスト時にさえ存在しなかったベータプラットフォームへの切り替えは、合理的なソリューションです。
明確化：私が言ったように、私はDockerに戻らないので、リンクを検索して収集するのに1時間を費やしたくはありませんが、私はこれを行う必要があるようです。
私は明らかにアマチュアリーグにいる男からかなりrather辱的な手紙を受け取った。彼は「どんな馬鹿でもUbuntuでDockerを実行できる」と書いてから、UbuntuでDockerを実行するために必要なソフトウェアパッケージと高度なシステム設定の一覧に進むからだ、つまり おそらく「誰でもGoogleを使用して5秒で見つけることができます 。 」
彼のレポートは、 このバグレポートに基づいています。これは、「Ubuntu docker not working」および「Ubuntu docker crash」クエリに関するGoogleでの最初の結果 です。Ubuntu16.04は1.11.2でハングします 。
2016年6月に公開されたこのバグレポートは、 Dockerの実行に必要な依存関係の一部をインストールしないため、 Ubuntuのインストーラーは単にタスクをまったく実行しないことを強調しています。 #WONTFIXはDocker開発者からのたわごとです。
Dockerの従業員は5か月後に最後の答えを出し、Ubuntuのインストーラーは決して修正されないと書いていますが、Dockerの次のメジャーバージョンは他のコンポーネントを使用する可能性があるため、問題自体がなくなることはありません。
新しいバージョン（v1.13）が最近リリースされました-その回答の8か月後-同じエラーが表示されるかどうかはまだ確認されていませんが、古い設定を壊してDocker自体に新しい変更が含まれていることは確かです。
たいていの場合、Dockerに期待できることを背景にしています。 確認のためのチェックリストは次のとおりです。
- すべてが壊れているため、Dockerはまったく機能しませんか？ はい 。
- 大規模な配布など、すべてのユーザーにとって問題がありますか？ はい 。
- 問題の存在を確認する開発者からのタイムリーな応答がありますか？ いいえ 。
- 確認には、問題の存在の確認とその重大度の表示が含まれていますか？ いいえ 。
- 修正の予定はありますか？ いいえ 。
- さまざまなレベルの危険と複雑さで問題を回避する方法はたくさんありますか？ はい 。
- 問題は修正されますか？ 誰が知っている 。
- 修正が発生した場合、バックポートされますか？ 絶対に 。
- 「最新バージョンへのアップグレード」のヒントは、すべての問題報告に対する普遍的な答えですか？ もちろんです。
AWSコンテナサービス
AWSには、Dockerを起動するために特別に準備されたAMIがあります。 Ubuntuに基づいています。
内部ソースによると、AWSにはDockerが少なくとも何らかの形で非常にうまく機能することを保証する上で深刻な問題がありました。
その結果、AMIをリリースし、カスタムバグ修正とカスタムバックポートを備えたカスタムDockerパッケージでカスタムOSを構築しました。 そして卒業後、彼らはまだ多くの努力を費やし、すべてを連携させるための継続的なテストを行っています。
DockerにアタッチしてAWSで作業している場合、唯一の救いは、AWSの肩の上で彼と大騒ぎすることです。
Googleコンテナサービス
Googleはコンテナをサービスとして提供しています。 Googleは単にDockerインターフェースを提供し、コンテナーはGoogleの内部コンテナー化テクノロジーで実行されますが、Docker実装のすべての欠点に悩まされることはありません。
誤解しないでください！ コンテナは概念としては美しいものであり、問題は理論上ではなく、実用的な実装と、利用可能なツール（つまり、Docker）にあります。
Docker（またはコンテナ）で実際にプレイしたいがAWSで動作しない場合は、特にオーケストレーション用のKubernetesが付属しているため、Googleオプションが唯一の信頼できる選択肢になります。
このオプションはまだ実験的であると考えるべきであり、火のあるゲームと考えるべきです。 たまたま、Googleのソリューションが信頼できる唯一のソリューションであり、コンテナとオーケストレーションの両方が同時に存在する唯一のソリューションであることがわかりました。
オープンシフト
破損したコア上で安定した製品を構築することはできませんが、RedHatは試みています。
私が行ったレビューのうち、彼らはDockerの問題を軽減するために苦労しており、さまざまな程度の成功を収めています。 あなたの場合、結果は異なる場合があります。
後者のオプションはどちらも失うものがある大企業に焦点を合わせていることを考えると、そのような選択（つまり、Dockerの上に構築されたものを選択すること）の賢明さを本当に疑います。
「通常の」クラウドを使用することをお勧めします：AWS、Google、またはAzure。 仮想マシンに加えて、サービスプロバイダーが提供するサービスを使用すると、Dockerでできることの90％、Dockerでできないことの90％がプラスまたはマイナスになります。 これが最良の長期戦略です。
ほとんどの場合、あなたの場合、OpenShiftを起動したい理由は、パブリッククラウドを使用できないことです。 まあ、これは目標へのかなり難しい方法です！ （これで幸運。あなたの経験がどうであったかについてコメントを書いてください）
合計
- CentOS / RHEL：ロシアンルーレット。
- Debian：飛行機から裸で飛び出します。
- Ubuntu：
わからない 修正：笑。 CoreOS：努力する価値はありません。
- AWSコンテナ：DockerとAWSを同時に扱う必要がある場合の唯一の救い。
- Google Containers：Dockerを起動する唯一の実用的な方法は、完全に正気ではありません。
- OpenShift：わかりません。 サポートとエンジニアがどれだけうまく働くかによって異なります。
ビジネスの視点
Dockerにはビジネスモデルがなく、収益化できません。 公平に言えば、すべてのプラットフォーム（Mac / Windowsを含む）でリリースを行い、必死の試みであらゆる種類の機能（Swarm）を統合していることは言うに値します。1）競合他社に独特の機能を持たせないこと。 2）全員にDockerおよびDockerツールを使用させる。 3）お客様のエコシステムを完全に維持します。 4）その過程で大量のニュース、記事、問題を発表し、誇大宣伝を増やします。 5）独自の市場評価を正当化する。
いくつかの製品と市場で水平および垂直の両方に成長することは非常に困難です（このアプローチが合理的または持続可能なビジネスソリューションであるかどうかに関係なく、これは別の側面です）。
同時に、競合他社、つまりAmazon、Microsoft、Google、Pivotal、RedHatはさまざまな方法で競争し、コンテナでDocker自体よりも多くのお金を稼ぎますが、CoreOSはOS（CoreOS）と競合技術に取り組んでいますコンテナ化（ロケット）。
その結果、優れた火力を持つ多くの大規模な市場プレーヤーは、Dockerと積極的かつ断固として競争することを目指しています。 彼らは、Dockerに他の誰かを自分自身にバインドさせることにまったく関心がありません。 個人的にも集団的にも、彼らはDockerが死に、彼を別のものに置き換えることに興味を持っています。
それをコンテナ戦争と呼びます。 それが何につながるか見てみましょう。
現在はGoogleがリーダーであり、Dockerに取って代わり、すぐに使用できるオーケストレーション（ Kubernetes ）を提供できるのは彼らだけです。
おわりに
Dockerは不安定で、おもちゃのプロジェクトだと言いましたか？
もちろん、説明されている問題は存在しなかった、またはすでに過去にあったと誰かが言うでしょう。 それらは過去のものではなく、 問題は非常に関連性が高く、非常に現実的です。 Dockerは重大なエラーに悩まされており、これはすべての主要なディストリビューションでの使用に適さず、長年にわたって常に干渉するエラーであり、その一部は現在でもなお存在しています。
Googleで「Docker +バージョン+ファイルシステム+ OS」の特定の組み合わせの行を探すと、過去の任意の時点で、Dockerが生まれた瞬間まで、多くの問題へのリンクが見つかります。 何かが非常に抜本的であり、それについて誰も書いていないことは謎です（実際、いくつかの記事があり、広告と迅速な価値判断の塊の下で単に失われたことが判明しました）。 このレベルの期待とこのレベルの失敗を伴う最新のソフトウェアはMongoDBでした。
Dockerを真剣に、首尾よく、そして手間をかけずに使用する人は、地球上で誰も見つかりませんでした。 この記事で言及した経験は、Dockerを一生懸命勉強した従業員や企業の血によって得られましたが、ダウンタイムの1秒ごとに1,000ドルかかりました。
私たちが自分の過ちと他の人の過ちから学び、それらを繰り返さないことを願っています。
何年も前にDockerを使用する必要があるかどうか疑問に思っている場合=>答えは、「いや、撮影する必要はありません！」です。 これを上司に伝えることができます（今日でも、オーケストレーションがなければDockerのメリットはほとんどありません。それ自体は非常に実験的な質問です）。
現在Dockerを使用する必要があるかどうかに興味がある場合、ソフトウェアを実行する現在の方法はうまく機能しますが、作業の質に関して期待があります=>合理的な答えは 、RHEL 8およびDebian 10がリリースされるまで待つことです。運転しないでください。 物事は解決されるべきであり、パッケージは使用されるディストリビューションよりも速く開発されるべきではありません。
火で遊ぶのが好きな方は、Google CloudのGoogle Container Engineをご覧ください。 間違いなくリスクが高く、考えられる利点も高い。
多数のエラーレポート、カーネルパニックのスクリーンショット、日中のシステム障害の個人的な図、関連するフォーラムの投稿、およびこのトピックに関するプライベートな会話をリンクすると、この記事はより信頼できるでしょうか？ おそらく。
この情報を再び収集するのにさらに数百時間を費やしたいですか？ いや。 DockerよりもTinderで夜を過ごしたいです。 さようなら、Docker！
次は？
私に戻って。 私のコンテナおよびクラウド管理アクションプランには大きな欠陥がありました。ハイテク企業での平均滞在期間はまだ長い間測定されていないため、2017年は新しい場所に誘われたときに始まりました。
悪いニュース：雲がなく、Dockerが行きません。 技術革新のニュースはありません。 座って自分の仕事をします。
良いニュース：何十億ドルもの人と「遊ぶ」必要はありません...私は少なくとも3桁動いているからです！ これで、私の「サンドボックス」は、このブログを読んでいる人々の一部を含む、数百万人のアメリカ人の年金と連携します。
確認してください：あなたの年金は良い手にあります！