2023.10.02

オンプレミス GitLab をみんなに使ってもらう前に

GitLab の設定や構成変更はそれほど難しくはありません。しかし、中には利用者に追加の作業をしなければならないケースもあります。

これらの周知などの付随作業は、開発チーム内で運用している GitLab ではあまり問題になりません。組織内に展開した誰がどのように利用しているかわからない GitLab では慎重にならざるを得ず、設定変更にかかるコストが高くなります。

このブログでは、利用者が増えた後では変更が難しい設定や構成をいくつか紹介します。

みんなに使ってもらう前に

Relative URL を避ける

GitLab は https://gitlab.example.com のような GitLab 専用のドメインを割り当てることが一般的ですが、https://example.com/gitlab のようにドメインを他のサービスと共有することもできます。GitLab はこの機能を Relative URL と呼んでいて、公式にサポートされています。

しかし、この Relative URL での GitLab のテストが不足しているようで、バグを踏むことが多いです。

これらのバグは Relative URL が原因と特定するまでに時間を要します。また、バグが報告されてから修正され、バグ修正版がリリースされ、運用中の GitLab に適用するまかなりの期間が必要です。一つ一つの対策コストはそれほどでもないかもしれませんが、ちりも積もればかなりの量になります。

中には Jira isseu integration のように、Relative URL 下での利用ができない機能もあります。このような制限はごく一部だけですが、利用したい人にとっては致命的になります。

Relative URL で構築した GitLab は、これらの理由により、どこかでか専用ドメインに変更する必要に迫られます。

GitLab の設定を専用のドメインに変更するのは簡単です。しかし、GitLab のイシューや Wiki、もしくは組織内のドキュメントやメールに貼り付けられた URL が変わるわけではありません。URL の変更を GitLab の利用者に周知しなければなりませんし、古い URL から新しい URL へリダイレクトするサーバーも構築し運用しなければなりません。

GitLab の利用者が増えれば増えるほど、設定変更に伴うこれらの対応が難しくなります。組織によってはドメインの取得が面倒で、つい手持ちのドメインを再利用したくなるかもしれません。その手間を惜しまず、専用のドメインを取得することを推奨します。

IP Address での運用を避ける

GitLab は https://192.168.19.2 のように IP Address で運用することもできます。GitLab に限らず、IP Address での運用は避けるべきです。

GitLab の利用者が増えるにつれ、サーバーの増強や構成変更などが発生します。また、運用の管轄が変わることもあります。これらのおりに IP Address が変更されることが多いです。

Relative URL を避けるのと同様に、URL の変更は利用者に負担を強います。そのための対策にコストがかかりますので、ドメインを取得することを推奨します。

なお、GitLab Pages は専用のドメインが必須です。

HTTPS 化する

http://gitlab.example.com で運用を始め、あとから https://gitlab.example.com と HTTPS 化するのはそれほど難しくありませんし、利用者へのインパクトもそれほど大きくはありません。

後からで HTTPS 化することもできますが、仮に暗号化前に漏洩していたとしてその事実がなくなるわけでもありません。漏洩したことを検出するのはとても難しいので、早いうちに HTTPS 化してください。GitLab Omnibus Package は Let’s Encrypt を利用した証明書の自動発行に対応しています。

自己署名証明書の利用は避けてください。自己署名証明書でもうまくやれば安全性を担保できますが、正規の TLS 証明書を取得するより遥かにコストがかかります。

もちろん、セキュリティインシデントは HTTPS にしたからすべてなくなるというものでもありません。HTTPS はあくまで通信経路上の漏洩・改ざん・なりすましを防ぐためのものです。ほかの安全対策もおろそかにしてないでください。

なお、非 HTTPS や自己署名証明書では、GitLab の Container Registry を利用するのが面倒になります。面倒くささは活用されないことにつながるので、安全性の面以外でも GitLab の HTTPS 化は必須だと考えた方が無難です。

Omnibus Package をなるべくそのまま利用する

一台のサーバーに GitLab Omnibus Package をインストールし、あまり設定を変更せずに、そのまま利用してください。

例えばリバースプロキシを導入すると、うまく動作しなかったときに GitLab の問題かリバースプロキシの問題かどうかがわかりにくくなります。GitLab バグは GitLab 開発リポジトリのイシューを探せば同じような現象が見つかり、一時回避策が提示されていることもあります。しかし、リバースプロキシ側に問題がある場合、それらが参考にならないことがほとんどです。その分、解消に時間がかかります。回避策を手当たりしだいに試して、状況が悪化することもあります。

リバースプロキシだけでなく、プロキシ全般トラブルの原因になることが多いです。弊社サポートへの問い合わせでも、プロキシの設定に問題があり GitLab は問題がなかったケースや、プロキシの存在をスタッフが認識するのが遅れ、解決まで時間がかかったケースがあります。

なるべく Omnibus Package のまま、必要最小限の設定で運用することを推奨します。Docker 版も避け、Omnibus Package を利用するのがもっともトラブルの確率が低いです。

運用工数を確保する

とりあえずで構築した GitLab ではバージョンアップ・バックアップ・監視などの運用がおざなりになりがちです。後でやるリストに入りっぱなしではないでしょうか? 安全性に問題が出やすくなり、障害が発生したときに対処に苦労します。

運用は片手間でできることではありませんので、必要な工数を必ず確保します。

GitLab.com を検討する

サーバーの運用コストはバカになりません。サーバー代や電気代よりも人件費のほうが問題になります。さらに、最近ではイントラネットへの侵入も増えていたり、攻撃が高度化していたりで、対策のための運用コストは今後も上昇し続けると思われます。

必要な運用工数が確保できない場合は、GitLab.com を検討します。

利用者が増えれば増えるほどオンプレミスから GitLab.com への移行コストが増大するので、早めの判断が必要です。

運用レベルを明示する

絶対にセキュリティ事故も起こさず、障害も起こさない GitLab を構築・運用することはできません。要件やコストを考えながら運用レベルを妥協する必要があります。

ところが、利用者はこの妥協を知りません。想定していないクリティカルなプロジェクトで使われるかもしれません。事故や障害の際にそのプロジェクトチームと揉めるかもしれません。責任まで取らされることは稀だと思いますが、揉め事でお互いの余計な時間を取られるのを避けるために、運用レベルを明示し、想定外のプロジェクトで利用されないようにします。

例えば、障害で最悪直近一日分のデータを失うことなどを利用者に明示します。これらを許容できないクリティカルなプロジェクトには利用を避けてもらいます。