はじめに
ご無沙汰しております。ネタがなく、記事の投稿も滞っていました。
困ったことがないと言えば聞こえはいいですが、正直もう少しいろいろなことで困って、なんやかんやあって試行錯誤して解決する、という体験が欲しいと思ったり思わなかったり。
直近はそんな状況でしたが、今回、
GitLabのアップグレードパス
という、聞き慣れないワードを耳にしました。
賞味よくわからないのですが、わからないなりに情報を集めたので、それを備忘録として残そうと思います。
前提
今回は、Linux系のサーバにGitLabが導入されていて、それをアップデートする前提で記述させていただきます。
Linux系システムへのツール導入
以前、RADIUSサーバの話を投稿した際、導入の方法も記載しました。
たとえば、RHEL系であれば
# gitlab-ctl stop
でGitLabのサービスを停止した後に
# yum install gitlab-ee
または
# dnf install gitlab-ee
でアップデートすればいいのでは？と考えていました。
けどそれだとダメらしくて、そこで出てくるのが今回のアップグレードパスという概念です。
アップグレードパス
詳細は公式ドキュメントに記載があるので、そちらをご覧ください。
GitLabは、ある版から別の版にアップグレードする際、特定の版へのアップデートを経由して最終目的の版へのアップデートを行う必要があるようで、その一連の版のことをこう呼ぶと理解しました。
原文だと
An upgrade path involves steps to move from your current GitLab version to the GitLab version you want to upgrade to.
と書いてあり、版というよりかは手順そのものを指している模様。この辺は、自分が"path"という単語に引っ張られすぎているだけかもしれない。
アップデートパスは、下記サイトで確認できます。
たとえば、v18.0.0から、v18.10.1 (2026/3/27時点で、表示の中での最新版) にアップデートする場合、
ツールでは、結果はこのように表示されます。
つまり、最終目的であるv18.10.1を入れるために
- v18.2.8
- v18.5.5
- v18.8.7
を入れる必要がある、ということになります。
面倒くさいですね。
なぜこんな面倒なことが必要かについて、明言はされていないように思いましたが、
上記の公式ドキュメントのページにて
Allow the background migrations for the upgrade to finish.
とあり、GitLabそのものだけでなく、バックグラウンドもいろいろと変えていて、一発で変えるとその辺の整合性が取れなくなるとか、そういった理由なのだと思われます。
おわりに
今回は、普段あまり触れないインフラ周りの話をネタにしてみました。
インフラとかネットワークとかはどうにも苦手ですが、こんな感じで調べつつデモ解消できればいいなと思います。
以上、ここまでお読みいただきありがとうございました。