Jenkinsの管理をIaC(Infrastructure as Code)に載せることで、運用コストの削減・不正な操作についての耐性・知見の共有といった様々な恩恵が受けられる。
具体的には以下のようなツールを使うことについて、この記事では述べようと思う。
- Jenkins初期設定についてはdockerなどで管理を行う
- Jenkinsの設定管理をConfiguration as Code Pluginにより管理をする
- 認証設定についてはsaml pluginを、認可設定についてはrole-strategy pluginによりRBAC管理を行う
- JenkinsのJobについては、job-dsl pluginで管理を行う
はじめに
Jenkins については説明するまでも無い有名なツールであると言えよう。ただし用途については人・会社によって違う所があり、CIのみに利用している企業やCDにも利用している企業などそれぞれだ。どのような利用用途においてもJenkins本体の運用は必要であり、Jenkins本体の管理・運用にははじめの頃はgood practiceがわからなく、手動で構築したJenkinsがそのままなんとなしに運用されてしまっている...といった事例が数多くあると思う。
ここでは一例として、どのようにすればJenkinsをIaCに載せることが出来るのかについて説明したい。IaCに載せることについては、ざっくりと以下のようなメリットがあると思ってくれれば良い。
- 再構築可能なJenkinsとなること
- Jenkinsの設定変更をコードで管理ができること
- コードレビューによる変更のフローが入ることで、より安全に、より知見が共有されるものとなる
今回語らないこととしては以下のようなものをあげる
- Jenkins以外の同様のツールとの比較
- Jenkins X - Cloud Native CI/CD Built On Kubernetes
- 実行環境になるNodeの話
JenkinsをIaCで管理する
Jenkins本体の起動から初期設定
以下のような案が考えられるが、ここは特に注目すべき点はない。Jenkinsはfile systemが必要となるため、NFSなどをmountするのも良い。
- 提供されているdocker imageを利用する案
- https://hub.docker.com/_/jenkins
- 上記ページに記載の通り起動パラメータなどを設定可能
init.groovy.dなどにgroovy scriptをmountさせれば、任意の設定についてもこの段階で設定可能
- VMに対してansibleでjenkinsを構築する案
- yum installのような操作でjenkins-ltsをinstallする
- docker image側同様、任意の設定をこのタイミングですることも可能
既に任意の設定がこの状態で可能となるが、ここでは必要なpluginのinstall以外はJCasC pluginに出来る限り設定を移すことを勧めたい。
Jenkins Configuration as Code pluginによる設定管理
Jenkinsの設定として、built-in nodeやagent nodeにはどのようなものを使うのか、Global toolsには何を入れるのか、各種pluginの個別設定をどうするのか...などと行ったものがある。これらの設定を上記初期設定の中でgroovy scriptなどで行うことも可能だが、ここではJenkins Configuration as Code plugin (JCasC)について紹介する。
JCasCはざっくり言うと、Jenkinsの全ての設定について1つのyamlで管理してしまおうと言うものだ。何が嬉しいって、こちらをinstallした後に /configuration-as-code/ へアクセスすると、既存の設定が全てyamlでdownload出来る。つまりもしIaCされていない野良Jenkinsがいるならば、設定を一括で落としてさえしまえばそのままIaC出来るのである。後はこのjenkins.yamlという設定ファイルをGitHubなどで管理をすれば、コードレビューのフローに載せることが出来る。
jenkins.yamlの反映については、初期設定で行う中でloadする設定を入れるのも良いし、最初は画面上からファイルを読み込むのでも良い。それ以外にもjenkins-cliで apply-configuration という操作で反映しても良い。
注意点として、credentialsを利用している場合、上記のjenkins.yamlにはbase64されただけのcredentialsが入っている。IaCする上で、jenkins.yamlにsecretを直接埋め込みたくない場合などもあるが、 Configuration as Code AWS SSM secrets | Jenkins plugin などを利用することで、予め設定をしておいたAWS Parameter StoreのSecretStringなどを取得することも可能だ。
認証・認可の設定
認証にはsaml pluginなどで他のIdPに委譲させてしまうのが望ましい。これはJenkinsに限らず、どのようなサービスを利用する場合においても同じである。全てのサービスに対してSingle Sign On出来る状態を目指し、人の管理はIdP側で全て行うべきである。
加えて、Jenkinsにおいてもその認証情報に基づき認可の設定をすべき状況は多々あるはずである。認可はRBAC or ABACでやるのがもはや常識だが、Jenkinsにも Role-based Authorization Strategy | Jenkins plugin が存在する。この設定をJCasC pluginで行うことで、IaCで認可設定を行うことが可能だ。
一例として、管理者のみがJenkins本体の設定を変更出来るようにする（全てJCasCで定義するならもはや不要だが）、運用チームAは ^path/to/team-a/.* 以下のJobのみ実行できる権限を持つ、運用チームBは ^path/to/team-b/.* のみ実行できる権限を持つ、全ての開発者チームにはJobを直接編集させないしCredentialsも見れないようにする、といったような設定をすることなど可能だ。後述するが、Jobの定義も本来は各チームがIaCで定義を行い、レビューの通ったもののみが反映されることが望ましいと考える。任意にJobを変更出来てしまうと、他の人の目を通っていない処理を迂闊に実行できてしまう。もちろんこれはより厳しくしているケースの話であり、これを緩めることは任意に可能である。
管理者や運用チームといった情報は、saml pluginを利用している場合は、group idのような情報がIdPから連携される。Jenkinsで /me/ にアクセスすると、自身がどのようなGroupsに属しているかも確認出来るかと思う。このGroupsに対して、role-strategy pluginにより、どのような操作ができるかを設定すれば良い。
注意点として、role-strategy pluginのread権限だとJob設定をread出来ない。これについては左の記事にある通り、 Extended Read Permission | Jenkins plugin にある Job/ExtendedRead といった権限を追加する必要がある。
Jobの定義
Jobの定義方法をIaCする方法にもいくつか手段があると思う
- Jenkinsfileで設定を行う
- Groovy scriptでJobの定義を行う
- job-dsl pluginでJobの定義を行う
一例として、 Job DSL | Jenkins plugin を運用に載せる方法についてを考える。
job-dsl pluginを利用すると、特定のrepositoryに定義されたjob一覧をまとめて1つのJobから指定のdirectory配下に生成することが可能だ。つまり、 認証・認可の設定 の所であげた運用チームA/Bのような物がある場合、運用チームAが管理するjob-dsl repositoryが実行できる^path/to/team-a/job-dsl-for-team-aというJobを1つ用意して、^path/to/team-a/*. 配下にJobを作成するといったことをすると、運用チームAがIaCで定義したJobを運用チームAが実行のみできるJobとして生成されるのである。 job-dsl-for-team-a のjobについても編集を行えないようにした上で、protected branchのみ実行出来る状態にすることで、必ずレビューの通ったJobのみが生成される環境が出来あがる。もちろんJob自体の定義はJenkinsfileで行うことも可能である。
〆
今回はJenkinsをIaCにより管理・運用しつつ、全てのJob定義もIaCでレビューされたものしか実行されないような環境の提供方法を記載した。
株式会社FOLIOでは、上記のような事例を利用しつつJenkinsの運用負荷を下げる取り組みなどを実施して、「技術と想像で"未来の金融"の礎となる」Visionを掲げて事業を展開しています。このようなサービス開発に興味のある人は、ぜひ 会社紹介資料 を参考にしつつ、以下のtwitterまでDMください。カジュアルに話をしたいなどもウェルカムです。
Ken Kaizu (@krrrr38) / Twitter
（本ブログの他記事にあるとおり、Jenkins以外にEKS上で動くArgo Workflow etcなどもあるので、そちらなどにも興味があれば是非）
