春の入門連載2024の10日目です。
はじめに
こんにちは。今回初めてブログを書きます、流通サービスグループの中邨です。
最近、業務で初めてJenkinsに触れたので、以下についてまとめます。「そもそもJenkinsとは?」「CI/CDって何?」 という人に読んでいただけたら嬉しいです。
- Jenkinsで何ができるのか/何が嬉しいのか
- Jenkinsを初めて触ってみた感想
- WSL2上のDockerでJenkinsを動かして簡単なジョブを作ってみる
Jenkinsとは何か?
Jenkinsで何ができるのか
JenkinsはCI/CDツールの1つで、アプリケーションのビルド、テスト、デプロイといったタスク実行を自動化できます。
CI/CDは continuous integration and continuous delivery/continuous deployment の略で、日本語では「継続的インテグレーション/継続的デリバリー(継続的デプロイ)」と訳されます。
何が嬉しいのか
あるコードに変更を加えると、別の部分と矛盾が生じてビルドできなくなるなどの影響を及ぼしてしまうことがあります。
ビルドやテストを自動化することで、コード変更をリポジトリに適用するごとにバグがないか検証し、アプリケーションを常に正常に動く状態に保つことができます(継続的インテグレーション)。
また、ワンクリックでアプリケーションをデプロイできたり(継続的デリバリー)、開発者が変更をプッシュするたびに実稼働環境に自動でデプロイできたりすると(継続的デプロイ)、デプロイを迅速かつ頻繁に行って品質を高めることができるようになります。
Jenkinsを初めて触ってみた感想
私の主観になりますが、CI/CD初心者が初めてJenkinsを使ってみた感想です。
心理的ハードルが高い
CI/CDツールをほぼ触ったことがない状態で、既に沢山のジョブが動いているプロジェクト環境のJenkinsで試しにジョブを作ろうとしたとき、個人的には少しハードルが高く感じました。
例えば、自PC上の壊してもいい環境でJenkinsを動かしたことがあれば、ハードルが下がってより身近に感じられるのではないでしょうか。
この記事の後半では、Jenkinsを身近に感じるため、実際にWSL2上のDockerでJenkinsを動かして簡単なジョブを作成してみます。
デバッグがつらい
アプリケーションのコードを書くのとは違い、Jenkinsの動作確認にはデバッグツールがありません。もっといいやり方があるのではないか・・・? と思いながらも、次のサイクルを繰り返してジョブを作成しました。
- ジョブの設定を変更
- ジョブを実行
- 想定した結果になっているか確かめる
- 想定と違ったらコンソールログを読み、エラーの原因を突き止める
- ジョブの設定を変更
- ・・・(以下1からループ)
また今回は踏み込めなかったのですが、Jenkinsfileと呼ばれるファイルにGroovyでジョブを定義することで、ジョブをコード化することもできるようです。コード化されていればバージョン管理や移植も容易になって良いなと思いました(Infrastructure as a Codeですね)
その他のCI/CDツールとの違い
Jenkinsはその前身を含めると約20年ほど前に誕生した歴史の長いツールですが、他にも様々なCI/CDツールがあり、ツールによってどこが違うのか気になってきました。
ざっくり調べると、専用のサーバを立てて実行する必要があるJenkinsに対して、GitHubリポジトリがあればGitHub上で利用できるGitHub Actionsや、AWS上でCI/CDを完結できるCodeBuildやCodeDeployなどがあり、導入コストや管理のしやすさを比較して選定することが多いようです。
WSL2上のDockerでJenkinsを動かして簡単なジョブを作ってみる
以下で行うのは実際のビルドやテストよりずいぶん単純な内容ですが、入門記事なので「Jenkinsでこんなことができる」というイメージの一助になればいいなと思っています。
WSL2とDockerの環境構築
本記事の主題ではないため、解説は別の記事に譲ります。
以下の手順は、環境があることを前提としています。
Dockerイメージの取得とコンテナ起動
Docker HubからJenkinsのDockerイメージを取得します。
Dockerリポジトリから任意のバージョンのイメージを指定してpullします。
※2024年4月19日時点の最新は 2.440.3-lts-jdk17
なのでこちらを使用します。
docker pull jenkins/jenkins:2.440.3-lts-jdk17 |
とりあえず起動できれば良いので、ポート番号だけ指定してコンテナを起動します。設定を保存したい場合はボリュームを指定してください。
※その他のオプションは公式ドキュメントのDocker用説明にサンプルがあります。
docker run -p 8080:8080 jenkins/jenkins:2.440.3-lts-jdk17 |
公式ドキュメントのセットアップウィザードの手順に沿ってセットアップします。
※プラグインは推奨を選択、admin以外の管理者ユーザーとJenkins URLはとりあえず作成せずスキップで大丈夫です。
コンソールにHello
シェルスクリプトを実行してコンソールに出力してみます。
新規ジョブ作成をクリックします。
適当なジョブ名を入力し、「フリースタイル・プロジェクトのビルド」を選択して「OK」
適当な説明を入力して下にスクロールします。
「Build Steps」>「ビルド手順の追加」から「シェルの実行」を選択します。
シェルスクリプトに以下を記述して保存します。
echo "Hello"
ジョブをつなげて実行する
test-job-A、test-job-B を作成し、A、Bの順番に実行してみます。
- 最初の例と同様に、フリースタイル・プロジェクトで空のジョブ test-job-A、test-job-B を作成します。
- 「test-job-A」の「Build Steps」>「ビルド後の処理の追加」から「他のプロジェクトのビルド」を選択します。
- 対象プロジェクトに「test-job-B」を入力して保存します。
- 「test-job-A」を実行すると、下流プロジェクトの「test-job-B」も実行されていることがわかります。
Gitリポジトリをチェックアウトする
- GitHubにとりあえず空のpublicリポジトリを作成します。
- 「test-job-git」ジョブの「ソースコード管理」で「Git」を選択し、リポジトリURLとブランチ名を入力します。
※チェックアウトするだけなので認証情報は特に入力していません。 - ジョブを実行してコンソール出力を見ると、(ビルドするものは何もありませんが)正常終了しています。
- ワークスペースの中を見ると、リポジトリの内容(READMEファイル)が取得されています。
さいごに
CI/CDはシステム開発を縁の下で支える存在ですが、ITの入り口からはなかなか見えにくい・機会がないと触りにくい部分なのではないか、と常々思っていました。
この記事を通して、JenkinsやCI/CDを少し身近に感じていただけたら嬉しいです。
(参考)