MAAS 배포에서 프록시 추적하기
MAAS에서 이미지 다운로드, 설치 프로그램 트래픽, 배포된 패키지 액세스, 이후 애플리케이션 요청을 구분합니다.
MAAS 부팅 이미지 다운로드가 성공하면 컨트롤러의 경로가 증명됩니다. 설치된 머신이 나중에 패키지를 가져오지 못하면 해당 단계의 소비자를 점검하십시오:
| 단계 | 점검할 소비자 |
|---|---|
| 이미지/프로비저닝 다운로드 | 책임 컨트롤러 서비스 |
| 커미셔닝 또는 설치 | 임시 작업 환경 |
| 설치된 OS 패키지 | 패키지 관리자와 생성된 구성 |
| 이후 charm, 스크립트 또는 애플리케이션 다운로드 | 해당 요청을 보내는 클라이언트 |
운영 중인 MAAS 버전의 지원되는 제어 수단을 사용하십시오. 문서화된 enable_http_proxy은 프로비저닝과 패키지 액세스에 내장 또는 지정 프록시를 사용하는 경우를 다룹니다. http_proxy은 외부 서비스를 식별합니다. 피어 프록시 모드에서는 배포된 머신이 MAAS의 내장 프록시를 사용할 수 있으며, 그 프록시는 해당 외부 서비스를 상위로 사용합니다. 공용 외부 상위의 허용된 사용을 위해서는 HTTP 프록시 목록에서 HTTP 후보를 선택하십시오. 피어 프록시 모드에서는 노드의 MAAS 로컬 엔드포인트를 변경하지 마십시오.
따라서 노드의 MAAS 로컬 엔드포인트가 반드시 오래된 것은 아닙니다. 외부 주소로 교체하기 전에 그 상위를 추적하십시오. 프록시 설정을 노드에 전달하지 않던 릴리스의 오래된 preseed 우회 방법은 현재의 모든 배포를 설명하지 않습니다.
실패하는 단계에서 생성된 패키지 설정, 엔드포인트 도달 가능성, 인증 ID를 설치 프로그램 환경과 비교하십시오. 홈 디렉터리나 변수를 공유할 필요는 없습니다. APT를 사용하는 Ubuntu 노드에서는 APT 자체의 프록시 옵션을 점검하십시오. 로컬 메타데이터 액세스는 공용 저장소와 분리하십시오. 내부 프로비저닝 URL을 외부 상위로 보내면 공용 다운로드는 작동해도 실패할 수 있습니다.
컨트롤러 셸이나 브라우저도 또 다른 소비자이며, 구성된 패키지 관리자가 이후의 모든 런타임을 구성하지는 않습니다. 관리 변경 후에는 설정이 즉시 다시 로드되었다고 가정하지 말고 영향을 받은 기존 워크로드가 실제로 무엇을 받았는지 점검하십시오.