【CI奮闘記】第13章:これまでに構築した内容をもう少し詳しく知る!


前回のブログでは、Jenkinsのパイプラインに通知機能を実装する方法を説明しました。
前回のブログはこちら
今回は一歩踏み込んだ「こういった場合どうすればいいの?」といった内容について確認していく記事となります。

はじめに

登場人物

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

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

これまでに構築した内容をもう少し詳しく知る!

前回まででパイプラインの大枠が完成したわね。

あとエージェントの作成についても、
・AWSのインスタンスをエージェントとして利用する
という事もやったじゃない?

ちょっと発展形のやつですね。必要な時にだけインスタンスを立ち上げて、というAWSインスタンスの特性を生かした構築方法でしたね。

そんな感じで、今回は今まで構築してきた内容に対して「こういったこともできる?」という、ちょっと深堀した内容についていくつか触れていきましょう。

今回のブログではいままで実際にいただいた質問のなかから以下の内容について記載します。

Dockerをエージェントとして利用する場合に、どのノードでコンテナを起動させるか指定したい

じゃあ早速。さっき話題にあがった「AWSのインスタンスをエージェントとして利用する」に関連して、エージェント関連の質問です。
こないだ調べていたら「Dockerコンテナをエージェントとして利用することができる」という文面がでてきて便利だなーと思ったんです。
ただ、Dockerコンテナを利用するにしても何らかのノードは必要じゃないですか。例えば

pipeline {
    agent {
        docker { image 'node:7-alpine' }
    }
   ・・・・

こんな感じで指定した場合、どのノード上でコンテナが起動するんですか?

Jenkinsに設定済みのどこかのノード上ね。
デフォルトではJenkinsは設定済みのノードすべてでDockerが実行可能と認識して実行するわ。
なので特に指定しない限り、設定済みのノードすべてでDockerが実行できるように設定する必要があるわね。

全部のノードにDockerをインストールして利用できるようにするのはちょっと手間ですね。「Dockerを利用するときはこのノードを使う」といった指定はできないんですか?

Jenkinsの管理にあるグローバルオプションで指定できるわ。
パイプラインの実行でDockerを利用するノードをラベルで指定するの。
このページも併せて確認してみてね。
https://www.jenkins.io/doc/book/pipeline/docker/#specifying-a-docker-label

Jenkinsのジョブの実行タイミングはどの程度制御できるのか

パイプラインに承認、Webhookを追加する」の章でJenkinsのジョブを自動実行するためにWebhookを追加したじゃないですか。
サンプルではpushのタイミングで実行という設定にしていましたが、このWebhookってどの程度細やかに指定ができるんですか?

設定したpushはもちろん、Pull request(Merge request)やIssueが作成されたとき等々設定が可能ね。
これはJenkinsの制約というよりもGitHubやGitLabといった構成管理ツール側に依存するわ。
例えばGitHubやGitLabだと、こういったものをWebhook eventsとして設定ができるわ。
・GitHub:https://docs.github.com/ja/developers/webhooks-and-events/webhooks/webhook-events-and-payloads
・GItLab:https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html

GitHubのWebhookイベントの設定項目。画面ショット範囲の下にも設定項目が続きます。

基本的にはイベントが貼れそうなものは大体できるイメージですね。

そうね。いままで作ってきたようなビルドや静的解析のといった開発プロセスを自動化するパイプラインのトリガーとするのはpushやPull request(Merge request)が多いと思うわ。

たしかに。ちなみになんですが、GitHubやGitLabはわかったのですが、Subversionの場合どうなりますか?SubversionにはWebhookは無いですよね。

Subversionの場合フックスクリプトを利用すると良いわ。JenkinsのSubversionのプラグインのページ(Post-commit hook)に設定方法が記載されているからこちらを確認すると良いわね。

Subversionでもコミットのタイミングに合わせてジョブを実行するという事は可能なんですね。ちなみにですが、SCMって特定の部署が管理していて、現場でこういったSCM側への設定ができないという事もあると思うんです。そういった場合にいい方法はありますか?

その場合SCMポーリング(pollSCM)の仕組みを用いることになるわ。

SCMポーリングとは何ですか?

定期的にJenkinsがSCMをチェックしに行って、変更があったときだけジョブを実行するという仕組みね。ただ、どうしてもチェックする間隔のタイムラグが発生するので、可能であればWebhookやフックスクリプトでジョブを実行する仕組みができると良いわね。

なるほどです。ちなみになんですが、その「変更があったときだけ」という条件に、例えば特定のフォルダに変更があったときだけ実行するという事もできるんですか?

SCMポーリングの仕組みとしてはできないわ。
プラグインや独自に実装をすればできると思うけど、プラグインに関しては
・長期間メンテナンスされていないもの
・利用者が少ないもの
・>The current version of this plugin contains a vulnerability: という問題のあるプラグイン
しか見当たらなかったのであまり現実的ではないわね。
ジョブ自体は実行されてしまうけど、Whenディレクティブのchangesetでステージ自体の実行を回避するといった方法が現実的な対応になるかと思うわ。
例えばresource/hoge.txtに変更が加わった際にのみ実行したいという場合、以下のようにwhenディレクティブを記載すればそのステージは実行されるようになるわ。


when { 
  changeset "resource/hoge.txt"
}

Jenkinsの移行ってどうすれば良いの?

構築したJenkinsを別サーバーに移行する場合何かいい方法ありますか?
インストールからすべて同じようにセットアップを行わなければならないのでしょうか?

そんな事しなくて大丈夫よ。
Jenkinsのジョブの設定データやプラグインの情報等Jenkinsの設定の大部分はJENKINS_HOMEに保存されているわ。
移行先のマシンにJenkinsをインストールして、JENKINS_HOMEのフォルダ内のデータを新しいマシンのJENKINS_HOME以下に移動すれば移行の大部分は完了よ。
一部、例えば認証情報についてはインストールしたマシン固有のIDを元に暗号化されているから移行先のJenkinsで再度設定する必要があったり、エージェントの設定は移行先の環境で再度構築する必要はあるけど、基本的にはこれで完了よ。
JENKINS_HOMEの設定はダッシュボード > Jenkinsの管理 > システムの設定 > ホームディレクトリで確認ができるわ。

という事はバックアップとかもJENKINS_HOMEのデータを保存しておけば問題無いんですか?

基本的には。
あとはバックアップ用のプラグインとかもあるので、そちらも併せて検討してもいいかもね。
https://plugins.jenkins.io/backup/
https://plugins.jenkins.io/thinBackup/

なるほどプラグインも良いですね。
そんなに難しくなさそうで良かったです。

詳しい移行手順を確認したい場合はこちらの記事が参考になると思うわ。
https://support.cloudbees.com/hc/en-us/articles/216241937-Migration-Guide-CloudBees-CI

まとめ

今回は過去Jenkinsトレーニングで講師を行っていた時に受けた質問やJenkinsのテクニカルサポートで受けた質問を元にブログ記事を記載しました。
Jenkinsトレーニングではトレーニングを通じてJenkinsの知識を深めていただく以外にも質疑応答の時間を設け、「自社環境だとこうだが、この場合どうすれば良いか」といった直接トレーニングの対象ではない質疑応答についても受け付けております。
テクニカルサポートは、認定CloudBees Jenkinsエンジニアによるチケット制のテクニカルサポートになります。例えば「ネットで調べた記事だと表面的なことしかわからない。もう一歩踏み込んだ内容が知りたい」といった場合にご利用いただければと思います。
ご検討いただけると幸いです。

CI環境アセスメントサービス

既に構築済のJenkins環境について、継続的な利用や今後のスケールアップ、CI/CDの計画を考慮した適切な構成であるかを明らかにします。

詳細はこちら

CI環境構築サービス

Jenkinsの認定資格保有エンジニアが貴社の環境に合わせて、Jenkinsのインストールからジョブの作成・保守を行います。

詳細はこちら

Jenkinsトレーニング

Jenkinsをこれから利用する方、継続的インテグレーションの導入に取り組んでいる方、さらに、Jenkinsの知識を深めたい方に、オススメの各種トレーニングを開催。

詳細はこちら