Broker 문제 해결
지역별 다중 테넌트 설정\n설치 시 데이터가 호스팅되는 지역의 Broker 서버 URL을 설정하는 명령을 스크립트에 추가해야 합니다. 사용할 명령 및 URL은 Broker URL을 참조하십시오.
이 페이지에는 다음 사항에 대한 정보와 지침이 포함되어 있습니다.
모니터링 기능인 Healthcheck 및 Systemcheck를 사용한 기본 문제 해결
더 포괄적인 문제 해결 정보는 Broker 문제 해결 FAQ를 참조하십시오.
Broker Client 로깅
기본적으로 Broker의 로그 레벨은 INFO로 설정되어 있습니다. HTTP 상태 코드에 관계없이 모든 SCM 응답이 Broker Client에 의해 로깅됩니다. 로깅 동작을 변경하려면 다음 환경 변수를 설정하십시오.
LOG_LEVEL
info
모든 로그를 보려면 "debug"로 설정하십시오.
LOG_ENABLE_BODY
false
클라이언트 로그에 응답 본문(body)을 포함하려면 "true"로 설정하십시오.
정상 작동 시 로그를 간결하게 유지하기 위해 Snyk은 INFO 레벨에서 최소한의 정보를 생성하며, Snyk에서 클라이언트로 들어오는 요청과 GitHub, GitLab, JIRA 등 대상 시스템으로 나가는 요청을 추적하고 호출된 URL과 수신된 응답 코드를 로깅합니다.
LOG_INFO_VERBOSE="true"로 설정하면 디버그 모드를 사용하지 않고도 이 로그 라인에 헤더를 추가합니다.
기본 로깅을 재정의하는 경우, API 요청과 같은 다른 프로세스에 의해 일부 로그가 제공될 수 있으며 자격 증명이 나열될 수 있습니다. 로깅이 강화된 상태로 Broker 로그를 보내기 전에 비밀번호나 토큰이 있는지 확인하고 모두 마스킹 처리하십시오.
모니터링: Healthcheck
Broker는 실행 중인 애플리케이션의 상태를 모니터링하는 데 사용할 수 있는 /healthcheck 엔드포인트를 노출합니다. 이 엔드포인트는 내부 요청이 성공하면 상태 코드 200 OK로 응답하고 응답 본문에 { ok: true }를 반환합니다.
Broker Client의 경우, 이 엔드포인트는 Broker WebSocket 연결 상태도 보고합니다. WebSocket 연결이 열려 있지 않으면 상태 코드 500 Internal Server Error와 함께 본문에 { ok: false }를 반환합니다.
이 상태는 기본 설정인 경우 Broker에 연결하여 http://localhost:8000/healthcheck 를 실행하여 테스트할 수 있습니다.
상태 점검 엔드포인트의 위치를 변경하려면 환경 변수에 대체 경로를 지정할 수 있습니다.
모니터링: Systemcheck
Broker Client는 Broker로 연결된 서비스(Git 또는 다른 SCM, 또는 Broker로 연결된 컨테이너 레지스트리)의 연결성과 자격 증명을 검증하는 데 사용할 수 있는 /systemcheck 엔드포인트를 노출합니다. 이 엔드포인트는 Broker Client가 미리 구성된 URL로 요청을 보내고 요청 성공 여부를 보고하게 합니다. 지원되는 구성은 다음과 같습니다.
BROKER_CLIENT_VALIDATION_URL- 요청을 보낼 URL입니다.BROKER_CLIENT_VALIDATION_AUTHORIZATION_HEADER- [선택 사항] 요청의Authorization헤더 값입니다.BROKER_CLIENT_VALIDATION_BASIC_AUTH와 상호 배타적입니다.BROKER_CLIENT_VALIDATION_BASIC_AUTH- [선택 사항] base64로 인코딩되어 요청의Authorization헤더 값에 들어갈 기본 인증 자격 증명(username:password)입니다.BROKER_CLIENT_VALIDATION_AUTHORIZATION_HEADER와 상호 배타적입니다.BROKER_CLIENT_VALIDATION_METHOD- [선택 사항] 요청의 HTTP 메서드입니다 (기본값은GET).BROKER_CLIENT_VALIDATION_TIMEOUT_MS- [선택 사항] 요청 시간 초과 밀리초입니다 (기본값은 5000ms).
이 엔드포인트는 내부 요청이 성공하면 상태 코드 200 OK로 응답하고, 자격 증명당 하나의 객체를 포함하는 배열과 함께 본문에 { ok: true }를 반환합니다. 자격 증명 풀링(Credential pooling)을 참조하십시오. 내부 요청이 실패하면 상태 코드 500 Internal Server Error와 함께 본문에 { ok: false }를 반환합니다.
이 상태는 기본 설정인 경우 Broker에 연결하여 http://localhost:8000/systemcheck 를 실행하여 테스트할 수 있습니다.
Broker와 Nexus 간의 연결성을 확인하기 위해 /systemcheck 기능을 활성화하는 예시:\n-e BROKER_CLIENT_VALIDATION_URL=https://[username:password]@acme.com/service/rest/v1/status[/check] / snyk/broker:nexus`
시스템 점검 엔드포인트의 위치를 변경하려면 환경 변수에 대체 경로를 지정할 수 있습니다.
Snyk Broker는 mTLS 인증 방식을 지원하지 않습니다.
Standalone Broker 문제 해결
Broker를 실행한 후에도 온프레미스 Git 연결에 오류가 발생하는 경우 다음 문제 해결 단계를 따르십시오.
Broker 컨테이너에 관련 로그가 있는지 확인하십시오. 이를 위해 온프레미스 Git에 연결을 시도하십시오. Integrations 탭으로 이동하여 가져오기(import)를 시도하면 이는 Broker 로그에 로그를 생성합니다.
컨테이너의 로그를 검토하십시오. Docker에서는
docker logs <container id>를 실행하여 수행할 수 있습니다.로그를 검토하여 어디에서 문제가 발생하는지 확인하십시오.
Standalone Broker의 일반적인 문제
위 단계를 수행한 후에도 로그가 없다면, 고객이 올바른 Broker 토큰을 가지고 있는지 확인하십시오. 그렇다면 WebSocket이 수립되었는지 확인하십시오. 일부 방화벽이 이를 차단할 수 있습니다.
온프레미스 Git으로의 요청에 있는 HTTP 코드를 검토하십시오.
404 - Not found - Docker 실행 명령의 정보가 올바른지 확인하십시오.
401/403 - 자격 증명을 확인하십시오.
SSL 관련 언급이 있다면 자체 서명된 인증서(self-signed certificate)로 인한 것일 수 있습니다. 올바른 인증서를 마운트했는지 확인하거나
-e NODE_TLS_REJECT_UNAUTHORIZED=0플래그를 사용하십시오.
Standalone Broker 연결성 테스트
Broker 및 에이전트 이미지에는 curl이 포함되어 있지 않습니다. 에이전트나 컨테이너 레지스트리, SCM과 같은 엔드포인트에 대한 연결성을 테스트하려면 다음 명령어를 사용할 수 있습니다.
GitHub 및 GitHub Enterprise를 위한 대용량 매니페스트 파일(> 1Mb) 지원
대용량 매니페스트 파일(> 1Mb)을 가져오지 못해 수정/업그레이드 PR 열기나 PR/반복 테스트가 실패할 수 있습니다. 이 문제를 해결하려면 대용량 매니페스트 파일을 허용하도록 Docker 또는 Helm 지침을 따르십시오. 호스트에서 로그아웃할 때 컨테이너가 중단되는 경우
호스트에서 분리할 때 Broker 에코시스템과 함께 컨테이너가 중단된다면, 로그아웃 후에도 컨테이너가 온라인 상태를 유지하도록 다음 명령을 실행하십시오.
loginctl enable-linger $(whoami)
Last updated