[オンプレ] GitLab を移設, アップデートする [Docker]

オンプレミスで稼働している GitLab を他のマシンに移設, ついでにアップデートした備忘録です。

 

 

環境

• GitLab-CE on Docker (v12.10.3)
• CPU: Ryzen 3700X --> EPYC 7742 x2
• ネットワーク: 外部へアクセス可 --> 基本的に不可

GitLab は以前設置した Dockerコンテナ(=Omnibus-package)。
CPU を記載した理由は後述。
ネットワークは主に docker pull に影響。
 

事前知識, 前準備

現行動作している GitLabバージョン確認と、オフライン環境での docker pull について。
 

現行GitLabバージョン確認

公式にアップデートについて記載がある。
GitLab のアップデートは、一発で最新まであげることは一般的にはできないようだ。
現在稼働しているバージョン以降の主要な系列の最新版を順に適用していく必要がある。

現在稼働しているバージョンの確認方法。

今回の私の場合は、v12.10.3 が動いていたので、公式のインストラクションに則って、
12.10.14 → 13.0.14 → 13.1.11 → 13.2.9 という順でアップデートを行う。
 

オフラインで docker pull

今回の移設先は、ssh などでプロキシサーバーにポートフォワードしない限り、
基本的には外へでることができない環境である。
Docker で 127.0.0.1/localhost を proxy に設定するとなぜか上手く動作しないので(※)、
（※curl, git, apt など他は全て問題なく動作する環境下においても）
上記のいくつかのGitLabバージョンをオフラインでも pull できるようしておく必要がある。
以下がその流れである。

• 外へ出れる別マシンにおいて
  • $ docker pull gitlab/gitlab-ce:12.10.14-ce.0
  • $ docker save -o gitlab-ce_12.10.14.tar gitlab/gitlab-ce:12.10.14-ce.0
  • 移設先のマシンへ tarファイルをコピー
• 移設先マシンにおいて
  • $ docker load -i gitlab-ce_12.10.14.tar
  • ($ docker pull gitlab/gitlab-ce:12.10.14-ce.0)

 

バックアップ

docker コマンドを使ってホスト側からバックアップを生成できる。

コンテナ内の /var/opt/gitlab/backups (に相当するホスト側の場所） に *_gitlab_backup.tar が生成される。
 

移設

元の環境で動作させていた docker-compose.yml を基本的に踏襲してコンテナを立ち上げます。
ただし image 指定が latest 等になっている場合は、元の環境の GitLab のバージョンを直接指定します。
データの移行は、同バージョン間で行う必要があります。

docker-compose.yml が準備できたら以下でデータを移行します。

• $ docker-compose up -d
• $ docker exec -it [container] gitlab-ctl status
  全ての daemon が走っていること, 起動が完了している事を確認
• $ docker exec -it [container] gitlab-ctl stop puma(unicorn)
• $ docker exec -it [container] gitlab-ctl stop sidekiq
• $ docker exec -it [container] gitlab-ctl status
  puma(unicorn) と sidekiq が停止していることを確認
• バックアップ: *_gitlab_backup.tar を移行先の backups 以下へ(所有権などに注意!!)
• $ docker exec -it [container] gitlab-backup restore BACKUP=~ (_gitlab_backup.tar の前まで)
• 元環境から gitlab-secrets.json をコピー
• $ docker restart [container]

 

アップデート

バージョン確認で説明したように、アップデートは一発で最新まであげることは一般的にはできない。
以下再掲。

docker-compose.yml の image 指定箇所で適切なバージョンを設定して起動、を繰り返すことで、
既存のデータや設定を新しいバージョンに適応させて正しく移行することができる。
 

[オプション] サブディレクトリ アクセス

http(s)://hogehoge.jp/gitlab/ のようなURLでアクセスできるようにする。
リバースプロキシには nginx を利用, proxy_pass に http://127.0.0.1:xxxxx を指定する。

さらに、docker-compose.yml の environment として以下を設定する。

 

移設後, レスポンスが遅い!? [解決済]

移設後にしばらくハマったのがこの問題。
マシンスペックは圧倒的のはずなのに、接続すると応答がなぜか逐一モタつく。

データ移行時にすでにその前兆があって、
移設先で元環境と同じバージョンを docker-compose でデプロイしても、
移設先でのみなぜか unicorn がエラーを吐いてうまく起動しない。
既存データをコピーせず、真っさらな状態から開始してもやはりコケる。
そこで gitlab.rb で unicorn を false, puma を true に変更しました。

このようにすると同じ環境のデプロイ, 既存データの移行, アップデートまではうまくいったのですが、
いざ使ってみると一々レスポンスが悪く使い勝手が非常に悪いことに気がつきました。

結果から言うと、どうやら puma の　worker 数が自動設定だと多すぎて逆に遅くなっていたようです。
公式の当該項 に詳細説明があるが、puma の worker数は多くの場合ホストのコア(スレッド)数に設定される。
今回の場合 EPYC 7742 x2 という環境なので puma worker が 256 も生成されるようになっていた。
そこで、gitlab.rb で puma['worker_process'] を調整する(減らす) ことでレスポンスが大幅に改善した。
(min/max_threads 設定も有効化した）

unicorn がうまく動作しなかったのもおそらく同様の理由ではないかと想像します。
 

トラブルシューティング

実体験に基づくトラブルシューティングを少しだけ。
 

移設後、既存レポジトリの設定を変更できない

バックアップデータをリストア後、gitlab-secrets.json ファイルを移設元からコピーし忘れていませんか？（１敗）
 

多コア, 多スレッド環境でむしろ遅い

worker数が自動設定では多くなりすぎているのかもしれません。
私の場合は worker数が 256 で、アクセスの度に 1-2 秒待たされるようになりました(puma)。
gitlab.rb で puma['worker_process'] を調整して見てください。
移設後, レスポンスが悪い!? を参照。
 

多コア, 多スレッド環境で unicorn がコケる

gitblab.rb で puma を試してみてください。
unicorn の worker数を制限するのも奏功するかもしれません。
移設後, レスポンスが悪い!? を参照。