20191120 beyondstudy#21 kitaoka
0 likes•684 views
2019年11月21日 ビヨンド勉強会#21 株式会社エクストランス 技術部システムオペレーション課 北岡 俊樹 「社内システムにGKEを組み込んだお話」
![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 から接続する](https://image.slidesharecdn.com/20191120beyondstudy21kitaoka-191121033625/85/20191120-beyondstudy-21-kitaoka-18-320.jpg)
20191120 beyondstudy#21 kitaoka
- 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. 目的
- 6. システムの紹介
- 7. GKE 7
- 8. 8 GKE とは ➜ GCP の Kubernetes マネージドサービ ス ➜ マスターは無料 ノードとして起動している ComputeEngineの費用のみ
- 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. 日々の運用
- 23. セルフヒーリング 最高 23
- 25. 開発業務 25
- 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. 本番環境でテスト
- 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
- 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
- 40. 基盤選択の経緯 40
- 41. 41 （会社からの）要求事項 ➜ 早急に必要 ➜ GCPを使いたい ➜ 管理するサーバを増やしたくない
- 46. ただ、使いたかったんです。 46
- 47. じゃあ、なんで GKE？ 47
- 52. Kubernetes といえば、Google AppEngine 最強 ConputeEngine は使いたくない 52
- 55. 良かった点
- 56. 良かった点 ➜ ここで登壇できる機会を得れた ➜ 無停止でのアップグレードが可 ○ ローリングアップデート ➜ 切り戻しが容易 ○ ロールバック ➜ スモールスタートで始められる ○ pod起動してダメならリソースあげる 56
- 57. 今後の課題
- 58. 今後の課題 ➜ チームでの運用に対応する ○ そろそろ楽したい ➜ 監視 ○ StackDriver使いたい ➜ チューニング ○ ほぼ全てデフォルト設定 ➜ セキュリティ ○ ログイン認証のみ 58
- 59. まとめ ➜ ナウいのができた…はず ➜ なんとなくでも触れるので、 とりあえず触ってみるべし。 ➜ それなりにリソース食うし、費用もそれな りに…。 ➜ オートスケーリングが必要なぐらいのシ ステムを作りたいな 59
- 61. Case By Case 61
- 62. これぐらいのコンテンツなら、 Docker Compose とかでもよいかも。 GCP なら Cloud Run という便利なものも 62
- 63. 最後に 63
- 66. ありがとうございました！！ 66