How to choose CI CD tools

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 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) - 国内の各種勉強会も積極的に参加

Slide 3

Slide 3 text

© 2019 NTT TechnoCross Corporation 3 概要 • CI/CDツールは、システムのライフサイクル全体で人の労力を減らしつつ、成果を最大化するため使われます。 • ですが、CI/CD対象の特性に応じ数多く存在し、流行り廃りもあり、どれが良いか迷うことが多いのも事実です。 • 本セッションでは、CI/CDの概要、ツール選択に関する考察について説明し、注目するツールをご紹介します。 Man power Release Cycle Speed Quality Feedback CI/CD

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 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)

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 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)

Slide 8

Slide 8 text

© 2019 NTT TechnoCross Corporation 8 CI/CDのおさらい(1) • CI • Continuous Integration • システム(Infrastructure + App.)のBuild/Test • 小さな修正で迅速かつ継続的に実施する • CD • Continuous Deployment • CI通過したシステムを、目的の環境に自動デプロイ • ユーザがすぐ使える状態にする(=リリース) • Continuous Delivery • 上記＋リリース判断(=リリースされないことがある)

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2019 NTT TechnoCross Corporation 10 CI/CDの特徴 • 小さく高頻度なフィードバックサイクル • 準備からリリースまで短く、反省をすぐ次に活かす • 品質担保の強制 • IaCやコンテナなど自動化しやすい仕組み、手法を使う • テストの仕組み、一定以上の品質でないとリリース不可 • 自動化により人の関与の最小化。手作業での不完全性を減らす ⇒ 上記により開発速度と品質向上の高速化 • 準備が手間だが仕組みできてからの開発速度は上がる Design Imple- mentation Build/Test Deploy Release Operation pass ※IaC = Infrastructure as Code repos

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© 2019 NTT TechnoCross Corporation 12 我々の過去の反省 • 多くのプロジェクトでは、テストコードやビルドの仕組みはリポジトリで管理され、レビューやjenkins等の仕組みもある。それでも以下のような失敗を経験してきている。（私の場合、インフラよりの案件が多い） 1. 定期的にbuild/test/deployするが1回の変更量が大きい 2. テスト後インフラ後片付けの仕組みが不完全、手作業多い 3. 一度流しきるのに時間かかる。数時間かかるものもある 4. 対象環境ごとに差分あり、リリースの失敗が多い ※この他にもいっぱいある

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2019 NTT TechnoCross Corporation 14 IaC, コンテナの恩恵(2) Twelve-Factor App • https://12factor.net/ja/ • クラウド上への構築を前提に設計されたサービスを開発する時の方法論 • 12個の指針からなる。開発の手段としてコンテナベースでのCI/CDを採用すると、おのずとそのうちの多くを満たしやすくなる ↓ コンテナベースCI/CDは、クラウドネイティブなアプリケーションで良いとされる性質を得やすい

Slide 15

Slide 15 text

© 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)

Slide 16

Slide 16 text

© 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 ・・・・

Slide 17

Slide 17 text

© 2019 NTT TechnoCross Corporation 17 補足:CI/CDツールの基本構成 • リポジトリ:CI/CD対象のコード • CI/CDの処理フロー:ビルド/テスト/デプロイの流れの定義。呼び方様々 • CI/CDの実行環境:工程ごとに変更可能なものもある。VMやコンテナ • 成果物置き場:レジストリ、ローカルディスク等 • デプロイ先環境:開発/検証/商用環境、オンプレ/クラウド等 • 通知先:CI/CDの処理結果の通知先リポジトリソースビルドテストデプロイ CI/CDツール処理フロー(pipeline/workflow等の呼び方) 実行環境実行環境実行環境成果物置場コンテナデプロイ先の環境アプリ通知先守備範囲は物によって多少変わる

Slide 18

Slide 18 text

© 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)

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 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 ●で記載の分類は個人的な観測範囲での見解によるものです

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 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 最初は比較的多くの方が使っているものが無難

Slide 25

Slide 25 text

© 2019 NTT TechnoCross Corporation 25 費用(3) • CI/CDツールの使い始めとして、おすすめのものは? • 無料で使えるコンテナベースのもので3つほど挙げてみた。 • GitLab • オールインワンで困ることが少ない → 他製品より多機能 • 情報量も多い • 構築が面倒ならサービス版もある • Wercker • Bitbucket連携もある → GitHub以外を使うこともありますよね • サービス版なので構築しないで済む • Jenkins • ユーザ、情報量の多さ • プラグインによりタスクをコンテナで実行可能 • Docker Pipeline Plugin等

Slide 26

Slide 26 text

© 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

Slide 27

Slide 27 text

© 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)

Slide 28

Slide 28 text

© 2019 NTT TechnoCross Corporation 28 情報量(1) • 使っている製品の情報を取得しやすいか? • 製品やサービスの公式ページの充実 • ユーザサポートの有無、コミュニティ • Github等リポジトリのReadme、INSTALL、Usage • Slack • 公式情報の分かりやすさ • いろいろ書いてあるがサッパリわからない、では困る • 使うまでの敷居が少しでも高いものは避けるのが吉 • トラブル時に情報多いと助かることも多い • バージョンなど前提条件は確認して参考にする

Slide 29

Slide 29 text

© 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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2019 NTT TechnoCross Corporation 31 性能、リソース消費量(1) • 性能をよくする仕組み • ツール自体でもっているもの • （ツール自体にないが）自分で工夫するもの • ツール自体にある仕組み • キャッシュ • 一連のファイル群に名前(キー)をつけビルドを高速化できる仕組み • たとえばCircleCIやGitLabは、このキャッシュの仕組みを持つ • https://circleci.com/docs/ja/2.0/caching/ • https://docs.gitlab.com/ee/ci/caching/ • ライブラリやファイルを保持して再利用する。古い情報をもってしまっていることによる弊害が出ることもある

Slide 32

Slide 32 text

© 2019 NTT TechnoCross Corporation 32 性能、リソース消費量(2) • 自分で工夫できる箇所 • 使用しているツールによらず、CI/CDの工程の中で各タスクかかる時間を短くする。 • ビルド • テスト • デプロイ • 手段? • パイプラインの工夫、リソース増強、キャッシュ、並行実行数、使用する道具のフットプリント縮小(imageサイズ等)、・・・ • オンプレ設置時 • 必要リソース量はどの程度か?requirementsを確認

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© 2019 NTT TechnoCross Corporation 34 性能、リソース消費量(4) • CI/CDタスク初期化 • 前のタスクの終了待ち • 実行環境コンテナ作成 • sshなど通信の準備 • ソースコードをgit clone • dockerfileからコンテナのbuild • パッケージダウンロード • コンパイル • キャッシュ使用 • ファイル読み書き • DB初期化 • コンテナレジストリへのpush • ファイル送信 • コンテナのtest • テストツールの準備 • パッケージダウンロード • コンパイル • ファイル読み書き • テストデータ準備(DB等) • テスト実施 • ものにより並行実施 • データ送受(入力値、結果) • ファイル読み書き • 集計 • ファイル読み書き • 結果通知 • コンテナのdeploy 実行ログなどでプロファイリングしたあとに、リソース増強、並列度増強、待ち時間削減、通信の軽減、ディスクI/Oの軽減、などの対処すべき箇所とその手法（キャッシュ使用等）を検討して、効き目の大きいところから対処していく

Slide 35

Slide 35 text

© 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/

Slide 36

Slide 36 text

© 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の例。ビルド結果ログはこんな感じ

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2019 NTT TechnoCross Corporation 38 CI/CDタスクの実行環境(1) • 自分で作成することもできるか • GitLab: executor • Wercker: box • Drone: imageとして任意のコンテナを指定可能 • 柔軟に変更できるか • GitLab: タグによりタスクと実行環境を対応付け • Wercker: boxはタスクごとに変更可能 • Drone : imageとして任意のコンテナを指定可能 • 初めから用意されている実行環境の確認ポイント • サポートされているOSバージョン、言語バージョン • テストに併用できるサービス(DB、MQなど) • 付属しているツール

Slide 39

Slide 39 text

© 2019 NTT TechnoCross Corporation 39 CI/CDタスクの実行環境(2) オンプレサービス両対応 JenkinsX Spinnaker TeamCity Tekton Skaffold Codefresh CircleCI Wercker Azure DevOps GCP CloudBuild GitLab • Deploy先としてkubernetesをサポートしているものも多い • ツールにより使い方が指定され、その枠の中で使える。以下は例

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© 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

Slide 42

Slide 42 text

© 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一続きに実施できるものは楽

Slide 43

Slide 43 text

© 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

Slide 44

Slide 44 text

© 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

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© 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

Slide 47

Slide 47 text

© 2019 NTT TechnoCross Corporation 47 補足:使い始めるタイミング、複数使うべきか • ツールを使い始めるタイミング(選定にかける時間) • CI/CDは「継続的」とあるように割と⾧く使います。一度でベストプラクティスは得られないし試行錯誤は多い。なので、選定に時間かけすぎず、できるだけ早く使い始めるのがよいです。 • 本番システムでの使用も、次の本番に向けた練習と思って、常に自分にとって最高の方法を探しましょう。 • 複数のCI/CDツールを使いわけるべきか • 「yes」です。どのツールも思想が違うので特徴がある。 • デプロイ対象のクラウドも複数あったりします。武器を複数もっておくのがよいと思います。

Slide 48

Slide 48 text

© 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)

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

© 2019 NTT TechnoCross Corporation 51 GitLab（ぎっとらぶ）について • https://about.gitlab.com/ • ソフトウェア開発のライフサイクル全体をカバーするソフトウェア。 • 単なるリポジトリではない。 • プロジェクトの計画や管理、コーディングやテスト、リリース、モニタリングなど何でも入っている。 • なので、これ1つあると困らない。 • ロゴはタヌキ

Slide 52

Slide 52 text

© 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

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© 2019 NTT TechnoCross Corporation 54 CI/CDを使う際の流れ • executor作成→アプリ作成→パイプライン定義→CI/CD アプリ開発者ソースコードコミットコンテナ (タスク実行環境) ビルドテストレジストリ CI/CDパイプラインコンテナ登録コンテナ基盤アプリデプロイ設定ファイルパイプライン定義ファイルコンテナ (アプリ) .gitlab-ci.yml

Slide 55

Slide 55 text

© 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

Slide 56

Slide 56 text

Slide 57

Slide 57 text

© 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

Slide 58

Slide 58 text

Slide 59

Slide 59 text

© 2019 NTT TechnoCross Corporation 59 適用事例２ GitLab source build deploy GitLab pipeline executor executor (docker内蔵) executor GitLab container • executor(docker)を使いテスト用コンテナを活用 executor(コンテナ) dbサーバコンテナ webサーバコンテナテストツールコンテナテスト結果ファイル拡大

Slide 60

Slide 60 text

Slide 61

Slide 61 text

© 2019 NTT TechnoCross Corporation 61 Zuulとは • OpenStackコミュニティで作成されたCI/CDツール。 • ver.2まではコミュニティ内部で利用されているツールだったが、ver.3から独立したソフトウェアとして OpenStackFoundationにホストされるようになった（2018年からホストされた）。 • OpenStackは2019年に全体で○件のコミットがあったが、それらはZuulを利用したCIでテストされている。

Slide 62

Slide 62 text

Slide 63

Slide 63 text

© 2019 NTT TechnoCross Corporation 63 Zuulの動作概要 • 動作概要は基本的に一般的なCI/CDツールと同様。コード管理システム (素のGit or Github or Gerrit) Zuul 概略図: Nodepool 開発者 Openstack, Kubernetes, Openshift, EC2など VM (k8sであればコンテナ) ①コード投稿 ②投稿を検知＆投稿されたコードを取得（試験環境VMを事前に準備） ④試験の終わった VM削除 ⑤試験結果を投稿 ③投稿されたコードを、 VM上で試験

Slide 64

Slide 64 text

© 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を実行することで実現している。

Slide 65

Slide 65 text

© 2019 NTT TechnoCross Corporation 65 Zuulの特徴① - テスト設定の管理の容易さ • テスト対象 • テスト実行のパイプライン • テストのジョブ内容 • テスト後の動作 ...など • Zuulではこれらすべてをテキストファイルで管理する。 • 設定類はYAML、テストのジョブ内容はAnsibleの Playbookとして記述する。 • 試験設定ファイルは試験対象リポジトリと設定管理リポジトリの両方に必要となる。 • テキストファイルなので、Gitによる管理が容易。 • 反面GUIによる設定は出来ないため、最初に設定を作り上げる工程はやや骨が折れる。

Slide 66

Slide 66 text

© 2019 NTT TechnoCross Corporation 66 Zuulの特徴② - 試験設定の再利用可能性の高さ • 試験のパイプラインは、リポジトリ間で、流用や、継承・オーバーライドのようなことが実現可能。例: リポジトリA向け設定 1. 投稿されたコードで環境を構築する。 2. 試験Aを実行する。 3. 結果を投稿する。リポジトリB向け設定 1. 投稿されたコードで環境を構築する。 2. 試験Aを実行する。 3. 結果を投稿する。リポジトリC向け設定 1. 投稿されたコードで環境を構築する。 2. 試験Cを実行する。 3. 結果を投稿する。そのまま流用一部内容をオーバーライド

Slide 67

Slide 67 text

© 2019 NTT TechnoCross Corporation 67 Zuulの特徴③ - リポジトリの権限や関係性の設定 • 権限 • Zuulで取り扱うリポジトリは、config-projectかuntrusted-project のいずれかに分類する。 • config-project:Zuulの全体的設定や、大本の継承元となるようなジョブを定義する。 • untrusted-project:試験対象のリポジトリ。これらのリポジトリに配置される試験設定ファイル類では、指定できる項目・値が少し制限されている。 • リポジトリ間の関係性 • Zuulは基本的に複数の試験を（試験用VMの最大数にもよるが）並行実施するが、ジョブ間の関係性を定義してやれば、試験をシリアライズすることも可能。例えば、コンテナイメージ作成ジョブと、そのコンテナイメージを利用するジョブ、など。 • また、ユーザーがgitのコミットログに専用のメッセージを記載することで、コミット間の関係性を規定することもできる。

Slide 68

Slide 68 text

© 2019 NTT TechnoCross Corporation 68 Zuulを推奨するケース • 同様の（しかし完全に同一ではない）試験を行いたいリポジトリが大量に存在する • リポジトリが大量に存在する場合、個々に試験設定を作成すると非効率的である。流用やオーバーライドができれば最小限の手間で試験を用意できる。 • リポジトリ間の依存関係が設定できるため、破壊的なコミットをマージする危険性がない。 • コミッターが大量に存在する • untrusted-projectに設定したリポジトリに対しては可能な操作が限定されているため、誤って（もしくは故意に）設定や環境を破壊してしまうリスクがない。（Zuulの出自からすると当たり前ですが）いずれもOpenStackコミュニティにあてはまる特徴

Slide 69

Slide 69 text

© 2019 NTT TechnoCross Corporation 69 Zuulを推奨しないケース • 試験対象のソフトウェアが数種類である、もしくは要求される環境・試験内容などが全く異なる • 全ての試験対象に対して、試験設定のYAMLや Ansible Playbookをゼロから手動で書かなくてはならないため、手間が大きい。 • Nodepoolの連携先となる試験環境インスタンス（VMやコンテナ）作成環境の準備がなく、かつ試験ごとにクリーンな環境を用意する必然性が薄い • OpenStackやKubernetes、Openshiftをオンプレで用意する場合、大きな工数を要することを念頭に置く必要あり。 • 上記サービスのパブリッククラウド版や、Amazon EC2を利用する場合、準備の手間はない。ただし利用料金を事前に検討しておく必要がある。

Slide 70

Slide 70 text

© 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)

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

© 2019 NTT TechnoCross Corporation 73 おわりに • CI/CDの導入や刷新についてお悩みでしたら、ぜひお声掛けください! • ご質問やご指摘などあれば、発表後、Ask The Speakers にて受け付けます。 • ご相談いただくにあたり定額・回数制で質問できる、安価なチケットサービスもご用意しております! • 定額制チケットサービス • https://www.ntt- tx.co.jp/products/osscloud/service/ticket/ • ご清聴ありがとうございました。