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

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

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

Linuxパッケージは、弊社のパッケージリポジトリで入手できます:

• GitLab Enterprise Edition。
• GitLab Community Edition。

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

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

GitLabは、以下のオペレーティングシステム向けにLinuxパッケージを提供しています。これらのプラットフォーム向けにパッケージをビルドし、配布しています。この表は、各オペレーティングシステムで利用可能なGitLabバージョンを示しています。

ベンダーのサポートライフサイクルに基づいて、オペレーティングシステム向けのLinuxパッケージを提供しています。LTSバージョンが存在する場合、当社はそれらを対象としますが、すべてのオペレーティングシステムがLTSモデルに従っているわけではありません。

パッケージビルドは通常、オペレーティングシステムがベンダーのエンドオブライフ (EOL) に達するまで継続されます。当社は標準またはメンテナンスサポートのタイムラインに従い、延長またはプレミアムサポート期間は対象外です。

ベンダーのEOL前にパッケージビルドを中止する場合があります。その理由は次のとおりです:

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

いずれかのオペレーティングシステムバージョンのサポートを中止する前に、少なくとも6か月の通知を行うことを目指しています。技術的な制限またはベンダーの制約により、より���い通知期間が必要な場合は、可能な限り迅速に変更をお知らせします。

脚注:

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リリースのリストを以下の表で確認できます:

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

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は現在、クッキーを発行するためにより強力なアクティブディスパッチソルトを必要とします。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ノード間で同期される必要があります。

3. FIPS 140-3へのアップグレード時のOAuthトークン移行の準備: GitLab 18.6.0、18.5.2、および18.4.4では、FIPS 140-3要件に準拠するためにOAuthトークンのSHA512ハッシュが導入されました。以前のGitLabはソルトなしのPBKDF2を使用していましたが、これはUbuntu 22.04のようなFIPS 140-3準拠システムとは互換性がありません。

   **注:**この移行は、FIPS 140-3準拠のオペレーティングシステム (Ubuntu 22.04など) に移行する場合にのみ必要です。すでに古いFIPSバージョン (Ubuntu 20.04など) で実行している場合、または非FIPSシステムを使用している場合は、変更は必要ありません。

   非FIPSインスタンスまたは古いFIPSバージョンからFIPS 140-3インスタンスに移行する場合:

   1. GitLab 18.4以降にアップグレードします。
   2. 通常の使用中に、アクティブなOAuthアクセストークンが自動的に再ハッシュされるのに十分な時間を確保します。
   3. OAuthアプリケーションのシークレットをローテーションして、新しく発行されたすべてのトークンがFIPS準拠のハッシュアルゴリズムを使用するようにします。
   4. ユーザーに、トークンが最近使用されていない場合、OAuth統合アプリケーションで再認証する必要があるかもしれないことを通知します。