AKSを活用した社内向けイベント支援プラットフォームをリリースした話

AKSを活用した
社内向け
イベント支援プラットフォーム
をリリースした話
第23回 Tokyo Jazug Night
2019/11/20
Shingo Kawahara
1

自己紹介
• 河原慎吾
• 株式会社セゾン情報システムズ
• テクノベーションセンター
• クラウド/インフラ/コンテナ担当
• 経歴
• VMwareベースの自社クラウド構築/運営
⇓⇓⇓
• パブリッククラウド活用推進
• 好きな漫画
• ワンピース
2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみたかったから！！
24

Kubernetesじゃなくてもいいんじゃね？
• 今回くらいの規模ならWeb App for Containerでいける
• コンテナ化しなくてWeb Appでもいける
25

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

全体像
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)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GHE drone
ACR
DataSpider社員マスタ
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
LogAnalytics Monitor
Internet
push
Internet
オフィス
27

全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GHE drone
ACR
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
Internet
push
Internet
オフィス
28

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

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"
30

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

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

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

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

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

全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GHE drone
ACR
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
Internet
push
Internet
オフィス
36

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

全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GHE drone
ACR
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
Internet
push
Internet
オフィス
38

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

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

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

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

• 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
43

• 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:
44

• https://qiita.com/shingo_kawahara/items/df8ae2c9d30ea09d7026
45

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

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

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

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

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

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
51

Helm rollback
$ helm rollback cert-manager 1
52

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
53

Helm
• https://qiita.com/shingo_kawahara/items/840287e06522bf2d5083
54

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

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

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

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

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
59

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

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

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

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

全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GHE drone
ACR
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
Internet
push
Internet
オフィス
64

Graph API
• Microsoft Cloudサービスリソースへのアクセスを可能にするRESTful
Web API
• 今回の開発では、以下のような機能をGraph APIで実現しています
• 申込みをすると、自動的にOffice 365 Outlookカレンダーに予定を登録する
• 申込み時に、上司に承認メールを送る
• 上司から却下されたときにメールを送る
• Azure ADからユーザ一覧を取ってくる
65

全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GHE drone
ACR
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
Internet
push
Internet
オフィス
66

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

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

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

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

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

• https://qiita.com/shingo_kawahara/items/be44def8c0bf89c86371
72

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

k9s
• kubectlでできることを簡単に、且つ視認性よくしたツール
• logやdescribeの確認など使いやすくて便利！
74

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

全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GHE drone
ACR
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
Internet
push
Internet
オフィス
76

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

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

Azure Container Registry 脆弱性スキャン
• 先日のIgnite 2019で、ACRの脆弱性スキャン機能がプレビューリリース
されました！
• 早速組み込んでみました。
• 脆弱性スキャン機能は、Security Centerに統合されているため、ACRか
らではなく、Security Centerから設定します。
• Security Centerから設定が終わると、ACRにイメージをPushしたら自動
的に脆弱性スキャンされるようになります
79

• こんな感じでACRの中で脆弱性のあるイメージが分かります。
80

• 更にイメージIDで掘り下げていくと、このイメージにはレベル中の脆弱
性が1件あることが分かります。
81

• $0.29 / Scan なので頻繁にPushする環境だと注意しないといけない
• いまのところ通知機能がない
• スキャン結果の詳細をSlack通知したり、RESTAPIで取れるようになると使いどころ
が広がってくる
• とはいえ、Azureサービスの中で脆弱性スキャンできるのは非常に便利な
ので、今後どんどん使いやすくなることに期待です！！
82

• https://qiita.com/shingo_kawahara/items/445e80d4820f86f387c6
83

全体像
Helm
nginx-Ingress
ClusterIP
Pod
Front
Pod
Front
ClusterIP
Pod
Backend
Pod
Backend
Helm
cert-manager
SQLDB Blob
ServiceEndpoint
ScaleSets
AKS
vNet(Prod)
ScaleSets
AKS
vNet(Staging)
SQLDB Blob
ServiceEndpoint
Developer
EndUsers
Internet
GHE drone
ACR
ExRoute
PublicPeering
ExRoute
PublicPeering
O365
AAD GraphAPI
Internet
Internet
push
Internet
オフィス
85

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

やりたいこと
• リポジトリがmasterにマージされたらAKS（ステージング）に自動デプ
ロイする
• リポジトリでgit tagが打たれたら（リリース用タグ）、AKS（本番）に自
動デプロイする
87

.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のコミットハッシュ値を指定可能
89

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ブランチにマージされたら動く
90

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でもいけそう
91

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

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]
93

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

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

CI/CD
• https://qiita.com/shingo_kawahara/items/9bf791e6ecbc1d1ecd32
96

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

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

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

AKSを活用した社内向けイベント支援プラットフォームをリリースした話

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to AKSを活用した社内向けイベント支援プラットフォームをリリースした話

Similar to AKSを活用した社内向けイベント支援プラットフォームをリリースした話 (20)

AKSを活用した社内向けイベント支援プラットフォームをリリースした話

Editor's Notes