Linuxパッケージを使用してGitLabをインストール

Linuxパッケージは成熟しており、スケーラブルで、GitLab.comで使用されています。さらに柔軟性と回復力が必要な場合は、リファレンスアーキテクチャドキュメントの説明に従ってGitLabをデプロイすることをお勧めします。

Linuxパッケージは、インストールが迅速で、アップグレードが容易であり、他のインストール方法にはない信頼性を高めるための機能が含まれています。GitLabを実行するために必要なすべての異なるサービスとツールをバンドルする単一のパッケージ（Omnibus GitLabとも呼ばれます）を介してインストールします。最小ハードウェア要件については、インストールの要件を参照してください。

Linuxパッケージは、パッケージリポジトリで次のものに使用できます:

• GitLab Enterprise Edition（EE）
• GitLab Community Edition

必要なGitLabバージョンが、ホストのオペレーティングシステムで使用可能であることを確認してください。

サポートされているプラットフォーム

GitLabは、オペレーティングシステムの長期サポート(LTS)バージョンを正式にサポートしています。Ubuntuなど、一部のオペレーティングシステムには、LTSバージョンと非LTSバージョンの明確な区別があります。ただし、openSUSEなど、LTSの概念に従わないオペレーティングシステムもあります。

通常、オペレーティングシステムのバージョンのサポートは、ベンダーによるサポートが終了するまで提供されます。サポートは、拡張サポート、延長サポート、またはプレミアムサポートではなく、標準サポートまたはメンテナンスサポートとして定義されます。ただし、次のような状況では、オペレーティングシステムのベンダーよりも早くサポートを終了する場合があります:

• ビジネス上の考慮事項: 顧客の採用率の低さ、不均衡なメンテナンスコスト、戦略的な製品方向の変更などが含まれますが、これらに限定されません。
• 技術的な制約: サードパーティの依存関係、セキュリティ要件、または基盤となるテクノロジーの変更により、継続的なサポートが非現実的または不可能になる場合。
• ベンダーのアクション: オペレーティングシステムのベンダーが、当社のソフトウェアの機能に根本的な影響を与える変更を加えたり、必要なコンポーネントが使用できなくなったりした場合。

通常、オペレーティングシステムのバージョンのサポートを中止する少なくとも6か月前に、できる限り非推奨通知を発行します。技術的な制約、ベンダーのアクション、またはその他の外部要因により、より短い通知期間を提供する必要がある場合、合理的に可能な限り迅速にサポートの変更を通知します。

Footnotes（脚注）:

1. ARMでGitLabを実行する場合、既知の問題が存在します。

非公式でサポートされていないインストール方法

次のインストール方法は、より広範なGitLabコミュニティによって現状のまま提供されており、GitLabによってサポートされていません:

• Debianネイティブパッケージ（Pirate Praveen著）
• FreeBSDパッケージ（Torsten Zühlsdorff著）
• Arch Linuxパッケージ（Arch Linuxコミュニティによる）
• Puppetモジュール（Vox Pupuli著）
• Ansibleプレイブック（Jeff Geerling著）
• GitLab仮想アプライアンス（KVM）（OpenNebula著）
• CloudronのGitLab（Cloudron App Library経由）

エンドオブライフバージョン

GitLabは、オペレーティングシステムのサポート終了日(EOL)まで、オペレーティングシステム用のLinuxパッケージを提供します。EOL日を過ぎると、GitLabは公式パッケージのリリースを停止します。

ただし、オペレーティングシステムがエンドオブライフになった後でも、新しいバージョンのパッケージを提供できないため、非推奨にならない場合があります。この最も一般的な理由としては、パッケージリポジトリプロバイダーであるPackageCloudが新しいバージョンをサポートしていないため、パッケージをアップロードできないことが挙げられます。

サポートが終了したオペレーティングシステムのリストと、それらに対する最終的なGitLabリリースは、以下のとおりです:

Raspberry Pi OS（32ビット - Raspbian）

GitLabは、Raspberry Pi OS（32ビット - Raspbian）のサポートをGitLab 17.11で廃止しました。これが32ビットプラットフォームで利用できる最後のバージョンです。GitLab 18.0以降、Raspberry Pi OS（64ビット）に移行し、Debian arm64パッケージを使用する必要があります。

32ビットOSでのデータのバックアップと64ビットOSへの復元については、PostgreSQLが動作しているオペレーティングシステムをアップグレードするを参照してください。

Linuxパッケージをアンインストールする

Linuxパッケージをアンインストールするには、データ（リポジトリ、データベース、設定）を保持するか、すべて削除するかを選択できます:

1. オプション。パッケージを削除する前に、Linuxパッケージによって作成されたすべてのユーザーとグループを削除するには:

   sudo gitlab-ctl stop && sudo gitlab-ctl remove-accounts

   アカウントまたはグループの削除で問題が発生した場合は、userdelまたはgroupdelを手動で実行して削除してください。また、/home/から残りのユーザーホームディレクトリを手動で削除することもできます。

2. データを保持するか、すべて削除するかを選択します:

   • データ（リポジトリ、データベース、設定）を保持するには、GitLabを停止し、その監視プロセスを削除します:

     sudo systemctl stop gitlab-runsvdir
     sudo systemctl disable gitlab-runsvdir
     sudo rm /usr/lib/systemd/system/gitlab-runsvdir.service
     sudo systemctl daemon-reload
     sudo systemctl reset-failed
     sudo gitlab-ctl uninstall

   • すべてのデータを削除するには:

     sudo gitlab-ctl cleanse && sudo rm -r /opt/gitlab

3. パッケージをアンインストールします（GitLab FOSSがインストールされている場合は、gitlab-ceに置き換えます）:

   apt

   # Debian/Ubuntu
   sudo apt remove gitlab-ee

   dnf

   # AlmaLinux/RHEL/Oracle Linux/Amazon Linux 2023
   sudo dnf remove gitlab-ee

   zypper

   # OpenSUSE Leap/SLES
   sudo zypper remove gitlab-ee

   yum

   # Amazon Linux 2
   sudo yum remove gitlab-ee

Ubuntu 22.04 FIPS

GitLab 18.4以降では、Ubuntu 22.04でFIPSビルドを使用できます。

アップグレードの前に:

1. すべてのアクティブユーザーのパスワードハッシュの移行を確認します: GitLab 17.11以降では、ユーザーパスワードは、ユーザーがサインインすると、強化されたソルトで自動的に再ハッシュされます。

   このハッシュの移行を完了していないユーザーは、Ubuntu 22 FIPSインストールにサインインできなくなり、パスワードのリセットを実行する必要があります。

   移行していないユーザーを見つけるには、Ubuntu 22.04にアップグレードする前に、このRakeタスクを使用してください。

2. GitLabシークレットJSONを確認します: RailsでCookieを発行するには、より強力なアクティブディスパッチソルトが必要になりました。Linuxパッケージは、Ubuntu 22.04でデフォルトで十分な長さの静的な値を使用します。ただし、Linuxパッケージの設定で次のキーを設定することにより、これらのソルトをカスタマイズできます:

   gitlab_rails['signed_cookie_salt'] = 'custom value'
   gitlab_rails['authenticated_encrypted_cookie_salt'] = 'another custom value'

   これらの値はgitlab-secrets.jsonに書き込まれ、すべてのRailsノード間で同期されている必要があります。