Docker 大規模プロジェクトのコンテナ化変革

仮想化とコンテナ化は、クラウドベースのプロジェクトでは避けられない 2 つの問題です。仮想化は純粋なプラットフォーム操作であるため、Linux オペレーティング システム上で実行されるプロジェクトを仮想化をサポートするために変更する必要はありません。プロジェクトでコンテナ化をサポートしたい場合は、詳細な変換作業を多数行う必要があります。仮想化に対するコンテナ化の利点も非常に明白です。ベアメタルで実行する場合のパフォーマンスが高く、数秒でコンテナを起動および停止できます。また、開発、テスト、デプロイメントのための一貫した環境 (DevOps コンセプト) や、前の記事で説明したマイクロサービス機能も備えています。コンテナ化（Docker）の知識を紹介する記事もいろいろあるので、ここでは詳しくは触れません。次に、コンテナ化変革が直面する課題と解決策をプロジェクトの実情を踏まえて紹介します。

数十万行の C++ コードと数十のアプリケーションを含む大規模なプロジェクトをコンテナ化します。元のコードの変更を最小限に抑える方法、またはコードを変更する必要性をまったくなくす方法。ビジネス プログラマーに気付かれずに静かに実行する方法。ビジネス画像のサイズを最小化する方法。ビジネスイメージを素早く作成する方法。これらは長い間私たちを悩ませてきた問題です。コンテナを分類する際に、コードの構成とアーキテクチャを調整する必要がある場合、数十万行のプロジェクトでは大惨事になります。変革後、開発モデルがあまりにも劇的に変化すると、数十人または数百人のビジネス プログラマーが必然的に再学習と適応のプロセスに直面することになり、莫大なコストがかかります。ビジネスイメージのサイズは、特にプロジェクトが海外にあり、ネットワーク速度がそれほど速くない場合、現場でのコンテナ更新の利便性に直接影響します。自動化された高速なイメージ作成は、アジャイル開発の鍵となります。

1. 始め方

Linux 上で実行されているプロジェクトをコンテナに移動する方法が、通常、最初に遭遇する問題です。インターネット上で、gcc コンパイラと Linux オペレーティング システムを含む基本イメージを見つけます。このイメージに基づいて、まずコンパイルと CI チェック (コード チェック、ユニット テストの実行など) 用のビルド イメージを作成できます。ビルド イメージをコンパイルと CI チェックに使用し、ベース イメージに基づいて実行イメージを作成し、コンパイルされたライブラリと実行可能プログラムをそのイメージにコピーします (Dockerfile 経由)。このような最もシンプルなイメージが作成されます。

上記の方法で作成したビジネス イメージは実行できますが、2 つの問題があります。作成時間が非常に長い (私たちのプロジェクトでは 1 時間かかります)、およびイメージのビジネス レイヤーが非常に大きい (私たちのプロジェクトでは 1G あります) ことです。これら 2 つの問題は特に深刻ではありませんが、プロジェクトを商業目的で使用する場合は非常に厄介になります。

2. コンテナのレイヤリング

コンテナの階層化の概念は Docker の中核となる概念であり、各コンテナが別のコンテナから「継承」できることをサポートしています。ここでの継承は、オブジェクト指向プログラミングにおける継承と同じ概念です。 「継承」機能の利点に加えて、基礎となるイメージが変更されても上位レベルのイメージを更新する必要がないため、更新する項目が大幅に減ります。本当に素晴らしいです。オブジェクト指向の継承がこんなに便利だとは思ってもいませんでした。この機能の影響を受けて、プロジェクトで使用されるサードパーティのライブラリを別のレイヤーに分離しました。下の図に示すように、生産プロセスもそれに応じて変化します。

工程は1つ増えますが、効果はすぐに現れます。ビジネスレイヤーの制作時間は1時間から12分に短縮され、サイズも100M程度にまで縮小されました。

3. ビジネスコンテナの分類

Docker のベスト プラクティスによれば、コンテナーでは 1 種類のプログラムまたは 1 つのカテゴリのプログラムのみを実行する必要があります。これまでと同様に、1 つのコンテナで数十のプロセスを実行することは決して適切ではありません。コンテナが明確に分類されると、さまざまな操作の管理や実行も容易になります。同時に、マイクロサービスのベストプラクティスでは、プロジェクトコードをマイクロサービスに分割することが推奨されています。各マイクロサービスのコードは異なるチームによって保守されており、互いに独立しています。現時点では、このアプローチの長所と短所については議論しません。元のプロジェクトは、数十万行、数十のプログラム、数十人の開発者、無数の共通モジュールを備えた大規模なプロジェクトであり、各モジュールが相互に参照し合うのが一般的でした。各プログラムは、さまざまな数のモジュールで構成されていました。 Docker のビジネス分類が上記の提案に従って実行されると、プロジェクトに大きな変化がもたらされ、組織構造に大きな調整が伴うことは間違いありませんが、これはほぼ不可能な作業です。では、元の開発モデルを変更せずにコンテナを分類するにはどうすればよいでしょうか?時には、新しいテクノロジーを進歩させる最善の方法は、変化を気づかれないようにすることです。

方法は実はとても簡単です。コンテナ内には、コンテナの起動後にどのプロセスを開始するかを管理する docker-entrypoint.sh というスクリプトがあります。上記のプロジェクト用に統一されたイメージを作成しました。分類する際には、異なるタイプのコンテナに応じて異なるタイプのプロセスを起動するために、異なる docker-entrypoint.sh を変更するだけで済みます。異なる環境変数、異なる設定ファイルなどを設定する必要があります。もちろん、すべて簡単です！

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。これについてもっと知りたい場合は、次のリンクをご覧ください。