AI 에이전트의 경우: 문서 인덱스는 https://www.mongodb.com/ko-kr/docs/llms.txt에서 사용할 수 있으며, 모든 페이지의 마크다운 버전은 어떤 URL 경로에 .md를 추가하여 사용할 수 있습니다.

로컬 환경에서의 기업용 TLS 검사 agentengine dev up

일부 기업 네트워크는 HTTPS(Zscaler 및 유사 제품)를 가로채서 회사 CA로 다시 서명합니다. 해당 CA는 노트북에서는 신뢰되지만 생성된 로컬 개발 이미지 내부에서는 신뢰되지 않으므로 이미지 빌드 중에 uv / npm이(가) UnknownIssuer와(과) 같은 TLS 신뢰 오류로 인해 실패합니다.

  1. 루트 인터셉트 CA를 PEM으로 내보냅니다. 중간 인증서는 체인이 불완전할 때만 도움이 되며, 신뢰 앵커는 루트입니다. 일반적인 소스:

    • OS 신뢰 저장소(Keychain / certmgr / /etc/ssl/certs)

    • IT 팀이 이미 문서화한 내보내기

  2. 해당 파일에 CLI를 지정합니다.

    agentengine dev up --ca-bundle /path/to/corp-root.pem

AGENTENGINE_CA_BUNDLE 프로세스 환경에서도 동일합니다. 워크스페이스 .env의 값은 무시되므로 복제된 리포지토리는 CA를 설치할 수 없습니다.

CLI는 PEM(인증서만 해당, 개인 키는 제외)을 검증하고, 아래의 작업 영역별로 ~/.agentengine/ca-bundles/ 기록하며, 패키지 설치 **전**에 생성된 이미지에 승인된 복사본을 포함합니다. 여기서 이 복사본은 Amazon Linux 신뢰 번들에 병합됩니다. 빌드는 쓰기 가능한 작업 영역에서 아무것도 읽지 않으므로 실행 간의 리포지토리 또는 컨테이너 변경 사항은 신뢰할 수 있는 항목을 변경할 수 없습니다. 리포지토리에서 제공하는 .agentengine/ca-bundle.crt은 읽지 않으며 경고만 표시됩니다.

기록된 CA는 빌드 타임뿐만 아니라 런타임에도 적용됩니다. 생성된 이미지는 표준 CA 환경 변수(SSL_CERT_FILE, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, NODE_EXTRA_CA_CERTS 및 uv의 system-cert 모드)를 병합된 번들로 가리키므로 인터셉트 프록시를 통한 에이전트 자체의 HTTPS 호출도 작동합니다. 이러한 변수와 해당 디렉토리 선택기 형제인 SSL_CERT_DIR는 로컬 스택에 대한 CLI가 소유합니다. 작업 공간 .env의 값은 개발 컨테이너로 전달되지 않으므로 복제된 리포지토리는 작업자의 TLS를 자체 제공하는 인증서로 가리킬 수 없습니다. 다른 CA(예시: 프라이빗 레지스트리의 CA)가 필요한 경우 --ca-bundle에 전달하는 번들에 추가하세요.

이후 agentengine dev up 실행은 동일한 머신에서 기록을 재사용합니다. 다른 머신이나 체크아웃은 이를 상속하지 않으므로 해당 위치에서 플래그를 다시 전달해야 합니다. --clear-ca-bundle은(는) 기록을 제거하고 CA 없이 다시 생성합니다.

.agentengine/Dockerfile.dev을(를) 직접 편집하지 마십시오. 다음 agentengine dev up이(가) 이를 재생성합니다.

  • CA를 제공하지 않는 개발자는 이전과 동일한 이미지 빌드를 얻게 됩니다.

  • --insecure 플래그가 없습니다. 신뢰할 수 있는 CA가 없는 TLS 오류는 여전히 신뢰 문제를 보고합니다.

  • agentengine 바이너리 자체에서 사용하는 OS 신뢰 저장소(예시: AGENTENGINE_IMAGE_SOURCE=custom)는 별개입니다. custom-artifact-source.md.에 문서화된 대로 호스팅하다에 해당 CA를 설치하십시오.

이 페이지 평가하기