- SSHホストキーの指紋
- SSH
known_hosts
エントリ - メール設定
- バックアップ
- 代替SSHポート
- GitLab Pages
- GitLab CI/CD
- リポジトリサイズ制限
- IPレンジ
- 最大webhook数
- 共有Runner
- Sidekiq
- PostgreSQL
- Unicorn
- GitLab.com固有のレート制限
- GitLab.com ロギング
- GitLab.com アットスケール
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 |
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の共有ランナーを提供しています。
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 | デフォルト |
---|---|---|
GitLab Runner | ランナーバージョンダッシュボード | - |
執行者 | docker+machine
| - |
デフォルトDockerイメージ | ruby:2.5
| - |
privileged (DockerでDockerを実行)。
| true
| false
|
プリクローンスクリプト
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
の全内容は以下の通りです:
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を使用しません。 つまり、パイプラインの設定で
image
やservices
を指定することができません。 - ベータリリースでは、ベース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の現在の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のログを統一するためにFluentdを使っています:
Prometheus
Prometheusは私たちの監視スタックを完成させました:
グラファナ
モニタリングデータの可視化
セントリー
オープンソースのエラートラッキング:
Consul
サービス発見:
HAProxy
高性能TCP/HTTPロードバランサー: