Workhorse 구성
역사적인 이유로 Workhorse는 다음을 사용합니다:
- 명령줄 플래그
- 구성 파일
- 환경 변수
새로운 Workhorse 구성 옵션을 구성 파일로 추가하세요.
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에 대한 Unix 도메인 소켓
-cableBackend string
ActionCable 백엔드
-cableSocket string
선택 사항: cableBackend에 다이얼을 걸기위한 Unix 도메인 소켓
-config string
구성을 로드 할 TOML 파일
-developmentMode
Rails 앱에서 에셋을 제공하는 것을 허용합니다
-documentRoot string
정적 파일 콘텐츠 경로 (기본 "public")
-listenAddr string
HTTP 서버의 청취 주소 (기본 "localhost:8181")
-listenNetwork string
청취 'network' (tcp, tcp4, tcp6, unix) (기본 "tcp")
-listenUmask int
Unix 소켓의 Umask
-logFile string
로그 파일 위치
-logFormat string
사용할 로그 형식 기본값은 text (text, json, 구조화 된, 없음) (기본 "text")
-pprofListenAddr string
예 : 'localhost:6060'와 같은 pprof 청취 주소
-prometheusListenAddr string
예 : 'localhost:9229'와 같은 Prometheus 청취 주소
-propagateCorrelationID X-Request-ID
헤더 X-Request-ID에서 기존의 상관 ID 재사용 (있는 경우)
-proxyHeadersTimeout duration
요청을 프록시하는 동안 응답 헤더를 기다리는 시간 (기본 5m0s)
-secretPath string
authBackend (기본 "./.gitlab_workhorse_secret")로 인증하기위한 비밀 키가있는 파일
-version
버전을 인쇄하고 종료
‘인증 백엔드’는 GitLab Rails 애플리케이션을 가리킵니다. 이름은 GitLab Workhorse가 git push
및 git pull
만 처리했을 때의 이전 상황에서 남아있습니다.
GitLab Workhorse는 TCP 또는 Unix 도메인 소켓에서 청취할 수 있습니다. 또한 Go net/http/pprof
프로파일러 서버를위한 두 번째 청취 TCP 소켓을 열 수도 있습니다.
GitLab Workhorse는 구성 파일을 -config
플래그를 통해 전달하면 Redis 빌드 및 러너 등록 이벤트를 청취할 수 있습니다.
일반적인 구성은 다음을 요구합니다 (문자열을 실제 소켓으로 바꿈).
Redis
CI 빌드 요청을위한 롱 폴링을위한 Redis와 통합합니다. 이를 구성하려면 다음을 수행하십시오.
- TOML 구성 파일에서 Redis 설정 구성.
-
-apiCiLongPollingDuration
명령줄 플래그로 CI 빌드 요청에 대한 폴링 동작 제어.
CI 폴링을 비활성화하고 구성 파일에서 Redis를 사용하도록 설정할 수 있습니다. 이 구성은 idle Redis Pub/Sub 연결로 이어집니다. 그 반대는 불가능합니다. CI 롱 폴링에는 올바른 Redis 구성이 필요합니다.
예를 들어 구성 파일의 [redis]
섹션은 다음을 포함할 수 있습니다.
[redis]
URL = "unix:///var/run/gitlab/redis.sock"
Password = "my_awesome_password"
Sentinel = [ "tcp://sentinel1:23456", "tcp://sentinel2:23456" ]
SentinelMaster = "mymaster"
-
URL
-unix://path/to/redis.sock
또는tcp://host:port
형식의 문자열. -
Password
- Redis 인스턴스에 암호가 있으면 필요합니다. -
Sentinel
- Sentinel을 사용하는 경우 필요합니다.
Sentinel
및 URL
이 모두 제공되면 Sentinel
만 사용됩니다.
선택적 필드:
[redis]
DB = 0
MaxIdle = 1
MaxActive = 1
-
DB
- 연결할 데이터베이스. 기본값은0
입니다. -
MaxIdle
- Redis 풀에있는 빈 연결 수. 기본값은1
입니다. -
MaxActive
- 풀이 유지 할 연결 수. 기본값은1
입니다.
상대 URL 지원
example.com/gitlab
와 같이 상대 URL에서 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"
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 reader를 제한하는 바이트 수 (GitLab 16.9에서 소개). |
예를 들어:
[metadata]
zip_reader_limit_bytes = 209715200 # 200 MB
오류 추적
GitLab-Workhorse는 Sentry와 원격 오류 추적을 지원합니다.
이 기능을 활성화하려면 GITLAB_WORKHORSE_SENTRY_DSN
환경 변수를 설정하십시오.
또한 GITLAB_WORKHORSE_SENTRY_ENVIRONMENT
환경 변수를 설정하여 환경 기능을 사용하여 스테이징, 프로덕션 및 개발을 분리하십시오.
gitlab_workhorse['env'] = {
'GITLAB_WORKHORSE_SENTRY_DSN' => 'https://foobar'
'GITLAB_WORKHORSE_SENTRY_ENVIRONMENT' => 'production'
}
export GITLAB_WORKHORSE_SENTRY_DSN='https://foobar'
export GITLAB_WORKHORSE_SENTRY_ENVIRONMENT='production'
분산 추적
Workhorse는 LabKit을 통해 분산 추적을 지원하며, OpenTracing APIs를 사용합니다.
기본적으로 바이너리에 추적 구현이 연결되어 있지 않습니다. 빌드 태그나 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는 요청이 서비스 간에 흘러가는 것을 추적하는 데 도움이 될 수 있는 무작위 값인 연관 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"]
trusted_cidrs_for_propagation
옵션이 작동하려면 -propagateCorrelationID
플래그를 사용해야 합니다.신뢰할 수 있는 프록시
Workhorse가 NGINX와 같은 역방향 프록시 뒤에 있으면, trusted_cidrs_for_x_forwarded_for
옵션이 필요합니다. 이 옵션을 사용하여 X-Forwarded-For
HTTP 헤더를 통해 원본 IP 주소를 제공할 수 있는 신뢰할 수 있는 CIDR 블록을 지정해야 합니다. 예를 들어:
trusted_cidrs_for_x_forwarded_for = ["10.0.0.0/8", "127.0.0.1/32"]
지속적인 프로파일링
Workhorse는 LabKit을 통해 지속적인 프로파일링을 지원하며, Stackdriver Profiler를 사용합니다. 기본적으로는 빌드 태그를 사용하여 Stackdriver Profiler 구현이 바이너리에 연결되지만 필수는 아니며 스킵할 수 있습니다. 예를 들어:
make BUILD_TAGS=""
지속적인 프로파일링으로 Workhorse를 컴파일한 후, GITLAB_CONTINUOUS_PROFILING
환경 변수를 사용하여 프로파일러 구성을 설정합니다. 예를 들어:
GITLAB_CONTINUOUS_PROFILING="stackdriver?service=workhorse&service_version=1.0.1&project_id=test-123 ./gitlab-workhorse"