コンテナは本当に万能なのでしょうか?これを読んだらあなたは黙ってしまうでしょう

マクリーン氏がコンテナを発明したとき、彼はおそらくこの輸送手段が経済のグローバル化を促進するとは考えていなかっただろう。大量の商品を梱包して列車、船、飛行機に積み込む場合、コンテナは積載が遅い、容量が小さいなどの問題を解決するだけでなく、輸送時間を数か月から数日に短縮します。もちろん、商品の多様性とその特定の用途を考慮すると、コンテナは万能薬ではありません。これはコンテナのようなものです。開発者のアプリケーションを Linux プラットフォーム上でパッケージ化して公開することは、あまり利益を生むものではありません。また、導入コスト、運用環境、セキュリティなどの問題も発生します。

2013 年 3 月、PaaS サービス プロバイダーの dotCloud (後の Docker) は、アプリケーション コンテナー エンジン Docker をオープンソース化し、コードを Github でホストしました。これに先立ち、コンテナ技術は Linux および UNIX 分野で 10 年以上の変化を経てきました。技術的な観点から見ると、Docker はサンドボックス メカニズムに基づいて、あらゆるアプリケーションを軽量で移植可能な標準化されたコンテナーに統合できます。中心的な課題は、Linux コンテナ テクノロジを使用して仮想マシンと同様の機能を実現することです。しかし、コンテナが称賛される一方で、この技術の弱点にも注意を払う必要があります。

コンテナにはコストがかかる

コンテナは万能のソリューションではないため、ユーザーは対応する専門知識を持ち、インフラストラクチャの整合性を確保する必要があります。しっかりした基礎があって初めて家を建てることができます。コンテナのデプロイメントを継続的デリバリー パイプラインに統合して自動化するには、コードが送信されるたびに、コード リポジトリへの手動チェックイン操作を含む一連の手順を実行する必要があります。簡単に言えば、パイプラインの役割は、コンテナが内部で機能テストを受け、テストに合格できるようにすることです。この期間中に実行が遅れると、継続性が失われ、問題を発見する機会を逃し、後で修正するためにさらに多くの労力が必要になります。覚えておいてください。バグは、コード送信後数分以内に報告された方が、数週間後に発見された場合よりも修正コストがはるかに安くなります。

Docker はコードを書き換えるのではなく、クロスプラットフォームの展開を容易にするだけであることに注意してください。スケーラビリティが必要な場合、それを実現できるかどうかは開発者自身にかかっています。 Docker はすべてのシステムに適用されるわけではありません。結局のところ、システム レベルでのソフトウェアのドッキングは、貨物を積み込むために船を停止するほど単純ではありません。システムをまたぐ場合は、まず Docker 自身のカーネルが最新であり、基礎となるレイヤーがユニバーサルであることを確認する必要があります。たとえエラー率が最小であっても、数万台のサーバーに拡大すると大きなリスクになります。同時に、コンテナの大規模な運用には管理とオーケストレーションのサポートが必要となり、これもまた投資費用となります。

コンテナは仮想マシンではない

コンテナを仮想マシンの観点から見ないでください。これらは自由に編集または削除できるオブジェクトではありません。問題が発生した場合、それらを破棄して新しいものを再構築するしかありません。一部の開発者は、コンテナの実行中にコンテナの内容 (構成ファイル情報など) が変更されたが、変更に問題があるため、コンテナを閉じた後に起動できないという問題に遭遇する場合があります。これを行うには、開発者は新しいイメージを作成するか、ファイルを直接変更することしかできません。

さらに、Docker のリソース分離レベルは仮想マシンほど高くありません。共有できるのは一部のリソースのみであり、他のプロセスはキューに入れる必要があります。コンテナはカーネル レベルでも共有されるため、環境によっては高い効率性が犠牲になりますが、可用性と冗長性も影響を受けます。独立したカーネルを持つ仮想マシンとは異なり、コンテナ カーネルが破損すると、その共有メカニズムによって、関連付けられているすべてのコンテナに影響が及ぶことになります。

生産環境の欠陥

成熟した企業は、登場してからわずか 2 年しか経っていないデータベース テクノロジーを使用するでしょうか?さらに、Docker は単なるツールであり、アーキテクチャソリューションではありません。前述したように、コンテナをデプロイするには、イメージ管理、ログ記録、監視、負荷分散など、プロセス全体のサポートが必要です。さらに、アップグレード後の前方互換性も低いため、大規模なアプリケーションのイメージを作成する場合はもちろん、実稼働環境でのコンテナの弱点にもつながります。独自の本番環境を構築するユーザーの中には、Docker を IaaS 上に配置しますが、その場合、リソース消費がコンテナ インスタンスの要件を超える可能性があります。ネットワーク層では、パブリックネットワークからすべてのコンテナにアクセスできるわけではないため、ネットワークを設定する際にはより注意を払う必要があります。ホストにパッチを適用するのは一般的なことです。

デプロイメント プロセス中、Docker Compose は他のツールよりも本番環境での構成が複雑です。ボリュームのバインド、ポートのドッキング、ネットワーク パラメータはすべて変更する必要があり、多くのスクリプトと外部データベース ツールを呼び出す必要があります。データベース管理を例に挙げてみましょう。開発環境はコンテナ間でホストできますが、運用環境では、高可用性と信頼性の高いバックアップおよびストレージを確保するために、I/O パフォーマンスなどの問題を考慮する必要があります。能力が高ければ高いほど、注意すべきポイントも多くなります。コンテナはパッケージを開発環境から本番環境に直接移動できますが、本番環境ではまだ改善が必要な領域が残っています。

コンテナはセキュリティから切り離せない

コンテナをめぐるセキュリティ論争は止むことはありません。リスクは内側から外側へ発生します。ハッカーはコンテナをクラックすることで基盤となるサーバーにアクセスし、クラウド サービス プロバイダーのデータ センターに影響を与える可能性があります。一方、ミラーソースが異なると、脅威を予測することが難しくなります。データによれば、Docker Hub のコンテナ イメージの 30% 以上に高リスクの脆弱性があり、これらのイメージは頻繁にダウンロードされています。この時点で、コンテナはパンドラの箱のようなもので、中に何が入っているかわかりません。

規制の観点から見ると、コンテナ アプリ ストアは良いアイデアかもしれません。実際、多くのサービス プロバイダーは、脆弱性が発生するまで、コンテナーに問題があることさえ認識していません。一般的に、ユーザーは使い慣れたサービスプロバイダーを選択し、長期間更新されていないコンテナーを避ける必要があります。プロバイダーとしては、コードの品質を管理し、定期的な「身体検査」を実施することしかできません。

結論

今後、コンテナ開発においては、最先端技術、コミュニティエコロジー、企業支援の3つが大きな基盤となるでしょう。クラウドコンテナ化はトレンドとなっているが、実際の適用プロセスでは、コンテナの初期導入時に不安定な要素を回避し、商品価値を最大化するために、自社のビジネス特性に基づいた判断を行う必要がある。