GitLab CIからGitLab CEまたはEEへの移行

GitLab Community Edition(CE) と Enterprise Edition(EE)のバージョン 8.0 以降、GitLab CI は独自のアプリケーションではなく、CE と EE アプリケーションに組み込まれています。

このガイドでは、CIインストールとデータをGitLab CEまたはEEインストールに移行するプロセスを詳しく説明します。GitLab CI 8.0からGitLab 8.0へのみCIデータの移行が可能で、他のバージョン間（7.14から8.1など）の移行はできません。

移行を開始する前に、このドキュメントの移行プロセス全体をお読みになることをお勧めします。

概要

このドキュメントでは、GitLabサーバーとGitLab CIサーバーがあることを想定しています。 これらは同じマシンであっても問題ありません。

移行はGitLabとGitLab CIの更新、データの移動、トラフィックのリダイレクトの3つの部分から成ります。

8.0にアップデートしてから移行が完了するまでの間にGitLabサーバーでトリガーされたCIビルドは失われることに注意してください。 GitLabサーバーは手順のほとんどの間オンラインにすることができます。GitLabのダウンタイムは（もしあれば）8.0へのアップグレード中だけです。8.0にアップグレードした瞬間から移行手順が完了するまで、CIサービスはオフラインになります。

アップグレード前

Omnibus GitLabパッケージを使ってGitLab CIをインストールしているが、既存のデータを移行したくない場合： 

mv /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/gitlab-ci/builds.$(date +%s)

sudo gitlab-ctl reconfigure gitlab.example.com/ciまでご連絡ください。

既存のデータを移行したい場合は、このまま読み進めてください。

0. 7.13より前のバージョンからのOmnibusのアップデート

古いバージョンからアップデートする場合は、まず7.14にアップデートし、その後8.0にアップデートしてください。そうしないと、トラブルシューティングに記載されている問題が発生する可能性がかなり高くなります。

1. バックアップの動作確認

両方のサーバーのバックアップ スクリプトがデータベースに接続できることを確認します。 

# On your CI server:
# Omnibus
sudo chown gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds
sudo gitlab-ci-rake backup:create

# Source
cd /home/gitlab_ci/gitlab-ci
sudo -u gitlab_ci -H bundle exec rake backup:create RAILS_ENV=production

GitLab サーバーも確認してください。 

# On your GitLab server:
# Omnibus
sudo gitlab-backup create SKIP=repositories,uploads

# Source
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production SKIP=repositories,uploads

これに失敗した場合は、8.0にアップグレードする前に修正する必要があります。https://about.gitlab.com/get-help/

NoteGitLab 12.1以前では、gitlab-rake gitlab:backup:createを使用してください。

2. ソースとターゲットのデータベースタイプの確認

GitLabサーバーとCIサーバーで使用しているデータベースを確認してください。 adapter:’行を探してください。 CIサーバーとGitLabサーバーが同じデータベースアダプターを使用している場合は、特に注意する必要はありません。 CIサーバーがMySQLを使用していて、GitLabサーバーがPostgreSQLを使用している場合は、’Moving data’の部分で特別なオプションを渡す必要があります。CIサーバーがPostgreSQLを使用していて、GitLabサーバーがMySQLを使用している場合は、CIデータをGitLab 8.0に移行することはできません。 

# On your CI server:
# Omnibus
sudo gitlab-ci-rake env:info

# Source
cd /home/gitlab_ci/gitlab-ci
sudo -u gitlab_ci -H bundle exec rake env:info RAILS_ENV=production

# On your GitLab server:
# Omnibus
sudo gitlab-rake gitlab:env:info

# Source
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production

3. 保管計画

GitLabサーバー上のCIビルドトレースの保存場所を決める GitLab CIは、CIビルドトレースを保存するためにディスク上のファイルを使用します。これらのビルドトレースのデフォルトパスは/var/opt/gitlab/gitlab-ci/builds (Omnibus)または/home/git/gitlab/builds (Source)です。リポジトリのデータを特別な場所に保存している場合、またはNFSを使用している場合は、ビルドトレースをGitリポジトリと同じストレージに保存することを確認する必要があります。

I. アップグレード

この時点から、GitLab CIはエンドユーザーから利用できなくなります。

1. GitLab 8.0へのアップグレード

まず GitLab サーバーをバージョン 8.0 にアップグレードします：https://about.gitlab.com/update/

2. 移行中はGitLabサーバーのCIを無効にします。

アップデート後、管理画面でCIを一時的に無効にします。管理者として、管理エリア->設定に移動し、継続的インテグレーションで、Disableのチェックを外すと、rake ci:migrate が実行されるまでCIが使用できなくなります（8.0のみ）。

3. CI の設定が GitLab に反映されました。

カスタム CI 設定（ビルドの保存場所の変更など）を使用したい場合は、/etc/gitlab/gitlab.rb (Omnibus) または/home/git/gitlab/config/gitlab.yml (Source) を更新してください。

4. GitLab CIを8.0にアップグレード

GitLab CI をバージョン 8.0 にアップグレードしましょう。Omnibus パッケージを使っている場合は、GitLab を 8.0 にアップグレードしたときにすでにアップグレードされているかもしれません。

5. CIサーバーでGitLab CIを無効にします。

8.0にアップグレードしたらGitLab CIを無効にします。 

# On your CI server:
# Omnibus
sudo gitlab-ctl stop ci-unicorn
sudo gitlab-ctl stop ci-sidekiq

# Source
sudo service gitlab_ci stop
cd /home/gitlab_ci/gitlab-ci
sudo -u gitlab_ci -H bundle exec whenever --clear-crontab RAILS_ENV=production

II. 移動データ

1. データベース暗号化キー

データベースの暗号鍵をCIサーバーからGitLabサーバーに移動します。以下のコマンドは、GitLabサーバーにコピーペーストするために必要なものを示しています。 Omnibus GitLabサーバーでは、/etc/gitlab/gitlab.rbに行を追加する必要があります。ソースからインストールしたGitLabサーバーでは、/home/git/gitlab/config/secrets.ymlの内容を置き換える必要があります。 

# On your CI server:
# Omnibus
sudo gitlab-ci-rake backup:show_secrets

# Source
cd /home/gitlab_ci/gitlab-ci
sudo -u gitlab_ci -H bundle exec rake backup:show_secrets RAILS_ENV=production

2. SQLデータとビルドトレース

最終的なCIのデータエクスポートを作成します。 MySQLからPostgreSQLに変換する場合は、Rakeコマンドの最後にMYSQL_TO_POSTGRESQL=1 。 コマンドが終了すると、データエクスポートアーカイブへのパスが出力されます。このファイルは後で必要になります。 

# On your CI server:
# Omnibus
sudo chown gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds
sudo gitlab-ci-rake backup:create

# Source
cd /home/gitlab_ci/gitlab-ci
sudo -u gitlab_ci -H bundle exec rake backup:create RAILS_ENV=production

3. GitLabサーバーにデータをコピーします。

GitLabとGitLab CIを同じサーバーで動かしていた場合は、このステップは省略できます。

CIのデータアーカイブをGitLabサーバーにコピーします。 これには多くの方法がありますが、ここではSSHエージェント転送と’scp’を使います。 CIサーバーからラップトップにデータアーカイブをコピーし、ラップトップからGitLabサーバーにコピーすることもできます。 

# Start from your laptop
ssh -A ci_admin@ci_server.example
# Now on the CI server
scp /path/to/12345_gitlab_ci_backup.tar gitlab_admin@gitlab_server.example:~

4. GitLabのバックアップフォルダにデータを移動します。

CIデータアーカイブをGitLabで検出できるようにします。 以下では、デフォルトのパスにバックアップを保存することを想定していますが、必要に応じてコマンドを調整してください。 

# On your GitLab server:
# Omnibus
sudo mv /path/to/12345_gitlab_ci_backup.tar /var/opt/gitlab/backups/

# Source
sudo mv /path/to/12345_gitlab_ci_backup.tar /home/git/gitlab/tmp/backups/

5. CIデータをGitLabにインポートします。

このステップでは、GitLabサーバー上に存在するCIデータを削除します。 先ほどGitLabサーバーのCIをオフにしたため、CIデータはまだないはずです。 

# On your GitLab server:
# Omnibus
sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
sudo gitlab-rake ci:migrate

# Source
cd /home/git/gitlab
sudo -u git -H bundle exec rake ci:migrate RAILS_ENV=production

6. GitLabを再起動します。 

# On your GitLab server:
# Omnibus
sudo gitlab-ctl hup unicorn
sudo gitlab-ctl restart sidekiq

# Source
sudo service gitlab reload

III.トラフィックのリダイレクト

GitLabCI をOmnibusパッケージで実行しており、内部 NGINX設定を使用していた場合、CI サービスはci.example.com (旧アドレス) とgitlab.example.com/ciの両方で利用できるようになっているはずです。これで完了です！

GitLab CI をソースからインストールした場合は、既存の CI ランナーが古い CI サーバーのアドレスを使い続けられるように、また既存の CI サーバーへのリンクが機能し続けるように、NGINX でリダイレクトを設定する必要があります。

1. NGINX設定の更新

既存の CI runner が移行したインストールと通信できるようにし、既存のビルドトリガーがまだ動作するようにするには、古いロケーションへのリクエストを新しいロケーションにリダイレクトするように NGINX の設定を更新する必要があります。

/etc/nginx/sites-available/gitlab_ci を編集して貼り付けます： 

# GITLAB CI
server {
  listen 80 default_server;         # e.g., listen 192.168.1.1:80;
  server_name YOUR_CI_SERVER_FQDN;  # e.g., server_name source.example.com;

  access_log  /var/log/nginx/gitlab_ci_access.log;
  error_log   /var/log/nginx/gitlab_ci_error.log;

  # expose API to fix runners
  location /api {
    proxy_read_timeout    300;
    proxy_connect_timeout 300;
    proxy_redirect        off;
    proxy_set_header      X-Real-IP $remote_addr;

    # You need to specify your DNS servers that are able to resolve YOUR_GITLAB_SERVER_FQDN
    resolver 8.8.8.8 8.8.4.4;
    proxy_pass $scheme://YOUR_GITLAB_SERVER_FQDN/ci$request_uri;
  }

  # redirect all other CI requests
  location / {
    return 301 $scheme://YOUR_GITLAB_SERVER_FQDN/ci$request_uri;
  }

  # adjust this to match the largest build log your runners might submit,
  # set to 0 to disable limit
  client_max_body_size 10m;
}

これらのプレースホルダーの値を実際の値で置き換えてください：

  1. YOUR_CI_SERVER_FQDN: GitLab CIインストールの内部公開アドレス（例：ci.gitlab.com）。
  2. YOUR_GITLAB_SERVER_FQDN: GitLab CE（またはEE）インストールの現在の公開アドレス（例：gitlab.com）。

/ci$request_uri 。これはリクエストを適切に転送するために必要です。

また、あなたができることを確認する必要があります：

  1. curl https://YOUR_GITLAB_SERVER_FQDN/ を以前の GitLab CI サーバーから削除します。
  2. curl https://YOUR_CI_SERVER_FQDN/ を GitLab CE (または EE) サーバーから取得します。

2. NGINX設定の確認 

sudo nginx -t

3. NGINXを再起動します。 

sudo /etc/init.d/nginx restart

バックアップからのリストア

何か問題が発生し、バックアップを復元する必要がある場合は、バックアップの復元ガイドを参照してください。

トラブルシューティング

show:シークレット問題（オムニバス限定）

このようなエラーが表示された場合： 

Missing `secret_key_base` or `db_key_base` for 'production' environment. The secrets will be generated and stored in `config/secrets.yml`
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - config/secrets.yml

この問題は、7.13以前のバージョンから8.0に直接アップデートした場合に発生する可能性があります。この問題を解決するには、まずOmnibus 7.14にアップデートし、その後8.0にアップデートします。

アクセス時に権限が拒否されました。/var/opt/gitlab/gitlab-ci/builds

このイシューを解決するには、最終バックアップを実行する前に、ビルド/フォルダの権限を変更する必要があります： 

sudo chown -R gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds

そして、ci:migrate を実行する前に、ビルドフォルダの権限を修正する必要があります： 

sudo chown git:git /var/opt/gitlab/gitlab-ci/builds

CIデータベースをGitLabにインポートする際の問題

CIデータベースをMySQLからPostgreSQLに手動で移行していた場合、インポート中にシーケンスの欠落に関するエラーが表示されることがあります： 

ALTER SEQUENCE
ERROR:  relation "ci_builds_id_seq" does not exist
ERROR:  relation "ci_commits_id_seq" does not exist
ERROR:  relation "ci_events_id_seq" does not exist
ERROR:  relation "ci_jobs_id_seq" does not exist
ERROR:  relation "ci_projects_id_seq" does not exist
ERROR:  relation "ci_runner_projects_id_seq" does not exist
ERROR:  relation "ci_runners_id_seq" does not exist
ERROR:  relation "ci_services_id_seq" does not exist
ERROR:  relation "ci_taggings_id_seq" does not exist
ERROR:  relation "ci_tags_id_seq" does not exist
CREATE TABLE

この問題を解決するには、最終バックアップを実行する前にこのSQLステートメントを適用する必要があります：

Omnibus GitLabのインストール： 

gitlab-ci-rails dbconsole <<EOF
-- ALTER TABLES - DROP DEFAULTS
ALTER TABLE ONLY ci_application_settings ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_builds ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_commits ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_events ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_jobs ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_projects ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_runner_projects ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_runners ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_services ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_taggings ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_tags ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_trigger_requests ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_triggers ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_variables ALTER COLUMN id DROP DEFAULT;
ALTER TABLE ONLY ci_web_hooks ALTER COLUMN id DROP DEFAULT;

-- ALTER SEQUENCES
ALTER SEQUENCE ci_application_settings_id_seq OWNED BY ci_application_settings.id;
ALTER SEQUENCE ci_builds_id_seq OWNED BY ci_builds.id;
ALTER SEQUENCE ci_commits_id_seq OWNED BY ci_commits.id;
ALTER SEQUENCE ci_events_id_seq OWNED BY ci_events.id;
ALTER SEQUENCE ci_jobs_id_seq OWNED BY ci_jobs.id;
ALTER SEQUENCE ci_projects_id_seq OWNED BY ci_projects.id;
ALTER SEQUENCE ci_runner_projects_id_seq OWNED BY ci_runner_projects.id;
ALTER SEQUENCE ci_runners_id_seq OWNED BY ci_runners.id;
ALTER SEQUENCE ci_services_id_seq OWNED BY ci_services.id;
ALTER SEQUENCE ci_taggings_id_seq OWNED BY ci_taggings.id;
ALTER SEQUENCE ci_tags_id_seq OWNED BY ci_tags.id;
ALTER SEQUENCE ci_trigger_requests_id_seq OWNED BY ci_trigger_requests.id;
ALTER SEQUENCE ci_triggers_id_seq OWNED BY ci_triggers.id;
ALTER SEQUENCE ci_variables_id_seq OWNED BY ci_variables.id;
ALTER SEQUENCE ci_web_hooks_id_seq OWNED BY ci_web_hooks.id;

-- ALTER TABLES - RE-APPLY DEFAULTS
ALTER TABLE ONLY ci_application_settings ALTER COLUMN id SET DEFAULT nextval('ci_application_settings_id_seq'::regclass);
ALTER TABLE ONLY ci_builds ALTER COLUMN id SET DEFAULT nextval('ci_builds_id_seq'::regclass);
ALTER TABLE ONLY ci_commits ALTER COLUMN id SET DEFAULT nextval('ci_commits_id_seq'::regclass);
ALTER TABLE ONLY ci_events ALTER COLUMN id SET DEFAULT nextval('ci_events_id_seq'::regclass);
ALTER TABLE ONLY ci_jobs ALTER COLUMN id SET DEFAULT nextval('ci_jobs_id_seq'::regclass);
ALTER TABLE ONLY ci_projects ALTER COLUMN id SET DEFAULT nextval('ci_projects_id_seq'::regclass);
ALTER TABLE ONLY ci_runner_projects ALTER COLUMN id SET DEFAULT nextval('ci_runner_projects_id_seq'::regclass);
ALTER TABLE ONLY ci_runners ALTER COLUMN id SET DEFAULT nextval('ci_runners_id_seq'::regclass);
ALTER TABLE ONLY ci_services ALTER COLUMN id SET DEFAULT nextval('ci_services_id_seq'::regclass);
ALTER TABLE ONLY ci_taggings ALTER COLUMN id SET DEFAULT nextval('ci_taggings_id_seq'::regclass);
ALTER TABLE ONLY ci_tags ALTER COLUMN id SET DEFAULT nextval('ci_tags_id_seq'::regclass);
ALTER TABLE ONLY ci_trigger_requests ALTER COLUMN id SET DEFAULT nextval('ci_trigger_requests_id_seq'::regclass);
ALTER TABLE ONLY ci_triggers ALTER COLUMN id SET DEFAULT nextval('ci_triggers_id_seq'::regclass);
ALTER TABLE ONLY ci_variables ALTER COLUMN id SET DEFAULT nextval('ci_variables_id_seq'::regclass);
ALTER TABLE ONLY ci_web_hooks ALTER COLUMN id SET DEFAULT nextval('ci_web_hooks_id_seq'::regclass);
EOF

ソースインストール： 

cd /home/gitlab_ci/gitlab-ci
sudo -u gitlab_ci -H bundle exec rails dbconsole production <<EOF
... COPY SQL STATEMENTS FROM ABOVE ...
EOF