워크호스 구성

역사적인 이유로, 워크호스는 다음을 사용합니다:

  • 명령줄 플래그.
  • 구성 파일.
  • 환경 변수.

새로운 워크호스 구성 옵션은 구성 파일에 추가하세요.

CLI 옵션 

  gitlab-workhorse [OPTIONS]

Options:
  -apiCiLongPollingDuration duration
        작업 요청을 위한 러너의 롱 폴링 지속 시간 (기본값 50ns)
  -apiLimit uint
        한 번에 허용되는 API 요청 수
  -apiQueueDuration duration
        요청의 최대 대기 시간 (기본값 30s)
  -apiQueueLimit uint
        대기 중인 API 요청 수
  -authBackend string
        인증/권한 부여 백엔드 (기본값 "http://localhost:8080")
  -authSocket string
        선택 사항: authBackend에 연결할 유닉스 도메인 소켓
  -cableBackend string
        액션 케이블 백엔드
  -cableSocket string
        선택 사항: cableBackend에 연결할 유닉스 도메인 소켓
  -config string
        구성 로드를 위한 TOML 파일
  -developmentMode
        Rails 앱에서 에셋을 제공하도록 허용
  -documentRoot string
        정적 파일 내용의 경로 (기본값 "public")
  -listenAddr string
        HTTP 서버의 수신 주소 (기본값 "localhost:8181")
  -listenNetwork string
        수신 '네트워크' (tcp, tcp4, tcp6, unix) (기본값 "tcp")
  -listenUmask int
        유닉스 소켓을 위한 Umask
  -logFile string
        로그 파일 위치
  -logFormat string
        기본적으로 텍스트를 사용하는 로그 형식 (text, json, structured, none) (기본값 "text")
  -pprofListenAddr string
        pprof 수신 주소, 예: 'localhost:6060'
  -prometheusListenAddr string
        Prometheus 수신 주소, 예: 'localhost:9229'
  -propagateCorrelationID X-Request-ID
        존재하는 경우 수신 요청 헤더 X-Request-ID에서 기존 Correlation-ID 재사용
  -proxyHeadersTimeout duration
        요청을 프록시할 때 응답 헤더를 기다리는 시간 (기본값 5m0s)
  -secretPath string
        authBackend와 인증하기 위한 비밀 키가 포함된 파일 (기본값 "./.gitlab_workhorse_secret")
  -version
        버전 출력 후 종료

‘인증 백엔드’는 GitLab Rails 애플리케이션을 의미합니다. 이 이름은 GitLab Workhorse가 HTTP를 통해 git push와 git pull만 처리할 때부터 사용되어 온 것입니다.

GitLab Workhorse는 TCP 또는 유닉스 도메인 소켓 중 하나에서 수신할 수 있습니다.

또한 Go net/http/pprof 프로파일러 서버를 통해 두 번째 TCP 수신 소켓을 열 수 있습니다.

GitLab Workhorse는 -config 플래그를 통해 유효한 TOML 구성 파일을 전달하면 Redis 빌드 및 러너 등록 이벤트를 수신할 수 있습니다.

정상적인 설정에는 다음이 필요합니다 (문자열을 실제 소켓으로 교체)

Redis

GitLab Workhorse는 CI 빌드 요청을 위해 롱 폴링을 수행하기 위해 Redis와 통합됩니다. 이를 구성하려면:

  • TOML 구성 파일에서 Redis 설정을 구성합니다.
  • -apiCiLongPollingDuration 명령줄 플래그로 CI 빌드 요청에 대한 폴링 동작을 제어합니다.

CI 폴링을 비활성화하면서 구성 파일에서 Redis를 활성화할 수 있습니다. 이 구성은 유휴 Redis Pub/Sub 연결을 초래합니다. 반대는 불가능합니다: CI 롱 폴링은 올바른 Redis 구성이 필요합니다.

예를 들어, 구성 파일의 [redis] 섹션은 다음과 같은 내용을 포함할 수 있습니다:

[redis]
URL = "unix:///var/run/gitlab/redis.sock"
Password = "my_awesome_password"
  • URL - unix://path/to/redis.sock 또는 redis://host:port 형식의 문자열입니다.
  • Password - Redis 인스턴스가 비밀번호로 보호되는 경우에만 필요합니다.
  • Sentinel - 센티넬을 사용하는 경우 필요합니다.

Sentinel과 URL이 모두 제공되면, Sentinel만 사용됩니다.

선택적 필드:

[redis]
DB = 0
MaxIdle = 1
MaxActive = 1
  • DB - 연결할 데이터베이스입니다. 기본값은 0입니다.
  • MaxIdle - Redis 풀에서 한 번에 사용할 수 있는 유휴 연결 수입니다. 기본값은 1입니다.
  • MaxActive - 풀에서 유지할 수 있는 연결 수입니다. 기본값은 1입니다.

상대 경로 URL 지원

GitLab을 상대 경로 URL로 마운트하는 경우, 예를 들어 example.com/gitlab에서 authBackend 설정에서 이 상대 경로 URL을 사용하세요:

gitlab-workhorse -authBackend http://localhost:8080/gitlab

TLS 지원

TLS가 있는 리스너를 구성하여 들어오는 요청에 사용할 수 있습니다. 서버를 위한 인증서와 일치하는 비공개 키를 포함하는 파일의 경로를 제공해야 합니다:

[[listeners]]
network = "tcp"
addr = "localhost:3443"
[listeners.tls]
  certificate = "/path/to/certificate"
  key = "/path/to/private/key"
  min_version = "tls1.2"
  max_version = "tls1.3"

certificate 파일은 서버의 인증서, 모든 중간 인증서 및 CA의 인증서가 연결된 형태여야 합니다.

메트릭 엔드포인트는 유사하게 구성할 수 있습니다:

[metrics_listener]
network = "tcp"
addr = "localhost:9229"
[metrics_listener.tls]
  certificate = "/path/to/certificate"
  key = "/path/to/private/key"
  min_version = "tls1.2"
  max_version = "tls1.3"

센티넬 지원 

[redis]
Sentinel = [ "redis://sentinel1:23456", "redis://sentinel2:23456" ]
SentinelMaster = "mymaster"

센티넬 TLS 지원 

[redis]
Sentinel = [ "rediss://sentinel1:23456", "rediss://sentinel2:23456" ]
SentinelMaster = "mymaster"
[Sentinel.tls]
  certificate = "/path/to/certificate"
  key = "/path/to/private/key"
  ca_certificate = "/path/to/ca_certificate" # 선택 사항
  min_version = "tls1.2"                     # 선택 사항
  max_version = "tls1.3"                     # 선택 사항

authBackend와 authSocket의 상호작용

authBackend와 authSocket 간의 상호작용은 혼란스러울 수 있습니다.

authSocket이 설정되면, authBackend의 호스트 부분을 덮어쓰지만, 상대 경로는 덮어쓰지 않습니다.

표 형식으로:

authBackend authSocket Workhorse 연결 Rails 상대 URL
unset unset localhost:8080 /
http://localhost:3000 unset localhost:3000 /
http://localhost:3000/gitlab unset localhost:3000 /gitlab
unset /path/to/socket /path/to/socket /
http://localhost:3000 /path/to/socket /path/to/socket /
http://localhost:3000/gitlab /path/to/socket /path/to/socket /gitlab

cableBackend와 cableSocket에도 동일하게 적용됩니다.

메타데이터 옵션

[metadata] 섹션에 다음 옵션을 포함하세요:

설정 유형 기본값 설명
zip_reader_limit_bytes bytes 104857600 (100 MB) 선택 사항으로 zip 리더에 제한할 바이트 수입니다. 도입됨 - GitLab 16.9.

예를 들어:

[metadata]
zip_reader_limit_bytes = 209715200 # 200 MB

오류 추적

GitLab-Workhorse는 Sentry를 통한 원격 오류 추적을 지원합니다.

이 기능을 활성화하려면 GITLAB_WORKHORSE_SENTRY_DSN 환경 변수를 설정하세요.

또한 GITLAB_WORKHORSE_SENTRY_ENVIRONMENT 환경 변수를 설정하여 스테이징, 프로덕션 및 개발을 구분할 수 있는 Sentry 환경 기능을 사용할 수 있습니다.

Linux 패키지 (Omnibus)
gitlab_workhorse['env'] = {
    'GITLAB_WORKHORSE_SENTRY_DSN' => 'https://foobar'
    'GITLAB_WORKHORSE_SENTRY_ENVIRONMENT' => 'production'
}
Self-compiled (소스)
export GITLAB_WORKHORSE_SENTRY_DSN='https://foobar'
export GITLAB_WORKHORSE_SENTRY_ENVIRONMENT='production'

분산 추적

Workhorse는 OpenTracing APIs를 사용하여 LabKit을 통해 분산 추적을 지원합니다.

기본적으로, 바이너리에 연결된 추적 구현이 없습니다. BUILD_TAGS 메이크 변수를 설정하여 다양한 OpenTracing 공급자를 링크할 수 있습니다.

지원되는 공급자에 대한 자세한 내용은 LabKit을 참조하세요. Jaeger 추적 지원 예시로, 다음과 같이 태그를 포함하세요: BUILD_TAGS="tracer_static tracer_static_jaeger":

make BUILD_TAGS="tracer_static tracer_static_jaeger"

OpenTracing 공급자로 Workhorse를 컴파일한 후, 다음과 같이 GITLAB_TRACING 환경 변수로 추적 구성을 설정하세요:

GITLAB_TRACING=opentracing://jaeger ./gitlab-workhorse

상관 ID 전파

사용자가 새 프로젝트를 생성하는 등 HTTP 요청을 생성할 때, 초기 요청이 Workhorse를 통해 다른 서비스로 라우팅됩니다. 이 서비스는 다시 다른 요청을 생성할 수 있습니다.

서비스 간 요청 흐름을 추적하기 위해 Workhorse는 상관 ID라는 무작위 값을 생성합니다. Workhorse는 이 상관 ID를 X-Request-Id HTTP 헤더와 함께 보냅니다.

GitLab Shell과 같은 일부 GitLab 서비스는 자체 상관 ID를 생성합니다. 또한 Gitaly와 같은 다른 서비스는 원래 요청의 상관 ID를 전달하는 내부 API 호출을 수행합니다. 두 경우 모두 상관 ID는 X-Request-Id HTTP 헤더와 함께 전달됩니다.

기본적으로, Workhorse는 이 헤더를 무시하고 항상 새 상관 ID를 생성합니다. 이는 디버깅을 어렵게 하고 분산 추적이 제대로 작동하지 않도록 하며, 새 상관 ID는 원래의 것과 완전히 관련이 없습니다.

Workhorse는 -propagateCorrelationID 명령줄 플래그로 들어오는 상관 ID를 전파하도록 구성할 수 있습니다. 이 옵션은 신뢰할 수 없는 클라이언트가 임의의 값을 생성할 수 없도록 IP 허용 목록과 함께 사용하는 것이 매우 권장됩니다.

IP 허용 목록은 Workhorse 구성 파일의 trusted_cidrs_for_propagation 옵션으로 지정됩니다. 신뢰할 수 있는 CIDR 블록 목록을 지정하세요. 예시:

trusted_cidrs_for_propagation = ["10.0.0.0/8", "127.0.0.1/32"]

참고: -propagateCorrelationID 플래그는 trusted_cidrs_for_propagation 옵션이 작동하기 위해 필요합니다.

신뢰할 수 있는 프록시

Workhorse가 NGINX와 같은 리버스 프록시 뒤에 있을 경우,
trusted_cidrs_for_x_forwarded_for 옵션이 필요하여 어떤 CIDR 블록을
신뢰할 수 있는지 지정하여 X-Forwarded-For HTTP 헤더와 함께
원래의 IP 주소를 제공할 수 있습니다. 예를 들어:

trusted_cidrs_for_x_forwarded_for = ["10.0.0.0/8", "127.0.0.1/32"]

지속적인 프로파일링

Workhorse는 LabKit을 통해
Stackdriver Profiler로 지속적인 프로파일링을 지원합니다.
기본적으로, Stackdriver Profiler 구현은
build tags를 사용하여 바이너리에 링크되지만,
필수는 아니며 생략할 수 있습니다. 예를 들어:

make BUILD_TAGS=""

Workhorse를 지속적인 프로파일링으로 컴파일한 후,
GITLAB_CONTINUOUS_PROFILING 환경 변수를 사용하여 프로파일러 구성을 설정합니다.
예를 들어:

GITLAB_CONTINUOUS_PROFILING="stackdriver?service=workhorse&service_version=1.0.1&project_id=test-123 ./gitlab-workhorse"

관련 주제