2019年11月21日　ビヨンド勉強会#21 株式会社エクストランス　技術部システムオペレーション課 北岡 俊樹 「社内システムにGKEを組み込んだお話」

1. 『初心者向け』
社内システムに
GKEを組み込んだ
お話

2. profile:
name: Toshiki Kitaoka
company: X-TRANS システムオペレーション課 サブリーダ
Job:
- Infrastructure engineer
- Handyman
favorite:
- GCP
- kubernetes
- terraform, Ansible
- Laravel, Vue.js
- golang, Python, PHP
- Zabbix
- AR
twitter
- account: @10key3
2

3. 3
目次
➜ システムの紹介
➜ 基盤選択の経緯
➜ 日々の運用
➜ 良かった点・課題
➜ まとめ

4. 目的

5. 明日から始めれる！という
自信をもって帰ってください。
5

6. システムの紹介

7. GKE
7

8. 8
GKE とは
➜ GCP の Kubernetes マネージドサービ
ス
➜ マスターは無料
ノードとして起動している
ComputeEngineの費用のみ

9. GKE 以外でもご参考にしていただけるかと
9

10. CMDB
10

11. 11
CMDB とは
➜ ITサービスにおける構成情報を管理す
るデータベース
➜ ISO20000 に準拠
➜ 機密性、可用性、完全性を常に保つ必
要がある
➜ IPアドレス及びインベントリの自動収集
を行うアプリを k8s で動かす

12. 12
App Engine Cloud SQL
Kubernetes
Engine
Cloud Source
Repositories
Cloud Build Container
Registry

13. 13
App Engine Cloud SQL
Kubernetes
Engine
Cloud Source
Repositories
Cloud Build Container
Registry

14. 14
Kubernetes 構成
➜ 2種類のPod
➜ 下記のアプリの動作用
○ IPアドレス管理
○ インベントリ収集
➜ Ingress を設置し下記処理を任せる
○ SSL処理
○ ルーティング
○ 負荷分散 …負荷かかんねぇ
➜ DeploymentリソースでPod管理

15. 15
App Engine Cloud SQL
Kubernetes
Engine
Cloud Source
Repositories
Cloud Build Container
Registry
Pod
IPアドレス管
理
SQL Proxy
Pod
インベントリ
収集
SQL Proxy
サイドカー・パターン（かっこいい
Ingress

16. 16
Deployment
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: <Application Name>
labels:
app: <Application Name>
spec:
replicas: 1
template:
metadata:
labels:
app: <Application Name>
spec:
Containers:
<Application Container Config>
<SQL Proxy Container Config>
volumes:
<For Cloud SQL Authencation>

17. 17
Application Container Config
- name: <Application Name>
image: <Image URL>
ports:
- containerPort: <Listen Port of Container>
readinessProbe:
httpGet:
<Helth Check URL>
envFrom:
- configMapRef:
name: <Env file>

18. 18
SQL Proxy Container Config
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.11
command: ["/cloud_sql_proxy",
"-instances=<Instance Connection Name>=tcp:3306",
"-credential_file=/secrets/cloudsql/credentials.json"]
# [START cloudsql_security_context]
securityContext:
runAsUser: 2 # non-root user
allowPrivilegeEscalation: false
# [END cloudsql_security_context]
volumeMounts:
- name: cloudsql-instance-credentials
mountPath: /secrets/cloudsql
readOnly: true
参照：Google Kubernetes Engine から接続する

19. 19
Service
kind: Service
apiVersion: v1
metadata:
name: <Application Name>-service
spec:
ports:
- port: <Listen port of external>
protocol: TCP
targetPort: <Listen port of container>
selector:
app: <Application Name>
type: NodePort

20. 20
Ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: <Ingress Name>
annotations:
kubernetes.io/ingress.allow-http: “false”
spec:
tls:
- secretName: <SSL Config Name>
rules:
- http:
paths:
- host: <FQDN for Application>
Http:
paths:
- backend:
serviceName: <Service Name>
servicePort: <Listen port for external>

21. 日々の運用

22. 通常の運用はほぼ何もしていないインフラエンジニアの危機
22

23. セルフヒーリング 最高
23

24. Kubernetes のアップグレードも
Google にお任せ
24

25. 開発業務
25

26. コンテナ使う開発っていろいろ手間…？
26

27. 27
通常想定される流れ
1. コーディング
2. イメージのビルド
3. デプロイ
4. テスト
5. 1-4 の繰り返し
6. コードのコミット（プルリク！）
7. イメージのプッシュ
8. 本番環境へデプロイ
9. 本番環境でテスト

28. 28
通常想定される流れ
1. コーディング
2. イメージのビルド
3. デプロイ
4. テスト
5. 1-4 の繰り返し
6. コードのコミット（プルリク！）
7. イメージのプッシュ
8. 本番環境へデプロイ
9. 本番環境でテスト

29. ビルド、デプロイは回数が多くて、
しかも時間かかるから面倒なんだよね。
29

30. ビルド、デプロイループから解放される
そう、Skaffold ならね。
30

31. Skaffold とは
➜ Google が開発した開発支援ツール
➜ ファイルの変更をトリガーに下記を行う
○ イメージのビルド
○ デプロイ
➜ Go なので環境依存度が低い
31

32. Skaffold の導入方法
1. GitHub からクローン
2. cmd/skaffold/skaffold.go を ビルド
3. 作業ディレクトリで skaffold dev を実行
a. 作業ディレクトリには skaffold.yaml が必要
32

33. 33
開発プロセス （Docker for Windows + Skaffold）
1. Skaffold を起動
2. コードの修正と同時にローカルに開発
環境反映
3. BitBucket にpush

34. CI/CD 作りたいな…難しそうだな。
34

35. CI/CD をサーバレスで実現できる
そう、 Cloud Build ならね。
35

36. Cloud Build とは
➜ GCP が提供する CI/CD をサポートする
強力なサービス
➜ Google の強大なインフラ上でビルドが
できるので超高速。
➜ コンテナイメージだけではなく、他の
サービスでも利用可能。
➜ レポジトリの変更をトリガーに自動ビル
ドが可能
36

37. 本番反映の流れ
1. BitBucketの master へpush
a. BitBucket と Source Repositories
はミラーリング
2. 上記をトリガーに CI 発動
3. CI が終わり次第、 CD を発動
37

38. CI / CD の流れ
1. 自動テストを実行
2. イメージをビルド、プッシュ
3. CD用レポジトリをクローン
4. GKE構成ファイルを修正
a. Image のIDとか
5. CD用レポジトリにGKE構成ファイルを
Push
6. 5をトリガーに本番環境へ反映
38

39. 39
詳細は下記をご参照ください！
https://cloud.google.com/kubernetes-engine/docs/tutorials/gitops-cloud-build?hl=ja

40. 基盤選択の経緯
40

41. 41
（会社からの）要求事項
➜ 早急に必要
➜ GCPを使いたい
➜ 管理するサーバを増やしたくない

42. 時間が限られていたので、
とりあえず試して良さげなら採用
42

43. なぜ、Kubernetesを候補にしたか
43

44. 運用負荷を軽減させたい！
CI/CD のパイプラインを作りたい！
稼働率を上げたい！
44

45. そんな崇高な理由ではありません。
いうても社内のシステムだし
45

46. ただ、使いたかったんです。
46

47. じゃあ、なんで GKE？
47

48. マスターノードが無料だから！
48

49. そんな崇高な理由ではありません。
どうせ会社が金出してくれるだろうし
49

50. GCPを使いたいという要求があったから！
50

51. 私はそんなにいい子ではありません。
会社に従うだけが良い子とは思いませんが
51

52. Kubernetes といえば、Google
AppEngine 最強
ConputeEngine は使いたくない
52

53. そんな感じでとりあえず、
使い始めてみました。
53

54. 実際に使ってみて良かった点は多かった。
非常に興味深い。やｍ…奥が深そう。
54

55. 良かった点

56. 良かった点
➜ ここで登壇できる機会を得れた
➜ 無停止でのアップグレードが可
○ ローリングアップデート
➜ 切り戻しが容易
○ ロールバック
➜ スモールスタートで始められる
○ pod起動してダメならリソースあげる
56

57. 今後の課題

58. 今後の課題
➜ チームでの運用に対応する
○ そろそろ楽したい
➜ 監視
○ StackDriver使いたい
➜ チューニング
○ ほぼ全てデフォルト設定
➜ セキュリティ
○ ログイン認証のみ
58

59. まとめ
➜ ナウいのができた…はず
➜ なんとなくでも触れるので、
とりあえず触ってみるべし。
➜ それなりにリソース食うし、費用もそれな
りに…。
➜ オートスケーリングが必要なぐらいのシ
ステムを作りたいな
59

60. 結局、
コンテナ使うなら Kubernetes が絶対いい？
60

61. Case By Case
61

62. これぐらいのコンテンツなら、
Docker Compose とかでもよいかも。
GCP なら Cloud Run という便利なものも
62

63. 最後に
63

64. ローカルに Kubernetes の環境が欲しい！
でも、クライアントPCだとリソース不足！
サーバならいっぱい余ってる！
64

65. Kubernetes の環境を簡単に手作りする方法
65

66. ありがとうございました！！
66