JenkinsとCodePipelineの比較
はじめに
部署の組織方針の変更に伴い構成管理としてCICDパイプラインの構築を行う機会が増えてきました。
最初の案件ではCodeシリーズを使用して、AWS上にパイプラインを構築し、現在の案件ではオンプレ環境でJenkinsを使用してパイプラインを構築しています。(時代の変化に逆行していて悲しい。。。)
そんな中でパイプラインごとに色々と異なる点が見えてきて、チーム会で共有することとなったので、その時の比較情報を簡単にまとめて投稿したいと思います。
IaC
インフラ情報やパイプライン情報をどこまでコードで管理できるかという観点で比較していきます。
環境情報
Jenkins
Jenkins自体の設定値やプラグインについてはJenkins ConfigurationAsCodeプラグインを使用することでファイルで管理可能。
パイプラインの章で記載しますが、パイプラインそのもの(パイプライン名やどのJenkinsfileを適用するかの情報)はファイルで定義することができず、手動で作成する必要がある。
CodePipeline
パイプラインだけでなくパイプライン内で使用するCodeBuildやCodeDeploy,CodeCommitを互いの依存関係、内部で使用するパラメータまで含めてCloud Formationでコード管理することができる。
(やっぱりCloudFormationはIaCのツールとして偉大ですね。)
使用するパラメータはパラメータストアやシークレットマネージャ等のサービスを使用することで、暗号化して管理することができる。
パイプライン
Jenkins
JenkinsFileでパイプラインの動作内容を管理する。
基本的には各ステージでシェルスクリプトを呼び出すことで処理内容を実装していくことになる。
ステージは自由に設定可能でビルド、テスト、デプロイ以外の操作を行う際にもステージ分けが行いやすい。
JenkinsFileの記載方法についての記事が少なく、細かな情報を取得するのに苦労するが、内容を雰囲気で理解しやすく、作成されたコードの理解は比較的容易。
パイプラインにJenkinsfileを設定することで、パイプライン起動時に
JenkinsFileの内容を読み込んでパイプラインの処理内容を設定してくれるが、パイプラインそのものを自動作成することはできない。パイプラインの作成とJenkinsFileの設定は手動で行う必要がある。
(もしパイプラインも自動作成可能だよって情報を持っている方がいたら教えていただきたいです。)
CodePipeline
CodeBuildのビルド設定はbuildspec.yml、CodeDeployによるデプロイにはappspec.yamlが必要となる。
CloudFormationの設定ファイルも含め、パイプラインの構成ファイルの数が多くなってしまいがち。
また、buildspec.yamlではinstall,prebuild,build,post_build…のように定義可能なphaseも決められているので、Jenkinsfileほどの自由度はない
(Jenkinsfileのステージに当たる部分はパイプライン側で定義するものなので、単純比較できるものではない)
パイプライン作成のコンソール画面が
1. パイプラインの設定を選択
2. ソースステージを追加
3. ビルドステージを追加
4. デプロイステージを追加
5. レビュー
の5Stepからなるように構成が最初から決められており、Jenkinsに比べて自由度は低い(独自のステージを追加することは可能です。)
また、AWS外のツールやサービスとの統合機能は限られているため、特殊な要件があるようなケースに弱い
管理
サーバー管理の煩雑さやロール制御、コストの面で比較
サーバー管理
Jenkins
Jenkinsを起動するサーバーの管理が必要
CodePipeline
フルマネージドサービスのためサーバー管理は不要
（自身の管理するVPCやプライベートサブネット内に閉じた環境で開発を行いたい場合は、CodeBuildのプロジェクト作成時に自身が管理するVPCやプライベートサブネットを指定することで、ネットワーク的に閉じた環境で完結させることも可能）
権限管理
Jenkins
Role-based Authorization Strategyプラグインを導入することで、ユーザーごとに利用・閲覧可能なパイプラインやジョブを、ロールベースで制限することが可能
CodePipeline
IAMでパイプライン名を指定した条件付きロールを作成することで、ユーザーごとに利用・閲覧可能なパイプラインの制限が可能
コスト
Jenkins
オープンソースのため無料。
ただし、Jenkinsを動かすためのサーバーを用意する必要があるため、その分の料金がかかる。
(具体的な金額は要件により異なるが、EC2での常時起動での比較だとCodeシリーズより高額になる)
CodePipeline
従量課金される。
実行時間などにもよるが、常時起動する場合に比べて安価で済む。
詳細な料金についてはAWS公式が料金計算ツールを公開してくれている。
https://aws.amazon.com/jp/codebuild/pricing/
※Mac環境を使用する場合は最低起動時間が24時間のため、利用料金が高額になりがちなため注意が必要
可用性
Jenkins
自前で負荷分散、冗長性の確保、バックアップ、DR対策が必要
スケーラビリティを確保するにはあらかじめ追加のサーバを用意しておく必要がある。
CodePipeline
自動スケールによる負荷分散、AZ、リージョン分割による冗長性の確保、バックアップ、DR対策を容易に行うことができる。
ドキュメントの多様さ
検索時にヒットする記事数で比較
Jenkins
約 363,000,000 件
AWS Code Service
約 258,000,000 件
Jenkinsfile
約 1,080,000 件
CloudFormation
約 9,930,000 件
実際に作業を行なっての所感としてJenkinsfileについて欲しい情報を見つけるのはかなり難しい。(日本語だとほぼ記事が存在しない)
ChatGPTのおかげでなんとかなった感が半端ない(ChatGPT4凄すぎる笑)
使用可能な言語
Java
Python
Node.js
Ruby
.NET
Go
PHP
(言語ではないが)Docker
Jenkins
主要な言語はプラグインで全てサポート。
その他のものもカスタムスクリプトにより対応可能。
CodePIpeline
主要な言語は全てサポート
その他のものもCodeBuildでカスタムDockerイメージを使用することで対応可能
使用可能なGitサービス
今回は使用機会が多いGitサービスとして
・GitHub
・GitLab
・CodeCommit
の３つで比較を行う。
Jenkins
全てのGitサービスを利用可能。
更新を検知しての自動起動についても、
GitHub,GitLabはGitサービス側にWebHookを設定する事で可能。
CodeCommitについてはAWS CodeCommit Trigger というCodeCommitの更新イベントをSQSとSNSを利用して検知するプラグインが作成されているが、未解決のセキュリティ脆弱性が発表されており、更新が2年前に止まっているため、実質自前での開発が必須。(CodeCommitを使用しながらローカルのJenkinsを使用する機会は無い気がしますが)
CodePipeline
全てのGItサービスを利用可能
GitHub,GitLabはGitサービス側にWebHookを設定する事で可能。
(GitLabは以前まではサポート対象外でLambda＋APIGatewayを使用しての連携が必要だったが、2023/8のアップデートでサポート対象に加わった)
CodeCommitの場合は特別な設定を行わなくてもCloudWatchEventにより変更を検知して起動することが可能
まとめ
Jenkinsは自由度が高い分自身で設定、管理しないといけない項目が多く、Codeシリーズはマネージドサービスである分、自由度は低くなってしまうが、自身で管理が必要な項目が少なく工数を削減しやすく、一定の水準の担保がしやすいという特徴があります。
今後システム構築を型化して、誰でも一定レベルの成果物を出すことを目指していくのであれば、マネージドサービスであるCodeシリーズを使用していくよう舵を切っていくのが良いのではないかと考えます。
この記事が気に入ったらサポートをしてみませんか？