大規模なオープンソース DevOps：GitLab を自前で運用する

laptop screen showing code in a busy room

ソースコードは、ほぼすべてのテクノロジー企業が重要資産だと同意する唯一のものであり、同時に、その大半が自社の所有でないインフラの上に、自分で選んだのではない司法管轄のもとで、注意深く読んだわけではない契約に基づいて置いているものでもあります。たいていの場合その状態で問題はありません。それでも、もう一方の道にいくらかかるのかを知っておく価値はあります。GitLab は十年以上にわたり、開発ライフサイクル全体を自前でホストすることを本当に現実的な選択肢にしてきたからです。

同時にこれは、無料階層が多くの人の想像より寛容で、運用の負担が想像より重い製品でもあります。どちらもコミットする前に理解しておきたいところなので、この記事では自前運用の GitLab が実際のところ何であるか、無料階層が本当に与えてくれるもの、そして痛みの大半を生む三つの運用上の問題を扱います。

GitLab とは何か

拡張機能を後付けした Git ホスティングではありません。Rails のアプリケーション、PostgreSQL、Redis、リポジトリ格納のための Gitaly、バックグラウンドジョブのための Sidekiq、そしてコンテナレジストリが、ひとつのシステムとしてまとめられ、バージョン管理、コードレビュー、課題管理、CI/CD、パッケージとコンテナのレジストリ、セキュリティスキャン、デプロイまでを覆います。

この幅こそが論点のすべてです。GitHub に Actions と Dependabot とパッケージレジストリとプロジェクト管理を足せば同等の機能群にはなりますが、それは部品を組み合わせたものです。GitLab はひとつのアプリケーションであり、権限モデルもデータベースもひとつです。それは求めているものそのものか、必要以上に多いかのどちらかで、どちらになるかはライフサイクルのどれだけを実際に一箇所で回すつもりかによります。

アーキテクチャ上の要点は、Matomo で分析を自前運用することや、Mautic でマーケティングオートメーションを自前運用すること、Mattermost でチームチャットを自前運用することと同じです。置いた場所で動く、ということです。自分のリポジトリ、自分の CI ログ、自分の成果物、自分のデータベース。

ライセンスの実情、率直に言うと

ここは本当に紛らわしく、正確さに値します。混乱が予想とは逆方向に進むからです。

ソースの配布は二種類あります。Community Edition は MIT ライセンスです。Enterprise Edition は独自のより制限的なライセンスを持ち、リポジトリの ee/ ディレクトリを対象とします。ここまではよくあるオープンコアの構図に聞こえます。

意外なのはここからです。ほぼ全員がインストールする Linux パッケージは Enterprise Edition のビルドで、ライセンスキーを入れない状態では Free 階層として動作し、Community Edition のように振る舞います。つまり、意図して CE パッケージを選んだのでない限り、MIT ライセンスの配布物を動かしてはいません。実務上これが問題になることはまれですが、自前運用の理由がデータの管理ではなく厳格なオープンソース方針であるなら、大いに問題になります。そしてほとんど誰も確認しません。

商用階層は Free、年額請求でユーザーあたり月 29 ドルの Premium、そして価格が個別見積もりの Ultimate です。Premium は高度な CI/CD、より良いプロジェクト管理、優先サポートを加えます。Ultimate はセキュリティとコンプライアンスの一式を加えます。アプリケーションセキュリティテスト、サプライチェーンセキュリティ、依存関係スキャンです。有償の両階層には現在、AI 機能向けの GitLab Credits が付き、Premium はユーザーあたり月 12 ドル、Ultimate は 24 ドルです。

そして、多くのチームの計算を変える事実であり、Mattermost の状況のちょうど裏返しがこれです。自前運用の Free 階層にユーザー数の上限はありません。 よく耳にする五ユーザーの上限は、GitLab.com の非公開グループにのみ適用されます。自前でホストする Free は、無制限のユーザー、バージョン管理、CI/CD、レジストリを与え、ストレージとランナーは自分で用意します。エンジニア百人の組織がまるごとその上で動けます。

手放すのは、セキュリティスキャン、コンプライアンス報告、高度な承認ルール、そしてサポートです。サイバーレジリエンス法の対象で、依存関係スキャンと SBOM 生成を別々のツールから組み上げるのではなくパイプラインに組み込みたいのなら、それは Ultimate の話になります。それ以外の多くのチームにとって、Free は試用ではありません。持続可能な恒久的解です。

構築の仕方

小規模な構成

GitLab は見た目より重い製品です。単一ノードの文書化された基準は 8 vCPU と 16GB のメモリで、たいていのベンダー最小要件と違い、この数字は楽観的ではなく正直です。8GB に押し込むこともできますが、それは体感されますし、スワップは切っておくべきです。このアプリケーションをスワップさせるのは、メモリがないことより悪い結果を招きます。

サポートされるデータベースは PostgreSQL だけです。どのバージョンかは GitLab のバージョン次第で、17.x は PostgreSQL 14.14 から 16.x、18.x は 16.5 から 17.x、19.x は 17.x を求めます。Redis は 7.2 が推奨で最低が 7.0、Valkey 7.2 も代替として使えます。単体インスタンスのみで、Redis のクラスタ構成とサーバーレス版はサポートされません。

インストールは Linux パッケージで行ってください。Helm チャート、Operator、Docker イメージ、ソースからの導入もありますが、Linux パッケージが最も成熟した選択肢で、GitLab.com 自身が動いているのもこれです。PostgreSQL、Redis、Sidekiq を同梱するので、一台のマシンと一つの設定ファイルで動くインスタンスが得られます。

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

gitlab-ctl reconfigure を一度実行すればインスタンスができます。external_url は最初に正しく設定してください。この値はクローン URL、Webhook、レジストリのアドレスに焼き付きます。

本番構成

GitLab は 1,000 から 50,000 ユーザーまでのリファレンスアーキテクチャを公開していて、どれも実装しないとしても読む価値があります。どのコンポーネントが最初にボトルネックになるかが見えるからです。

最も費用を節約する助言は GitLab 自身のもので、複雑さに反対する内容です。3,000 ユーザー未満なら、高可用性よりも堅実なバックアップ戦略を勧めています。ドキュメントはこの点について異例なほど率直で、バックアップ方式は確かに復旧時間が遅くなるものの、はるかに小さい構成と低い維持費を意味すると述べています。3,000 ユーザーを超えるか、停止が本当に会社を止める場合には、高可用性が推奨になります。

これは真に受けてよい助言です。きちんとバックアップされ復旧を試したことのある単一ノードのほうが、半分しか理解していない高可用性クラスタより実際には信頼でき、しかもかなり安くつきます。

成果物、アップロード、LFS オブジェクト、レジストリのイメージは、最初からオブジェクトストレージに置いてください。理由は他と同じで、ノードを状態を持たない状態に保ち、バックアップを扱える大きさに保ち、移行を可能に保つためです。

うまくいかない三つのこと

ここまではすべてドキュメントに書かれています。以下が障害を生む部分です。

バックアップには、それを復号するものが入っていない

これがこの記事で最も重要な段落です。

gitlab-backup create はかなりの範囲を取り込みます。データベース、リポジトリ、LFS オブジェクト、CI の成果物とジョブログ、レジストリのイメージ、Wiki、アップロード、Pages のコンテンツ、Terraform の状態、スニペット。取り込まないのは設定ディレクトリで、とりわけ /etc/gitlab/gitlab-secrets.json です。

このファイルはデータベースの暗号鍵を保持します。ドキュメントは帰結について率直です。これを失えば、GitLab アプリケーションはデータベース内のいかなる暗号化された値も復号できなくなります。CI/CD 変数、トークン、二要素認証の秘密情報、連携の資格情報がそれにあたります。復元はできるのに自分の秘密情報を読めないインスタンスができあがる、ということです。

同じく対象外なのが /etc/gitlab/gitlab.rb、TLS の鍵と証明書、SSH ホスト鍵、そしてオブジェクトストレージを設定している場合のその中身です。最後の項目は、アーキテクチャ上正しいことをしたうえで、バックアップがそれを含んでいると思い込んだ人をこそ捕まえます。

ですから /etc/gitlab は別途バックアップし、アーカイブと同じ場所ではないところに保管してください。それはアーカイブの鍵だからです。そのうえで全体を使い捨てのマシンに復元し、ログインして CI 変数を読めることを確認します。試していないバックアップはバックアップではありませんし、GitLab の場合、試していない復元はたいてい壊れています。

一度の跳躍ではアップグレードできない

GitLab には必須のアップグレード経由点があり、これは助言ではありません。飛ばせません。17.5 以降、経由点は予測可能で x.2、x.5、x.8、x.11 に置かれます。したがって 18.0 から 19.2 へ上げるには、途中で 18.2、18.5、18.8、18.11、19.0 を通ることになります。

各経由点にはバックグラウンドマイグレーションが伴い、次に進む前に完全に終わっていなければなりません。マイグレーションが走っている最中に次のアップグレードを始めるのが、サポートでなければ解けない状態にインスタンスが陥る典型的な経路です。大きなインスタンスでは、これらのマイグレーションに数時間かかることもあります。

実務上の帰結は二つ。定期的に上げること。一年ぶんの先送りは、連続アップグレードの週末になります。そして目標のマイナーバージョンでは最初のパッチではなく最新のパッチリリースを取ること。ドキュメントが明示的にそう書いています。GitLab はアップグレード経路を計算するツールを提供しており、自分で考えるよりそれを使う価値があります。

本当の費用はランナーにある

GitLab サーバーはあなたの CI を実行しません。GitLab Runner は別のコンポーネントで、自分で導入し、設定し、費用を負担します。動かすインフラも自分で用意します。自前運用の Free には計算時間が一切含まれません。与えるべき計算資源が同梱されていないからです。マシンは自分で持ち込みます。

たいていこれは良い取引です。量が本格化すれば専用ランナーはホスト型 CI より分あたり安く、ビルドごとに必要なハードウェアを与えられます。ただし、これは本物のインフラ作業です。エグゼキューターを shell にするか Docker にするか Kubernetes にするか、深夜三時にランナーが空回りしないようオートスケールをどうするか、そして四分のパイプラインと十四分のパイプラインを分けるキャッシュをどうするか、といった判断が必要になります。

ランナー群は独立した費目として予算化してください。自前運用の費用を GitLab のノードだけで見積もるチームは大きく過小評価し、その不足を保留中ジョブの行列として発見することになります。

GitHub からの移行

GitHub インポーターは優秀で、多くのベンダーの移行ツールよりかなり良く、リポジトリのデータ、ブランチ、LFS オブジェクト、イシューとプルリクエストをコメント、レビュー、議論の返信ごと、Wiki ページ、リリースと添付、ラベル、マイルストーン、ブランチ保護ルール、そしてロール対応づけ込みのコラボレーターを運んできます。

文書化された欠落は計画に織り込んでおくとよいでしょう。組織とグループは移りませんので、グループ構造は受け継ぐのではなく自分で設計することになり、たいていはそのほうが改善になります。GitHub Actions のワークフローは GitLab CI に変換されません。2017 年より前のプルリクエストのコメントは GitHub API の制約から別スレッドとして取り込まれ、コメントがおよそ三万件を超えるリポジトリでは代替のコメント取り込み方式を有効にする必要があります。

GitHub がイシューにもプルリクエストにも # を使うのに対し GitLab は両者を区別するため、一部の相互参照は解決しません。失われるものはありませんが、古い議論のリンクが誤った対象を指すことはあります。

CI の書き直しこそが本体のプロジェクトだと考えて計画してください。実際そうです。それ以外は、走らせて確認できる取り込み作業にすぎません。

ヨーロッパの観点

ヨーロッパで事業を営む企業にとっては、費用の上にコンプライアンスの次元が重なります。ソースコード、ビルドパイプライン、成果物は、テクノロジー企業が抱えるもののなかでも特に機微なものであり、それらがどこにあるかは、自分から答える問いというより、次第に問われる問いになっています。

自前運用はそれらを自分が管理する境界の内側に置きます。これは GDPR の移転分析と NIS2 のサプライチェーンの問いを一度に単純化しますし、クラウド・AI 開発法が組み立てられている主権の論理とも同じものです。

より鋭い結びつきはサイバーレジリエンス法です。EU 市場にソフトウェアを出すなら、依存関係の目録、脆弱性への対応、そして調整された開示の手続きが必要になります。これらの義務は文書ではなくビルドパイプラインの中で満たされるものであり、パイプラインとレジストリとスキャンを自分が運用する一つのシステムに持っていると、四社から証跡をかき集めるよりずっと楽に証明できます。

やめておくべき場合

エンジニアが二十人未満で、規制上の圧力もなく、コードがどこにあるかについて強い考えもないなら、SaaS を使ってください。運用の手間は購読料より高くつきます。

組織が GitHub のエコシステムに深く根を張っているなら、何を失うかを正直に数えてください。Actions、マーケットプレイス、そして採用するどの候補者にとっても馴染みがあるという事実は本物の資産で、答えが自動的に GitLab の勝ちになるわけではありません。

そして、誰もそのインスタンスを引き受けないのであれば、始めないでください。GitLab は、パッチを当て、ランナー群を見守り、復元を試す人に報います。その人がいなければ、最も価値のある資産を抱えたまま更新されない箱に成り下がります。それは離れようとしていた SaaS より悪い状態です。

お手伝いできること

私たちはヨーロッパで事業を行う企業向けに、自前運用の開発基盤を構築し運用しています。必須経由点をまたぐアップグレードの段取り、きちんとオートスケールするランナー群、オブジェクトストレージへの移行、そして実際に復元したことのあるバックアップ設計といった、地味な部分も含めてです。

正直にサイズを見積もった GitLab インスタンス、CI の書き直しを経験した人間が計画する GitHub からの移行、あるいは現在のバックアップが本物の障害に耐えるかどうかの点検が必要でしたら、office@c9group.dev までご連絡ください。基盤まわりの仕事については AWS コスト最適化のページもご覧ください。

自前運用のスタックを一式そろえるのであれば、同じ考え方が分析、マーケティングオートメーション、チームコミュニケーションにも当てはまります。

公開日：2026年8月8日 カテゴリー：DevOps、オープンソース、プライバシー