Gitlab で redis-server を外部サーバに移行してみた

• 概要
• 環境
• redis-server の設定
  • bind アドレスの変更
• Gitlab の設定
• 動作確認
• 動作確認
• おまけ: flushall したらどうなるか
• 最後に
• 参考サイト

概要

前回 Gitlab の Postgres のプロセスを外部のサーバに移行してみました
Gitlab は内部で redis-server も動作しています
主に非同期処理を担っている Sidekiq が使っています
今回は redis-server を外部のサーバに移行する方法を紹介します

環境

• Ubuntu 16.04
  
  • GitLab Enterprise Edition 12.9.2-ee
• macOS 10.15.4
  
  • PostgreSQL 12.2

redis-server の設定

まずは redis 側の設定を行います
なお今回は redis は単体で動作させるので sentinel などは考慮していません
Gitlab 自体は sentinel にも対応しているので sentinel 環境でも動作します

bind アドレスの変更

• vim /usr/local/etc/redis.conf

bind 192.168.100.1

後に書かれている設定が有効になるので注意してください

• brew services start redis

Gitlab の設定

次に Gitlab 側の設定変更を行います
基本的には gitlab.rb に記載されている redis のエンドポイントを変更するだけです

• vim /etc/gitlab/gitlab.rb

gitlab_rails['redis_host'] = "192.168.100.1"

パスワードの指定やポートの指定がある場合は redis_password や redis_port の指定もしてください
あとは reconfigure すれば OK です

• sudo gitlab-ctl reconfigure
• sudo gitlab-ctl start

動作確認

redis-cli でアクセスしてみましょう
うまく起動していれば外部の redis-server に以下のようなキーが生成されているはずです

resque:gitlab:stat:failed:2020-04-16
resque:gitlab:cron_job:schedule_migrate_external_diffs_worker:enqueued
resque:gitlab:cron_job:sync_seat_link_worker:enqueued
resque:gitlab:cron_job:gitlab_usage_ping_worker:enqueued
resque:gitlab:cron_job:adjourned_projects_deletion_cron_worker:enqueued
resque:gitlab:cron_jobs
resque:gitlab:cron_job:environments_auto_stop_cron_worker
resque:gitlab:cron_job:environments_auto_stop_cron_worker:enqueued
resque:gitlab:cron_job:geo_container_repository_sync_worker:enqueued
cache:gitlab:flipper/v1/feature/prometheus_metrics_view_instrumentation
･･･

一部省略していますが起動するだけで 120 ほどキーが作成されました

動作確認

プロジェクトの作成/削除が行えるか確認してみましょう
問題なければ redis が正常に動作しています

おまけ: flushall したらどうなるか

試してに redis 上のデータが全部なくなったら Gitlab が動作するのが試してみました
Gitlab が起動している状態で FLUSHALL コマンドを発行してみます

192.168.100.1:6379> FLUSHALL
OK
192.168.100.1:6379> keys *
1) "resque:gitlab:ubuntu-xenial:5873:8e3f66aefc21"
2) "resque:gitlab:stat:processed:2020-04-16"
3) "resque:gitlab:stat:failed:2020-04-16"
4) "resque:gitlab:processes"
5) "resque:gitlab:stat:processed"
6) "resque:gitlab:reliable-fetcher-heartbeat-ubuntu-xenial-5873"
7) "resque:gitlab:stat:failed"

いくつかのキーは削除と同時にすぐに作成されました
この状態で Gitlab にアクセスするとユーザはログアウトした状態になりました
おそらくはセッショントークンの情報は redis で管理しているためだと思います
またそれ以外のページの移動は問題なく行えました
やはりキャッシュ的な使い方がメインでキャッシュがない場合は再度生成するだけなのでシステム的にはデータが消えても大きな問題にはならないようです

最後に

Gitlab のコンポーネントの一部である redis を外部に移行してみました
Postgres に比べるとデータの移行はなさそうなので簡単に移行できると思います

外部に移行するこで VM の役割が明確になりまた運用するコマンドも純正の redis-cli などが使えるのでやりやすくなると思います
Sentinel と組み合わせれば更に安定したアーキテクチャにすることができます

参考サイト

• https://docs.gitlab.com/charts/advanced/external-redis/external-omnibus-redis.html