GitLabを16万8千光年ワープさせた話（改）

© 2017 UNICAST INC.
2017年11月17日
GitLab Meetup Tokyo #5:
GitLab 10リリース記念
GitLabを16万8千光年ワープさせた話（改）
GITLAB BIG UPGRADE PROJECT --amend

自己紹介
© 2017 UNICAST INC. 1
• ソフトウェアエンジニアといいつつ主にサーバの構築・運用とか
ネットワーク機器の設定・運用をメインでやっています
• オンプレおじさん@31歳
• 日々Ansibleのプレイブックを書く、サーバのお守りをする
• ボタン一発で欲しいサーバができるようにしたい
• 大都会日立市（茨城県）
• 好きなPodcast: Rebuild.fm
LPIC
Leve3 Certified Engineer
Virtualization &High Availability
株式会社ユニキャスト
ソフトウェアエンジニア
野口航（Wataru NOGUCHI）
@wnoguchi
https://blog.pg1x.com/
Acclaim
https://goo.gl/fwxMRB
過去のスライド
https://www.slideshare.net/
watarunoguchi0727

アジェンダ
1. この発表で一番言いたいこと
2. 弊社のGitLabの歴史
3. GitLabを選択するポイント
4. 回想（2017年6月のこと）
5. アップグレード戦略
6. 7.4.3->9.2 までアップグレードする道のり
7. その後7～10月
8. デモ（2段階認証、 Mattermost）

この発表について
GitLabを7.4.3から10.0にアップグレードするまでの
道のりを紹介するもの

免責事項
git commit --amend –m “
社内勉強会で発表したスライドの焼き直し
https://www.slideshare.net/watarunoguchi0727/gitlab168-
gitlab-big-upgrade-project
“

この発表で一番言いたいこと
• 毎月リリースされるアップデートを絶対に放置しないこと
• ペットと一緒で一回飼うと決めたら最後まで面倒見る
• じゃないとあとで大きなツケを払うことになる
• あんまり放置すると
• アップグレードドキュメントも消される(e.g. ownCloud)
• ／(^o^)＼

弊社のGitLabの歴史
古文書(Redmine, ChatWork)によれば
2012年12月10日
社内にGitLab3.1が爆誕
まだGitLabのリポジトリが
GitHubにあったころ

転生を繰り返す

10.0.6

GitLabの導入を検討している人への情報
• GitLabは気軽に導入できる
• SCMすら使わないプロジェクトでどうにかこうにかしてチーム内に
導入したことがある
GitLabは気軽に導入できる

• Ubuntu Server がおすすめ
• CentOS だけがすべての選択肢ではない
• 要求されているパッケージのバージョンが古いからビルド・手動で
持ってこなきゃ
• e.g. Ruby, Redis, Git, Golang, PostgreSQL
• CentOS7.3->7.4でちょっと痛い目を見た
• firewalld複雑に設定してたらSSH繋がらなくなって涙目
（今もまだ直ってないように見受けられる）
• Omnibusパッケージ版ならいい感じにやってくれる
• GitLab社の開発がUbuntu Serverベースで行われているので公式が推奨す
る方法を採用するのがよい
ディストリビューションの選択
This installation guide was created for and tested on Debian/Ubuntu
operating systems.

• ナウい（死語）ソフトウェア、ミドルウェアを使う: GitLab, ownCloud,
KONG, OpenStack等
• PHP7をベースとしたナウい（死語）LAMPスタックを使うならUbuntu
Server
• OSSでディストリの指定がある
Ubuntu Server が適しているシーン

• 特に理由がないのであればOmnibusパッケージ版を強く推奨
• 企業規模がでかすぎて1ノード構成じゃむりぽというスケールアウト可能
な構成とらないといけない理由がある場合に限ってソース版を選択しま
しょう
• https://docs.gitlab.com/ce/install/requirements.html
• https://docs.gitlab.com/ce/install/installation.html
インストール方法の選択

• 悪いことは言わないのでPostgreSQLを使っておきましょう
• Omnibus版はEE版しかサポートしていなかったような・・・
俺はMySQL(or MariaDB)が使いたいんだ

• いつアップグレードするか？
• 毎月21日頃にGitLab新バージョンがリリースされる
• リリース直後は地雷を踏む可能性がある
• 弊社は-0.1バージョンが古い、つまり1ヶ月遅れでアップグレードする
• 毎月アップグレードは実施（じゃないとキャッチアップ大変になる）
アップグレードポリシーの選択

全然大変さが伝わってこない？？

回想（2017年6月のこと）
• Ver 7.4.3 ソース版&MySQL
• GitLabアップグレードしたい
• 比べ物にならないぐらい機能も充実してる
• UIもかっこよくなってる
• 二段階認証対応
• なんかソースの検索かけようとするとInternal Server Error(ISE) になる
• 重い Merge Request を走らせるとすぐ ISE で音を上げる
• キツネのロゴがきもい
• 青い草が生やせる
• AD(LDAP)と連携できる
• Slack Alternative の Mattermost が使える
• そもそもバージョンが古いままであること自体が良くない
• 脆弱性の塊

当時
7.4.3
ソース版
MySQL

最新版
9.2.7
Omnibus パッケージ
PostgreSQL 推奨

アップグレードドキュメント一覧
https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/update

アップグレード戦略
• マイナーバージョンレベルまで完全に一致していないと無理
• ボツ
方法1: GitLab付属のツールでとったバックアップをインポートする

• ユーザー、グループ情報、公開鍵情報が一切引き継がれない
• ゆえに開発、デプロイに大きく支障が出るので廃案
方法2: リポジトリだけ丸ごと最新GitLabに移し替える

• Pros: もっとも安全・確実な方法
• Cons: ひとつひとつ検証して確認していかなければならないためアップグ
レードにものすごい時間がかかる
• 採用
方法3: 愚直にGitLab社の提供しているソースバージョンのアップグレード方
法を一個一個実施していく

アップグレードドキュメント一覧（再掲）

当時のアップグレード作業の過酷さを物語る社内Wiki

• 現行本番KVM仮想マシンをシャットダウンしてイメージ丸ごとコピー
• イメージをraw形式からvmdk形式に変換
• VMware Workstation上でバージョンごとにスナップショットをとっていつでも切
り戻しできるようにして検証
（超便利！！超おすすめ！！）
• RDBMSの変換はPythonのバージョンが違ってかなり大変そうなので最新版まで
上げてからやる
（そう思っていた時期が私にもありました）
• なぜRDBMSの変換が必要なのか
• GitLabがPostgreSQLを使うことを強く推奨
• OmnibusパッケージでMySQLがサポートされるのはGitLab EEのみ
• GitLab CEはPostgreSQL一択
• 検証が全部済んだら
• 土日使って一気に本番環境をアップグレード
• ついでにOmnibusパッケージ版にも変換、ディストリビューションもCentOS6.9
からちゃんと公式でテストされているUbuntu Server16.04 LTSに

検証: 7.4.3→7.14.3
• 2回失敗
• Redisのソケット化がうまくいかなかった
• 3回目にしてやっと成功
• 本当に大丈夫なのかと思った
• diff取るの大変。。。

7.14.3のGitLabの姿

検証: 7.14.3→8.0
• メジャーバージョンアップ
• diff取るの大変。。。

検証: 8.0→8.11→8.5
• 8.0→8.17までやる予定だった
• だんだんバージョンアップ作業に慣れてきた
• というかこのあたりから必要な新設定ファイルを
git show abc123>8.0/new/gitlab.yml
のように予め8.0,8.1,8.2,…,9.0,9.1,9.2まで抽出しておく
• そして差分をWinMergeで視覚的に比較、慎重にvim :sp Vjy C-b w p する
• という効率的なやり方に切り替えていく
• 頭の切り替えが大変だから
• patchコマンド使っても良かったかもしれない
• でもdiffとるのすごくつらい。。。。
• 0.1増えるだけでちょこちょこ設定ファイルやミドルウェアが変わる
• 8.11でついにMySQLのマイグレーションが失敗するようになった
• mysqldumpもMySQL server has gone away
• gone awayしなくなるまでスナップショット戻す
• 8.5まで戻る
• MySQLからPostgreSQLに変換することを真剣に検討しなければいけなくなる

ひたすらdiffをとって設定をコピー

検証: MySQL→PostgreSQL RDBMS変換
• CentOS6.9で標準で入っているPythonのバージョンは2.4
• PostgreSQLに変換するにはPython 2.7が必要
• ビルドするのは絶対イヤ
• あちこち探しまくってYumリポジトリ見つける（一時的にPython 2.7が使える）
• RDBMS変換スクリプトのgitlabブランチをチェックアウトして変換実施
• 動いた。。。。。
• なんで動いているのかわからない。。。。
• 奇跡の技では。。。
$ sudo yum install centos-release-scl-rh
$ sudo yum --enablerepo=centos-sclo-rh -y install python27
$ scl enable python27 bash
$ git clone https://github.com/gitlabhq/mysql-postgresql-converter.git -b gitlab
$ cd mysql-postgresql-converter
$ mysqldump --compatible=postgresql --default-character-set=utf8 -r
gitlab_production.mysql -u root gitlab_production -p
$ python db_converter.py gitlab_production.mysql gitlabhq_production.psql

検証: 8.5→8.17
• バックエンドをPostgreSQLに改めて再度挑戦
• 今度は8.16まで素直に動く
• 8.16ちょっと詰まる
• けど8.17までアップグレードできた
• diff取るの大変だよ。。。。

検証: 8.17→9.0
• メジャーバージョンアップ
• あと一息。。
• 相変わらずdiff取るの大変だよ。。。。

検証: 9.0→9.2
• ガシガシミドルウェアの変更が入る
• いつのまにかグループに公開制御がついていて（8.6あたりから）デフォルトで全
世界に公開する設定になっていて50+個ぐらいのグループをpublicからprivateに
修正。。。
• やっと検証完了（したと思ったら9.3がリリースされた）
• リリースから1ヶ月ぐらい寝かせないとバグ満載で生きた心地しないのでここで
うちやめ

本番: 7.4.3→9.2
• 今までの検証結果をまとめた手順書ベースに一気にアップグレード
• 大ワープ
• 予め検証済みの設定ファイル一式をバージョンを一つ上げるごとにコピーして行
くのでかなり高速
• 万が一に備えてVMはイメージごとバックアップ

本番: CentOS 6.9 Src. Ver. → Ubuntu Server 16.04 LTS Omnibus Package Ver.
• 今度はソースバージョンのGitLabをOmnibusパッケージ版のGitLabに変換
• これは検証間に合ってなかった
• 一発勝負
• ついでにディストリビューションもUbuntu Server 16.04 LTSに変更
• なぜなら開発、テストは主にUbuntu Serverをベースに行われているから
• CentOSは安定している代わりにパッケージのバージョンが圧倒的に古く、無いソ
フトウェアは自力でビルドする必要がある
• 一応うまくいった
• LDAP認証対応(Active Directory)
• httpsのURLクローン対応

本番: 7.4.3→9.2
GitLabロードアベレージ上昇中

本番: 7.4.3→9.2
CPU使用率60%

本番: 7.4.3→9.2
90%

本番: 7.4.3→9.2
メモリ使用量も上昇させます。

本番: 7.4.3→9.2
CPU使用率120%

本番: 7.4.3→9.2
秒読み開始

本番: 7.4.3→9.2
3

本番: 7.4.3→9.2
2

本番: 7.4.3→9.2
1

本番: 7.4.3→9.2
ワーーーープ！！！！！！！

本番: 7.4.3→9.2
ついに、来たんだな、イス●ン●ル・・・

本番: 7.4.3→9.2
ああ・・・そうだ

所感
diff取るのすごく大変でした。。。

一番言いたいこと
導入したソフトウェアの
バージョンアップにはアンテナを張って
こまめにアップデートしていくべき

その後
• 順調にアップデートを重ねていく
• 7月 9.3
• 8月 9.4
• 9月 9.5
• 10月 10.0
基本的にVMのスナップショットとって
sudo apt-get -y install gitlab-ce
するだけ

10.0になった！

Next 10.1

デモ

デモ
イス●ン●ルについたのでデモします。

デモ：2段階認証
• 現在のGitLabは2段階認証に対応しています
• AuthyなりGoogle Authenticatorなり使ってもよし
• ハードウェアトークンYubiKeyにも対応
• Your Ubiquitous Key
• https://www.yubico.com/
• https://www.yubico.com/why-yubico/how-yubikey-works/
• 秘密鍵、管理してますか? YubiKeyで鍵の一元管理とSSH接続、２段階認
証の高速化を試す – Qiita
https://qiita.com/dseg/items/77d77467970b1b510285
• Amazon
• https://www.amazon.co.jp/dp/B018Y1Q71M
YubiKeyを使った2段階認証

デモ：Mattermost
• 現在のGitLab OmnibusパッケージにはMattermostというSlack Alternative
なチャットツールをバンドルしています

デモ：Mattermost
• GitLab Mattermost - GitLab Documentation
https://docs.gitlab.com/omnibus/gitlab-mattermost/
• https://gist.github.com/wnoguchi/d9a79e616aaf06e81522ed681a2921c4
GitLabにMattermost入れたい人へ
-#mattermost_external_url 'https://mattermost.example.com'
+mattermost_external_url 'https://mattermost.demo.pg1x.com'
-# mattermost['gitlab_auth_endpoint'] = "http://gitlab.example.com/oauth/authorize"
-# mattermost['gitlab_token_endpoint'] = "http://gitlab.example.com/oauth/token"
-# mattermost['gitlab_user_api_endpoint'] = "http://gitlab.example.com/api/v4/user"
+mattermost['gitlab_auth_endpoint'] = "https://gitlab.demo.pg1x.com/oauth/authorize"
+mattermost['gitlab_token_endpoint'] = "https://gitlab.demo.pg1x.com/oauth/token"
+mattermost['gitlab_user_api_endpoint'] = "https://gitlab.demo.pg1x.com/api/v4/user"

オフトゥン、、何もかも皆、懐かしい・・・

帰ろう、オフトゥンへ・・・

GitLabを16万8千光年ワープさせた話（改）

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie GitLabを16万8千光年ワープさせた話（改）

Ähnlich wie GitLabを16万8千光年ワープさせた話（改） (20)

Mehr von Wataru NOGUCHI

Mehr von Wataru NOGUCHI (8)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

GitLabを16万8千光年ワープさせた話（改）