GitLabのインストール入門

By /

はい、承知いたしました。GitLabインストール入門に関する詳細な記事を約5000語で記述し、直接表示します。

GitLabインストール入門：完全ガイドと詳細解説

はじめに：DevOpsプラットフォームとしてのGitLab

現代のソフトウェア開発において、バージョン管理システムは不可欠です。中でもGitは分散型バージョン管理システムのデファクトスタンダードとなり、多くの開発現場で利用されています。しかし、単なるバージョン管理だけでなく、コードレビュー、継続的インテグレーション（CI）、継続的デリバリー（CD）、プロジェクト管理、監視といった開発ライフサイクル全体を効率化するためのプラットフォームが求められています。

そこで登場するのがGitLabです。GitLabは、Gitリポジトリ管理を中心に据えながら、CI/CDパイプライン、イシュー追跡、Wiki、コンテナレジストリ、モニタリングなど、DevOpsに必要な様々な機能を統合的に提供するウェブベースのプラットフォームです。これにより、開発チームは一つのアプリケーション上でプロジェクトの計画、コード作成、検証、パッケージ化、リリース、設定、監視という全ての段階を円滑に進めることができます。

GitLabには、SaaS（Software as a Service）として提供されるGitLab.comと、自分たちのサーバーにインストールして運用するセルフホスト版があります。GitLab.comは手軽に利用を開始できる反面、データの保管場所やカスタマイズ性に制限があります。一方、セルフホスト版は、自社のセキュリティポリシーに合わせた環境構築、リソースの柔軟な管理、他の内部システムとの連携など、より高度な要件に対応できるというメリットがあります。

このガイドでは、GitLabのセルフホスト版をLinuxサーバーにインストールするための最も一般的で推奨される方法であるOmnibusパッケージを利用したインストール手順について、初心者の方でも理解できるように詳細かつ丁寧に解説します。約5000語というボリュームで、単なるコマンドの羅列に終わらず、各ステップの背景にある理由や、インストール後に必要となる基本的な設定、運用に関するヒントまで網羅することを目指します。

このガイドを通じて、GitLabセルフホスト環境を構築し、DevOps実践の第一歩を踏み出すためのお手伝いができれば幸いです。

対象読者

  • GitLabを自分たちのサーバーにインストールしてみたい開発者、システム管理者。
  • Gitや基本的なLinuxコマンドの知識はあるが、サーバーアプリケーションのインストール経験は少ない方。
  • GitLabのセルフホスト版のメリットとデメリットを理解し、自分で環境をコントロールしたいと考えている方。

このガイドで学ぶこと

  • GitLabインストールに必要なサーバー要件と準備。
  • 最も簡単なGitLabのインストール方法であるOmnibusパッケージの利用。
  • 主要なLinuxディストリビューション（Ubuntu, CentOS/RHEL）での具体的なインストールコマンド。
  • GitLabの基本的な設定（外部URL、メール送信設定など）。
  • GitLabへの初回アクセスと管理者パスワードの設定。
  • セキュリティのためのSSL/TLS設定（Let’s Encrypt利用を含む）。
  • インストール後の基本的な運用（再設定、サービス制御、ログ確認）。
  • トラブルシューティングのヒント。

GitLabのインストール方法の選択：なぜOmnibusパッケージか？

GitLabのセルフホスト版をインストールする方法はいくつか存在します。

  1. Omnibusパッケージ: 推奨される最も簡単な方法です。GitLab本体、ウェブサーバー(Nginx)、データベース(PostgreSQL)、キャッシュ(Redis)、バックグラウンドジョブ処理(Sidekiq)など、GitLabを動作させるために必要なすべてのコンポーネントと依存関係が一つにまとめられており、単一のパッケージとして提供されます。インストールと設定が非常に簡単で、特別な専門知識なしにGitLab環境を構築できます。ほとんどのユーザーにとって、この方法が最適です。
  2. Source Installation: GitLabのソースコードからビルドしてインストールする方法です。コンポーネントを個別に管理できるため、高度なカスタマイズが可能ですが、設定や依存関係の管理が非常に複雑で、高い専門知識が必要です。初心者には推奨されません。
  3. Docker: DockerコンテナとしてGitLabを実行する方法です。環境構築が再現可能で比較的容易ですが、Dockerやコンテナ技術に関する知識が必要です。
  4. Kubernetes (Helm Charts): Kubernetesクラスター上にGitLabをデプロイする方法です。スケーラビリティや可用性に優れますが、Kubernetesに関する深い知識が必要です。
  5. Cloud Images: 各種クラウドプロバイダー（AWS, GCP, Azureなど）が提供するGitLabのAMIやイメージを利用する方法です。すでにGitLabがインストールされた状態から始められるため手軽ですが、クラウドプロバイダーに依存します。

このガイドでは、導入の敷居が最も低く、多くのユースケースで十分な機能と安定性を提供するOmnibusパッケージに焦点を当てて解説します。

ステップ1：インストール前の準備と要件確認

GitLabをスムーズにインストールし、安定して運用するためには、事前にいくつかの準備と要件の確認が必要です。

1. サーバーの選択とオペレーティングシステム (OS)

GitLab Omnibusパッケージは、主に以下のLinuxディストリビューションをサポートしています。

  • Ubuntu LTS (長期サポート版): 18.04, 20.04, 22.04 など
  • CentOS/RHEL (Red Hat Enterprise Linux): 7, 8, 9 など
  • Debian: 9, 10, 11 など
  • Oracle Linux: 7, 8, 9 など
  • Amazon Linux 2

このガイドでは、代表的なディストリビューションであるUbuntu LTSとCentOS/RHELを例に進めます。ご自身のサーバー環境に合わせて適切なディストリビューションを選択してください。新しい安定版LTSバージョンが推奨されます。

サーバーは物理サーバー、仮想マシン（VM）、クラウドインスタンス（AWS EC2, GCP Compute Engine, Azure VMなど）のいずれでも構いません。

2. ハードウェア要件

GitLabのハードウェア要件は、利用ユーザー数やアクティビティ（特にCI/CDの実行頻度）によって大きく変動します。以下は一般的な推奨スペックですが、小規模なチーム（100ユーザー未満、軽度なCI/CD）であれば最低要件でも動作可能です。しかし、快適な利用と将来的な拡張性を考えると、推奨スペック以上を用意することをお勧めします。

  • CPU:
    • 最低要件: 2コア
    • 推奨: 4コア以上 (100ユーザー未満の場合)
    • 注意: GitLabのコンポーネント（Puma, Sidekiqなど）はマルチプロセス・マルチスレッドで動作するため、コア数が多いほど多くの並列処理が可能です。CI/CD Runnerを同じサーバーで実行する場合は、さらに多くのコアが必要になります。
  • メモリ (RAM):
    • 最低要件: 4GB
    • 推奨: 8GB以上 (100ユーザー未満の場合)
    • 注意: メモリはGitLabのパフォーマンスに最も影響する要素の一つです。データベース、アプリケーションサーバー、バックグラウンドジョブなどがメモリを使用します。特にCI/CDを利用する場合、多くのメモリを消費します。メモリ不足はスワップの多用につながり、パフォーマンスが著しく低下します。
  • ディスク容量:
    • 最低要件: 50GBの空き容量
    • 推奨: 100GB以上
    • 注意: Gitリポジトリ、データベース、ビルドアーティファクト、コンテナイメージなどがディスク容量を消費します。特にリポジトリサイズが大きい場合やCI/CDを多用する場合、バックアップをサーバー上に保存する場合などは、より多くの容量が必要です。高速なSSDが強く推奨されます。
  • スワップ領域:
    • メモリサイズの2倍（ただし、メモリが8GBを超える場合は8GB以上）。スワップ領域は、物理メモリが不足した際に使用されますが、パフォーマンスに悪影響を与えるため、スワップが発生しない十分なメモリを確保することが理想です。

3. ネットワーク要件 (ドメイン名とDNS)

GitLabにウェブブラウザからアクセスするためには、サーバーのIPアドレスまたはドメイン名が必要です。

  • IPアドレス: 一時的なテスト目的であればIPアドレスでもアクセス可能ですが、HTTPS (SSL/TLS) を利用するにはドメイン名が必須です。また、GitLabの機能の多くは、正確なURL (external_url) 設定に依存しており、ドメイン名を使用する方が安定して動作します。
  • ドメイン名とDNS: 運用目的であれば、ドメイン名（例: gitlab.yourcompany.com）を取得し、そのドメイン名がGitLabをインストールするサーバーのパブリックIPアドレスを指すようにDNSレコード（Aレコード）を設定してください。プライベートネットワーク内にインストールする場合は、内部DNSまたはhostsファイルで名前解決できるように設定します。

4. ファイアウォール設定

外部からGitLabサーバーにアクセスできるように、必要なポートを開放する必要があります。

  • SSH (ポート22): サーバーへのリモートアクセス、およびGitのSSHプロトコルによるクローン/プッシュに必要です。
  • HTTP (ポート80): WebUIへのアクセス、およびHTTPSへのリダイレクトやLet’s EncryptによるSSL証明書の発行/更新に必要です。
  • HTTPS (ポート443): WebUIへのセキュアなアクセスに必要です。

サーバーのOSレベルのファイアウォール（ufw, firewalldなど）や、クラウドプロバイダーのセキュリティグループ設定で、これらのポートを開放してください。

5. メール送信設定 (SMTP)

GitLabは、ユーザー登録時の確認、パスワードリセット、プッシュ通知、CI/CDのステータス通知など、多くの場面でメールを送信します。これらの通知を有効にするためには、GitLabが利用できるSMTPサーバーを設定する必要があります。これはGitLabサーバー自身にPostfixなどのMTAをインストール・設定するか、GmailやSendGridのような外部のSMTPサービスを利用することで実現できます。インストール後の設定で詳しく解説します。

6. ホスト名の設定

サーバーのホスト名が正しく設定されていることを確認してください。hostname -f コマンドでFQDN (Fully Qualified Domain Name) が表示されるのが理想です。

7. 既存のサービスとの競合

GitLab Omnibusパッケージは、Nginx (Webサーバー)、PostgreSQL (データベース)、Redis (キャッシュ) などのコンポーネントを内部にインストール・設定します。もしサーバー上に既にこれらのサービスが動作している場合、ポートの競合が発生する可能性があります。Omnibusパッケージはデフォルトで標準ポート (Nginx: 80/443, PostgreSQL: 5432, Redis: 6379) を使用するため、競合する場合は既存サービスを停止するか、GitLabの設定を変更して別のポートを使用させる必要があります。最も簡単なのは、GitLab専用のサーバーを用意することです。

これらの準備が整ったら、いよいよインストールに進みます。

ステップ2：GitLab Omnibusパッケージのインストール

ここでは、UbuntuとCentOS/RHELそれぞれでのインストール手順を解説します。ご自身のOSに合わせて手順を選択してください。

作業はrootユーザーまたはsudo権限を持つユーザーで行います。セキュリティのため、sudoを使用することを推奨します。

共通の準備：必要なパッケージのインストール

まず、Omnibusパッケージのダウンロードやインストールに必要な基本的なパッケージをインストールします。

Ubuntuの場合:

bash
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates postfix

  • apt-get update: パッケージリストを最新の状態に更新します。
  • curl: GitLabリポジトリを追加するためのスクリプトをダウンロードするのに使用します。
  • openssh-server: GitのSSHアクセスに必要です。通常は既にインストールされていますが、念のため確認します。
  • ca-certificates: SSL/TLS通信に必要な証明書を扱います。
  • postfix: GitLabからのメール通知のために使用します。インストール時に設定画面が表示されることがあります。インターネットサイト、ローカルのみなど、環境に合わせて設定してください。これは必須ではありませんが、後で外部SMTPサーバーを設定する場合でも、一時的にインストールしておくと依存関係の問題が起きにくい場合があります。

CentOS/RHELの場合:

“`bash
sudo yum update -y
sudo yum install -y curl policycoreutils openssh-server perl
sudo systemctl enable sshd
sudo systemctl start sshd
sudo firewall-cmd –permanent –add-service=ssh
sudo firewall-cmd –reload

Postfixをインストール（任意 – メール通知用）

sudo yum install -y postfix

sudo systemctl enable postfix

sudo systemctl start postfix

sudo firewall-cmd –permanent –add-service=smtp # SMTPポートを開放する場合

sudo firewall-cmd –reload

“`

  • yum update -y: パッケージを最新の状態に更新します。
  • curl: GitLabリポジトリを追加するためのスクリプトをダウンロードするのに使用します。
  • policycoreutils: SELinux関連のユーティリティ。SELinuxが有効な環境で必要になることがあります。
  • openssh-server: GitのSSHアクセスに必要です。インストールと起動、ファイアウォール設定を行います。
  • perl: GitLabの一部のスクリプトで利用されることがあります。
  • postfix: メール通知のためにインストールできます（任意）。インストール、起動、ファイアウォール設定を行います。

GitLabリポジトリの追加

GitLab Omnibusパッケージは、公式のリポジトリからダウンロードしてインストールするのが一般的です。以下のスクリプトを実行することで、システムのパッケージマネージャー（aptまたはyum）がGitLabパッケージを見つけられるようになります。

共通コマンド:

“`bash
curl https://packages.gitlab.com/install/certificates/gitlab.gpg | sudo apt-key add – # Ubuntu/Debianの場合
curl https://packages.gitlab.com/install/certificates/gitlab.gpg | sudo rpm –import – # CentOS/RHELの場合

GitLab CE (Community Edition) または EE (Enterprise Edition) のリポジトリを追加

CEは無料版、EEは有料版（トライアル可能）。ここではCEを例に進めます。

curl https://packages.gitlab.com/install/auto/gitlab-ce/install.sh | sudo bash
“`

  • curl ... | sudo apt-key add - または curl ... | sudo rpm --import -: GitLabパッケージの署名に使われているGPGキーを追加します。これにより、ダウンロードしたパッケージがGitLab公式のものであることを検証できます。
  • curl ... | sudo bash: GitLab公式が提供するインストールスクリプトを実行します。このスクリプトは、OSを自動で判別し、適切なリポジトリ設定ファイル（/etc/apt/sources.list.d/gitlab_gitlab-ce.list など）を作成し、パッケージリストを更新します。

このスクリプトの実行が完了すると、システムはGitLabパッケージをインストール可能な状態になります。

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

リポジトリが追加されたので、いよいよGitLabパッケージ本体をインストールします。Community Edition (CE) または Enterprise Edition (EE) のどちらかをインストールします。機能比較はGitLab公式サイトを参照してください。ここでは無料で利用できるCEをインストールします。

Ubuntuの場合:

bash
sudo apt-get update
sudo apt-get install gitlab-ce

  • apt-get update: 追加したGitLabリポジトリからパッケージ情報を取得するために、もう一度パッケージリストを更新します。
  • apt-get install gitlab-ce: GitLab Community EditionのOmnibusパッケージをインストールします。

CentOS/RHELの場合:

bash
sudo yum makecache
sudo yum install gitlab-ce

  • yum makecache: 追加したGitLabリポジトリからパッケージ情報を取得します。
  • yum install gitlab-ce: GitLab Community EditionのOmnibusパッケージをインストールします。

これらのコマンドを実行すると、GitLab本体とその依存コンポーネント（Nginx, PostgreSQL, Redisなど）がまとめてダウンロードされ、インストールされます。インストールには数分から数十分かかる場合があります。

インストールの確認

インストールが完了しても、GitLabはまだ完全に設定され、起動しているわけではありません。パッケージのインストールが成功したことを確認するには、特にエラーメッセージが出ていないことを確認します。

ステップ3：GitLabの初期設定と再設定

Omnibusパッケージのインストールが完了したら、次にGitLabを起動・設定する必要があります。これは gitlab-ctl reconfigure コマンドで行います。このコマンドを実行する前に、最低限必要な設定を行います。

GitLab Omnibusパッケージの主要な設定ファイルは /etc/gitlab/gitlab.rb です。このファイルはRuby構文で記述されており、様々な設定項目がコメントアウトされた状態で含まれています。デフォルト設定を上書きしたい項目のみ、コメントアウトを解除して値を変更します。

必須設定：外部URL (external_url)

最も重要な設定項目は external_url です。これは、GitLabインスタンスにブラウザからアクセスする際に使用するURLを指定します。GitLabの内部コンポーネント（例: Nginx）はこの設定を元に動作するため、正しく設定することが不可欠です。

/etc/gitlab/gitlab.rb ファイルを編集します。

bash
sudo vi /etc/gitlab/gitlab.rb

ファイルを開き、external_url の行を探します。

“`ruby

external_url ‘GENERATED_EXTERNAL_URL’ # この行を探す

“`

この行のコメントアウト # を外し、ご自身のGitLabインスタンスにアクセスするURLを指定します。HTTPSを最終的に使用する場合でも、最初はHTTPで設定し、後からSSLを設定するのが簡単です。

ruby
external_url 'http://your.gitlab.domain.or.ip' # 例：http://gitlab.example.com または http://192.168.1.100

注意点:
* 必ずスキーム (http:// または https://) を含めてください。
* ポート番号を省略した場合、HTTPは80、HTTPSは443が使用されます。標準以外のポートでアクセスする場合は、ポート番号も含めます（例: http://gitlab.example.com:8080）。
* ドメイン名を使用することを強く推奨します。SSL設定にはドメイン名が必須です。

その他の一般的な設定 (オプション)

/etc/gitlab/gitlab.rb には、他にも多くの設定項目があります。必要に応じてコメントアウトを解除し、設定します。

  • メール送信設定 (SMTP): GitLabからの通知メールを送信するために必要です。Postfixなどをローカルで使用する場合、特に設定は不要なことが多いですが、外部SMTPサーバーを利用する場合は設定が必要です。

    “`ruby
    gitlab_rails[‘smtp_enable’] = true
    gitlab_rails[‘smtp_address’] = “smtp.gmail.com” # 例：Gmailの場合
    gitlab_rails[‘smtp_port’] = 587 # 例：Gmailの場合
    gitlab_rails[‘smtp_user_name’] = “[email protected]” # 例：Gmailの場合
    gitlab_rails[‘smtp_password’] = “your_email_password” # 例：Gmailの場合（アプリパスワードを推奨）
    gitlab_rails[‘smtp_authentication’] = “login”
    gitlab_rails[‘smtp_enable_starttls_auto’] = true

    gitlab_rails[‘smtp_tls’] = true # SSL/TLSを使用する場合

    gitlab_rails[‘smtp_openssl_verify_mode’] = ‘peer’ # 証明書の検証モード

    gitlab_rails[‘smtp_ca_path’] = ‘/etc/ssl/certs’ # CA証明書のパス

    gitlab_rails[‘smtp_ca_file’] = ‘/etc/ssl/certs/ca-certificates.crt’ # CA証明書ファイル

    GitLabからのメール送信元アドレス

    gitlab_rails[‘gitlab_email_from’] = ‘[email protected]’
    gitlab_rails[‘gitlab_email_display_name’] = ‘GitLab’
    “`
    設定例はGmailですが、SendGrid, Mailgun, あるいは自社内のSMTPサーバーなど、利用するサービスに合わせて設定してください。パスワードを直接ファイルに記述することになるため、ファイルの権限管理には注意が必要です。

  • タイムゾーン: GitLabが表示する時刻のタイムゾーンを設定します。

    ruby
    gitlab_rails['time_zone'] = 'Asia/Tokyo' # 例：日本標準時

  • Nginx設定: デフォルトのポートやSSL設定などをカスタマイズできます。詳細は後述のSSL設定セクションで触れます。

設定の変更が完了したら、ファイルを保存してエディタを終了します。

GitLabの再設定 (Reconfigure)

/etc/gitlab/gitlab.rb の設定をGitLabに反映させるには、gitlab-ctl reconfigure コマンドを実行します。このコマンドは以下の処理を行います。

  1. /etc/gitlab/gitlab.rb ファイルを読み込み、Rubyシンタックスエラーがないかチェックします。
  2. 設定ファイルを元に、各コンポーネント（Nginx, Puma, PostgreSQL, Redisなど）の具体的な設定ファイルを生成します。これらのファイルは /var/opt/gitlab/ 配下に配置されます。
  3. 必要に応じてデータベースの初期化やマイグレーションを実行します。
  4. 各サービス（Nginx, Puma, Sidekiqなど）を再起動またはリロードして、新しい設定を反映させます。

bash
sudo gitlab-ctl reconfigure

このコマンドの実行には数分かかります。実行中は、各コンポーネントの設定生成、チェック、サービスの起動・停止・再起動などのログが詳細に表示されます。

重要: external_url の設定が正しくない場合や、ファイアウォール設定、ポート競合などがある場合、reconfigure プロセス中にエラーが発生することがあります。エラーメッセージをよく確認し、原因を取り除いてから再度 reconfigure を実行してください。

GitLabサービスの確認

reconfigure が成功したら、GitLabの各サービスが正常に起動しているか確認します。

bash
sudo gitlab-ctl status

このコマンドを実行すると、GitLabを構成する主なサービス（logrotate, nginx, postgresql, puma, redis, sidekiqなど）の現在の状態（起動中、停止中など）が表示されます。すべてのサービスが run (または running) と表示されていれば正常です。

もし down と表示されているサービスがある場合は、そのサービスのログを確認して原因を特定します（例: sudo gitlab-ctl tail nginx でNginxのログを表示）。

ステップ4：GitLabへの初回アクセスと管理者パスワード設定

gitlab-ctl reconfigure が成功し、サービスが起動していることを確認できたら、ウェブブラウザからGitLabにアクセスしてみましょう。

ウェブブラウザを開き、external_url で設定したURLにアクセスします（例: http://your.gitlab.domain.or.ip）。

初回アクセス時には、rootユーザー（管理者）のパスワードを設定する画面が表示されます。

  1. 新しいパスワードを入力します。
  2. 確認のため、もう一度同じパスワードを入力します。
  3. 「Change your password」ボタンをクリックします。

パスワードの設定が成功すると、ログイン画面にリダイレクトされます。

ログイン画面:

  • Username or Email: root を入力します。
  • Password: 先ほど設定したパスワードを入力します。

「Sign in」ボタンをクリックしてログインします。

これで、GitLabの管理者としてシステムにアクセスできるようになりました。ログイン後の画面は、GitLabのダッシュボードです。

ステップ5：基本的なセキュリティ設定 (SSL/TLS)

HTTPでアクセスできるようになったら、次にセキュリティ向上のためにHTTPS (SSL/TLS) を設定することを強く推奨します。これにより、クライアント（ブラウザやGitクライアント）とGitLabサーバー間の通信が暗号化され、盗聴や改ざんのリスクが軽減されます。

GitLab Omnibusパッケージは、組み込みのNginxウェブサーバーを利用し、Let’s Encryptと簡単に連携して無料のSSL証明書を自動的に取得・更新する機能を持っています。ドメイン名を使用している場合、この方法が最も簡単です。

Let’s Encryptによる自動SSL設定

前提条件：
* GitLabサーバーがインターネットからポート80と443でアクセス可能であること。
* external_url で設定したドメイン名が、GitLabサーバーのパブリックIPアドレスを正しく指すようにDNSレコードが設定されていること。Let’s Encryptはポート80経由でドメインの所有権を検証します。

/etc/gitlab/gitlab.rb を再度編集します。

bash
sudo vi /etc/gitlab/gitlab.rb

external_url を https に変更します。

ruby
external_url 'https://your.gitlab.domain.or.ip' # 例：https://gitlab.example.com

そして、Let’s Encryptの設定を有効にします。

“`ruby
letsencrypt[‘enable’] = true # Let’s Encrypt を有効にする
letsencrypt[‘auto_renew’] = true # 証明書の自動更新を有効にする

letsencrypt[‘contact_emails’] = [‘[email protected]’] # 通知を受け取るメールアドレス (任意)

“`

変更を保存し、再度 gitlab-ctl reconfigure を実行します。

bash
sudo gitlab-ctl reconfigure

reconfigure プロセス中に、GitLabはLet’s Encryptクライアントを実行し、指定されたドメイン名の証明書を取得しようとします。ログにエラーが出ていないか注意深く確認してください。証明書の取得が成功すると、Nginxの設定がHTTPSを使用するように自動的に更新されます。

reconfigure が完了したら、ブラウザから https://your.gitlab.domain.or.ip にアクセスしてみてください。正しく設定されていれば、南京錠アイコンが表示され、HTTPSで接続できていることが確認できます。HTTPでアクセスした場合も、自動的にHTTPSにリダイレクトされるはずです。

Let’s Encryptで証明書が取得できない場合は、DNS設定が正しいか、ポート80と443がファイアウォールで開放されているか、他のサービスがこれらのポートを使用していないかなどを確認してください。

手動でのSSL証明書設定

CA署名付きの商用証明書や自己署名証明書を使用したい場合は、手動で設定することも可能です。

  1. 証明書ファイル (.crt, .cer, .pem など) と秘密鍵ファイル (.key) をサーバーの安全な場所に配置します（例: /etc/gitlab/ssl/ ディレクトリを作成してそこに配置）。
  2. /etc/gitlab/gitlab.rb を編集します。external_url はHTTPSに設定します。

  3. 組み込みNginxのSSL設定をカスタマイズします。letsencrypt['enable'] = false に設定し、NginxのSSL関連設定を有効にします。

    “`ruby
    external_url ‘https://your.gitlab.domain.or.ip’

    Let’s Encrypt は無効にする

    letsencrypt[‘enable’] = false

    Nginx の SSL 設定を有効にする

    nginx[‘redirect_http_to_https’] = true # HTTPからHTTPSへのリダイレクトを有効にする
    nginx[‘ssl_certificate’] = “/etc/gitlab/ssl/your_domain.crt” # 証明書ファイルのパス
    nginx[‘ssl_certificate_key’] = “/etc/gitlab/ssl/your_domain.key” # 秘密鍵ファイルのパス

    オプション：中間証明書などを指定する場合

    nginx[‘ssl_trusted_certificate’] = “/etc/gitlab/ssl/trusted_ca_certs.crt”

    ``
    4. ファイルを保存し、    sudo gitlab-ctl reconfigure` を実行します。

どちらの方法にしても、HTTPSで安全にアクセスできる状態にすることは、運用上非常に重要です。

ステップ6：インストール後の基本的な運用

GitLabがインストールされ、ウェブUIからアクセスできるようになったら、日々の運用に必要な基本的なコマンドや考慮事項を理解しておくことが重要です。

GitLabサービスの制御

gitlab-ctl コマンドを使って、GitLabを構成するサービスの制御ができます。

  • すべてのサービスを起動: sudo gitlab-ctl start
  • すべてのサービスを停止: sudo gitlab-ctl stop
  • すべてのサービスを再起動: sudo gitlab-ctl restart
  • すべてのサービスの状態確認: sudo gitlab-ctl status
  • 設定変更を反映してサービスを再起動: sudo gitlab-ctl reconfigure (最も頻繁に使用)

設定ファイルの場所

  • メイン設定ファイル: /etc/gitlab/gitlab.rb
  • 証明書などのファイル置き場（推奨）: /etc/gitlab/ssl/ (手動で作成)
  • 自動生成されたコンポーネント設定ファイル: /var/opt/gitlab/ 配下
  • リポジトリデータ、データベースデータなどの保存場所: /var/opt/gitlab/ 配下

ログファイルの確認

トラブルシューティングやサーバーの状態確認のために、ログファイルを確認することが重要です。GitLab Omnibusパッケージのログは、デフォルトで /var/log/gitlab/ ディレクトリ配下に、各サービス（nginx, puma, sidekiq, postgresqlなど）ごとに格納されています。

  • 特定のサービスのログをリアルタイムで表示: sudo gitlab-ctl tail <service_name> (例: sudo gitlab-ctl tail nginx)
  • 特定のログファイルの中身を確認: sudo less /var/log/gitlab/<service_name>/current
  • reconfigure のログ: /var/log/gitlab/reconfigure/current

バックアップ

GitLabのバックアップは非常に重要です。 万が一のデータ損失に備え、定期的なバックアップ戦略を確立してください。

GitLab Omnibusパッケージには、バックアップ作成コマンドが用意されています。

bash
sudo gitlab-backup create

このコマンドを実行すると、GitLabのすべてのデータ（リポジトリ、データベース、アップロードファイルなど）が /var/opt/gitlab/backups/ ディレクトリ配下にタイムスタンプ付きのtarファイルとして保存されます。

デフォルトのバックアップ保存先はGitLabサーバー上なので、必ずこのバックアップファイルをリモートストレージ（S3、NFS、別のサーバーなど）にコピーするように自動化してください。サーバーがクラッシュした場合、ローカルにバックアップがあっても復旧できません。

バックアップの保存場所は /etc/gitlab/gitlab.rb で設定できます。

ruby
gitlab_backup['backup_directory'] = '/mnt/backups' # 例：NFSマウントされたディレクトリなど

バックアップの自動化は、cronなどのタスクスケジューラを使用して定期的に sudo gitlab-backup create コマンドを実行することで実現できます。

例：毎日午前2時にバックアップを実行する (cronを使用)

bash
sudo crontab -e
以下の行を追加：
crontab
0 2 * * * sudo gitlab-backup create CRON=1
CRON=1 オプションは、cronから実行されたことをGitLabに伝え、一部の処理を調整します。

リストア方法についても公式ドキュメントを確認しておくことを推奨します。

アップデート

GitLabは頻繁にアップデートがリリースされます。セキュリティ修正や新機能が含まれているため、定期的にアップデートすることをお勧めします。アップデートは、システムのパッケージマネージャーを使って簡単に行えます。

アップデート前に、必ずバックアップを作成し、GitLabのリリースノートを確認してください。特にメジャーバージョンアップ（例: 15.x から 16.x）では、重要な変更点や注意点がある場合があります。

Ubuntuの場合:

bash
sudo apt-get update
sudo apt-get upgrade gitlab-ce # または gitlab-ee
sudo gitlab-ctl reconfigure # アップデート後に必ず再設定を実行

CentOS/RHELの場合:

bash
sudo yum update gitlab-ce # または gitlab-ee
sudo gitlab-ctl reconfigure # アップデート後に必ず再設定を実行

アップデート後には、gitlab-ctl reconfigure が自動的に実行されない場合があるため、手動で実行することが重要です。また、アップデート後にウェブUIにアクセスして、正しく動作しているか確認してください。

ステップ7：トラブルシューティングのヒント

インストールや運用中に問題が発生した場合の一般的なトラブルシューティング方法です。

1. gitlab-ctl reconfigure が失敗する

これは最もよく遭遇する問題の一つです。reconfigure が失敗した場合、エラーメッセージがコンソールに表示されるか、ログファイルに記録されます。

  • エラーメッセージの確認: ターミナルに表示される赤いエラーメッセージを注意深く読んでください。どのコンポーネント（Nginx, PostgreSQL, Rubyなど）で問題が発生しているかがわかることが多いです。
  • reconfigureログの確認: /var/log/gitlab/reconfigure/current ファイルに詳細なログが記録されています。エラーが発生した箇所の周辺を重点的に確認します。
  • 一般的な原因:
    • /etc/gitlab/gitlab.rb の記述ミス（Rubyシンタックスエラー、typoなど）。sudo gitlab-ctl check-config コマンドで基本的な設定ファイルのチェックができます。
    • ハードウェアリソース不足（特にメモリ）。メモリが不足していると、一部のサービス起動やデータベースマイグレーションに失敗することがあります。free -h などでメモリ使用量とスワップ使用量を確認します。
    • ポート競合。Nginx (80/443)、PostgreSQL (5432)、Redis (6379) などのポートが他のサービスによって使用されている場合。sudo netstat -tulnp などでリスニングポートを確認します。
    • ファイアウォールの問題。外部との通信や、ローカルホスト内でのサービス間通信がファイアウォールによってブロックされている可能性。
    • SELinuxの設定。SELinuxがEnforcingモードになっている場合、GitLabの特定の操作がブロックされることがあります。ログ (/var/log/audit/audit.log など) を確認し、必要に応じてSELinuxポリシーを調整するか、Permissiveモードに変更します（セキュリティリスクを理解した上で行ってください）。

2. ウェブUIにアクセスできない

  • GitLabサービスの起動確認: sudo gitlab-ctl status でNginxとPumaサービスが run 状態であることを確認します。
  • ファイアウォール確認: ポート80/443 (または external_url で指定したポート) がサーバーのファイアウォールやセキュリティグループで開放されているか確認します。
  • external_url 設定の確認: /etc/gitlab/gitlab.rb の external_url がブラウザでアクセスしているURLと一致しているか確認します。スキーム (http:// または https://)、ホスト名/IPアドレス、ポート番号が全て正しい必要があります。
  • DNS設定の確認: ドメイン名でアクセスしている場合、そのドメイン名がGitLabサーバーのIPアドレスを正しく指しているか確認します（ping your.gitlab.domain や nslookup your.gitlab.domain）。
  • Nginxログの確認: /var/log/gitlab/nginx/current にアクセスログやエラーログが出力されます。何が原因で接続が失敗しているかヒントが得られます。

3. メールが送信されない

  • SMTP設定の確認: /etc/gitlab/gitlab.rb のSMTP設定が正しいか確認します。SMTPサーバーのアドレス、ポート、ユーザー名、パスワード、認証方法などが正確である必要があります。
  • ファイアウォール確認: GitLabサーバーから外部SMTPサーバーへの接続に必要なポート（例: 25, 465, 587）が開放されているか確認します。
  • GitLabコンソールの利用: 管理エリアの「Settings」->「Network」->「Outgoing emails」セクションで、設定したSMTPサーバーへの接続テストやテストメール送信ができる機能が提供されている場合があります（バージョンによる）。または、gitlab-rails console を使ってRuby on Railsコンソールから手動でメール送信を試すことも可能です（上級者向け）。
  • Postfixなどのログ確認: ローカルのMTAや外部SMTPサーバー側のログを確認します。

4. パフォーマンスが遅い

  • ハードウェアリソース: CPU使用率、メモリ使用率、スワップ使用量、ディスクI/Oなどを監視します。特にメモリ不足やスワップの多用はパフォーマンスに致命的な影響を与えます。top, htop, vmstat, iostat などのコマンドで確認できます。
  • GitLabの組み込み監視: GitLabはPrometheusとの連携など、多くの監視機能を持っています。これらを活用してパフォーマンスボトルネックを特定します。
  • Sidekiqキュー: バックグラウンドジョブキュー (Sidekiq) が大量に詰まっている場合、GitLabの応答性が低下します。管理者エリアからSidekiqのステータスを確認できます。

トラブルシューティングの際には、GitLabの公式ドキュメントが非常に役立ちます。エラーメッセージや現象で検索することで、解決策が見つかることが多いです。また、GitLabコミュニティフォーラムで質問することもできます。

ステップ8：さらなるステップと高度な設定 (概要)

GitLabのインストールと基本的な設定が完了したら、さらに多くの機能を利用したり、運用を最適化したりするためのステップがあります。

  • ユーザー・グループの管理: 新しいユーザーを作成し、グループを作成してプロジェクトへのアクセス権限を管理します。LDAP/Active Directory連携やSAML/OAuthなどの外部認証連携も可能です。
  • プロジェクトの作成とGitリポジトリの利用: プロジェクトを作成し、既存のGitリポジトリをインポートするか、新しいリポジトリを作成してクローン/プッシュを開始します。
  • CI/CDの活用: .gitlab-ci.yml ファイルを作成して、ビルド、テスト、デプロイなどのCI/CDパイプラインを定義します。GitLab Runnerのセットアップが必要です。
  • Kubernetes連携: Kubernetesクラスターとの連携を設定し、デプロイメントを自動化したり、Kubernetes上のCI/CD Runnerを利用したりできます。
  • Container Registry: GitLabに内蔵されているContainer Registryを利用して、Dockerイメージなどを管理できます。
  • その他の機能: イシューボード、Wiki、スニペット、マージリクエスト、コードレビュー、パッケージレジストリなど、GitLabが提供する豊富な機能を活用します。
  • 監視とロギングの強化: Prometheus, Grafana, Elasticsearchなどの外部ツールと連携して、より詳細な監視やログ分析を行います。
  • スケーリング: 利用ユーザー数や負荷が増加した場合、GitLabを複数のサーバーに分散して構成することでスケーリングが可能です（データベースの分離、アプリケーションサーバーの複数化など）。これはOmnibusパッケージでも可能ですが、設定はより複雑になります。

これらの高度な設定や機能については、GitLabの公式ドキュメントに詳細な情報が掲載されています。

まとめ：GitLabインストール成功への道

このガイドでは、GitLabのセルフホスト版をOmnibusパッケージを使ってLinuxサーバーにインストールする手順を詳細に解説しました。

  1. 適切なサーバーとOSを選択し、ハードウェア要件やネットワーク、ファイアウォール、DNSなどの事前準備を行いました。
  2. システムにGitLabリポジトリを追加し、Omnibusパッケージをインストールしました。
  3. /etc/gitlab/gitlab.rb ファイルを編集して、必須のexternal_url を設定し、gitlab-ctl reconfigure コマンドでGitLabを初期設定・起動しました。
  4. ウェブブラウザからGitLabに初回アクセスし、管理者パスワードを設定してログインしました。
  5. Let’s Encryptを利用してHTTPS (SSL/TLS) を設定し、通信をセキュアにしました。
  6. gitlab-ctl コマンドによるサービス制御、ログの確認、バックアップ、アップデートといった基本的な運用方法について学びました。
  7. 遭遇しうるトラブルシューティングのヒントを得ました。

Omnibusパッケージは、複雑な依存関係やコンポーネントの設定を抽象化してくれるため、GitLab環境を比較的容易に構築できる強力なツールです。しかし、サーバー環境やネットワーク構成は千差万別であり、予想外の問題が発生することもあり得ます。問題に直面した際は、エラーメッセージをよく読み、ログファイルを丁寧に確認することが解決への近道です。

GitLabは非常に多機能なプラットフォームであり、その全てを使いこなすには時間がかかるかもしれません。まずはインストールした環境で、プロジェクトの作成、リポジトリの利用、簡単なCI/CDの試行など、基本的な機能から使い始めてみてください。GitLabを社内の開発ワークフローに組み込むことで、チームの生産性向上とDevOps文化の醸成に大きく貢献できるはずです。

このガイドが、あなたのGitLab導入の助けとなり、素晴らしいDevOpsジャーニーの一歩となることを願っています。

コメントする

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

上部へスクロール