【CI奮闘記】第5章:コントローラー?エグゼキューター?エージェント?


はじめに

前回のブログでは、CIやCDのデメリットについて説明しました。
前回のブログはこちら
今回は実際にJenkinsというツールを用いてCI/CDを実現する第一歩の内容となります。

登場人物

吉田:転職したてのエンジニア。前職では積極的にCIやCDという事に取り組みながら開発をしていた。

溝口:入社20年のベテラン。現職の部署の開発経験しかなく、従来通りのウォーターフォールでの開発経験しかない。新しい取り組みには積極的だが、どうしても今までの成功体験に寄ってしまいがち。

服部:今回から初登場。配属1年後の新人。CIやJenkinsについては言葉は聞いたことがある程度。もともと開発で今回初めて環境周りを扱う事になった。

Jenkinsを使う上での用語整理

今回は用語について勉強していこうか。

了解です。前回「エグゼキューター」という単語が出てきましたよね。

そうそう、そういったものを説明していくよ。まずは「Jenkinsコントローラー」からね。

Jenkinsコントローラー

「Jenkinsコントローラー」はJenkinsのサービス自体を指すの。
前回インストールしたJenkinsは「Jenkinsコントローラー」ね。
単に「コントローラー」と呼んだ場合も「Jenkinsコントローラー」を指すわ。

なるほど、Jenkins本体というわけですね。どういった役割があるんですか?

色々あるけど、代表的なものはこんな感じね。

JenkinsコントローラーはJenkinsがインストールした場所を指します。
前回述べたJenkinsのURLの設定といったJenkins自体の設定はJenkinsコントローラーで実施します。ログインユーザーの設定といった認証、認可言う事も同様にJenkinsコントローラーで設定します。
Jenkinsコントローラーが行う処理としては

  • ユーザーからのすべてのWebアクセスを受け付けてジョブを管理し、ビルドを実行する
  • コントローラー自体に割り当てられたジョブのビルドを実行する

といったことが挙げられます。

エグゼキューター

実際にジョブ(タスク)を実行する計算リソースを「エグゼキューター」と呼ぶわ。

executorの和訳の通り実行者というわけですね。

この「エグゼキューター」でJenkinsはジョブを実行するの。

エージェント

ジョブの実行に関して、Jenkinsコントローラー自体も「エグゼキューター」を持つこともできるんだけど、Jenkinsコントローラーと切り出すこともできるのね。
このときにJenkinsコントローラーの代わりに「エグゼキューター」を管理してくれるのを「エージェント」と呼ぶの

ここで「エージェント」が登場するんですね。

図にするとこういったイメージになるわ。

ノード

こんな風にして切り出したエージェントはJenkinsコントローラーと別のサーバーに配置することができるの。
別サーバーに配置することで分散ビルドの実現もできる様になるのね。

分散ビルド。複数のサーバー上でビルドを行うってことですか?

そう。
それ以外にもJenkinsコントローラーとは別のサーバーでジョブを実行したほうがメリットがある場合が多いの。
Jenkinsのコンポーネントでは、ビルド時に使用されるツールとかパッケージを提供するサーバーの事を「ノード」という表現をするわ。
なので「エージェント」は「ノード」上で動作するし、「Jenkinsコントローラー」も「ノード」上で動作するのね。

おお、ややこしい!

イメージとしてはこういった形ね。

「Jenkinsコントローラー」はこのノードをモニターしていて、例えば一定のディスク容量を超えたらほかのノードとの接続を切ったりもするわ。

理想的なコントローラーとエージェントの関係

さっき「Jenkinsコントローラーとは別のサーバーでジョブを実行したほうがメリットがある場合が多い」との事でしたが、それって何でですか?
Jenkinsコントローラーにもエグゼキューターを持てるのであれば分けないほうが楽そうだなーと思ってしまいます。

色々理由はあるけど、大きくは「セキュリティ」と「負荷分散」、「異なる環境の提供」ね。

別のサーバーでジョブを実行する効果① セキュリティ

Jenkinsコントローラーのノードでジョブを実行した場合、そのジョブはJenkinsコントローラーのファイルであったり設定にもアクセスが可能になってしまいます。
意図する・しないにかかわらずJenkinsコントローラーの設定を変更してしまう事や、ファイルの削除、悪意のあるコードをJenkinsコントローラーのノードに導入してしまう可能性等があります。
セキュリティを強化するためにJenkinsコントローラーのノードと切り離したエージェントでの実行を推奨します。
より強化するために、すべてのビルドをクラウドやDockerコンテナといった一時的なエージェントで実行し、ビルドジョブ終了時にエージェントを破棄するといった方法もあります。

別のサーバーでジョブを実行する効果② 負荷分散

セキュリティに限らず負荷分散という観点でも効果があります。
処理が重たいビルドをJenkinsコントローラーで実行してそのノードのCPUやメモリの負荷が増大した場合、Jenkinsコントローラーが正常に動作しなくなることもあります。
いかに良いCI/CD環境を構築してもJenkinsコントローラーが停止してしまっては意味がありません。
そのためにも分散ビルドの環境を作成するためにJenkinsコントローラーとノードを分け環境を構築することを推奨します。

別のサーバーでジョブを実行する効果③ 異なる環境の提供

また、異なる環境の提供という点でもノードを分けることにはメリットがあります。
例えば開発しているアプリケーションによってはWindows環境だけでなく、異なるOSで同一ソースをビルドするといったケースもあるでしょう。また、Javaの開発の場合JDK8とJDK11で同時にビルドを行いそれぞれのJavaのバージョンでテストを実施したいといったケースもあるかと思います。ノードを分けることでこのような異なる環境を用いたCI/CD環境を実現できます。

セキュリティに負荷分散、異なる環境の提供ですか。メリットは理解しました。
でもノードを分けるとか負荷分散とかちょっと設定が難しそうですね。

そんなことないわよ。次回は実際にノードとエージェントの設定をやっていきましょうか。

Jenkins「マスター」と「コントローラー」

あとちょっとした名称についての補足もしておくわ。

なんですか?

昔は「エージェント」の事を「スレーブ」と呼んでいたのね。
なのでちょっと古い本とかネットとかでは「スレーブ」という単語を目にすることがあると思うけど、
これは「エージェント」と同じ意味なので気にしなくていいわよ。

確かにでてきますね。単語が差別的といった理由からですか?

その通り。
先ほど説明した「Jenkinsコントローラー」についても同様ね。こちらも「Jenkinsマスター」という名称で呼ばれていたけど、主従関係を連想させてしまうという理由で、「コントローラー」に変更になったわ。現時点ではマスターのほうが情報が多いけど、今後コントローラーという単語が増えてくると思うわ。
こちらも知っておくといいわね。

2020年8月12日時点でJenkinsプロジェクトでは「マスター」の代替用語として「コントローラー」になっていることが確認されています。そのため本記事では「コントローラー」という表現を用いております。機能等は「マスター」と変わりはありません。
https://www.jenkins.io/doc/book/glossary/#master
こちらのJenkinsの公式ドキュメントに「マスター:Controllerと同義の非推奨の用語。」と記載されております。

変更の背景としてはCloudBees社のブログにまとめられております。併せてご確認いただければと思います。
Continuous Improvement To Maintain A Culture of Continuous Respect
https://www.cloudbees.com/words-have-power-updating-industry-terms

まとめ

今回は「コントローラー」や「エージェント」といった用語について説明いたしました。
次回以降も引き続きJenkinsの利用方法であったり、用語についても説明を進めていきますが、体系的Jenkinsを学べる講座としてJenkinsトレーニングというものもございます。こちらも併せてご確認いただけると幸いです。
https://cloudbees.techmatrix.jp/jenkins-training/

CI奮闘記一覧