• SSHホストキーの指紋
• SSHknown_hosts エントリ
• メール設定
• バックアップ
• 代替SSHポート
• GitLab Pages
• GitLab CI/CD
• リポジトリサイズ制限
• IPレンジ
• 最大webhook数
• 共有Runner
  • Linux共有ランナー
    • プリクローンスクリプト
    • config.toml
  • Windows共有ランナー（ベータ版）
    • 設定
    • 例
    • 制限と既知のイシュー
• Sidekiq
• PostgreSQL
• Unicorn
• GitLab.com固有のレート制限
  • HAProxy API スロットル
  • ラックアタック・イニシャライザー
    • プロテクトパス スロットル
    • git とコンテナレジストリの認証禁止に失敗しました。
  • 管理エリアの設定
  • 可視性の設定
  • SSH最大接続数
  • インポート/エクスポート
• GitLab.com ロギング
• GitLab.com アットスケール
  • エラスティッククラスター
  • フルエント
  • Prometheus
  • グラファナ
  • セントリー
  • Consul
  • HAProxy

GitLab.comの設定

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

SSHホストキーの指紋

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

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）でアクセスできます。

例として~/.ssh/config ：

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

GitLab Pages

以下はGitLab Pagesの設定です。

GitLab CI/CD

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

リポジトリサイズ制限

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

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

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の共有ランナーを提供しています。

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 時間後にタイムアウトします。 イシュー4010と4070を参照してください。

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

プリクローンスクリプト

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

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

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

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

config.toml

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

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 の全内容は以下の通りです：

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を使用しません。 つまり、パイプラインの設定でimage やservices を指定することができません。
• ベータリリースでは、ベースVMイメージにソフトウェアパッケージのセットを含んでいます。 CIジョブがこのリストに含まれていない追加ソフトウェアを必要とする場合、before_script またはscript にインストールコマンドを追加して、必要なソフトウェアをインストールする必要があります。各ジョブは新しいVMインスタンス上で実行されるため、パイプライン内の各ジョブで追加ソフトウェアパッケージのインストールを繰り返す必要があることに注意してください。
• ジョブは、Linux共有Runnerよりも長い時間保留状態になる可能性があります。
• Windows Shared Runnerを使用しているパイプラインにアップデートが必要となるような変更を加える可能性があります。

Sidekiq

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

PostgreSQL

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

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

これらの設定の一部は調整中です。例えば、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の現在のHAProxy設定で、rate_limit_http_rate_per_minute とrate_limit_sessions_per_second を検索します。

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

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

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

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．

• 生エンドポイントのレート制限がデフォルトに設定されています。
• ユーザーおよびIPレート制限の設定が有効になっていません。

可視性の設定

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-cookbooks /gitlab-elk - GitLab
• gitlab-cookbooks /gitlab_elasticsearch - GitLab

フルエント

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

• gitlab-cookbooks /gitlab_fluentd - GitLab

Prometheus

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

• gitlab-cookbooks /gitlab-prometheus - GitLab

グラファナ

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

• gitlab-cookbooks /gitlab-grafana - GitLab

セントリー

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

• gitlab-cookbooks /gitlab-sentry - GitLab

Consul

サービス発見：

• gitlab-cookbooks /gitlab_consul - GitLab

HAProxy

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

• gitlab-cookbooks /gitlab-haproxy - GitLab