운영 Ansible Automation Platform
Ansible Automation Platform 설치를 원활하게 배포하기 위한 설치 구성 게시
초록
머리말 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Ansible Automation Platform을 설치한 후 배포가 원활하게 실행되도록 시스템에 추가 구성이 필요할 수 있습니다. 이 가이드에서는 Red Hat Ansible Automation Platform을 설치한 후 수행할 수 있는 구성 작업에 대한 절차를 제공합니다.
면책 조항:이 정보에 포함된 외부 웹 사이트 링크는 편의를 위해서만 제공됩니다. Red Hat은 링크를 검토하지 않았으며 컨텐츠 또는 이용 가능 여부에 대해 책임을 지지 않습니다. 외부 웹 사이트에 대한 링크가 포함되어 있다고 해서 Red Hat이 해당 웹 사이트 또는 해당 엔티티, 제품, 서비스를 보증한다는 의미는 아닙니다. 사용자는 본인이 그러한 외부 사이트나 콘텐츠를 사용(또는 신뢰)하여 초래되는 어떠한 손실이나 비용에 대해 Red Hat이 어떠한 책임도 지지 않는 데 동의합니다.
Red Hat 문서에 관한 피드백 제공 링크 복사링크가 클립보드에 복사되었습니다!
이 문서를 개선하기 위한 제안이 있거나 오류를 찾을 수 있는 경우 https://access.redhat.com 에서 기술 지원에 문의하여 요청을 열 수 있습니다.
1장. Red Hat Ansible Automation Platform 활성화 링크 복사링크가 클립보드에 복사되었습니다!
조직 관리자인 경우 서비스 계정을 생성하고 클라이언트 ID 및 클라이언트 시크릿을 사용하여 서브스크립션을 활성화해야 합니다.
관리 액세스 권한이 없는 경우 클라이언트 ID 및 클라이언트 시크릿 필드에 Red Hat 사용자 이름과 암호를 입력하여 Ansible Automation Platform 인스턴스에 서브스크립션을 찾아 추가할 수 있습니다.
클라이언트 ID와 클라이언트 시크릿을 입력했지만 서브스크립션을 찾을 수 없는 경우 서비스 계정에 올바른 권한이 설정되어 있지 않을 수 있습니다. 서비스 계정에 대한 자세한 내용 및 문제 해결 지침은 서비스 계정 자격 증명을 통해 인증하도록 Ansible Automation Platform 구성을 참조하십시오.
Red Hat Satellite의 경우 아래 필드에 Satellite 사용자 이름과 Satellite 암호를 입력합니다.
Red Hat Ansible Automation Platform은 사용 가능한 서브스크립션 또는 서브스크립션 매니페스트를 사용하여 Ansible Automation Platform 사용을 승인합니다. 서브스크립션을 얻으려면 다음 중 하나를 수행할 수 있습니다.
- Ansible Automation Platform을 시작할 때 Red Hat 사용자 이름 및 암호, 서비스 계정 인증 정보 또는 Satellite 인증 정보를 사용합니다.
- Red Hat Ansible Automation Platform 인터페이스를 사용하거나 Ansible 플레이북에서 수동으로 서브스크립션 매니페스트 파일을 업로드합니다.
자격 증명을 사용하여 Ansible Automation Platform을 활성화하려면 인증 정보로 활성화를 참조하십시오.
매니페스트 파일을 사용하여 Ansible Automation Platform을 활성화하려면 매니페스트 파일로 활성화를 참조하십시오.
2장. Red Hat Ansible Automation Platform에 대한 프록시 지원 구성 링크 복사링크가 클립보드에 복사되었습니다!
프록시를 사용하여 트래픽과 통신하도록 Red Hat Ansible Automation Platform을 구성할 수 있습니다. 프록시 서버는 다른 서버의 리소스를 찾는 클라이언트의 요청에 대해 중개자 역할을 합니다. 클라이언트는 프록시 서버에 연결하여 다른 서버에서 일부 서비스 또는 사용 가능한 리소스를 요청하고 프록시 서버는 요청을 간소화하고 복잡성을 제어하는 방법으로 평가합니다. 다음 섹션에서는 지원되는 프록시 구성과 설정 방법에 대해 설명합니다.
2.1. 로드 밸런서를 통한 프록시 지원 활성화 링크 복사링크가 클립보드에 복사되었습니다!
전달 프록시는 클라이언트 트래픽을 처리하여 이를 조정하고 보호합니다. 프록시 서버 지원을 제공하기 위해 자동화 컨트롤러는 자동화 컨트롤러의 REMOTE_HOST_HEADERS 목록 변수를 사용하여 프록시된 요청(예: ALB, NLB, HAProxy, Squid, Nginx 및 tinyproxy)을 처리합니다. 기본적으로 REMOTE_HOST_HEADERS 는 ["REMOTE_ADDR", "REMOTE_HOST"] 로 설정됩니다.
프록시 서버 지원을 활성화하려면 자동화 컨트롤러의 설정 페이지에서 REMOTE_HOST_HEADERS 필드를 편집합니다.
프로세스
- 탐색 패널에서 → → 을 선택합니다.
- 클릭합니다.
원격 호스트 헤더 필드에 다음 값을 입력합니다.
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 클릭하여 설정을 저장합니다.
자동화 컨트롤러는 첫 번째 IP 주소가 있을 때까지 Remote Host Headers 의 헤더 목록을 검색하여 원격 호스트의 IP 주소를 결정합니다.
2.2. 알려진 프록시 링크 복사링크가 클립보드에 복사되었습니다!
자동화 컨트롤러가 REMOTE_HOST_HEADERS = ['HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR', 'REMOTE_HOST'] 로 구성된 경우 X-Forwarded-For 의 값이 자동화 컨트롤러 앞에 있는 프록시/로드 밸런서에서 발생했다고 가정합니다. 프록시/로드 밸런서를 사용하지 않고 자동화 컨트롤러에 도달하거나 프록시에서 헤더의 유효성을 검사하지 않는 경우 X-Forwarded-For 의 값을 위조하여 원래 IP 주소를 위조할 수 있습니다.
REMOTE _FOR를 사용하면 취약점이 발생합니다.
_HOST_HEADERS 설정에서 HTTP_X_FORARDED
이를 방지하려면 허용되는 알려진 프록시 목록을 구성할 수 있습니다.
프로세스
- 탐색 패널에서 → → 을 선택합니다.
서비스에서 프록시 IP 허용 목록 필드에서 사용자 지정 원격 헤더 값을 신뢰해야 하는 프록시 IP 주소 목록을 입력합니다.
참고알려진 프록시 목록에 없는 로드 밸런서 및 호스트로 인해 요청이 거부됩니다.
2.2.1. 알려진 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
자동화 컨트롤러에 대해 알려진 프록시 목록을 구성하려면 시스템 설정 페이지의 프록시 IP 허용 목록 필드에 프록시 IP 주소를 추가합니다.
프로세스
- 탐색 패널에서 → → 을 선택합니다.
프록시 IP 허용 목록 필드에 다음 예의 구문을 사용하여 자동화 컨트롤러에 연결할 수 있는 IP 주소를 입력합니다.
프록시 IP 허용 목록 항목 예
[ "example1.proxy.com:8080", "example2.proxy.com:8080" ]
[ "example1.proxy.com:8080", "example2.proxy.com:8080" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요-
프록시 IP 허용 목록에 있는 프록시는 헤더 입력을 적절히 제거하고
X-Forwarded-For값을 클라이언트의 실제 소스 IP와 올바르게 설정합니다. 자동화 컨트롤러는 프록시 IP 허용 목록 의 IP 주소 및 호스트 이름을 사용하여X-Forwarded-for에 스푸핑되지 않은 값을 제공할 수 있습니다. 다음 조건을 모두 충족하지 않는 한
HTTP_X_FORWARDED_FOR을 원격 호스트 헤더 의 항목으로 구성하지 마십시오.- ssl 종료가 있는 프록시된 환경을 사용하고 있습니다.
-
프록시는 클라이언트 스푸핑을 방지하기 위해
X-Forwarded-For헤더의 종료 또는 검증을 제공합니다. -
/etc/tower/conf.d/remote_host_headers.py는 신뢰할 수 있는 프록시 또는 로드 밸런서의 원래 IP 주소만 포함하는PROXY_IP_ALLOWED_LIST를 정의합니다.
-
프록시 IP 허용 목록에 있는 프록시는 헤더 입력을 적절히 제거하고
- 클릭하여 설정을 저장합니다.
2.3. 로드 밸런서를 통해 역방향 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
역방향 프록시는 서버에 대한 외부 요청을 관리하고 추가 보안을 위해 부하 분산 및 서버 ID를 숨깁니다. 시스템 설정의 원격 호스트 헤더 필드에 HTTP_X_FORWARDED_FOR 을 추가하여 역방향 프록시 서버 구성을 지원할 수 있습니다. X-Forwarded-For (XFF) HTTP 헤더 필드는 HTTP 프록시 또는 로드 밸런서를 통해 웹 서버에 연결하는 클라이언트의 원래 IP 주소를 식별합니다.
프로세스
- 탐색 패널에서 → → 을 선택합니다.
원격 호스트 헤더 필드에 다음 값을 입력합니다.
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 아래 행을
/etc/tower/conf.d/custom.py에 추가하여 애플리케이션이 올바른 헤더를 사용하는지 확인합니다.USE_X_FORWARDED_PORT = True USE_X_FORWARDED_HOST = True
USE_X_FORWARDED_PORT = True USE_X_FORWARDED_HOST = TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 클릭하여 설정을 저장합니다.
2.4. 고정 세션 활성화 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 애플리케이션 로드 밸런서는 선택한 로드 밸런싱 알고리즘을 기반으로 각 요청을 등록된 대상으로 개별적으로 라우팅합니다. 로드 밸런서 뒤에서 자동화 허브의 여러 인스턴스를 실행할 때 인증 오류를 방지하려면 고정 세션을 활성화해야 합니다. 고정 세션을 활성화하면 로드 밸런서에 구성된 쿠키와 일치하는 사용자 지정 애플리케이션 쿠키가 설정되어 고정성을 활성화합니다. 이 사용자 지정 쿠키는 애플리케이션에 필요한 모든 쿠키 속성을 포함할 수 있습니다.
3장. 송신 프록시를 사용하도록 Ansible Automation Platform 구성 링크 복사링크가 클립보드에 복사되었습니다!
프록시 서버를 통해 다양한 용도로 플랫폼에서 송신하도록 Ansible Automation Platform을 배포할 수 있습니다. 송신 프록시를 사용하면 클라이언트가 프록시 서버를 통해 네트워크 서비스에 대한 간접 요청을 수행할 수 있습니다. 클라이언트는 먼저 프록시 서버에 연결하고 다른 서버에 있는 이메일과 같은 일부 리소스를 요청합니다. 그런 다음 프록시 서버는 지정된 서버에 연결하여 해당 서버에서 리소스를 검색합니다.
3.1. 개요 링크 복사링크가 클립보드에 복사되었습니다!
송신 프록시는 모든 RPM 및 컨테이너화된 설치 방법에 대해 Ansible Automation Platform의 시스템 및 구성 요소 수준에서 구성해야 합니다. 컨테이너화된 설치 프로그램의 경우 노드에서 podman의 시스템 프록시 구성은 프록시를 통해 액세스하는 대부분의 문제를 해결합니다. RPM 설치의 경우 시스템 및 구성 요소 구성이 모두 필요합니다.
3.1.1. 프록시 백엔드 링크 복사링크가 클립보드에 복사되었습니다!
HTTP 및 HTTPS 프록시의 경우 squid 서버를 사용할 수 있습니다. squid는 HTTP, HTTPS 및 FTP를 지원하는 웹을 위한 전달 프록시로, 자주 요청되는 웹 페이지를 캐싱하고 재사용하여 대역폭을 줄이고 응답 시간을 개선합니다. GNU GPL에 따라 라이센스가 부여됩니다. 전달 프록시는 다른 네트워크(일반적으로 인터넷)로 이동하여 내부 시스템을 대신하여 네트워크 트래픽을 가로채는 시스템입니다. squid 프록시를 사용하면 필요한 모든 통신을 통과할 수 있습니다.
필요한 모든 Ansible Automation Platform 컨트롤 플레인 포트가 squid 프록시 백엔드에서 열려 있는지 확인합니다. Ansible Automation Platform 특정 포트:
다음 포트는 컨테이너화된 설치용입니다.
3.2. 시스템 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
아웃바운드 프록시는 컨트롤 플레인의 모든 노드에 대해 시스템 수준에 구성됩니다.
다음 환경 변수를 설정해야 합니다.
http_proxy=“http://external-proxy_0:3128” https_proxy=“http://external-proxy_0:3128” no_proxy=“localhost,127.0.0.0/8,10.0.0.0/8”
http_proxy=“http://external-proxy_0:3128”
https_proxy=“http://external-proxy_0:3128”
no_proxy=“localhost,127.0.0.0/8,10.0.0.0/8”
해당 변수를 /etc/environment 파일에 추가하여 영구적으로 만들 수도 있습니다.
설치 프로그램은 설치 중에 모든 외부 통신이 프록시를 통과하도록 합니다. 컨테이너화된 설치의 경우 해당 변수는 podman이 egress 프록시를 사용하는지 확인합니다.
3.3. 자동화 컨트롤러 설정 링크 복사링크가 클립보드에 복사되었습니다!
RPM 설치 프로그램을 사용한 후 송신 프록시를 사용하도록 자동화 컨트롤러를 구성해야 합니다.
podman은 시스템 구성된 프록시를 사용하고 모든 컨테이너 트래픽을 프록시로 리디렉션하므로 컨테이너화된 설치 관리자에는 필요하지 않습니다.
자동화 컨트롤러의 경우 /api/v2/settings/ 에서 AWX_TASK_ENV 변수를 설정합니다. UI를 통해 이 작업을 수행하려면 다음 절차를 사용합니다.
프로세스
- 탐색 패널에서 → → 을 선택합니다.
- 클릭합니다.
추가 환경 변수 필드에 변수 를 추가합니다.
및 설정:
"AWX_TASK_ENV": { "http_proxy": "http://external-proxy_0:3128", "https_proxy": "http://external-proxy_0:3128", "no_proxy": "localhost,127.0.0.0/8" }"AWX_TASK_ENV": { "http_proxy": "http://external-proxy_0:3128", "https_proxy": "http://external-proxy_0:3128", "no_proxy": "localhost,127.0.0.0/8" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.1. 자동화 컨트롤러에서 프록시로 작동하도록 SSH를 사용하여 SCM 프로젝트 동기화 구성 링크 복사링크가 클립보드에 복사되었습니다!
RPM 기반 Ansible Automation Platform의 다음 절차에서는 SSH 프로토콜을 사용하여 프록시 서버와 함께 작동하여 자동화 컨트롤러 프로젝트 동기화를 사용하는 방법을 설명합니다.
프로세스
자동화 컨트롤러 노드에서 다음 단계를 수행합니다. ansible-builder가 아직 설치되지 않은 경우 먼저 설치합니다.
subscription-manager repos --enable ansible-automation-platform-2.5-for-rhel-8-x86_64-rpms dnf install ansible-builder
# subscription-manager repos --enable ansible-automation-platform-2.5-for-rhel-8-x86_64-rpms # dnf install ansible-builderCopy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 정의 실행 환경을 빌드합니다.
먼저 작업 디렉터리를 생성합니다.
su - awx mkdir -p builder/newee cd builder/newee
# su - awx $ mkdir -p builder/newee $ cd builder/neweeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 콘텐츠를 사용하여
execution-environment.yml파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow registry.redhat.io에 로그인합니다.
podman login registry.redhat.io
$ podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow ansible-builder를 실행하여 빌드 프로세스를 시작합니다.
cd /var/lib/awx/builder/newee/ ansible-builder build -t my-env -v 3
$ cd /var/lib/awx/builder/newee/ $ ansible-builder build -t my-env -v 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 생성한 사용자 정의 실행 환경을 추가합니다.
- 탐색 패널에서 선택합니다.
- 클릭합니다.
-
이미지 필드에
localhost/my-env:latest를 추가합니다. - 클릭합니다.
Ansible Automation Platform 설치 프로그램을 프로젝트 동기화로 사용할 사용자 지정 환경에서 실행 환경을 기본값에서 교체하는 다음 단계로 다시 실행합니다.
참고설치 프로그램을 실행하기 전에 Ansible Automation Platform을 백업합니다.
./setup.sh -b
# ./setup.sh -bCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup.sh파일과 동일한 위치에 있는group_vars디렉터리에자동화 컨트롤러파일을 생성합니다. 파일 내용은 다음과 같습니다.control_plane_execution_environment: localhost/my-env
control_plane_execution_environment: localhost/my-envCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup.sh실행./setup.sh
# ./setup.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 디렉터리에
ssh_config를 만듭니다. 예를 들면 다음과 같습니다.Host github.com Hostname ssh.github.com ProxyCommand nc --proxy-type http --proxy proxy.example.com:port %h %p User git
Host github.com Hostname ssh.github.com ProxyCommand nc --proxy-type http --proxy proxy.example.com:port %h %p User gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
컨테이너 실행 환경에서
ssh_config파일을 읽을 수 있도록 PATH에ssh_config파일의 디렉터리 경로를 추가하여 격리된 작업을 노출합니다. - 탐색 패널에서 → → 을 선택합니다.
- 클릭합니다.
ssh_config파일이/var/lib/awx/.ssh/ssh_config로 생성된 경우 격리된 작업에 노출할경로에 이 파일을 추가합니다.참고ssh_config가 AWX 사용자가 소유하고 있는지 확인합니다. (#chown awx:awx /var/lib/awx/.ssh/ssh_config)[ "/var/lib/awx/.ssh:/etc/ssh:O" ]
[ "/var/lib/awx/.ssh:/etc/ssh:O" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. AWS 인벤토리 동기화에 구성 가능한 프록시 환경 활성화 링크 복사링크가 클립보드에 복사되었습니다!
AWS 인벤토리 동기화에 대해 구성 가능한 프록시 환경을 활성화하려면 수동으로 재정의 구성 파일을 편집하거나 플랫폼 UI에서 구성을 설정할 수 있습니다.
/usr/lib/systemd/system/receptor.service.d/override.conf를 수동으로 편집하고 여기에 다음http_proxy환경 변수를 추가합니다.http_proxy:<value> https_proxy:<value> proxy_username:<value> Proxy_password:<value>
http_proxy:<value> https_proxy:<value> proxy_username:<value> Proxy_password:<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 또는
- UI를 통해 이 작업을 수행하려면 다음 절차를 사용합니다.
프로세스
- 탐색 패널에서 → → 을 선택합니다.
- 클릭합니다.
추가 환경 변수 필드에 변수 를 추가합니다.
예: *
"AWX_TASK_ENV": {
"no_proxy": "localhost,127.0.0.0/8,10.0.0.0/8",
"http_proxy": "http://proxy_host:3128/",
"https_proxy": "http://proxy_host:3128/"
},
"AWX_TASK_ENV": {
"no_proxy": "localhost,127.0.0.0/8,10.0.0.0/8",
"http_proxy": "http://proxy_host:3128/",
"https_proxy": "http://proxy_host:3128/"
},
3.5. 자동화 허브에서 프록시 설정 구성 링크 복사링크가 클립보드에 복사되었습니다!
프라이빗 자동화 허브가 네트워크 프록시 뒤에 있는 경우 로컬 네트워크 외부에 있는 콘텐츠를 동기화하도록 원격에 프록시 설정을 구성할 수 있습니다.
사전 요구 사항
- 수정 Ansible 리포지토리 콘텐츠 권한이 있습니다. 권한에 대한 자세한 내용은 액세스 관리 및 인증을 참조하십시오.
다음 예제와 같이 Ansible Galaxy에서 동기화할 컬렉션을 식별하는
requirements.yml파일이 있습니다.requirements.yml 예
collections: # Install a collection from Ansible Galaxy. - name: community.aws version: 5.2.0 source: https://galaxy.ansible.comcollections: # Install a collection from Ansible Galaxy. - name: community.aws version: 5.2.0 source: https://galaxy.ansible.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
프로세스
- Ansible Automation Platform에 로그인합니다.
- 탐색 패널에서 → 를 선택합니다.
- 커뮤니티 원격의 세부 정보 탭에서 클릭합니다.
-
YAML requirements 필드에
requirements.yml파일의 내용을 붙여넣습니다. - 클릭합니다.
결과
이제 Ansible Galaxy의 requirements.yml 파일에서 식별된 컬렉션을 프라이빗 자동화 허브로 동기화할 수 있습니다.
다음 단계
동기화 단계는 자동화 허브에서 Ansible 콘텐츠 컬렉션 동기화를 참조하십시오.
3.6. 이벤트 기반 Ansible에서 프록시 설정 구성 링크 복사링크가 클립보드에 복사되었습니다!
이벤트 기반 Ansible의 경우 프록시를 설정할 글로벌 설정이 없습니다. 모든 프로젝트에 대해 프록시를 지정해야 합니다.
프로세스
- 탐색 패널에서 → 선택합니다.
- 클릭합니다.
Proxy 필드를 사용합니다.
3.7. 자동화 메시에 대한 프록시 설정 구성 링크 복사링크가 클립보드에 복사되었습니다!
프록시 서버를 통해 자동화 메시 노드의 수신기에서 아웃바운드 통신을 라우팅할 수 있습니다. 프록시가 TLS 인증서를 제거하지 않으면 Ansible Automation Platform 설치가 프록시 서버 사용을 자동으로 지원합니다.
메시의 모든 노드에는 설치 프로그램이 사용자를 대신하여 생성하는 인증 권한이 있어야 합니다.
인증 기관의 기본 설치 위치는 다음과 같습니다.
/etc/receptor/tls/ca/mesh-CA.crt
사용자를 대신하여 생성된 인증서 및 키는 이름에 nodeID를 사용합니다.
인증서의 경우: /etc/receptor/tls/NODEID.crt
키의 경우: /etc/receptor/tls/NODEID.key
4장. 고급 구성 링크 복사링크가 클립보드에 복사되었습니다!
플랫폼 관리자는 고급 구성을 구현하여 데이터베이스 연결, 로깅, 캐싱, gRPC 서버 매개변수를 포함하여 Ansible Automation Platform을 사용자 지정할 수 있습니다.
4.1. settings.py 파일 링크 복사링크가 클립보드에 복사되었습니다!
플랫폼 관리자는 settings.py 파일을 수정하여 데이터베이스 연결, 로깅 구성, 캐싱 등과 같은 Ansible Automation Platform의 다양한 측면을 구성할 수 있습니다.
두 개의 settings.py 파일이 있습니다. 기본 settings.py 파일은 코드베이스의 일부이며 편집해서는 안 되며 기본값을 재정의하는 데 사용할 수 있는 덮어쓰기 파일입니다.
재정의 설정.py 파일의 위치 및 관리는 배포(RPM 기반, 컨테이너 기반 설치 또는 운영자 기반 설치)에 따라 다를 수 있습니다.
4.1.1. RPM 배포 링크 복사링크가 클립보드에 복사되었습니다!
RPM 기반 설정의 덮어쓰기 settings.py 파일은 직접 편집할 수 있으며 플랫폼 게이트웨이 서비스를 다시 시작한 후 변경 사항이 적용됩니다. 파일을 편집하도록 선택하는 경우 적절한 구문 및 값을 사용해야 합니다. override settings.py 파일은 다음 디렉터리에 있습니다.
/etc/ansible-automation-platform/gateway/settings.py
/etc/ansible-automation-platform/gateway/settings.py
4.1.2. 컨테이너 기반 배포 링크 복사링크가 클립보드에 복사되었습니다!
컨테이너 기반 설치 배포의 경우 Ansible Automation Platform은 컨테이너 내에서 실행되며 settings.py 파일은 컨테이너 내부에 포함됩니다. 그러나 업그레이드 또는 새 설치 중에 settings.py 파일을 덮어쓰므로 컨테이너 기반 설치 배포에서 settings.py 파일을 직접 편집하는 것은 권장되지 않습니다.
컨테이너 기반 설치 배포에서 설정을 사용자 지정하려면 extra_settings 매개변수를 사용하여 설치 프로그램 업데이트를 통해 사용자 지정이 유지되도록 할 수 있습니다. 자세한 내용은 컨테이너화된 설치 가이드의 인벤토리 파일 변수를 참조하십시오.
4.1.3. Operator 기반 배포 링크 복사링크가 클립보드에 복사되었습니다!
Operator 기반 설치 배포의 경우 settings.py 파일은 일반적으로 컨테이너 내부에 있지만 Red Hat OpenShift Container Platform의 컨테이너가 읽기 전용이므로 컨테이너에 직접 settings.py 파일을 수정할 수 없습니다.
대신 운영자 기반 배포의 경우 Ansible Automation Platform 사용자 정의 리소스에서 spec.extra_settings 매개변수를 사용하여 플랫폼 게이트웨이의 설정을 수정할 수 있습니다.
4.2. grpc_settings.py 파일 링크 복사링크가 클립보드에 복사되었습니다!
플랫폼 관리자는 grpc_settings.py 파일을 사용하여 gRPC 서버의 특수 또는 사용자 지정 매개변수를 정의할 수 있습니다.
두 개의 gRPC 설정 파일이 있습니다. 기본 grpc_default.py 는 코드베이스의 일부이며 편집해서는 안 되며 기본값을 재정의하는 데 사용할 수 있는 덮어쓰기 파일입니다. grpc_default.py 파일에는 정상적인 gRPC 연결을 유지하고 중단을 방지하기 위해 데이터베이스 keepalive OPTIONS가 포함되어 있습니다. 이러한 기본값을 변경해야 하는 경우 grpc_settings.py 파일을 사용하여 grpc_defauly.py 파일의 값을 재정의할 수 있습니다.
재정의 grpc_settings.py 파일의 위치 및 관리는 배포에 따라 다를 수 있습니다(RPM 기반, 컨테이너 기반 설치 또는 운영자 기반 설치).
4.2.1. RPM 배포 링크 복사링크가 클립보드에 복사되었습니다!
RPM 기반 설정의 재정의 grpc_settings.py 파일은 직접 편집할 수 있으며 게이트웨이 systemd 서비스를 다시 시작한 후 변경 사항이 적용됩니다. 파일을 편집하도록 선택하는 경우 적절한 구문 및 값을 사용해야 합니다. 재정의 grpc_settings.py 파일은 다음 디렉터리에 있습니다.
/etc/ansible-automation-platform/gateway/grpc_settings.py
/etc/ansible-automation-platform/gateway/grpc_settings.py
4.2.2. grpc_settings.py 파일을 수정할 때의 영향 링크 복사링크가 클립보드에 복사되었습니다!
gRPC 서버는 다양한 플랫폼 서비스 간의 인증을 지원합니다. grpc_settings.py 파일에서 설정을 변경하면 특히 연결 안정성 측면에서 gRPC 연결의 동작 및 성능에 큰 영향을 미칠 수 있습니다.
gRPC 서버가 예상대로 작동하는지 확인하기 위해 프로덕션에 배포하기 전에 gRPC 설정에 대한 모든 변경 사항을 철저히 테스트하는 것이 중요합니다.
4.3. 설정 로드 순서 링크 복사링크가 클립보드에 복사되었습니다!
플랫폼 게이트웨이는 애플리케이션 설정을 관리하기 위해 Dynaconf 라이브러리를 활용합니다. Dynaconf는 여러 소스의 설정이 정의된 순서로 로드되고 나중에 소스가 이전 소스를 재정의하는 계층화된 구성 접근 방식을 따릅니다. Ansible Automation Platform은 다음 순서로 설정을 로드합니다.
- 애플리케이션 설정.py: 이 파일은 애플리케이션 자체에 있으며 추가 설정 파일의 로드 순서와 위치를 정의합니다.
- 애플리케이션 기본 설정: 플랫폼은 애플리케이션 자체의 일부인 defaults.py 파일에서 기본 설정을 로드합니다. 이 파일에는 API 서버와 gRPC 서버 모두에 대한 일반 구성이 포함되어 있습니다.
-
고객 덮어쓰기 파일:
/etc/ansible-automation-platform/gateway/settings.py파일이 자동으로 설치되고defaults.py의 설정을 재정의하는 데 사용할 수 있습니다. 이 파일의 변경 사항은 API 및 gRPC 서버 모두에 영향을 미칩니다. -
Application gRPC 기본 설정: 고객이 파일을 재정의한 후 애플리케이션은
grpc_default.py파일에서만 gRPC 서버에 대한 추가 기본 설정을 로드합니다. 특히 이 파일에는 keepalive 매개변수와 같은 gRPC 서버의 데이터베이스 OPTIONS가 포함됩니다. -
Customer gRPC 덮어쓰기 파일:
/etc/ansible-automation-platform/gateway/grpc_settings.py파일이 다음에 로드되고 이 파일에 포함된 모든 설정은 gRPC 서버에만 적용됩니다. -
플랫폼 덮어쓰기 설정 파일:
/etc/ansible-automation-platform/settings.py파일의 모든 설정은 gRPC 서버와 API 서버 모두에 적용됩니다. 단일 노드에 Ansible Automation Platform 서비스가 여러 개 있는 경우 이 파일의 항목이 모든 서비스에 적용됩니다. - ENV vars: 구성 파일 외부에서 특정 Ansible Automation Platform 설정을 구성할 수 있는 환경 변수가 마지막으로 로드됩니다. 이전에 로드된 모든 설정을 재정의합니다.
5장. 자동화 컨트롤러에서 사용성 분석 및 데이터 수집 관리 링크 복사링크가 클립보드에 복사되었습니다!
자동화 컨트롤러 사용자 인터페이스에서 설정을 선택하거나 변경하여 자동화 컨트롤러에서 사용성 분석 및 데이터 수집에 참여하는 방법을 변경할 수 있습니다.
5.1. 유용성 분석 및 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
사용성 데이터 수집은 자동화 컨트롤러 사용자가 자동화 컨트롤러와 구체적으로 상호 작용하는 방식을 더 잘 이해하고, 향후 릴리스를 개선하고, 사용자 환경을 계속 간소화하기 위해 데이터를 수집할 수 있는 자동화 컨트롤러에 포함되어 있습니다.
자동화 컨트롤러 평가판 또는 자동화 컨트롤러 신규 설치를 설치하는 사용자만 이 데이터 수집에 옵트인됩니다.
5.1.1. 자동화 컨트롤러에서 데이터 수집 제어 링크 복사링크가 클립보드에 복사되었습니다!
자동화 컨트롤러에서 → → 메뉴에서 데이터를 수집하는 방법을 제어할 수 있습니다.
프로세스
- 자동화 컨트롤러에 로그인합니다.
- 탐색 패널에서 → → 을 선택합니다.
- Automation Analytics에 대한 데이터 수집을 선택하여 자동화 컨트롤러에서 자동화에 대한 데이터를 수집하여 Automation Analytics로 보낼 수 있습니다.
6장. SSL/TLS 인증서 갱신 및 변경 링크 복사링크가 클립보드에 복사되었습니다!
현재 SSL/TLS 인증서가 만료되었거나 곧 만료되는 경우 Ansible Automation Platform에서 사용하는 SSL/TLS 인증서를 갱신하거나 교체할 수 있습니다.
새 호스트와 같은 새 정보로 다시 생성해야 하는 경우 SSL/TLS 인증서를 갱신해야 합니다.
내부 인증 기관에서 서명한 인증서를 사용하려면 SSL/TLS 인증서를 교체해야 합니다.
6.1. 컨테이너 기반 설치 링크 복사링크가 클립보드에 복사되었습니다!
컨테이너 기반 Ansible Automation Platform 설치에 대한 TLS 인증서 및 키를 변경할 수 있습니다. 이 프로세스에는 새 사용자 지정 인증서를 제공하거나 이전 인증서를 삭제하거나 이동한 다음 설치 프로그램을 실행하는 준비 단계가 포함됩니다.
6.1.1. 설치 프로그램을 사용하여 TLS 인증서 및 키 변경 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 설치 프로그램을 사용하여 TLS 인증서 및 키를 업데이트하는 방법을 설명합니다.
프로세스
인증서 및 키를 준비하려면 다음 방법 중 하나를 선택합니다.
사용자 정의 인증서 제공 - 업데이트된 TLS 인증서가 필요한 각 서비스에 대해 새 인증서와 키를 Ansible Automation Platform 설치 프로그램을 기준으로 경로에 복사합니다. 그런 다음 새 파일의 절대 경로로 인벤토리 파일 변수를 업데이트합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새 인증서를 생성하려면 설치 프로그램에서 서비스에 대한 새 인증서를 생성하거나 기존 인증서 및 키를 삭제하거나 이동합니다.
Expand 표 6.1. 서비스당 인증서 및 키 파일 경로 서비스 인증서 파일 경로 키 파일 경로 자동화 컨트롤러
~/AAP/controller/etc/tower.cert~/AAP/controller/etc/tower.key이벤트 기반 Ansible
~/aap/eda/etc/eda.cert~/aap/eda/etc/eda.key플랫폼 게이트웨이
~/aap/gateway/etc/gateway.cert~/aap/gateway/etc/gateway.key자동화 허브
~/AAP/hub/etc/pulp.cert~/AAP/hub/etc/pulp.keyPostgreSQL
~/aap/postgresql/server.crt~/aap/postgresql/server.key수신기
~/AAP/receptor/etc/receptor.crt~/AAP/receptor/etc/receptor.keyRedis
~/AAP/redis/server.crt~/AAP/redis/server.key
인증서를 준비한 후 설치 디렉터리에서
설치플레이북을 실행합니다.ansible-playbook -i <inventory_file_name> ansible.containerized_installer.install
ansible-playbook -i <inventory_file_name> ansible.containerized_installer.installCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
서비스가 실행 중이고 액세스 가능한지 확인하여 새 TLS 인증서가 사용 중인지 확인합니다. 이렇게 하려면 curl 을 사용하여 특정 끝점을 확인합니다.
curl -vk https://<hostname_or_ip>:<port_number>/api/v2/
$ curl -vk https://<hostname_or_ip>:<port_number>/api/v2/
이 명령의 출력은 TLS 핸드셰이크에 대한 세부 정보를 제공합니다. 다음 출력을 검색하여 올바른 인증서가 사용 중인지 확인합니다.
* SSL certificate verify OK
* SSL certificate verify OK
6.2. Operator 기반 설치 링크 복사링크가 클립보드에 복사되었습니다!
6.2.1. OpenShift Container Platform의 자동화 컨트롤러에서 SSL 인증서 및 키 변경 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 OpenShift Container Platform에서 실행되는 자동화 컨트롤러의 SSL 인증서 및 키를 변경하는 방법을 설명합니다.
프로세스
- 서명된 SSL 인증서 및 키를 보안 위치에 복사합니다.
OpenShift 내에 TLS 시크릿을 생성합니다.
oc create secret tls ${CONTROLLER_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyoc create secret tls ${CONTROLLER_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 자동화 컨트롤러 사용자 정의 리소스를 수정하여
route_tls_secret및 새 시크릿 이름을 spec 섹션에 추가합니다.oc edit automationcontroller/${CONTROLLER_INSTANCE}oc edit automationcontroller/${CONTROLLER_INSTANCE}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ... spec: route_tls_secret: automation-controller-certs-2023-04-06 ...
... spec: route_tls_secret: automation-controller-certs-2023-04-06 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TLS 시크릿의 이름은 임의의 이름입니다. 이 예에서는 시크릿이 생성된 날짜로 타임스탬프를 지정하여 자동화 컨트롤러 인스턴스에 적용된 다른 TLS 보안과 구별합니다.
- 변경 사항을 적용할 때까지 몇 분 정도 기다립니다.
새 SSL 인증서 및 키가 설치되었는지 확인합니다.
true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.2. OpenShift Container Platform에서 자동화 허브의 SSL 인증서 및 키 변경 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 OpenShift Container Platform에서 실행되는 자동화 허브의 SSL 인증서 및 키를 변경하는 방법을 설명합니다.
프로세스
- 서명된 SSL 인증서 및 키를 보안 위치에 복사합니다.
OpenShift 내에 TLS 시크릿을 생성합니다.
oc create secret tls ${AUTOMATION_HUB_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyoc create secret tls ${AUTOMATION_HUB_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 자동화 허브 사용자 정의 리소스를 수정하여
route_tls_secret및 새 시크릿 이름을 spec 섹션에 추가합니다.oc edit automationhub/${AUTOMATION_HUB_INSTANCE}oc edit automationhub/${AUTOMATION_HUB_INSTANCE}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ... spec: route_tls_secret: automation-hub-certs-2023-04-06 ...
... spec: route_tls_secret: automation-hub-certs-2023-04-06 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TLS 시크릿의 이름은 임의의 이름입니다. 이 예에서는 시크릿이 생성된 날짜로 타임스탬프를 지정하여 자동화 허브 인스턴스에 적용된 다른 TLS 시크릿과 구별합니다.
- 변경 사항을 적용할 때까지 몇 분 정도 기다립니다.
새 SSL 인증서 및 키가 설치되었는지 확인합니다.
true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3. RPM 기반 설치 링크 복사링크가 클립보드에 복사되었습니다!
RPM 기반 설치를 위한 SSL 인증서를 갱신하거나 변경하려면 인벤토리 파일을 편집하고 설치 프로그램을 실행할 수 있습니다. 설치 프로그램은 모든 Ansible Automation Platform 구성 요소가 작동하는지 확인합니다.
또는 수동으로 SSL 인증서를 변경할 수 있습니다. 이는 더 빠르지만 자동 확인은 없습니다.
설치 프로그램을 사용하여 Ansible Automation Platform 배포를 변경하는 것이 좋습니다.
6.3.1. 자체 서명된 SSL/TLS 인증서 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
다음 단계에서는 모든 Ansible Automation Platform 구성 요소에 대해 새 SSL/TLS 인증서를 다시 생성합니다.
프로세스
[all:vars]섹션의 인벤토리 파일에aap_service_regen_cert=true를 추가합니다.[all:vars] aap_service_regen_cert=true
[all:vars] aap_service_regen_cert=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 설치 프로그램을 실행합니다.
검증
Event-Driven Ansible 컨트롤러에서 CA 파일 및 인증서 파일을 검증합니다.
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/eda/server.cert openssl s_client -connect <EDA_FQDN>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/eda/server.cert openssl s_client -connect <EDA_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 플랫폼 게이트웨이에서 CA 파일 및 인증서 파일을 확인합니다.
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/gateway/gateway.cert openssl s_client -connect <GATEWAY_FQDN>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/gateway/gateway.cert openssl s_client -connect <GATEWAY_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 자동화 허브에서 CA 파일 및 인증서 파일을 확인합니다.
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/pulp/certs/pulp_webserver.crt openssl s_client -connect <HUB_FQDN>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/pulp/certs/pulp_webserver.crt openssl s_client -connect <HUB_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 자동화 컨트롤러에서 CA 파일 및 인증서 파일을 확인합니다.
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert openssl s_client -connect <CONTROLLER_FQDN>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert openssl s_client -connect <CONTROLLER_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2. 설치 프로그램을 사용하여 SSL/TLS 인증서 및 키 변경 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 인벤토리 파일에서 SSL/TLS 인증서 및 키를 변경하는 방법을 설명합니다.
사전 요구 사항
- 인증서는 PEM 형식이어야 합니다.
- 중간 인증 기관이 있는 경우 서버 인증서에 추가해야 합니다.
- 인증서에 대해 올바른 순서를 사용합니다. 서버 인증서가 먼저 오고 중간 인증 기관이 있습니다.
자세한 내용은 NGINX 문서의 ssl 인증서 섹션을 참조하십시오.
프로세스
- 새 SSL/TLS 인증서 및 키를 Ansible Automation Platform 설치 프로그램 관련 경로에 복사합니다.
SSL/TLS 인증서 및 키의 절대 경로를 인벤토리 파일에 추가합니다. 이러한 변수 설정에 대한 지침은 인벤토리 파일 변수를 참조하십시오.
-
이벤트 기반 Ansible 컨트롤러:
automationedacontroller_ssl_cert,automationedacontroller_ssl_key,custom_ca_cert -
플랫폼 게이트웨이:
automationgateway_ssl_cert,automationgateway_ssl_key,custom_ca_cert -
자동화 허브:
automationhub_ssl_cert,automationhub_ssl_key,custom_ca_cert 자동화 컨트롤러:
web_server_ssl_cert,web_server_ssl_key,custom_ca_cert참고custom_ca_cert는 중간 인증 기관에 서명한 루트 인증 기관이어야 합니다. 이 파일은/etc/pki/ca-trust/source/anchors에 설치됩니다.
-
이벤트 기반 Ansible 컨트롤러:
- 설치 프로그램을 실행합니다.
6.3.3. 수동으로 SSL/TLS 인증서 및 키 변경 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 모든 Ansible Automation Platform 구성 요소에 대해 SSL/TLS 인증서 및 키를 수동으로 변경하는 방법을 설명합니다.
프로세스
현재 SSL/TLS 인증서를 백업합니다.
cp <CERT_PATH> <CERT_PATH>-$(date +%F)
cp <CERT_PATH> <CERT_PATH>-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 현재 키 파일을 백업합니다.
cp <KEY_PATH> <KEY_PATH>-$(date +%F)
cp <KEY_PATH> <KEY_PATH>-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 새 SSL/TLS 인증서를 인증서 경로에 복사합니다.
- 새 키를 키 경로에 복사합니다.
SELinux 컨텍스트를 복원합니다.
restorecon -v <CERT_PATH> <KEY_PATH>
restorecon -v <CERT_PATH> <KEY_PATH>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 인증서 및 키 파일에 대한 적절한 권한을 설정합니다.
chown <OWNER>:<GROUP> <CERT_PATH> <KEY_PATH> chmod 0600 <CERT_PATH> <KEY_PATH>
chown <OWNER>:<GROUP> <CERT_PATH> <KEY_PATH> chmod 0600 <CERT_PATH> <KEY_PATH>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NGINX 구성을 테스트합니다.
nginx -t
nginx -tCopy to Clipboard Copied! Toggle word wrap Toggle overflow NGINX를 다시 로드합니다.
systemctl reload nginx.service
systemctl reload nginx.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 새 SSL/TLS 인증서 및 키가 설치되었는지 확인합니다.
true | openssl s_client -showcerts -connect <COMPONENT_FQDN>:443
true | openssl s_client -showcerts -connect <COMPONENT_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 표 6.2. SSL/TLS 인증서 및 서비스당 키 파일 경로 서비스 인증서 파일 경로 키 파일 경로 소유자:Group 자동화 컨트롤러
/etc/tower/tower.cert/etc/tower/tower.keyroot:awx자동화 허브
/etc/pulp/certs/pulp_webserver.crt/etc/pulp/certs/pulp_webserver.keyroot:pulp이벤트 기반 Ansible 컨트롤러
/etc/ansible-automation-platform/eda/server.cert/etc/ansible-automation-platform/eda/server.keyroot:eda플랫폼 게이트웨이
/etc/ansible-automation-platform/gateway/gateway.cert/etc/ansible-automation-platform/gateway/gateway.keyroot:gateway