Download to read offline
![k8s で、コンテナ起動前と終了時にコマンド実行できる
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/sha
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]](https://image.slidesharecdn.com/ci-170928102751/75/Ci-63-2048.jpg)
![[Cloud OnAir] Talks by DevRel Vol.5 アプリケーションのモダナイゼーション 2020年9月3日 放送](https://cdn.slidesharecdn.com/ss_thumbnails/ffffffffffffffff-200903090943-thumbnail.jpg?width=640&height=640&fit=bounds)
パフォーマンス計測Ciサービスを作って得た知見を共有したい
- 1. パフォーマンス計測CIサービスを 作って得た知見を共有したい Rails Developers Meetup#5 2017-09-28 @zaru
- 2.
- 3.
- 4.
- 5. 今日話したいこと raysCI について GitHub Appsについて Docker / kubernetes について 個人開発プロジェクトについて
- 6.
- 7. 個人で開発している パフォーマンス計測をするCIサービス プルリクを作ったら自動でMasterとPRブランチのベンチマーク ベンチマークの種類 ApacheBench ヘッドレスブラウザ First paint DOM contentload assets network (HAR) stackprof (gem)
- 8.
- 9.
- 11.
- 12.
- 13. OAuth Apps (従来のもの)はユーザに対してインストール ユーザが削除されたりリポジトリへの権限を失うと消える アクセストークンはユーザが取り消さない限り永久有効 GitHub Apps はリポジトリに対してインストール 正確にはリポジトリのオーナー（Organization やUser）に インストールして、配下のリポジトリに付与するようなイメージ アクセストークンの有効期限は1時間 GitHub Apps のOAuth も可能 こちらはユーザ情報を取得するために使う（限定的） マーケットプレイスに出せる
- 14. OAuth Apps ではbotがコメントするためには実ユーザになりすます GitHub Apps は一人格としてコメントできる OAuth したユーザの代わりにもコメントできる
- 15.
- 16.
- 17.
- 18.
- 19.
- 20. JWT コード例 private_pem =File.read(path_to_pem) private_key = OpenSSL::PKey::RSA.new(private_pem) payload = { iat: Time.now.to_i, exp: Time.now.to_i + (10 * 60), iss: <GitHub App ID> } jwt = JWT.encode(payload, private_key, "RS256")
- 21.
- 22.
- 23. GitHub Apps にもユーザ情報を取得するOAuthがある 取得できるユーザの情報は限定されている ユーザ名やID・アバター 公開設定のEmail 非公開の場合はnull /user/emails にはアクセスできない 将来的には取得できるようになるっぽいが… インストール済みリポジトリ/ Public リポジトリ インストールしてないPrivate リポジトリは取得できない リポジトリの検索などはできない
- 24.
- 25.
- 26. 現時点で全てのAPIにアクセスできるわけではない 少しずつ解放される様子 9月21日にも66個のAPIが解放されている もし要望があるならフォーラムに投稿すると早くなるかも？ Request support foradditional endpoints for Integrations リポジトリ検索ができないのがつらい
- 27.
- 28. GitHub Enterprise v2.11で利用可能になるアナウンス しかしv2.11 のリリースノートには記載なし…
- 29.
- 30.
- 31.
- 32.
- 34. 不親切な流れになってしまう サービスページ（インストール誘導） → GitHubのインストール承認ページ → インストール完了 →終了（github.comのまま…） インストール後、サービスページに自動で戻らない 理想なのはOAuth Appsのような流れ サービスサイトでちゃんとフローを案内する必要がある（厳しい） 要望は出ていて検討中らしいので改善されるかもしれない マーケットプレイス中心の導線設計なのかも
- 35.
- 36.
- 37. ローカルでWebhook 受け取る方法 ngrok で外部に解放 無料だと起動のたびにホスト名が変わるので面倒 nginxでproxy サーバをたてる ルータでポートフォワーディングが必要 payload の例があるので、curl などで叩く https://developer.github.com/v3/activity/events/types/
- 38. upstream http_backend { #server example.ngrok.io; # ngrokの場合 server 10.0.0.10:3000; # ローカルのグローバルIP keepalive 128; } server { location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-CSRF-Token $http_x_csrf_token; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; # proxy_set_header Host example.ngrok.io; # ngrokの場合 proxy_redirect off; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://http_backend/; } }
- 40.
- 41.
- 42. CIは、ユーザのアプリ毎・ビルド毎に分離した動作環境が必要 今ならDockerが良い気がする どうやってDockerビルド/ コンテナ管理しよう？ CIサービス自体もDockerで動かしたい Docker inDocker docker.sock 共有 自前ビルドサーバ+ オーケストレーション kubernetes + GCP Container Builder
- 43.
- 44.
- 45.
- 46. 良い点 階層構造なので綺麗で管理しやすい 悪い点 パフォーマンス privilegedオプションで怖い ボリュームが残ってしまう そもそも制作者自身があまり推奨していない Using Docker-in-Docker foryour CI or testing environment? Think twice.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55. いつどれくらいコンテナが立てられるか予測できない GKE + k8sならコンテナ作成時にリソースが不足していたら自動で ノードを起動してくれる（オートスケール） リトライ処理やライフサイクルなど機能が豊富 複雑になりがちなビルドステップどうしよう… ContainerBuilder自体が簡易CIみたいなもの 簡単にステップを記述でき、公式で用意してあるイメージが便利 （gitコンテナ・dockerコンテナ・gcloudコンテナなど） 悪い点 Container Builderがビルドキャッシュをサポートしていない 毎回フルビルドなので時間がかかる
- 56. ところで GKE + kubernetesかHeroku か
- 57.
- 58.
- 60. 計測の流れ Container Builder にビルド依頼 ビルドコンテナがAppコンテナに計測用のコードを仕込む Gemle やinitializer / environment など ビルドコンテナがk8s デプロイファイルを作成 k8s にデプロイ 計測コンテナがApp の立ち上がりを待機 計測開始 計測後、CIコンテナにレポート送信 Pod を削除して終了
- 61.
- 62. appコンテナ起動時にDB作成／インポートを行う 正直、力技…どうにかしたい command: - "sh" - "-c" -> bundle exec rails db:create && bundle exec rails db:schema:load && bundle exec rails db:seed && bundle exec rails db < import.sql && bundle exec rails s -p 3000 -b 0.0.0.0
- 63. k8s で、コンテナ起動前と終了時にコマンド実行できる spec: containers: - name:lifecycle-demo-container image: nginx lifecycle: postStart: exec: command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/sha preStop: exec: command: ["/usr/sbin/nginx","-s","quit"]
- 64.
- 65. k8sのボリュームは以下の3種類 EmptyDir HostDir GCEPersistentDisk / awsElasticBlockStore EmptyDirとHostDir は永続化されない。Pod 内で一時的に使いたいな らEmptyDir、ホスト側でも使いたいならHostDir、永続化したいのな ら外部ストレージのGCEPersistentDisk。 raysCI ではベンチマーク結果や、設定ファイルなどをEmptyDir に格納 して利用。
- 66. resources を指定してリソースを固定する resources: requests: #最低限 cpu: 200m memory: 512M limits: # 最大 cpu: 200m memory: 512M ちゃんと指定しないとパフォーマンスがかなりブレる 1CPUに対しての割合を指定する。 0.1 は 100m m はミリコアと読んだりする メモリ使用が指定量を超えたらPod が死ぬ（再起動） CPU は指定量を超えたら水平オートスケールする（設定が必要）
- 67. 環境変数・秘匿情報について env: - name: FOO_KEY# 普通の環境変数 value: "foo value" - name: SECRET_KEY # 秘匿情報 valueFrom: secretKeyRef: name: secret_name key: secret_key k8sクラスタに接続できるなら誰でも閲覧可能 秘匿情報はsecrets API 経由で取得するようにする
- 68. Container Builder のローカル開発 GoogleCloudPlatform/container-builder-local ローカルで動かせる いちいちdockerpush とかしなくて済む 気の済むまでビルドデバッグ可能
- 70.
- 71. raysCI の開発ステータス 5月15日開発開始/ 約70日間の開発 1日平均2時間程度/ 累計で約142 時間の開発 業務でやったら1ヶ月くらい？
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81. ゴールを大きくしすぎない 小さく始めて素早く公開できる仕様にする やらないことを決める 対象ユーザの範囲を限定する なにかを妥協する 例えば完璧なテストコードや管理画面 raysCI はDocker 環境のみに対応、今はRailsだけビルドできるように 制限を加えることで作りやすくなる。ある程度は拡張できるように事前 設計するけど、まだ見えない未来に投資しすぎない。
- 82. まとめ GitHub Apps は作るのは簡単だけど、発展途上中 Docker自前でやるならkubernetes ContainerBuilderが優秀すぎて泣く 個人開発は習慣化と実益をとれるようにする 小さく作って、早く公開できるようにする
- 83. ありがとうございました。 docker stop $(dockerps -a -q)