「社内システムにGKEを組み込んだお話」

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

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

目的

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

システムの紹介

GKE 7

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

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

CMDB 10

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

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

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

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

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

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> 16

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> 17

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 から接続する
18

• https://cloud.google.com/sql/docs/mysql/connect-kubernetes-engine?hl=ja

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 19

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> 20

日々の運用

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

セルフヒーリング 最高 23

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

開発業務 25

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

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

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

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

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

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

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

• https://github.com/GoogleContainerTools/skaffold

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

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

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

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

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

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

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

• https://cloud.google.com/kubernetes-engine/docs/tutorials/gitops-cloud-build?hl=ja

基盤選択の経緯 40

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

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

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

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

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

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

じゃあ、なんで GKE？ 47

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

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

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

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

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

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

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

良かった点

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

今後の課題

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

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

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

Case By Case 61

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

最後に 63

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

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

• https://docs.google.com/presentation/d/1_NGifggQJZmc-DQWc9Tv4aMlGIZIpF-Rcp2g6r1ChCE/edit?usp=sharing

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