Docker: 人々が後悔する賭け

【編集後記】Docker には利点もありますが、その裏には無理な設計も数多く存在します。この記事の目的は、Docker のさまざまな欠点を説明し、関連する証拠を指摘することです。

Docker を批判するたびに、怒りの反応をたくさん受け取ります。 6 か月前に「なぜ大きなバイナリではなく Docker を選ぶのか?」という記事を書きましたが、Hacker News での激しい批判の中でようやく、いくつかの賢明なコメントを目にすることができました。したがって、本日の記事は主に、Docker の設計上の欠陥をさらに説明し、将来直面する可能性のある批判に応えることを目的としています。

[[229318]]

HFT Guy の経験と比べると、私は十分幸運だと思います。 HFT Guy 氏はかつて、金融会社の製品の製造段階で Docker を使用したことで失敗に終わり、大きな代償を払わなければならなかったことに怒りを表明したことがある。原文を引用すると次のようになります。

明らかにアマチュアコミュニティのメンバーである人物から、非常に失礼なメールを受け取りました。「UbuntuでDockerを実行するのはバカだけだ」と男性はメールで怒って書いた。メールには、Ubuntu 上で Docker を実行するために必要なソフトウェアパッケージと高度なシステム調整のリストも含まれていました。さらに、メールには「誰でも Google を通じて 5 秒以内にリスト内の関連コンテンツを見つけることができます」と明記されていました。

人々はオンラインで怒りをぶちまける傾向があります。理由は分かりませんが、それは事実です。そして、開発者は、自分たちが愛するテクノロジーを誰かが攻撃しているのを見ると、反撃し、言葉の戦いを引き起こす傾向があります。しかし、この否定的な感情は、実用面における関連ソリューションの長期的な重要性を彼らに認識させません。

Docker は、移植性、セキュリティ、リソース管理、オーケストレーション機能を提供することを約束します。したがって、理性的な人は当然、「Docker は本当に移植性、セキュリティ、リソース管理、オーケストレーション機能を実現する最良の方法なのか?」と知りたいと思うでしょう。

その前に、私が受け取ったいくつかの回答に返答したいと思います。ほとんどの回答は議論する価値のない点を指摘していますが、1 つの議論が私の注意を引きました。これについては、この記事の最後で詳しく説明します。

以下のようなコメントがあります。

Docker を使用すると、必要なリソースが少なくなり、関連するリソースを処理する必要があるかどうかやユーザーの既存の処理能力に依存しなくなるためです。

はい。しかし、参照するものは何でしょうか?ビルド、デプロイメント、オーケストレーション、リソースの使用を標準化するためのスクリプトを開発者に作成させることでしょうか?上記のコメントは、「結果がすでにあるから開発者がこれらの操作を選択すべきだと言っているのではなく、標準化すべきだと言っているのです」と言っているようです。

開発者や管理者が Docker を好むのは、カスタマイズが制限され、混乱が少なく、寿命が長く、標準化が進んでいる、あるいは少なくともこれらの効果を実現する機会があるからです。しかし、現実には、Docker はこれまでのところ信じられないほどの混乱をもたらしただけです (詳細については、「Docker の運用: 失敗の歴史」を参照してください)。それにもかかわらず、Docker の現在の問題はすぐに解決され、Docker はコンテナ化シナリオに対して安定した一貫した標準を提供できると信じている人はまだたくさんいます。これは間違いなく Docker に関する大きな賭けです。この「賭け」に参加したほぼすべての企業が大きな代償を払ってきたが、いつか大きな利益を得られることを期待して、この賭けに賭け続ける企業もまだある。

過去 2 年間に私が仕事をしたすべての企業は、Docker を使用しているか、使用する予定です。実際には、これらの企業は標準化されたソリューションに高額を支払っています。

さらに恐ろしいのは、この「ギャンブル」の現実をテクノロジーマネージャーが明確に述べるのをまだ聞いたことがないことです。 Docker をサポートするグループのほとんどは、その移植性、セキュリティ、オーケストレーション、構成機能を重視し続けています。はい、Docker は確かに移植性、セキュリティ、オーケストレーション、構成機能を提供しますが、そのコストも相当なものになります。ほとんどの場合、特定のスクリプトを記述する方が簡単です。

私が Docker に関する最高の記事だと考える記事の中で、著者は Docker を使用することのトレードオフを強調しています。

Docker は高レベルの最適化ソリューションとして考えるのが最適です。確かに、Docker はクールで強力ですが、システムの複雑さも増します。Docker を本番環境で安全に使用し、ミッションクリティカルなシステムに導入する方法を理解できるのは、プロのシステム管理者だけです。

現状では、Docker を使用するには、さらにシステムの専門知識が必要です。実際、Docker 関連の記事のほとんどは、過度に単純化されたユースケースのみを示しており、マルチホストの本番システムで Docker を使用する複雑さと課題は無視されています。これにより、Docker の実際の運用アプリケーションは非常にシンプルで簡単であるという非常に誤った印象が人々に与えられることは間違いありません。

コンピュータプログラミングの分野には、「時期尚早な最適化は諸悪の根源である」という有名な格言があります。しかし、今年はほとんどのお客様が「最初からすべてを Docker 化する必要がある」と主張しています。そのため、実用的なシステムを構築し、それを本番環境に導入し、最終的に Docker が比較優位をもたらすかどうかを検討するという従来の初期のベストプラクティスとは異なり、顧客は Docker の標準化された開発と展開を盲目的に推進し始めました。

おそらく皆さんの多くは、次のようなシナリオに遭遇したことがあるでしょう。

私: 「プロジェクトのこの早い段階では Docker を使う必要はありません。」
相手：「このアプリケーションには、Nginx、PostGres、Redis、および多数の環境変数が必要です。Docker なしでこれらを設定するにはどうすればいいですか?」
私: 「Bash スクリプトを書いたり、make を使用したり、他のタイプのインストーラーを使用したりできます。選択肢はたくさんあり、何年も前から存在しています。」
もう一人の人: 「これはおかしいですね。Bash スクリプトは壊れる可能性があり、デバッグに時間を費やす必要があります。また、コンテナと比較すると、他のマシンでは必ずしも機能しません。Docker を使用すると、ビルドスクリプトを記述して、どのマシンでも実行できることを保証できます。」

これは明らかに典型的な営業担当者のシナリオであり、彼らは Docker の最も魅力的な機能だけを強調します。開発ツールとしては、Docker は他のオプションよりも一貫性が高く、混乱が少ないようです。しかし、実際の使用、特に本番環境では、Docker は多くの場合、苦痛をもたらすだけです。

開発チームには、Windows マシンを使用する開発者が 1 人、Mac ユーザーが 1 人、Ubuntu をインストールした開発者が 1 人、Red Hat Linux を使用する開発者が 1 人いる場合があります。チームリーダーにとって、チームが使用するマシンを完全に制御することはほぼ不可能な作業です。一見すると、Docker はすべてのプラットフォームで同じ開発環境を保証するように見えます。 (ただし、Windows 環境では Docker を決して使用してはならないことをここで述べておく必要があります。Docker を使用すると Windows マシンの開発プロセスが簡素化されると主張する人は、あなたを騙そうとしているのです。)

しかし、実際の運用では、運用環境で実行されているマシンを完全に制御できます。 CentOS で標準化したいのであれば、それはまったく問題ありません。何千台もの CentOS サーバーを管理し、Puppet などの従来のテクノロジーを使用して、すべてのサーバーで同じオペレーティング環境を確保できます。これは、Docker が言われているほど重要ではないことを意味します。対照的に、Docker を使用して開発する場合、開発者は実際の運用環境も Docker で構築されると想定する傾向がありますが、これは当てはまりません。

Docker の問題に関する実際の例をもっと挙げることもできますが、これらはかなり退屈です。 Docker の設計上の欠陥について議論するブログ投稿は数多くあり、異論をすべて無視する熱狂的な Docker ファンでない限り、あなたもそのことを聞いたことがあると思います。こうした友人たちは、そのような記事を単に無視するか、しぶしぶ読んだ後に「Docker エコシステムは急速に成熟しており、来年までには実際の運用に適した安定した状態になると思います」と言うでしょう。このような言葉は過去5年間毎年登場しています。確かに、そのような発言は最終的には現実になるかもしれないが、最初に戻って考えてみると、それは危険な賭けだ。

これらの問題にもかかわらず、Docker は成功しているようで、私たちが協力しているほぼすべての企業が Docker の導入に熱心になっています。なぜ？私の知る限り、標準化が最も重要な理由です。

再び、Hacker News の記事へのコメントで、ユーザー「friend-monoid」が Docker について次のようにコメントしました。

さまざまな言語で書かれた HTTP サービスが多数あります。これらすべてを [スーパー] バイナリで管理するのは大変な作業でした。作成者はポートとリッスンアドレスを設定するためのスキームを提供する必要があり、私はポートを設定するすべての方法を追跡する必要がありました。 Docker は、ネット名前空間とよりスマートな iptables ルーティングを使用してこのタスクを実行するのに役立ちます。

ネットユーザーのnotyourdayさんは、私の心を本当に動かすような反応をくれた。

もちろん、他の方法を使用して同じ書き方とルールに従えば、同じ効果を得ることができます。実際、後者の方が、よりスマートな名前空間と iptables を提供し、アプリケーションの動作状態を完全に無視することもできるため、より優れている可能性があります。

ネットユーザーのanilakarさんはnotyourdayにこう返信した。

これが、Docker スキルの移転可能性の核心だと私は考えています。つまり、このようにして、新しく採用された人々はすぐに新しい仕事を始めることができるのです。多くの企業は、基本的なビジネスニーズには十分対応できるビルド/デプロイメントシステムを依然として使用していますが、企業外でも継続的に機能する実用的なエクスペリエンスを提供できていません。

私の知る限り、これは Docker の本当の利点をほぼ要約したものです。そうです、Docker の利点は、アプリケーションの展開、セキュリティ、オーケストレーションが容易になるということではありません。これはまったくのナンセンスです。実際、Docker が標準になった唯一の理由は、人々がある会社で学んだことを別の会社に適用できるようにするためでした。 Docker は、カスタム Bash スクリプトよりも煩雑さが少なく、独自性も低いです。しかし、すべてを危険にさらす価値はあるのでしょうか?

しかし、正直に言うと、上記の議論は実際にはコンテナ技術と Docker を混同していると思います。そして、かなりの数の Docker 支持者がこの問題を故意に混同しています。コンテナ技術自体は確かに先進的な概念ですが、単一の企業によって管理されているDockerには、必然的に特定の問題があります。 HTF Guy の意見を続けましょう。

Docker にはビジネスモデルがなく、収益化できません。公平に言えば、Docker, Inc. は、次のことを必死になって試みて、これをすべてのプラットフォーム (Mac/Windows) に展開し、すべての機能を無理やりまとめています (Swarm)。1) 競合他社に大きな独自性がないことを確認する。 2) 全員が Docker と Docker ツールを使用するようにする。 3) 顧客を自社のエコシステムに完全に閉じ込める4) その過程で多くのニュース、記事、報道を生み出し、誇大宣伝を高める。 5) 評価を正当化する。

Docker を複数の製品や市場に水平方向および垂直方向に拡張することはほぼ不可能です。（このような拡大が適切または持続可能なビジネス上の決定であるかどうかは、別の機会に議論する別のトピックです。）

一方、Amazon、Microsoft、Google、Pivotal、Red Hat などのライバルはさまざまな方法で競争しており、Docker よりもはるかに多くの収益をコンテナから得ています。実際、CoreOS もオペレーティングシステムを開発しており、Rocket コンテナ化テクノロジで競合しています。

したがって、コンテナ技術に含まれる巨大な力を認識し、それがもたらす構成の一貫性機能を高く評価したとしても、Docker 自体の基盤が不安定であるという事実は変わりません。

さて、ここでは Docker とコンテナを一時的に同じものとみなします。この観点から、私の過去の記事を見直し、どの批判が依然として現実に当てはまるかを見てみましょう。

前回の記事では「大きなバイナリファイル」という用語を誤って使用したため、多くの誤解を招いてしまいました。数時間後、私は次の免責事項を投稿しました。

この投稿では、「大きなバイナリ」という用語を、すべての依存関係を含むバイナリの意味で使用します。 32 ビットから 64 ビットへの移行全体を意味しているわけではありません。 Java と JVM の領域にのみ焦点を当てる場合は、「uberjar」という用語を使用します。しかし、私がそれを使用しなかった理由は、認識に値する Go 言語とそのエコシステムを私の声明に含めたかったからです。

もう一度やり直す必要がある場合、私は間違いなく「スーパーバイナリ」という用語を使用します。これは主に JVM 分野での私の個人的な作業を表していますが、その意味は比較的正確です。これが私が思いつく最良の表現方法なので、この記事の残りの部分では代わりに「スーパーバイナリ」という用語を使用することにします。

開発者が、自分たちが好むコンピュータープログラミング方法がクラウド分散コンピューティングシステムには適さない可能性があることを認識してくれることを願っています。ここでこの点を何度も強調したいと思いますが、多くの開発者は、クラウドコンピューティングシステムが、自分が記述する PHP コード、Ruby コード、または Python コードにますます適応する必要があるとすでに感じていると思いますが、コードレベルではこの新しい世界に適応することは決してありません。

新しいプロジェクトを開始し、その規模が拡大すると予想される場合 (スケーラビリティを考慮する必要があるため、または単に高可用性を重視するためなど)、クラウド向けに設計された最新の言語を使用できます。現在、多くの新しい言語がこれまでにない新鮮な機能を提供できます。私が個人的に使用し、深い印象を残したのは Go と Clojure です。個人的には Rust、Scala、Kotlin の経験があまりないので、あまり議論できません。もちろん、それらも非常に優れているはずです (以前の記事では、多くの読者が私が意図的にいくつかの言語を無視したと考えました。私はこれらの言語を意図的に侮辱しているわけではありませんが、私の個人的な経験の限界により、実際に使用したソリューションについてのみ言及します)。私は Scala Akka フレームワークに関する記事をいくつか読みましたが、そこには多くの非常に興味深いアイデアが含まれていることがわかりました。そのため、実際に使用したことはないのですが、デザインレベルは非常に高く、モダン感に溢れていると思います。

以前の記事で、ネットユーザーのbtownはこう書いています。

現代の Web アプリケーションはすべて Golang または JVM で記述されていると考えている人は、奇妙な自己認識のループに陥っています。

繰り返しになりますが、世の中には本当に素晴らしい言語がたくさんあります。しかし、すべてを知ることは不可能なので、私が個人的に遭遇したいくつかのものについてのみコメントすることができます。私はこれまで使ってきた古い言語、つまり PHP、Ruby、最近人気の Python についても批判しています。これらは古いパラダイムから来ているため、クラウド内のマイクロサービスや分散アーキテクチャには適していません。これについては、Docker が私たちが離れるべきプログラミングパラダイムを保護しているという記事で説明しました。今のところ、この問題を真剣に受け止めている人は誰もいないようです。 2000 年頃にオブジェクト指向プログラミングの流行がピークに達したことを覚えています。当時、このモデルに敢えて反対する者はほとんどいませんでした。テクノロジー業界はこれまで完全にオープンであると信じてきましたが、現実にはさまざまな推進要因がまだ満ち溢れています。その後数年で参加者全員が撤退し、混乱と傍観者の嘲笑を残した。この記事の主題に沿って言えば、XML とオブジェクト指向プログラミングは 2000 年に過剰宣伝され、Docker も現在同じ状態にあります。

私は Clojure をよく使用していますが、アプリケーションの作成や依存関係をバンドルする uberjar の作成に適しているようです。また、Jenkins のようなシステムを設定して、Clojure ビルドを完全に自動化する方法も知っています。多くの企業が、外部依存関係のないアプリケーションを構築し、データベースなどを uberjar にバンドルするという、非常に極端な方法を採用していると聞きました。「Clojure と AWS を使用して 7 か月で 600 倍の成長を達成」の記事を参照してください。

これが2番目の決定につながりました。データセットのサイズが小さいため、コンテンツデータベース全体を 1 つのリリースに追加することができました。はい、その通りです。私たちは Solr の組み込みインスタンスを使用してソフトウェアを構築し、ホテルの在庫管理用の標準化されたクリーンな非リレーショナルデータベースを採用し、それをすべてアプリケーションデプロイメントに組み込みました。

私たちはこの型破りなアプローチから多大な利益を得ました。まず、コードとデータの不一致という大きな障害点を排除しました。ソフトウェアのどのバージョンでも、何年も後に別のシステムに移行し、その間にコンテンツデータベースにさまざまな変更を加えたとしても、正常に動作します。この場合、さまざまな環境への展開と構成管理が非常に簡単になります。

次に、ユーザー向けレイヤーで水平シェアードナッシングのスケーラビリティを実現します。その拡張機能は非常に印象的です。

この大規模な拡張が新しいテクノロジー (Docker など) を導入せずに達成できるのであれば、そうする必要はまったくありません。最も簡単な方法で問題を解決することが、私たちが守るべき原則です。 Ruby/Python/Perl から新しい言語とエコシステムに移行することで、より少ないテクノロジーと可動部分で拡張できるのであれば、そうすべきであり、そうしなければなりません。繰り返しになりますが、原則は可能な限り最も簡単な方法で目標を達成することであり、ほとんどの場合、これは使用するテクノロジの数を最小限に抑えることを意味します。 Rich Hickey に触発されて、私は「シンプル」と「簡単」を区別しています。すでに知っている言語を使うのは「簡単」ですが、新しい言語を学ぶのは難しいです。ただし、後者の方が「簡単」であり、システム内のテクノロジーの量が減ります。ここでの「シンプル」とは、コードサイズが小さくなり、構成がシンプルになり、使用するテクノロジが少なくなり、システムが最終的によりシンプルに動作することを意味します。

以前の記事のコメントでは、私が Jenkins について頻繁に言及していることは私の考え方が時代遅れであることを示していると多くの読者が考えていましたが、時には退屈なことが必ずしも悪いわけではないことを認めなければなりません。

退屈であること（制限レベルが高いこと）の利点は、これらのものの機能が比較的理解しやすいことです。しかし、もっと重要なのは、その障害モードをより簡単に理解できることです。 …しかし、新しいテクノロジーには未知の部分の方がはるかに多いことを覚えておくことが重要です。

言い換えれば、10 年間使用されているソフトウェアは理解しやすく、不明な点も少なくなります。未知数が少ないということは、運用上のオーバーヘッドが低くなるということであり、これは決して悪いことではありません。

多くの開発者が非常に強い偏見を持っていることに気づきました。こうした記事を読むと、一つの理由をつかんで記事全体を反論する傾向があります。したがって、私が Jenkins、Ansible、Go、Clojure、Kotlin、Akka などの技術的ソリューションについて言及すると、記事自体の価値を下げるために、これらのテクノロジーの欠陥を見つけることに重点が置かれます。免責事項を追加する以外に、このグループの読者と本当にコミュニケーションをとる方法がわかりません。実際、免責事項を追加したとしても、聞きたくない読者はやはり聞かないと思います。

以前の記事で、ネットユーザーのtytsoはこう書いている。

Go が大規模バイナリの先駆者であるという主張は明らかに誤りです。何十年もの間、人々はこの問題を解決するために静的バイナリ（場合によっては組み込みデータリソース付き）を使用してきました。 MacOS はその代表例の一つです。

ここで、わかりにくい表現がありましたことをお詫び申し上げます。私が実際に言いたいのは、すべての依存関係、すべての必要な構成、さらにはすべての必要なリソースを同じバイナリファイルに入れて、システムリソースメカニズム全体を簡素化することです。この方法は、単に静的ライブラリにリンクするよりも概念的に広範囲にわたります。最新の継続的インテグレーションシステムは、各バイナリに特定の構成が確実に与えられるように構成することができ、この構成情報はバイナリの特定のインスタンスに固有のものである場合があります。したがって、同じアプリケーションのインスタンスを何千も同時に実行する必要がある場合でも、わずかに異なる構成を持つインスタンスのバリアントを何千も構築できます。もちろん、Jenkins のような比較的古いビルドシステムを使用してこのタスクを実行することもできます。これらのシステムは理解しやすいですが、その一方で非常に退屈でもあります。しかし、退屈さが Docker を選択する理由であってはなりません。Docker は、困難な複雑な課題をもたらす可能性があります。 (もちろん、ここでは Jenkins を例として使用しているという事実にとらわれないでください。好みに応じて Travis、TeamCity、または Bamboo を選択することもできます。ソリューションの選択によって、多くの開発者が記事に同意することをあきらめたり、記事全体を読むことさえ諦めてしまうことに、私はしばしば驚かされます。)

読者の中にはこう言う人もいました。

Docker は、クラウドサービスプロバイダーのロックイン問題からユーザーを保護します。

もちろん違います。 DevOps ツールの標準化された展開は、ベンダーロックインの問題を解決するのに役立ちます。そして、この種のツールには多くのオプションがあります。

ユーザー friend-monoid は次のように書きました:

同僚がアプリケーションを適切に展開する方法を理解する必要がなければ、彼らの仕事は大幅に簡素化されます。言語やスタイルの影響を受けずに彼らの作品をコンテナに収めることができれば、私の仕事は大幅に簡素化されます。クラッシュ、無限ループ、その他のコードエラーに対処する必要はなくなりました。

ネットユーザーnotyourdayからの反応は私の考えと一致しています。

もちろん、このロジックを「オーケストレーション」および「管理」レイヤーに移動したからです。正しく実行するには、まだコードを記述する必要があります。豚に口紅を塗っても、豚は豚のままです。

さらに、小規模な会社で開発者が合計で数人しかいない場合は、必然的に互いのコードの結果を処理することになります。大企業であれば、開発チームとは別に DevOps チームがあり、さまざまなヘルスチェックソリューションの使用を含め、長年にわたってこれらの問題に注力してきました。ヘルスチェックにはコードの記述も含まれますが、これは Docker の標準化された範囲ではカバーされていません。アプリケーション開発者は、定期的なテストのために DevOps に 200 の応答を送信するための対応するエンドポイントを作成する必要があります。この場合、Docker はあまり役に立ちません。ほとんどの DevOps チームには、アプリケーションアクティビティをテストするスクリプトがあり、ターゲットアプリケーションが応答しない場合は、アプリケーションを終了して再起動します。

ネットユーザーのラザールさんはこう書いている。

たとえば、Ruby、PHP、Node.js などのスクリプト言語を使用して、古いスクリプトモデルに基づく既存のコードベースを構築しています。

既存のコードをすべて Docker コンテナにパッケージ化し、いくつかのオーケストレーションソリューションと組み合わせてリリースする方法を考えることができます。

この記事によると、著者は（スーパー）バイナリの方が優れていると考えていることがわかりました。しかし、PHP アプリケーションを Docker 化することは可能であり、難しいことではありません。しかし、どうやって（スーパー）バイナリを構築するのでしょうか？答えが「コードベース全体を Golang で書き直す」である場合、それは無意味です。私たちにはそれを実行するためのリソースがありませんし、たとえあったとしても、そのような費用対効果の低いアプローチを取るつもりはありません。最後に、私たちは Golang 言語があまり好きではありません。

この場合、同社は長い間 PHP アプリケーションを使用しており、そのアプリケーションを Docker 化することが目標でした。なぜこのような結論に至ったのですか?このアプリケーションを Docker 化する必要が生じた原因は何でしたか?これは不自然な例のように感じます。 Docker 化前、アプリケーションはどのように動作していましたか?従来のアプローチの問題は何でしたか? Docker はこれらの問題を解決できると思いますか?

このアプリケーションの最終的な目標は、他のアプリケーション (またはそれ自体の更新バージョン) と連携して調整できるようにすることですか? Docker とオーケストレーションを組み合わせると、通常は Docker と Kubernetes を組み合わせることになります。 (もちろん、Kubernetes の代わりに Mesos や Nomad を使用することもできます)。これは非常に複雑なオプションの組み合わせであり、企業はこの道を選ぶ前に慎重に検討する必要があります。「K8s は複雑すぎるか？」を参照してください。アプリケーションが小さい場合は、全体を書き直すのが実際には良い選択です。アプリケーションが大きい場合は、Chef または Ansible スクリプトを作成するなど、他のより簡単な実装方法があるかどうかを検討する必要があります。

かつて、Symfony フレームワークを使用して PHP で書かれた大規模なモノリシックアプリケーションに出会ったことがあります。アプリはひどいパフォーマンスの問題が発生していました。私たちは、HTML テンプレートのレンダリングのための Symfony 部分はそのままにして、パフォーマンスを本当に決定する部分を他の言語で書き直すなど、少しずつ分解し始めました。これについては、すでに私の記事「小規模アプリケーションのアーキテクチャ上の問題」で述べました。当時、DevOps チームはデプロイメントを処理するために Puppet といくつかのカスタムスクリプトを使用していました。私たちにとってはそれで十分です。退屈だが安定した技術で、本当にうまく機能します。

覚えておいてください、あなたの時間は限られています。 PHP コードの Docker 化にどれだけ時間を費やしても、その時間は奪われてしまいます。つまり、その時間を他のモダナイゼーションの取り組みに使うことができないのです。したがって、投資によって目に見える利益が得られるかどうかを確認してください。

奇妙なのは、Docker について議論するときに、実際にオーケストレーションが必要なアプリケーションの例を挙げないことが多いことです。私は、Nomad を使用してオーケストレーションされた、Spark 上で長時間実行されるデータ分析スクリプトを見たことがあります。これは、毎日テラバイト単位のデータが Kafka、Apache Storm、そして最後に ElasticSearch に追加される大規模なシステムであることに気づきました。システムには高度なヘルスチェックと監視機能が備わっていますが、ほとんどのジョブでは Storm 自体が適切なオーケストレーションツールになります。 Web アプリケーションでは、大量のデータを処理する前に、多数のビジネスプロセスを処理する必要があります。 Twitter は膨大な量のデータを抱えており、そのオーケストレーションには Aurora を使用しています。あなたはTwitterと同じくらい大きいですか？通常の Web サイトに Docker と Kubernetes を使用している場合は、今すぐやめてください。Web サイトを実行するには、もっと簡単な方法があります。私は 25 年間 Web サイトを構築してきましたが、信じてください、ほとんどの Web サイトでは Docker は必要ありません。

ユーザー mwcampbell は次のように書いています:

「古い技術を使い続けるために多大な労力を費やすという考えにはまったく賛成できません。」

私はこの部分に強く反対します。テクノロジーと文明を真に進歩させるには、既存のソリューションを再発明して時間を無駄にしないようにする必要があります。言い換えれば、古いテクノロジーを使い続ける必要があります。したがって、Docker が 2007 年に書かれた Rails アプリを動作させることができれば、それは素晴らしいことです。実際、Rails、Django、PHP などを使用して新しいアプリケーションを開発する必要があります。これらのツールが流行らなくなったとしても、すでに非常に成熟したこれらのプラットフォームとツールを使用する理由はまだあります。

「ヒップスター」という言葉を聞くと、テクノロジーの世界で広まっている誤解を思い出します。盲目的にトレンドを追いかけるのはやめられないでしょうか?たとえば、テクノロジーとポップカルチャーを混同することは、ロック音楽の黄金時代の音楽はすべて不要になったと仮定するようなものです。逆に言えば、優れたテクノロジーはポップミュージックではありません。 1993 年にうまくいったことは、今日のシナリオでもまだうまくいく可能性があります。

これは明らかに皮肉を意図したコメントです。もちろん、すべてを Docker 化すべきだと考える冷静な現実主義者もいますが、古い DevOps ツールを使い続けて新しい言語と組み合わせるべきだと考える私のような変な人もいます。彼らの見方では、私の選択は「流行」によって動かされたのに対し、Docker に対する彼らの愛は「技術と文明を本当に進歩させよう」という大きな願望によって動かされたものでした。

私の考えでは、古くて退屈なテクノロジーが、設計された目的を果たし、それを使い続けることで追加のコストが発生しない限り、使い続けるべきです。しかし、テクノロジーの運用方法に大きな変化があった場合、特定のテクノロジーが新しい環境のニーズに適応しなくなったかどうかを自問する必要があります。具体的には、クラウドコンピューティングとクラウド環境におけるマイクロサービスアーキテクチャの台頭により、テクノロジソリューションの選択を再考する必要があります。指針となる原則は、「現在の目標を達成するための最も簡単な方法は何か」です。古い技術で目的を達成でき、しかもそれが最も簡単な方法であるなら、それが最良の選択であるはずです。しかし、新しいテクノロジーがシステムの簡素化に役立つのであれば、この新しいソリューションを積極的に採用すべきです。

ネットユーザーのchmikeさんはこう書いている。

コンテナは依存関係のソリューションであるだけでなく、効果的な境界保護ソリューションでもあります。

ネットユーザーのニール・ウィルソンはこう反応した。

これは、chroot の単なる派手で強化されたバージョンです。 Docker に関する誇大宣伝をすべて信じないでください。賢明な管理者は何年も同じようなことをやっていますが、PR プロモーションに大金を費やすことはありません。

これも私の個人的な意見です。

この記事の前半で、「外部依存関係のない巨大なバイナリを使用しないのはなぜですか?」と質問しました。「それが Docker の機能です。アプリケーションの実行に必要なものがすべて含まれた 1 つの大きなバイナリです。言語に依存しません。Ruby、PHP、Python、Java、Haskell など、あらゆるもので使用できます。」と答えるかもしれません。

それは本当ですが、企業は使用するテクノロジーソリューションの数を減らす機会を探すことをお勧めします。おそらく、最新の言語とエコシステムを活用して、このスーパーバイナリ設計をネイティブな方法で実装できるでしょう。

Docker の反対派が Docker を批判するのは、企業内のテクノロジーソリューションを変更する能力がないからだ、と多くの人が考えています。しかし、私たちの想定では、企業は実際にはクラウドでの分散コンピューティングには適さないレガシーテクノロジを含む、異種テクノロジの組み合わせを独自に使用しています。したがって、Docker は実際には一種の「不可視呪文」であり、その実際の機能は、企業が独自の言語とエコシステムを調整してクラウド分散コンピューティングアーキテクチャに適応できないという実際の問題を隠すことです。

長期的には、改善を拒否することでビジネスが破滅する可能性があります。私は、最新のテクノロジーのトレンドを盲目的に追い求めることを推奨しているわけではありませんが、企業自体にとって最も有益な技術的成果を常に再評価することは支持しています。現在、コンピューティングの全体的な実装は変化しており、従来のアプリケーションを受動的に受け入れることは、最終的には企業にとっての悩みの種となり、時間の経過とともに企業の発展を遅らせることになります。従来のアプリケーションが実行できなくなった場合、それを書き直すと企業にとってより大きなリスクが生じます。企業が既存のアプリケーションをバンドル解除して最新化する方法を見つけることができれば素晴らしいでしょう。実際、マイクロサービスアーキテクチャの最も重要な機能は、レガシーアプリケーションを段階的に最新化できることです。これについては、すでに私の記事「漸進的改善のサンゴ礁モデル」で説明しました。

先ほど、毎日 TB 単位のデータを Kafka に追加し、それを Apache Storm に配信し、最終的に ElasticSearch に配信する必要のある分析会社について説明しました。同社では長年にわたりPythonを使用してきました。パフォーマンスの問題が発生すると、システム内で大規模な同時実行を実現するために、Tornado などの Python 同時実行システムの使用を検討します。彼らは、非常に才能のあるエンジニア（以前はインテルで働いていた）にプロジェクトを任せ、新しいシステムの構築に 3 か月を与えました。結果は完全な失敗でした。彼らは望んでいたパフォーマンスの改善を得ることができず、竜巻は予想していた微調整された並行性と同時性のレベルさえもたらすことさえできませんでした。最後に、彼らはあらゆるレベルでPythonに固執することができないという現実を受け入れました。今、彼らは行ってエリクサーになり、これが問題の本当の解決策であることを認めています。（会社は少し傷ついたと確信しています - 彼らは本当のパイソンのサポーターであり、多くの理想主義者でした。）

彼らが取っている再評価のアプローチに感謝していますが、企業はこれを事業に組み込み、定期的に実行する必要があると思います。

Netizen PmoriartyからのDockerを支持する最も強力な議論は次のとおりです。

すべての構成管理ツール（Ansible/Chef/Salt/Cfengine/Puppet）についてほぼ同じ批判を作成できます。それらはすべて、あなたがそれが機能するときに満足することができる大きな混乱ですが、そうでないときはひどい悪夢をもたらすことができます。

これらのツールはすべて、少なくとも数十年かかり、完全に成熟します。

はい、その通りです。

WordPressを実行するためのレシピが必要ですか？ Ansibleはそれを提供できます。 Dockerもそうです。 Dockerは、Drupal、MySQL、または他の無数のタスクを実行するときにもそのようなヘルプを提供できます。 Dockerは、少なくともDevOpsに一般的に必要なデフォルトを提供することに関しては、かなり良い仕事をします。

シェフやAnsibleが成熟していれば、今日、Dockerについてこのような熱烈な議論はありませんでした。私の知る限り、スタートアップは2013年にシェフのためのフレームワークの構築に焦点を当てていました（彼らは、独自のフレームワークがDevOpsスペースのレールでRubyになることを望んでいました）。彼らはいくつかの問題に遭遇し、その過程で他のより収益性の高い開発の方向性を発見しました。最終的に、彼らは気を散らされ、失敗しました。それにもかかわらず、彼らの未完成の仕事はいつか成功するかもしれません。このようなフレームワークには、Dockerのような基礎となるオペレーティングシステムを完全にカバーすることなく、オペレーティングシステム機能に直接依存するという利点があります。

シェフとAnsibleは、すべての潜在的なマシンタイプとすべての一般的なDevOpsタスクに対して何千ものスクリプトを約束しています。どちらもコミットメントを完全に満たしていないことは明らかです。 2005年には、すべてのビジネスには、社内のすべてのDevOpsタスクのカスタマイズされたスクリプトを作成するDevOpsの人がいます。これは非常に正常と思われます。ただし、2010年までに、より集中した通常のタスクスクリプトライブラリが表示されることは明らかです。これは、Perl CPANライブラリよりも具体的であり、リソース管理とオーケストレーションレベル（携帯性を達成するため）およびセキュリティの問題での一貫性の問題に細心の注意を払う必要があります。また、シェフがすぐに飛んだのはこの時代から、その後、その後追いつき、数年後にDockerも多くのことに追いつきました。多くの開発者は、Dockerが最終的にシェフとAnsibleが長い間約束してきたが、達成できなかったという効果をもたらすと信じています。しかし、長い間、Dockerは内部開発作業にのみ適しています。 2015年まで、生産環境でDockerを使用することはまだ自殺のようでした。 2016年でさえ、Dockerを使用して生産システムをサポートしようとしている企業は、依然として痛みの束縛に直面しています。そして、これはすべて過去1年間で大幅に改善されていません。

私の意見では、Dockerはいつか大きな間違いとして特徴付けられるでしょう。最も強い議論は、最終的にそれが標準になり、最終的には発展し、成熟したとしても、Dockerは、テクノロジー業界で現在遭遇しているさまざまな困難に対する「バンドエイド」にすぎないということです。根本原因を治す能力がないため、Dockerの運命は良い結果をもたらすことはできません。

5年後には、雲の分散コンピューティングを標準化するために、それほど複雑ではない方法が見えると思われます。この推測を目撃してください。もちろん、今のところ、Dockerはまだどこにでもあり、非常に人気があります。

<<: エッジコンピューティングにより集中型ソフトウェア制御がユビキタス化

>>: クラウドコンピューティングは AI を民主化するための鍵となるのでしょうか?