Skip to content

Commit 8778f16

Browse files
committed
[Translation] Add Japanese version of Chapter 9 keptn
1 parent 7ae6f1c commit 8778f16

File tree

1 file changed

+146
-0
lines changed

1 file changed

+146
-0
lines changed

chapter-9/keptn/README-ja.md

Lines changed: 146 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,146 @@
1+
# Keptn Lifecycle Toolkit、すぐに使えるデプロイメント頻度
2+
3+
---
4+
_🌍 利用可能な言語_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md)
5+
6+
> **注意:** これは素晴らしいクラウドネイティブコミュニティの [🌟 コントリビューター](https://github.com/salaboy/platforms-on-k8s/graphs/contributors) によってもたらされました!
7+
8+
---
9+
10+
この短いチュートリアルでは、Keptn Lifecycle Toolkitを使用して、クラウドネイティブアプリケーションのライフサイクルイベントをモニタリング、観察、対応する方法を探ります。
11+
12+
## インストール
13+
14+
[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を使用してラスターを作成できます。
15+
16+
次に、Keptn Lifecycle Toolkit (KLT)をインストールできます。通常、これはKeptn Lifecycle Toolkit Helmチャートをインストールするだけで済みますが、このチュートリアルではダッシュボードを使用するためにPrometheus、Jaeger、Grafanaもインストールします。そのため、Keptn Lifecycle Toolkitリポジトリに基づいて、この例に必要なすべてのツールをインストールするためにMakefileを使用します。
17+
18+
以下を実行してください:
19+
20+
```shell
21+
make install
22+
```
23+
24+
**注意**: インストールプロセスには、必要なすべてのツールをインストールするために数分かかります。
25+
26+
最後に、KLTにモニタリングしたい名前空間を知らせる必要があります。そのために、名前空間に注釈を付ける必要があります:
27+
28+
```shell
29+
kubectl annotate ns default keptn.sh/lifecycle-toolkit="enabled"
30+
```
31+
32+
## Keptn Lifecycle toolkitの実践
33+
34+
Keptnは標準のKubernetes注釈を使用して、ワークロードを認識しモニタリングします。
35+
Conference Applicationで使用されるKubernetes Deploymentには、以下のような注釈が付けられています。例えば、Agenda Serviceの場合:
36+
37+
```shell
38+
app.kubernetes.io/name: agenda-service
39+
app.kubernetes.io/part-of: agenda-service
40+
app.kubernetes.io/version: {{ .Values.services.tag }}
41+
```
42+
43+
これらの注釈により、ツールはワークロードについてより詳しく理解できます。例えば、この場合、ツールはサービス名が`agenda-service`であることを知ることができます。`app.kubernetes.io/part-of`を使用して、複数のサービスを同じアプリケーションの一部として集約できます。この例では、各サービスを個別にモニタリングできるように、各サービスを別個のエンティティとして保持しています。
44+
45+
この例では、KeptnTaskも使用します。これにより、デプロイメント前後にタスクを実行できます。以下の非常にシンプルな`KeptnTaskDefinition`の例をデプロイできます:
46+
47+
```yaml
48+
apiVersion: lifecycle.keptn.sh/v1alpha3
49+
kind: KeptnTaskDefinition
50+
metadata:
51+
name: stdout-notification
52+
spec:
53+
function:
54+
inline:
55+
code: |
56+
let context = Deno.env.get("CONTEXT");
57+
console.log("Keptn Task Executed with context: \n");
58+
console.log(context);
59+
```
60+
61+
ご覧の通り、このタスクは実行コンテキストを出力するだけですが、ここで他のプロジェクトとの統合や外部システムの呼び出しを構築できます。Keptnの例を見ると、Slackに接続したり、負荷テストを実行したり、デプロイメントが更新後に期待通りに動作していることを検証したりするKeptnTaskDefinitionが見つかります。これらのタスクは、[Deno](https://deno.land/)(Typescriptをすぐに使用できる全なJavaScriptランタイム)、Python 3、または直接コンテナイメージを使用します。
62+
63+
以下を実行してデプロイします:
64+
65+
```shell
66+
kubectl apply -f keptntask.yaml
67+
```
68+
69+
KeptnTaskDefinitionを使用すると、プラットフォームチームはアプリケーションのデプロイメント前後のフックに組み込める再利用可能なタスクを作成できます。ワークロード(この場合はデプロイメント)に以下の注釈を追加することで、Keptnはデプロイメント実行後(および更新後)に自動的に`stdout-notification`を実行します:
70+
71+
```shell
72+
keptn.sh/post-deployment-tasks: stdout-notification
73+
```
74+
75+
Conference applicationをデプロイし、JaegerとGrafanaのダッシュボードを開きましょう。別のタブで以下を実行してください:
76+
77+
```shell
78+
make port-forward-jaeger
79+
```
80+
81+
ブラウザで[http://localhost:16686/](http://localhost:16686/)にアクセスすると、以下のように示されるはずです:
82+
83+
![jaeger](../imgs/jaeger.png)
84+
85+
そして、別のターミナルで以下を実行します:
86+
87+
```shell
88+
make port-forward-grafana
89+
```
90+
91+
ブラウザで[http://localhost:3000/](http://localhost:3000/)にアクセスします。`admin/admin`の認証情報を使用すると、以下のように表示されるはずです:
92+
93+
![grafana](../imgs/grafana.png)
94+
95+
では、第2章で行ったようにConference Applicationをデプロイしましょう:
96+
97+
```shell
98+
helm install conference oci://registry-1.docker.io/salaboy/conference-app --version v1.0.0
99+
```
100+
101+
JaegerとGrafanaのKeptnダッシュボードを確認してください。デフォルトでは、Keptn Workloadsはデプロイメント頻度を追跡します。
102+
103+
Grafanaで、`Dashboards` -> `Keptn Applications`に移動します。異なるアプリケーションサービスを選択できるドロップダウンが表示されます。Notifications Serviceを確認してください。デプロイメントの最初のバージョンのみをデプロイしたため、あまり見るべきものはありませんが、サービスの新しいバージョンをリリースした後、ダッシュボードはより興味深いものになります。
104+
105+
例えば、notifications-serviceデプロイメントを編集し、`app.kubernetes.io/version`注釈の値を`v1.1.0`に更新し、コンテナイメージに使用されるタグを`v1.1.0`に更新します。
106+
107+
```shell
108+
kubectl edit deploy conference-notifications-service-deployment
109+
```
110+
111+
変更を行い、新しいバージョンが起動して実行されたら、再度ダッシュボードを確認してください。
112+
Grafanaでは、2回目の成功したデプロイメントが表示され、私の環境ではデプロイメント間の平均時間が5.83分であり、`v1.0.0`は641秒かかったのに対し、`v1.1.0`はわずか40秒しかかからなかったことがわかります。ここには明らかに改善の余地があります。
113+
114+
![grafana](../imgs/grafana-notificatons-service-v1.1.0.png)
115+
116+
Jaegerのトレースを見ると、Keptnのコアコンポーネントの1つである`lifecycle-operator`が、デプロイメントリソースをモニタリングし、デプロイメント前後のタスク呼び出しなどのライフサイクル操作を実行していることがわかります。
117+
118+
![jager](../imgs/jaeger-notifications-service-v1.1.0.png)
119+
120+
これらのタスクは、ワークロードが実行されているのと同じ名前空間でKubernetes Jobsとして実行されます。これらのタスクのログは、jobのポッドのログをtailすることで確認できます。
121+
122+
```shell
123+
kubectl get jobs
124+
NAME COMPLETIONS DURATION AGE
125+
post-stdout-notification-25899-78387 1/1 3s 66m
126+
post-stdout-notification-28367-11337 1/1 4s 61m
127+
post-stdout-notification-54572-93558 1/1 4s 66m
128+
post-stdout-notification-75100-85603 1/1 3s 66m
129+
post-stdout-notification-77674-78421 1/1 3s 66m
130+
post-stdout-notification-93609-30317 1/1 3s 23m
131+
```
132+
133+
ID `post-stdout-notification-93609-30317`のJobは、Notification Serviceデプロイメントの更新を行った後に実行されました。
134+
135+
```shell
136+
> kubectl logs -f post-stdout-notification-93609-30317-vvwp4
137+
Keptn Task Executed with context:
138+
139+
{"workloadName":"notifications-service-notifications-service","appName":"notifications-service","appVersion":"","workloadVersion":"v1.1.0","taskType":"post","objectType":"Workload"}
140+
```
141+
142+
## 次のステップ
143+
144+
Keptn Lifecycle Toolkitの機能と特徴についてさらに詳しく学ぶことを強くお勧めします。この短いチュートリアルで見たのは基本的な部分だけです。サービスのデプロイ方法をより細かく制御するために、[KeptnApplication](https://lifecycle.keptn.sh/docs/concepts/apps/)の概念を確認してください。Keptnを使用すると、どのサービスとのバージョンをデプロイできるかについて、詳細なルールを定義できます。
145+
146+
`app.kubernetes.io/part-of`注釈を使用して複数のサービスを同じKubernetesアプリケーションの一部としてグループ化することで、サービスのグループに対して事前および事後のアクションを実行でき、個々のサービスだけでなく、セット全体が期待通りに動作していることを検証できます。

0 commit comments

Comments
 (0)