GitLab.comの設定

このページでは、GitLab.comで使用される設定に関する情報をご覧いただけます。

SSHホストキーの指紋

以下は、GitLab.com の SSH ホストキーのフィンガープリントです。 GitLab.com のリポジトリに初めて接続したときには、これらのキーのいずれかが出力されます。

アルゴリズム MD5 (非推奨) シェア256
DSA(非推奨) 7a:47:81:3a:ee:89:89:64:33:ca:44:52:3d:30:d4:87 p8vZBUOR0XQz6sYiaWSMLmh0t9i8srqYKool/Xfdfqw
イーシーディーエスエー f1:d0:fb:46:73:7a:70:92:5a:ab:5d:ef:43:e2:1c:35 HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw
ED25519 2e:65:6a:c8:cf:bf:b2:8b:9a:bd:6d:9f:11:5c:12:16 eUXGGm1YGsMAS7vkcx6JOJdOGHPem5gQp4taiCfCLB8
アールエスエー b6:03:0e:39:97:9e:d0:e7:24:ce:a3:77:3e:01:42:09 ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ

SSHknown_hosts エントリ

SSHで手動指紋確認をスキップするには、.ssh/known_hosts

gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf
gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9
gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=

メール設定

GitLab.com はmg.gitlab.com ドメインからMailgun経由でメールを送信し、専用の IP アドレス (198.61.254.240) を持っています。

バックアップ

バックアップ戦略をご覧ください。

代替SSHポート

GitLab.com には別の SSH ポートgit+ssh)でアクセスできます。

設定
Hostname altssh.gitlab.com
Port 443

例として~/.ssh/config

Host gitlab.com
  Hostname altssh.gitlab.com
  User git
  Port 443
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/gitlab

GitLab Pages

以下はGitLab Pagesの設定です。

設定 GitLab.com デフォルト
ドメイン名 gitlab.io -
IPアドレス 35.185.44.232 -
カスタムドメインのサポート はい いいえ
TLS証明書のサポート はい いいえ
最大サイズ(非圧縮) 1G 100M
注:Pagesサイトの最大サイズはGitLab CI/CDの一部であるアーティファクトの最大サイズによって規制されます。

GitLab CI/CD

以下はGitLab CI/CDに関する現在の設定です。

設定 GitLab.com デフォルト
アーティファクトの最大サイズ(非圧縮) 1G 100M
アーティファクトの有効期限 2020年6月22日以降は、特に指定がない限り30日後に削除されます(それ以前に作成されたアーティファクトには有効期限はありません)。 特に指定がない限り、30日後に削除されます。
パイプライン・クーロン予定表 */5 * * * * 19 * * * *
パイプラインの最大ジョブ数 500 無料期間中は無制限 無制限
プロジェクトにおける最大パイプラインスケジュール 10 無料ティア向け、50 すべての有料ティア向け 無制限
インスタンスレベル変数の最大数 25 25
スケジュールされたジョブのアーカイブ 3ヶ月 決して

リポジトリサイズ制限

GitLab.comでは、以下のアカウント制限が有効になっています。 設定がリストにない場合は、デフォルト値に設定されています。

リポジトリサイズの上限が近いか超えている場合は、gitを使ってリポジトリサイズを小さくすることができます。

設定 GitLab.com デフォルト
LFSを含むリポジトリサイズ 10 GB 無制限
注意:git push と GitLab プロジェクトのインポートは、Cloudflare 経由のリクエストごとに 5 GB に制限されています。Git LFS とファイルアップロード以外のインポートは、この制限の影響を受けません。

IPレンジ

GitLab.comは、そのウェブ/APIフリートからのトラフィックにIPレンジ34.74.90.64/28 。このレンジ全体がGitLabだけに割り当てられています。 webhookやリポジトリミラーリングからの接続がこれらのIPから来ることが予想されるので、それらを許可してください。

GitLab.comはCloudflareによってフロントされています。GitLab.comへの着信接続には、CloudflareのCIDRブロック(IPv4と IPv6)を許可する必要があるかもしれません。

CI/CDランナーからの発信接続については、固定IPアドレスは提供していません。 私たちのランナーはすべてGoogle Cloud Platform(GCP) にデプロイされています。GCPのすべてのIPアドレス範囲またはCIDRブロックを調べることで、IPベースのファイアウォールを設定できます。

最大webhook数

の限界:

  • 100のwebhookはプロジェクトに適用されます。
  • 50 webhook はグループに適用されます。

共有Runner

GitLabはパイプラインを実行するためにGitLab.comでホストされたLinuxとWindowsの共有ランナーを提供しています。

注:GitLabが提供する共有Runnerは設定できません。 特定の設定が必要な場合は、独自のRunnerをインストールすることを検討してください。

Linux共有ランナー

GitLab.comのLinux Shared Runnerはオートスケールモードで動作し、Google Cloud Platformを利用しています。 オートスケールとは、CI/CDジョブをスピンアップするまでの待ち時間を短縮し、プロジェクトごとにVMを分離することで、セキュリティを最大化することを意味します。 公開オープンソースプロジェクトでは無料で利用でき、非公開プロジェクトではグループごとに月2000分のCIに制限されています。 必要に応じて、さらに多くの分を購入することもできます。GitLab.comのすべてのプランについて読む。

すべてのCI/CDジョブは、3.75GBのRAM、CoreOS、最新のDocker Engineがインストールされたn1-standard-1インスタンス上で実行されます。 インスタンスには、1つのvCPUと25GBのHDDディスク容量があります。 VMのデフォルトリージョンはUS East1です。 各インスタンスは1つのジョブにのみ使用され、システム上に残された機密データが他のCIジョブからアクセスされないようにします。

gitlab-shared-runners-manager-X.gitlab.com のフリートは GitLab プロジェクトとそのコミュニティフォーク専用のランナーです。少し大きめのマシンタイプ (n1-standard-2) を使い、SSD ディスクサイズも大きくなっています。 タグなしジョブは実行されず、一般的な共有ランナーとは異なり、インスタンスは最大 40 回まで再利用されます。

GitLab.com (shared-runners-manager-X.gitlab.com) の共有 Runner によって処理されるジョブは、プロジェクトで設定されたタイムアウトに関係なく、3 時間後にタイムアウトします。 イシュー40104070を参照してください。

以下は共有ランナーの設定です。

設定 GitLab.com デフォルト
GitLab Runner ランナーバージョンダッシュボード -
執行者 docker+machine -
デフォルトDockerイメージ ruby:2.5 -
privileged (DockerでDockerを実行)。 true false

プリクローンスクリプト

GitLab.com の Linux Shared Runner は、Runner がgit initgit fetch を実行して GitLab リポジトリをダウンロードしようとする前に、CI ジョブでコマンドを実行する方法を提供します。pre_clone_scriptは次のことに使えます:

  • ビルドディレクトリにリポジトリデータをシードします。
  • サーバーへのリクエスト送信
  • CDNからのアセットダウンロード
  • の前に実行しなければならない他のコマンドはgit init

この機能を使うには、CI_PRE_CLONE_SCRIPT というCI/CD変数にBashスクリプトを定義します。

この例では、ビルドディレクトリをシードするためにプレクローンステップを使用する方法を示します。

config.toml

config.toml の全内容は以下の通りです:

注:公開されていない設定は、Xと表示されます。

Google Cloud Platform

concurrent = X
check_interval = 1
metrics_server = "X"
sentry_dsn = "X"

[[runners]]
  name = "docker-auto-scale"
  request_concurrency = X
  url = "https://gitlab.com/"
  token = "SHARED_RUNNER_TOKEN"
  pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
  executor = "docker+machine"
  environment = [
    "DOCKER_DRIVER=overlay2",
    "DOCKER_TLS_CERTDIR="
  ]
  limit = X
  [runners.docker]
    image = "ruby:2.5"
    privileged = true
    volumes = [
      "/certs/client",
      "/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro" # Make kaniko builds work on GCP.
    ]
  [runners.machine]
    IdleCount = 50
    IdleTime = 3600
    OffPeakPeriods = ["* * * * * sat,sun *"]
    OffPeakTimezone = "UTC"
    OffPeakIdleCount = 15
    OffPeakIdleTime = 3600
    MaxBuilds = 1 # For security reasons we delete the VM after job has finished so it's not reused.
    MachineName = "srm-%s"
    MachineDriver = "google"
    MachineOptions = [
      "google-project=PROJECT",
      "google-disk-size=25",
      "google-machine-type=n1-standard-1",
      "google-username=core",
      "google-tags=gitlab-com,srm",
      "google-use-internal-ip",
      "google-zone=us-east1-d",
      "engine-opt=mtu=1460", # Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
      "google-machine-image=PROJECT/global/images/IMAGE",
      "engine-opt=ipv6", # This will create IPv6 interfaces in the containers.
      "engine-opt=fixed-cidr-v6=fc00::/7",
      "google-operation-backoff-initial-interval=2" # Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
    ]
  [runners.cache]
    Type = "gcs"
    Shared = true
    [runners.cache.gcs]
      CredentialsFile = "/path/to/file"
      BucketName = "bucket-name"

Windows共有ランナー(ベータ版)

Windows Shared Runnerは現在ベータ版であり、本番ワークロードには使用しないでください。

ベータ期間中、共有ランナーパイプラインのクォータはLinuxランナーと同じようにグループとプロジェクトに適用されます。 これは、この関連イシューで説明されているように、ベータ期間が終了すると変更される可能性があります。

GitLab.comのWindows Shared Runnerは、Google Cloud Platform上で仮想マシンを起動することで、自動的にオートスケールします。 このソリューションでは、GitLabが開発したカスタムexecutor用の新しいオートスケーリングドライバを使用しています。 Windows Shared Runnerは、2 vCPUと7.5GB RAMを搭載したn1-standard-2 インスタンス上でCI/CDジョブを実行します。利用可能なWindowsパッケージの全リストは、パッケージのドキュメントで確認できます。

Windows Shared Runnerを安定した状態にし、一般的に利用できるようにするために、私たちは反復を続けたいと考えています。 この目標に向けた私たちの作業を、関連するエピックで追うことができます。

設定

config.toml の全内容は以下の通りです:

注:公開されていない設定は、Xと表示されます。
concurrent = X
check_interval = 3

[[runners]]
  name = "windows-runner"
  url = "https://gitlab.com/"
  token = "TOKEN"
  executor = "custom"
  builds_dir = "C:\\GitLab-Runner\\builds"
  cache_dir = "C:\\GitLab-Runner\\cache"
  shell  = "powershell"
  [runners.custom]
    config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
    config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
    prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
    prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
    run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
    run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
    cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
    cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]

autoscaler/config.toml の全内容は以下の通りです:

Provider = "gcp"
Executor = "winrm"
OS = "windows"
LogLevel = "info"
LogFormat = "text"
LogFile = "C:\\GitLab-Runner\\autoscaler\\autoscaler.log"
VMTag = "windows"

[GCP]
  ServiceAccountFile = "PATH"
  Project = "some-project-df9323"
  Zone = "us-east1-c"
  MachineType = "n1-standard-2"
  Image = "IMAGE"
  DiskSize = 50
  DiskType = "pd-standard"
  Subnetwork = "default"
  Network = "default"
  Tags = ["TAGS"]
  Username = "gitlab_runner"

[WinRM]
  MaximumTimeout = 3600
  ExecutionMaxRetries = 0

[ProviderCache]
  Enabled = true
  Directory = "C:\\GitLab-Runner\\autoscaler\\machines"

以下は、Windows共有ランナーの使い方を示す簡単な.gitlab-ci.yml ファイルです:

.shared_windows_runners:
  tags:
    - shared-windows
    - windows
    - windows-1809

stages:
  - build
  - test

before_script:
 - Set-Variable -Name "time" -Value (date -Format "%H:%m")
 - echo ${time}
 - echo "started by ${GITLAB_USER_NAME}"

build:
  extends:
    - .shared_windows_runners
  stage: build
  script:
    - echo "running scripts in the build job"

test:
  extends:
    - .shared_windows_runners
  stage: test
  script:
    - echo "running scripts in the test job"

制限と既知のイシュー

  • ベータ版の定義に記載されているすべての制限事項。
  • 新しいWindows VMの平均プロビジョニング時間は5分です。 これは、ベータ期間中、Windows Shared Runnerフリートでのビルド開始時間が遅くなる可能性があることを意味します。 将来のリリースでは、仮想マシンの事前プロビジョニングを有効にするためにオートスケーラーを更新します。 これにより、WindowsフリートでのVMのプロビジョニングにかかる時間が大幅に短縮されます。関連するイシューを参照してください。
  • Windows Shared Runnerフリートは、メンテナンスやアップデートのために利用できないことがあります。
  • WindowsのShared Runner仮想マシンインスタンスはGitLab Docker executorを使用しません。 つまり、パイプラインの設定でimageservices を指定することができません。
  • ベータリリースでは、ベースVMイメージにソフトウェアパッケージのセットを含んでいます。 CIジョブがこのリストに含まれていない追加ソフトウェアを必要とする場合、before_script またはscript にインストールコマンドを追加して、必要なソフトウェアをインストールする必要があります。各ジョブは新しいVMインスタンス上で実行されるため、パイプライン内の各ジョブで追加ソフトウェアパッケージのインストールを繰り返す必要があることに注意してください。
  • ジョブは、Linux共有Runnerよりも長い時間保留状態になる可能性があります。
  • Windows Shared Runnerを使用しているパイプラインにアップデートが必要となるような変更を加える可能性があります。

Sidekiq

GitLab.comは引数--timeout=4 --concurrency=4、以下の環境変数でSidekiqを実行します:

設定 GitLab.com デフォルト
SIDEKIQ_DAEMON_MEMORY_KILLER - -
SIDEKIQ_MEMORY_KILLER_MAX_RSS 2000000 2000000
SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS - -
SIDEKIQ_MEMORY_KILLER_CHECK_INTERVAL - 3
SIDEKIQ_MEMORY_KILLER_GRACE_TIME - 900
SIDEKIQ_MEMORY_KILLER_SHUTDOWN_WAIT - 30
SIDEKIQ_LOG_ARGUMENTS 1 -
注:SIDEKIQ_MEMORY_KILLER_MAX_RSS 設定は、SidekiqインポートノードおよびSidekiqエクスポートノードで16000000

PostgreSQL

GitLab.comはかなり大規模なGitLabのインストールであるため、私たちのニーズに合うようにPostgreSQLの様々な設定を変更しています。 例えば、異なるデータベースサーバー間でクエリのバランスを取るために、ストリーミングレプリケーションやホットスタンバイ状態のサーバーを使っています。

GitLab.com固有の設定(とそのデフォルト)のリストは以下の通りです:

設定 GitLab.com デフォルト
archive_command /usr/bin/envdir /etc/wal-e.d/env /opt/wal-e/bin/wal-e wal-push %p 何もない
archive_mode オン オフ
autovacuum_analyze_scale_factor 0.01 0.01
autovacuum_max_workers 6 3
autovacuum_vacuum_cost_limit 1000 -1
autovacuum_vacuum_scale_factor 0.01 0.02
checkpoint_completion_target 0.7 0.9
checkpoint_segments 32 10
effective_cache_size 338688MB 利用可能なメモリ容量に基づいて
hot_standby オン オフ
hot_standby_feedback オン オフ
log_autovacuum_min_duration 0 -1
log_checkpoints オン オフ
log_line_prefix %t [%p]: [%l-1] 何もない
log_min_duration_statement 1000 -1
log_temp_files 0 -1
maintenance_work_mem 2048MB 16 MB
max_replication_slots 5 0
max_wal_senders 32 0
max_wal_size 5GB 1GB
shared_buffers 112896MB 利用可能なメモリ容量に基づいて
shared_preload_libraries pg_stat_statements 何もない
shmall 30146560 サーバーの能力に応じて
shmmax 123480309760 サーバーの能力に応じて
wal_buffers 16MB -1
wal_keep_segments 512 10
wal_level レプリカ 最小限
statement_timeout 15s 60s
idle_in_transaction_session_timeout 60s 60s

これらの設定の一部は調整中です。例えば、shared_buffers の値がかなり高いため、その調整を検討しています。この特定の変更に関する詳細は、https://gitlab.com/gitlab-com/infrastructure/-/issues/1555をご覧ください。変更案の最新リストは、https://gitlab.com/gitlab-com/infrastructure/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=database&label_name[]=changeをご覧ください。

Unicorn

GitLab.com がunicorn-worker-killergem のメモリ制限を調整しました。

基本デフォルト:

  • memory_limit_min = 750MiB
  • memory_limit_max = 1024MiB

ウェブフロントエンド:

  • memory_limit_min = 1024MiB
  • memory_limit_max = 1280MiB

GitLab.com固有のレート制限

注:管理者の文書については、料金制限を参照してください。

IPブロックは通常、GitLab.comがレートリミットの設定に基づいて悪意のある可能性があるとシステムがみなす単一のIPアドレスから異常なトラフィックを受信した場合に発生します。 異常なトラフィックが停止した後、IPアドレスは以下に説明するようにブロックの種類に応じて自動的に解放されます。

GitLab.comへのすべてのリクエストに対して403 Forbidden エラーが表示される場合は、ブロックをトリガーしている可能性のある自動プロセスがないか確認してください。サポートが必要な場合は、影響を受けるIPアドレスなどの詳細をGitLabサポートまでお問い合わせください。

HAProxy API スロットル

GitLab.comは、1IPアドレスあたり毎秒10リクエストを超えるAPIリクエストに対してHTTPステータスコード429

以下のヘッダ例は、すべてのAPIリクエストに含まれます:

RateLimit-Limit: 600
RateLimit-Observed: 6
RateLimit-Remaining: 594
RateLimit-Reset: 1563325137
RateLimit-ResetTime: Wed, 17 Jul 2019 00:58:57 GMT

ソース

ラックアタック・イニシャライザー

ラックアタックによる料金制限の詳細。

プロテクトパス スロットル

GitLab.com は、保護されたパスでの POST リクエストが IP アドレスあたり毎分10 リクエストを超えた場合、HTTP ステータスコード429 で応答します。

どのパスが保護されるかについては、以下のソースを参照してください。 これには、ユーザーの作成、ユーザーの確認、ユーザーのサインイン、およびパスワードのリセットが含まれます。

このヘッダーはブロックされたリクエストに対する応答に含まれます:

Retry-After: 60

詳しくは保護されたパスをご覧ください。

git とコンテナレジストリの認証禁止に失敗しました。

GitLab.comは、1つのIPアドレスから3分間に30回の認証失敗リクエストがあった場合、HTTPステータスコード403 で1時間応答します。

これは、git リクエストとコンテナレジストリ (/jwt/auth) リクエスト (を合わせたもの) にのみ適用されます。

この限界:

  • 例えば、29の認証失敗リクエストの後に1つの認証成功リクエストがあり、さらに29の認証失敗リクエストがあったとしても、BANのトリガーにはなりません。
  • gitlab-ci-tokenによって認証されたJWTリクエストには適用されません。

応答ヘッダは提供されません。

管理エリアの設定

GitLab.

可視性の設定

GitLab.comでは、作成されたプロジェクト、グループ、スニペット GitLab 12.2(2019年7月)より、GitLab.comではプロジェクト、グループ、スニペットの内部可視化設定が無効になっています。

SSH最大接続数

GitLab.com はMaxStartups 設定を使うことで、認証されていない SSH 接続の最大同時接続数を定義しています。許可された最大接続数を超える接続が同時に発生した場合、接続は切断され、ユーザーはssh_exchange_identification エラーを受け取ります。

インポート/エクスポート

不正使用を避けるため、プロジェクトとグループのインポート、エクスポート、エクスポート・ダウンロードにはレート制限があります。 詳しくは、プロジェクトのインポート/エクスポート・レート制限と グループのインポート/エクスポート・レート制限をご覧ください。

GitLab.com ロギング

FluentdはログをStackdriver Loggingと Cloud Pub/Subに送ります。 StackdriverはログをGoogle Cold Storage(GCS)に長期保存するために使います。 Cloud Pub/Subはpubsubbeatを使ってログをElasticクラスターに転送するために使います。

詳しい情報はランブックでご覧いただけます:

GitLab.com アットスケール

GitLab Enterprise Edition Omnibusのインストールに加えて、GitLab.comはスケールを実現するために以下のアプリケーションと設定を使っています。 すべての設定はchef cookbooksで公開されています。

エラスティッククラスター

監視ソリューションの一部に Elasticsearch と Kibana を使用しています:

フルエント

GitLabのログを統一するためにFluentdを使っています:

Prometheus

Prometheusは私たちの監視スタックを完成させました:

グラファナ

モニタリングデータの可視化

セントリー

オープンソースのエラートラッキング:

Consul

サービス発見:

HAProxy

高性能TCP/HTTPロードバランサー: