Jenkins勉強会#9で発表してきた

コンテナCIとJobの管理方法について話してきた。
話した内容や質問された内容を補足する。

スライドはこちら。

コンテナCIの流れ

ありがちではあるが、以下の通り。

  1. GitHubへ変更内容をPush or PRのコメント欄にtest this pleaseと記述
  2. 上記のイベントをトリガとしてJenkinsのJobが実行
  3. 試験内容はJenkinsではなく、Kubernetes上のコンテナで実行
  4. 試験結果をSlackに通知する

環境構成

図は、分かりやすさを優先してだいぶ省略している

試験の目的は、OpenStackの1コンポーネントに対して入れた修正の動作確認。 そのため、他のコンポーネントについては基本修正が入らない。 修正が行われるコンポーネントのみコンテナ化して、他のものはVM上に固定で作っている。 これは、コンテナ化には初期コスト&起動時間を回避するためだ。

VMはOpenStackのNovaで作ったものなので、OpenStack上に試験用OpenStackがいる

Job構成

ITとUTは並列して走るようになっており、
どちらかの試験がコケた段階でもう一方の試験も停止して結果を返す。

また、コンテナの後片付けは試験の開始時に行っている。 試験の最後にコンテナを片付けてしまうと、 試験に失敗した時の解析ができなくなってしまうためである。

Job管理

チームでは、Jenkins Job Builder(略してJJB)というYAML(/JSON)でJobを定義できるものを使用している。 Jenkinsの2.0がオススメしているJenkinsfileを使えばGitでJobを管理できるが、 昔のPluginを全て捨てPiplineに移行するのは大変であるし、 Jenkinsfileの指定には結局GUIが必要になってしまう。 しかし、JJBなら全てをCLI上で完結することができる。

YAMLのキーはJenkinsJob設定のXMLファイルと要素がほぼ一致しているので、 Jenkinsに慣れている人であれば、すぐに書けるようになると思う。

Jobの反映フロー

  1. JJBのDocument or Code参照しつつYAMLを書く
  2. 適用して動作を見る
  3. GitHubのPRをつくる
  4. メンバーにレビューしてもらう
  5. Mergeされる
  6. Mergeイベントを契機に、Jenkinsが自身に対してMasterのJob定義を反映する
comments powered by Disqus