コンテナーが重要なのはなぜですか?

このユニットでは、Tailspin チームに従って、DevOps プロセスに必要な改善点について説明します。 このシナリオでは、チームは Docker を使用して Web アプリケーションをコンテナー化します。 その後、チームは CI/CD パイプラインを更新してサポートします。

辛い数週間が経過しました

ここ数週間は、Tailspin では困難な時期でした。 チームはさまざまな理由で期限を迎えるのに苦労しており、会社全体の生産性に懸念が生じていました。 Andy は、Space Game Web サイト チームの主要な利害関係者を呼び出して、今後の経営陣へのプレゼンテーションに関するフィードバックを収集しました。

アンディ： お立ち寄りいただき、ありがとうございます。 私は最後の数週間はすべての人のために荒れている知っているが、私はいくつかの良い知らせを持っている。 経営陣は、パフォーマンスを向上させるために行うことができる変更に関する提案を聞くために、明日オフサイトを開催しています。 彼らは、DevOps の成功に関するケース スタディを紹介するように私を招待し、他のアイデアにも開かれていると言いました。 この会議をブレーンストーミングの機会として利用できることを期待していました。 誰が最初に行きたいですか?

全員が Amita を見る。 彼女は最近特に不満を抱いてきました.

Amita: 私は最初に行きます。 ご存知のように、私は複数のチームをテストしますが、各チームが独自のテクノロジ スタックを使用しているため、難しい場合があります。 .NET や Java などの同じ基になるプラットフォームを使用する場合でも、多くの場合、異なるバージョンを対象とします。 1 日の半分は、テストする必要があるコードを実行できる状態でテスト環境を取得するだけで済む場合もあるような気がします。 何かが機能しない場合、コードにバグがあるかどうか、または誤ってバージョン 4.2.3 を 4.3.2 ではなく構成したかどうかを判断するのは困難です。

Andy は、ホワイトボードに "QA の依存関係のバージョン管理の課題" を書き込みます。

Tim:そのストレスに、運用も加えたいと思います。 固有のバージョン要件を持つチームがいくつかあります。そのため、バージョンとコンポーネントの要件が他のアプリと競合しないように、独自の仮想マシンにアプリを公開する必要があります。 VM の追加セットの維持に伴うオーバーヘッドに加えて、これらのアプリが並行して実行できる場合よりもコストがかかります。

Andy はホワイトボードに「VM によるアプリの分離を解決するためのオーバーヘッド」と書き込みます。

マラ： 開発側からの情報があります。 数週間前、私はピアツーピア更新システムで作業していて、すべて自分のマシンで動作していました。 しかし、デプロイのために渡したとき、運用環境では機能しませんでした。 私はサービスの一部としてポート315を開く必要があることを忘れていた。 何が起こっているのかを理解するために、1 日以上のトラブルシューティングが必要でした。 運用環境でオープンすると、物事は期待どおりに機能しました。

Andy は、ホワイトボードに "デプロイ ステージ間の構成の不整合" と書き込みます。

アンディ： この会話は良いスタートだと思います。 私はこれらの問題を調査し、私が思い付くことができるものを見てみましょう。 私が聞いた懸念は次のとおりです。

• QA の依存関係のバージョン管理の課題
• VM を使用したアプリの分離の解決によるオーバーヘッド
• デプロイ ステージ間の構成の不整合

すべてをまとめる (1 つのコンテナー内)

次の朝、Andy は会議を呼び出して、チームに新しいアイデアを提示します。

アンディ： 昨日、私たちが直面している課題について何人かの同僚と話しましたが、彼らはいくつかの興味深い提案をしました。 私が試してみるのを楽しみにしているのが Docker です。 これは、アプリケーション全体をコンテナーとしてパッケージ化するためのテクノロジです。

Amita: コンテナーとは それは .zip ファイルのようなものですか?

アンディ： 全くそういうわけではありません。 これは、ホスト オペレーティング システム上で直接実行するように設計された軽量の仮想マシンに似ています。 プロジェクトをビルドすると、出力はソフトウェアとその依存関係を含むコンテナーになります。 ただし、完全な仮想化システムではないため、1 秒未満で起動できます。

ティム： セキュリティと分離はどのように処理されますか?

アンディ： セキュリティと分離は、ホスト オペレーティング システムによって処理されます。 コンテナーがホスト プロセスで実行されている場合、コンテナーはその同じホスト コンピューター上の他のプロセスから分離されます。 この分離により、コンテナーは、他のコンテナーの実行に関係なく、必要なバージョンのコンポーネントを読み込むことができます。 また、同じホスト上で複数のコンテナーを同時に簡単に実行できることも意味します。

Amita: これは運用環境にとって素晴らしいことですが、パイプラインで以前に直面している課題は解決されますか?

アンディ： そうですよ！ ソース コードまたはバイナリのセットを配布する代わりに、コンテナー全体が成果物になります。 つまり、Mara の開発時に、自分のコンピューターでホストされているコンテナーに対してデバッグ セッションがローカルで実行されます。 Amita がテストするとき、同じコンテナーのコピーに対してテストします。このコンテナーには、必要なすべてのバージョンの依存関係が既に含まれています。 Tim が運用環境を管理する場合、監視するコンテナーは Mara によって開発され、Amita によってテストされたのと同じコンテナーのスタンドアロン コピーです。

マラ： コンテナー アプリケーションの開発はどのくらい難しいですか? 既存のコードに大きな変更を加える必要がありますか?

アンディ： コンテナは、パッケージングとデプロイメントのための技術です。 これらは、私たちが書いている基本的なソフトウェアには影響しません。 ビルドの最後に Docker コンテナーを生成するようにツールに指示するだけです。 その後、デバッグすると、アプリケーションはローカル Web サーバーではなく、そのローカル コンテナーから実行されます。 実際、Visual Studio などのツールでは、Docker や IIS Express などのデバッグ環境を切り替えて、必要な柔軟性を提供することもできます。 昨夜私は実際に Webサイトプロジェクトをフォークし、テストのために Dockerコンテナとしてビルドするように変換しました。 基本的なコンテナー構成を追加するだけで済んだ。既存のコードを変更する必要はありませんでした。

マラ： それを聞いて嬉しいです。 Docker バージョンをビルドしてデプロイするために、フォークから Azure Pipelines のリリース パイプラインを更新することもできます。

アンディ： あなたは私の心を読んだ。

Docker とは

Docker は、移植可能で自己十分なコンテナーのパッケージ化とデプロイを自動化するためのテクノロジです。 Docker コンテナーは、開発用マシン、部門別サーバー、エンタープライズ データセンター、クラウドのいずれの場合でも、Docker ホストが見つかった場所であればどこでも実行できます。 Azure には、App Service や Kubernetes などのオーケストレーション テクノロジで管理されるクラスターの一部として、コンテナー ベースのアプリケーションを実行する複数の方法が用意されています。

Tailspin チームは、すべてのニーズを満たしているため、このシナリオで Docker コンテナーを選択しました。

• QA の依存関係のバージョン管理の課題: アプリケーションは、適切なバージョンの依存関係を持つコンテナーとしてパッケージ化されます。

• VM でのアプリの分離を解決するためのオーバーヘッド: 多くの分離されたコンテナーは、仮想マシンよりも優れた利点を持つ同じホスト上で実行できます。これには、リソース効率の向上のための起動時間の短縮が含まれます。

• DevOps ステージ間の構成の不整合: コンテナーには、公開する必要があるポートなど、構成要件を自動化するマニフェストが付属しています。

Docker コンテナーの導入は、マイクロサービス アーキテクチャの重要なステップになる可能性があります。 これについては後で詳しく説明します。