はい、承知いたしました。GitLabをOmnibus Packageを用いてLinuxサーバーにインストールする完全ガイドとして、詳細な説明を含む記事を作成します。約5000語を目指し、前提条件からインストール後の管理、トラブルシューティングまで網羅的に解説します。

GitLabをインストールする完全ガイド：Omnibus Packageによる詳細解説

はじめに

ソフトウェア開発において、バージョン管理システムはプロジェクト管理、共同作業、デプロイメントパイプラインの構築において不可欠なツールです。中でもGitLabは、単なるGitリポジトリホスティングにとどまらず、CI/CD、Issue Tracking、Wiki、Container Registryなど、ソフトウェア開発ライフサイクル全体をカバーするDevOpsプラットフォームとして広く利用されています。

GitLabには、SaaS版であるGitLab.comと、ご自身のサーバーにインストールして利用するセルフホスト版があります。セルフホスト版を導入することで、データの完全な制御、カスタマイズ性、そして独自のセキュリティポリシー適用が可能になります。

この記事では、セルフホスト版GitLabの最も一般的なインストール方法であるOmnibus Packageを利用したインストール手順について、詳細かつ網羅的に解説します。約5000語にわたる解説を通じて、GitLabの導入を成功させ、円滑な運用を開始するための知識を提供します。

GitLabのインストール方法の概要

GitLabセルフホスト版には、いくつかのインストール方法があります。それぞれにメリットとデメリットがあり、用途や環境によって適切な方法を選択する必要があります。

Omnibus Package (推奨)
- GitLabとその実行に必要な全てのコンポーネント（Nginx, PostgreSQL, Redis, Sidekiq, Gitalyなど）が一つにまとめられたパッケージです。
- 利点: インストールが最も容易で、依存関係の管理が不要です。設定は単一の設定ファイル (gitlab.rb) で行い、アップデートも簡単です。ほとんどのユーザーにとって最適な方法です。
- 欠点: コンポーネントのカスタマイズ性が低い場合があります。
Source Installation (ソースコードからのインストール)
- GitLabのソースコードをダウンロードし、手動でコンパイル・設定する方法です。
- 利点: 非常に高いカスタマイズ性があります。
- 欠点: インストールと設定が非常に複雑で、依存関係の管理、コンパイル、各コンポーネントの設定などを全て手動で行う必要があります。一般的には推奨されません。
Docker Container
- Dockerイメージとして提供されるGitLabを利用する方法です。
- 利点: 環境構築が迅速で、可搬性（移植性）が高いです。依存関係がコンテナ内に隔離されます。
- 欠点: Dockerの知識が必要です。永続化ストレージや設定管理に考慮が必要です。
Kubernetes (Helm Chart)
- Kubernetesクラスター上にGitLabをデプロイする方法です。Helm Chartが提供されています。
- 利点: 高い可用性、スケーラビリティ、運用自動化が可能です。
- 欠点: Kubernetesの知識とクラスター環境が必要です。Omnibusと比較して複雑な構成になります。大規模な環境や高可用性が求められる場合に適しています。
Cloud Provider Marketplaces
- AWS, GCP, Azureなどのクラウドプロバイダーが提供するマーケットプレイスのイメージを利用する方法です。
- 利点: 事前設定されたイメージを利用できるため、迅速にデプロイできます。
- 欠点: クラウドプロバイダーに依存します。カスタマイズの自由度が制限される場合があります。

この記事では、最も一般的で推奨されるOmnibus Packageによるインストール方法に焦点を当て、詳細に解説します。

Omnibus Packageによるインストール

Omnibus Packageは、GitLabを構成する全てのサービス（Webサーバー、データベース、キャッシュサーバー、Gitサーバープロセスなど）を単一のパッケージにまとめ、インストールと管理を容易にするために設計されています。ChefのCookbooksを使用して、インストール、設定、起動、管理を行います。

なぜOmnibus Packageが推奨されるのか？

手軽さ: 数コマンドを実行するだけで、GitLabとその依存関係がすべてインストールされます。
依存関係の解決: 必要なソフトウェア（Ruby, Go, PostgreSQL, Redis, Nginxなど）がパッケージに含まれているため、手動でインストールしたりバージョン競合を解決したりする必要がありません。
容易な設定: ほとんどの設定は /etc/gitlab/gitlab.rb という単一のファイルで行い、gitlab-ctl reconfigure コマンドで適用できます。
容易なアップデート: パッケージマネージャー（aptやyum）を使用して簡単にアップデートできます。

前提条件 (Prerequisites)

GitLab Omnibus Packageをインストールする前に、サーバーが以下の要件を満たしていることを確認してください。

1. オペレーティングシステム (OS)

GitLab Omnibus Packageは、以下の主要なLinuxディストリビューションの特定のバージョンをサポートしています。インストールを開始する前に、ご使用のOSがサポートされているか確認してください。

Ubuntu (LTSバージョン推奨: 20.04, 22.04)
Debian (Stableバージョン推奨: 11, 12)
CentOS/RHEL/Rocky Linux/AlmaLinux (8, 9)
openSUSE Leap (15.x)

注意: サポートされているOSバージョンは変更される可能性があります。常に公式ドキュメントの最新情報を確認してください。この記事ではUbuntu 22.04またはCentOS Stream 9を想定して手順を記述します。

2. ハードウェア要件

GitLabのハードウェア要件は、利用するユーザー数や負荷によって大きく異なります。以下は、最低限および推奨される要件の目安です。これらはGitLab Community Edition (CE) および Enterprise Edition (EE) の基本的な要件であり、CI/CDの使用状況などによってはさらにリソースが必要になります。

リソース	最小要件 (最大100ユーザー)	推奨要件 (最大500ユーザー)	大規模環境 (500+ユーザー)
CPU	4コア	8コア	16+コア
RAM	8 GB	16 GB	32+ GB
ストレージ	50 GB (SSD推奨)	100 GB (SSD必須)	250+ GB (SSD必須)

CPU: GitLabは多くのプロセス（Webサーバー、Sidekiqワーカー、Gitalyなど）を実行するため、複数のコアを持つCPUが推奨されます。
RAM: GitLabはメモリを比較的多く消費します。特にデータベース（PostgreSQL）とSidekiq（バックグラウンド処理）に十分なメモリが必要です。Swap領域も確保することを強く推奨します。RAMが不足するとパフォーマンスが著しく低下します。
ストレージ: リポジトリデータ、データベースデータ、ログなどが保存されます。高速なSSDが必須です。ユーザー数やリポジトリサイズが増えると、ストレージ容量も比例して増大します。将来の拡張も考慮して余裕を持った容量を確保してください。IOPS性能も重要です。

3. ネットワーク要件

GitLabサーバーにアクセスするためには、特定のポートを開放する必要があります。

ポート 22 (SSH): GitリポジトリへのSSHアクセス、およびサーバー管理に必要です。
ポート 80 (HTTP): 初期設定時やHTTPSリダイレクトに使用されます。最終的にはポート443にリダイレクトするのが一般的です。
ポート 443 (HTTPS): ウェブUIへのセキュアなアクセスに使用されます。

これらのポートがサーバーのファイアウォール（ufw, firewalld, iptablesなど）やネットワークファイアウォール（セキュリティグループなど）で許可されていることを確認してください。

4. ドメイン名とDNS設定 (推奨)

GitLabインスタンスにアクセスするためのドメイン名を設定することを強く推奨します（例: gitlab.yourcompany.com）。このドメイン名をGitLabサーバーのパブリックIPアドレスまたはプライベートIPアドレス（内部ネットワークの場合）に解決できるようにDNSレコード（Aレコード）を設定してください。

ドメイン名を設定することで、HTTPS（SSL/TLS）を簡単に有効化でき、セキュリティを向上させることができます。

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

サーバー上で稼働しているファイアウォール（ufw, firewalldなど）で、必要なポート（22, 80, 443）が外部からの接続に対して許可されていることを確認してください。

Ubuntu (ufwの例):

bash sudo ufw allow OpenSSH sudo ufw allow http sudo ufw allow https sudo ufw enable sudo ufw status

CentOS/RHEL/Rocky/AlmaLinux (firewalldの例):

bash sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reload sudo firewall-cmd --list-all

6. SELinux / AppArmor

SELinux (CentOS/RHEL系) や AppArmor (Ubuntu系) のセキュリティ強化機能が有効になっている場合、GitLabの正常な動作を妨げる可能性があります。GitLab Omnibus PackageはSELinuxポリシーを同梱しており、自動的に適切なポリシーを設定しようとしますが、環境によっては手動での調整が必要になる場合があります。

一時的にSELinuxをPermissiveモードにする (sudo setenforce 0) か、完全に無効化する (/etc/selinux/config を編集して SELINUX=disabled に設定し、再起動) こともトラブルシューティングとして行われますが、セキュリティリスクを高めるため、可能な限りSELinuxを有効にしたまま適切なポリシーを適用することが推奨されます。GitLabのインストールスクリプトがポリシーの設定を試みます。

ステップバイステップインストール手順 (Omnibus Package)

ここからは、具体的なインストール手順を解説します。ここではUbuntu 22.04 LTSを例に進めますが、他の対応OSでもコマンドが若干異なるだけで基本的な流れは同じです。CentOS/RHEL/Rocky/AlmaLinux系の場合の注意点も適宜補足します。

ステップ 1: OSの準備とアップデート

まず、サーバーのパッケージリストを更新し、既存のパッケージを最新の状態にアップグレードします。また、GitLabのインストールに必要な基本的なツール（curl, policycoreutils-python-utils – SELinux関連, ca-certificates など）をインストールします。

Ubuntu/Debianの場合:

“`bash
sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates apt-transport-https lsb-release gnupg2

SELinuxを使用している場合はpolicycoreutilsも必要ですが、Ubuntu/DebianではAppArmorが一般的です。

AppArmorの状態は `sudo apparmor_status` で確認できます。必要に応じてルール調整や無効化を検討します。

“`

CentOS/RHEL/Rocky/AlmaLinuxの場合:

“`bash
sudo yum update -y
sudo yum install -y curl policycoreutils-python-utils openssh-server

SELinuxの状態は `getenforce` で確認できます。有効(Enforcing)またはPermissiveであることを確認します。

policycoreutils-python-utils は SELinux ポリシー管理ツールに含まれます。

“`

ステップ 2: GitLabリポジトリの追加

GitLabのパッケージは標準のOSリポジトリには含まれていません。GitLab公式リポジトリを追加する必要があります。GitLabは各OSディストリビューションとバージョンに合わせたリポジトリ設定スクリプトを提供しています。

以下のコマンドを実行して、GitLab公式リポジトリを追加します。このスクリプトは、OSを自動的に判別し、適切なリポジトリ設定ファイルを作成し、リポジトリのGPGキーをインポートします。

Ubuntu/Debianの場合:

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

Community Edition (CE) をインストールする場合は以下のコマンドを実行します。

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

“`

CentOS/RHEL/Rocky/AlmaLinuxの場合:

“`bash
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash

Community Edition (CE) をインストールする場合は以下のコマンドを実行します。

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

“`

補足:

gitlab-ee はEnterprise Editionのリポジトリです。無償で利用開始でき、一部のEE機能が含まれていますが、ライセンスが必要な機能は無効になっています。ライセンスを適用することでEEの全機能が利用可能になります。
gitlab-ce はCommunity Editionのリポジトリです。完全に無償で利用できますが、EEの一部の高度な機能（例: グループ単位でのSAML SSO、高度なCI/CD機能など）は含まれていません。
ほとんどの場合、gitlab-ee をインストールしておき、必要に応じてライセンスを適用するのが推奨されます。機能比較は公式ウェブサイトをご確認ください。
sudo bash を使用してスクリプトを実行することで、管理者権限でリポジトリ設定が行われます。スクリプトの内容を確認したい場合は、| sudo bash の部分を除いて実行し、標準出力で確認できます。

スクリプトが完了すると、/etc/apt/sources.list.d/gitlab_gitlab-ee.list (Ubuntu/Debian) や /etc/yum.repos.d/gitlab_gitlab-ee.repo (CentOS/RHEL系) のようなファイルが作成され、GitLabリポジトリがシステムに認識されます。

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

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

Ubuntu/Debianの場合:

まず、新しいリポジトリのパッケージリストを更新します。

bash sudo apt update

次に、GitLabパッケージをインストールします。

“`bash
sudo apt install gitlab-ee

または Community Edition: sudo apt install gitlab-ce

“`

CentOS/RHEL/Rocky/AlmaLinuxの場合:

まず、新しいリポジトリのキャッシュを更新します。

bash sudo yum makecache

次に、GitLabパッケージをインストールします。

“`bash
sudo yum install gitlab-ee

または Community Edition: sudo yum install gitlab-ce

“`

パッケージマネージャーが依存関係を解決し、GitLabとその関連コンポーネント（Nginx, PostgreSQL, Redis, Gitalyなど）をインストールします。これには時間がかかる場合があります。

ステップ 4: GitLabの初期設定 (gitlab.rb)

GitLabのインストールが完了しても、すぐにアクセスできるわけではありません。初期設定を行う必要があります。設定は /etc/gitlab/gitlab.rb ファイルを編集して行います。これはGitLab Omnibus Packageの主要な設定ファイルです。

このファイルを編集する前に、バックアップを作成しておくことをお勧めします。

bash sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak

nanoやviなどのテキストエディタで /etc/gitlab/gitlab.rb を開きます。

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

または sudo vi /etc/gitlab/gitlab.rb

“`

ファイル内には多くの設定項目がありますが、最初は以下の項目を主に編集します。コメントアウト (#) されている行を解除し、値を変更します。

external_url (必須): GitLabインスタンスにアクセスするためのURLを設定します。これは最も重要な設定項目です。ドメイン名を使用する場合は、'http://gitlab.yourcompany.com' または 'https://gitlab.yourcompany.com' の形式で指定します。IPアドレスを使用する場合は 'http://your_server_ip' または 'https://your_server_ip' と指定します。末尾にスラッシュ (/) は不要です。

ruby external_url 'https://gitlab.yourcompany.com'

注意: HTTPSを使用する場合は、external_url を https://... で始める必要があります。後述のHTTPS設定を併せて行ってください。
HTTPS設定 (強く推奨): ウェブUIへのアクセスをセキュアにするため、HTTPSを有効化します。Omnibus PackageはLet’s Encryptによる無料SSL証明書の自動取得と更新をサポートしています。

Let’s Encrypt を使用する場合 (推奨):
external_url を https://your.domain.com の形式で設定し、以下の行のコメントアウトを解除し、true に設定します。

ruby letsencrypt['enable'] = true letsencrypt['auto_renew'] = true

Let’s Encryptを使用するには、GitLabサーバーがポート80および443でインターネットからアクセス可能であり、external_url で指定したドメイン名がサーバーのIPアドレスに正しく解決されている必要があります。

独自のSSL証明書を使用する場合:
external_url を https://your.domain.com の形式で設定し、証明書ファイル (.crt/.pem) と秘密鍵ファイル (.key) をサーバー上に配置します（例: /etc/gitlab/ssl/). 次に、以下の行のコメントアウトを解除し、ファイルパスを指定します。

“`ruby
nginx[‘ssl_certificate’] = “/etc/gitlab/ssl/gitlab.yourcompany.com.crt”
nginx[‘ssl_certificate_key’] = “/etc/gitlab/ssl/gitlab.yourcompany.com.key”

Nginxリスニングポートが競合する場合などに変更

nginx[‘listen_port’] = 443

nginx[‘listen_https’] = true

“`

証明書と秘密鍵ファイルのパーミッションがGitLabを動作させるユーザー（通常はgitユーザー）から読み取り可能になっているか確認してください。推奨されるパーミッションは 600 です。

bash sudo mkdir -p /etc/gitlab/ssl sudo chmod 700 /etc/gitlab/ssl sudo cp your_certificate.crt /etc/gitlab/ssl/gitlab.yourcompany.com.crt sudo cp your_private_key.key /etc/gitlab/ssl/gitlab.yourcompany.com.key sudo chmod 600 /etc/gitlab/ssl/*
HTTPからHTTPSへのリダイレクト (推奨): HTTP (ポート 80) へのアクセスを自動的にHTTPS (ポート 443) へリダイレクトするように設定します。external_url が https:// で始まっている場合、デフォルトで有効になりますが、明示的に設定する場合は以下を確認します。

ruby nginx['redirect_http_to_https'] = true
SSHポート (デフォルトは22): SSHプロトコルによるGitクローン/プッシュに使用されるポートです。デフォルトは22ですが、変更する場合は設定します。ポート22を使用する場合、通常はOS標準のSSHデーモンがポートをListenしています。GitLabはSSHリクエストを処理するために内部でポートをListenし、OS標準のSSHデーモンがそのポートに転送する必要があります。Omnibus Packageはその設定を自動で行います。

“`ruby

ssh_host を external_url と同じドメイン名にするのが一般的

gitlab_rails[‘gitlab_ssh_host’] = ‘gitlab.yourcompany.com’
gitlab_rails[‘gitlab_shell_ssh_port’] = 22 # OS標準のSSHポート
“`

もしOS標準のSSHデーモンを別のポート（例: 2222）で実行し、GitLab SSHをポート22で実行したい場合は、OSのSSH設定を変更し、GitLab側で以下の設定を行います。

“`ruby

OS標準のSSHデーモンはポート 2222 で起動

GitLab SSHをポート 22 で起動

gitlab_rails[‘gitlab_ssh_host’] = ‘gitlab.yourcompany.com’
gitlab_rails[‘gitlab_shell_ssh_port’] = 22 # GitLabがListenするポート

Nginxはポート 80/443, GitLab SSHはポート 22 をListenするようになる

ポート 22 が他のサービスに使用されていないか確認が必要です

`` 通常はgitlab_rails[‘gitlab_shell_ssh_port’]は OS標準のSSHポートと同じにしておき、アクセスURLとしてSSHクローンURLに表示されるホスト名をgitlab_rails[‘gitlab_ssh_host’]` で指定します。
SMTP設定 (メール通知のため): GitLabからのメール通知（新しいIssue、コメント、パスワードリセットなど）を送信するために、SMTPサーバーの設定が必要です。

“`ruby
gitlab_rails[‘smtp_enable’] = true
gitlab_rails[‘smtp_address’] = “smtp.example.com”
gitlab_rails[‘smtp_port’] = 587
gitlab_rails[‘smtp_user_name’] = “[email protected]”
gitlab_rails[‘smtp_password’] = “password”
gitlab_rails[‘smtp_domain’] = “example.com”
gitlab_rails[‘smtp_authentication’] = “login” # または “plain”, “cram_md5”
gitlab_rails[‘smtp_enable_starttls_auto’] = true
gitlab_rails[‘smtp_tls’] = false # smtp_port が 465 の場合は true にすることが多い
gitlab_rails[‘smtp_pool’] = false

“from” メールアドレス

gitlab_rails[‘gitlab_email_from’] = ‘[email protected]’
gitlab_rails[‘gitlab_email_display_name’] = ‘GitLab’
“`

これらの設定をSMTPプロバイダーの情報に合わせて変更してください。認証方法 (smtp_authentication) やTLS (smtp_tls, smtp_enable_starttls_auto) の設定は重要です。
メモリ設定: サーバーのリソースに合わせて、各コンポーネントが使用するメモリ量を調整できます。特にメモリ使用量が多いUnicorn (またはPuma) とSidekiqの設定を確認します。

“`ruby

Unicorn worker 数 (デフォルトは CPU コア数 + 1)。メモリに応じて調整

gitlab_rails[‘unicorn_workers’] = 4

Puma 設定 (最近のバージョンでデフォルト)

gitlab_rails[‘puma_workers’] = 4

gitlab_rails[‘puma_threads’] = 4

Sidekiq concurrency (デフォルトは 25)。メモリに応じて調整

gitlab_rails[‘sidekiq_concurrency’] = 10

“`
デフォルト設定は多くの環境で動作しますが、メモリが少ない環境ではUnicorn/PumaワーカーやSidekiqコンカレンシーを減らすことでメモリ消費を抑えられます。メモリが十分にある場合は増やすことで並列処理能力を高められます。

他にも様々な設定項目がありますが、まずは上記の項目を設定すれば最低限GitLabを動作させることができます。必要に応じて公式ドキュメントを参照し、他の設定（LDAP認証、OmniAuth、バックアップ設定など）を検討してください。

設定ファイルを編集したら保存して閉じます。

ステップ 5: 設定の再構成 (Reconfigure)

/etc/gitlab/gitlab.rb ファイルを変更したら、その設定をGitLabに適用するために再構成コマンドを実行する必要があります。

bash sudo gitlab-ctl reconfigure

このコマンドは以下の処理を行います。

/etc/gitlab/gitlab.rb ファイルを読み込みます。
Chef Cookbooks を実行し、その設定に基づいて各コンポーネントの設定ファイル（Nginx, PostgreSQL, Redisなど）を生成または更新します。
PostgreSQLデータベースの初期化（初回インストール時）やマイグレーションを行います。
各GitLabサービスの起動、停止、再起動などを行い、新しい設定を適用します。

gitlab-ctl reconfigure コマンドは時間がかかる場合があります。コマンド実行中には、Chefの実行ログが表示されます。特に初回実行時はデータベースの初期化やスキーマ作成が行われるため、時間がかかります。

エラーが発生した場合:

gitlab-ctl reconfigure の実行中にエラーが発生した場合、エラーメッセージが表示されます。エラーの詳細は /var/log/gitlab/reconfigure/ ディレクトリ内のログファイルを確認することで把握できます。

よくある原因としては、gitlab.rb の設定ミス（シンタックスエラーなど）、サーバーのリソース不足、必要なポートがブロックされている、SELinux/AppArmorによる制限などが挙げられます。エラーメッセージやログを確認し、原因を取り除いてから再度 sudo gitlab-ctl reconfigure を実行してください。

ステップ 6: ファイアウォールとSELinuxの調整 (必要に応じて)

既にステップ2でファイアウォール設定を説明しましたが、gitlab-ctl reconfigure の実行後に改めて確認または調整が必要になる場合があります。

ファイアウォール: ポート80 (HTTP) および 443 (HTTPS) が外部からアクセス可能になっていることを確認してください。SSHアクセス (ポート 22) も必要であれば確認します。
SELinux: gitlab-ctl reconfigure は適切なSELinuxポリシーを設定しようとしますが、環境によっては完全でない場合があります。SELinuxが原因でGitLabのコンポーネントが正常に動作しない場合、ログファイル /var/log/audit/audit.log や /var/log/messages に関連するエラー（AVC denialsなど）が出力されます。これらのログを確認し、必要に応じてポリシーを修正するか、一時的にPermissiveモードにして問題が解決するか確認します。永続的なポリシー修正には semanage や audit2allow などのツールを使用します。SELinuxを完全に無効化することは推奨されませんが、トラブルシューティングの最終手段として考慮されることがあります。

ステップ 7: 初期ログインと管理者パスワードの設定

gitlab-ctl reconfigure がエラーなく完了したら、GitLabインスタンスにウェブブラウザからアクセスできるようになります。external_url で設定したURLを開いてください。

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

ブラウザで external_url (例: https://gitlab.yourcompany.com) にアクセスします。
パスワード設定画面が表示されるはずです。
rootユーザーのパスワードを設定し、確認用パスワードを入力して「Change your password」をクリックします。

パスワード設定画面が表示されない場合、rootユーザーの初期パスワードはサーバー上の /etc/gitlab/initial_root_password ファイルに一時的に保存されています（GitLabバージョン14.0以降）。

bash sudo cat /etc/gitlab/initial_root_password

このコマンドを実行すると、ユーザー名 root と生成された初期パスワードが表示されます。ログイン画面でユーザー名 root とこのパスワードを入力してログインしてください。ログイン後、すぐにパスワードを変更することを強く推奨します。このファイルは初回ログインまたは gitlab-ctl reconfigure 後24時間で自動的に削除されます。

ログイン後、rootユーザーのプロフィール設定画面にリダイレクトされる場合があります。ここで名前やメールアドレスなどを設定できます。

これで、GitLabの基本的なインストールと初期設定が完了しました。ユーザーを作成したり、プロジェクトをインポート/作成したり、CI/CDパイプラインを設定したりと、GitLabの利用を開始できます。

Omnibus Package インストール後の管理

GitLabサーバーを安定して運用するためには、インストール後の適切な管理が必要です。

サービスの管理

Omnibus PackageでインストールされたGitLabの各サービス（nginx, unicorn/puma, sidekiq, postgresql, redis, gitalyなど）は、gitlab-ctl コマンドで管理できます。

サービスの状態確認:
bash sudo gitlab-ctl status
これにより、各サービスが実行中か停止しているかを確認できます。
全サービスの起動:
bash sudo gitlab-ctl start
全サービスの停止:
bash sudo gitlab-ctl stop
全サービスの再起動:
bash sudo gitlab-ctl restart
特定のサービスの再起動:
bash sudo gitlab-ctl restart nginx sudo gitlab-ctl restart unicorn # または puma

設定の変更と再構成

インストール後に設定を変更する場合（例: SMTP設定の変更、メモリ設定の調整、新しい機能の有効化など）は、以下の手順で行います。

/etc/gitlab/gitlab.rb ファイルを編集します。
変更内容を保存します。
sudo gitlab-ctl reconfigure コマンドを実行して設定を適用します。

reconfigure は、GitLabが依存する全てのコンポーネントの設定ファイルを再生成し、必要に応じてサービスを再起動するため、設定変更を反映させるための標準的な方法です。

ログの確認

GitLabの動作に問題が発生した場合や、サーバーの状態を監視したい場合は、ログファイルを確認することが重要です。Omnibus PackageでインストールされたGitLabのログは、主に /var/log/gitlab/ ディレクトリ以下に保存されています。

/var/log/gitlab/nginx/: Nginx (Webサーバー) のアクセスログとエラーログ
/var/log/gitlab/unicorn/: Unicorn (Rubyアプリケーションサーバー) のログ (バージョンによっては puma/)
/var/log/gitlab/sidekiq/: Sidekiq (バックグラウンドジョブ処理) のログ
/var/log/gitlab/postgresql/: PostgreSQL (データベース) のログ
/var/log/gitlab/redis/: Redis (キャッシュ、キュー) のログ
/var/log/gitlab/gitaly/: Gitaly (Git RPCサービス) のログ
/var/log/gitlab/reconfigure/: gitlab-ctl reconfigure の実行ログ
/var/log/gitlab/sshd/: GitLab ShellのSSHデーモンログ

ログファイルは通常、current というシンボリックリンクが現在のログファイルを示しており、古いログはローテーションされてタイムスタンプ付きのファイル名で保存されます。

リアルタイムでログを監視するには、gitlab-ctl tail コマンドが便利です。

全サービスのログをリアルタイム表示:
bash sudo gitlab-ctl tail
特定のサービスのログをリアルタイム表示:
bash sudo gitlab-ctl tail unicorn # または puma sudo gitlab-ctl tail sidekiq

バックアップと復元

GitLabのデータ（リポジトリ、データベース、添付ファイル、CI/CDジョブログなど）は非常に重要です。定期的なバックアップは必須です。Omnibus Packageにはバックアップ/復元ツールが同梱されています。

バックアップの作成:

バックアップは gitlab-rake コマンドを使用して作成します。

bash sudo gitlab-rake gitlab:backup:create

このコマンドは、/var/opt/gitlab/backups/ ディレクトリにタイムスタンプ付きの .tar ファイルを作成します。このファイルには、GitLabの全てのデータ（リポジトリ、データベース、その他設定）が含まれています。

バックアップファイルの保存場所:

デフォルトでは /var/opt/gitlab/backups/ に保存されます。これは /etc/gitlab/gitlab.rb の gitlab_rails['backup_path'] で変更できます。このディレクトリはGitLabが書き込み可能である必要があります。セキュリティのため、このディレクトリはGitLabサーバー以外の安全な場所に定期的にコピーすることを強く推奨します。

自動バックアップの設定:

定期的にバックアップを作成するには、cronなどのスケジューラーを使用します。例えば、毎日午前2時にバックアップを作成するcrontabエントリは以下のようになります。

“`crontab

crontab -e で編集

0 2 * * * sudo /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1
``CRON=1` は、cronジョブであることを示し、一部のインタラクティブな出力を抑制します。

復元:

バックアップからGitLabを復元するには、以下の手順で行います（新しいサーバーに復元する場合を想定）。

新しいサーバーにGitLab Omnibus Packageをインストールしますが、まだ gitlab-ctl reconfigure は実行しないでください。
GitLabサービスを停止します。
bash sudo gitlab-ctl stop unicorn sudo gitlab-ctl stop puma # GitLab 14.0 以降のデフォルト sudo gitlab-ctl stop sidekiq
Gitリポジトリ関連のプロセスも停止するため、gitlab-shell と gitaly も停止します。
bash sudo gitlab-ctl stop gitlab-shell sudo gitlab-ctl stop gitaly
復元したいバックアップファイル ([TIMESTAMP]_gitlab_backup.tar) を /var/opt/gitlab/backups/ ディレクトリに配置します。
バックアップファイル名からタイムスタンプ部分を取得します（例: 1678886400_2023_03_15_15.1.2 のような形式）。
復元コマンドを実行します。タイムスタンプを指定します。
bash sudo gitlab-rake gitlab:backup:restore BACKUP=1678886400_2023_03_15_15.1.2
警告が表示されたら yes と入力して続行します。
復元が完了したら、GitLabのパーミッションを再設定します。
bash sudo gitlab-ctl reconfigure
これにより、ファイルシステム上の権限や設定がGitLabに合わせて調整されます。
GitLabサービスを起動し、正しく動作するか確認します。
bash sudo gitlab-ctl start sudo gitlab-ctl status
ウェブUIにアクセスして、リポジトリやプロジェクトデータが正しく復元されているか確認してください。

注意:
* バックアップを作成したGitLabのバージョンと、復元先のGitLabのバージョンは一致している必要があります。異なるバージョン間で復元する場合は、まず古いバージョンをインストールして復元し、その後GitLabを段階的にアップデートしていく必要があります。
* バックアップには gitlab.rb ファイルは含まれません。設定ファイルは手動でバックアップ・復元する必要があります。

アップデート

GitLabは頻繁にアップデートされます。セキュリティの向上や新機能の利用のために、定期的にアップデートを行うことが推奨されます。Omnibus Packageのアップデートは、OSのパッケージマネージャーを使用して簡単に行えます。

アップデート手順:

現在のバージョンの確認: アップデート前に現在のバージョンを確認しておくと良いでしょう。
bash sudo dpkg -l gitlab-ee # Ubuntu/Debian sudo yum list installed gitlab-ee # CentOS/RHEL系
または、GitLabウェブUIのHelpメニューから確認できます。
OSパッケージリストの更新:
bash sudo apt update # Ubuntu/Debian sudo yum makecache # CentOS/RHEL系
GitLabパッケージのアップデート:
bash sudo apt install gitlab-ee # Ubuntu/Debian sudo yum update gitlab-ee # CentOS/RHEL系
または、CEの場合は gitlab-ce を指定します。
パッケージマネージャーがGitLabの新しいバージョンをダウンロードし、インストールします。この際、自動的に gitlab-ctl reconfigure が実行され、データベースマイグレーションやサービス再起動が行われます。
アップデート後の確認: sudo gitlab-ctl status でサービスが正常に起動していることを確認し、ウェブUIにアクセスして動作を確認します。

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

GitLabは、X.Y.Zのバージョン体系を取っており、Xがメジャーバージョン、Yがマイナーバージョン、Zがパッチバージョンです。
* マイナーバージョンアップ (例: 15.1.x -> 15.2.x) やパッチバージョンアップ (例: 15.1.0 -> 15.1.2) は通常、上記の手順で直接アップデートできます。
* メジャーバージョンアップ (例: 14.x -> 15.x) は、複数ステップでのアップデートが必要になる場合があります。 通常、N-1アップグレードというルールが適用されます。つまり、現在のバージョンから一つ前のメジャーバージョンにしか直接アップデートできません。例えば、GitLab 14.0 から 15.0 にアップデートしたい場合、まず GitLab 14.x (最新のマイナーバージョン) にアップデートし、次に GitLab 15.0 にアップデートするという手順が必要です。詳細は公式ドキュメントのアップグレードパスを確認してください。
* メジャーバージョンアップには、時間がかかり、データベーススキーマの大きな変更が含まれる場合があります。必ず事前にバックアップを取得し、メンテナンス期間を設けて実施することを強く推奨します。

その他のインストール方法の概要 (簡易版)

この記事ではOmnibus Packageに焦点を当てましたが、他の方法についても簡単に触れておきます。

Dockerコンテナ

GitLabは公式のDockerイメージを提供しています。Dockerがインストールされている環境であれば、イメージをプルしてコンテナとして実行できます。

基本的な実行例:

bash sudo docker run --detach \ --hostname gitlab.yourcompany.com \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab \ --restart always \ --volume $GITLAB_HOME/config:/etc/gitlab \ --volume $GITLAB_HOME/logs:/var/log/gitlab \ --volume $GITLAB_HOME/data:/var/opt/gitlab \ gitlab/gitlab-ee:latest # または gitlab/gitlab-ce:latest

--hostname: コンテナのホスト名、external_url に使用されます。
--publish: ポートマッピング。ホスト側のポートとコンテナ側のポートを関連付けます。
--name: コンテナ名。
--restart always: Dockerデーモン起動時にコンテナを自動起動します。
--volume: 永続化ストレージのマウント。GitLabの設定、ログ、データをコンテナ外部のホストストレージに保存するために必須です。$GITLAB_HOME はホスト上のディレクトリパスです。
イメージ名: gitlab/gitlab-ee:latest または gitlab/gitlab-ce:latest。latest タグは最新版ですが、特定のバージョンを指定することも可能です (gitlab/gitlab-ee:15.10.0-ee.0)。

利点: 環境構築が迅速、環境間の差異が少ない、特定のGitLabバージョンを固定しやすい。
考慮事項: Dockerやコンテナオーケストレーションの知識が必要、永続化ストレージの設定が重要、コンテナのリソース制限を適切に行う必要あり、Docker Composeを使うと設定が容易になります。

Kubernetes (Helm Chart)

Kubernetesクラスター上にGitLabをデプロイするための公式Helm Chartが提供されています。複雑な構成ですが、Kubernetesの利点（スケーラビリティ、高可用性、自動復旧など）を最大限に活かせます。

基本的な手順:

Kubernetesクラスター（例: GKE, EKS, AKS, OpenShift, kops, kubeadmなど）を準備します。
Helmをインストールします。
GitLab Helmリポジトリを追加します。
bash helm repo add gitlab https://charts.gitlab.io/ helm repo update
Helm Chartをインストールします。この際に、values.yaml ファイルを編集して各種設定を行います（例: Ingress設定、PersistentVolumeClaim設定、外部サービスの利用など）。
bash helm upgrade --install gitlab gitlab/gitlab \ --namespace gitlab \ --create-namespace \ -f values.yaml \ --timeout 600s

利点: 高度なスケーラビリティと可用性、Kubernetesエコシステムとの統合。
考慮事項: 導入・運用が最も複雑、KubernetesとHelmの深い知識が必要、リソース要件が高い、外部依存サービス（オブジェクトストレージ、外部データベースなど）の利用が一般的。

一般的なトラブルシューティング

GitLabのインストールや運用中に発生しうる一般的な問題とその対処法について説明します。

`gitlab-ctl reconfigure` のエラー

問題: sudo gitlab-ctl reconfigure の実行中にエラーが発生し、完了しない。
原因: 設定ファイル (/etc/gitlab/gitlab.rb) の構文エラー、サーバーリソース不足、ポートの競合、ファイルシステム権限の問題、SELinux/AppArmorによる制限、外部サービスへの接続失敗（SMTPサーバーなど）。
対処法:
1. エラーメッセージの確認: コマンド出力の最後に表示されるエラーメッセージを注意深く読む。
2. ログファイルの確認: /var/log/gitlab/reconfigure/ ディレクトリ内の最新のログファイルを確認する。Chef実行のどのステップで失敗したか、具体的なエラー内容が記録されている。
3. gitlab.rb の構文チェック: 設定ファイルの記述ミスがないか確認する。YAMLやRubyのシンタックスエラーが原因の場合がある。
4. サーバーリソースの確認: top, free -m, df -h などでCPU, メモリ, ディスク容量に余裕があるか確認する。リソース不足の場合はサーバーをスケールアップする。
5. ファイルシステム権限: GitLabのデータディレクトリ (/var/opt/gitlab/) や設定ディレクトリ (/etc/gitlab/) の権限が正しく設定されているか確認する。通常、reconfigure コマンドが適切に設定しますが、手動での変更や外部からの操作があった場合に問題となることがある。
6. SELinux/AppArmor: SELinuxがEnforcingモードの場合は、/var/log/audit/audit.log を確認し、AVC denial エラーが出ていないか確認する。関連するポリシーを追加するか、一時的にPermissiveモードにして再試行する。AppArmorの場合も同様にログを確認する。
7. 外部接続: SMTPなど外部サービスへの接続設定を行っている場合、ネットワークの問題や設定ミスがないか確認する。telnetコマンドなどで疎通確認を行うことも有効。

ウェブUIにアクセスできない (HTTP 500エラー, Connection Refusedなど)

問題: ブラウザでGitLabのURLにアクセスしてもページが表示されない、エラーになる。
原因: GitLabサービスが起動していない、ファイアウォールでポートがブロックされている、Nginxの設定ミス、external_url の設定ミス、GitLab Railsアプリケーションのエラー。
対処法:
1. サービス状態の確認: sudo gitlab-ctl status を実行し、必要なサービス（nginx, unicorn/puma, sidekiq, gitalyなど）が全て run 状態になっているか確認する。停止しているサービスがあれば、sudo gitlab-ctl start <service-name> で起動してみる。
2. ファイアウォールの確認: サーバーのファイアウォール（ufw, firewalldなど）およびネットワークファイアウォール（セキュリティグループなど）で、ポート80 (HTTP) および 443 (HTTPS) が外部からアクセス可能になっているか確認する。ローカルからの接続 (curl http://localhost や curl https://localhost) ができるか試す。
3. external_url の確認: /etc/gitlab/gitlab.rb で設定した external_url が正しいか、DNSで正しく解決できるか確認する。HTTPSを使用している場合は、https:// で始まっているか確認する。
4. Nginxログの確認: /var/log/gitlab/nginx/ ディレクトリの error.log を確認する。HTTPリクエストがNginxに到達しているか、NginxからGitLab Railsアプリケーションへのプロキシ設定に問題がないかなどがわかる。
5. GitLab Railsログの確認: /var/log/gitlab/unicorn/ (または /var/log/gitlab/puma/) のログを確認する。Rubyアプリケーション内部でエラーが発生していないか確認する。sudo gitlab-ctl tail unicorn でリアルタイムログを確認するのも有効。
6. gitlab-ctl reconfigure の再実行: 最近設定変更を行った場合、設定が正しく適用されていない可能性があるため、再度 sudo gitlab-ctl reconfigure を実行してみる。

Gitプッシュ/クローンができない (SSHまたはHTTPS)

問題: SSHまたはHTTPS経由でリポジトリのクローン、プッシュ、プルができない。
原因:
- SSH: ポート22がブロックされている、SSHキーの設定ミス、GitLab Shellの設定ミス。
- HTTPS: ポート443がブロックされている、Nginxの設定ミス、ユーザー認証情報の問題。
対処法:
1. サービス状態の確認: sudo gitlab-ctl status で gitlab-shell, gitaly (および SSH 経由の場合 sshd ) が実行されているか確認する。
2. ファイアウォールの確認: SSHの場合はポート22、HTTPSの場合はポート443が開放されているか確認する。
3. GitLab設定の確認:
  - SSHの場合: /etc/gitlab/gitlab.rb の gitlab_rails['gitlab_ssh_host'] および gitlab_rails['gitlab_shell_ssh_port'] の設定を確認する。SSHクローンURLに表示されているホスト名とポートが正しいか確認する。
  - HTTPSの場合: /etc/gitlab/gitlab.rb の external_url (HTTPSになっているか) および Nginx 設定を確認する。
4. ユーザー認証情報の確認:
  - SSHの場合: クライアント側のSSHキーがGitLabのユーザー設定に正しく登録されているか確認する。クライアント側で ssh -T [email protected] を実行して接続テストを行う（GitLabのウェルカムメッセージが表示されればSSH接続自体は成功）。
  - HTTPSの場合: ユーザー名とパスワード（またはパーソナルアクセストークン）が正しいか確認する。Git Credential Manager を使用している場合は、キャッシュされた情報が古い可能性がある。
5. ログファイルの確認:
  - SSHの場合: /var/log/gitlab/gitlab-shell/ および /var/log/gitlab/sshd/ (GitLab管理のSSHデーモンを使用している場合) のログを確認する。
  - HTTPSの場合: /var/log/gitlab/nginx/ および /var/log/gitlab/unicorn/ (または puma/) のログを確認する。

メール通知が届かない

問題: GitLabからのメール通知（Issueのメンション、プッシュ通知、パスワードリセットなど）がユーザーに届かない。
原因: SMTP設定ミス、ファイアウォールでSMTPポートがブロックされている、SMTPサーバー側の問題、GitLabバックグラウンド処理 (Sidekiq) の問題。
対処法:
1. SMTP設定の確認: /etc/gitlab/gitlab.rb のSMTP設定 (gitlab_rails['smtp_enable'] や認証情報、ポートなど) が正しいか、SMTPプロバイダーの情報と一致しているか入念に確認する。
2. gitlab-ctl reconfigure の再実行: SMTP設定を変更した場合は、必ず sudo gitlab-ctl reconfigure を実行したか確認する。
3. ファイアウォールの確認: GitLabサーバーからSMTPサーバーへのアウトバウンド接続に必要なポート（25, 465, 587など）がファイアウォールでブロックされていないか確認する。
4. SMTPサーバーへの接続テスト: GitLabサーバー上で telnet smtp.example.com 587 のようにコマンドを実行し、SMTPサーバーに接続できるか確認する。
5. GitLab診断ツールの利用: GitLabには診断ツールがいくつかあります。SSHでサーバーにログインし、sudo gitlab-rake gitlab:check コマンドを実行すると、基本的な設定やサービスの健全性をチェックできます。メール送信関連のエラーが表示されるか確認する。
6. Railsコンソールからのメール送信テスト: より詳細なテストとして、Railsコンソールからテストメールを送信してみる。
  bash sudo gitlab-rails console # コンソール起動後 Notify.deliver_test_email('[email protected]', 'Test Email', 'This is a test email from GitLab.').deliver_now
  エラーが出力されるか確認し、SMTPサーバーのログも確認する。
7. Sidekiqログの確認: メール送信はSidekiqによってバックグラウンドで処理されるため、/var/log/gitlab/sidekiq/ のログを確認し、メール送信に関連するエラーが出ていないか確認する。

パフォーマンス問題 (GitLabが遅い、動作が重い)

問題: GitLabのウェブUIの表示が遅い、Git操作が遅い、CI/CDジョブの実行が遅いなど。
原因: サーバーリソース不足 (CPU, RAM, ディスクIO)、データベースの負荷、Sidekiqキューの滞留、ネットワーク帯域不足、不適切な設定。
対処法:
1. リソース使用状況の監視: top, htop, free -m, iostat, vmstat などのツールで、サーバーのCPU使用率、メモリ使用率、Swap使用率、ディスクI/O負荷を確認する。特にメモリが不足しSwapが多用されている場合は、GitLabのパフォーマンスが著しく低下する。
2. gitlab-ctl top の利用: sudo gitlab-ctl top コマンドで、GitLabの各プロセス（unicorn/puma, sidekiq, gitaly, postgresqlなど）のリソース使用状況を確認する。どのプロセスがリソースを消費しているか特定する。
3. GitLabリソース要件の見直し: 現在のユーザー数や利用状況が、インストール時のハードウェア要件を満たしているか再評価する。必要であればサーバーをスケールアップ（CPUコア数増加、RAM増加、高速なSSDへの移行など）する。
4. gitlab.rb のメモリ設定調整: メモリに余裕がある場合は、unicorn_workers/puma_workers/puma_threads や sidekiq_concurrency の値を増やして並列処理能力を高める。メモリが不足している場合は、これらの値を減らしてメモリ消費を抑える。変更後は sudo gitlab-ctl reconfigure を実行する。
5. データベース (PostgreSQL) の最適化: ユーザー数が多い場合やリポジトリが大きい場合、データベースがボトルネックになることがある。sudo gitlab-ctl psql -d gitlabhq_production でPostgreSQLに接続し、負荷の高いクエリやインデックスの状態などを確認する。PostgreSQLのチューニングは専門的な知識が必要になる場合がある。
6. Sidekiqキューの確認: SidekiqのウェブUI (/admin/sidekiq/) で、キューにジョブが大量に滞留していないか確認する。滞留している場合、Sidekiqプロセスが正常に動作していないか、Sidekiqワーカー数が不足している可能性がある。Sidekiqの設定 (sidekiq_concurrency) を調整する。
7. ログの確認: 各サービスのログ（特に unicorn/puma, sidekiq, gitaly, postgresql）を確認し、エラーや警告が出力されていないか確認する。

これらのトラブルシューティング手順は、問題の特定と解決に役立ちます。解決しない場合は、GitLab公式ドキュメントやコミュニティフォーラムで同様の問題が報告されていないか検索したり、サポートに問い合わせたりすることを検討してください。

まとめ

この記事では、GitLabセルフホスト版の最も一般的で推奨されるインストール方法であるOmnibus Packageに焦点を当て、その詳細な手順を解説しました。

まず、GitLabとは何か、なぜセルフホスト版をインストールするのか、そしてOmnibus Packageがなぜ多くのユーザーにとって最適な選択肢であるのかを説明しました。

次に、Omnibus Packageをインストールするための前提条件として、対応OS、ハードウェア要件、ネットワーク要件、そして推奨されるドメイン名とDNS設定について詳しく解説しました。

インストール手順としては、OSの準備、GitLabリポジトリの追加、パッケージのインストール、そして最も重要な設定ファイルである /etc/gitlab/gitlab.rb の編集方法（特に external_url、HTTPS、SMTP設定）について、ステップバイステップで詳細なコマンドと共に説明しました。設定変更を反映させるための gitlab-ctl reconfigure コマンドの重要性についても強調しました。

インストールが完了した後の管理作業として、サービスの起動/停止/再起動、設定変更時の手順、ログの確認方法、そして定期的なバックアップと復元の手順についても詳しく触れました。特にバックアップはシステムの安定運用に不可欠な作業です。また、OSのパッケージマネージャーを使ったGitLabのアップデート手順、およびメジャーバージョンアップ時の注意点についても説明しました。

最後に、インストール後や運用中に遭遇しうる一般的なトラブル（reconfigure エラー、ウェブUIアクセス不可、Git操作不可、メール通知問題、パフォーマンス問題）とその対処法について、ログの確認方法や利用できるツールを含めて解説しました。

Omnibus Packageは、GitLabの導入を比較的容易にする素晴らしい方法ですが、それでもサーバー管理やLinuxの基本的な知識は必要です。この記事が、GitLabをインストールし、安定して運用するための第一歩となることを願っています。

GitLabは非常に多くの機能を持ち、設定項目も多岐にわたります。ここで説明した内容は基本的な部分ですが、必要に応じてGitLab公式ドキュメントを参照し、ご自身の環境や用途に合わせてさらにカスタマイズを進めていくことができます。

GitLabを導入することで、チームの開発プロセスを効率化し、DevOpsの実践を推進できるようになります。ぜひ、GitLabを活用して、より良いソフトウェア開発を目指してください。

GitLabをインストールする完全ガイド：Omnibus Packageによる詳細解説

はじめに

GitLabのインストール方法の概要

Omnibus Packageによるインストール

なぜOmnibus Packageが推奨されるのか？

前提条件 (Prerequisites)

ステップバイステップ インストール手順 (Omnibus Package)

SELinuxを使用している場合はpolicycoreutilsも必要ですが、Ubuntu/DebianではAppArmorが一般的です。

AppArmorの状態は sudo apparmor_status で確認できます。必要に応じてルール調整や無効化を検討します。

SELinuxの状態は getenforce で確認できます。有効(Enforcing)またはPermissiveであることを確認します。

policycoreutils-python-utils は SELinux ポリシー管理ツールに含まれます。

Community Edition (CE) をインストールする場合は以下のコマンドを実行します。

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

Community Edition (CE) をインストールする場合は以下のコマンドを実行します。

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

または Community Edition: sudo apt install gitlab-ce

または Community Edition: sudo yum install gitlab-ce

または sudo vi /etc/gitlab/gitlab.rb

Nginxリスニングポートが競合する場合などに変更

nginx[‘listen_port’] = 443

nginx[‘listen_https’] = true

ssh_host を external_url と同じドメイン名にするのが一般的

OS標準のSSHデーモンはポート 2222 で起動

GitLab SSHをポート 22 で起動

Nginxはポート 80/443, GitLab SSHはポート 22 をListenするようになる

ポート 22 が他のサービスに使用されていないか確認が必要です

“from” メールアドレス

Unicorn worker 数 (デフォルトは CPU コア数 + 1)。メモリに応じて調整

gitlab_rails[‘unicorn_workers’] = 4

Puma 設定 (最近のバージョンでデフォルト)

gitlab_rails[‘puma_workers’] = 4

gitlab_rails[‘puma_threads’] = 4

Sidekiq concurrency (デフォルトは 25)。メモリに応じて調整

gitlab_rails[‘sidekiq_concurrency’] = 10

Omnibus Package インストール後の管理

サービスの管理

設定の変更と再構成

ログの確認

バックアップと復元

crontab -e で編集

アップデート

その他のインストール方法の概要 (簡易版)

Dockerコンテナ

Kubernetes (Helm Chart)

一般的なトラブルシューティング

gitlab-ctl reconfigure のエラー

ウェブUIにアクセスできない (HTTP 500エラー, Connection Refusedなど)

Gitプッシュ/クローンができない (SSHまたはHTTPS)

メール通知が届かない

パフォーマンス問題 (GitLabが遅い、動作が重い)

まとめ

コメントする 返信をキャンセル

ステップバイステップインストール手順 (Omnibus Package)

AppArmorの状態は `sudo apparmor_status` で確認できます。必要に応じてルール調整や無効化を検討します。

SELinuxの状態は `getenforce` で確認できます。有効(Enforcing)またはPermissiveであることを確認します。

`gitlab-ctl reconfigure` のエラー

コメントする返信をキャンセル