概要
社内のオンプレ版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の修正を元に戻す