コンテナーが重要な理由
このユニットでは、DevOps プロセスに対して強く求められるいくつかの改善について Tailspin チームが話し合うのを見ていきます。 このシナリオでは、チームは Docker を使用して Web アプリケーションをコンテナー化します。 次に、チームはそれをサポートするように CI/CD パイプラインを更新します。
大変な数週間
Tailspin にとって、これまでの数週間は困難な期間でした。 各チームはさまざまな理由で期限を守るのに苦労しており、会社全体の生産性について懸念があります。 Andy は、経営陣に対する今度のプレゼンテーションのためのフィードバックを収集するために、Space Game Web サイトのチームから何人かの主要な利害関係者を招集しました。
Andy: お立ち寄りいただき感謝します。 ここ数週間は全員が大変だったことと思いますが、いくつか良いニュースがあります。 経営陣により、パフォーマンスを改善するために加えることができる変更についての提案を聞くためのオフサイトが明日開かれます。 彼らは私たちの DevOps の成功に関するケース スタディを提示するために私を招待しており、他にもアイデアがあれば耳を傾けると言っていました。 私はこのミーティングを、ブレーンストーミングの機会として使用できることを期待していました。 誰から始めますか?
皆が Amita を見ました。 彼女は最近特にイライラしていました。
Amita: 私から始めましょう。 ご存じのように、私は複数のチームのテストを行っていますが、チームごとに独自のテクノロジ スタックが使われているので、それが困難になる場合があります。 .NET や Java のような同じ基盤プラットフォームを使っていても、ターゲット バージョンが異なることがよくあります。 テストする必要があるコードを各チームが実行できる状態にテスト環境を設定するだけで、その日の半分を消費することもあるような気がします。 何かがうまくいかない場合、コードにバグがあるのか、それとも私が間違ってバージョン 4.3.2 ではなく 4.2.3 を構成したのか、判別するのは困難です。
"Andy は、ホワイトボードに「QA の依存関係のバージョン管理に関する課題」と書き込みました。"
Tim: そのストレスに、運用も加えたいと思います。 独自のバージョン要件を持つチームがいくつかあります。そのため、各自のバージョンとコンポーネントの要件が私たちの他のアプリと競合しないようにするために、各チームのアプリを独自の仮想マシンに発行する必要があります。 追加の VM セットを維持するためのオーバーヘッドが発生するだけでなく、それらのアプリをサイド バイ サイドで実行できる場合よりもコストが高くなります。
"Andy は、ホワイトボードに「VM によってアプリの分離を解決することによるオーバーヘッド」と書き込みました。"
Mara: 開発側からも問題があります。 数週間前、私はピアツーピア更新システムに取り組んでいて、すべてを自分のコンピューター上で動作させていました。 しかし、デプロイのためにそれをハンドオフしたとき、運用環境では動作しませんでした。 私はサービスの一部としてポート 315 を開く必要があったことを忘れていたのです。 何が起こっていたかを把握するのに、丸一日以上トラブルシューティングする必要がありました。 運用環境でそれを開いた後は、想定どおりに動作しました。
"Andy は、ホワイトボードに「デプロイ ステージ間における構成の不整合」と書き込みました。"
Andy: この会話は良いスタートだと思います。 これらの問題を調査して、何ができるかを確かめたいと思います。 私が聞いた懸念事項は次のとおりです。
- QA の依存関係のバージョン管理に関する課題
- VM によってアプリの分離を解決することによるオーバーヘッド
- デプロイ ステージ間の構成の不整合
すべてを (1 つのコンテナーに) まとめて配置する
翌日の朝、Andy はチームに新しいアイデアを知らせるためにミーティングを開きました。
Andy: 私たちが直面している課題について、昨日何人かの同僚と話したのですが、いくつかの興味深い提案がありました。 試してみたくてワクワクしているのは、Docker です。 これは、アプリケーション全体をコンテナーとしてパッケージ化するためのテクノロジです。
Amita: コンテナーとは何ですか。 .zip ファイルのようなものですか。
Andy: 少し違います。 それは、ホスト オペレーティング システム上で直接実行するように設計された軽量の仮想マシンのようなものです。 プロジェクトをビルドすると、ソフトウェアとその依存関係を含むコンテナーが出力されます。 ただし、完全な仮想化システムではないため、1 秒も経たないうちに処理が開始します。
Tim: セキュリティと分離はどのように処理されますか。
Andy: セキュリティと分離は、ホスト オペレーティング システムによって処理されます。 コンテナーがホスト プロセスで実行されている場合、そのコンテナーは同じホスト コンピューター上の他のプロセスから分離されます。 この分離により、そのコンテナーは、他のコンテナーが何を実行しているかに関係なく、必要などんなバージョンのコンポーネントでも読み込むことができます。 またこれは、同じホスト上で複数のコンテナーを同時に実行できることも意味しています。
Amita: それは運用環境にとってはすばらしいことのようですが、パイプラインの早い段階で直面している課題は解決されるのでしょうか。
Andy: もちろんです。 ソース コードや一連のバイナリを配布する代わりに、コンテナー全体が成果物になります。 つまり、Mara が開発を行うときは、彼女のコンピューター上でホストされているコンテナーに対して、ローカルでデバッグ セッションを実行します。 Amita がテストを行うときは、必要なすべてのバージョンの依存関係が既に含まれている、その同じコンテナーのコピーに対してテストを行います。 Tim が運用環境を管理する場合、彼が監視するコンテナーは、Mara によって開発され、Amita によってテストされたのと同じコンテナーのスタンドアロンのコピーです。
Mara: コンテナー アプリケーションを開発するのはどのくらい大変ですか。 既存のコードに大幅な変更を加える必要がありますか。
Andy: コンテナーは、どちらかといえばパッケージ化とデプロイに関するテクノロジです。 私たちが作成している基本的なソフトウェアには影響しません。 ビルドの最後に、Docker コンテナーを生成するようにツールに指示するだけです。 その後、デバッグするときは、ローカル Web サーバーではなく、そのローカル コンテナーからアプリケーションが実行されます。 実際、Visual Studio のようなツールを使用すると、Docker や IIS Express などのデバッグ環境を切り替えて、必要な柔軟性を得ることすらできます。 このプロセスをテストするために、昨晩、Web サイト プロジェクトを実際にフォークして、Docker コンテナーとしてビルドするように変換しました。 いくつかの基本的なコンテナー構成を追加する必要があっただけでした。既存のコードを変更する必要はありませんでした。
Mara: それはすばらしいですね。 フォークから Azure Pipelines のリリース パイプラインを更新して、Docker バージョンをビルドしてデプロイすることもできるはずです。
Andy: 同じことを考えていました。
Docker とは
Docker は、移植可能な独立型のコンテナーのパッケージ化とデプロイを自動化するためのテクノロジです。 Docker コンテナーは、開発マシン、部門サーバー、エンタープライズ データセンター、クラウドなど、Docker ホストがある場所ならどこでも実行できます。 Azure には、App Service や、Kubernetes などのオーケストレーション テクノロジで管理されるクラスターの一部としての実行など、コンテナーベースのアプリケーションを実行するための複数の方法が用意されています。
Tailspin チームはこのシナリオのために Docker コンテナーを選択しました。これが彼らのすべてのニーズを満たしているためです。
QA の依存関係のバージョン管理に関する課題: アプリケーションは、適切なバージョンの依存関係が備わったコンテナーとしてパッケージ化されます。
VM によってアプリの分離を解決することによるオーバーヘッド: 多くの分離されたコンテナーを同じホスト上で実行することができ、起動時間の短縮やリソース効率の向上など、仮想マシンよりも優れた利点があります。
DevOps ステージ間の構成の不整合: コンテナーには、公開する必要があるポートといった構成要件を自動化するマニフェストが付属しています。
Docker コンテナーの採用は、マイクロサービス アーキテクチャを実現するための重要なステップとなる可能性があります。 詳細については、後で説明します。