• インストール
  • GitLabパッケージのダウンロード
  • GitLab パッケージのインストール
• SSLの有効化
• GitLab コンテナレジストリの有効化
• DockerデーモンがレジストリとGitLab Runnerを信頼できるようにします。
• GitLab Runnerの有効化
  • ホストOSに対するレジストリの認証
  • バージョンチェックとサービスPingの無効化
  • NTPの設定
• パッケージメタデータデータベースの有効化
  • gsutil ツールを使ってパッケージのメタデータエクスポートをダウンロードします。
  • Google Cloud Storage REST API を使ってパッケージのメタデータエクスポートをダウンロードします。
  • 自動同期
  • 変更メモ

オフラインのセルフマネージド GitLab インスタンスをインストールします。

これは、セルフマネージド GitLab インスタンスを完全にオフラインでインストール、設定、使用するためのステップバイステップのガイドです。

インストール

このプロセスのビデオ・ウォークスルーについては、Offline GitLab Installationをご覧ください：ダウンロードとインストールをご覧ください。

GitLabパッケージのダウンロード

インターネットにアクセスできる同じオペレーティングシステムのサーバーを使って、GitLabパッケージと関連する依存関係を手動でダウンロードする必要があります。

オフライン環境でローカルネットワークにアクセスできない場合は、USBドライブなどの物理メディアを使って手動で関連パッケージを転送する必要があります。

Ubuntuでは、インターネットにアクセスできるサーバー上で以下のコマンドを使用して実行できます：

# Download the bash script to prepare the repository
curl --silent "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh" | sudo bash

# Download the gitlab-ee package and dependencies to /var/cache/apt/archives
sudo apt-get install --download-only gitlab-ee

# Copy the contents of the apt download folder to a mounted media device
sudo cp /var/cache/apt/archives/*.deb /path/to/mount

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

前提条件：

• オフライン環境にGitLabパッケージをインストールする前に、まず必要な依存関係がすべてインストールされていることを確認してください。

Ubuntuを使用している場合は、dpkg でコピーした依存関係.deb パッケージをインストールできます。GitLabパッケージはまだインストールしないでください。

# Navigate to the physical media device
sudo cd /path/to/mount

# Install the dependency packages
sudo dpkg -i <package_name>.deb

オペレーティングシステムに関連するコマンドを使ってパッケージをインストールしますが、EXTERNAL_URL のインストールステップでは必ずhttp URL を指定してください。インストールが終わったら、手動でSSLを設定します。

サーバーのIPアドレスにバインドするのではなく、IP解決のためにドメインをセットアップすることを強くお勧めします。この方が、証明書のCNのターゲットが安定し、長期的な解決が簡単になります。

次の Ubuntu の例では、HTTP を使ってEXTERNAL_URL を指定し、GitLab パッケージをインストールしています：

sudo EXTERNAL_URL="http://my-host.internal" dpkg -i <gitlab_package_name>.deb

SSLの有効化

以下の手順に従って、新しいインスタンスで SSL を有効にします。これらの手順は、Omnibus の NGINX 設定で SSL を手動で設定する手順を反映しています：

1. /etc/gitlab/gitlab.rb に以下の変更を加えます：

   # Update external_url from "http" to "https"
   external_url "https://my-host.internal"
      
   # Set Let's Encrypt to false
   letsencrypt['enable'] = false
   

2. 自己署名証明書を生成するために適切な権限で以下のディレクトリを作成します：

   sudo mkdir -p /etc/gitlab/ssl
   sudo chmod 755 /etc/gitlab/ssl
   sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/gitlab/ssl/my-host.internal.key -out /etc/gitlab/ssl/my-host.internal.crt
   

3. インスタンスを再構成して変更を適用します：

   sudo gitlab-ctl reconfigure
   

GitLab コンテナレジストリの有効化

コンテナレジストリを有効にするには、以下の手順に従います。これらの手順は、既存のドメインでコンテナレジストリを設定する手順を反映しています：

1. /etc/gitlab/gitlab.rb に以下の変更を加えます：

   # Change external_registry_url to match external_url, but append the port 4567
   external_url "https://gitlab.example.com"
   registry_external_url "https://gitlab.example.com:4567"
   

2. インスタンスを再構成して変更を適用します：

   sudo gitlab-ctl reconfigure
   

DockerデーモンがレジストリとGitLab Runnerを信頼できるようにします。

レジストリで信頼された証明書を使用する手順に従って、Dockerデーモンに証明書を提供します：

sudo mkdir -p /etc/docker/certs.d/my-host.internal:5000

sudo cp /etc/gitlab/ssl/my-host.internal.crt /etc/docker/certs.d/my-host.internal:5000/ca.crt

GitLabランナー（次にインストールします）に、ランナーで信頼された証明書を使用する手順に従って証明書を提供します：

sudo mkdir -p /etc/gitlab-runner/certs

sudo cp /etc/gitlab/ssl/my-host.internal.crt /etc/gitlab-runner/certs/ca.crt

GitLab Runnerの有効化

GitLab Runner を Docker サービスとしてインストールする手順と同じように、まず Runner を登録します：

$ sudo docker run --rm -it -v /etc/gitlab-runner:/etc/gitlab-runner gitlab/gitlab-runner register
Updating CA certificates...
Runtime platform                                    arch=amd64 os=linux pid=7 revision=1b659122 version=12.8.0
Running in system-mode.

Please enter the gitlab-ci coordinator URL (for example, https://gitlab.com/):
https://my-host.internal
Please enter the gitlab-ci token for this runner:
XXXXXXXXXXX
Please enter the gitlab-ci description for this runner:
[eb18856e13c0]:
Please enter the gitlab-ci tags for this runner (comma separated):

Registering runner... succeeded                     runner=FSMwkvLZ
Please enter the executor: custom, docker, virtualbox, kubernetes, docker+machine, docker-ssh+machine, docker-ssh, parallels, shell, ssh:
docker
Please enter the default Docker image (for example, ruby:2.6):
ruby:2.6
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

次に、Runner にいくつかの設定を追加しなければなりません：

/etc/gitlab-runner/config.toml に以下の変更を加えます：

• ボリュームにDockerソケットを追加volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
• Executor 設定にpull_policy = "if-not-present" を追加します。

これでランナーを起動できます：

sudo docker run -d --restart always --name gitlab-runner -v /etc/gitlab-runner:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest
90646b6587127906a4ee3f2e51454c6e1f10f26fc7a0b03d9928d8d0d5897b64

ホストOSに対するレジストリの認証

Dockerのレジストリ認証ドキュメントに記載されているように、Dockerの特定のバージョンではOSレベルで証明書チェーンを信頼する必要があります。

Ubuntuの場合、これはupdate-ca-certificates ：

sudo cp /etc/docker/certs.d/my-host.internal\:5000/ca.crt /usr/local/share/ca-certificates/my-host.internal.crt

sudo update-ca-certificates

すべてがうまくいけば、このように表示されるはずです：

1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

バージョンチェックとサービスPingの無効化

バージョンチェックとサービスPingはGitLabのユーザーエクスペリエンスを向上させ、ユーザーがGitLabの最新のインスタンスを利用していることを確認します。オフライン環境では、この2つのサービスをオフにすることで、GitLabサービスにアクセスしようとして失敗することがなくなります。

詳しくは、利用統計を有効または無効にするをご覧ください。

NTPの設定

GitLab 15.4および15.5では、Gitalyクラスタはpool.ntp.org アクセス可能で pool.ntp.orgあることを前提としています。アクセス可能でないpool.ntp.org 場合は pool.ntp.org、GitalyサーバーとPraefectサーバーのタイムサーバー設定をカスタマイズして、アクセス可能なNTPサーバーを使用できるようにしてください。

オフラインインスタンスでは、GitLab Geo チェック Rake タスクは pool.ntp.org を使用するため、常に失敗します。このエラーは無視できますが、回避方法についてはこちらをご覧ください。

パッケージメタデータデータベースの有効化

CycloneDXファイルのライセンススキャンを有効にするには、Package Metadata Databaseを有効にする必要があります。このプロセスはEEライセンスでライセンスされているPackage Metadata Databaseと総称されるものの下でLicenseおよび/またはAdvisory Dataを使用する必要があります。Package Metadata Databaseの使用に関して、以下の点に注意してください：

• 私たちはいつでも予告なしにパッケージメタデータデータベースの全部または一部を変更または中止することができます。
• パッケージメタデータ・データベースは第三者のウェブサイトまたはリソースへのリンクを含むことがあります。私たちはこれらのリンクを便宜上提供しているだけであり、それらのウェブサイトやリソースからの第三者のデータ、コンテンツ、製品、サービス、またはそれらのウェブサイトに表示されているリンクについて責任を負いません。
• パッケージメタデータデータベースは部分的に第三者によって提供された情報に基づいており、GitLabは提供されたコンテンツの正確性や完全性について責任を負いません。

Dependency Scanning の Continuous Vulnerability Scans を有効にするには、Package Metadata Database を有効にすることも必要です（詳細はこの作業を追跡しているエピック 9534を参照してください）。

パッケージメタデータは以下の Google Cloud Provider(GCP) バケットに保存されます：

• ライセンススキャン - prod-exporter-license-bucket-1a6c642fc4de57d4
• 依存関係のスキャン - prod-export-advisory-bucket-1a6c642fc4de57d4

gsutil ツールを使ってパッケージのメタデータエクスポートをダウンロードします。

1. gsutil ツールをインストールします。

2. GitLab Railsディレクトリのルートを探します。

   export GITLAB_RAILS_ROOT_DIR="$(gitlab-rails runner 'puts Rails.root.to_s')"
   echo $GITLAB_RAILS_ROOT_DIR
   

3. 同期したいデータの種類を設定します。

   # For License Scanning
   export PKG_METADATA_BUCKET=prod-export-license-bucket-1a6c642fc4de57d4
   export DATA_DIR="licenses"
      
   # For Dependency Scanning
   export PKG_METADATA_BUCKET=prod-export-advisory-bucket-1a6c642fc4de57d4
   export DATA_DIR="advisories"
   

4. パッケージのメタデータエクスポートをダウンロードします。

   # To download the package metadata exports, an outbound connection to Google Cloud Storage bucket must be allowed.
   mkdir -p "$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/$DATA_DIR"
   gsutil -m rsync -r -d gs://$PKG_METADATA_BUCKET "$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/$DATA_DIR"
      
   # Alternatively, if the GitLab instance is not allowed to connect to the Google Cloud Storage bucket, the package metadata
   # exports can be downloaded using a machine with the allowed access, and then copied to the root of the GitLab Rails directory.
   rsync rsync://example_username@gitlab.example.com/package_metadata/$DATA_DIR "$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/$DATA_DIR"
   

Google Cloud Storage REST API を使ってパッケージのメタデータエクスポートをダウンロードします。

パッケージのメタデータエクスポートはGoogle Cloud Storage APIを使ってダウンロードすることもできます。その内容はhttps://storage.googleapis.com/storage/v1/b/prod-export-license-bucket-1a6c642fc4de57d4/o と https://storage.googleapis.com/storage/v1/b/prod-export-advisory-bucket-1a6c642fc4de57d4/oにあります。以下は、cURLとjqを使ったダウンロードの例です。

#!/bin/bash

set -euo pipefail

DATA_TYPE=$1

GITLAB_RAILS_ROOT_DIR="$(gitlab-rails runner 'puts Rails.root.to_s')"

if [ "$DATA_TYPE" == "license" ]; then
  PKG_METADATA_DIR="$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/licenses"
elif [ "$DATA_TYPE" == "advisory" ]; then
  PKG_METADATA_DIR="$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/advisories"
else
  echo "Usage: import_script.sh [licenses|advisories]"
  exit 1
fi

PKG_METADATA_BUCKET="prod-export-$DATA_TYPE-bucket-1a6c642fc4de57d4"
PKG_METADATA_MANIFEST_OUTPUT_FILE="/tmp/package_metadata_${DATA_TYPE}_export_manifest.json"
PKG_METADATA_DOWNLOADS_OUTPUT_FILE="/tmp/package_metadata_${DATA_TYPE}_object_links.tsv"

# Download the contents of the bucket
curl --silent --show-error --request GET "https://storage.googleapis.com/storage/v1/b/$PKG_METADATA_BUCKET/o?maxResults=7500" > "$PKG_METADATA_MANIFEST_OUTPUT_FILE"

# Parse the links and names for the bucket objects and output them into a tsv file
jq -r '.items[] | [.name, .mediaLink] | @tsv' "$PKG_METADATA_MANIFEST_OUTPUT_FILE" > "$PKG_METADATA_DOWNLOADS_OUTPUT_FILE"

echo -e "Saving package metadata exports to $PKG_METADATA_DIR\n"

# Track how many objects will be downloaded
INDEX=1
TOTAL_OBJECT_COUNT="$(wc -l $PKG_METADATA_DOWNLOADS_OUTPUT_FILE | awk '{print $1}')"

# Download the objects
while IFS= read -r line; do
   FILE="$(echo -n $line | awk '{print $1}')"
   URL="$(echo -n $line | awk '{print $2}')"
   OUTPUT_DIR="$(dirname $PKG_METADATA_DIR/$FILE)"
   OUTPUT_PATH="$PKG_METADATA_DIR/$FILE"

   echo "Downloading $FILE"

   curl --progress-bar --create-dirs --output "$OUTPUT_PATH" --request "GET" "$URL"

   echo -e "$INDEX of $TOTAL_OBJECT_COUNT objects downloaded\n"

   let INDEX=(INDEX+1)
done < "$PKG_METADATA_DOWNLOADS_OUTPUT_FILE"

echo "All objects saved to $PKG_METADATA_DIR"

自動同期

GitLabインスタンスは、package_metadata ディレクトリの内容と定期的に同期されます。ローカルのコピーをアップストリームの変更で自動的に更新するには、定期的に新しいExporterをダウンロードするcronジョブを追加します。例えば、30分ごとに実行するcronジョブをセットアップするために、以下のcrontabsを追加することができます。

ライセンススキャン用：

*/30 * * * * gsutil -m rsync -r -d gs://prod-export-license-bucket-1a6c642fc4de57d4 $GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/licenses

依存関係のスキャン

*/30 * * * * gsutil -m rsync -r -d gs://prod-export-advisory-bucket-1a6c642fc4de57d4 $GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/advisories

変更メモ

16.2 のリリースに伴い、パッケージメタデータのディレクトリがvendor/package_metadata_db からvendor/package_metadata/licenses に変更されました。 このディレクトリが既にインスタンス上に存在し、Dependency Scanning を追加する必要がある場合は、以下の手順を実行する必要があります。

1. licenses ディレクトリの名前を変更します:mv vendor/package_metadata_db vendor/package_metadata/licenses.
2. 保存されているオートメーション スクリプトまたはコマンドを更新して、vendor/package_metadata_db をvendor/package_metadata/licenses に変更します。

3. cron エントリーを更新し、vendor/package_metadata_db をvendor/package_metadata/licenses に変更します。

   sed -i '.bckup' -e 's#vendor/package_metadata_db#vendor/package_metadata/licenses#g' [FILE ...]