Jenkins を使ってバッチ処理を行っているプログラム群がある。プラグインのアップデートをしたところスレーブ機能の設定が飛んだということで、改めて設定した際のメモ。
実現したいこと
- マスターサーバーでスケジュール管理
- マスターサーバーでログ管理
- 大量データを処理する長時間処理を、高性能なスレーブサーバーに任せる
- スレーブサーバーを使い終わったら自動でターミネートする
参考：Jenkinsを使った自動テスト環境を作る（後編）――Dockerコンテナを使って自動ビルドを実行する | さくらのナレッジ
環境
- Jenkins 2.332.1
- Amazon EC2 (ec2-plugin) 1.68
指定の必要がある項目
Jenkinsの管理 > ノードの管理 > Configure Clouds からスレーブサーバーの設定を行う
Amazon EC2
- Name: スレーブサーバーを置くAWS アカウントの名前を入れた
- Amazon EC2 Credentials: 利用対象の IAM 権限を渡す。Jenkinsの管理 > Manage Credentials からクレデンシャル登録を行っておく
- Region: スレーブサーバーを置くリージョン。今回は普通に ap-northeast-1
- EC2 Key Pair's Private Key: スレーブサーバーへのssh接続用情報、こちらもManage Credentials から追加しておく
AMIs
- AMI ID: 利用する AMI のID
- Instance Type: AMI のタイプに合っていないと無言でエラーになって起動できないので注意
- Availability Zone: 後で指定するサブネットのAZと合わせないとエラーになる
- Security group names: nameだけどセキュリティグループIDじゃないとエラーになる。マスターのいるSGからのインバウンドを許可しておく
- Remote FS root: とりあえず今回は /var/jenkins で問題ない
- Remote user: ssh接続するユーザー名。今回は ec2-user
- Labels: ジョブ側から指定する時のスレーブサーバータイプのお名前
- 用途: このマシーンを特定ジョブ専用にする。明示的にこのノードを使用するよう指定された場合のみこのノードで作業が行われる
以下は「高度な設定」を開いて設定する。
- Subnet IDs for VPC: ここを指定しないとデフォルトVPCに置かれてしまう
- Tags: Name = [お好きなお名前]。これくらいはやっておかないとEC2のコンソールで探しづらいので
- Associate Public IP: 今回はインターネットを使う必要があるプログラムなので、パブリックIP付与。パブサブネットに建てる
注意事項
マスターからスレーブへのssh接続には5分以上かかる
Launch Timeout in seconds を設定しているとタイムアウトの可能性がある
https://issues.jenkins.io/browse/JENKINS-62724
Host Key Verification Strategy は check-new-hard が推奨
らしい。以前のバージョンではデフォルトで check-new-soft だったようだが……
https://github.com/jenkinsci/ec2-plugin/#strategies
そもそもを考えれば
このバッチ処理たちのアーキテクトを今の自分がイチから組むとしたら、Cloudwatch のクーロンと AWS Batch の組み合わせにすると思う。処理時間15分以上かかるかつ大量データ扱う以上 Lambda では無理だし。サーバーのお世話をしたくない。プラグインのバージョン問題に悩まされたくない。そもそものバッチプログラムを Docker 上で動くように組む。
移行にかかる工数（ほぼほぼ元のバッチプログラムの変更になるだろうけど）を考えると、あえてそれを今やるという判断にならないのだろうが……
マスター/スレーブという言葉もあまり使うべきではなかったね。