Environ の例

このページでは、Environ を使用するサンプル シナリオを例にして、ガイドのコンセプトとベスト プラクティスをいくつか紹介します。このガイドでは、Environ の概要Environ の要件とベスト プラクティスを読み、コンセプトを理解していることを前提としています。

例 1: Environ で本番環境、ステージング環境、開発環境のリソースを使用する

最初の例では 4 つのクラスタがあります。2 つのクラスタは本番環境用(冗長性のために 2 つのリージョンに配置)、1 つはステージングとテスト用、1 つは開発用です。すべてのクラスタがプラットフォーム チームによって所有、管理されています。この簡単な例では、frontendbackend の 2 つのサービスを使用していますが、より複雑なシナリオでは、サービスとクラスタの数が多くなります。

本番環境、ステージング環境、開発環境のリソースを使用するシステムの図
本番環境、ステージング環境、開発環境のリソースを使用するシステム

アプローチ 1: 本番環境、ステージング、開発の Environ を分離する

1 つのアプローチとして、本番環境、ステージング、開発用のリソースに独自の Environ を作成する方法があります。

この場合、3 つの Environ ホスト プロジェクトを作成し、これらのプロジェクトにリソースを配置します。オンプレミス開発クラスタの場合は、クラスタを example-dev プロジェクトに登録します。この例では、名前空間やサービスの同一性の問題に対処する必要はありませんが、prod-east クラスタと prod-west クラスタの名前空間が適切に正規化されている必要があります。

このアプローチの利点は、両方の Environ 間に強固な分離があることです。その反面、3 つの異なる Environ を管理しなければならないため、本番環境、ステージング環境、開発環境で一貫性を持たせることが難しくなります。開発チームから見ると、ステージング サービスの開発が難しくなります。

本番環境、ステージング環境、開発環境のリソースに個別の Environ を作成した場合の図
本番環境、ステージング環境、開発環境のリソースに個別の Environ を作成

アプローチ 2: すべてのリソースに 1 つの Environ を作成する

このアプローチでは、すべてのリソースに対して 1 つの Environ を作成します。

この場合、example プロジェクトにリソースを残し、そのプロジェクトの Environ を作成します。本番環境とステージング環境のリソースを別々の Environ ホスト プロジェクトに配置し、共有 VPC を利用することもできますが、説明を簡単にするため、この方法は選択しません。

このアプローチでは、Environ 全体で名前空間とサービスが正規化されている必要があります。たとえば、本番環境のクラスタとステージング環境のクラスタのそれぞれで、汎用の frontendfrontend-prodfrontend-staging という名前に変更しています。開発用の名前空間の元の名前をそのまま維持することも可能ですが、開発環境の名前空間であることを示すため、より明確な名前(frontend-dev-alice など)を使用します。

このアプローチでは、管理の容易さと分離がトレードオフになります。不要なサービス間通信を防ぐためにサービス メッシュの承認を使用していますが、この 1 つの Environ を使用してシステム全体を簡単に管理できます。このように配置することで、すべてのリソースにポリシーを適用できるようになり、開発環境と本番環境を近いものにすることができます。

本番環境、ステージング環境、開発環境のリソースを 1 つの Environ に配置した場合の図
本番環境、ステージング環境、開発環境のリソースを 1 つの Environ に配置

アプローチ 3: 本番環境と非本番環境で Environ を分離する

このアプローチは前の 2 つの折衷案で、ステージング環境と開発環境のリソースを非本番環境の Environ に統合し、本番環境を別の Environ に配置します。

この場合、2 つの Environ ホスト プロジェクトを作成し、1 つを本番環境に、もう 1 つを非本番環境に使用します。また、これらのプロジェクトにリソースを直接配置し、オンプレミスの dev クラスタを非本番環境の Environ に登録します。明確にするため、ステージング環境と開発環境のリソースの間で名前空間とサービスを正規化する必要があります。たとえば、ステージング環境のクラスタで frontend の名前を frontend-staging に変更します。

このアプローチの利点は、本番環境が非本番環境から分離されている点です。たとえば、開発サービスを有効にしてステージング サービスと通信できるようにすることで、サービスの開発中に、デベロッパー(Alice)の frontend がステージングされた backend と通信できるようになります。

本番環境の Environ と非本番環境の Environ を表す図
本番環境の Environ と非本番環境の Environ

まとめ

例 1 で説明したアプローチはいずれも有効な方法です。組織でどのアプローチを選択するかは、分離と整合性(管理の容易性)、つまり、リソースタイプ間で必要な分離の度合いとリソースタイプ間で必要な整合性の程度によって決まります。Environ の数を少なくすると、整合性が高くなります。3 番目の方法は中間的なアプローチですが、本番環境を完全に分離しながら、デベロッパーがステージング サービスを操作できます。

例 2: リソース オーナーが異なる Environ を使用する

この例では、team-a と team-b という 2 つのチームがあります。これらのチームは独自のクラスタを所有し、管理しています。どちらのサービスも、作成するサービスの名前空間として frontendbackend を使用しています。ただし、team-a の frontendbackend は、team-b のものと同じではありません。2 つのチームは、お互いのサービス間でやり取りができるように、サービス メッシュを作成したいと考えています。

2 つのチームのリソースが存在するシステムの図
2 つのチームのリソースが 1 つのシステムに存在している

このままでは、これらのクラスタを同じメッシュの一部にすることはできません。手始めに、一元化されたプラットフォーム チームにクラスタの所有権を移行し、それらのクラスタ間の信頼関係を確立することをおすすめします。team-a と team-b が相互に信頼している場合は、その信頼関係を調整することもできます。次に、この 2 つのチームのクラスタで frontendbackend がオーバーロードされないように、名前空間の使用を正規化します。これにより、すべてのリソースに対して単一の Environ を確立し、サービス メッシュを作成できます。

1 つの Environ に存在する 2 つのチームのリソースを表す図
1 つの Environ に 2 つのチームのリソースが存在する

このレベルの信頼関係を確立できない場合は、異なる Environ ホスト プロジェクトを使用する 2 つの別々の Environ に team-a と team-b を配置します。この方法の欠点は、メッシュの連携が必要になり、単一メッシュの場合よりも管理が難しくなる点です。その反面、どちらのチームもデプロイされる名前空間とサービスを正規化する必要がありません。また、明示的に承認された通信のみが許可されます。

2 つのチームのリソースが別々の Environ に存在している状況を示す図
2 つのチームのリソースを別々の Environ に配置