Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie ServiceMeshEndpointWithMinimalAPIPublish.pptx
Ähnlich wie ServiceMeshEndpointWithMinimalAPIPublish.pptx (20)
Mehr von Takao Tetsuro
Mehr von Takao Tetsuro (20)
ServiceMeshEndpointWithMinimalAPIPublish.pptx
- 2. Profile •ブログ : http://blog.processtune.com •プロフィール : Facebook, Twitter or Microsoft MVP Website •コミュニティ : .NETラボの運営スタッフ •Microsoft MVP : July 2010 ～ Jun 2023 •Current expertise : MVP for Developer Technologies Solutions Architect システム構築のプロセス評価、改善、策定、開発フ レームワークの設計、実装管理、プリセールスやプロ ジェクトの立ち上げなど
- 3. コンテナとサービス・メッシュ Well-architected framework for cloud マイクロサービスのサイドカー・パターン サービスメッシュ・パターンとコンテナ コンテナとサービスメッシュの通信 サービス・メッシュと汎用ホストの既定の機能 サービスメッシュで考慮すべき観点 汎用ホストが既定で提供している機能 認証の実装 プロジェクト作成 認証認可 Azure Active Directoryアプリケーション appsettings.json Program.cs ルートのHttp Getメソッド 抽象化、構成、ロギングの実装 抽象化 構成 別のappsettingsの切り替え オプションズ・パターンのおさらい 汎用ホストのロギング W3Cロギングフォーマットのロギング
- 4. Well-architected framework for cloud マイクロサービスのサイドカー・パターン サービスメッシュ・パターンとコンテナ コンテナとサービスメッシュの通信
- 5. google cloud architecture framework https://cloud.google.com/architecture/framework?hl=ja オペレーショナルエクセレンス セキュリティ 信頼性 パフォーマンス効率 コスト最適化 + 持続性（Amazon Web Service） System design（Google Cloud） 6 elements of support（Azure） AWS Well-Architected Labs - SUSTAINABILITY https://www.wellarchitectedlabs.com/sustainability/ Azure Well-Architected レビュー Azure Advisor ドキュメント パートナー、サポート、サービス オファー 参照用アーキテクチャ 設計原則 Well-architected framework for cloud
- 6. Micro service Micro service Micro service Side car ロギング NSG: Network Security Group マイクロサービスのサイドカー・パターン Micro service Micro service Side car Side car Side car プロキシ 認証認可 構成 抽象化 Side car 物理層 永続化層
- 7. 物理層 永続化層 Service mesh control plane Service mesh data plane Micro service Micro service Micro service 抽象化 認証認可 構成 ロギング プロキシ サービスメッシュ・エンドポイン サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 サービスメッシュ・エンドポイント特有の役割 サービスメッシュ・エンドポイントとしての役 NSG: Network Security Group サービスメッシュ・パターンとコンテナ Micro service Micro service
- 8. 物理層 永続化層 Service mesh control plane Service mesh data plane Micro service Micro service Micro service サービスメッシュ・エンドポイン サービス間通信を行うコンテナ NSG: Network Security Group コンテナとサービスメッシュの通信 Micro service Micro service チケットサービス 決済サービス シネマサービス スクリーン情報サービス 作品情報サービス Micro service スケールアウト
- 10. Micro service Micro service Micro service 抽象化 認証認可 構成 プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 サービスメッシュ・エンドポイント特有の役割 サービスメッシュ・エンドポイントとしての役 NSG: Network Security Group サービスメッシュで考慮すべき観点 Well-architected frameworkの役割 ロギング Micro service Micro service 物理層 永続化層 Service mesh control plane Service mesh data plane サービスメッシュ・エンドポイン Security Operational Excellence Reliability Performance efficiency Cost optimization
- 11. サービスメッシュ・エンドポイント特有の役割 サービスメッシュ・エンドポイントとしての役 NSG: Network Security Group 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 汎用ホストが既定で提供している機能 抽象化 認証認可 構成 プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 ロギング
- 12. テンプレートに既定で組み込まれている 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 >dotnet new webapi -minimal true -au SingleOrg >dotnet run https://localhost:7047/swagger/index.html 汎用ホストが既定で提供している機能 これから追加していく >dotnet new webapi -minimal true >dotnet run
- 14. 2.タイプ「jsonc」 1.クリック プロジェクト作成 テンプレートに既定で組み込まれている これから追加していく 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 0. >dotnet new webapi -minimal true -au SingleOrg または、設定のfiles.associationsに「*.json」「jsonc」と設定しておいてもエラーを非表示
- 15. 2.タイプ「jsonc」 1.クリック 認証認可 3.Ctrl + クリック テンプレートに既定で組み込まれている これから追加していく 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 0. >dotnet new webapi -minimal true -au SingleOrg file-preference-settings
- 16. 認証認可 これから追加していく 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 1.名前だけ入力して登録 2. マニフェストで“accessTokenAcceptedVersion”を「
- 17. Azure Active Directoryアプリケーション これから追加していく 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 1.アプリの公開でScopeを作成 3. スコープ名や説明などを設定して追加 2. 保存して続ける
- 20. ルートのHttp Getメソッド これから追加していく 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理
- 23. 構成 これから追加していく 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 1. AddJsonFileメソッドでファイル追加 2. 追加した「appsettings2.json」にはGoogleの認証情報を設定 3. 構成をサービスとして追加 4. ルートの要求があった時に構成サービスの目的の設定をバインドした値
- 25. オプションズ・パターンのおさらい これから追加していく 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 public string ClientSecret{ get; set; } = String.Empty;
- 26. 汎用ホストのロギング これから追加していく 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 builder.Services.AddLogging( bulder=>{ bulder.AddNLog(); } );
- 27. W3Cロギングフォーマットのロギング これから追加していく 抽象化 認証認可 構成 ロギング プロキシ サービス複製管理 ネットワーク通信暗号化 呼び出し回数管理 ネットワーク密集度 サービス通過数管理 サービス反復管理 ネットワーク経路管理 using Microsoft.AspNetCore.HttpLogging; dotnet add package Microsoft.Extensions.Logging --version 6.0.0
- 28. 汎用ホストは多数のミドルウェアを追加しカスタマイズすること可 能であり、 エンドポイントの構築を行うのであれば、ASP.NET Core Web API minimal テンプレートから必要なミドルウェアを追加していく方法が効果的 サービスメッシュ・エンドポイントに必要なデータプレーン機能は、 ASP.NET Core Web API minimalテンプレートで組み込まれる汎用ホ ストが既定でサポートしている機能であり、カスタマイズすること でクラウド・ソリューション・アーキテクチャの基本的なスキルを 身に付けることが可能 各クラウドベンダーが推奨するWell-architected frameworkは、クラ
- 29. Dream Wallpapers: このプレゼンテーションの背景 https://wallpaperaccess.com/dream 保護された Web API: アプリの登録 – Microsoft Docs https://docs.microsoft.com/ja-jp/azure/active-directory/develop/scenario-protected-web-api-app-registration Microsoft ID プラットフォーム アクセス トークン – Microsoft Docs https://docs.microsoft.com/ja-jp/azure/active-directory/develop/access-tokens Swashbuckle.AspNetCore: NuGet Gallery https://www.nuget.org/packages/Swashbuckle.AspNetCore/ Google Cloud アーキテクチャ フレームワーク https://cloud.google.com/architecture/framework?hl=ja AWS Well-Architected https://aws.amazon.com/jp/architecture/well-architected/ Microsoft Azure Well-Architected Framework – Microsoft Docs https://docs.microsoft.com/ja-jp/azure/architecture/framework/ クイックスタート:Microsoft ID プラットフォームを使用して Web API を保護する – Microsoft Docs https://docs.microsoft.com/ja-jp/azure/active-directory/develop/web-api-quickstart?source=recommendations&pivots=devlang-aspnet-core Microsoft.Identity.Web.UI : NuGet Gallery https://www.nuget.org/packages/Microsoft.Identity.Web.UI
- 30. Microsoft Identity Web 認証ライブラリ – Microsoft Docs https://docs.microsoft.com/ja-jp/azure/active-directory/develop/microsoft-identity-web Web API を呼び出す Web API:コード構成 – Microsoft Docs https://docs.microsoft.com/ja-jp/azure/active-directory/develop/scenario-web-api-call-api-app-configuration?tabs=aspnetcore Microsoft.Identity.Web.MicrosoftGraph https://www.nuget.org/packages/Microsoft.Identity.Web.MicrosoftGraph Web API を呼び出す Web API:運用環境に移行する – Microsoft Docs https://learn.microsoft.com/ja-jp/azure/active-directory/develop/scenario-web-api-call-api-production Azure-Samples / active-directory-dotnet-native-aspnetcore-v2 https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2/tree/master/2.%20Web%20API%20now%20calls%20Microsoft%20Graph ASP.NET Core の静的ファイル – Microsoft Docs https://learn.microsoft.com/ja-jp/aspnet/core/fundamentals/static-files?view=aspnetcore-6.0 Extended Log File Format https://www.w3.org/TR/WD-logfile.html Microsoft.Extensions.Logging: NuGet Gallery https://www.nuget.org/packages/Microsoft.Extensions.Logging W3CLogger in ASP.NET Core – Microsoft Docs https://learn.microsoft.com/ja-jp/aspnet/core/fundamentals/w3c-logger/?view=aspnetcore-6.0
- 31. W3CLoggingFields 列挙型 – Microsoft Docs https://learn.microsoft.com/ja-jp/dotnet/api/microsoft.aspnetcore.httplogging.w3cloggingfields?view=aspnetcore-6.0 .NET でのログ プロバイダー – Microsoft Docs https://learn.microsoft.com/ja-jp/dotnet/core/extensions/logging-providers#built-in-logging-providers Getting started with ASP.NET Core 6 https://github.com/NLog/NLog/wiki/Getting-started-with-ASP.NET-Core-6 Minimal API の概要: ASP.NET Core のミドルウェア - Microsoft Docs https://learn.microsoft.com/ja-jp/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-6.0#aspnet-core-middleware Azure Kubernetes Service (AKS) のネットワーク ポリシーを使用したポッド間のトラフィックの保護 https://learn.microsoft.com/ja-jp/azure/aks/use-network-policies fluentd https://www.fluentd.org/ Google Anthos https://cloud.google.com/anthos/ AWS Outposts https://aws.amazon.com/jp/outposts/ Azure Stack https://azure.microsoft.com/ja-jp/products/azure-stack/
Hinweis der Redaktion
- これまで.NETラボでお話ししてきたように、ASP.NET Core Web APIのminimalテンプレートは、既定でいくつかのサービスをあらかじめ組み込んであるWeb APIスタックです。このWebスタックでは、前回のお話しのようにWebアプリにもDesktop Nativeアプリにも使える汎用ホストを使ってます。Web APIのホストビルダーが提供する汎用ホストには、既定でSwagger、ロギング、構成のサービスが組み込んであり、アプリケーションのライフサイクル管理の機能があらかじめ用意されています。これらは汎用ホストが持つDependency Injectionの機能によってアプリケーション・ホストを構成できるようになっており、IHostedServiceを実装するサービスであれば同じように開発者がいくつかのサービスの組合せをカスタマイズすることができるようになっているのでWebアプリもDesktop Nativeアプリもホストすることができます。 一方、サービスメッシュ・エンドポイントに必要な機能は、各サービスの認証機能であり、ネットワークのロードバランシング（レート上限管理）やフォールトトレラント（サービスの複製管理）、通信の暗号化、サービスの呼び出し回数の管理、クラスタ係数などを使ったネットワーク密集度の管理、分散トレーシングとしてサービス通過数や反復の管理、経路の管理（トポロジ）が必要です。 これらのすべての実装をお話するわけではありませんが、ASP.NET Core Web APIのminimalテンプレートにいくつかのサービスを組み合わせてサービスメッシュエンドポイントを作成することで、サービスメッシュエンドポイントの各種機能を、クラウドベンダーが提供するAzureのAPI Management、Google CloudのAPI ゲートウェイ、AWSのAPI Managementなどを使って簡単に構築できることを理解できます。これは、istioを使ってメッシュを構成してEnvoyでプロキシを構築する場合も同じです。 サービスメッシュエンドポイントを自作するコストと各クラウドベンダーが提供するAIP管理サービスのコストを考慮してクラウドネイティブなソリューションを計画することは重要で、単にサービスのオペレーションだけを覚えるのでなく、サービスメッシュ・エンドポイントのメカニズムを理解し、各クラウドプロバイダーのAPI管理機能やEnvoy、自作のメッシュなどを組み合わせた柔軟な設計を行います。
- 自己紹介を読む
- まず最初にクラウド・アプリケーションの設計に必要な概念であるWell-architected frameworkについて少し触れます。この概念の実装アプローチのひとつとしてマイクロサービスがあるのですが、その実装時にコンテナとサービス・メッシュを計画することでWell-architected frameworkの多くをカバーすることができます。
- Well-architected frameworkという概念は、AzureやAWS、Google Cloudでエンドユーザーの基盤を構築する人間に求められている知識として訴求されている設計概念です。それぞれのクラウドベンダーで共通して訴求されているのは「オペレーショナルエクセレンス」「セキュリティ」「信頼性」「パフォーマンス効率」「コスト最適化」です。クラウドベンダーは、これらを実装できる機能をサービスしているのだから、それをエンドユーザーにサービス提供する技術者はそれらを適切に設定して、適切に構築、配置、保守運用していくことが求められます。 詳細は各クラウドベンダーのオフィシャルのドキュメントを参照してください。実装アプローチとしてマイクロサービスパターンを採用した時に、サービスメッシュ・エンドポイントがカバーするWell-architected frameworkの部分がわかると役割分担やクラウドの設定、運用設計に役立つと思います。
- まず、マイクロサービスのサービスメッシュ・エンドポイントがなぜ必要になったのかをお話します。マイクロサービスは、サービスの機能の内容、つまりビジネスロジックの部分と各サービスに共通に必要な基盤を利用するための機能を分離するためにサードカー・パターンという設計パターンが生まれました。このサイドカーは機器の抽象化や認証認可、ロギングやプロキシの役割を受け持ちます。
- サービスメッシュ・パターンでは、各サービスのサイドカーが行っていた構成やロギング、ハードウェアの抽象化や認証認可、プロキシなどはサービスメッシュ・データプレーンにまとめられます。プロキシの役割もサービスメッシュ・データプレーンに移行するのでここがサービスメッシュ・エンドポイントになります。ここでは、各サービスのサイドカーの役割は連携することになり、各サービスを統合的に管理できますので個別のサードカーの役とは別の役割も増えることになります。 具体的には「サービス複製管理、ネットワーク通信暗号化、呼び出し回数管理、ネットワーク密集度、サービス通過数管理、サービス反復管理、ネットワーク経路管理」といったメッシュエンドポイント特有の役割が増えることになります。 【クリック】こうすることで、各マイクロサービスをコンテナ化することが容易になります。ひとつのコンテナに複数のサービスをまとめることもできます。
- 図のようなソリューションを想定してみてください。コンテナにはサービスメッシュ・エンドポイントとの通信を実装する必要がありますが、コンテナへのトランザクションは必ずサービスメッシュ・エンドポイントを通過するように設計すると、各コンテナにユニファイド・ファイアーウォールの設定やリソースクォーター、コンテナ自体のリソースへのアクセス制限などを実装しないように構築できます（これらはプロキシの役割です）。この方法の利点は、コンテナのサービスを生成、破棄、コンテナを切り離しする機能をサービスメッシュ・エンドポイントに実装することで、サーバーレスコンピューティングにおけるプロセスの一部としてコンテナに実装されたサービスを管理することができます。図のようなトポロジで、青線であらわされるコンテナ間通信で相手のコンテナの仮想ネットワーク内の内部IPアドレスを絞ることもできますが、可搬性やスケーラビリティは低下します。マイクロサービスのコンテナには、稼働環境におけるスタティックな情報はできるだけ排除しながらセキュリティや可用性のバランスを計画する必要があります。たとえば、作品情報サービスがスケールアウトされた場合のIPアドレスをシネマサービスが知る方法はサービスメッシュ・エンドポイントへの問合せが効率的です。これをKubernetesのレプリケーションのようにコントローラーで実装しても良いですし、istioのpilotでEnvoyのエンドポイントディスカバリーサービスをコントロールしても構いませんが、コンテナから稼働環境におけるスタティックな情報を分離します。 【クリック】同様に、すべてのサービスは、どのコンテナに実装されているかに関係なく、サービスメッシュ・エンドポイントが提供するコンテキストによって参照、呼び出しができるように設計します。
- まず最初にクラウド・アプリケーションの設計に必要な概念であるWell-architected frameworkについて少し触れます。この概念の実装アプローチのひとつとしてマイクロサービスがあるのですが、その実装時にコンテナとサービス・メッシュを計画することでWell-architected frameworkの多くをカバーすることができます。
- Well-architected frameworkの「オペレーショナルエクセレンス」「セキュリティ」「信頼性」「パフォーマンス効率」「コスト最適化」の観点をサービスメッシュの役割に当てはめると設計の内容が明確化されます。たとえば、ロギングに記録すべき内容はコスト観点、パフォーマンス観点であり、ネットワーク受送信量の詳細などを記録するのではなく、トランザクションごとのサービスの通過数が重要になってくるかもしれません。ネットワーク受送信量についてはクラウドベンダーがメトリックスを提供してくれています。クラウドの基盤に任せるべき部分とサービスメッシュを管理することを明確に分離し、その中でWell-architected frameworkを意識した設計をすることが重要です。 また、プロキシの役割は、サイドカーでのプロキシの役割より大幅に増えます。サービスメッシュエンドポイント特有の役割が増えることになります。
- Minimal Web APIの汎用ホストは構成、認証、Swaggerのサービスを既定で組み込んだプロジェクトをテンプレートで作成できますので、ロギングとハードウェア抽象化の部分を作っていきます。ただし、今回はプロキシと認証の部分を外して作成します。 【クリック】プロキシや認証を外す理由なのですが、プロキシは、ご覧の通り非常に広範な話をする必要があります。Envoyサーバーや各クラウドベンダーが提供する管理サービスとの費用対効果、トレードオフ、コラボレーションなど、このセッションとは分離する必要があると考えましたので、またの機会にお話します。 認証はAzure Active Directoryアプリケーションを作成する必要があり、Web API向けの認証については、ユーザーログインでなくスコープによるアプリケーションログインをするためのロールを作成する必要があります。つまり、スコープとロールを結び付けたAADアプリケーションを使ったMicrosoft ID プラットフォームでの認証を行いますので、これについても解説を分けてまたの機会にお話しします。認証についてはこの後、構築の流れだけお話しします。
- Minimal Web APIの汎用ホストは構成、認証、Swaggerのサービスを既定で組み込んだプロジェクトをテンプレートで作成できますので、ロギングとハードウェア抽象化の部分を作っていきます。ただし、今回はプロキシと認証の部分を外して作成します。 【クリック】プロキシや認証を外す理由なのですが、認証はAzure Active Directoryアプリケーションを作成する必要があり、Web API向けの認証については、ユーザーログインでなくスコープによるアプリケーションログインをするためのロールを作成する必要があります。つまり、スコープとロールを結び付けたAADアプリケーションを使ったMicrosoft ID プラットフォームでの認証を行いますので、これについては解説を分けてまたの機会にお話しします。今回はその流れだけお話しします。
- まず最初にクラウド・アプリケーションの設計に必要な概念であるWell-architected frameworkについて少し触れます。この概念の実装アプローチのひとつとしてマイクロサービスがあるのですが、その実装時にコンテナとサービス・メッシュを計画することでWell-architected frameworkの多くをカバーすることができます。
- 認証部分の作成の流れとしては、「>dotnet new webapi -minimal true -au SingleOrg」でプロジェクトを作成した後に、appsettings.jsonを開きます。JSON Commentのエラーが出る場合はVisual Studio Codeの右下のJsonをクリックしてコマンドバーを表示しjsoncとタイプしてJSON with Commentsを選択してください。 または、設定を開いて検索ボックスで「files.asso」と入力して「*.json」「jsonc」と設定しておいてもエラーを非表示にします。
- 認証部分の作成の流れとしては、「>dotnet new webapi -minimal true -au SingleOrg」でプロジェクトを作成した後に、appsettings.jsonを開きます。JSON Commentのエラーが出る場合はVisual Studio Codeの右下のJsonをクリックしてコマンドバーを表示しjsoncとタイプしてJSON with Commentsを選択してください。 Swagger UIのブラウズの後に、ルートのIndexを参照すると認証していないのでエラーがブラウザに表示されます。 Microsoft ID プラットフォームで認証するために、Azure Active Directory Applicationを作らなければいけないのですが、テンプレートのappsettings.jsonのコメント部分のURLをクリックすると、「プロジェクトから作成、IDEからAADアプリケーションを作る」という流れの作成方法が載っています。 【クリック】ただし、.NET 5.0対象のツールを使う方法なので、このツールを使わない方法の解説へのリンクがあります。コメントのURLをクリックして開く「vs2019-16.9-how-to-use.md」というマークダウンファイルの最下部です。 【クリック】この資料の巻末にもリンクは載せてありますが、WEB APIのリンクを選択して表示されるページの言語をja-jpにして参照することもできます。
- マークダウンの最下部のWeb APIのリンクをクリックするとMicrosoft Docsに遷移します。手順はシンプルな6つのステップです。「アプリケーション作成」「マニフェスト編集」「メッシュエンドポイント専用のスコープを作成」「アプリケーションにロールを作成」「ロールがスコープを使えるように紐づけ」「アクセス許可に同意」という手順です。
- Azure Active Directoryアプリケーションを作成したら、APIの公開-Scopeの追加を選択します。続いてそのまま「保存してから続ける」を選択してスコープを設定します。スコープ名は「access_as_user」、管理者とユーザーが同意できるようにしておきます。同意の表示名と説明は管理者、ユーザーとも設定します。今回はこのスコープを要求するのはアプリケーションに割り当てるロールなのでユーザーの認証は行いません。
- もう少し設定は必要ですが、この段階ではここまでで大丈夫です。Visual Studio Codeに戻ってappsettings.jsonを開き、Domainを入力してから、Azureポータルから「TenantId」と「ClientId」をコピーします。入力はこの2つですが、Scopesを確認してください。先ほど作成した「access_as_user」がテンプレートとして指定されています。それから「program.cs」を開いてGetメソッド「weatherforecast」を確認してください。 このapp.MapGetメソッドの最後に「.RequireAuthorization()」メソッドを呼び出しているところが認証を強制しているところになります。そのため、先ほどのルートの「Index」がエラーを表示するということになります。それでは、このルート呼び出し部分を認証を必要としない表示にしておいて、ユーザー（実際はアプリケーション）がログインできるようにします。
- もう少し設定は必要ですが、この段階ではここまでで大丈夫です。Visual Studio Codeに戻ってappsettings.jsonを開き、Domainを入力してから、Azureポータルから「TenantId」と「ClientId」をコピーします。入力はこの2つですが、Scopesを確認してください。先ほど作成した「access_as_user」がテンプレートとして指定されています。それから「program.cs」を開いてGetメソッド「weatherforecast」を確認してください。 【クリック】このapp.MapGetメソッドの最後に「.RequireAuthorization()」メソッドを呼び出しているところが認証を強制しているところになります。ルートの「Index」のGetメソッドを作成し、がエラーを表示しないようにするためには、ルート呼び出し部分を認証を必要としない設定にしておいて、ユーザー（実際はアプリケーション）がログインできるようにしておくことでログインのUIを持つサービスを呼び出すことができるように構成することも可能です。
- まず、ルート「/」にGetメソッドを設置して「.AllowAnonymous()」メソッドを最後に呼ぶようにします。エラーが表示されなくなったことを確認してください。ここまでが認証の流れになります。サービスメッシュエンドポイントで認証を行うのではなく、UIを持つWeb Appからメッシュエンドポイントを経由して他のサービスを呼ぶように構成すると思いますので、実際の認証はもう少し複雑になります。具体的には、このような代理認証を行うMicrosoft.AspNetCore.Authentication ミドルウェアを作成するのでなく、UIを持つWeb Appで認証、認証済みトークンをサービスメッシュエンドポイントで検証して他のサービスを代理呼び出しを行うといったことが行われるかと思います。このような方法としてマイクロソフトのドキュメント（巻末リンク参照）「Web API を呼び出す Web API:運用環境に移行する」の「次のステップ」にあるリンク先に汎用ホストに登録できるMicrosoft ID プラットフォームのWeb API認証サービスが持つEnableTokenAcquisitionToCallDownstreamApiメソッドを使う方法が記載されています。このDownstreamApiはWeb AppからWeb APIに認証情報をわたすこともでき、Web APIからWeb APIに認証情報をわたすこともできます。
- まず最初にクラウド・アプリケーションの設計に必要な概念であるWell-architected frameworkについて少し触れます。この概念の実装アプローチのひとつとしてマイクロサービスがあるのですが、その実装時にコンテナとサービス・メッシュを計画することでWell-architected frameworkの多くをカバーすることができます。
- 抽象化は物理的な機器を他のサービスが利用できるようにするものです。マイクロサービスをオンプレミスでサービスする場合であっても、Azure StackやAWS Outposts、Google Anthosなどでクラウドネイティブなソリューションを構築するため、ネットワークストレージなどを抽象化する場合でもサービスメッシュ・エンドポイントが行うことはありません。おそらく唯一あるとするとローカルファイルの抽象化だと考えられます。ここでは、簡単なサービスとしてローカルファイルを抽象化してそのファイルの読み込みを行えるようにするサービスを汎用ホストに実装します。ローカルファイルの読込にはURLを公開する手段があり、Microsoft.Extensions.FileProviders名前空間のPhysicalFileProviderオブジェクトを使うことでローカルの静的ファイルをURLで指定させることができます。図はWebルートのStaticFilesアドレスを使って、プロジェクトルートのMyStaticFilesフォルダのファイルを公開している例です。
- 構成サービスの仕組みですが、Options patternの時にお話しした通り、Web APIやWeb Appの「WebApplication.CreateBuilder」メソッドで作成される汎用ホストは既定で「appsettings.json」を読み込んでいます。 追加で「appsettings2.json」を読みこんでみましょう。 まず、汎用ホストのアプリ構成の構築時に追加のファイル「appsettings2.json」を「AddJsonFile」メソッドで追加します。ファイルにはGoogleのシークレットとクライアントIDを設定しておきます。もともとの「appsettings.json」にはMicrosoftのAzure Active Directoryの設定が入っています。続いて構築した構成をサービスとして汎用ホストに追加します。最後にルートのGetメソッドで受け取った構成サービスの目的の設定をバインドした値を利用します。
- 切り替えができることを確認します。ルートのGetメソッドで構成サービスの目的の値を読み込む際、追加したappsettings2.jsonに設定されているGoogleの値を取得できましたので、Microsoft側の値を取得するように変更して、保存-いったんCtrl+Cでサーバーを終了して、もう一度ブラウザで表示を確かめるとappsettings.jsonのMicrosoftの値が取得できることを確認できます。
- ここでおさらいになりますが、構成サービスの値をバインドする際にAuthContextという型を指定しています。Modelsフォルダを設けてその中にAuthContext.csという名前のファイルを作成して型を定義しています。 【クリック】これは、appsettings.jsonのAzureADセクションとappsettings2.jsonのGoogleCloudセクションの設定をマージしたプロパティを定義してオプションズパターンのカプセル化とビジネスの関心ごとを分離したサンプルになります。例えば、Google CloudのAPIサービスのOAuth同意画面では、新規認証情報を作成するとクライアントIDとクライアントシークレットを持つWebアプリケーションを作成できます。 【クリック】MicrosoftのAzureAd設定にClientSecretという名前の値が追加されてもGoogle Cloud側には影響の出ないカプセル化ができており、Google側の設定が「Secret」という名前で値がすでに設定されているから「ClientSecret」ではなく「Secret」でなくてはいけないなどの継続的インテグレーションとしての制限もなく、ビジネスの関心ごととしてMicrosoftの認証だけを改修すればよいという分離がされています。
- ロギング機能として利用できるミドルウェアには、IDEやOSのイベントログに出力するものやHTTPロギング、W3Cロガーなどがあります。.NETが持つログプロバイダーのほかにもILoggerFactoryやILoggingBuilderを使ってDepecdency Injectionを実装し、サードパーティ製のログプロバイダーを利用することも可能です。NLogのようにDepecdency Injectionを実装済みのサードパーティ製のログプロバイダーもあります。 【クリック】変数logger宣言時にDepecdency Injectionを実装済みなのでビルダーで汎用ホストにNLogを使うことを定義するだけです。 【クリック】メソッドで使う場合は、「builder.Services.AddLogging(bulder=>{bulder.AddNLog();});」でサービス化します。
- サービスメッシュ・エンドポイントの各サービス向けのロギング機能として、W3Cロガーを使ったW3C標準ログフォーマット（WD-logfile-960323：巻末リンク参照）の例を解説します。汎用ホストのサービスコレクションのAddW3CLoggingメソッドを使用してW3Cロギングフォーマットの各種設定を行います。 【クリック】ログフィールドを設定する際のW3CLoggingFields列挙値は「Microsoft.AspNetCore.HttpLogging」名前空間にあるので、「Microsoft.Extensions.Logging」パッケージをNugetギャラリーからインストールします。 【クリック】設定の通り、C:\logsフォルダにMyLogFileと日付シーケンスが入った名前のファイルが作成されます。