Self-managed GitLab で Renovate を GitLab CI から動かしていたところ、EC2 のストレージ使用量が継続的に増加していることに気付きました。
原因は Renovate そのものというより、Docker イメージの蓄積でした。
同様の構成で運用した場合に起こり得る事象と感じたため、原因と対策をまとめておきます。
何が起きたか
Grafana で GitLab サーバのストレージ使用量を確認していたところ、ディスク使用量が継続的に増加していました。
Jenkins ではストレージアラートを設定していましたが、GitLab 側では主にメモリ使用量を監視していたため、グラフを確認したタイミングでストレージ使用量の増加傾向を把握しました。
右肩上がりで使用量が増加し、cleanup 実施後に大きく低下している点を見ると、不要データが継続的に蓄積していたことが分かります。
原因
当時は Renovate のコンテナイメージを latest で運用していました。
この状態で定期実行すると、renovate/renovate:latest の更新に伴って旧イメージが Docker 上で <none> として残り、/var/lib/docker 配下に蓄積されていきます。
GitLab と Runner を同じ EC2 上で動かしていたため、その影響が GitLab サーバのルートボリューム使用量の増加として現れていました。
調査時には docker system df -v で <none> の大きなイメージが多数見つかりました。
復旧
まず、停止済みコンテナを削除しました。
sudo docker container prune -f
次に、不要になったイメージを削除しました。
sudo docker image prune -f
必要に応じて、未使用イメージもまとめて削除しました。
sudo docker image prune -a -f
未使用ボリュームも整理したい場合は、こちらを実行します。
sudo docker volume prune -f
この対応により、ディスク使用率は大きく改善しました。
教訓
.gitlab-ci.yml で Renovate に latest を使わないことです。 固定タグでの運用は、再現性やセキュリティの観点でも推奨される一般的な運用であり、今回のようなストレージ逼迫の防止にもつながります。
現在は、Renovate のイメージを renovate/renovate:43.52.0 に固定しています。テンプレートを include しつつ、RENOVATE_IMAGE 変数を定義し、renovate ジョブでそれを利用しています。対象リポジトリは RENOVATE_REPOSITORIES で明示し、手動実行またはスケジュール実行のルールにしています。
実際の設定は次のとおりです。
include:
- remote: "https://gitlab.com/renovate-bot/renovate-runner/-/raw/v24.0.0/templates/renovate.gitlab-ci.yml"
variables:
RENOVATE_IMAGE: "renovate/renovate:43.52.0"
RENOVATE_EXTRA_FLAGS: ""
RENOVATE_REPOSITORIES: ＜Renovate対象のリポジトリ＞
renovate:
image: $RENOVATE_IMAGE
rules:
- if: '$CI_PIPELINE_SOURCE == "web"'
- if: '$CI_PIPELINE_SOURCE == "schedule"'
振り返り
今回あらためて感じたのは、GitLab に対してもストレージ使用量の監視を明確にしておくことの重要性です。
Grafana で可視化していたことで増加傾向を把握できた一方で、Jenkins と同様に GitLab 側でもストレージ使用量の変化を把握しやすい運用にしておくと、より早く気付けます。
まとめ
Renovate は便利ですが、latest 指定で実行すると Docker イメージが蓄積し、GitLab サーバのストレージ使用量に影響することがあります。
Renovate を GitLab CI で動かす場合は、.gitlab-ci.yml で latest を使わず、固定タグで運用しましょう！ 固定タグでの運用は、再現性・セキュリティの観点でも推奨される一般的な運用です。