GitLab User Community Fukuoka に登壇してきました

4/23 に大名ガーデンシティにて開催された GitLab User Community Fukuoka にてゼロバンク・デザインファクトリーから2名が登壇させていただきました。

参加された方、ありがとうございました! 我々としても勉強になりました。
また次回の開催があれば近隣の方々、どうぞご参加を願います！

---

...

これだけだとアレですので、私の発表内容を紹介いたします。

Self-Managed GitLab のアップデートについて

私たちの開発組織では、ソースコードを重要資産と位置付け、その管理およびCIのインフラとして「Self-Managed GitLab」をGoogle Cloud 上の Kubernetes(GKE)上で運用しています。自前でGitLabを運用する上で避けて通れないのが「定期的なバージョンアップデート」です。

「いちばんよい GitLab のバージョン」とは？

まずは GitLab の 「どのバージョンを適用するか」についてまとめます。

GitLabには以下のような明確なリリースケイデンス（リリースサイクル、リズム）があります。

• Major（年1回・毎年5月23日）: 大きな新機能や後方互換性のない変更
• Minor（月1回・毎月第3木曜日）: 後方互換性のある新機能の追加（例：UIデザインの変更など）
• Patch（月2回・毎月第2/第4水曜日＋必要に応じて）: バグ修正やセキュリティフィックス（例：XSSの修正など）

GitLabの公式の推奨は常に「最新バージョン」の利用であり、過去のバージョンへの修正（バックポート）は最新から2つ前のマイナーバージョンまでしか提供されません。
(重要なセキュリティフィックスなどはそれよりも前のバージョンに対してもリリースされることがあるそうです)

また当然のことながら新機能を利用できるのは新しいバージョンです。

アップグレードパス

リリースケイデンスの他に考慮する必要があるものがアップグレードパスです。
アップグレード時には内部でデータベースの構造が大きく変わることがあります。
そのため、いきなり最新版へジャンプしてアップデートすることはできません。途中の「特定のバージョン」を順番に経由しながら、階段を一段ずつ上るようにシステムを更新していく必要があります。この決められた安全なルートのことを「アップグレードパス」と呼びます。

たとえば 16.11 から 18.10 までの　2年分のアップグレードを実施しようとすると10回のアップグレードパスを経由する必要があります。

アップグレードパスを確認するためのツールを GitLab は提供しています。
https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/

アップデートポリシー

GitLab のリリースサイクルを踏まえた上で、私たちがArchitectural Decision Records (ADRs)として定めたアップデートポリシーは 「毎月アップデートを行う」 です。

セキュアに保ちたいということと、段階的なアップデートが必要になると大変なのでそれを避けたいことがモチベーションになっています。

ただし最新版は適用せず、その1つ前のマイナーバージョンを適用するスケジュールを定めました。
これにより、世界のどこかで私たちが遭遇する問題に先立って対処する方がいらっしゃることになり、 Issue をみれば、大抵のケースは解決するという状況になります。常に最新バージョンを利用して、Issue 報告する方には感謝しております。

アップデート作業

リリースノートの確認

まずはリリースノートの確認です。
Slack で リリースノート の feed をサブスクライブしており、リリースノートを読んでおります。
我々が要望したり、欲しかった機能がリリースノートに記載されると嬉しく盛り上がります

またリリースノートでは新機能だけでなく、removal milestone と release-deprecations のセクションにも注目しており、運用上の問題が発生しないかについても確認しています。

逆に読み飛ばしがちなのは UI の変更で記載はあるものの体感してみるまで、(少なくとも私は)わからんな、と思っており、某ファミレスの間違い探し並の難度だと思っております。

UI の変更については以下の URL で確認することができますが、個々の変化を認識することは難しい部分でもあります。
https://papercuts.gitlab.com/

検証環境(staging) の更新

リリースノートの確認後にまず検証環境(staging) の更新を実施します。
この環境では更新の他に運用している環境に大きく影響する変更を試したりもしています。(GitLab DAP の有効化など)
ここで、アップデート時に必要な対応の不足(Database のバージョン更新の必要性など)や UI の更新について確認します。

アップデート手順

アップデート手順ではまず、GitLab にて Broadcast message を登録します。
これにより、UI 上と git push した場合に登録したメッセージが表示されます。そのため、利用者には伝わっていると信じております。

我々の構成は Kubernetes(GKE) 上の deploy であるため、GitLab Helm chart を利用しています。
GitLab を更新するということ自体は Helm chart のバージョンをインクリメントし、ArgoCD から適用(apply)を行うというものになっています。

つまり適用時の変更は以下のようなものであり、この変更を MR をマージすることで更新が実施されます。

   - name: gitlab
     namespace: gitlab
     chart: gitlab/gitlab
-    version: 9.8.3
+    version: 9.9.3
     values:
       - "./values.yaml"
     needs:

またこの時、動作確認用の スクリプトを用意しています。
GitLab には 公式の Diagnostics tools である gitlabsos というものがありますが、それよりもユーザ目線での動作確認を行うもので、基本的で必要な機能がうまく動いているかを確認するものです。

今後

日々の運用ではこのように頻繁なアップデートに取り組んでいます。
できれば達成してみたいことは GitLab は毎月のリリースで notable-contributors というものを発表しており、いつか何らかの Merge Reuqest を送ってみたいな、と思っております。

補遺

イベントの際に会場で「GitLab の運用環境として Kubernetes を利用することはオススメできるか？」という質問がありました。

Kubernetes には難しさがあることは否定できません。GitLab の Reference architectures をみてもかなり贅沢な構成です。
https://docs.gitlab.com/administration/reference_architectures/cloud_native_first/

しかし、我々は サービスそのものを Kubernetes 上に構築していることから組織内のスキルとしては十分にあります。
また GitLab Runner を Kubernetes で動かすことでスケールが容易であるという利点があります。