How to choose CI CD tools

CI/CDつーるのエラビカタ (7/23 RoomE , 14:20-15:00)
2019/7/23のCloudNative Days Tokyoで発表した資料です。
https://cloudnativedays.jp/cndt2019/
Twitter Hashtag: #CNDT2019

Transcript

1. © 2019 NTT TechnoCross Corporation CI/CDつーるのエラビカタ (How to choose CI/CD tools) #CNDT2019 #OSDT2019 2019/7/23(tue) room E [2E2] 14:20-15:00 新倉 雄樹、本上 力丸 Yuki Niikura , Rikimaru Honjo
2. © 2019 NTT TechnoCross Corporation 2 自己紹介 ・名前:新倉 雄樹 ・所属:NTTテクノクロス株式会社 ・今までやっていたこと: 2001～2008:開発 2008～:インフラ設計/構築/運用 → 2018から主にコンテナ関連 ・趣味:楽器演奏(Sax。主にジャズ、吹奏楽) ・その他 https://www.ntt-tx.co.jp/column/ 社外向けの記事を書いたり https://qiita.com/niiku-y Qiitaでアドベントカレンダー等記事書いたり しています。 - OpenStack Summitも3回ほど参加。 (Tokyo, Sydney, Berlin) - 国内の各種勉強会も積極的に参加
3. © 2019 NTT TechnoCross Corporation 3 概要 • CI/CDツールは、システムのライフサイクル全体で人の労力 を減らしつつ、成果を最大化するため使われます。 • ですが、CI/CD対象の特性に応じ数多く存在し、流行り廃り もあり、どれが良いか迷うことが多いのも事実です。 • 本セッションでは、CI/CDの概要、ツール選択に関する考察 について説明し、注目するツールをご紹介します。 Man power Release Cycle Speed Quality Feedback CI/CD
4. © 2019 NTT TechnoCross Corporation 4 今日お伝えしたいこと • コンテナベースCI/CDツールで我々が実感した利点 • ツールを選ぶ際に考慮する点 • GitLabとZuulを使ってみてほしい
5. © 2019 NTT TechnoCross Corporation 5 résumé 1. CI/CD概要 (CI/CD Overview) 1. Regarding CI/CD, Infrastructure as Code (IaC) 2. Our past failure 3. The importance of Container-based CI/CD tool 2. ツール選択の考察 (Consideration on tool selection) 1. Viewpoint & Example 2. Consideration 3. ツール紹介 (CI/CD tools introduction) 1. GitLab 2. Zuul 4. おわりに (The end)
6. © 2019 NTT TechnoCross Corporation 6 会場の皆様へ質問 • 挙手をお願いします。 • CI/CDをやったことがある方 (期間/対象/ツールは不問) • 紹介予定の、GitLabを使ったことがある方 • 紹介予定の、Zuulを使ったことがある方
7. © 2019 NTT TechnoCross Corporation 7 résumé 1. CI/CD概要 (CI/CD Overview) 1. Regarding CI/CD, Infrastructure as Code (IaC) 2. Our past failure 3. The importance of Container-based CI/CD tool 2. ツール選択の考察 (Consideration on tool selection) 1. Viewpoint & Example 2. Consideration 3. ツール紹介 (CI/CD tools introduction) 1. GitLab 2. Zuul 4. おわりに (The end)
8. © 2019 NTT TechnoCross Corporation 8 CI/CDのおさらい(1) • CI • Continuous Integration • システム(Infrastructure + App.)のBuild/Test • 小さな修正で迅速かつ継続的に実施する • CD • Continuous Deployment • CI通過したシステムを、目的の環境に自動デプロイ • ユーザがすぐ使える状態にする(=リリース) • Continuous Delivery • 上記＋リリース判断(=リリースされないことがある)
9. © 2019 NTT TechnoCross Corporation 9 CI/CDのおさらい(2) • 目的:何のためにCI/CDを導入するのか? • 開発効率（開発速度）の向上 • システムの品質向上 • 特徴:なぜそのような効果があるか? • 小さく高頻度なフィードバックサイクル • 品質担保の強制
10. © 2019 NTT TechnoCross Corporation 10 CI/CDの特徴 • 小さく高頻度なフィードバックサイクル • 準備からリリースまで短く、反省をすぐ次に活かす • 品質担保の強制 • IaCやコンテナなど自動化しやすい仕組み、手法を使う • テストの仕組み、一定以上の品質でないとリリース不可 • 自動化により人の関与の最小化。手作業での不完全性を減らす ⇒ 上記により開発速度と品質向上の高速化 • 準備が手間だが仕組みできてからの開発速度は上がる Design Imple- mentation Build/Test Deploy Release Operation pass ※IaC = Infrastructure as Code repos
11. © 2019 NTT TechnoCross Corporation 11 補足:Infrastructure as Code (IaC) • インフラの構築や管理に、ソフトウェア開発の考え 方、手法やツールを取り入れること。 • バージョン管理 (e.g. : Git) • 手順や設定のCode化による恩恵 • 自動化 • (設計等の)見える化 • レビュー • 上記をベースとしたCI/CD
12. © 2019 NTT TechnoCross Corporation 12 我々の過去の反省 • 多くのプロジェクトでは、テストコードやビルドの仕組みは リポジトリで管理され、レビューやjenkins等の仕組みもある。 それでも以下のような失敗を経験してきている。 （私の場合、インフラよりの案件が多い） 1. 定期的にbuild/test/deployするが1回の変更量が大きい 2. テスト後インフラ後片付けの仕組みが不完全、手作業多い 3. 一度流しきるのに時間かかる。数時間かかるものもある 4. 対象環境ごとに差分あり、リリースの失敗が多い ※この他にもいっぱいある
13. © 2019 NTT TechnoCross Corporation 13 IaC, コンテナの恩恵(1) • 前述のような反省点を改善する方法、仕組みとして の、IaC、コンテナ。 • 壊して毎回再作成:環境依存を考慮した手順が不要 • 成果物の質の確保:元が同じなら誰が作っても同じ ↓ ・コンテナをベースにしたCI/CDツールの必要性 ・適切なツールの導入は効率と品質の両面で効果あり
14. © 2019 NTT TechnoCross Corporation 14 IaC, コンテナの恩恵(2) Twelve-Factor App • https://12factor.net/ja/ • クラウド上への構築を前提に設計されたサービスを 開発する時の方法論 • 12個の指針からなる。開発の手段としてコンテナ ベースでのCI/CDを採用すると、おのずとそのうち の多くを満たしやすくなる ↓ コンテナベースCI/CDは、クラウドネイティブな アプリケーションで良いとされる性質を得やすい
15. © 2019 NTT TechnoCross Corporation 15 コンテナCI/CDとThe Twelve-Factor App • 例えばGitLab使いコンテナCI/CD実施しRailsのアプリを開発 して、composeやk8sの上での実行を考える。 • コンテナベースのCI/CD実施時、使っている各ツールの性質 上、12個の指針について自然と満たされやすい I. バージョン管理された1つのコードベース、複数デプロイ → GitLab II. 依存関係の明示的な宣言 → RailsのGemfile, Bundler III. 設定を環境変数に格納 → Docker, Docker-compose IV. バックエンドはアクセス情報や設定の変更により柔軟に変更可能 → DBコンテナ V. ビルド、リリース、実行を工程として分離 → GitLabのpipeline VI. アプリケーションを1つ以上のステートレスなプロセスで実行 → Docker VII. ポートバインディングを通したサービス公開 → Docker, Docker-compose VIII. 互いに疎で状態をもたないプロセス単位のスケールアウト → k8s IX. 廃棄容易性、高速な起動 → Docker, Docker-compose X. 開発/本番環境の一致 → Docker, Docker-compose XI. ログをイベントストリームとして扱う → postgresなど XII. 管理タスクを単発のプロセスとして実行 → k8s(job)
16. © 2019 NTT TechnoCross Corporation 16 CI/CDツール • ざっと調べただけで50くらい余裕で出てくる。。 AppVeyor Argo AWS CodeBuild Azure DevOps Bamboo Bitbucket Pipelines Brigade Buildkite CircleCI CloudBees Codefresh Codemagic Concourse Drone GCP CloudBuild GitLab GoCD Harness Heroku CI Jenkins JenkinsX Octopus Deploy Prow Rancher pipeline Screwdriver Skaffold Spinnaker Teamcity Tekton Travis CI Weave Flux Wercker Zuul Buildbot Codeship ・・・・
17. © 2019 NTT TechnoCross Corporation 17 補足:CI/CDツールの基本構成 • リポジトリ:CI/CD対象のコード • CI/CDの処理フロー:ビルド/テスト/デプロイの流れの定義。呼び方様々 • CI/CDの実行環境:工程ごとに変更可能なものもある。VMやコンテナ • 成果物置き場:レジストリ、ローカルディスク等 • デプロイ先環境:開発/検証/商用環境、オンプレ/クラウド等 • 通知先:CI/CDの処理結果の通知先 リポジトリ ソース ビルド テスト デプロイ CI/CDツール 処理フロー(pipeline/workflow等の呼び方) 実行環境 実行環境 実行環境 成果物置場 コンテナ デプロイ 先の環境 アプリ 通知先 守備範囲は物に よって多少変わる
18. © 2019 NTT TechnoCross Corporation 18 résumé 1. CI/CD概要 (CI/CD Overview) 1. Regarding CI/CD, Infrastructure as Code (IaC) 2. Our past failure 3. The importance of Container-based CI/CD tool 2. ツール選択の考察 (Consideration on tool selection) 1. Viewpoint & Example 2. Consideration 3. ツール紹介 (CI/CD tools introduction) 1. GitLab 2. Zuul 4. おわりに (The end)
19. © 2019 NTT TechnoCross Corporation 19 どれを選ぶか? • 選択肢が多様であることは良い • 一方で、（特に初めての方にとって）どれを使えば よいかが分かりにくい ↓ 観点 ＆ 具体例
20. © 2019 NTT TechnoCross Corporation 20 評価軸 • 設置場所 • 費用 • 情報量 • 性能、リソース消費量 • CI/CDの設定方法 • CI/CDタスクの実行環境 • CI/CD対象の種類・規模 • 連携製品・サービス
21. © 2019 NTT TechnoCross Corporation 21 設置場所(1) • クラウド上などのサービス • 運用の手間がない • 柔軟性は少ない、限られた使い方 • 有料版だけでなく、制限あり無料版もある • オンプレミス • 守秘上の理由 • 構築・運用が面倒 • 構築が必要だが、自分の好きな構成にできる • 運用はがんばってね
22. © 2019 NTT TechnoCross Corporation 22 設置場所(2) オンプレ サービス 両対応 •定番 Jenkins •大規模向け Concourse CI Zuul Spinnaker •GitOps向け ArgoCD Weave Flux •k8sへdeployする系ツール ArgoCD Brigade Tekton Prow Screwdriver.cd JenkinsX Skaffold Teamcity Bamboo GoCD Rancher Pipeline Buildbot •定番 CircleCI Wercker Heroku CI •クラウド AWS CodeBuild/CodeDeploy Azure DevOps GCP CloudBuild •k8s特化 Codefresh •flutter特化 Codemagic Bitbucket Pipelines Buildkite CloudBees Core/Codeship •定番/OSSでよく見る TravisCI GitLab Drone •windows/.NET AppVeyor Octopus Deploy •で記載の分類は個人的な観測範囲 での見解によるものです
23. © 2019 NTT TechnoCross Corporation 23 費用(1) • 無料 • OSS製品 • 有料サービスのOSS版 • お金かからない。・・・・ほんとに? • 運用の稼働費・・・ • 有料 • 複数プランある場合、サポートされる点の差がポイント • 無料のOSS製品でも構築運用が大変なくらいなら札束で解 決したいことも多いはず
24. © 2019 NTT TechnoCross Corporation 24 費用(2) • 無料で使えるプランのあるもの • OSS製品であることや制限あり(小規模チーム、並列実行 数1など)により無料となる製品・サービスがほとんど AppVeyor Argo Bamboo Bitbucket Pipelines Brigade Buildkite CircleCI Codefresh Concourse Drone GitLab GoCD Jenkins JenkinsX Octopus Deploy Prow Rancher pipeline Screwdriver Skaffold Spinnaker Teamcity Tekton Travis CI Weave Flux Wercker Zuul Buildbot 最初は比較的多くの方が 使っているものが無難
25. © 2019 NTT TechnoCross Corporation 25 費用(3) • CI/CDツールの使い始めとして、おすすめのものは? • 無料で使えるコンテナベースのもので3つほど挙げてみた。 • GitLab • オールインワンで困ることが少ない → 他製品より多機能 • 情報量も多い • 構築が面倒ならサービス版もある • Wercker • Bitbucket連携もある → GitHub以外を使うこともありますよね • サービス版なので構築しないで済む • Jenkins • ユーザ、情報量の多さ • プラグインによりタスクをコンテナで実行可能 • Docker Pipeline Plugin等
26. © 2019 NTT TechnoCross Corporation 26 費用(4) • 有料のものは、どこを確認するか? • 例:CircleCI • https://circleci.com/pricing/ • 実行環境のOS、並列実行数、ビルドの回数や時間、サ ポートの内容によって月額が変わるタイプ • Linux • 1concurrent job with4containers 4x parallelism , repo数やuser 数やビルド時間は制限なし, email support→ $150/mo • mac • 2x concurrency 1-5 builds/day 500 max min/mo , community support → $39/mo
27. © 2019 NTT TechnoCross Corporation 27 費用(5) • 例:GitLab • https://about.gitlab.com/pricing/ • SaaS型 • グレードが格上のプランになるごとに、使える機能が増え、サポートが 手厚くなる • Free $0, Bronze $4, Silver $19, Gold $99(すべてper user, per month) • 月あたりの使用時間がプランごとに決まっている • 例えばFreeだと2,000 CI pipeline minutes 、Silverなら10,000 • Self-managed型 →オンプレ、public cloud • これもプランが上になると使える機能やサポートが増える • https://about.gitlab.com/pricing/self-managed/feature-comparison/ • Core $0, Startar $4, Premium $19, Ultimate $99 (すべてper user, per month)
28. © 2019 NTT TechnoCross Corporation 28 情報量(1) • 使っている製品の情報を取得しやすいか? • 製品やサービスの公式ページの充実 • ユーザサポートの有無、コミュニティ • Github等リポジトリのReadme、INSTALL、Usage • Slack • 公式情報の分かりやすさ • いろいろ書いてあるがサッパリわからない、では困る • 使うまでの敷居が少しでも高いものは避けるのが吉 • トラブル時に情報多いと助かることも多い • バージョンなど前提条件は確認して参考にする
29. © 2019 NTT TechnoCross Corporation 29 情報量(2) • 参考:Stack Overflow や Qiita での情報量 (2019年7月上旬時点) search qiita stack overflow Jenkins CI 1216 500+ Travis CI 968 500+ GitLab CI 603 500+ Circle CI 599 500+ Heroku CI 276 427 Wercker CI 173 21 Drone CI 103 98 AWS CodeBuild CI 91 50 Azure DevOps CI 84 320 AppVeyor CI 70 190 AWS CodePipeline CI 80 54 Concourse CI 69 134 teamcity CI 21 500+ bamboo CI 18 485 Spinnaker CI 32 13
30. © 2019 NTT TechnoCross Corporation 30 情報量(3) • CircleCIではチャットで質問できたりする 分からないところは ここでリアルタイム で聞ける
31. © 2019 NTT TechnoCross Corporation 31 性能、リソース消費量(1) • 性能をよくする仕組み • ツール自体でもっているもの • （ツール自体にないが）自分で工夫するもの • ツール自体にある仕組み • キャッシュ • 一連のファイル群に名前(キー)をつけビルドを高速化できる仕組み • たとえばCircleCIやGitLabは、このキャッシュの仕組みを持つ • https://circleci.com/docs/ja/2.0/caching/ • https://docs.gitlab.com/ee/ci/caching/ • ライブラリやファイルを保持して再利用する。古い情報をもってし まっていることによる弊害が出ることもある
32. © 2019 NTT TechnoCross Corporation 32 性能、リソース消費量(2) • 自分で工夫できる箇所 • 使用しているツールによらず、CI/CDの工程の中で各タス クかかる時間を短くする。 • ビルド • テスト • デプロイ • 手段? • パイプラインの工夫、リソース増強、キャッシュ、並行実行数、 使用する道具のフットプリント縮小(imageサイズ等)、・・・ • オンプレ設置時 • 必要リソース量はどの程度か?requirementsを確認
33. © 2019 NTT TechnoCross Corporation 33 性能、リソース消費量(3) CI/CDの各工程でやっていることを分解して考えてみる アプリ開発者 ソース コード コミット コンテナ (タスク 実行環境) ビルド テスト レジストリ CI/CDパイプライン コンテナ 登録 コンテナ基盤 アプリ デプロイ コンテナ (アプリ)
34. © 2019 NTT TechnoCross Corporation 34 性能、リソース消費量(4) • CI/CDタスク初期化 • 前のタスクの終了待ち • 実行環境コンテナ作成 • sshなど通信の準備 • ソースコードをgit clone • dockerfileからコンテナのbuild • パッケージダウンロード • コンパイル • キャッシュ使用 • ファイル読み書き • DB初期化 • コンテナレジストリへのpush • ファイル送信 • コンテナのtest • テストツールの準備 • パッケージダウンロード • コンパイル • ファイル読み書き • テストデータ準備(DB等) • テスト実施 • ものにより並行実施 • データ送受(入力値、結果) • ファイル読み書き • 集計 • ファイル読み書き • 結果通知 • コンテナのdeploy 実行ログなどでプロファイリングしたあとに、リソース増強、並列度増強、待ち時間 削減、通信の軽減、ディスクI/Oの軽減、などの対処すべき箇所とその手法（キャッ シュ使用等）を検討して、効き目の大きいところから対処していく
35. © 2019 NTT TechnoCross Corporation 35 CI/CD設定方法(1) • 設定の手段 • YAML • GUI • CLIやAPI • 例としてdrone : https://docs.drone.io/ • 設定の柔軟性や、道具の使いやすさ • GUI • プラグイン • デバッグ用設定 • Circle CIはビルド環境にssh接続しトラブルシュートできる • https://circleci.com/docs/ja/2.0/ssh-access-jobs/
36. © 2019 NTT TechnoCross Corporation 36 CI/CD設定方法(2) # .drone.yml kind: pipeline name: default steps: - name: build image: kura2i/drone-test-img:latest privileged: false commands: - ./install.sh /usr/local/ - echo "hoge" | /usr/local/bin/cowsay 設定ファイルはツールによって （書く内容がほとんど同じでも） 書き方が結構、違う。UIも個性ある。 左記はdroneの例。 ビルド結果ログはこんな感じ
37. © 2019 NTT TechnoCross Corporation 37 CI/CD設定方法(3) 設定ファイルはツールによって （書く内容がほとんど同じでも） 書き方が結構、違う。UIも個性ある。 左記はwerckerの例。 色かえてリポジトリ識別 パイプライン 結果: OK緑/NG赤
38. © 2019 NTT TechnoCross Corporation 38 CI/CDタスクの実行環境(1) • 自分で作成することもできるか • GitLab: executor • Wercker: box • Drone: imageとして任意のコンテナを指定可能 • 柔軟に変更できるか • GitLab: タグによりタスクと実行環境を対応付け • Wercker: boxはタスクごとに変更可能 • Drone : imageとして任意のコンテナを指定可能 • 初めから用意されている実行環境の確認ポイント • サポートされているOSバージョン、言語バージョン • テストに併用できるサービス(DB、MQなど) • 付属しているツール
39. © 2019 NTT TechnoCross Corporation 39 CI/CDタスクの実行環境(2) オンプレ サービス 両対応 JenkinsX Spinnaker TeamCity Tekton Skaffold Codefresh CircleCI Wercker Azure DevOps GCP CloudBuild GitLab • Deploy先としてkubernetesをサポートしているものも多い • ツールにより使い方が指定され、その枠の中で使える。以下は例
40. © 2019 NTT TechnoCross Corporation 40 CI/CD対象の種類・規模(1) • k8sのサポート状況 • 今時、「コンテナサポートなし」は殆ど聞かない • が、k8s対応状況は差がある • 特定の目的に対応できる製品・サービスか? • GitOps • モバイルアプリ • 大規模な開発にも使えるか • Windows系 • それ以外
41. © 2019 NTT TechnoCross Corporation 41 CI/CD対象の種類・規模(2) • k8sへのデプロイのサポート有無 • GitOpsに使える → Weave flux, ArgoCD, JenkinsX • それ以外 → Spinnaker, GitLabなど。 • 特定のものに対応しているか? • モバイルアプリ → Bitrise, Codemagic • 大規模 → Zuul, Concourse-CI, Spinnaker • Windows系 → AppVeyor, Octopus Deploy
42. © 2019 NTT TechnoCross Corporation 42 連携製品・サービス(1) • CI/CDツール周辺の選択肢(連携製品)の広さ • CI/CDのトリガーとして使えるリポジトリ • Github, Bitbucket, GitLab, ・・・ • CI/CD結果の通知先 • Slack, mail, chat,・・・ • CIとCDで別製品・サービスを使えるか? • 例:CIにjenkins、CDにSpinnaker • GitLabのようにCI/CD一続きに実施できるものは楽
43. © 2019 NTT TechnoCross Corporation 43 連携製品・サービス(2) • 例:Wercker（サービス）の使用例 • リポジトリ:GitHub • パイプライン/ワークフロー:Werckerのpipeline, workflows(pipelineを組合せ作成) • CI/CDタスク実行環境:Werckerのbox → DockerHubのコンテナイメージから作成 • 成果物置き場:DockerHub • デプロイ先環境:Heroku • 通知先:Slack GitHub source build test deploy Wercker pipeline/workflow box box box DockerHub container Heroku app Slack
44. © 2019 NTT TechnoCross Corporation 44 連携製品・サービス(3) • 例:GitLab（オンプレ）の使用例 • リポジトリ:GitLab • パイプライン/ワークフロー:GitLabのpipeline • CI/CDタスク実行環境:GitLabのexecutor • 成果物置き場:GitLab Container Registry • デプロイ先環境:社内検証サーバ • 通知先:メール GitLab source build test deploy GitLab pipeline executor executor executor GitLab container staging app mail
45. © 2019 NTT TechnoCross Corporation 45 どう考えて評価するか?（順番） 1. CI/CD対象の種類・規模 2. 連携製品・サービス 3. 設置場所 4. 費用 5. 情報量 6. 性能、リソース消費量 7. CI/CDの設定方法 8. CI/CDタスクの実行環境 目的に関わる部分 費用に関わる部分 最後に使いこなしに 関わる部分
46. © 2019 NTT TechnoCross Corporation 46 補足:併用するツール • CI/CDツール本体ではないが、組み合わせて使うこ とを想定されているツールも存在している。 • セキュリティ関連のチェックツール • レポート（UI画像取得,テスト結果など） • 例:CI/CD+セキュリティ • Trivy : A Simple and Comprehensive Vulnerability Scanner for Containers, Suitable for CI • https://github.com/knqyf263/trivy
47. © 2019 NTT TechnoCross Corporation 47 補足:使い始めるタイミング、複数使うべきか • ツールを使い始めるタイミング(選定にかける時間) • CI/CDは「継続的」とあるように割と⾧く使います。一度 でベストプラクティスは得られないし試行錯誤は多い。な ので、選定に時間かけすぎず、できるだけ早く使い始める のがよいです。 • 本番システムでの使用も、次の本番に向けた練習と思って、 常に自分にとって最高の方法を探しましょう。 • 複数のCI/CDツールを使いわけるべきか • 「yes」です。どのツールも思想が違うので特徴がある。 • デプロイ対象のクラウドも複数あったりします。武器を複 数もっておくのがよいと思います。
48. © 2019 NTT TechnoCross Corporation 48 résumé 1. CI/CD概要 (CI/CD Overview) 1. Regarding CI/CD, Infrastructure as Code (IaC) 2. Our past failure 3. The importance of Container-based CI/CD tool 2. ツール選択の考察 (Consideration on tool selection) 1. Viewpoint & Example 2. Consideration 3. ツール紹介 (CI/CD tools introduction) 1. GitLab 2. Zuul 4. おわりに (The end)
49. © 2019 NTT TechnoCross Corporation 49 具体的なツールのご紹介 • GitLab • Zuul
50. 50 © 2019 NTT TechnoCross Corporation GitLab
51. © 2019 NTT TechnoCross Corporation 51 GitLab（ぎっとらぶ）について • https://about.gitlab.com/ • ソフトウェア開発のライフサイクル全体をカバーす るソフトウェア。 • 単なるリポジトリではない。 • プロジェクトの計画や管理、コーディングやテスト、 リリース、モニタリングなど何でも入っている。 • なので、これ1つあると困らない。 • ロゴはタヌキ
52. © 2019 NTT TechnoCross Corporation 52 オンプレ • 割とリソースは食う。omnibus packageよく使う • https://help.github.com/en/enterprise/2.15/admin/i nstallation/installing-github-enterprise-server-on- openstack-kvm#hardware-considerations • https://docs.gitlab.com/ee/install/requirements.html seats vcpus memory GitLab -100 2 8G 100-2000 4 16G GitHub Enterprise 10-500 2 16G 500-3000 4 32G
53. © 2019 NTT TechnoCross Corporation 53 サービス • サービス版(SaaS)も制限あるが無料で使える • https://gitlab.com/users/sign_in • https://about.gitlab.com/pricing/ • 制限といいつつ、個人で使うには十分
54. © 2019 NTT TechnoCross Corporation 54 CI/CDを使う際の流れ • executor作成→アプリ作成→パイプライン定義→CI/CD アプリ開発者 ソース コード コミット コンテナ (タスク 実行環境) ビルド テスト レジストリ CI/CDパイプライン コンテナ 登録 コンテナ基盤 アプリ デプロイ 設定 ファイル パイプライン 定義ファイル コンテナ (アプリ) .gitlab-ci.yml
55. © 2019 NTT TechnoCross Corporation 55 .gitlab-ci.ymlサンプル • 以下のように、ステージ(工程)、ジョブ(工程内のタスク)を定義する。 • ステージ内のジョブは並行で実施される。下の例だとtest1, test2が並走する。各ステージ は配下の全ジョブが完了しないと先に進めない # .gitlab-ci.yml image: registry.gitlab.com/niiku-y/executor_compose:1.0 before_script: - docker info - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY - git config --global user.email "$GITLAB_USER_EMAIL" - git config --global user.name "$GITLAB_USER_NAME" stages: - build - test - deploy compose_build: stage: build tags: - niiku-y-sample2-build script: - make clean - make build compose_test1: stage: test tags: - niiku-y-sample2-test script: - make test1 compose_test2: stage: test tags: - niiku-y-sample2-test script: - make test2 compose_deploy: stage: deploy tags: - niiku-y-sample2-deploy script: - make up
56. © 2019 NTT TechnoCross Corporation 56 画面サンプル リポジトリ表示は githubに近い pipelineはymlから 自動生成される loginすると自分のリポジトリ や最近の行動履歴が分かるよ うになっている 左側、上側にある メニューで画面を 行き来する
57. © 2019 NTT TechnoCross Corporation 57 適用事例１ • コンテナ学習環境。GitLab-RunnerによるCI/CD kubernetes cluster kubernetes cluster kubernetes cluster master master master worker worker worker master master master worker worker worker master master master worker worker worker 管理テナント レジストリ CI/CD リポジトリ コンテナ クラスタ管理 カタログ モニタリング 社内 persistent volume GitLab Rancher
58. © 2019 NTT TechnoCross Corporation 58 適用事例２ • GitLabによるコンテナ開発環境。試験用コンテナを活用 GitLab-Runner 開発 試験 Kubernetes CI/CD実行 コンテナ デプロイ・運用 Rancher GitLab リポジトリ レジストリ
59. © 2019 NTT TechnoCross Corporation 59 適用事例２ GitLab source build deploy GitLab pipeline executor executor (docker内蔵) executor GitLab container • executor(docker)を使いテスト用コンテナを活用 executor(コンテナ) dbサーバ コンテナ webサーバ コンテナ テストツール コンテナ テスト 結果ファイル 拡大
60. 60 © 2019 NTT TechnoCross Corporation Zuul
61. © 2019 NTT TechnoCross Corporation 61 Zuulとは • OpenStackコミュニティで作成されたCI/CDツール。 • ver.2まではコミュニティ内部で利用されているツー ルだったが、ver.3から独立したソフトウェアとして OpenStackFoundationにホストされるようになった （2018年からホストされた）。 • OpenStackは2019年に全体で◦件のコミットが あったが、それらはZuulを利用したCIでテストされ ている。
62. © 2019 NTT TechnoCross Corporation 62 Zuulの、試験実行状況確認UIの例
63. © 2019 NTT TechnoCross Corporation 63 Zuulの動作概要 • 動作概要は基本的に一般的なCI/CDツールと同様。 コード管理システム (素のGit or Github or Gerrit) Zuul 概略図: Nodepool 開発者 Openstack, Kubernetes, Openshift, EC2など VM (k8sであればコンテナ) ①コード投稿 ②投稿を検知＆投稿されたコードを取得 （試験環境VMを 事前に準備） ④試験の終わった VM削除 ⑤試験結果を投稿 ③投稿されたコードを、 VM上で試験
64. © 2019 NTT TechnoCross Corporation 64 Zuulの動作概要（補足） • 動作概要は基本的に一般的なCI/CDツールと同様。 コード管理システム (素のGit or Github or Gerrit) Zuul 概略図: Nodepool 開発者 Openstack, Kubernetes, Openshift, EC2など VM (k8sであればコンテナ) ①コード投稿 ②投稿を検知 （試験環境VMを 事前に準備） ④試験の終わった VM削除 ⑤試験結果を投稿 ③VM上で試験を実行 Nodepoolは、Zuulと共に開発されてい る、試験環境用インスタンス（VM等） を制御するツール。 OpenStackのほかにk8s, Openshift, Amazon EC2などに対応している。 （私は、OpenStack以外は未検証） ZuulがVM（やコンテナ）上で 試験実行する動作は、Zuulが 試験用のAnsible Playbookを 実行することで実現している。
65. © 2019 NTT TechnoCross Corporation 65 Zuulの特徴① - テスト設定の管理の容易さ • テスト対象 • テスト実行のパイプライン • テストのジョブ内容 • テスト後の動作 ...など • Zuulではこれらすべてをテキ ストファイルで管理する。 • 設定類はYAML、テストの ジョブ内容はAnsibleの Playbookとして記述する。 • 試験設定ファイルは試験 対象リポジトリと設定管 理リポジトリの両方に必 要となる。 • テキストファイルなので、Gitによる管理が容易。 • 反面GUIによる設定は出来ないため、 最初に設定を作り上げる工程はやや骨が折れる。
66. © 2019 NTT TechnoCross Corporation 66 Zuulの特徴② - 試験設定の再利用可能性の高さ • 試験のパイプラインは、リポジトリ間で、流用や、 継承・オーバーライドのようなことが実現可能。 例: リポジトリA向け設定 1. 投稿されたコードで 環境を構築する。 2. 試験Aを実行する。 3. 結果を投稿する。 リポジトリB向け設定 1. 投稿されたコードで 環境を構築する。 2. 試験Aを実行する。 3. 結果を投稿する。 リポジトリC向け設定 1. 投稿されたコードで 環境を構築する。 2. 試験Cを実行する。 3. 結果を投稿する。 そのまま流用 一部内容を オーバーライド
67. © 2019 NTT TechnoCross Corporation 67 Zuulの特徴③ - リポジトリの権限や関係性の設定 • 権限 • Zuulで取り扱うリポジトリは、config-projectかuntrusted-project のいずれかに分類する。 • config-project:Zuulの全体的設定や、大本の継承元となるよう なジョブを定義する。 • untrusted-project:試験対象のリポジトリ。これらのリポジト リに配置される試験設定ファイル類では、指定できる項目・値が 少し制限されている。 • リポジトリ間の関係性 • Zuulは基本的に複数の試験を（試験用VMの最大数にもよるが）並行実施するが、ジョ ブ間の関係性を定義してやれば、試験をシリアライズすることも可能。例えば、コンテ ナイメージ作成ジョブと、そのコンテナイメージを利用するジョブ、など。 • また、ユーザーがgitのコミットログに専用のメッセージを記載することで、コミット 間の関係性を規定することもできる。
68. © 2019 NTT TechnoCross Corporation 68 Zuulを推奨するケース • 同様の（しかし完全に同一ではない）試験を行いた いリポジトリが大量に存在する • リポジトリが大量に存在する場合、個々に試験設定 を作成すると非効率的である。流用やオーバーライ ドができれば最小限の手間で試験を用意できる。 • リポジトリ間の依存関係が設定できるため、破壊的 なコミットをマージする危険性がない。 • コミッターが大量に存在する • untrusted-projectに設定したリポジトリに対しては 可能な操作が限定されているため、誤って（もしく は故意に）設定や環境を破壊してしまうリスクがな い。 （Zuulの出自からすると当たり前ですが） いずれもOpenStackコミュニティにあてはまる特徴
69. © 2019 NTT TechnoCross Corporation 69 Zuulを推奨しないケース • 試験対象のソフトウェアが数種類である、もしくは 要求される環境・試験内容などが全く異なる • 全ての試験対象に対して、試験設定のYAMLや Ansible Playbookをゼロから手動で書かなくてはな らないため、手間が大きい。 • Nodepoolの連携先となる試験環境インスタンス （VMやコンテナ）作成環境の準備がなく、かつ試験 ごとにクリーンな環境を用意する必然性が薄い • OpenStackやKubernetes、Openshiftをオンプレで 用意する場合、大きな工数を要することを念頭に置 く必要あり。 • 上記サービスのパブリッククラウド版や、Amazon EC2を利用する場合、準備の手間はない。ただし利 用料金を事前に検討しておく必要がある。
70. © 2019 NTT TechnoCross Corporation 70 résumé 1. CI/CD概要 (CI/CD Overview) 1. Regarding CI/CD, Infrastructure as Code (IaC) 2. Our past failure 3. The importance of Container-based CI/CD tool 2. ツール選択の考察 (Consideration on tool selection) 1. Viewpoint & Example 2. Consideration 3. ツール紹介 (CI/CD tools introduction) 1. GitLab 2. Zuul 4. おわりに (The end)
71. © 2019 NTT TechnoCross Corporation 71 まとめ • 適切なCI/CDツール導入は効率品質の両面で効果的。 • 適切なCI/CDツールの選定は知見が必要。 • 特にオンプレは導入にあたり運用面も考慮する必要がある。 • GitLab, Zuulについてご紹介しました
72. © 2019 NTT TechnoCross Corporation 72 ブースについて • 展示エリアのブース 22、23 • ぜひお立ち寄りください!DPDKやログ解析の展示もしています! 扉 扉 扉 扉 jobボード、 ステッカー コーナー ミニ ブース テーブルブース テ ｜ ブ ル ブ ｜ ス システム ブース システム ブース システム ブース ブース22, 23 NTTテクノクロス
73. © 2019 NTT TechnoCross Corporation 73 おわりに • CI/CDの導入や刷新についてお悩みでしたら、ぜひ お声掛けください! • ご質問やご指摘などあれば、発表後、Ask The Speakers にて受け付けます。 • ご相談いただくにあたり定額・回数制で質問できる、 安価なチケットサービスもご用意しております! • 定額制チケットサービス • https://www.ntt- tx.co.jp/products/osscloud/service/ticket/ • ご清聴ありがとうございました。