July Tech Festa 2020 Dトラック 11:00～ に登壇させて頂いた資料です

1. AKSを活用した
内製教育支援プラットフォーム
をリリースした話
July Tech Festa 2020
2020/7/25
Shingo Kawahara
1

2. 自己紹介
• 河原慎吾
• 株式会社セゾン情報システムズ
• テクノベーションセンター 先端技術部 部長
• 経歴
• オンプレLinuxやラッキングなど
⇓⇓⇓
• VMwareベースの自社クラウド構築/運営
⇓⇓⇓
• パブリッククラウド活用推進
⇓⇓⇓
• 先端技術活用推進/組織運営
• 好きなAzureのサービス
• Azure Logic Apps 2

3. Qiita
• Azure中心に書き溜めているので参考になればうれしいです！
• https://qiita.com/shingo_kawahara
• フォローお待ちしております♪
3

4. 会社概要
4
◇ 社 名 株式会社セゾン情報システムズ SAISON INFORMATION SYSTEMS CO.,LTD.
◇ 設 立 年 月 日 1970 年 9月 1日
◇ 代 表 取 締 役 社 長 内 田 和 弘
◇ 資 本 金 1,367百万円
◇ 事 業 内 容
 フィナンシャル IT サービスビジネス
 流通 IT サービスビジネス
 リンケージビジネス
 HULFTビジネス
◇ 年 間 売 上 高 23,560百万円（2020年 3月期 連結）
◇ 社 員 数 716名（2020年 3月末現在 連結）
◇ 上 場 市 場 東京証券取引所JASDAQスタンダード市場 （証券コード 9640 / 1993年 11月公開）
◇ 主 要 株 主 （ 上 位 3
社 ）
 株式会社クレディセゾン
 イーシーエム エムエフ
 イーシーエム マスターフアンド エスピーブイワン
◇ グ ル ー プ 会 社
 世存信息技術（上海）有限公司
 HULFT Pte. Ltd.
 HULFT, Inc.
◇ 認 定 ・ 届 出 総務省 電気通信事業者届出
◇ 品質・セキュリティ
へ の 取 り 組 み
プライバシーマーク付与 認定取得 登録番号 【11820059】
JISQ27001:2014（ISO/IEC27001:2013）認証取得 登録番号 【JMAQA-S030】

5. Agenda
• 内製教育
• デザインプロセス
• Azure Kubernetes Service
• Azure ARM Template
• Kubernetes(ingress/cert-manager/helm/hpa)
• Monitor/Log Analytics
• k9s
• Azure Container Registry
• CI/CD
• drone.io
5

6. 内製教育
6

7. テクノベーションセンターについて
• 2016年4月に設立
• メンバは全員が専任。兼務なし。
• 存在意義
• 外部へ積極的に発信し、ブランドの向上とともに案件の創出
につなげる
• 事業部の先端技術分野への進出を支援する
• 全社の技術スキルを高める
内製教育支援プラットフォームの必要性
7

8. 内製教育
• 従来の技術教育は、受講者自身が外部の研修プログラムを受講
する形式でした
• しかし、学んだことを実践で活かす機会がないことが多く、ま
た必要なときがきても内容を忘れてしまっているといった課題
がありました
• 自分たちで教育を行うことで以下のようなメリットがあります
• 講師は常に社内にいるので、いざ必要になった時や実業務の中で発生
した疑問をすぐに聞くことができる
• 講師は現場の状況を把握することができ、教育を通じて技術支援を行
うことができる
• 講師自身も技術力アップ！
8

9. グレゴリオ
• 全社員が利用可能な、内製教育支援プラットフォームです。
• 現状の社内イベント作成＆申し込みに対する課題を解決するた
めに開発しました。
• 名前の由来は、「社内で開催されるイベントをカレンダーにプ
ロットして俯瞰する」という当初のコンセプトから、世界中の
カレンダーで用いられているグレゴリオ暦をプロジェクトコー
ドとして命名しました。
9

10. グレゴリオの由来
ローマの偉い人
グレゴリウス13世 グレちゃん
10

11. 開発の経緯/当初の課題
• 当初の課題って？
• いつどんなイベント、勉強会が開催されているかわからない
• スケジュールが一覧で見れない
• 自分の予定表に追加するのを忘れる
• ゆえにリマインドされない
• 申請がめんどくさい
• 開催者は集計が大変
など
11

12. グレゴリオとは
• 何ができるの？
• 社内イベントの検索、申し込み、募集ができます。
• 申請者の上長は申請を承認、差戻できます。
• O365アカウントと連携し、申し込んだイベントは自動的にカレンダー
に登録されます。
• イベントの作成、募集、開催ができ、アンケートの回収まで行えます。
12

13. 13
2019年10月に社内リリース！

14. デザインプロセス
14

15. デザインプロセス
• システム開発を始める前に、2か月間デザイン手法を用いて設
計を行いました
• 非常に有効だったため簡単に紹介してからAKSの話しに入りた
いと思います
15

16. デザインプロセス
• Gregorioにおけるデザインプロセスの流れ
16

17. ユーザーインタビュー
• インタビューガイドを事前に検討/作成する
• 承諾を得て動画と音声を記録する
• 誘導型質問を避けてインタビューする
17
• インタビュー後の分析
• 議事録から重要箇所をカード化する
• グループ化する
• 図解化/アウトライン化する
• 検証、考察する

18. ペルソナの作成
• ペルソナとは
• 商品やサービスのターゲットとなる架空のユーザー像
• その人物が実在しているかのように、年齢・性別・居住地・職業・役
職・年収・趣味・価値観・家族構成・休日の過ごし方・ライフスタイ
ル・ネットリテラシーなどリアリティのある詳細な情報を設定する
• ペルソナを作成するメリット
• ユーザーファーストが実現されやすい
• チーム内で、ターゲットの人物像への認識をより統一できる
• 「こういう時ペルソナならどうするかな？」みたいな会話が生まれる
18

19. ペルソナの作成
• インタビューの分析結果から共通点を抽出し人物像を当ててい
く
19

20. カスタマージャーニーマップの作成
感情が落ち込んでいるポイントを優
先課題とする
20

21. 分析から見えてきたニーズ
• イベントを一覧（カレンダー）で見たい
• 申し込んだらOutlookの予定に自動で追加してほしい
• 新しいイベントが追加されたら教えてほしい
• 自分が参加したイベントの履歴が見たい
• アンケートのリマインドが欲しい
など
21

22. プロトタイプの作成
• ペーパープロトタイピング
• イメージが固まったら紙に清書
してProttで動きを付けて確認
する
22

23. ユーザーテスト
• モックアップを作成して実際のユーザーに操作してもらう
• ユーザーにはタスクの説明のみを行い、期待する行動をとって
もらえるかがポイントとなる（例：自分が申し込んだ勉強会の
申し込み内容を確認してください）
• インタビュー同様音声の録音と画面収録
• 結果から導線やコンテンツの位置、大小などを調整していく
23

24. デザインプロセスまとめ
• デザインプロセスには時間がかかる
• ペルソナやマップをアウトプットすることで後で立ち返れるこ
とは大きなメリット
• 全員が同じ方向/イメージ（共通認識）を持って開発に取り組
める
• デザインプロセスは前提となるフレームワークなどの知識は必要だが、
基本的には誰でも参加できる
• 今回の開発では役割に関係なくチーム全員でこの作業を行ったことが
結果的に良かった
24

25. Azure Kubernetes Service
25

26. そもそもなぜ
Kubernetesを採用したのか？
26

27. 使ってみたかったから！！
27

28. Kubernetesじゃなくてもいいんじゃね？
• 今回くらいの規模なら他のサービスで実現できる
• Web App for Container
• コンテナ化しなくてWeb Appでもいける
28

29. それでも使ってみたいんだ！
• 勉強してKubernetesの知識は付いたが、実際にアプリケー
ションをリリースして、その後運用して、といったことを経験
しておかないと、Kubernetesの良さや苦労がほんとの意味で
分からない
• そういったリアルな声を社内に伝えていくのがテクノベーショ
ンセンターのミッション
• あえて先端技術を選ぶ！
29

30. 全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
NameSpace cert-manager
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging&Dev)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GitHub
Enterprise
drone
ACR
社員マスタ
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
LogAnalytics Monitor
Internet
push
Internet
オフィス
30

31. 全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
NameSpace cert-manager
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging&Dev)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GitHub
Enterprise
drone
ACR
社員マスタ
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
LogAnalytics Monitor
Internet
push
Internet
オフィス
31

32. Azure ARM Template
• Azureリソースの構成情報をJSONに落とし込むことで、
Infrastructure as Codeを実現することができる
• コードをGitHubで管理することで、パラメータシートの代わり
となり得る
• ただし、コード化することにこだわりすぎないようにしている。
初期セットアップがだれがやってもすぐに実現できる。くらい
に考えている。
32

33. Azure ARM Template vNet構築例
"resources": [
{
"apiVersion": "2018-10-01",
"type": "Microsoft.Network/virtualNetworks",
"name": "[parameters('vnetName')]",
"location": "[parameters('location')]",
"tags": {
"Environment": "[parameters('environmentTag')]",
"Service": "[parameters('serviceTag')]"
},
"properties": {
"addressSpace": {
"addressPrefixes": [
"[parameters('vnetAddressPrefix')]"
]
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vnetName": {
"value": “testvnet"
},
"vnetAddressPrefix": {
"value": “xx.xx.xx.xx/24"
},
"subnetPrefix": {
"value": “xx.xx.xx.xx/24"
},
"subnetName" : {
"value": “testsubnet"
azuredeploy.json(一部抜粋) azuredeploy.parameters.json(一部抜粋)
$ az group deployment create -g $RG -n vnet-create --mode Incremental --template-file azuredeploy.json `
--parameters "@azuredeploy.parameters.json"
33

34. Azure ARM Template GitHub構成
• Azureリソース毎にフォルダを分けて管理
• ステージング用にはパラメータファイルのみを分けて作成
34

35. Azure ARM Template Secret情報の取り扱い
• 例えばSQL Databaseの管理者パスワードなど、GitHub上で管
理できないSecret情報は以下のように指定しています
$ az group deployment create -g $RG -n sqldb-create --mode Incremental --template-file azuredeploy.json `
--parameters "@azuredeploy.parameters.json" `
--parameters sqlAdministratorLoginPassword=[Your Any Password]
35

36. Azure-Quickstart-Templates
• GitHub.comに公開されているクイックスタートテンプレート
が超便利で、これをベースに改良するのがおススメ
• https://github.com/Azure/azure-quickstart-templates
36

37. Azure ARM Template
• もし壊れてもすぐに一から作り直せる安心感はいい
• AKS環境の場合、頻繁に変更が入るのは、Kubernetesの中
（マニフェストファイル）なので、ARM Templateファイルの
変更はまれ。
• コード化に拘りすぎないようにする
37

38. Azure ARM Template
• 詳細な手順はQiitaにまとめているので参考にしてください
• https://qiita.com/shingo_kawahara/items/c65ed88da717f52c4f79
38

39. 全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
NameSpace cert-manager
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging&Dev)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GitHub
Enterprise
drone
ACR
社員マスタ
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
LogAnalytics Monitor
Internet
push
Internet
オフィス
39

40. ステージング環境
• 本番とステージングで異なる設定は、
• ステージングは監視していない
• ステージングは開発環境と同居している
• AKSのバージョンを本番とステージングで完全に一致させたいのであれば、
本番環境を作った時と同じタイミングでステージングも作ったほうがよい
• 1.X.Y
• patch部分のアップデートが早くて、数か月で過去バージョンのクラスターが作れな
くなってしまう
• ただ、本番もステージングも両方ともアップデートしてしまえばバージョ
ンは一致するのでそこまで拘らなくてもよい
40
[major].[minor].[patch]
Example:
1.12.14
1.12.15

41. 開発環境
• 当初はステージングと本番だけだったが、運用を始めてみると手軽に更新
ができる開発環境が必要になってきた
• ステージングと同一k8sクラスターにNamespaceを分けて作成
• 開発環境k8sクラスターがあったほうが便利だが、このあたりの構成はコスト次第
41

42. 全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
NameSpace cert-manager
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging&Dev)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GitHub
Enterprise
drone
ACR
社員マスタ
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
LogAnalytics Monitor
Internet
push
Internet
オフィス
42

43. Kubernetesコンポーネント
• AKSではMasterノード部分の設定は変更できません
43https://kubernetes.io/docs/concepts/overview/components/

44. Kubernetes基本的なオブジェクト
• Pod
• Kubernetesクラスターにコンテナを展開するときの最小単位
• Pod内に1つ以上のコンテナが含まれる
• ReplicaSet
• Podのレプリケーションを管理する
• Deployment
• ReplicaSetのローリングアップデートを管理する
44
Deployment ReplicaSet
Pod
Container
Pod
Container

45. Kubernetes
• Nginx Ingressを使ったAKS構成はほぼ公式マニュアル通り作
成
• https://docs.microsoft.com/ja-jp/azure/aks/ingress-static-ip
45

46. Ingress Controllerでネットワーク制御
• 公式マニュアル通りだと、アクセス元のIPアドレスを制御せず
にどこからでもアクセス可能となります。（インターネットに
公開された状態）
• 今回の要件だと、社内からのみアクセス可能にする必要があっ
たため、Ingress Controllerでアクセス元IP制限を加えました
46

47. Ingress Controllerでネットワーク制御
• Ingress Controller作成時に
「controller.service.externalTrafficPolicy=Local」オプショ
ンを付与する
$ helm install stable/nginx-ingress
--namespace [Your Namespace]
--set controller.service.loadBalancerIP="[Public IP]"
--set controller.replicaCount=2
--set controller.service.externalTrafficPolicy=Local
47

48. Ingress Controllerでネットワーク制御
• Ingressルートを作成する際のマニフェストで、アノテーショ
ン「nginx.ingress.kubernetes.io/whitelist-source-range」
を付与して作成する。
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: hello-world-ingress
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/whitelist-source-range: xxx.xxx.xxx.xxx/32,yyy.yyy.yyy.yyy/32
spec:
48

49. Ingress Controllerでネットワーク制御
• 詳細な手順はQiitaにまとめているので参考にしてください
• https://qiita.com/shingo_kawahara/items/df8ae2c9d30ea09d7026
49

50. Let’s Encrypt
• 認証局(CA)として、90日間有効なSSL/TLSサーバ証明書を無
料で発行します。
• 設定はAKSの公式マニュアル通りにいけます。
50

51. cert-manager
• さまざまな発行元からのTLS証明書の管理と発行を自動化する
Kubernetesアドオン
• Let’s Encryptにも対応
• cert-managerを使うことで、90日更新切れの前に自動更新し
てくれます。
• 設定はAKSの公式マニュアル通りにいけます。(Helm install)
• Ingress-Controllerでネットワーク制御をしている環境でも自
動更新は問題なく動きました。
51

52. Helm
• Kubernetesのパッケージマネージャ
• cert-managerを使いたい場合、Deploymentや
ServiceAccountなど様々なリソースが必要ですが、helmでひ
とまとめになっているイメージ
52

53. Helm install
$ helm install
--name cert-manager
--namespace cert-manager
--version v0.7.0
jetstack/cert-manager
53

54. Helm upgrade
$ helm upgrade
--version v0.8.0 cert-manager jetstack/cert-manager
54

55. Helm history
$ helm history cert-manager
REVISION UPDATED STATUS CHART DESCRIPTION
1 Wed Jun 19 16:35:26 2019 SUPERSEDED cert-manager-v0.7.0 Install complete
2 Wed Oct 16 19:49:15 2019 DEPLOYED cert-manager-v0.8.0 Upgrade complete
55

56. Helm rollback
$ helm rollback cert-manager 1
56

57. Helm history
$ helm history cert-manager
REVISION UPDATED STATUS CHART DESCRIPTION
1 Tue Sep 24 23:08:30 2019 SUPERSEDED cert-manager-v0.7.0 Install complete
2 Wed Oct 16 19:34:38 2019 SUPERSEDED cert-manager-v0.8.0 Upgrade complete
3 Wed Oct 16 19:42:03 2019 DEPLOYED cert-manager-v0.7.0 Rollback to 1
57

58. Helm
• 詳細な手順はQiitaにまとめているので参考にしてください
• https://qiita.com/shingo_kawahara/items/840287e06522bf2d5083
58

59. cert-managerのバージョンアップ理由
• ある日こんなメールが届いたから・・・
Cert-managerは、Let's Encryptのサーバーに継続的に本当に過剰なトラフィックを送信するトラフィックパ
ターンに陥ることがあります。
これを緩和するため、2019年11月1日から、バージョン0.8.0（現在のsemverマイナーリリース）未満のcert-
managerからのすべてのトラフィックのブロックを開始する予定です。
59

60. k8sアップデート頻度
• 2019年10月にリリースしてから、9か月で2回 k8sクラスター
のバージョンアップをしています。
• k8s周りはアップデートの速度が速いので注意が必要！！
60

61. アプリケーション
• アプリケーションは、
• フロントエンド（Nuxt.js）
• バックエンド（Spring Boot）
• それぞれ別のPodで動作させています。
61
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
NameSpace

62. リソース制限
• アプリケーション毎に、リソース制限設定をしています。
• Requests（下限）
• ここで指定した値を確保できなければPodスケジューリングされない
• Limits（上限）
• そのコンテナが利用できるリソースの上限値
62

63. リソース制限
• 実際の使用量と、クラスターノード数を考慮して設定
containers:
- name: front
image: xxx
imagePullPolicy: Always
ports:
- containerPort: 80
name: front-http
resources:
requests:
cpu: 100m
memory: 200Mi
limits:
cpu: 200m
memory: 500Mi
63

64. Horizontal Pod Autoscaler
• Podのリソース使用状況に応じて、自動的にスケールアウトす
る機能
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v1
metadata:
name: front-hpa
labels:
environment: prod
spec:
scaleTargetRef:
kind: Deployment
apiVersion: apps/v1
name: front
minReplicas: 2
maxReplicas: 4
targetCPUUtilizationPercentage: 50
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
NameSpace
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
NameSpace
Pod
Front
Pod
Front
64

65. ヘルスチェック
• デフォルトだと、Kubernetesがプロセス死活チェックして、
プロセスが異常終了したら自動的に復旧させる
• LivenessProbe/ReadinessProbeを使うことで、HTTPベース
のチェックや、コンテナ内でコマンドを実行して正常終了する
かといったヘルスチェックが可能
• LivenessProbe
• このチェックがNGの場合、Podを再起動する
• ReadinessProbe
• このチェックがNGの場合、Podは再起動せず、Podへのトラフィック
を止める
65

66. ヘルスチェック
livenessProbe:
httpGet:
path: /health
port: front-http
scheme: HTTP
initialDelaySeconds: 15
timeoutSeconds: 2
periodSeconds: 10
successThreshold: 1
failureThreshold: 5
• /healthにHTTP GETリクエストを実行する
• エラーだとPod再起動
66

67. ヘルスチェック
initialDelaySeconds: 15
timeoutSeconds: 2
periodSeconds: 10
successThreshold: 1
failureThreshold: 5
• initialDelaySeconds
• 最初にコンテナが起動されてから、ヘルスチェックするまでどれくらい待つか
• timeoutSeconds
• タイムアウトまでの秒数
• periodSeconds
• ヘルスチェック間隔
• successThreshold
• 何回ヘルスチェックが成功したらPodが正常だと判断するか
• failureThreshold
• 何回ヘルスチェックが失敗したらPodが異常だと判断するか
67

68. ヘルスチェック
• 例えば、initialDelaySecondsが短すぎると、起動しきる前にまたコンテ
ナを再起動してしまい、永遠と起動しない状態になってしまう
• 例えば、periodSecondsが長すぎると、検知までに時間が掛かってしまう
• 今回のアプリケーションだと、バックエンド（Spring Boot）のほうが、
フロントエンド（Nuxt.js）よりも起動に時間が掛かるので、
initialDelaySecondsは変えている
• これらの値は繰り返し試しながら最適値を見つける必要がある
68

69. 全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
NameSpace cert-manager
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging&Dev)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GitHub
Enterprise
drone
ACR
社員マスタ
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
LogAnalytics Monitor
Internet
push
Internet
オフィス
69

70. Azure Monitor
• Azureポータルからk8sクラスターの各メトリックを確認する
ことが可能
70

71. Azure Log Analytics
• Log Analytics連携設定をしておくと、各種メトリックやstdoutを集約す
ることができるので、分析が可能に。
• 以下はKubernetesクラスターの1か月間の平均CPU使用率の推移
71

72. 障害時アラート
• 基本的にはコンテナーダウンしても自己復旧する仕組み
• ただし、以下のような項目は、Log Analyticsを活用しアラー
ト通知している
• AKSクラスターのCPU使用率が閾値を超えた
• AKSクラスターのディスク使用率が閾値を超えた
• AKSクラスターのメモリ使用率が閾値を超えた
• AKSクラスター内のコンテナーのステータス異常
72

73. アラートルール
Log Analyticsで実行するクエリ
アラート条件
15分毎に、30分前までの期間を対象とする
73

74. 障害時アラート
• 監視間隔とコスト
• 監視間隔15分だと、$0.5/月
• 最短監視間隔は5分
• 5分だと、$1.5/月
• このへんはシステム要件に合わせて設定
• アラート検知したらSlackに通知する
74

75. 障害時アラート
• 詳細な手順はQiitaにまとめているので参考にしてください
• https://qiita.com/shingo_kawahara/items/be44def8c0bf89c86371
75

76. Azure Log Analytics
• アラート機能としては使えますが、実際障害があったときに、Log
Analyticsから原因調査するのはちょっと辛い
• 細かくログを見る場合は、kubectl logsやdescribeといったコマンドベー
スで調査したほうがやりやすい
76

77. AKSクラスターノード障害の注意点
• ノード障害が発生すると、Kubernetesがそれを検知するまで5分掛かりま
す。
• これはマスターノードのkube-controller-managerの設定（--pod-
eviction-timeout）がデフォルト値5分であるためです。
• AKSはマネージドサービスなので、マスターノードの設定を変更すること
ができません。
• 今回のケースだと、他のノードにPodが分散配置されるので業務影響はお
きませんが、1Podで動作するもの（例えばStatefulSet）は、この影響を
受けるので注意が必要です。
77

78. 全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
NameSpace cert-manager
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging&Dev)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GitHub
Enterprise
drone
ACR
社員マスタ
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
LogAnalytics Monitor
Internet
push
Internet
オフィス
78

79. Azure Container Registry
• コンテナイメージを格納するプライベートレジストリ
• Kubernetesマニフェストファイルの中で、ACRのイメージを指定するこ
とで、AKSがACRから直接pullして、コンテナ起動する
spec:
containers:
- name: front
image: [ACR-URL]/[Image Name]:[Tag]
imagePullPolicy: Always
ports:
- containerPort: 80
name: front-http
79
Developer
① kubectl apply
② pull

80. Azure Container Registry
• AKS作成時にサービスプリンシパルを指定しますが、そのサービスプリン
シパルがACRPull権限を持っていないと、コンテナデプロイ時にエラーに
なるので、ACRのIAM設定で権限付与しておきます
80

81. Azure Container Registry 脆弱性スキャン
• 2020年3月にACRのコンテナイメージ脆弱性スキャン機能がGAされまし
た
• 脆弱性スキャン機能は、Security Centerに統合されているため、ACRか
らではなく、Security Centerから設定します。
• Security Centerから設定が終わると、ACRにイメージをPushしたら自動
的に脆弱性スキャンされるようになります
81

82. Azure Container Registry 脆弱性スキャン
• こんな感じでACRの中で脆弱性のあるイメージが分かります。
82

83. Azure Container Registry 脆弱性スキャン
• 更にイメージIDで掘り下げていくと、このイメージにはレベル中の脆弱
性が1件あることが分かります。
• スキャン結果はAPIで取得することも可能です
83

84. Azure Container Registry 脆弱性スキャン
• 詳細な手順はQiitaにまとめているので参考にしてください
• https://qiita.com/shingo_kawahara/items/445e80d4820f86f387c6
84

85. CI/CD
85

86. 全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
NameSpace cert-manager
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging&Dev)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GitHub
Enterprise
drone
ACR
社員マスタ
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
LogAnalytics Monitor
Internet
push
Internet
オフィス
86

87. CI/CD
• オンプレ（プライベートクラウド）上に、GitHubEnterpriseを導入しており、コードは
全てGHE上で管理している
• GitHub.comならAzure DevOpsという選択肢だが、GHEはDevOpsと繋がらないので、
CIツールは別のツールを選択する必要がある
• 厳密にはGHEをインターネットにさらせばいいがそんなことはできない
• CIツールはコンテナと親和性の高いdrone.ioを選定
• drone自体もコンテナとして動作する
87

88. やりたいこと
• ソースコードがdevelopブランチにマージされたらAKS（開発）に自動デ
プロイする
• ソースコードがmasterブランチにマージされたらAKS（ステージング）
に自動デプロイする
• リポジトリでgit tagが打たれたら（リリース用タグ）、AKS（本番）に自
動デプロイする
88

89. やりたいこと
89
GitHub
Enterprise
Drone CI

90. .drone.yml
kind: pipeline
name: staging
steps:
- name: build
image: node:10.16.0-alpine
environment:
GREGORIO_CLIENT_ID:
from_secret: GREGORIO_CLIENT_ID_STAG
GREGORIO_TENANT_ID:
from_secret: GREGORIO_TENANT_ID_STAG
GREGORIO_API_BASE_URL:
from_secret: GREGORIO_API_BASE_STAG_URL
GREGORIO_VERSION: ${DRONE_COMMIT_SHA:0:8}
commands:
- yarn install
- yarn run build
- name: test
image: node:10.16.0-alpine
commands:
- yarn run test
buildステップ
testステップ
secretはdroneのWebUIから事前設定
GitHubのコミットハッシュ値を指定可能
90

91. ACR Push step
- name: publish
image: plugins/docker
settings:
dockerfile: docker/Dockerfile
username:
from_secret: USERNAME
password:
from_secret: PASSWORD
repo: xxx.azurecr.io/yourimage
registry: xxx.azurecr.io
tags:
- latest
- ${DRONE_COMMIT_SHA:0:8}
when:
branch:
- master
event:
- push
ACRのシークレット情報
ACRのリポジトリ情報
このDockerfileでビルド
latestとコミットハッシュ値をタグにする
このステップは、
masterブランチにマージされたら動く
91

92. AKS Deploy step
- name: deploy
image: azurecli:latest
pull: if-not-exists
environment:
AZURE_APPLICATION_ID:
from_secret: AZURE_APPLICATION_ID
AZURE_SECRET:
from_secret: AZURE_SECRET
AZURE_TENANT_ID:
from_secret: AZURE_TENANT_ID
IMAGE_TAG: ${DRONE_COMMIT_SHA:0:8}
commands:
- echo $IMAGE_TAG
- /usr/bin/az login --service-principal -u $AZURE_APPLICATION_ID
-p $AZURE_SECRET --tenant $AZURE_TENANT_ID
- /usr/bin/az aks install-cli
- /usr/bin/az aks get-credentials -g [Resource Group Name] –n
[k8s Clouster Name]
- kubectl apply –f docker/[k8s Manifest file] –n [Namespace Name]
- kubectl get po -n [Namespace Name]
- kubectl set image deployment.apps/[Pod Name] [Pod
Name]=[ACR Server URL]/[Repository Name]:$IMAGE_TAG -n [k8s
NameSpace]
when:
branch:
- master
event:
- push
azurecliコンテナ内でkubectlのインストールから
AKSクレデンシャル設定まで行う
kubectl applyでAKSにデプロイ
次ページで解説
独自に作ったazurecliコンテナを使った
公式のmcr.microsoft.com/azure-cliでもいけそう
92

93. latestを使いたくない！
• イメージタグのlatestは便利な反面、現在どのバージョンが動作している
かが分かりにくいため、本番利用は避けたい
• front:1.0.0 といったバージョン情報をイメージタグに使いたい
• その為にはKubernetesマニフェストファイルで動的に変更できなければ
ならない
• droneではイメージタグ部分を動的に変更できなかった
containers:
- name: front
image: xxx.azurecr.io/front:latest
imagePullPolicy: Always
93

94. latestでデプロイした直後に無理やり変更
• drone.ymlの中であれば、Gitのコミットハッシュが環境変数として使え
るので、これをイメージタグとする
• 一度latestで書かれたマニフェストファイルをデプロイして、起動しきる
前にkubectl set imageで、イメージタグを差し替える（latestも
IMAGE_TAGも中身は同じ。タグが違うだけ）
• 他のCIツールだとマニフェストファイルに環境変数設定して、簡単に動的
にできるかも
- kubectl apply –f docker/[k8s Manifest file] –n [Namespace Name]
- kubectl set image deployment.apps/[Pod Name] [Pod Name]=[ACR Server URL]/[Repository Name]:$IMAGE_TAG -n [k8s NameSpace]
94

95. リストア方法
• リリース後に不具合が見つかって、前回リリースバージョンに戻したい場
合、以下のような前回リリース時のタグが打たれたDroneジョブを見つけ
て選択します。
• あとはRESTARTボタンを押すだけで前回バージョンに戻ります。
95

96. CI/CD
• CIは比較的早く作れると思うが、CDを絡めるとなると難易度が上が
る。
• CD環境はできるだけ早く作っておいたほうがいい。色々ハマって結
局できたのはリリース直前になってしまった。
• 前向きに捉えるならリリース前に環境作れてよかった。リリース後
だと更に難易度が上がる。
• リストアのしやすさで設計したのがよかった
• KubernetesへのCD環境を作るのは、DevとOps双方の協力と理解
が必要不可欠。
• しかし、CI/CD環境が構築できたあとの世界は利便性が全然ちが
う！！最高！！
96

97. CI/CD
• 詳細な手順はQiitaにまとめているので参考にしてください
• https://qiita.com/shingo_kawahara/items/9bf791e6ecbc1d1ecd32
97

98. まとめ
98

99. まとめ
• 障害が発生しても基本的には自動復旧されるし、負荷が上がっ
てもオートスケールされるため、意外とKubernetes運用（マ
ネージドサービスの場合）は大変ではない印象
• ただし、まだ新しめの技術であり、Kubernetes自体の全容も
複雑なため、基盤部分の障害が起きたときの対処には時間が掛
かりそう
• 全てコード化しておいて、すぐに作り直せるようにしておくことが重
要
• 最悪作り直せばいいという安心感
99

100. まとめ
• もっと大規模で、高いSLAを求められるシステムを運用する場
合は、Kubernetes専任のチームがいたほうがよい
• Kubernetes自体もエコシステムも変化が早いのでバージョン
アップは常に考えておかないといけないし、情報のアンテナを
張っておかないといけない
100

101. まとめ
• CI/CDは劇的に生産性が上がるため早めに作ったほうがよい！
• Kubernetesのような旬な技術に触れるのは自身の成長につな
がるし心地いい
• まずは今回のような小規模な社内システムから初めてみるのも
よい経験になるんじゃないかなと思います！
101