見出し画像
Photo by chi_bit_

OpenShiftにJenkinsを構築してGitLabと連携する

tkhm

Jenkins v2を再び立てる機会がやってきた。
今回はOpenShiftの上に構築する。そんで、IaC(Infra as Code)/CasC(Configuration as Code)の実現に当たってはGitLabを使用する。

達成しようとしているのは、
* Jenkinsの本体（マスター）の設定のコード化
* インストールするプラグインのコード化
* シードジョブのためのパイプラインのコード化
* シードジョブを使用したパイプラインのコード化

OpenShift上へのJenkinsの構築とカスタマイズ

OpenShiftではカタログから選ぶとJenkinsはあっという間に構築できる。
悩みうるポイントがあるとすれば設定類を永続化するかどうか。（永続化しない場合＝Ephemeralを使う）
本番利用の時は当たり前に永続化するとして、今回はまだ検証段階なのと、狙い通りコード化できているかを確認しやすいという点で永続化していない。

で、カスタマイズするにあたっては、提供されているJenkinsがテンプレートであり、S2Iできるっぽかった。
いろんなやり方があるように見えたけれど、とりあえず自分の期待にマッチしそうなやり方として、BuildConfigを書いてテンプレートのイメージの一部を更新する。その後カタログから払い出す際に、デフォルトが次のようになっているところを、更新したイメージのイメージ名、タグ名に置き換える、というもの。

Jenkins ImageStreamTag

jenkins:2

↓

custom-jenkins:latest


BuildConfigの一部：

 output:
   to:
     kind: ImageStreamTag
     name: custom-jenkins:latest

これで、自分が構築したJenkinsのイメージをカタログから払い出すことができるようになった。

このカスタマイズとして盛り込む内容は、Red Hatのガイドを参考にした。（アカウントがないと見れないかも）


JenkinsのS2Iに向けて加えた変更

今回自分が加えたのは plugins.txtとシードジョブとして構築時に組み込みたいジョブについての設定だったのだけど、後者が結構大変だった。
上記のRed Hatのガイドページにはこう書かれている。

configuration/jobs
このディレクトリーには、Jenkins ジョブ定義が含まれます。

で、それは一体何？どう書けばいいの？という例は、ない。
日本語だからわかりにくいのかと思い、英語版でも確認したが内容は同じ。
ジョブということで、試しにGroovyのファイルを置いてみるも、Jenkinsで確認しても何も変化がない。

ただ今回は幸いPodとして上がったJenkinsの中身をOpenShiftから直接覗くことができる。
/var/lib/jenkins/以下に必要なものは置いてあり、今回のお目当てだと/var/lib/jenkins/jobs/以下を見れば良さそう。ということで次の手順で確認しながら対応した。


* 手動で新しいジョブを作成
* ターミナルからディレクトリに生成されているものや構成を確認
* 生成されているものをコピーしてS2Iで同じものができることを確認

ジョブのパイプラインごとにディレクトリが一つでき、読み込むスクリプトなどはそのディレクトリの中のworkspaceに置かれることが想定、というのは知らなかった。
また、一つ一つのディレクトリごとにconfig.xmlができて、その中に色々と定義されるというのもわかった。

というわけで、最終的にはこういうディレクトリ構成で落ち着いた。
この状態でビルドされると、Jenkinsの起動時にseedjobと称したパイプラインが1つ初めから作られた状態となる。

.
├── README.md
├── buildconfig.yaml
├── configuration
│   └── jobs
│       └── seedjob
│           ├── config.xml
│           └── workspace
│               └── seedjob.groovy
└── plugins.txt


GitLabとの連携

今回構築した環境では、ライフサイクルの考慮や各責任の境界がクリアになるようにするため、あえて次のような構成に分けている。

1. Jenkins本体のIaC/CasC＋シードジョブのパイプラインIaC/CasC
2. パイプラインのIaC/CasC
3. パイプライン上で実行される各テストのIaC/CasC

下に行くほど頻繁に更新される。一番したのは実際にはアプリのリポジトリなどを想定していて、アプリの横並びでJenkinsfileが置かれその中にテストの内容が描かれるというのが想定。

今ではもう解決しているので難しい話ではないがmultibranchPipelineJobを前提にした設定がなかなか見つけられず苦慮した。GitLabとの連携はこんな感じでできる。（multibranchPipelineJobの前に各種変数の定義は必要）

multibranchPipelineJob(jobName) {
 description(jobDescription)
 branchSources {
   branchSource {
     source {
       gitLabSCMSource {
         id(jobId)
         credentialsId(repoCredentialsId)
         projectOwner(repoOwner)
         projectPath(repoPath)
         serverName(repoHost)
       }
     }
   }
 }
}

設定方法はこれに救われた。
これを見る前はJenkinsの公式を見ていてもなかなか見つけられず、プラグインのGitHubのページを見てもそのものズバリの質問・応答がなく、という状況だった。

You can use the dynamic DSL that it's specific for your installation, more precisely <your_jenkins_url>/plugin/job-dsl/api-viewer/index.html#method/jenkins.scm.api.SCMSource$$List.bitbucket

Further details:
- https://github.com/jenkinsci/job-dsl-plugin/wiki/Dynamic-DSL

Cheers

出典：JobDSL: an example of configuring a bitbucket source trait of bitbucketForkDiscovery in the multibranchPipelineJob is wanted|Jenkins Users Mailing List https://groups.google.com/g/jenkinsci-users/c/11GrDSTbPY8/m/yvk152p1CgAJ

ここで紹介されているAPI Viewerでは、例えばbranchSourcesの中に規定されているのはなにか、などが一覧となって見れる。
いくつかの書籍とそれなりの数のブログ記事は読んでいたけど、これまで見落としていたみたい......。

あまり多くの場所で言及されないのは、生成が動的であり、しかもアクセス先がJenkinsのホストされている環境によって変わってしまうということもあり、紹介しにくいという事情があったのかなと思ってはいる。


これが見つかるまでの間、多くの記事で紹介されているorganizationFolder > organizations > gitLabSCMNavigatorという順番でセットされている例と自分の設定を見比べる時間が長かった。

organizationFolderを使いたいことってあんまりなくて、multibranchPipelineを使うことが多い。
その結果、API Viewerを見るべきとわかるまで、次のリンクなどを見ながら試行錯誤となり時間をそれなりに食った。

これで各リポジトリなども連携が済み、まずは一息つける状態になった。

完全にIaCを実現しようとすると、現在の作りの場合はGitLabのホストされているサーバーの情報をシードジョブを回す前に手動でセットする必要があるとか、認証に使うトークンを手動で配置する必要があるとか、スマートとは言い難い状況になっている。
今の設定に加えて、それらも徐々にコード化を進めていく。

posted on: https://blog.tkhm.dev/2020/12/openshiftjenkinsgitlab.html