From 3dd0f059f325087cb8c7b1e361847d26e8b1daf8 Mon Sep 17 00:00:00 2001 From: nwiizo Date: Wed, 26 Jun 2024 11:34:04 +0900 Subject: [PATCH 1/4] [Translation] Add Japanese version of Chapter 9 --- chapter-9/README-ja.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 chapter-9/README-ja.md diff --git a/chapter-9/README-ja.md b/chapter-9/README-ja.md new file mode 100644 index 0000000..b9ec919 --- /dev/null +++ b/chapter-9/README-ja.md @@ -0,0 +1,27 @@ +# 第9章 :: プラットフォームの測定 + +--- +*🌍 利用可能な言語*: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md) + +> **注意:** これは素晴らしいクラウドネイティブコミュニティの [🌟 コントリビューター](https://github.com/salaboy/platforms-on-k8s/graphs/contributors) によってもたらされました！ + +--- + +この章では、DORメトリクス（DORA: DevOps Research and Assessment）を使用してプラットフォームイニシアチブのパフォーマンスを測定する方法に関する2つの異なるチュートリアルを取り上げています。 + +- [DORメトリクスとCloudEvents](dora-cloudevents/README-ja.md) +- [Keptn Lifecycle Toolkit](keptn/README-ja.md) + +## まとめ + +この章で取り上げたチュートリアルは、アプリケーションを観察およびモニタリングするために使用できる、完全に異なるが補完的な2つのアプローチを示すとを目的としています。最初のチュートリアルはCloudEventsとCDEventsに焦点を当て、プラットフォームチームが異なるイベントソースを活用してDORAメトリクスを計算する方法を示しています。一方、2番目のチュートリアルはKeptn Lifecycle Toolkitに焦点を当て、Kubernetesスケジューラを拡張し、アプリケーションに関する情報を収集することで、デプロイメント頻度メトリクスをすぐに提供します。 + +プラットフォームチームは、ここで紹介したようなツールを評価し、メトリクスを計算するだけでなく、プラットフォームへの投資を正当化するべきです。プラットフォームの決定とイニシアチブがチームのデプロイメント頻度、変更のリードタイムを改善し、同時に障害からの復旧時間を短縮する場合、適切なプラットフォームを構築していることになります。チムがあまり頻繁にデプロイしていない、変更が顧客の前に届くまでに時間がかかっていることに気付いた場合は、選択を再評価する必要があるかもしれません。 + +## クリーンアップ + +このチュートリアル用に作成したKinDクラスターを削除したい場合は、次のコマンドを実行できます： + +```shell +kind delete clusters dev +``` From 7ae6f1cd634371ea1c2f3d0d7bba8effb46b4ba0 Mon Sep 17 00:00:00 2001 From: nwiizo Date: Wed, 26 Jun 2024 11:39:13 +0900 Subject: [PATCH 2/4] [Translation] Add Japanese version of Chapter 9 dora-cloudevents --- chapter-9/dora-cloudevents/README-ja.md | 198 ++++++++++++++++++++++++ 1 file changed, 198 insertions(+) create mode 100644 chapter-9/dora-cloudevents/README-ja.md diff --git a/chapter-9/dora-cloudevents/README-ja.md b/chapter-9/dora-cloudevents/README-ja.md new file mode 100644 index 0000000..883267f --- /dev/null +++ b/chapter-9/dora-cloudevents/README-ja.md @@ -0,0 +1,198 @@ +# Kubernetes向けDORAメトリクス + CloudEvents & CDEvents + +--- +_🌍 利用可能な言語_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md) + +> **注意:** これは素晴らしいクラウドネイティブコミュニティの [🌟 コントリビューター](https://github.com/salaboy/platforms-on-k8s/graphs/contributors) によってもたらされました！ + +--- + +このチュートリアルでは、複数のソースから[CloudEvents](https://cloudevents.io)を消費し、Kubernetesネイティブなアーキテクチャ（クラウドに依存しない）を使用してDORAメトリクスを追跡できるコンポーネントのセットをインストールします。 + +このデモは、異なるイベントソースを観察し、これらのイベントをソフトウェアデリバリープラクティスに関連する意味のあるイベントにマッピングし、DORAメトリクスを計算するために集計できるようすることに焦点を当てています。 + +イベント変換フローは次のようになります： +- 入力は、異なるソースからの[CloudEvents](https://cloudevents.io)です +- これらのCloudEventsは、さらなる処理のために[CDEvents](https://cdevents.dev)にマッピングおよび変換できます +- DORA（またはその他の）メトリクスを計算するために集計関数を定義できます +- メトリクスは消費のために公開できます（この例ではRESTエンドポイントを介して） + +## インストール + +変換関数を実行するために、Knative Servingを使用したKubernetesクラスターを使用します。[第8章のKnative Servingをインストールしたクラスターを作成する手順](https://github.com/salaboy/platforms-on-k8s/tree/main/chapter-8/knative#creating-a-kubernetes-with-knative-serving)に従うことができます。 + +次に、Knative Eventingをインストールします。これはオプションでが、内部のKubernetesイベントを取得してCloudEventsに変換するKubernetes API Event Sourceをインストールするために使用します。 + +1. [Knative Eventing](https://knative.dev/docs/install/yaml-install/eventing/install-eventing-with-yaml/)をインストールします +```shell +kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.11.0/eventing-crds.yaml +kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.11.0/eventing-core.yaml +``` + +2. "dora-cloudevents"名前空間を作成します： +```shell +kubectl create ns dora-cloudevents +``` + +3. PostgreSQLをインストールしてテーブルを作成します +```shell +kubectl apply -f resources/dora-sql-init.yaml +helm install postgresql oci://registry-1.docker.io/bitnamicharts/postgresql --version 12.5.7 --namespace dora-cloudevents --set "image.debug=true" --set "primary.initdb.user=postgres" --set "primary.initdb.password=postgres" --set "primary.initdb.scriptsConfigMap=dora-init-sql" --set "global.postgresql.auth.postgresPassword=postgres" --set "primary.persistence.size=1Gi" +``` + +4. シンプルなCloudEventsモニターであるSockeyeをインストールします。これにはKnative Servingがインストールされている必要があります： + +```shell +kubectl apply -f https://github.com/n3wscott/sockeye/releases/download/v0.7.0/release.yaml +``` + +5. [Kubernetes API Server CloudEvent Event Source](https://knative.dev/docs/eventing/sources/apiserversource/getting-started/#create-an-apiserversource-object)をインストールします： +```shell +kubectl apply -f api-serversource-deployments.yaml +``` + +## コンポーネント + +このデモでは、CloudEventsをCDEventsに変換し、利用可能なデータを集計するために以下のコンポーネントをデプロイします。 + +- **CloudEvents Endpoint**: すべてのCloudEventsを送信するエンドポイント。これらのCloudEventsはSQLデータベースの`cloudevents-raw`テーブルに保存れます。 + +- **CloudEvents Router**: ルーティングテーブルを持つルーター。イベントを`CDEvents`に変換するためにルーティングします。このメカニズムにより、必要に応じて同じイベントタイプを複数の`CDEvents`に変換できます。このコンポーネントは`cloudevents-raw`テーブルから読み取り、イベントを処理します。このコンポーネントは設定可能な固定期間でトリガーされます。 + +- **CDEvents Transformers**: これらの関数は`CloudEvents Router`からイベントを受け取り、CloudEventsをCDEventsに変換します。結果は`CDEvents Endpoint`に送信されます。 + +- **CDEvents Endpoint**: `CDEvents`を送信するエンドポイント。これらのCloudEventsはSQLデータベースの`cdevents-raw`テーブルに保存されます。変換が不要なためです。このエンドポイントは、受信したCloudEventがCD CloudEventであることを検証します。 + +- **Metrics Functions**: これらの関数は異なるメトリクスを計算し、特別なテーブル（おそらくテーブルごとに1つ）に保存する責任があります。これらのメトリクスを計算するために、これらの関数は`cdevents-raw`から読み取ります。**デプロイメント頻度**メトリクスの計算方法の例を以下で説明します。 + +- **Metrics Endpoint**: 名前でメトリクスを照会し、フィルターを追加できるエンドポイント。これはオプションのコンポーネントです。これらのエンドポイントを使用せずに、メトリクステーブルからダッシュボードを構築することもできます。 + +![dora-cloudevents-architecture](../imgs/dora-cloudevents-architecture.png) + +## コンポーネントのデプロイとデータの生成 + +まず、以下のコマンドを実行してコンポーネントと変換関数をデプロイします： + +```shell +kubectl apply -f resources/components.yaml +``` + +ブラウザで[http://sockeye.default.127.0.0.1.sslip.io/](http://sockeye.default.127.0.0.1.sslip.io/)にアクセスして、CloudEventsをモニタリングするためにSockeyeを開きます。 + +次に、設定が正しく動作していることをテストするために、`default`名前空間に新しいDeploymentを作成します。 + +```shell +kubectl apply -f test/example-deployment.yaml +``` + +この時点で、Sockeyeに大量のイベントが表示されるはずです： + +![sockeye](../imgs/sockeye.png) + +デプロイメント頻度関数（変換と計算）がインストールされている場合、デプロイメント頻度エンドポイントにクエリを実行してメトリクスを確認できるはずです。Cronジョブを使用してデータを定期的に集計しているため、これには最大で数分かかる場合があることに注意してください： + +```shell +curl http://dora-frequency-endpoint.dora-cloudevents.127.0.0.1.sslip.io/deploy-frequency/day | jq +``` + +作成したデプロイメントに応じて、次のような出力が表示されるはずです（私は`nginx-deployment`と`nginx-deployment-3`という2つのデプロイメントを作成しました）： + +```shell +[ + { + "DeployName": "nginx-deployment", + "Deployments": 1, + "Time": "2023-08-05T00:00:00Z" + }, + { + "DeployName": "nginx-deployment-3", + "Deployments": 1, + "Time": "2023-08-05T00:00:00Z" + } +] +``` + +デプロイメントを変更したり新しいものを作成したりしてみてください。コンポーネントは`default`名前空間内のすべてのDeploymentをモニタリングするように設定されています。 + +すべてのコンポーネントは`dora-cloudevents`名前空間にインストールされていることに注意してください。以下のコマンドを実行して、ポッドとKnative ServicesのURLを確認できます： + +`dora-cloudevents`名前空間のKnative ServicesのURLを確認します： +```shell +kubectl get ksvc -n dora-cloudevents +``` + +実行中のポッドを確認します。Knative Servingを使用しているため、使用されていないすべての変換関数が常に実行されている必要がないことが興味深いです： + +```shell +kubectl get pods -n dora-cloudevents +``` + +最後に、データを集計するすべてのCronJob実行を確認するには、次のコマンドを実行します： + +```shell +kubectl get cronjobs -n dora-cloudevents +``` + +## 開発 + +開発用に`ko`を使用して`dora-cloudevents`コンポーネントをデプロイします： + +```shell +ko apply -f config/ +``` + +# メトリクス + +[https://github.com/GoogleCloudPlatform/fourkeys/blob/main/METRICS.md](https://github.com/GoogleCloudPlatform/fourkeys/blob/main/METRICS.md)より + +## デプロイメント頻度 + +![deployment frequency](imgs/deployment-frequency-metric.png) + +新しいまたは更新されたデプロイメントリソースを探します。これは、以前に設定した`APIServerSource`を使用して行われます。 + +フローは次のようになります： +```mermaid +graph TD + A[API Server Source] --> |writes to `cloudevents_raw` table| B[CloudEvent Endpoint] + B --> |read from `cloudevents_raw` table| C[CloudEvents Router] + C --> D(CDEvent Transformation Function) + D --> |writes to `cdevents_raw` table| E[CDEvents Endpoint] + E --> F(Deployment Frequency Function) + F --> |writes to `deployments` table| G[Deployments Table] + G --> |read from `deployments` table| H[Metrics Endpoint] +``` + +バケットの計算：日次、週次、月次、年次。 + +これは1日あたりのデプロイメント数をカウントします： + +```sql +SELECT +distinct deploy_name AS NAME, +DATE_TRUNC('day', time_created) AS day, +COUNT(distinct deploy_id) AS deployments +FROM +deployments +GROUP BY deploy_name, day; +``` + +## TODOと拡張 + +- `cloudevents_raw`および`cdevents_raw`テーブルに処理済みイベントメカニズムを追加します。これにより、`CloudEvents Router`と`Metrics Calculation Functions`が既に処理済みのイベントを再計算するのを避けることができます。これは、最後に処理されたイベントを追跡するテーブルを持ち、`CloudEvents Router`と`Metrics Calculation Functions`が新しいテーブルに対して結合することで実現できます。 +- デプロイメント頻度メトリクスのバケットを計算するクエリを`deployment-frequency-endpoint.go`に追加します：週次、月次、年次。頻度ではなくボリュームを計算するためのブログ投稿を確認してください：https://codefresh.io/learn/software-deployment/dora-metrics-4-key-metrics-for-improving-devops-performance/ +- 汎用コンポーネント（CloudEvents Endpoint、CDEvents Endpoint、CloudEvents Router）用のHelmチャートを作成します。 +- PostgreSQL helmチャートのテーブル作成を自動化します（https://stackoverflow.com/questions/66333474/postgresql-helm-chart-with-initdbscripts） +- **変更のリードタイム**の関数を作成します。 + +## その他のソースと拡張 + +- [Tektonのインストール](https://github.com/cdfoundation/sig-events/tree/main/poc/tekton) + - Tektonダッシュボード：`k port-forward svc/tekton-dashboard 9097:9097 -n tekton-pipelines` + - Cloud Events Controller：`kubectl apply -f https://storage.cloud.google.com/tekton-releases-nightly/cloudevents/latest/release.yaml` + - ConfigMap：`config-defaults` for +- https://github.com/GoogleCloudPlatform/fourkeys +- https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance +- Continuously Delivery Events aka [CDEvents](https://cdevents.dev) +- CloudEvents aka [CEs](https://cloudevents.io/) +- GitHub Source：https://github.com/knative/docs/tree/main/code-samples/eventing/github-source From 8778f16659619853358e51d600738b4e5554fbea Mon Sep 17 00:00:00 2001 From: nwiizo Date: Wed, 26 Jun 2024 11:41:51 +0900 Subject: [PATCH 3/4] [Translation] Add Japanese version of Chapter 9 keptn --- chapter-9/keptn/README-ja.md | 146 +++++++++++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 chapter-9/keptn/README-ja.md diff --git a/chapter-9/keptn/README-ja.md b/chapter-9/keptn/README-ja.md new file mode 100644 index 0000000..0ba9161 --- /dev/null +++ b/chapter-9/keptn/README-ja.md @@ -0,0 +1,146 @@ +# Keptn Lifecycle Toolkit、すぐに使えるデプロイメント頻度 + +--- +_🌍 利用可能な言語_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md) + +> **注意:** これは素晴らしいクラウドネイティブコミュニティの [🌟 コントリビューター](https://github.com/salaboy/platforms-on-k8s/graphs/contributors) によってもたらされました！ + +--- + +この短いチュートリアルでは、Keptn Lifecycle Toolkitを使用して、クラウドネイティブアプリケーションのライフサイクルイベントをモニタリング、観察、対応する方法を探ります。 + +## インストール + +[Keptn KLT](https://keptn.sh)をインストールするには、Kubernetesクラスターが必要です。[第2章](https://github.com/salaboy/platforms-on-k8s/blob/main/chapter-2/README-ja.md#kubernetes-kindを使用してローカルクラスタを作成する)で行ったように、Kubernetes KinDを使用してラスターを作成できます。 + +次に、Keptn Lifecycle Toolkit (KLT)をインストールできます。通常、これはKeptn Lifecycle Toolkit Helmチャートをインストールするだけで済みますが、このチュートリアルではダッシュボードを使用するためにPrometheus、Jaeger、Grafanaもインストールします。そのため、Keptn Lifecycle Toolkitリポジトリに基づいて、この例に必要なすべてのツールをインストールするためにMakefileを使用します。 + +以下を実行してください： + +```shell +make install +``` + +**注意**: インストールプロセスには、必要なすべてのツールをインストールするために数分かかります。 + +最後に、KLTにモニタリングしたい名前空間を知らせる必要があります。そのために、名前空間に注釈を付ける必要があります： + +```shell +kubectl annotate ns default keptn.sh/lifecycle-toolkit="enabled" +``` + +## Keptn Lifecycle toolkitの実践 + +Keptnは標準のKubernetes注釈を使用して、ワークロードを認識しモニタリングします。 +Conference Applicationで使用されるKubernetes Deploymentには、以下のような注釈が付けられています。例えば、Agenda Serviceの場合： + +```shell + app.kubernetes.io/name: agenda-service + app.kubernetes.io/part-of: agenda-service + app.kubernetes.io/version: {{ .Values.services.tag }} +``` + +これらの注釈により、ツールはワークロードについてより詳しく理解できます。例えば、この場合、ツールはサービス名が`agenda-service`であることを知ることができます。`app.kubernetes.io/part-of`を使用して、複数のサービスを同じアプリケーションの一部として集約できます。この例では、各サービスを個別にモニタリングできるように、各サービスを別個のエンティティとして保持しています。 + +この例では、KeptnTaskも使用します。これにより、デプロイメント前後にタスクを実行できます。以下の非常にシンプルな`KeptnTaskDefinition`の例をデプロイできます： + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: stdout-notification +spec: + function: + inline: + code: | + let context = Deno.env.get("CONTEXT"); + console.log("Keptn Task Executed with context: \n"); + console.log(context); +``` + +ご覧の通り、このタスクは実行コンテキストを出力するだけですが、ここで他のプロジェクトとの統合や外部システムの呼び出しを構築できます。Keptnの例を見ると、Slackに接続したり、負荷テストを実行したり、デプロイメントが更新後に期待通りに動作していることを検証したりするKeptnTaskDefinitionが見つかります。これらのタスクは、[Deno](https://deno.land/)（Typescriptをすぐに使用できる全なJavaScriptランタイム）、Python 3、または直接コンテナイメージを使用します。 + +以下を実行してデプロイします： + +```shell +kubectl apply -f keptntask.yaml +``` + +KeptnTaskDefinitionを使用すると、プラットフォームチームはアプリケーションのデプロイメント前後のフックに組み込める再利用可能なタスクを作成できます。ワークロード（この場合はデプロイメント）に以下の注釈を追加することで、Keptnはデプロイメント実行後（および更新後）に自動的に`stdout-notification`を実行します： + +```shell + keptn.sh/post-deployment-tasks: stdout-notification +``` + +Conference applicationをデプロイし、JaegerとGrafanaのダッシュボードを開きましょう。別のタブで以下を実行してください： + +```shell +make port-forward-jaeger +``` + +ブラウザで[http://localhost:16686/](http://localhost:16686/)にアクセスすると、以下のように示されるはずです： + +![jaeger](../imgs/jaeger.png) + +そして、別のターミナルで以下を実行します： + +```shell +make port-forward-grafana +``` + +ブラウザで[http://localhost:3000/](http://localhost:3000/)にアクセスします。`admin/admin`の認証情報を使用すると、以下のように表示されるはずです： + +![grafana](../imgs/grafana.png) + +では、第2章で行ったようにConference Applicationをデプロイしましょう： + +```shell +helm install conference oci://registry-1.docker.io/salaboy/conference-app --version v1.0.0 +``` + +JaegerとGrafanaのKeptnダッシュボードを確認してください。デフォルトでは、Keptn Workloadsはデプロイメント頻度を追跡します。 + +Grafanaで、`Dashboards` -> `Keptn Applications`に移動します。異なるアプリケーションサービスを選択できるドロップダウンが表示されます。Notifications Serviceを確認してください。デプロイメントの最初のバージョンのみをデプロイしたため、あまり見るべきものはありませんが、サービスの新しいバージョンをリリースした後、ダッシュボードはより興味深いものになります。 + +例えば、notifications-serviceデプロイメントを編集し、`app.kubernetes.io/version`注釈の値を`v1.1.0`に更新し、コンテナイメージに使用されるタグを`v1.1.0`に更新します。 + +```shell +kubectl edit deploy conference-notifications-service-deployment +``` + +変更を行い、新しいバージョンが起動して実行されたら、再度ダッシュボードを確認してください。 +Grafanaでは、2回目の成功したデプロイメントが表示され、私の環境ではデプロイメント間の平均時間が5.83分であり、`v1.0.0`は641秒かかったのに対し、`v1.1.0`はわずか40秒しかかからなかったことがわかります。ここには明らかに改善の余地があります。 + +![grafana](../imgs/grafana-notificatons-service-v1.1.0.png) + +Jaegerのトレースを見ると、Keptnのコアコンポーネントの1つである`lifecycle-operator`が、デプロイメントリソースをモニタリングし、デプロイメント前後のタスク呼び出しなどのライフサイクル操作を実行していることがわかります。 + +![jager](../imgs/jaeger-notifications-service-v1.1.0.png) + +これらのタスクは、ワークロードが実行されているのと同じ名前空間でKubernetes Jobsとして実行されます。これらのタスクのログは、jobのポッドのログをtailすることで確認できます。 + +```shell +kubectl get jobs +NAME COMPLETIONS DURATION AGE +post-stdout-notification-25899-78387 1/1 3s 66m +post-stdout-notification-28367-11337 1/1 4s 61m +post-stdout-notification-54572-93558 1/1 4s 66m +post-stdout-notification-75100-85603 1/1 3s 66m +post-stdout-notification-77674-78421 1/1 3s 66m +post-stdout-notification-93609-30317 1/1 3s 23m +``` + +ID `post-stdout-notification-93609-30317`のJobは、Notification Serviceデプロイメントの更新を行った後に実行されました。 + +```shell +> kubectl logs -f post-stdout-notification-93609-30317-vvwp4 +Keptn Task Executed with context: + +{"workloadName":"notifications-service-notifications-service","appName":"notifications-service","appVersion":"","workloadVersion":"v1.1.0","taskType":"post","objectType":"Workload"} +``` + +## 次のステップ + +Keptn Lifecycle Toolkitの機能と特徴についてさらに詳しく学ぶことを強くお勧めします。この短いチュートリアルで見たのは基本的な部分だけです。サービスのデプロイ方法をより細かく制御するために、[KeptnApplication](https://lifecycle.keptn.sh/docs/concepts/apps/)の概念を確認してください。Keptnを使用すると、どのサービスとのバージョンをデプロイできるかについて、詳細なルールを定義できます。 + +`app.kubernetes.io/part-of`注釈を使用して複数のサービスを同じKubernetesアプリケーションの一部としてグループ化することで、サービスのグループに対して事前および事後のアクションを実行でき、個々のサービスだけでなく、セット全体が期待通りに動作していることを検証できます。 From 82aaec8579b0adb843cf642206fe01a694f606e3 Mon Sep 17 00:00:00 2001 From: nwiizo Date: Wed, 26 Jun 2024 11:45:37 +0900 Subject: [PATCH 4/4] [Translation] Add Japanese version of Chapter 9 keptn/support/observability/config/prometheus --- .../support/observability/config/prometheus/README-ja.md | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 chapter-9/keptn/support/observability/config/prometheus/README-ja.md diff --git a/chapter-9/keptn/support/observability/config/prometheus/README-ja.md b/chapter-9/keptn/support/observability/config/prometheus/README-ja.md new file mode 100644 index 0000000..2354fa2 --- /dev/null +++ b/chapter-9/keptn/support/observability/config/prometheus/README-ja.md @@ -0,0 +1,7 @@ +# 自動生成ファイル - 変更しないでください + +## Grafana ダッシュボード - ConfigMaps + +これらのファイルは、Kubernetes内でGrafanaダッシュボードを自動プロビジョニングするために使用できます。 + +詳細情報: