6.12. 프로비저닝 콜백
프로비저닝 콜백은 사용자가 자동화 컨트롤러 콘솔에서 호스트를 관리하는 작업을 시작할 때까지 기다리는 대신 호스트에서 자체적으로 플레이북 실행을 시작할 수 있는 자동화 컨트롤러의 기능입니다.
프로비저닝 콜백은 호출 호스트에서 플레이북을 실행하는 데만 사용되며 클라우드 버스팅을 위한 것입니다. 클라우드 버스팅은 컴퓨팅에 수요가 급증할 때 프라이빗 클라우드가 퍼블릭 클라우드에 "버그"를 통해 퍼블릭 클라우드 리소스에 액세스할 수 있는 클라우드 컴퓨팅 구성입니다.
예
다른 호스트에 대해 작업을 실행하는 것이 아니라 권한 부여 키 전송과 같은 구성을 위해 클라이언트가 서버 간 통신이 필요한 새 인스턴스입니다. 이를 통해 자동으로 다음을 구성합니다.
- 다른 시스템에서 프로비저닝한 후(예: AWS 자동 확장 또는 kickstart 또는 preseed와 같은 OS 프로비저닝 시스템)
- 자동화 컨트롤러 API를 직접 호출하지 않고 프로그래밍 방식으로 작업을 시작합니다.
시작된 작업 템플릿은 프로비저닝을 요청하는 호스트에 대해서만 실행됩니다.
이는 종종 firstboot 유형 스크립트 또는 cron 을 사용하여 액세스할 수 있습니다.
6.12.1. 프로비저닝 콜백 활성화
프로세스
콜백을 활성화하려면 작업 템플릿에서 프로비저닝 콜백 옵션을 선택합니다. 그러면 작업 템플릿에 대한 프로비저닝 콜백 세부 정보가 표시됩니다.
참고동적 인벤토리에 자동화 컨트롤러의 프로비저닝 콜백 기능을 사용하려면 작업 템플릿에 사용된 인벤토리 그룹에 대해 Update on Launch 를 설정합니다.
URL이 있는 외부 호스트에서 구성을 요청할 수 없도록 콜백에도 호스트 구성 키가 필요합니다. Host config 키의 사용자 지정 값을 지정합니다. 호스트 키를 여러 호스트에서 다시 사용하여 이 작업 템플릿을 여러 호스트에 적용할 수 있습니다. 구성을 요청할 수 있는 호스트를 제어하려면 언제든지 키를 변경할 수 있습니다.
REST를 사용하여 수동으로 콜백하려면 다음을 수행합니다.
프로세스
UI의 콜백 URL 검사: https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback/
- 샘플 URL의 "7"은 자동화 컨트롤러의 작업 템플릿 ID입니다.
호스트의 요청이 POST인지 확인합니다. 다음은
curl을 사용하는 예입니다(모두 한 줄에 있음).curl -k -f -i -H 'Content-Type:application/json' -XPOST -d '{"host_config_key": "redhat"}' \ https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback/- 콜백이 성공하려면 요청하는 호스트가 인벤토리에 정의되어 있는지 확인합니다.
문제 해결
자동화 컨트롤러가 정의된 인벤토리 중 하나에서 이름 또는 IP 주소로 호스트를 찾지 못하면 요청이 거부됩니다. 이러한 방식으로 작업 템플릿을 실행할 때 자체적으로 플레이북 실행을 시작하는 호스트가 인벤토리에 있는지 확인합니다. 인벤토리에 호스트가 없으면 작업 템플릿이 No Hosts Matched 유형 오류 메시지와 함께 실패합니다.
호스트가 인벤토리에 없고 인벤토리 그룹에 대해 Update on Launch 가 확인되면 자동화 컨트롤러는 콜백을 실행하기 전에 클라우드 기반 인벤토리 소스 업데이트를 시도합니다.
검증
요청에 성공하면 작업 탭에 항목이 생성되고 결과 및 기록을 볼 수 있습니다. REST를 사용하여 콜백에 액세스할 수 있지만 권장되는 콜백 사용 방법은 자동화 컨트롤러를 포함하는 예제 스크립트 중 하나를 사용하는 것입니다.
-
/usr/share/awx/request_tower_configuration.sh(Linux/UNIX) -
/usr/share/awx/request_tower_configuration.ps1(Windows)
사용법은 다음과 같이 -h 플래그를 전달하여 파일의 소스 코드에 설명되어 있습니다.
./request_tower_configuration.sh -h Usage: ./request_tower_configuration.sh <options> Request server configuration from Ansible Tower. OPTIONS: -h Show this message -s Controller server (e.g. https://ac.example.com) (required) -k Allow insecure SSL connections and transfers -c Host config key (required) -t Job template ID (required) -e Extra variables
이 스크립트는 명령을 재시도할 수 있으므로 간단한 curl 요청보다 더 강력한 콜백을 사용하는 방법입니다. 스크립트는 최대 10분 동안 분당 한 번 재시도합니다.
다음은 예제 스크립트입니다. 200이 아닌 오류 코드가 다시 시도해야 하는 일시적인 오류가 아닐 수 있으므로 오류 시나리오를 감지할 때 더 동적인 동작이 필요한 경우 이 스크립트를 편집합니다.
자동화 컨트롤러에서 동적 인벤토리와 함께 콜백을 사용할 수 있습니다. 예를 들어 지원되는 클라우드 공급자 중 하나에서 클라우드 인벤토리를 가져오는 경우입니다. 이러한 경우 Update On Launch 와 함께 인벤토리 소스에 대한 인벤토리 캐시 시간 초과를 구성하여 클라우드의 API 끝점이 손상되지 않도록 해야 합니다. request_tower_configuration.sh 스크립트는 최대 10분 동안 분당 한 번씩 폴링하므로 인벤토리에 대해 권장되는 캐시 무효화 시간(인벤토리 소스 자체에 구성됨)은 1분 또는 2분입니다.
cron 작업에서 request_tower_configuration.sh 스크립트를 실행하는 것은 권장되지 않지만 30분마다 제안된 cron 간격을 사용하는 것이 좋습니다. 반복된 구성은 자동화 컨트롤러를 예약하여 처리할 수 있으므로 대부분의 사용자가 콜백을 주로 사용하면 온라인 상태가 될 때 최신 구성으로 부트 스트랩되는 기본 이미지를 활성화할 수 있습니다. 처음 부팅할 때 실행하는 것이 가장 좋습니다. 첫 번째 부팅 스크립트는 일반적으로 자체 삭제되는 init 스크립트이므로 request_tower_configuration.sh 스크립트 복사본을 호출하는 init 스크립트를 설정하고 이를 자동 확장 이미지로 설정합니다.
6.12.2. 프로비저닝 콜백에 추가 변수 전달
일반 작업 템플릿에서 가능한 것과 동일한 방식으로 프로비저닝 콜백에서 extra_vars 를 전달할 수 있습니다. extra_vars 를 전달하려면 전송된 데이터는 콘텐츠 유형으로 POST를 애플리케이션 또는 JSON으로 사용하는 본문의 일부여야 합니다.
프로세스
다음 방법 중 하나를 사용하여 추가 변수를 전달합니다.
전달할 고유한
extra_vars를 추가할 때 다음 JSON 형식을 예로 사용합니다.'{"extra_vars": {"variable1":"value1","variable2":"value2",...}}'curl을 사용하여 작업 템플릿 호출에 추가 변수를 전달합니다.root@localhost:~$ curl -f -H 'Content-Type: application/json' -XPOST \ -d '{"host_config_key": "redhat", "extra_vars": "{\"foo\": \"bar\"}"}' \ https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback
자세한 내용은 자동화 실행 구성에서 Curl을 사용하여 작업 시작을 참조하십시오.
