概要

社内のオンプレ版Gitlab CE 13.1.xをAWS EC2に移行した際のメモ

移行前後の環境対比

	移行前	移行後
OS	CentOS 7	Amazon Linux 2
Gitlab	CE 13.1.x(オンプレ版)	EE 14.10.2(Docker版)
通信	HTTP	HTTPS(ALB + ACM)

Docker、AWS ALB + ACM（SSL証明書）などの導入方法は割愛します。

構成

Gitlab Omnibus版の構成を理解しくことで適切に設定できるようになります。
ざっくりとした流れはこんな感じです。
クライアント → ALB → ターゲットグループ → EC2 → Gitlabコンテナ（Nginx → gitlab-workhorse → puma → Gitlab）

※参考：【GitLab】アーキテクチャ

前提条件

mattermostの移行は含まれていない（必要な方は別途コメント頂ければ回答可能）
pagesの移行は含まれていない（CIでpageをS3に保存し、Nginxで公開するようにした）
registoryの移行は含まれていない（ECRを使うようにした）
gitリモートのプロトコルはhttpsのみ
下記の説明用にドメイン名はhogefuga.comを用いる

手順

オンプレ版Gitlabでバックアップを取得する。
BKファイルをS3のアップロードする。（後述のEC2にBKファイルをULできる場所ならどこでもよい）
Route53にGitlab用のドメイン（仮gitlab.hogefuga.com）を設定する。
Gitlab用のターゲットグループ（ポートは80）を作成する。
ALBの443のリスナールールでGitlabのターゲットグループに転送するように設定する。

gitlab.rbをAWS + ALB環境に合わせて修正する。
AWS環境に依存する設定はだいたい以下の2か所を修正すればOK。

external_url 'https://gitlab.hogefuga.com'
# ALB経由になるので、ヘッダーを修正
nginx['proxy_set_headers'] = {
    "Host" => "$http_host_with_default",
    "X-Real-IP" => "$remote_addr",
    "X-Forwarded-For" => "$proxy_add_x_forwarded_for",
    "X-Forwarded-Proto" => "https",
    "X-Forwarded-Ssl" => "off",
    "Upgrade" => "$http_upgrade",
    "Connection" => "$connection_upgrade",
    "Access-Control-Allow-Origin" => "*"
}

EC2にDocker版Gitlabを構築する。
- オンプレ版と同じバージョンでなければならない
- ストレージ容量はリストア時にオンプレのBKファイル＋そのBKファイルの展開分＋実データ分を予め確保しておく必要があります。
- メンテナンスがしやすいようにデータ領域は別EBSに分離することをおすすめします。
ターゲットグループにEC2を追加する。
https://gitlab.hogefuga.comにアクセスし、gitlabの画面が表示されることを確認する。
初期化処理で起動に時間を要するので、コンテナログを確認しつつ、様子見てください。
gitlabコンテナ内で/var/opt/gitlab/backupsを作成し、フォルダの所有権をgit:gitに変更する。
backupsフォルダ内にBKファイルを配置する。
公式手順に従ってリストアする
途中にリストアしますか？のダイアログが表示されるので、その表示なしにする場合は、こちらを参照してください。
リストア後Gitlabが起動でき、リストアできていることを確認する
以降のバージョンアップはdocker-compose.ymlの「gitlabのコンテナイメージのタグを更新 → 起動 → 動作確認」を繰り返していく。
バージョンアップは経由しなければならないバージョンがあるので、バージョンアップパスを参考にしつつバージョンアップしてください
※gitlabのコンテナイメージを更新していくとローカルに不要なイメージが溜まるので、適宜に削除してください！

バージョンアップ履歴

ce → eeに切り替えるタイミングは任意のタイミングでOK
docker-compose.ymlのコンテナイメージ名を変更するだけ。

バージョン	備考
15.4.0
15.3.0
15.1.6
15.1.0
15.0.5
14.10.5
14.10.0	自環境では必須だった。 `gitlab-rake gitlab:background_migrations:finalize[ProjectNamespaces::BackfillProjectNamespaces,projects,id,'[null\,"up"]']`
14.9.0
14.8.0
14.7.0
14.6.0
14.5.0
14.4.0
14.3.0
14.2.7
14.2.0
14.1.8
14.1.0
14.0.12
14.0.0
13.12.15
13.7.9
13.7.1	AWS＋Docker化

トラブルシュート

アップグレード中にDB migrationでエラーが発生した場合は、表示されたコマンド(gitlab-rake xxx)を実行する。

ただし、gitlab-rakeコマンドの処理が完了しないうちに（エラーになり）再起動されることがあるので、以下の「migrateが間に合わない時の対応法」を参照してください。

なお、コマンドが表示されていない場合は、以下のコマンドをエラーが発生したバージョンで実行するとコマンドが表示される。

> gitlab-rake db:migrate --trace

# ホストで実行する場合

> docker exec -it gitlab gitlab-rake gitlab:background_migrations:

migrateが間に合わない時の対応法

docker compose up -d中に上記で表示されたコマンドを実行するも間に合わないことがあるので、以下の方法で実行する

docker compose up -d中に/assets/wrapperのGITLAB_OMNIBUS_CONFIG= /opt/gitlab/embedded/bin/runsvdir-start &の&を削除し、保存する
docker compose restartする
docker exec -it gitlab bashでログインし、gitlab-ctl reconfigureを実行する
再度DB migrationエラーが表示されるのを確認する
gitlab-ctl statusでpostgresが起動していることを確認する
DB migrationエラーで表示されたコマンド（gitlab-rake xxx）を実行する
1の修正を元に戻す