GitLab CEで Zeroダウンタイムアップグレードを試す

# GitLab CE で Zeroダウンタイムアップグレードを試してみます。

## 1. よくある話
最近のオープンソースソフトウェアは非常に更新が激しい(頻繁リリースを旨とするから)のです。

GitLabもご多分に漏れず、結構な頻度でアップデートがリリースされます。
まあ、こんな風になります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/01176077-e9fd-6be4-94fa-11910b4ea238.png)

そうなると、よくある話は「また、メンテナンスしてるの！？(怒) なんでそんなにいつもアップデートしてるねん！(怒怒)」と開発者さんに言われることです(弊社にはいないようですが)。

そういうことを言われてしまうと、ついついアップグレードがおっくうになってしまって放置状態。
そうこうしているうちにアップデートできなくなってしまい...。

という事がよくあります。(弊社社内管理のサーバーでもいろいろ。。)

それを避けるには一所懸命オープンソースのバージョンと合わせてアップデートしていくしかありません。

## 2. GitLabはダウンタイムゼロでアップグレードできるぜ

DBが1カ所であるとなかなかアップデートできないのですが(テーブルのマイグレーションとかあるとね)、
GitLabは、Version 9.1.0からZeroダウンタイムアップグレードができるようになっています。

Updating GitLab installed with the Omnibus GitLab package | GitLab
https://docs.gitlab.com/omnibus/update/README.html#zero-downtime-updates

「これで、開発者からの文句を避けつつ、アップグレードできるぜ！」と思ったのと、
ググってみてもやっている記事を見つけられなかったので、チャレンジしてみます。

## 3. 前提条件

その前に、適用作業が以下の3種類で違うようです。

| Deployment type                              | Description                    |
| -------------------------------------------- | ------------------------------ |
| [Single](https://docs.gitlab.com/omnibus/update/README.html#single-deployment)                 | GitLab CE/EE on a single node  |
| [Multi-node / HA](https://docs.gitlab.com/omnibus/update/README.html#multi-node-ha-deployment) | GitLab CE/EE on multiple nodes |
| [Geo](https://docs.gitlab.com/omnibus/update/README.html#geo-deployment)                       | GitLab EE with Geo enabled     |

また、Zeroダウンタイムアップグレードできる条件と注意事項というのがあります。
Updating GitLab | GitLab
https://docs.gitlab.com/ee/update/README.html#upgrading-without-downtime

1. マイナーアップデート1つ分しかアップデートできないこと
2. パッケージアップデート後の手動作業が必要なこと
3. PostgreSQLを使っていること(MySQLはNG)  
※注1：Zeroダウンタイムアップグレードでは、マイグレーションがバックグラウンドタスクで実行される(特に月次のリリース)のでその間に次のアップデートを実行しないようにする事！  
※注2：アップデートの手動作業には通常のupdateで実行されるバックアップが含まれていないようでした(やってみた結果です)。

今回は、Singleノードです。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/24c880f6-9dd8-6604-ec53-e0920637178b.png)

10.8.3 がインストールされているサーバーですが、10.8.4 がリリースされています。
10.8.3 ---> 10.8.4 にアップデートしてみようと思います。

OSは、Ubuntu 16.04 LTS
omnibusインストールされているGitLabです。

```
GitLab 10.8.3 (564c342)
GitLab Shell 7.1.2
GitLab Workhorse v4.2.1
GitLab API v4
Ruby 2.3.7p456
Rails 4.2.10
postgresql 9.6.8
Gitaly Servers
```

## 4. やってみる

シングルノードの手順は5つです。
### 4-1.  /etc/gitlab/skip-auto-reconfigure ファイルの作成
まず、skip-auto-reconfigure ファイルを作ります。
これによって、sudo apt upgradeしたときに reconfigureされないようです。

```shell:bash
sudo touch /etc/gitlab/skip-auto-reconfigure
```
![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/6f572447-20d5-01af-c303-6fe988280d68.png)
まあ、ファイルができるだけですね。問題ないでしょう。

どうも、Version 10.6からは
`/etc/gitlab/skip-auto-migrations`

じゃなくて、
`/etc/gitlab/skip-auto-reconfigure`
になっているみたいですね(10.6以前の場合は、*skip-auto-migrations* を使いましょう)。

https://github.com/voxpupuli/puppet-gitlab/pull/234/commits/80d356cdfd93efb3921858eedbfecfe3f95947d4

### 4-2. GitLabのパッケージをアップデートします。

```shell:bash
sudo apt-get update && sudo apt-get install gitlab-ce
```

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/88174a28-53a4-0744-7cbd-a4b06879936d.png)

パッケージはアップデートされましたが、reconfigureは実行されませんでした。

GitLabの絵文字の上の **Found /etc/gitlab/skip-auto-reconfigure, exiting...** で終了しています。

### 4-3. reconfigureを手動実行します

```shell:bash
SKIP_POST_DEPLOYMENT_MIGRATIONS=true sudo gitlab-ctl reconfigure
```

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/0d3153ef-e143-5826-d137-589ba2a5710c.png)

reconfigureされたようです。

#### 4-4. DBをマイグレーションします。

```shell:bash
sudo gitlab-rake db:migrate
```

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/0ee7e070-8cc0-ab63-692e-a93e6fc28c4a.png)

サクッとDBマイグレーションも終了しました。
何のメッセージも出なかったということは、DBの更新はなかったんですね。

#### 4-5. アプリ再起動

```shell:bash
sudo gitlab-ctl hup unicorn
sudo gitlab-ctl hup sidekiq
```

unicorn と sidekiq をhupします

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/4050253b-b568-42e7-516f-56ac9d040efe.png)

こちらも何の問題もなく終了しました。

#### 4-6. 結果確認

Adminページをリロードします。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/45b626d5-bd2e-5ddd-4257-01458cfa9f7d.png)

アップデートされました！

なかなか良いのではないでしょうか。

### 5. 結論

OSSは特にバージョンアップして最新版についていくのは非常に重要です。

これで、いつでも気兼ねなくバージョンアップすることできることが確認できました。
私のようなアップデート坊には特に嬉しい機能ではないでしょうか。

### 6. ちなみに

4-1で作ったファイルはアップデート後にどうなるかというと、

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/184fbd86-7a12-e996-ef3c-3063cd91529a.png)

残ります。
次回実行時も上記のアップデート手順が必要になります。

### 7. アップデートシェルスクリプト

cron用に適当に書いたbashスクリプトをgistにアップしておきました。

https://gist.github.com/ynott/3010e4f85ae4f7d185301c88a552e30e

メジャーアップデート(数字の1桁目、2桁目が変わる場合)はアップデートしません。
アップデートがない場合は、すぐ終了します。