Red Hatのソリューションアーキテクトの井上たかひろです。
「Module2：デバッグ、モニタリング、継続的デリバリー」に続いて「Module3：サービスメッシュによるアプリの制御とセキュリティ」についてざっくり紹介いたします。
OpenShift Service Meshにアプリをデプロイして可視化したり、A/Bテスト、フォルトインジェクション、サーキットブレーカーを試したり、サービスメッシュでのシングルサインオンを実践します。
使うソフトウェア：Service Mesh(istio), Kiali, Jaeger, Prometheus, Grafana, Red Hat Single -Sign on(Keycloak)など
Module3：サービスメッシュによるアプリの制御とセキュリティ
ハンズオンで実施する項目
- サービスメッシュを使ってみて、可視化してみる
- サービスメッシュの色々な機能を使ってみる(A/Bテスト、フォルトインジェクション、サーキットブレーカー)
- サービスメッシュでシングルサインオンをやってみる
サービスメッシュを使ってみて、可視化してみる
サービスメッシュはオープンソースプロジェクトの Istio をベースにしています。
これにより、サービスメッシュ全体のモニタリングと運用制御が可能になります。サービスのネットワーク全体で統一されたトラフィック管理 、可視化、ポリシー運用、セキュリティなどを提供します。
Kiali, Jaeger, Prometheus, Grafanaを使って、色々可視化していきます。
ガイドを見ながら、サンプルアプリケーションをインストールと、サービスメッシュの設定をやっていきます。
アプリはIstioのサンプル・アプリケーションのBookinfoを使用します。
OpenShift上にデプロイした後のトポロジービューは以下のようになっています。
Kialiを試してみます。サービスメッシュの設定の表示、トラフィックの流れと健全性の監視、トレースの分析を行うことができます。
サービスグラフでは、各マイクロサービスが、それらを通過するリクエストによって接続されたグラフが見れます。
アプリケーションのメトリクスも確認できます。インバウンドのリクエストについて表示しています。
分散トレースを確認してみます。Kiali は Jaeger との統合機能も備えています。
詳細なトレースとスパン(1つのサービス内の処理時間)のデータが確認できます。
この情報を使用して、アプリケーションの問題を迅速に発見することができます。
Prometheus によるメトリクスのクエリーも試してみます。
Prometheus は定期的にアプリケーションをスクレイプしてメトリクスを取得します 。
Istio 用の Prometheus アドオンは、Istio Mixer エンドポイントに対して、メトリクスを収集するように予め設定されています。
アプリケーションの各サービスが何回アクセスされたかのカウントとともに一覧表示しています。
また、 Graph タブをクリックすることで、結果を時間経過とともにグラフ化することもできます。
必要なデータを抽出するために実行できるクエリは、非常に多くものがありますので、詳細は Prometheusドキュメント を参照してください。
とはいえ、アプリケーションでサービスや数が増えてくると、このスタイルのメトリクスには少し大変かもしれません。
Grafana は、Istio データプレーンから抽出された多くの利用可能な Prometheus メトリクスを視覚的に表現し、問題を迅速に発見するために便利です。
ここでは、Istio Service メトリクスからbookinfoアプリのproductpage サービスの詳細なメトリクスを表示しています。
サービスメッシュの色々な機能を使ってみる(A/Bテスト、フォルトインジェクション、サーキットブレーカー)
サービスメッシュでは、A/Bテスト、カナリアロールアウト、パーセンテージベーストなどを実現することができます。 ここでは、サーキットブレーカー、タイムアウトやリトライなどの障害系も試していきます。
ガイドを見ながら、A/Bテストを試していきます。
jasonさんでログインするとreviewsサービスのv2 に、それ以外は reviewsサービスのv3にリクエストを送信するようにします。
yamlの該当箇所の抜粋です。
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v3
ハンズオンで、実際にアプリを動かしてみると、jasonさんでログインするとreviewsサービスのv2に、それ以外は reviewsサービスのv3にリクエストが送信されます。 このルーティング機能で、テスト、ブルー/グリーンデプロイメント、ダークローンチなどにおいて、異なるサービスインスタンスにトラフィックを選択的に送信することができます。
ガイドを見ながら、フォルトインジェクションを試していきます。
inventoryサービスへのリクエストの 50% にフォルト( HTTPのステータスコード500)を注入しています。
http:
- fault:
abort:
httpStatus: 500
percentage:
value: 50
route:
- destination:
host: inventory
port:
number: 8080
リクエストを何度か送信し、kialiで確認すると、リクエストの50%がエラーになっていることがわかります。
ガイドを見ながら、サーキットブレーカーを試していきます。
inventoryサービスへのリクエストを最大接続数を 1 に、最大保留中のリクエストを 1 を注入しています。
spec:
host: inventory
trafficPolicy:
connectionPool:
tcp:
maxConnections: 1
http:
http1MaxPendingRequests: 1
maxRequestsPerConnection: 1
リクエストを纏めて送信し、kialiで確認すると、サーキットブレーカーが HTTP 503 エラーを発生させているのがわかります。
このような流れでサービスメッシュのA/Bテスト、フォルトインジェクション、サーキットブレーカーを試してみました。
アプリ側に手を入れずに、出来るのが大きな魅力です。
サービスメッシュでシングルサインオンをやってみる
認証を有効します。ここでは、Red Hat Runtimesの一部であるRed Hat Single Sign On(keycloakベース)を利用してJSON Web Tokens (JWT)でやっていきます。
Red Hat Single Sign Onを簡単に試せるカタログがあるので、そこからインストールしていきます。
1〜2分で、Red Hat Single Sign Onが利用できるようなります。
ガイドを見ながら、Single Sign Onの設定を実施していきます。
JWTと OIDC 認証フローを使って、認証ポリシーを作成します。
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: calalog-req-auth
namespace: user1-catalog
spec:
selector:
matchLabels:
deploymentconfig: catalog-springboot
jwtRules:
- issuer: http://sso-user1-rhsso.apps.cluster-xxxxx.opentlc.com/auth/realms/istio
jwksUri: http://sso-user1-rhsso.apps.cluster-xxxxopentlc.com/auth/realms/istio/protocol/openid-connect/certs
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: catalog-auth-policy
namespace: user1-catalog
spec:
selector:
matchLabels:
deploymentconfig: catalog-springboot
rules:
- from:
- source:
requestPrincipals: ["*"]
curlを使って、RH-SSOから出力されたAuthorizationトークンを取得し、そのトークンでアプリにアクセスできることを確認します。
このような流れでシングルサインを試すことができます。
手順の類はだいぶ端折っているので、短く感じるかもしれませんが、実際にハンズオンを行うとそこそこのボリュームです。
ガイドに従って進めればサービスメッシュの可視化、リクエストルーティング、サービスメッシュでの認証の流れが理解できると思います。
ワークショップにご興味があればご連絡ください。
