GitLab インストール方法をわかりやすく解説

By /

GitLab インストール方法をわかりやすく徹底解説！あなたのチーム開発環境を構築しよう

はじめに：なぜ今、GitLabなのか？

ソフトウェア開発において、バージョン管理システムは不可欠です。その中でも、Gitはその柔軟性と分散性から、現代の開発の中心的なツールとなっています。そして、そのGitを中核に据え、ソースコード管理だけでなく、CI/CD（継続的インテグレーション/継続的デリバリー）、コードレビュー、イシュー管理、Wiki、コンテナレジストリなど、開発ライフサイクル全体をカバーするDevOpsプラットフォームとして、GitLabは世界中の開発チームに利用されています。

GitHubやBitbucketといった他の選択肢もありますが、GitLabの大きな特徴は、これらの豊富な機能を「セルフホスト」できる（自分たちのサーバーにインストールして運用できる）点にあります。これにより、機密性の高いコードを社内ネットワーク内に閉じて管理したり、利用ユーザー数に制限なく自由にスケールさせたりすることが可能になります。もちろん、SaaS版としてGitLab.comを利用することもできますが、ここではセルフホスト版（オンプレミス版とも呼ばれます）のインストールに焦点を当てます。

この記事では、GitLabのセルフホスト版をあなたのサーバーにインストールし、基本的な設定を行う方法を、初心者の方にも理解できるよう、丁寧に解説します。特に、最も手軽で推奨される「Omnibus Package」を使ったインストール方法を中心に、準備段階から初期設定、そして安定運用に向けたポイントまで、ステップバイステップで進めていきます。

「サーバーの操作はあまり得意ではない」「GitLabのインストールは難しそう」と感じている方も、この記事を読めばきっと一人でインストールを完了させ、あなたのチーム開発環境を構築できるはずです。さあ、GitLabの世界へ飛び込み込みましょう！

GitLabのインストール方法の選択肢

GitLabのセルフホスト版をインストールするには、いくつかの方法があります。それぞれに特徴があり、あなたの環境や目的によって最適な方法が変わってきます。

  1. Omnibus Package (推奨):

    • GitLab本体、Nginx (Webサーバー)、PostgreSQL (データベース)、Redis (キャッシュ/キュー)、Sidekiq (バックグラウンドジョブ処理)、Prometheus (監視) など、GitLabの実行に必要なすべてのコンポーネントが一つにまとめられたパッケージです。
    • 利点: インストールが非常に簡単で、セットアップや管理の大部分が自動化されています。必要な依存関係の管理や各コンポーネントの連携設定などが不要なため、最も手軽にGitLabサーバーを立ち上げられます。公式も最も推奨している方法です。
    • 欠点: 各コンポーネントの詳細なカスタマイズには限界があります。パッケージに含まれるバージョンで固定されるため、特定のバージョンを使いたいなどの要件には向きません。また、すべてのコンポーネントが同じサーバー上で動作するため、リソース消費が大きくなる傾向があります。

  2. Source Installation:

    • GitLabのソースコードを直接ダウンロードし、必要なミドルウェア（Ruby on Rails、Go、Vue.jsなど）やデータベース、Webサーバーなどを個別に準備してコンパイル・設定する方法です。
    • 利点: 各コンポーネントを自由に選択・設定できます。既存のデータベースサーバーやWebサーバーと連携させるなど、柔軟な構成が可能です。
    • 欠点: インストール手順が非常に複雑で、各コンポーネントに関する深い知識が必要です。依存関係の管理、設定、バージョンアップなど、運用管理の負担が大きくなります。これはGitLabの開発者や、非常に特殊な環境要件がある場合にのみ推奨される方法です。

  3. Docker Image:

    • DockerコンテナとしてGitLabを実行する方法です。GitLab公式が提供するDockerイメージを利用します。
    • 利点: 既存のDocker環境に簡単にデプロイできます。ホストOSを汚さず、GitLabの環境を分離できます。スケーリングや管理がDockerの仕組みに乗って行えます。
    • 欠点: Dockerやコンテナ技術に関する知識が必要です。永続的なデータを保存するためのボリューム管理などの設定が必要です。

  4. Kubernetes (GitLab Helm Chart):

    • Kubernetesクラスター上にGitLabをデプロイする方法です。Helmというパッケージマネージャーを使って公式チャートを利用します。
    • 利点: 高可用性、スケーラビリティ、耐障害性に優れたGitLab環境を構築できます。Kubernetesの運用ノウハウを活かせます。
    • 欠点: Kubernetesクラスターの構築・運用に関する高度な知識が必要です。小規模な利用にはオーバースペックとなることが多いです。

この記事では、前述の通り、最も一般的で推奨されるOmnibus Packageによるインストール方法に焦点を当てて解説します。この方法で、まずは手軽にGitLabサーバーを立ち上げてみましょう。他の方法に興味がある方は、公式ドキュメントを参照してください。

インストール前の重要な準備

GitLabのインストールをスムーズに進めるためには、事前の準備が非常に重要です。サーバーの選定からネットワーク設定、必要な情報の決定まで、しっかりと確認しておきましょう。

1. システム要件の確認

GitLabは多くの機能を内包しているため、ある程度のサーバーリソースを必要とします。利用するユーザー数や、CI/CDをどれだけ頻繁に実行するかによって必要なリソースは変動しますが、最低限の要件と推奨要件を知っておくことが重要です。

  • オペレーティングシステム (OS): GitLab Omnibus Packageは、主要なLinuxディストリビューションをサポートしています。一般的に以下のOSのLTS版（長期サポート版）が推奨されます。

    • Ubuntu (特に20.04 LTS, 22.04 LTS)
    • CentOS / RHEL (7, 8, 9)
    • Debian (10, 11)
    • Oracle Linux (7, 8, 9)
    • Amazon Linux 2
    • openSUSE Leap (15.x)
    • インストールするGitLabのバージョンによって対応OSバージョンが異なる場合があるので、必ず公式ドキュメントで確認してください。古いOSバージョンや、デスクトップ版OSはサポート対象外となることが多いです。

  • CPU:

    • 最低: 2コア
    • 推奨: 4コア以上。利用ユーザー数が増えたり、CI/CDジョブが並列で実行されたりすると、多くのCPUリソースが必要になります。小規模チームでも4コアは欲しいところです。大規模な場合は、ユーザー数やCI/CDの負荷に応じてコア数を増やしていく必要があります。

  • メモリ (RAM):

    • 最低: 4 GB
    • 推奨: 8 GB以上。GitLabはメモリを多く消費するアプリケーションです。特にPostgreSQL, Redis, Sidekiq, Puma/Unicornといったコンポーネントがメモリを使用します。メモリが不足すると、パフォーマンスが著しく低下したり、サービスが不安定になったりします。小規模チームでも8GB以上を強く推奨します。CI/CDを多用する場合やユーザー数が多い場合は、16GB、32GBと増強を検討してください。

  • ディスク容量:

    • 最低: 50 GB
    • 推奨: 100 GB以上。Gitリポジトリのデータ、データベースのデータ、CI/CDのアーティファクト、ログなどがディスク容量を消費します。特にリポジトリのサイズが大きかったり、バイナリファイルを含むリポジトリが多い場合、CI/CDで生成されるアーティファクトが多い場合は、予想以上に容量を消費します。最初は100GB程度を確保し、必要に応じて拡張できるようにしておくのが良いでしょう。
    • 推奨: 高速なストレージ（SSD）を利用することを強く推奨します。特にデータベースやGitリポジトリのI/O性能は、GitLab全体のパフォーマンスに大きく影響します。

  • その他:

    • IPv4またはIPv6ネットワーク接続
    • root権限、またはsudoを使えるユーザーアカウント

2. サーバーの準備と基本的な設定

上記の要件を満たすサーバーを用意します。物理サーバー、仮想マシン (VMware, VirtualBoxなど)、クラウド上のインスタンス (AWS EC2, GCP Compute Engine, Azure VMなど) のいずれでも構いません。

サーバーを準備したら、以下の基本的な設定を行っておきます。

  • OSのインストールと初期設定: 選択したOSをインストールし、ネットワーク設定、タイムゾーン設定、SSHサーバーの有効化などを行います。
  • ファイアウォールの設定: 後述のネットワーク設定で必要なポートを開放します。
  • SSHでの接続: リモートからサーバーにアクセスするためのSSHクライアントを用意し、接続できることを確認します。以降の作業はSSHで行うのが一般的です。
  • OSのアップデート: インストールされているパッケージを最新の状態にしておきます。
    • Ubuntu/Debian: sudo apt update && sudo apt upgrade -y
    • CentOS/RHEL/Oracle Linux: sudo yum update -y または sudo dnf update -y

3. ネットワーク設定

GitLabにアクセスするためには、特定のポートがサーバーのファイアウォールや、ネットワーク全体のファイアウォール（クラウドプロバイダーのセキュリティグループなど）で許可されている必要があります。

  • HTTP/HTTPS (ポート 80/443): WebブラウザからGitLabのUIにアクセスするために必要です。通常、インターネットからアクセスする場合は443 (HTTPS) を使用します。内部ネットワークからのアクセスのみの場合は、80 (HTTP) でも構いませんが、セキュリティのためHTTPSを強く推奨します。
  • SSH (ポート 22): GitクライアントがSSHプロトコルでリポジトリを操作するために必要です。また、SSHでサーバー管理を行う際にも使用します。

これらのポートについて、サーバー自体のファイアウォール（例: ufw, firewalld）で許可設定を行います。

例：ufw (Ubuntu)
bash
sudo ufw allow ssh # SSHポートを許可
sudo ufw allow http # HTTPポートを許可 (必要であれば)
sudo ufw allow https # HTTPSポートを許可
sudo ufw enable # ファイアウォールを有効化
sudo ufw status # 設定を確認

例：firewalld (CentOS/RHEL)
bash
sudo firewall-cmd --zone=public --add-service=ssh --permanent # SSHポートを許可
sudo firewall-cmd --zone=public --add-service=http --permanent # HTTPポートを許可 (必要であれば)
sudo firewall-cmd --zone=public --add-service=https --permanent # HTTPSポートを許可
sudo firewall-cmd --reload # 設定を反映
sudo firewall-cmd --zone=public --list-services # 設定を確認

クラウド環境の場合は、プロバイダーの管理コンソールでセキュリティグループやネットワークACLの設定を確認・変更してください。

4. ドメイン名またはIPアドレスの決定

GitLabにアクセスするためのURLを決定します。

  • ドメイン名 (FQDN): gitlab.yourcompany.com のような完全修飾ドメイン名を使用することを強く推奨します。これにより、SSL証明書を使ったHTTPS接続が容易になり、セキュリティが向上します。また、GitLabの多くの機能（CI/CD、Container Registryなど）が正しく動作するためにFQDNが必要となる場合があります。
    • 使用するドメイン名を決定し、そのドメイン名がサーバーのグローバルIPアドレス（または内部IPアドレス）を指すようにDNSレコード（Aレコードなど）を設定してください。
  • IPアドレス: ドメイン名がない場合や、一時的な利用、内部ネットワークからのアクセスのみの場合は、サーバーのIPアドレスを直接使うことも可能です。ただし、SSL/TLS証明書の取得や、一部機能の制約が発生する可能性がある点に注意が必要です。

この記事では、FQDNを使用することを前提に解説を進めます。

5. SSL証明書の準備 (推奨)

HTTPS接続を有効にするためにSSL証明書が必要です。
* 信頼できるCAが発行した証明書: Let’s Encryptのような無料の証明書や、商用の証明書があります。GitLab Omnibus Packageは、Let’s Encrypt証明書の自動取得・更新機能を内蔵しています。FQDNを用意していれば、この機能を利用するのが最も手軽です。
* 自己署名証明書: テスト環境など、信頼性が問われない環境でのみ使用します。自己署名証明書はブラウザからアクセスする際に警告が表示されます。

本番運用では、Let’s Encryptなど信頼できるCAが発行した証明書を使用することを強く推奨します。FQDNが準備できていれば、GitLab Omnibusの機能で簡単に設定できます。

6. メール送信設定の検討

GitLabは、ユーザー登録時の確認メール、パスワードリセット、通知、CI/CDの実行結果通知など、様々な場面でメールを送信します。SMTPサーバーの設定は必須ではありませんが、設定しないとGitLabの利便性が大きく損なわれます。

  • Postfixなどのローカルのメールサーバーを立てる
  • SendGrid, Mailgunのようなメール送信サービスを利用する
  • GmailやOutlook365などの既存のメールアカウントをSMTPリレーとして利用する

などの方法があります。いずれかの方法で、SMTPサーバーの接続情報を準備しておくと良いでしょう。ローカルのPostfixサーバーをインストール時に自動で設定することも多いです。

7. バックアップ戦略の検討 (本番運用の場合)

本番環境でGitLabを運用する場合、データのバックアップは極めて重要です。インストールが完了したら、必ずバックアップ設定を行いましょう。Omnibus Packageにはバックアップツールが付属しています。

GitLab Omnibus Packageによるインストール手順

それでは、Omnibus Packageを使ってGitLabをインストールする具体的な手順に入ります。ここでは、一般的なLinuxディストリビューションであるUbuntu 22.04 LTSを例に説明しますが、他の対応OSでも基本的な流れは同じです。OSによってパッケージマネージャーのコマンド（apt or yum/dnf）などが異なりますので、適宜読み替えてください。

事前に準備セクションで述べたシステム要件を満たすサーバーを用意し、SSHで接続できる状態にしておいてください。root権限、またはsudoコマンドを実行できるユーザーで作業を行います。

Step 1: 必須パッケージのインストール

GitLab Omnibus Packageをインストールするために必要ないくつかのパッケージをインストールします。特に curl はGitLabのリポジトリを追加するために必要です。ca-certificates はSSL通信を行うために必要です。postfix はGitLabがメールを送信するためにインストールされます。

“`bash

Ubuntu/Debianの場合

sudo apt update
sudo apt install -y curl ca-certificates apt-transport-https postfix

CentOS/RHEL/Oracle Linuxの場合

sudo yum install -y curl policycoreutils-python-utils postfix

CentOS 8/RHEL 8以降 または Oracle Linux 8以降 の場合、policycoreutils-python-utils が dnf install policycoreutils-python-utils となることもあります。

CentOS 7/RHEL 7 では、以下のコマンドでファイアウォールを有効化し、SMTPポートを開放する必要がある場合があります

sudo systemctl enable firewalld && sudo systemctl start firewalld

sudo firewall-cmd –permanent –add-service=http

sudo firewall-cmd –permanent –add-service=https

sudo firewall-cmd –permanent –add-service=ssh

sudo firewall-cmd –permanent –add-service=smtp # 必要であれば

sudo firewall-cmd –reload

Amazon Linux 2の場合

sudo yum update -y
sudo yum install -y curl policycoreutils-python postfix

SELinuxが有効な場合、postfixが外部ネットワークに接続できるように設定が必要なことがあります。

sudo semanage boolean -m allow_postfix_smpt_relay –on

“`

postfix のインストール中に設定画面が表示されることがあります。
* “General type of mail configuration?”: “Internet Site” を選択します。
* “System mail name:”: サーバーのホスト名またはFQDNを入力します。これは、GitLabが送信するメールのFromアドレスに使われるドメイン名になります（例: gitlab.yourcompany.com）。

postfix はGitLabがメールを送信するためのMTA (Mail Transfer Agent) として機能します。後でGitLabの設定ファイルで外部SMTPサーバーを指定することも可能です。

Step 2: GitLabパッケージリポジトリの追加

GitLabの最新版パッケージを取得するために、公式のリポジトリをシステムのパッケージソースに追加します。

GitLab Inc.が提供するスクリプトを利用するのが最も簡単です。このスクリプトは、OSの種類を自動的に判断し、適切なリポジトリ設定を行います。

“`bash
curl https://packages.gitlab.com/install/certificates/gitlab.gpg | sudo apt-key add –

または CentOS/RHEL系の場合

curl https://packages.gitlab.com/install/certificates/gitlab.gpg | sudo rpm –import –

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

もしEnterprise Edition (EE) ではなく Community Edition (CE) をインストールしたい場合は、URLの gitlab-ee を gitlab-ce に変更してください。

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

``
**補足**:
*gitlab-eeはGitLab Enterprise Editionのリポジトリです。EEにはCEの全機能に加え、より大規模なチームやエンタープライズ向けの高度な機能（例: グループ/プロジェクト間のCross-project dependencies, 高度なレポーティング, サポート体制など）が含まれます。商用ライセンスが必要ですが、インストール後30日間はトライアルとして利用できます。
*gitlab-ce` はGitLab Community Editionのリポジトリです。こちらは完全に無料で利用できますが、EEに比べて機能は限定されます。
* 通常、個人や小規模チームでの利用であればCEで十分なことが多いです。EEの高度な機能が必要か、または試してみたい場合はEEを選択してください。インストール後の設定ファイルでエディションを切り替えることはできません（再インストールが必要）。

スクリプトが実行されると、GitLabパッケージのリポジトリ情報が /etc/apt/sources.list.d/ ディレクトリ以下（Ubuntu/Debianの場合）または /etc/yum.repos.d/ ディレクトリ以下（CentOS/RHELの場合）に追加されます。

Step 3: GitLabパッケージのインストール

リポジトリを追加したら、パッケージマネージャーを使ってGitLab本体のパッケージをインストールします。

“`bash

Ubuntu/Debianの場合

sudo apt update
sudo apt install gitlab-ee # または gitlab-ce

CentOS/RHEL/Oracle Linuxの場合

sudo yum install gitlab-ee # または gitlab-ce

または dnf install gitlab-ee/ce

Amazon Linux 2の場合

sudo yum install gitlab-ee # または gitlab-ce
“`

このコマンドを実行すると、GitLab本体と、依存する多くのコンポーネント（Nginx, PostgreSQL, Redisなど）が自動的にダウンロード・インストールされます。これにはしばらく時間がかかります。

Step 4: 初回設定 (Reconfigure)

パッケージのインストールが完了したら、GitLabの初回設定を行います。Omnibus Packageでは、gitlab-ctl reconfigure コマンドを実行することで、設定ファイルの読み込み、各コンポーネントの設定適用、データベースの初期化、サービスの起動などが自動的に行われます。

このコマンドを実行する前に、一つ重要な設定を行うことを推奨します。それは、GitLabにアクセスするためのURL（FQDNまたはIPアドレス）を指定する設定です。この設定は /etc/gitlab/gitlab.rb というファイルで行います。

まず、エディタで /etc/gitlab/gitlab.rb ファイルを開きます（通常はroot権限が必要です）。

“`bash
sudo nano /etc/gitlab/gitlab.rb

または

sudo vi /etc/gitlab/gitlab.rb
“`

ファイルの中に # external_url 'GENERATED_EXTERNAL_URL' という行があります。この行のコメントアウト（行頭の#）を外し、'GENERATED_EXTERNAL_URL' の部分を、あなたが準備したGitLabのアクセスURLに書き換えます。FQDNを使用する場合は、スキーム（http:// または https://）を含めて指定します。

例：FQDN gitlab.yourcompany.com を使う場合（HTTPS推奨）
ruby
external_url 'https://gitlab.yourcompany.com'

例：IPアドレス 192.168.1.100 を使う場合（HTTP）
ruby
external_url 'http://192.168.1.100'
HTTPSを使う場合、もしLet’s Encryptを自動設定したい場合は、external_url を https:// で始めるだけでOKです。gitlab-ctl reconfigure が初回実行時にLet’s Encrypt証明書を自動取得・設定しようとします。ただし、これにはポート80が開いており、DNS設定が正しく行われている必要があります。自己署名証明書や、別途取得した証明書を使う場合は、追加の設定が/etc/gitlab/gitlab.rbに必要になります（後述）。

external_url の設定以外にも、必要に応じてこのファイルで他の設定（例: SMTP設定、バックアップ設定など）を行うことができますが、初回インストール時は external_url だけ設定しておけば、まずは基本的なGitLabサーバーを立ち上げることができます。

設定ファイルを保存したら、以下のコマンドを実行してGitLabの設定を適用します。

bash
sudo gitlab-ctl reconfigure

このコマンドは、設定ファイルの検証、各コンポーネントの設定ファイルの生成、データベースのマイグレーション、サービスの再起動など、多くの処理を順次実行します。これには数分から数十分かかる場合があります。画面には実行されている処理の詳細が表示されます。途中でエラーが発生した場合は、表示されるメッセージを確認し、必要に応じて設定ファイルを修正するか、エラーの原因を取り除いて再度 sudo gitlab-ctl reconfigure を実行してください。

Step 5: 初回アクセスと管理者アカウントの設定

gitlab-ctl reconfigure がエラーなく完了したら、GitLabサーバーが起動しています。Webブラウザを開き、external_url で設定したURLにアクセスしてみてください。

初回アクセス時は、管理者 (root) アカウントのパスワード設定画面が表示されます。

  1. ブラウザで https://gitlab.yourcompany.com (または設定したURL) にアクセスします。
  2. “Reset password” または “Change your password” のようなタイトルの画面が表示されます。
  3. この画面は、初回ログイン用のrootユーザーのパスワードを設定するためのものです。安全なパスワードを設定してください。
  4. パスワードを入力し、確認用にもう一度入力したら、「Change your password」ボタンをクリックします。
  5. パスワードが設定されると、ログイン画面にリダイレクトされます。
  6. ユーザー名に root、パスワードに先ほど設定したパスワードを入力してログインします。

これで、GitLabサーバーのインストールと、最初の管理者アカウントのパスワード設定が完了しました！ダッシュボードが表示されれば成功です。

注意: 初回ログイン時のrootユーザーは非常に強力な権限を持っています。日常的な操作には、別途新しいユーザーを作成し、そのユーザーを使用することを推奨します。

GitLabの詳細設定 (/etc/gitlab/gitlab.rb)

gitlab-ctl reconfigure は /etc/gitlab/gitlab.rb という設定ファイルを読み込んで、GitLab及び付属する各コンポーネント（Nginx, PostgreSQL, Redisなど）の設定を行います。このファイルには、GitLabの挙動をカスタマイズするための非常に多くのオプションが含まれています。コメントアウトされた行が多くありますが、設定を変更したい項目のコメントアウトを外し、値を編集することでカスタマイズできます。

設定ファイルを変更した後は、必ず sudo gitlab-ctl reconfigure コマンドを実行して変更を反映させる必要があります。

よく変更される設定項目や重要な設定項目をいくつか紹介します。

  • external_url: (必須) GitLabにアクセスするためのURL。インストール手順で設定済みですが、もし変更する場合はここを編集します。スキーム (http/https) を含め、FQDNまたはIPアドレスを指定します。

  • gitlab_rails['smtp_enable'] 以下のSMTP設定: メール送信設定。

    • gitlab_rails['smtp_enable'] = true # メール送信を有効化
    • gitlab_rails['smtp_address'] = "smtp.example.com" # SMTPサーバーのアドレス
    • gitlab_rails['smtp_port'] = 587 # SMTPサーバーのポート番号
    • gitlab_rails['smtp_user_name'] = "smtp_user" # 認証ユーザー名
    • gitlab_rails['smtp_password'] = "smtp_password" # 認証パスワード
    • gitlab_rails['smtp_authentication'] = "login" # 認証方式 (plain, login, cram_md5)
    • gitlab_rails['smtp_enable_starttls_auto'] = true # STARTTLSを有効化
    • gitlab_rails['smtp_tls'] = false # TLSを有効化 (ポート465などの場合)
    • gitlab_rails['smtp_pool'] = false # プールを使用するかどうか
    • gitlab_rails['gitlab_email_from'] = '[email protected]' # 送信元メールアドレス
    • gitlab_rails['gitlab_email_display_name'] = 'GitLab' # 送信元表示名
      設定後、sudo gitlab-ctl reconfigure を実行します。メールが正しく送信されるかテストするには、GitLabの管理画面 (Admin Area) -> Settings -> Network -> “Send a test email” を利用できます。

  • SSL/TLS設定 (external_url が https の場合):

    • Let’s Encrypt自動設定: external_url を https://... とし、ポート80が開いていてDNS設定が正しい場合、初回 reconfigure 時に自動で証明書を取得しようとします。成功すれば追加設定は不要です。更新も自動で行われます。
    • 手動設定: 自分で取得した証明書を使う場合は、以下のような設定を行います。
      • nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.yourcompany.com.crt" # 証明書ファイルのパス
      • nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.yourcompany.com.key" # 秘密鍵ファイルのパス
        証明書ファイルと秘密鍵ファイルをサーバー上の指定したパスに配置し、適切なパーミッションを設定します。
        設定後、sudo gitlab-ctl reconfigure を実行します。

  • バックアップ設定:

    • gitlab_rails['backup_keep_time'] = 604800 # バックアップファイルを保持する期間 (秒単位、ここでは7日間)
    • GitLabのバックアップツールは gitlab-backup create コマンドで実行できます。これをcronなどで定期実行するように設定するのが一般的です。
    • 例: 毎日午前2時にバックアップを実行する (cron設定)
      bash
      sudo nano /etc/cron.d/gitlab-backup
      ファイルに以下の行を追加します。
      cron
      0 2 * * * root /opt/gitlab/bin/gitlab-backup create CRON=1
      設定後、cronサービスを再起動する必要があるかもしれません (sudo systemctl restart cron など)。

  • ユーザー登録制限:

    • gitlab_rails['gitlab_signup_enabled'] = false # 新規ユーザーのセルフ登録を無効化
      デフォルトでは誰でもサインアップできてしまうため、クローズドな環境で利用する場合は無効化することを強く推奨します。無効化した場合、ユーザー追加は管理者アカウントで行います。

  • Puma (または Unicorn) 設定: Webサーバーのワーカー数やスレッド数を調整できます。リソースに応じてパフォーマンスをチューニングする場合に触ります。

    • puma['worker_processes'] = 2 # ワーカープロセスの数 (CPUコア数+1などが目安)
    • puma['min_threads'] = 4 # 各ワーカープロセスの最小スレッド数
    • puma['max_threads'] = 4 # 各ワーカープロセスの最大スレッド数
      これらの設定は、サーバーのメモリ量やCPUコア数に応じて調整が必要です。

  • PostgreSQL設定: データベースに関する詳細設定。

    • postgresql['shared_buffers'] = "256MB" # 共有バッファサイズ (メモリの約1/4が目安)
    • postgresql['max_connections'] = 200 # 最大接続数
    • データベースを外部サーバーに構築する場合は、/etc/gitlab/gitlab.rbで外部データベースの接続情報を設定する必要があります。

  • Prometheusによる監視: GitLabはデフォルトでPrometheusによる内部監視機能が有効になっています。

    • prometheus['enable'] = true # 監視有効化
    • prometheus['listen_address'] = 'localhost:9090' # 監視エンドポイント
      これらの設定を確認し、必要に応じて調整することで、GitLabサーバーのリソース使用状況やパフォーマンスを詳細に監視できます。

/etc/gitlab/gitlab.rb ファイルには、これ以外にも非常に多くの設定項目があります。詳細については、公式ドキュメントの「Configuration (gitlab.rb)」を参照してください。

設定を変更する際は、元のファイルをバックアップしておくと安全です。
bash
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak_$(date +%Y%m%d)

設定変更後は必ず sudo gitlab-ctl reconfigure を忘れずに実行してください。

GitLabサービスの管理

GitLab Omnibus PackageでインストールされたGitLabサービスは、gitlab-ctl コマンドを使って管理できます。

  • サービスの起動: sudo gitlab-ctl start
  • サービスの停止: sudo gitlab-ctl stop
  • サービスの再起動: sudo gitlab-ctl restart
  • サービスのステータス確認: sudo gitlab-ctl status
  • 設定の再適用: sudo gitlab-ctl reconfigure
  • コンポーネントごとのログ表示: sudo gitlab-ctl tail <component> (例: sudo gitlab-ctl tail nginx, sudo gitlab-ctl tail puma, sudo gitlab-ctl tail sidekiq, sudo gitlab-ctl tail postgresql)
  • すべてのログを表示: sudo gitlab-ctl tail
  • データベースコンソールへの接続: sudo gitlab-rails dbconsole
  • GitLab Railsコンソールへの接続: sudo gitlab-rails console (トラブルシューティングや高度な設定に使用)

これらのコマンドは、GitLabサーバーの運用・管理において頻繁に使用します。

GitLabのバージョンアップ

GitLabは活発に開発されており、セキュリティアップデートや新機能が頻繁にリリースされます。安定性やセキュリティのためにも、定期的なバージョンアップを強く推奨します。

Omnibus Packageを使っている場合、バージョンアップは非常に簡単です。

バージョンアップ手順:

  1. バックアップの取得: バージョンアップ前に必ずフルバックアップを取得してください。万が一問題が発生した場合に、元の状態に戻せるようにするためです。
    bash
    sudo gitlab-backup create
    生成されたバックアップファイルが /var/opt/gitlab/backups/ ディレクトリ以下に作成されます。これを別の場所に安全に保管してください。

  2. GitLabサービスの停止: 念のため、主要なサービスを停止します。
    bash
    sudo gitlab-ctl stop puma
    sudo gitlab-ctl stop sidekiq
    # またはすべてのサービスを停止
    # sudo gitlab-ctl stop

  3. パッケージリストの更新: パッケージマネージャーのキャッシュを更新し、新しいバージョンの情報を取得します。
    “`bash
    # Ubuntu/Debianの場合
    sudo apt update

    CentOS/RHEL/Oracle Linuxの場合

    sudo yum update

    または dnf update

    “`

  4. GitLabパッケージのアップグレード: パッケージマネージャーを使ってGitLabパッケージをアップグレードします。
    “`bash
    # Ubuntu/Debianの場合
    sudo apt install gitlab-ee # または gitlab-ce

    CentOS/RHEL/Oracle Linuxの場合

    sudo yum update gitlab-ee # または gitlab-ce

    または dnf update gitlab-ee/ce

    ``
    このコマンドを実行すると、利用可能な最新バージョンのGitLabパッケージがダウンロード・インストールされます。インストール中に自動的に    gitlab-ctl reconfigure` が実行され、データベースのマイグレーションなど必要な処理が行われます。

  5. サービスの起動: アップグレードが完了したら、サービスを起動します。
    bash
    sudo gitlab-ctl start
    # またはすべてのサービスを起動
    # sudo gitlab-ctl start

  6. 動作確認: WebブラウザでGitLabにアクセスし、正常に動作しているか、特に変更された機能や重要な機能（リポジトリへのプッシュ、CI/CDなど）が問題なく利用できるか確認します。GitLabの管理画面でバージョンが更新されていることも確認できます。

メジャーバージョンアップ時の注意点:

GitLabは月に一度、新しいメジャーバージョンをリリースします。例えば、15.x から 16.x へのバージョンアップのような、メジャーバージョンの変更を伴うアップグレードでは、データベースのマイグレーションなどが大きく変わる場合があります。

重要な注意点: メジャーバージョンを複数スキップして一度にアップグレードすることは推奨されません。 例えば、GitLab 14.x から 16.x に直接アップグレードしようとすると、失敗したりデータが破損したりする可能性があります。

推奨されるバージョンアップパス: 最新バージョンまでアップグレードする場合、必ず間に存在するメジャーバージョンを順番に経由してアップグレードしてください。

例：14.x から 16.x へアップグレードする場合
14.x -> 15.0 -> 15.1 -> … -> 15.N -> 16.0 -> 16.1 -> … -> 最新版

ただし、GitLabはバージョンアップパスに関する特定のガイドラインを提供しています。一般的には、同じメジャーバージョン内のポイントリリース（例: 15.0 から 15.10）は直接アップグレードできますが、メジャーバージョン間のアップグレード（例: 15.x から 16.x）は、必ず 15.x から 16.0 または特定のマイナーバージョン (16.y) を経由する必要がある場合があります。

公式ドキュメントで推奨されるアップグレードパスを必ず確認してください。 特に、”Upgrading GitLab” のドキュメントは、アップグレード元のバージョンとアップグレード先のバージョンに基づいて、どのようなパスでアップグレードすべきか、そして各バージョンアップ時の注意点（特別なマイグレーションや非推奨になった設定など）が詳細に記載されています。

計画的なバージョンアップと、事前のバックアップ、そして公式ドキュメントの確認が、安全なGitLab運用には不可欠です。

トラブルシューティング

GitLabのインストールや運用中に問題が発生することはあります。ここでは、一般的な問題とその解決策、そして問題発生時の調査方法をいくつか紹介します。

一般的な問題と解決策:

  • Webインターフェースにアクセスできない:

    • external_url の設定が正しいか確認する。
    • Nginxサービスが起動しているか確認する (sudo gitlab-ctl status -> nginx)。
    • サーバーのファイアウォール (ufw/firewalld) や、ネットワークのファイアウォール (セキュリティグループなど) で、ポート 80 (HTTP) や 443 (HTTPS) が許可されているか確認する。
    • DNS設定が正しく、FQDNがサーバーのIPアドレスを指しているか確認する (ping your.gitlab.url, dig your.gitlab.url)。
    • Nginxのログを確認する (sudo gitlab-ctl tail nginx)。

  • gitlab-ctl reconfigure がエラーになる:

    • エラーメッセージの内容を詳しく読む。どのコンポーネントでエラーが発生しているか (postgresql, nginx, gitlab-rails など)。
    • 設定ファイル (/etc/gitlab/gitlab.rb) の記述ミス (typo, 構文エラーなど) がないか確認する。YAMLやRubyの基本的な文法に従っている必要がある。
    • システムリソース (メモリ、ディスク容量) が不足していないか確認する。
    • 依存関係のパッケージが正しくインストールされているか確認する。
    • ログ (sudo gitlab-ctl tail <component>) に詳細なエラー情報が出力されていることが多いので確認する。
    • ディスク容量が100%になっていないか確認 (df -h)。

  • メールが送信できない:

    • /etc/gitlab/gitlab.rb のSMTP設定が正しいか確認する (アドレス、ポート、認証情報、TLS/SSL設定)。
    • SMTPサーバーへのネットワーク接続が可能か確認する (telnet smtp.example.com 587 など)。
    • SMTPサーバー側で認証エラーになっていないか確認する。
    • GitLabのSMTP関連のログを確認する (sudo gitlab-ctl tail sidekiq または sudo gitlab-ctl tail gitlab-rails/smtp.log (もし存在するなら))。
    • サーバーのファイアウォールで、SMTPポート (587, 465, 25など) から外部への通信が許可されているか確認する。
    • Postfixが正しく動作しているか確認する (sudo systemctl status postfix)。

  • プッシュやクローンがSSHでできない:

    • SSHサービスが起動しているか (sudo gitlab-ctl status -> sshd または sudo systemctl status sshd)。
    • ポート 22 がファイアウォールで許可されているか。
    • クライアント側で指定しているリポジトリURLが正しいか。
    • ユーザーのSSH公開鍵がGitLabに正しく登録されているか。登録後、サーバー側での同期に時間がかかる場合がある (sudo gitlab-rake gitlab:shell:setup)。
    • SSHクライアント側の設定 (~/.ssh/config) がGitLabサーバーを正しく参照しているか。
    • サーバー側のSSHログを確認する (/var/log/auth.log または /var/log/secure)。

  • パフォーマンスが悪い:

    • サーバーのリソース使用率 (top, htop, free -m, iostat) を確認する。CPU, メモリ, ディスクI/Oがボトルネックになっていないか。
    • GitLabの管理画面 (Admin Area) -> Monitoring -> Health check で、各コンポーネントの状態を確認する。
    • gitlab-ctl tail で各コンポーネント (puma/unicorn, sidekiq, postgresql, redis) のログを確認し、エラーや警告が出ていないか確認する。
    • PostgreSQLの統計情報などを確認し、遅いクエリがないか調査する。
    • gitlab-ctl reconfigure で、リソースに応じたPuma/UnicornやPostgreSQLの設定（ワーカー数、メモリ割り当てなど）が適切か確認する。

問題調査の基本的な流れ:

  1. エラーメッセージの確認: コマンドの出力、Web画面のエラー表示などを注意深く確認する。
  2. ログの確認: sudo gitlab-ctl tail <component> または /var/log/gitlab/ ディレクトリ以下のログファイル (nginx/current, puma/current, sidekiq/current, postgresql/current など) を確認する。タイムスタンプを見て、問題が発生した時間帯のログに注目する。
  3. サービスのステータス確認: sudo gitlab-ctl status で、関連するサービスがRunningになっているか確認する。
  4. 設定ファイルの確認: /etc/gitlab/gitlab.rb に設定ミスがないか確認する。
  5. システムリソースの確認: CPU, メモリ, ディスク容量、ディスクI/Oに余裕があるか確認する。
  6. ネットワーク接続の確認: 関連するサーバーやサービスとの間で、必要なポートでの通信が可能か確認する (ping, telnet, curl)。
  7. 公式ドキュメントの参照: GitLabの公式ドキュメントは非常に充実しています。エラーメッセージや現象で検索すると、解決策が見つかることが多いです。特に、Troubleshootingセクションや特定のバージョンのRelease Notes/Upgrade guideに情報がある場合があります。
  8. コミュニティフォーラムやイシュー検索: 同じ問題に遭遇している人がいないか、GitLabのコミュニティフォーラムや公開されているイシュートラッカー (GitLab.comのgitlab-org/gitlabプロジェクトなど) で検索してみるのも有効です。

セキュリティに関する考慮事項

GitLabはあなたのチームの重要な資産であるソースコードを管理します。セキュリティは常に最優先事項です。インストール後、以下の点に注意してセキュリティを強化しましょう。

  • HTTPSの有効化: 信頼できるCAが発行したSSL証明書を使用し、HTTPS接続を必須にしてください。これにより、通信内容が暗号化され、中間者攻撃を防ぐことができます。Let’s Encryptの自動設定機能が最も手軽です。
  • ファイアウォールの適切な設定: GitLabの利用に必要なポート (HTTP/S: 80/443, SSH: 22) 以外は閉じ、不要なサービスは無効化してください。特に管理画面やデータベース、Redisなどの内部ポートは、外部からのアクセスを厳重に制限する必要があります。
  • GitLabのバージョンアップ: セキュリティパッチが適用されるため、GitLabを常に最新のバージョンに保つことが極めて重要です。計画的にバージョンアップを行いましょう。
  • ユーザー認証の強化:
    • ユーザー登録制限: 不特定多数からのサインアップを許可しない場合は、gitlab_rails['gitlab_signup_enabled'] = false を設定し、管理者が手動でユーザーを追加するか、招待制にしてください。
    • 強力なパスワードポリシーの設定: 管理画面からパスワードの最小長などのポリシーを設定できます。
    • 二要素認証 (2FA) の有効化: 管理画面からユーザーに対して2FAを強制できます。これにより、パスワードが漏洩しても不正アクセスを防ぐリスクが大幅に減ります。
    • LDAP/AD連携、SAML SSO: 組織で利用している認証基盤と連携することで、ユーザー管理を一元化し、認証を強化できます。これは/etc/gitlab/gitlab.rbで設定します。
  • SSHキーの管理: GitLabに登録されるSSH公開鍵を適切に管理します。不要になった鍵は削除するようにユーザーに促すか、定期的に棚卸しを行います。
  • サーバーOSのセキュリティ対策: GitLabサーバー自体のOSも定期的にアップデートし、セキュリティパッチを適用してください。不要なサービスは停止し、OSレベルのファイアウォールやSELinuxなどのセキュリティ機能を適切に設定します。
  • 監査ログの確認: GitLabは様々な操作に関する監査ログを記録しています。不審な活動がないか、定期的に監査ログを確認することをお勧めします。

運用と管理

インストールが完了し、基本的な設定が終わったら、継続的な運用と管理が必要です。

  • 定期的なバックアップ: 最も重要です。cronなどを利用して自動的に毎日バックアップを取得し、バックアップファイルをGitLabサーバーとは別の安全な場所に保管してください。リカバリ手順も事前に確認しておきましょう。
  • リソース監視: CPU使用率、メモリ使用率、ディスク使用量、ネットワークトラフィックなどを継続的に監視します。GitLab Omnibus Packageに付属するPrometheusやGrafanaを利用したり、Nagios, Zabbix, Prometheusなどの外部監視ツールと連携させたりして、問題が発生する前にリソース不足を検知できるようにします。
  • ログ管理: GitLabのログは /var/log/gitlab/ 以下に蓄積されます。ディスク容量を圧迫しないよう、ログローテーションの設定を確認したり、syslogサーバーなどに集約したりすることを検討します。問題発生時の原因調査のためにもログは重要です。
  • GitLab Runnerの管理: CI/CDを利用する場合、ジョブを実行するためのGitLab Runnerを別途インストールしてGitLabサーバーに登録する必要があります。Runnerも定期的なメンテナンスとバージョンアップが必要です。
  • パフォーマンスチューニング: ユーザー数の増加やリポジトリサイズの増大によってパフォーマンスが悪化した場合は、gitlab-ctl reconfigure でPostgreSQL, Redis, Puma/Unicornなどの設定パラメータを見直したり、サーバーのリソースを増強したりしてパフォーマンスを改善します。

他のインストール方法について (簡単な紹介)

この記事ではOmnibus Packageを中心に解説しましたが、他の方法にも簡単に触れておきます。

  • Dockerを使ったインストール: Dockerが利用できる環境であれば、公式Dockerイメージをpullして実行することでGitLabを立ち上げられます。データ永続化のためにボリューム設定が必要です。docker-composeを使うと、依存するPostgreSQLやRedisコンテナもまとめて管理できて便利です。手軽に試したい場合や、既存のDocker環境がある場合に良い選択肢です。
  • Kubernetesを使ったインストール: 大規模なチームや高い可用性が求められる環境では、Kubernetes上にGitLabをデプロイすることがあります。公式のHelm Chartを利用するのが標準的な方法です。これにより、GitLabの各コンポーネントが独立したPodとして動作し、スケーリングやフェイルオーバーがKubernetesによって管理されます。Kubernetesの運用ノウハウがあるチーム向けです。
  • ソースコードからのインストール: これはGitLabの開発者や、非常に特殊なカスタマイズが必要な場合にのみ検討される方法です。手順が複雑で、依存関係の管理やバージョンアップが非常に困難なため、特別な理由がない限り避けるべきです。

まとめ：あなたのGitLab環境が整いました！

この記事では、GitLabのセルフホスト版を、最も手軽で推奨されるOmnibus Packageを使ってインストールする方法を、準備段階から初回アクセス、詳細設定、運用、セキュリティまで、約5000語にわたり詳細に解説しました。

GitLabをセルフホストすることで、開発プロセス全体を統合した強力なDevOpsプラットフォームをあなたの管理下に置くことができます。チームの規模やプロジェクトの特性に合わせて、柔軟にカスタマイズし、セキュリティとパフォーマンスをコントロールできるようになります。

インストールが完了したら、まずは以下のステップでGitLabの基本機能を試してみてください。

  1. 新しいプロジェクトを作成してみる。
  2. Gitクライアントを使って、作成したプロジェクトをクローン、変更、プッシュしてみる。
  3. チームメンバーをユーザーとして追加し、プロジェクトに招待してみる。
  4. イシューを作成し、タスク管理を始めてみる。
  5. 簡単な .gitlab-ci.yml ファイルを作成し、CI/CDパイプラインを試してみる。

GitLabの機能は非常に豊富です。最初はすべての機能を使いこなせなくても問題ありません。チームで使いながら、徐々にGitLabの様々な機能を活用していくことで、開発効率とチームのコラボレーションは間違いなく向上するでしょう。

この記事が、あなたのGitLabサーバー構築の一助となれば幸いです。安全で快適なGitLabライフをお楽しみください！そして、困ったときは公式ドキュメントやコミュニティを積極的に活用してください。GitLabは強力な味方になってくれるはずです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール