コンテナー オーケストレーションが重要である理由

完了

このユニットでは、Tailspin チームが、マネージメントからの新しい指令に応えるための戦略を調べるのを見ていきます。 チームは、Kubernetes がマイクロサービス アーキテクチャへの移行にどのように役立つかを調べています。

将来はますます小さくなる

Tailspin の状況は上向きです。 最近の管理オフサイトで、Andy はチームの Azure DevOps に関する最近の成功について説明し、歓迎されました。 また、Andy は、チームの最近の Docker コンテナーを使用する概念実証プロジェクトのデモも行いました。 これらのデモからの流れで、組織の技術的な将来についての有意義な話し合いが行われました。 翌日、戻ってきた Andy は、Space Game Web チームにそのニュースを伝えます。

Andy: 昨日のオフサイト プレゼンテーションとてもうまくいったよ。 経営陣はこれまでの成果に満足していて、特命を与えられたんだ。

Tim: おやおや。 長年の経験から、それが罠なのは見え見えだな。

Andy: いいや、これはすばらしいチャンスだよ。 経営陣は Docker コンテナーのデモをとても気に入って、マイクロサービス アーキテクチャの採用について調べてほしいと言っているのさ。

Amita: マイクロサービスですか。 携帯電話や腕時計用のアプリのようなものなの。

Andy: いいや、マイクロサービスは Web アプリのような普通のアプリだよ。 主な違いは、単一のモノリシック アプリを構築してデプロイするのではなく、自律的なサービスにした方が保守も管理もしやすいコンポーネントをリファクタリングするんだ。 それから、サービスをビルドし、独立して動作するようにデプロイするのさ。

Tim: あまりいいもののようには思えないなあ。 僕はもう環境全体で多くのサービスを抱えているんだ。 これ以上増やしたくはないよ。

Andy: その心配はよくわかるよ。 ありがたいことに、特定の環境で多数のコンテナーを管理するための優れたツールがいくつもあるよ。 僕たちは、Kubernetes を使用して調整される Web アプリ用の複数コンテナー ソリューションを調べるように求められているんだ。 それと、DevOps プロセスに与える影響についても知りたがっている。

Mara: Kubernetes については読んだことがあるわ。 Azure の Azure Kubernetes Service でうまくサポートされているし、Azure DevOps にはそのためのパイプライン サポートがあるみたい。

Amita: このプロセスは複雑になりそうね。 テストにはどんな影響があるのかしら。

Mara: 大きな変更はないはずよ。 Kubernetes には、別の名前空間にデプロイする方法があるの。 それを使ってデプロイをパーティション分割すると、テストや運用のために専用の環境をそっくり用意できるわ。 それらはみんな同じクラスターで実行されて、同じコンテナーを使用するから、運用環境で想定しているものがテスト エクスペリエンスでも提供されるはずよ。

Amita: どの環境がどこにあるのか追跡するのが難しくないかしら。

Mara: いいえ、Azure DevOps 環境を使用してそのすべてを実行できるわ。 各サービスがどこにあって、ポータルでそこに行くにはどうすればいいかがわかるの。 パイプラインですべて自動化されているので、手作業で追跡する必要はないわ。 今私が気になっているのは、これを構築するときに開発エクスペリエンスにどの程度の影響があるかということだけね。

Andy: ありがたいことに、影響は最小限だよ。 Docker コンテナーを構築するようにプロジェクトを設定したとして、Kubernetes にデプロイする必要があるのは、サービスとそのデプロイが記述されているマニフェスト ファイルだけだよ。

Mara: 2 番目のコンテナーとして何をリファクタリングするか考えてみたことはあるの。 Web API でランキングを利用できるようにしてほしいと言ってきているチームがいくつもあるわ。

Andy: 僕は君より一歩先を行っているよ。 昨夜、Docker プロジェクトをフォークして、ランキング データ機能を専用のマイクロサービスにリファクタリングしたのさ。 これで、Web サイト用の 1 つのコンテナーと、ランキング API 用に別のコンテナーが手元にある。 どちらのコンテナーにも独自のパブリック エンドポイントが構成されていて、サイトや API を使いたい人がいれば、アプリで使われているテクノロジ スタックが何であっても、そのエンドポイントを共有できるよ。 どちらかの負荷が大幅に増えた場合は、コンテナーを個別にスケーリングできるのさ。

Mara: これはとても素晴らしいプロジェクトみたい。 さっそく、リリース パイプラインの更新に取りかかりましょう。

Kubernetes とは

Kubernetes は、コンテナー化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースのコンテナー オーケストレーション プラットフォームです。 これは、宣言型で応答性の高い方法で分散システムを実行するためのフレームワークを提供し、複数のホスト間でコンテナーを実行できるため、リソースの効率的な使用と信頼性の向上が実現されます。

Tailspin チームは、次のすべてのニーズを満たしたため、このシナリオに Kubernetes を選択しました。

  • 複数コンテナーのデプロイの複雑さ: Kubernetes は、コンテナーのデプロイの実施と保守に関するプロセスを自動化することを最優先に設計されています。

  • 環境間およびステージ間の一貫性: コンテナーによりそれに含まれるアプリの一貫性のあるデプロイが保証されるのと同じように、Kubernetes を使用すると、クラスターによって管理されるコンテナーの一貫したデプロイが保証されます。

  • Azure DevOps サポート: Azure DevOps により、Kubernetes を使用するためのファーストクラスのサポートが提供されます。

  • 開発の容易さ: ソース プロジェクトへの Kubernetes の影響は、Docker のサポートを追加する場合と同程度であり、最小限で、宣言型の構成に限定されます。

Kubernetes を導入すると、複数の Docker コンテナーを使用するマイクロサービス アーキテクチャの導入プロセスが大幅に簡素化されます。

自分の知識をチェックする

1.

マイクロサービスを使用する理由として適切でないのは、次のうちどれですか?

2.

Docker と Kubernetes の類似点は何ですか?

3.

あなたのチームは、複数の Docker コンテナーを生成するソリューションで、複数の .NET Core プロジェクトを使用しているとします。 Kubernetes のサポートを追加するために必要なオーバーヘッドはどれくらいですか?