Presentation at OpenStack Days Tokyo 2019 (20min session) Zuul introduction, features, basic job definitions and OpenStack integration are covered.

1. Zuul と OpenStack で作る
気の利いた CI 環境
Akihiro Motoki
Jul 22, 2019
OpenStack Days Tokyo 2019

2. Who am I ?
● Akihiro Motoki / 元木 顕弘
○ NEC OSS推進センター
○ IRC: amotoki, Twitter: @ritchey98
○ 以前は IPルータ、広域Ethernet装置、迷惑メールフィルタ、 OpenFlow 関連技術などの研究開発
をしていました。
● OpenStack Upstream Developer
○ Neutron: Core reviewer + drivers team
○ Core reviewer of Horizon, OpenStack Client (OSC), I18n
○ API-SIG, OpenStack SDK …
● OpenStack Operator (でした、ちょっと前まで)
● 日本OpenStackユーザー会 – 副会長、勉強会企画チーム

3. Zuul とは？
“Stop Merging Broken Code”
https://zuul-ci.org/index.html
● Project Gating ツール (CI ツール)
● コードの変更に対するテストを実行するためのインフラ
● もとは OpenStack 開発での CI を実現するために作られた
● 現在は汎用的な CI ツールになっている

5. Zuul の特徴
● Cross Project Testing (マージ時)
○ 複数のレポジトリが関係している場合、それぞれのレポジトリではテストが通っていても、組み合わ
せるとテストが失敗することがある
○ 関連があるレポジトリに関しては、マージが指示された順序で、すべての組み合わせを検証
→ どの時点においても動作することを保証
nova
neutron
cinder
1
1
1
2
2
2
1
1 1
N マージ対象
2
3
1
並列実行
2
3
3
失敗したときは戻した組
み合わせで実行
2
2
3

6. Zuul の特徴
● Cross Project Dependency
○ 複数のプロジェクトにまたがるパッチをマージ前にテスト可能
●
● 例えば、nova と neutron にまたがる機能を開発しているとする
● Nova のパッチは neutron に実装中の機能に依存
● Neutron のパッチをマージする前に nova との組み合わせが動作することを確認し
たい
Awesome network feature support
Depends-On: https://review.example.com/3
Nova パッチのコミットメッセージ
Neutron のパッチの URL

7. ジョブ定義
● レポジトリ内でのジョブ定義
○ CI システムに各レポジトリのジョブ定義を書く必要がなく、ジョブの分散・自律管理が可能
○ https://opendev.org/openstack/neutron/src/branch/master/.zuul.yaml
● Ansible によるジョブ定義
○ shell script で書く場合に比べるとモジュール化が行いやすい
● ジョブの再利用、継承
○ CI を運用する上で必要となるジョブやロールがあらかじめ準備されている
■ https://opendev.org/zuul/zuul-jobs など外部の定義のインポートもできる
○ パッチのテスト環境への展開や実行ログの保存など
○ OpenStack CI での継承 : http://zuul.openstack.org/jobs
■ 例えば “neutron-functional” でフィルタしてみるとわかりやすい

8. ジョブ定義の再利用
$ cat playbooks/base/post-logs.yaml
- hosts: localhost
gather_facts: False
roles:
- role: upload-logs
zuul_log_url: "http://localhost:8000"
$ cat zuul.d/jobs.yaml
- job:
name: base
parent: null
pre-run: playbooks/base/pre.yaml
post-run:
- playbooks/base/post-ssh.yaml
- playbooks/base/post-logs.yaml
roles:
- zuul: zuul/zuul-jobs
$ cat playbooks/base/pre.yaml
- hosts: all
roles:
- add-build-sshkey
- prepare-workspace
$ less .zuul.yaml
- job:
name: testjob
parent: base
run: playbooks/testjob.yaml
継承

9. ジョブ定義も比較的カンタン
Python プロジェクト test1 で “tox -e pep8” を実行したい場合
● tox-pep8 が、 tox 環境の準備を行って、
pep8 環境を実行してくれる
● base ジョブを継承しているので、
ログの保存なども行われる。
$ less test1/.zuul.yaml
- project:
check:
jobs:
- tox-pep8:
vars:
tox_install_siblings: false
gate:
jobs:
- tox-pep8:
vars:
tox_install_siblings: false

10. Zuul の構造
zuul-executor
zuul-scheduler
Test node
Test node
gerrit
github
ジョブ実行
nodepool
gearman
zookeeper
Test node 作成

11. Nodepool
● テストノードの管理を行う
○ 負荷に応じてテストノード数を増減
○ テストが終わったノードを削除
● 様々なバックエンドに対応
○ static
○ OpenStack
○ Kubernetes (namespace / pod)
○ OpenShift
○ AWS

12. Nodepool の OpenStack との連携
● Nodepool 実行ノードに clouds.yaml (OpenStack 認証情報を書いたファイル) を
用意する。
○ 置き場所は以下のいずれか
■ ~/.config/openstack/clouds.yaml
■ /etc/openstack/clouds.yaml
○ https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html
○ clouds.yaml の動作確認は OS_CLOUD 環境変数を設定して openstack コマンドを実行
● Nodepool の設定ファイルにノード情報を記載
○ http://paste.openstack.org/show/754613/
● Nodepool を再起動すると OpenStack 側に VM が自動的に作成される
○ http://paste.openstack.org/show/754612/

13. Zuul のユーザー
● BMW
○ Zuul で CI/CD をまとめて運用。Zuul プロセスは OpenShift 上で動かすことで可用性を確保
● GoDaddy
● OpenLab
● OpenStack Foundation
○ OpenStack, Airship, StarlingX など
● Ansible CI (openstack module + openstacksdk integration)
○ E.g. https://github.com/ansible/ansible/pull/59292
https://zuul-ci.org/users.html

14. どんな場面で有効？
● 多くの類似ジョブが存在している CI 環境では有用
○ 成果の再利用、継承
● 複数の互いに関連するプロジェクトがあり、
それらにまたがる開発を行う場合
● Jenkins ジョブ定義で shell script をたくさん書いている場合
● 単純な CI であれば SaaS の CI を利用する方が楽と思われる
○ CircleCI, TravisCI
● CD Foundation の下、Tekton や JenkinsX, Spinaker などの動向も見つつ、
使いやすいものを使っていくがよいと思われる

15. References
● Zuul Homepage https://zuul-ci.org
● Quick start and Tutorial https://zuul-ci.org/docs/zuul/admin/quick-start.html