既存のJenkinsサーバをEKS上に移行する #kubernetes

はじめに

私が所属するDevOpsチームではEKS上で開発向けasleadというサービスを展開しています。asleadではCI/CDツールとしてGitLab Runnerを採用しているのですが、Jenkinsを利用しているユーザーも多く移行コストがかかるため、EKS上にJenkinsを構築しサポートすることにしました。本記事ではEKS上にJenkinsを構築・移植する観点で手順を説明します。

方針

EKS環境にHelmを利用してJenkinsサーバを構築し、既存オンプレ環境のJenkins資産を移行します。
サーバ側の設定や認証など基本機能についてはこちらで作業を実施し、管理対象であるプロジェクトの移行はユーザー側で実施いただくことになりました。

構成

以下の移行先の現行構成に、HelmのJenkinsを追加します。

master/slave構成の検討

Jenkinsのmaster/slave機能はHelm版でも利用できます。

方式

master方式

Helm Chartでslave podを無効にした場合、master podですべての処理を行います。

master-slave方式

master-slave方式ではmaster podで設定を行い、揮発性のslave podでジョブを実行します。ジョブが完了したらslave podは消滅します。
Helm Chartで各slave pod毎にイメージを選択したり個別の設定を行うことができます。Jenkinsで管理するソフトウェア毎に異なるビルド・実行環境を用意したい場合、slave podを容易に準備し割り当てることができるため有効です。
masterの設定に加えて、以下のslaveの設定を追加すれば利用できます
- Chart内でagentセクション、kubernetesのプラグインを設定
- デプロイ後、Jenkins UIのConfigureCloudsのページでslave pod利用の設定

課題

master-slave方式の場合、ジョブとpodの対応をパイプラインの形式で記述する必要があり、移植コストがかかる

結論

当初master-slave方式で検討を進めていましたが、上記課題に記載のとおり、既存のJenkinsから移行する際にパイプライン形式にジョブを移植する必要がありました。
そもそもJenkinsを希望するユーザーは移植コストを抑えることが主な目的であること、今回のテナントでは全てのプロジェクトで同一のビルド・実行環境でよいという要件であったため、前者のmaster方式を採択しました。

構築の手順

ここから手順になります。

1. S3バケットの作成

Jenkinsのアプリケーションバックアップの手段が用意されているため、設定情報を記述するvalue.yamlで設定行うことでS3にバックアップを取得できます。

value.yamlのパラメータは後ほど記載しますが、先にバックアップの保存先となるS3バケットを作成します。Jenkinsコンテナ内の/home/jenkins配下のファイルがバックアップされます。

2. AWS Backupの設定

EBSバックアップの設定を行います。
アプリケーションバックアップも設定していますが、リストアを考えるとEBSバックアップから行う方が簡単かつ確実なためです。

3. JenkinsのHelm Chartをダウンロード

公式からHelm Chartをダウンロードします。
https://github.com/helm/charts/tree/master/stable/jenkins

今回使用したバージョンは以下です。

Chartバージョン	アプリバージョン
2.1.0	2.235.3

4. Helm Chartのパラメータの設定

value.yamlで以下のパラーメータを設定します。

名前	デフォルト値	設定値	内容
initContainerEnv	(空)	(環境変数)	initコンテナでの環境変数の設定
containerEnv	(空)	(環境変数)	masterコンテナの環境変数の設定
javaOpts	(空)	(環境変数)	java_ops環境変数の設定
serviceType	ClusterIP	NodePort	サービスの種類
installPlugins	`kubernetes:1.25.7` - `workflow-job:2.39` - `workflow-aggregator:2.6` - `credentials-binding:1.22` - `git:4.2.2` - `configuration-as-code:1.41`	（インストールするプラグイン）	インストールするプラグインを設定。デプロイ後UIからも追加可能。
ingress.enabled	false	true	Ingressの設定。今回は構築済み。
ingress.annotations	(空)	(ingressのannotations)	ingressのannotations
agent.enabled	true	false	slaveの設定
backup.enabled	false	true	アプリケーションバックアップの設定
backup.schedule	02***	19***	バックアップ取得のCronJobのスケジュール設定(UTC時間)
backup.annotations	(空)	iam.amazonaws.com/role: -S3FullAccessRole	backup podのannotations
backup.env.name	(空)	AWS_REGION	バックアップ環境変数
backup.env.value	(空)	ap-northeast-1	バックアップのリージョン
backup.env.destination	s3://jenkins-data/backup	(手順2で作成したS3バケット)	バックアップを保存するオブジェクトストレージのアクセス先

デフォルトではbackupジョブ起動時にbackup podがたち完了後も残ります。
jenkins-backup-cronjob.yamlでpodの世代数を指定するためパラメータを追加します。

名前	デフォルト値	設定値	内容
successfulJobsHistoryLimit	(空)	1	バックアップジョブ成功時のpodの世代数
failedJobsHistoryLimit	(空)	1	バックアップジョブ失敗時のpodの世代数

5. Jenkinsをデプロイ

以下のコマンドで、パラメータ設定済みのvalue.yamlを使用してJenkinsをデプロイします。

$ helm install --name jenkins --namespace jenkins ./jenkins

Deployment、service、Podの状態を確認します。（起動までには数分かかります）
起動すれば以下のような結果が返ってきます。initとmasterコンテナが起動した状態です。

$ kubectl get pod -n jenkins
NAMESPACE     NAME                                                         READY   STATUS    RESTARTS   AGE
jenkins       jenkins-786dbcf7dc-mjqvb                                    2/2     Running   0          4h19m

6. JenkinsのUIへのアクセス

以下のコマンドで、ingressで割り当てられたJenkinsのアドレス、ポートが確認できます。

$ kubectl get ing -n jenkins

Webブラウザからhttp://上記で確認したアドレス:ポートでアクセスできます。初回は認証はなくトップページが表示されます。