RHEL 시스템 역할을 사용하여 시스템 관리 자동화
Red Hat Ansible Automation Platform 플레이북을 사용하여 여러 호스트에서 RHEL 배포의 일관되고 반복 가능한 구성
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서 및 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.
특정 문구에 대한 의견 제출
- Multi-page HTML 형식으로 설명서를 보고 페이지가 완전히 로드된 후 오른쪽 상단 모서리에 피드백 버튼이 표시되는지 확인합니다.
- 커서를 사용하여 주석 처리할 텍스트 부분을 강조 표시합니다.
- 강조 표시된 텍스트 옆에 표시되는 피드백 추가 버튼을 클릭합니다.
- 의견을 추가하고 제출을 클릭합니다.
Jira를 통해 피드백 제출 (등록 필요)
- Jira 웹 사이트에 로그인합니다.
- 상단 탐색 모음에서 생성 을 클릭합니다.
- 요약 필드에 설명 제목을 입력합니다.
- 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
- 대화 상자 하단에서 생성 을 클릭합니다.
1장. RHEL 시스템 역할 소개
RHEL 시스템 역할은 Ansible 역할 및 모듈의 컬렉션입니다. RHEL 시스템 역할을 사용하면 RHEL의 주요 버전에서 여러 RHEL 시스템의 시스템 구성을 원격으로 관리할 수 있습니다. 이 구성 요소를 사용하여 시스템을 구성하려면 다음 구성 요소를 사용해야 합니다.
- 제어 노드
- 제어 노드는 Ansible 명령 및 플레이북을 실행하는 시스템입니다. 제어 노드는 Ansible Automation Platform, Red Hat Satellite 또는 RHEL 9, 8 또는 7 호스트일 수 있습니다. 자세한 내용은 RHEL 8에서 제어 노드 준비를 참조하십시오.
- 관리형 노드
- 관리형 노드는 Ansible을 사용하여 관리하는 서버 및 네트워크 장치입니다. 관리 노드는 호스트라고도 합니다. Ansible을 관리형 노드에 설치할 필요가 없습니다. 자세한 내용은 관리 노드 준비를 참조하십시오.
- Ansible 플레이북
- 플레이북에서는 관리형 노드에서 수행할 구성을 정의하거나 수행할 관리 노드의 시스템 단계 세트를 정의합니다. Ansible 플레이북은 Ansible의 구성, 배포 및 오케스트레이션 언어입니다.
- 인벤토리
- 인벤토리 파일에서 관리 노드를 나열하고 각 관리 노드의 IP 주소와 같은 정보를 지정합니다. 인벤토리에서는 더 쉽게 스케일링할 수 있도록 그룹을 생성하고 중첩하여 관리 노드를 구성할 수도 있습니다. 인벤토리 파일은 hostfile이라고도 합니다.
Red Hat Enterprise Linux 8에서는 AppStream
리포지토리에서 사용할 수 있는 rhel-system-roles
패키지에서 제공하는 다음 역할을 사용할 수 있습니다.
역할 이름 | 역할 설명 | 장 제목 |
---|---|---|
| 인증서 발급 및 갱신 | RHEL System Roles를 사용하여 인증서 요청 |
| 웹 콘솔 | RHEL 시스템 역할을 사용하여 웹 콘솔 설치 및 구성 |
| 시스템 전체 암호화 정책 | 시스템 전체에서 사용자 정의 암호화 정책 설정 |
| firewalld | 시스템 역할을 사용하여 firewalld 구성 |
| HA Cluster | 시스템 역할을 사용하여 고가용성 클러스터 구성 |
| 커널 덤프 | RHEL 시스템 역할을 사용하여 kdump 구성 |
| 커널 설정 | Ansible 역할을 사용하여 커널 매개변수 영구 구성 |
| 로깅 | 로깅 시스템 역할 사용 |
| 메트릭 (PCP) | RHEL 시스템 역할을 사용하여 성능 모니터링 |
| Microsoft SQL Server | windows.sql.server Ansible 역할을 사용하여 Microsoft SQL Server 구성 |
| 네트워킹 | 네트워크 RHEL 시스템 역할을 사용하여 InfiniBand 연결 관리 |
| 네트워크 Bound 디스크 암호화 클라이언트 | nbde_client 및 nbde_server 시스템 역할 사용 |
| 네트워크 Bound 디스크 암호화 서버 | nbde_client 및 nbde_server 시스템 역할 사용 |
| Postfix | 시스템 역할에서 postfix 역할의 변수 |
| SELinux | 시스템 역할을 사용하여 SELinux 구성 |
| SSH 클라이언트 | ssh 시스템 역할을 사용하여 보안 통신 구성 |
| SSH 서버 | ssh 시스템 역할을 사용하여 보안 통신 구성 |
| 스토리지 | RHEL 시스템 역할을 사용하여 로컬 스토리지 관리 |
| 터미널 세션 레코드 | tlog RHEL 시스템 역할을 사용하여 세션 레코딩을 위한 시스템 구성 |
| 시간 동기화 | RHEL 시스템 역할을 사용하여 시간 동기화 구성 |
| VPN | vpn RHEL 시스템 역할을 사용하여 IPsec과 VPN 연결 구성 |
추가 리소스
- Red Hat Enterprise Linux (RHEL) 시스템 역할
-
rhel-system-roles 패키지에서 제공하는 /usr/share/doc
/rhel-system-roles
/
2장. RHEL 시스템 역할을 사용하도록 제어 노드 및 관리형 노드 준비
개별 RHEL 시스템 역할을 사용하여 서비스 및 설정을 관리하려면 먼저 제어 노드 및 관리 노드를 준비해야 합니다.
2.1. RHEL 8에서 제어 노드 준비
RHEL 시스템 역할을 사용하기 전에 제어 노드를 구성해야 합니다. 그런 다음 이 시스템은 플레이북에 따라 인벤토리에서 관리 호스트를 구성합니다.
사전 요구 사항
- RHEL 8.6 이상이 설치되어 있어야 합니다. RHEL 설치에 대한 자세한 내용은 표준 RHEL 8 설치 수행을 참조하십시오.
- 시스템이 고객 포털에 등록되어 있습니다.
-
Red Hat Enterprise Linux Server
서브스크립션이 시스템에 연결되어 있습니다. -
고객 포털 계정에서 사용 가능한 경우
Ansible Automation Platform
서브스크립션이 시스템에 연결됩니다.
절차
rhel-system-roles
패키지를 설치합니다.[root@control-node]# yum install rhel-system-roles
이 명령은
ansible-core
패키지를 종속성으로 설치합니다.참고RHEL 8.5 및 이전 버전에서 Ansible 패키지는 Ansible Core 대신 Ansible Engine을 통해 제공되었으며 다른 수준의 지원이 제공되었습니다. 패키지가 RHEL 8.6 이상의 Ansible 자동화 콘텐츠와 호환되지 않을 수 있으므로 Ansible Engine을 사용하지 마십시오. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리에 포함된 Ansible Core 패키지에 대한 지원 범위를 참조하십시오.
ansible
이라는 사용자를 생성하여 플레이북을 관리하고 실행합니다.[root@control-node]# useradd ansible
새로 생성된
ansible
사용자로 전환합니다.[root@control-node]# su - ansible
이 사용자로 나머지 절차를 수행하십시오.
SSH 공개 및 개인 키를 생성합니다.
[ansible@control-node]$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/ansible/.ssh/id_rsa): <password> ...
권장되는 기본 위치를 키 파일에 사용합니다.
- 선택 사항: Ansible에서 연결을 설정할 때마다 SSH 키 암호를 입력하라는 메시지를 표시하지 않도록 SSH 에이전트를 구성합니다.
다음 콘텐츠를 사용하여
~/.ansible.cfg
파일을 생성합니다.[defaults] inventory = /home/ansible/inventory remote_user = ansible [privilege_escalation] become = True become_method = sudo become_user = root become_ask_pass = True
참고~/.ansible.cfg
파일의 설정은 우선 순위가 높으며 글로벌/etc/ansible/ansible.cfg
파일의 설정을 덮어씁니다.이러한 설정을 통해 Ansible은 다음 작업을 수행합니다.
- 지정된 인벤토리 파일의 호스트를 관리합니다.
-
관리 노드에 대한 SSH 연결을 설정할 때
remote_user
매개변수에 설정된 계정을 사용합니다. -
sudo
유틸리티를 사용하여 관리 노드에서root
사용자로 작업을 실행합니다. - 플레이북을 적용할 때마다 원격 사용자의 루트 암호를 입력하라는 메시지를 표시합니다. 이는 보안상의 이유로 권장됩니다.
관리 호스트의 호스트 이름을 나열하는 INI 또는 YAML 형식으로
~/inventory
파일을 생성합니다. 인벤토리 파일에서 호스트 그룹을 정의할 수도 있습니다. 예를 들어 다음은 3개의 호스트와US
라는 호스트 그룹이 포함된 INI 형식의 인벤토리 파일입니다.managed-node-01.example.com [US] managed-node-02.example.com ansible_host=192.0.2.100 managed-node-03.example.com
제어 노드는 호스트 이름을 확인할 수 있어야 합니다. DNS 서버가 특정 호스트 이름을 확인할 수 없는 경우 호스트 항목 옆에
ansible_host
매개 변수를 추가하여 IP 주소를 지정합니다.
다음 단계
- 관리형 노드를 준비합니다. 자세한 내용은 관리 노드 준비를 참조하십시오.
2.2. 관리형 노드 준비
관리형 노드는 인벤토리에 나열되는 시스템이며, 플레이북에 따라 제어 노드에서 구성합니다. 관리 호스트에 Ansible을 설치할 필요가 없습니다.
사전 요구 사항
- 제어 노드가 준비되었습니다. 자세한 내용은 RHEL 8에서 제어 노드 준비를 참조하십시오.
제어 노드에서 SSH 액세스 권한이 있어야 합니다.
중요root
사용자로 직접 SSH 액세스는 보안 위험이 있습니다. 이 위험을 줄이기 위해 이 노드에 로컬 사용자를 생성하고 관리 노드를 준비할 때sudo
정책을 구성합니다. 그런 다음 제어 노드의 Ansible은 로컬 사용자 계정을 사용하여 관리 노드에 로그인하고root
와 같은 다른 사용자로 플레이북을 실행할 수 있습니다.
절차
ansible
이라는 사용자를 생성합니다.[root@managed-node-01]# useradd ansible
나중에 제어 노드는 이 사용자를 사용하여 이 호스트에 대한 SSH 연결을 설정합니다.
ansible
사용자의 암호를 설정합니다.[root@managed-node-01]# passwd ansible Changing password for user ansible. New password: <password> Retype new password: <password> passwd: all authentication tokens updated successfully.
Ansible에서
sudo
를 사용하여root
사용자로 작업을 수행할 때 이 암호를 입력해야 합니다.관리 노드에
ansible
사용자의 SSH 공개 키를 설치합니다.제어 노드에
ansible
사용자로 로그인하고 SSH 공개 키를 관리 노드에 복사합니다.[ansible@control-node]$ ssh-copy-id managed-node-01.example.com /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/ansible/.ssh/id_rsa.pub" The authenticity of host 'managed-node-01.example.com (192.0.2.100)' can't be established. ECDSA key fingerprint is SHA256:9bZ33GJNODK3zbNhybokN/6Mq7hu3vpBXDrCxe7NAvo.
프롬프트가 표시되면
yes
를 입력하여 연결합니다.Are you sure you want to continue connecting (yes/no/[fingerprint])? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
암호를 입력하라는 메시지가 표시되면 암호를 입력합니다.
ansible@managed-node-01.example.com's password: <password> Number of key(s) added: 1 Now try logging into the machine, with: "ssh '<managed-node-01.example.com>'" and check to make sure that only the key(s) you wanted were added.
제어 노드에서 명령을 원격으로 실행하여 SSH 연결을 확인합니다.
[ansible@control-node]$ ssh <managed-node-01.example.com> whoami ansible
ansible
사용자에 대한sudo
구성을 생성합니다.visudo
명령을 사용하여/etc/sudoers.d/ansible
파일을 만들고 편집합니다.[root@managed-node-01]# visudo /etc/sudoers.d/ansible
일반 편집기에서
visudo
를 사용할 때의 이점은 이 유틸리티에서 파일을 설치하기 전에 기본 온전성 검사를 제공하고 구문 분석 오류를 확인하는 것입니다.요구 사항을 충족하는
/etc/
파일에서 sudoers 정책을 구성합니다. 예를 들면 다음과 같습니다.sudoers
.d/ansibleansible
사용자 암호를 입력한 후ansible
사용자에게 모든 명령을 실행하여 이 호스트에서 모든 명령을 실행할 수 있는 권한을 부여하려면 다음을 사용합니다.ansible ALL=(ALL) ALL
ansible
사용자에게ansible
사용자 암호를 입력하지 않고 이 호스트에서 모든 명령을 실행할 수 있는 권한을 부여하려면 다음을 사용합니다.ansible ALL=(ALL) NOPASSWD: ALL
또는 보안 요구 사항과 일치하는 보다 세분화된 정책을 구성합니다.
sudoers
정책에 대한 자세한 내용은sudoers(5)
매뉴얼 페이지를 참조하십시오.
검증
모든 관리형 노드의 제어 노드에서 명령을 실행할 수 있는지 확인합니다.
[ansible@control-node]$ ansible all -m ping BECOME password: <password> managed-node-01.example.com | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python3" }, "changed": false, "ping": "pong" } ...
하드 코딩된 모든 그룹에는 인벤토리 파일에 나열된 모든 호스트가 동적으로 포함됩니다.
Ansible
command
모듈을 사용하여 관리 호스트에서whoami
유틸리티를 실행하여 권한 상승이 올바르게 작동하는지 확인합니다.[ansible@control-node]$ ansible managed-node-01.example.com -m command -a whoami BECOME password: <password> managed-node-01.example.com | CHANGED | rc=0 >> root
명령이 root를 반환하면 관리 노드에서
sudo
를 올바르게 구성한 것입니다.
추가 리소스
- RHEL 8에서 제어 노드 준비.
-
sudoers(5)
매뉴얼 페이지
3장. 컬렉션 설치 및 사용
3.1. Ansible 컬렉션 소개
Ansible Collections는 자동화를 배포, 유지 관리 및 사용하는 새로운 방법입니다. 플레이북, 역할, 모듈 및 플러그인과 같은 여러 유형의 Ansible 콘텐츠를 결합하여 유연성과 확장성을 개선할 수 있습니다.
Ansible 컬렉션은 기존 RHEL 시스템 역할 형식의 옵션입니다. Ansible Collection 형식에서 RHEL 시스템 역할을 사용하는 것은 기존 RHEL 시스템 역할 형식에서 사용하는 것과 거의 동일합니다. 차이점은 Ansible Collections가 네임스페이스
와 컬렉션 이름으로 구성된 정규화된 컬렉션 이름
(FQCN) 개념을 사용한다는 것입니다. 사용하는
네임스페이스
는 redhat
이며 컬렉션 이름은
rhel_system_roles
입니다. 따라서 kernel_settings
역할의 기존 RHEL 시스템 역할 형식은 rhel-system-roles.kernel_settings
로 표시되지만 kernel_settings
역할에 대해 정규화된 컬렉션 이름을
사용하여 rhel-system-roles.kernel_settings
로 표시됩니다.
네임스페이스
와 컬렉션 이름을 결합하면
오브젝트가 고유합니다. 또한 충돌 없이 Ansible 컬렉션 및 네임스페이스에서 오브젝트가 공유되도록 합니다.
추가 리소스
- Automation Hub 에 액세스하여 Red Hat Certified Collections를 사용하려면 AAP(Ansible Automation Platform)가 있어야 합니다.
3.2. 컬렉션 구조
컬렉션은 Ansible 콘텐츠의 패키지 형식입니다. 데이터 구조는 다음과 같습니다.
- docs/: 역할이 문서를 제공하는 경우 예제와 함께 컬렉션에 대한 로컬 설명서
- Galaxy.yml: Ansible Collection 패키지에 포함될 MANIFEST.json의 소스 데이터
playbooks/: Playbook은 여기에서 사용할 수 있습니다.
- tasks/: include_tasks/import_tasks 사용에 대해 '작업 목록 파일'이 있습니다.
plugins/: 모든 Ansible 플러그인 및 모듈을 여기에서 사용할 수 있으며, 각 플러그인의 하위 디렉터리
- modules/: Ansible 모듈
- modules_utils/: 모듈 개발을 위한 공통 코드
- lookup/: 플러그인 검색
- filter/: Jinja2 필터 플러그인
- connection/: 기본값을 사용하지 않는 경우 필요한 연결 플러그인
- roles/: Ansible 역할을 위한 디렉터리
- tests/: 컬렉션의 콘텐츠에 대한 테스트
3.3. CLI를 사용하여 컬렉션 설치
컬렉션은 플레이북, 역할, 모듈 및 플러그인을 포함할 수 있는 Ansible 콘텐츠의 배포 형식입니다.
Ansible Galaxy를 통해 또는 명령줄을 사용하여 컬렉션을 설치할 수 있습니다.
사전 요구 사항
- 하나 이상의 관리 노드에 대한 액세스 및 권한.
Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다. - 관리 노드를 나열하는 인벤토리 파일이 있어야 합니다.
-
절차
RPM 패키지를 통해 컬렉션을 설치합니다.
# yum install rhel-system-roles
설치가 완료되면 redhat.rhel_system_roles.<role_name>으로 역할을 사용할 수 있습니다
. 각 역할에 대한 설명서는 /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/roles/<role_name>/README.md
에서도 확인할 수 있습니다.
검증 단계
설치를 확인하려면 localhost에서 확인
모드로 kernel_settings
역할을 실행합니다. Ansible package
모듈에 필요하므로 --become
매개변수도 사용해야 합니다. 그러나 매개변수는 시스템을 변경하지 않습니다.
다음 명령을 실행합니다.
$ ansible-playbook -c local -i localhost, --check --become /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/tests/kernel_settings/tests_default.yml
명령 출력의 마지막 줄에는 failed=0
값이 포함되어야 합니다.
localhost
이후의 쉼표는 필수입니다. 목록에 호스트가 하나만 있는 경우에도 추가해야 합니다. ansible-playbook
이 없으면 localhost
를 파일 또는 디렉터리로 식별합니다.
추가 리소스
-
ansible-playbook
매뉴얼 페이지. -
ansible-playbook
명령의-i
옵션
3.4. Automation Hub에서 컬렉션 설치
Automation Hub를 사용하는 경우 Automation Hub에 호스팅되는 RHEL 시스템 역할 컬렉션을 설치할 수 있습니다.
사전 요구 사항
- 하나 이상의 관리 노드에 대한 액세스 및 권한.
Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다. - 관리 노드를 나열하는 인벤토리 파일이 있어야 합니다.
-
절차
-
Red Hat Automation Hub를
ansible.cfg
구성 파일에 있는 콘텐츠의 기본 소스로 정의합니다. 콘텐츠의 기본 소스로 Red Hat Automation Hub 구성을 참조하십시오. Automation Hub에서
redhat.rhel_system_roles
컬렉션을 설치합니다.# ansible-galaxy collection install redhat.rhel_system_roles
설치가 완료되면
redhat.rhel_system_roles.<role_name>으로 역할을 사용할 수 있습니다
. 각 역할에 대한 설명서는/usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/roles/<role_name>/README.md
에서도 확인할 수 있습니다.
검증 단계
설치를 확인하려면 localhost에서 확인
모드로 kernel_settings
역할을 실행합니다. Ansible package
모듈에 필요하므로 --become
매개변수도 사용해야 합니다. 그러나 매개변수는 시스템을 변경하지 않습니다.
다음 명령을 실행합니다.
$ ansible-playbook -c local -i localhost, --check --become /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/tests/kernel_settings/tests_default.yml
명령 출력의 마지막 줄에는 failed=0
값이 포함되어야 합니다.
localhost
이후의 쉼표는 필수입니다. 목록에 호스트가 하나만 있는 경우에도 추가해야 합니다. ansible-playbook
이 없으면 localhost
를 파일 또는 디렉터리로 식별합니다.
추가 리소스
-
ansible-playbook
매뉴얼 페이지. -
ansible-playbook
명령의-i
옵션
3.5. 컬렉션을 사용하여 로컬 로깅 시스템 역할 적용
다음은 컬렉션을 사용하여 Ansible 플레이북을 준비 및 적용하여 별도의 머신 세트에서 로깅 솔루션을 구성하는 예입니다.
사전 요구 사항
- rhel-system-roles의 컬렉션 형식은 rpm 패키지 또는 Automation Hub에서 설치됩니다.
절차
필요한 역할을 정의하는 플레이북을 생성합니다.
새 YAML 파일을 생성하고 텍스트 편집기에서 엽니다. 예를 들면 다음과 같습니다.
# vi logging-playbook.yml
YAML 파일에 다음 내용을 삽입합니다.
--- - name: Deploying basics input and implicit files output hosts: all roles: - redhat.rhel_system_roles.logging vars: logging_inputs: - name: system_input type: basics logging_outputs: - name: files_output type: files logging_flows: - name: flow1 inputs: [system_input] outputs: [files_output]
특정 인벤토리에서 플레이북을 실행합니다.
# ansible-playbook -i inventory-file logging-playbook.yml
다음과 같습니다.
- inventory-file 은 인벤토리 파일의 이름입니다.
- logging-playbook.yml 은 사용하는 플레이북입니다.
검증 단계
구성 파일
/etc/rsyslog.conf
및/etc/rsyslog.d
:의 구문을 테스트합니다.# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye.
시스템이 로그에 메시지를 전송하는지 확인합니다.
테스트 메시지를 보냅니다.
# logger test
/var/log/ECDHE 로그를 확인합니다.
예를 들면 다음과 같습니다.# cat /var/log/messages Aug 5 13:48:31 hostname root[6778]: test
호스트
이름은 클라이언트 시스템의 호스트 이름입니다. 로그에 logger 명령을 입력한 사용자의 사용자 이름이 표시됩니다(이 경우root
).
4장. RHEL의 Ansible IPMI 모듈
4.1. rhel_mgmt 컬렉션
IPMI(Intelligent Platform Management Interface)는 BMC(Baseboard Management Controller) 장치와 통신하기 위한 표준 프로토콜 집합의 사양입니다. IPMI
모듈을 사용하면 하드웨어 관리 자동화를 활성화하고 지원할 수 있습니다. IPMI
모듈은 다음에서 사용할 수 있습니다.
-
rhel_mgmt
컬렉션 패키지 이름은ansible-collection-redhat-rhel_mgmt
입니다. -
새로운
ansible-collection-redhat-rhel_mgmt
패키지의 일부로 RHEL 8 AppStream.
다음 IPMI 모듈은 rhel_mgmt 컬렉션에서 사용할 수 있습니다.
-
ipmi_boot
: 부팅 장치 순서 관리 -
ipmi_power
: 머신의 전원 관리
IPMI 모듈에 사용되는 필수 매개변수는 다음과 같습니다.
-
ipmi_boot
매개변수:
모듈 이름 | 설명 |
---|---|
name | BMC의 호스트 이름 또는 IP 주소 |
암호 | BMC에 연결할 암호입니다. |
bootdev | 다음 부팅에서 사용할 장치 * 네트워크 * 플로피 *HD * 안전 * 최적 * 설정 * 기본 |
사용자 | BMC에 연결할 사용자 이름 |
-
ipmi_power
매개변수:
모듈 이름 | 설명 |
---|---|
name | BMC 호스트 이름 또는 IP 주소 |
암호 | BMC에 연결할 암호입니다. |
user | BMC에 연결할 사용자 이름 |
상태 | 시스템이 원하는 상태에 있는지 확인 * On * off * 종료 * 재설정 * 부팅 |
4.2. CLI를 사용하여 rhel mgmt 컬렉션 설치
명령줄을 사용하여 rhel_mgmt
컬렉션을 설치할 수 있습니다.
사전 요구 사항
-
ansible-core
패키지가 설치되어 있습니다.
절차
RPM 패키지를 통해 컬렉션을 설치합니다.
# yum install ansible-collection-redhat-rhel_mgmt
설치가 완료되면
redhat.rhel_mgmt
Ansible 컬렉션에서 IPMI 모듈을 사용할 수 있습니다.
추가 리소스
-
ansible-playbook
매뉴얼 페이지.
4.3. ipmi_boot 모듈 사용 예
다음 예제는 플레이북에서 ipmi_boot
모듈을 사용하여 다음 부팅에 대한 부팅 장치를 설정하는 방법을 보여줍니다. 간단히 하기 위해 예제에서는 Ansible 제어 호스트 및 관리 호스트와 동일한 호스트를 사용하므로 플레이북이 실행되는 동일한 호스트에서 모듈을 실행합니다.
사전 요구 사항
- rhel_mgmt 컬렉션이 설치되어 있어야 합니다.
python3-
패키지의 pyghmi 라이브러리는 다음 위치 중 하나에 설치됩니다.pyghmi
- 플레이북을 실행하는 호스트입니다.
-
관리 호스트 localhost를 관리 호스트로 사용하는 경우 대신 플레이북을 실행하는 호스트에
python3-pyghmi
패키지를 설치합니다.
- 제어하려는 IPMI BMC는 플레이북을 실행하는 호스트에서 네트워크를 통해 또는 localhost를 관리 호스트로 사용하지 않는 경우 관리 호스트를 통해 액세스할 수 있습니다. 모듈에서 BMC를 구성하는 호스트는 일반적으로 모듈이 실행되는 호스트(Ansible 관리 호스트)가 IPMI 프로토콜을 사용하여 네트워크를 통해 BMC에 연결하므로 호스트와 다릅니다.
- 적절한 수준의 액세스 권한을 사용하여 BMC에 액세스할 수 있는 인증 정보가 있습니다.
절차
다음 내용으로 새 playbook.yml 파일을 생성합니다.
--- - name: Sets which boot device will be used on next boot hosts: localhost tasks: - redhat.rhel_mgmt.ipmi_boot: name: bmc.host.example.com user: admin_user password: basics bootdev: hd
localhost에 대해 플레이북을 실행합니다.
# ansible-playbook playbook.yml
결과적으로 출력은 "success" 값을 반환합니다.
4.4. ipmi_power 모듈 사용 예
이 예제에서는 플레이북에서 ipmi_boot
모듈을 사용하여 시스템이 설정되어 있는지 확인하는 방법을 보여줍니다. 간단히 하기 위해 예제에서는 Ansible 제어 호스트 및 관리 호스트와 동일한 호스트를 사용하므로 플레이북이 실행되는 동일한 호스트에서 모듈을 실행합니다.
사전 요구 사항
- rhel_mgmt 컬렉션이 설치되어 있어야 합니다.
python3-
패키지의 pyghmi 라이브러리는 다음 위치 중 하나에 설치됩니다.pyghmi
- 플레이북을 실행하는 호스트입니다.
-
관리 호스트 localhost를 관리 호스트로 사용하는 경우 대신 플레이북을 실행하는 호스트에
python3-pyghmi
패키지를 설치합니다.
- 제어하려는 IPMI BMC는 플레이북을 실행하는 호스트에서 네트워크를 통해 또는 localhost를 관리 호스트로 사용하지 않는 경우 관리 호스트를 통해 액세스할 수 있습니다. 모듈에서 BMC를 구성하는 호스트는 일반적으로 모듈이 실행되는 호스트(Ansible 관리 호스트)가 IPMI 프로토콜을 사용하여 네트워크를 통해 BMC에 연결하므로 호스트와 다릅니다.
- 적절한 수준의 액세스 권한을 사용하여 BMC에 액세스할 수 있는 인증 정보가 있습니다.
절차
다음 내용으로 새 playbook.yml 파일을 생성합니다.
--- - name: Turn the host on hosts: localhost tasks: - redhat.rhel_mgmt.ipmi_power: name: bmc.host.example.com user: admin_user password: basics state: on
플레이북을 실행합니다.
# ansible-playbook playbook.yml
출력에서 "true" 값을 반환합니다.
5장. RHEL의 Redfish 모듈
이제 장치의 원격 관리를 위한 Redfish 모듈이 redhat.rhel_mgmt
Ansible 컬렉션에 포함됩니다. Redfish 모듈을 사용하면 표준 HTTPS 전송 및 JSON 형식을 사용하여 서버에 대한 정보를 얻거나 OOB(Out-Of-Band) 컨트롤러를 통해 서버를 제어하는 방식으로 베어 메탈 서버 및 플랫폼 하드웨어에서 관리 자동화를 쉽게 사용할 수 있습니다.
5.1. Redfish 모듈
redhat.rhel_mgmt
Ansible 컬렉션은 Redfish를 통해 Ansible에서 하드웨어 관리를 지원하는 Redfish 모듈을 제공합니다. redhat.rhel_mgmt
컬렉션은 ansible-collection-redhat-rhel_mgmt
패키지에서 사용할 수 있습니다. 설치하려면 CLI를 사용하여 redhat.rhel_mgmt 컬렉션 설치를 참조하십시오.
다음 Redfish 모듈은 redhat.rhel_mgmt
컬렉션에서 사용할 수 있습니다.
-
redfish_info
:redfish_info
모듈은 시스템 인벤토리와 같은 원격 OOB(Out-Of-Band) 컨트롤러에 대한 정보를 검색합니다. -
redfish_command
:redfish_command
모듈은 로그 관리 및 사용자 관리와 같은 OOB(Out-Of-Band) 컨트롤러 작업과 시스템 재시작, 전원 켜기 및 off와 같은 전원 작업을 수행합니다. -
redfish_config
:redfish_config
모듈은 OOB 구성 변경 또는 BIOS 구성 설정과 같은 OOB 컨트롤러 작업을 수행합니다.
5.2. Redfish 모듈 매개변수
Redfish 모듈에 사용되는 매개변수는 다음과 같습니다.
redfish_info parameters: | 설명 |
---|---|
| (필수) - OOB 컨트롤러의 기본 URI입니다. |
| (필수) - OOB 컨트롤러에서 실행할 카테고리 목록입니다. 기본값은 ["Systems"]입니다. |
| (필수) - OOB 컨트롤러에서 실행할 명령 목록입니다. |
| OOB 컨트롤러에 대한 인증에 대한 사용자 이름입니다. |
| OOB 컨트롤러에 대한 인증 암호입니다. |
redfish_command 매개변수: | 설명 |
---|---|
| (필수) - OOB 컨트롤러의 기본 URI입니다. |
| (필수) - OOB 컨트롤러에서 실행할 카테고리 목록입니다. 기본값은 ["Systems"]입니다. |
| (필수) - OOB 컨트롤러에서 실행할 명령 목록입니다. |
| OOB 컨트롤러에 대한 인증에 대한 사용자 이름입니다. |
| OOB 컨트롤러에 대한 인증 암호입니다. |
redfish_config parameters: | 설명 |
---|---|
| (필수) - OOB 컨트롤러의 기본 URI입니다. |
| (필수) - OOB 컨트롤러에서 실행할 카테고리 목록입니다. 기본값은 ["Systems"]입니다. |
| (필수) - OOB 컨트롤러에서 실행할 명령 목록입니다. |
| OOB 컨트롤러에 대한 인증에 대한 사용자 이름입니다. |
| OOB 컨트롤러에 대한 인증 암호입니다. |
| 업데이트할 BIOS 속성입니다. |
5.3. redfish_info 모듈 사용
다음 예제는 플레이북에서 redfish_info
모듈을 사용하여 CPU 인벤토리에 대한 정보를 가져오는 방법을 보여줍니다. 간단히 하기 위해 예제에서는 Ansible 제어 호스트 및 관리 호스트와 동일한 호스트를 사용하므로 플레이북이 실행되는 동일한 호스트에서 모듈을 실행합니다.
사전 요구 사항
-
redhat.rhel_mgmt
컬렉션이 설치되어 있습니다. -
python3-
패키지의 pyghmi 라이브러리는 관리 호스트에 설치됩니다. localhost를 관리 호스트로 사용하는 경우 플레이북을 실행하는 호스트에pyghmi
python3-pyghmi
패키지를 설치합니다. - OOB 컨트롤러 액세스 세부 정보.
절차
다음 내용으로 새 playbook.yml 파일을 생성합니다.
--- - name: Get CPU inventory hosts: localhost tasks: - redhat.rhel_mgmt.redfish_info: baseuri: "{{ baseuri }}" username: "{{ username }}" password: "{{ password }}" category: Systems command: GetCpuInventory register: result
localhost에 대해 플레이북을 실행합니다.
# ansible-playbook playbook.yml
결과적으로 출력은 CPU 인벤토리 세부 정보를 반환합니다.
5.4. redfish_command 모듈 사용
다음 예제는 플레이북에서 redfish_command
모듈을 사용하여 시스템을 설정하는 방법을 보여줍니다. 간단히 하기 위해 예제에서는 Ansible 제어 호스트 및 관리 호스트와 동일한 호스트를 사용하므로 플레이북이 실행되는 동일한 호스트에서 모듈을 실행합니다.
사전 요구 사항
-
redhat.rhel_mgmt
컬렉션이 설치되어 있습니다. -
python3-
패키지의 pyghmi 라이브러리는 관리 호스트에 설치됩니다. localhost를 관리 호스트로 사용하는 경우 플레이북을 실행하는 호스트에pyghmi
python3-pyghmi
패키지를 설치합니다. - OOB 컨트롤러 액세스 세부 정보.
절차
다음 내용으로 새 playbook.yml 파일을 생성합니다.
--- - name: Power on system hosts: localhost tasks: - redhat.rhel_mgmt.redfish_command: baseuri: "{{ baseuri }}" username: "{{ username }}" password: "{{ password }}" category: Systems command: PowerOn
localhost에 대해 플레이북을 실행합니다.
# ansible-playbook playbook.yml
그 결과 시스템은 전원을 켭니다.
5.5. redfish_config 모듈 사용
다음 예제는 플레이북에서 redfish_config
모듈을 사용하여 UEFI로 부팅할 시스템을 구성하는 방법을 보여줍니다. 간단히 하기 위해 예제에서는 Ansible 제어 호스트 및 관리 호스트와 동일한 호스트를 사용하므로 플레이북이 실행되는 동일한 호스트에서 모듈을 실행합니다.
사전 요구 사항
-
redhat.rhel_mgmt
컬렉션이 설치되어 있습니다. -
python3-
패키지의 pyghmi 라이브러리는 관리 호스트에 설치됩니다. localhost를 관리 호스트로 사용하는 경우 플레이북을 실행하는 호스트에pyghmi
python3-pyghmi
패키지를 설치합니다. - OOB 컨트롤러 액세스 세부 정보.
절차
다음 내용으로 새 playbook.yml 파일을 생성합니다.
--- - name: "Set BootMode to UEFI" hosts: localhost tasks: - redhat.rhel_mgmt.redfish_config: baseuri: "{{ baseuri }}" username: "{{ username }}" password: "{{ password }}" category: Systems command: SetBiosAttributes bios_attributes: BootMode: Uefi
localhost에 대해 플레이북을 실행합니다.
# ansible-playbook playbook.yml
결과적으로 시스템 부팅 모드가 UEFI로 설정됩니다.
6장. kernel_settings
RHEL 시스템 역할을 사용하여 영구적으로 커널 매개변수 구성
Red Hat Ansible에 대한 지식이 있는 숙련된 사용자는 kernel_settings
역할을 사용하여 여러 클라이언트에서 동시에 커널 매개 변수를 구성할 수 있습니다. 이 해결 방법:
- 효율적인 입력 설정으로 친숙한 인터페이스를 제공합니다.
- 의도한 모든 커널 매개 변수를 한 곳에 유지합니다.
제어 머신에서 kernel_settings
역할을 실행하면 커널 매개 변수가 관리 시스템에 즉시 적용되고 재부팅 시 지속됩니다.
RHEL 채널을 통해 제공되는 RHEL 시스템 역할은 RHEL 고객이 기본 AppStream 리포지토리에서 RPM 패키지로 사용할 수 있습니다. RHEL 시스템 역할은 Ansible Automation Hub를 통해 Ansible 서브스크립션이 있는 고객에게 컬렉션으로 사용할 수도 있습니다.
6.1. kernel_settings 역할 소개
RHEL 시스템 역할은 여러 시스템을 원격으로 관리하기 위한 일관된 구성 인터페이스를 제공하는 역할 집합입니다.
kernel_settings
시스템 역할을 사용하여 커널의 자동화된 구성을 위해 RHEL 시스템 역할이 도입되었습니다. rhel-system-roles
패키지에는 이 시스템 역할과 참조 문서가 포함되어 있습니다.
자동화된 방식으로 하나 이상의 시스템에서 커널 매개 변수를 적용하려면 플레이북에서 선택한 역할 변수 중 하나 이상과 함께 kernel_settings
역할을 사용합니다. 플레이북은 사람이 읽을 수 있는 하나 이상의 플레이 목록으로, YAML 형식으로 작성됩니다.
인벤토리 파일을 사용하여 Ansible이 플레이북에 따라 구성할 시스템 집합을 정의할 수 있습니다.
kernel_settings
역할을 사용하면 다음을 구성할 수 있습니다.
-
kernel_settings_sysctl
역할 변수를 사용하는 커널 매개변수 -
kernel_settings_sysfs
역할 변수를 사용하는 다양한 커널 하위 시스템, 하드웨어 장치, 장치 드라이버 -
systemd
서비스 관리자의 CPU 선호도 및kernel_settings_systemd_cpu_affinity
역할 변수를 사용하여 포크를 처리합니다. -
커널 메모리 하위 시스템은 kernel_settings_transparent_hugepages 및
kernel_settings_transparent_hugepages
_defrag 역할 변수를 사용하여 hugepages를 투명하게
추가 리소스
-
/usr/share/doc/rhel-system-roles/kernel_settings/
디렉터리의README.md
및README.html
파일 - 플레이북 작업
- 인벤토리를 빌드하는 방법
6.2. kernel_settings
역할을 사용하여 선택한 커널 매개변수 적용
다음 단계에 따라 Ansible 플레이북을 준비 및 적용하여 여러 관리 운영 체제에 지속적으로 영향을 미치는 커널 매개 변수를 원격으로 구성합니다.
사전 요구 사항
-
root
권한이 있습니다. -
RHEL 서브스크립션에서 권한을 부여한 경우 제어 시스템에
ansible-core
및rhel-system-roles
패키지를 설치했습니다. - 관리 호스트의 인벤토리는 제어 시스템에 있으며 Ansible은 해당 호스트에 연결할 수 있습니다.
RHEL 8.0 - 8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible ,
과 같은 명령줄 유틸리티, ansible
-playbookdocker
및 podman
과 같은 커넥터, 플러그인 및 모듈 전체 환경이 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 How do I download and Install Red Hat Ansible Engine 을 참조하십시오.
RHEL 8.6 및 9.0에는 Ansible 명령줄 유틸리티, 명령 및 일부 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
RPM으로 제공됨)가 도입되었습니다. AppStream 리포지토리에서는 제한된 지원 범위가 있는 ansible-core
를 제공합니다. RHEL 9 AppStream에 포함된 ansible-core 패키지의 지원 범위를 확인하여 자세한 내용을 확인할 수 있습니다.
절차
선택적으로 설명을 위해
인벤토리
파일을 검토합니다.# cat /home/jdoe/<ansible_project_name>/inventory [testingservers] pdoe@192.168.122.98 fdoe@192.168.122.226 [db-servers] db1.example.com db2.example.com [webservers] web1.example.com web2.example.com 192.0.2.42
파일은
[testingservers]
그룹 및 기타 그룹을 정의합니다. 이를 통해 특정 시스템 세트에 대해 보다 효율적으로 Ansible을 실행할 수 있습니다.구성 파일을 생성하여 Ansible 작업에 대한 기본값 및 권한 에스컬레이션을 설정합니다.
새 YAML 파일을 생성하고 텍스트 편집기에서 엽니다. 예를 들면 다음과 같습니다.
# vi /home/jdoe/<ansible_project_name>/ansible.cfg
다음 내용을 파일에 삽입합니다.
[defaults] inventory = ./inventory [privilege_escalation] become = true become_method = sudo become_user = root become_ask_pass = true
[defaults]
섹션은 관리 호스트의 인벤토리 파일에 대한 경로를 지정합니다.[privilege_escalation]
섹션은 지정된 관리 호스트에서 사용자 권한을root
로 이동하는 것을 정의합니다. 이는 커널 매개 변수를 성공적으로 구성하려면 필요합니다. Ansible 플레이북이 실행되면 사용자 암호를 입력하라는 메시지가 표시됩니다. 사용자는 관리 호스트에 연결한 후sudo
를 통해 자동으로root
로 전환합니다.
kernel_settings
역할을 사용하는 Ansible 플레이북을 생성합니다.새 YAML 파일을 생성하고 텍스트 편집기에서 엽니다. 예를 들면 다음과 같습니다.
# vi /home/jdoe/<ansible_project_name>/kernel-roles.yml
이 파일은 플레이북을 나타내며 일반적으로
인벤토리
파일에서 선택한 특정 관리 호스트에 대해 실행되는 플레이 라고도 하는 정렬된 작업 목록이 포함되어 있습니다.다음 내용을 파일에 삽입합니다.
--- - hosts: testingservers name: "Configure kernel settings" roles: - rhel-system-roles.kernel_settings vars: kernel_settings_sysctl: - name: fs.file-max value: 400000 - name: kernel.threads-max value: 65536 kernel_settings_sysfs: - name: /sys/class/net/lo/mtu value: 65000 kernel_settings_transparent_hugepages: madvise
name
키는 선택 사항입니다. 임의의 문자열과 플레이를 레이블로 연결하고 플레이의 용도를 식별합니다. 플레이의hosts
키는 플레이가 실행되는 호스트를 지정합니다. 이 키의 값 또는 값은 관리 호스트의 개별 이름 또는인벤토리
파일에 정의된 호스트 그룹으로 제공될 수 있습니다.vars
섹션은 선택한 커널 매개 변수 이름과 설정해야 할 값이 포함된 변수 목록을 나타냅니다.roles
키는vars
섹션에 언급된 매개변수 및 값을 구성할 시스템 역할을 지정합니다.참고필요에 맞게 플레이북에서 커널 매개변수와 해당 값을 수정할 수 있습니다.
필요한 경우 플레이의 구문이 올바른지 확인합니다.
# ansible-playbook --syntax-check kernel-roles.yml playbook: kernel-roles.yml
이 예제에서는 플레이북의 성공적인 확인을 보여줍니다.
플레이북을 실행합니다.
# ansible-playbook kernel-roles.yml ... BECOME password: PLAY [Configure kernel settings] ********************************************************************************** PLAY RECAP ******************************************************************************************************** fdoe@192.168.122.226 : ok=10 changed=4 unreachable=0 failed=0 skipped=6 rescued=0 ignored=0 pdoe@192.168.122.98 : ok=10 changed=4 unreachable=0 failed=0 skipped=6 rescued=0 ignored=0
Ansible에서 플레이북을 실행하기 전에 암호를 입력하라는 메시지가 표시되므로 관리 호스트의 사용자가 커널 매개 변수를 구성하는 데 필요한
root
로 전환할 수 있습니다.recap 섹션에서는 모든 관리 호스트에 대해 플레이가 성공적으로 완료되었습니다(
failed=0
). 4 커널 매개 변수가 적용됨(changed=4
).- 관리 호스트를 다시 시작하고 영향을 받는 커널 매개변수를 확인하여 변경 사항이 적용되었는지 확인하고 재부팅해도 유지됩니다.
추가 리소스
- RHEL 시스템 역할을 사용하도록 제어 노드 및 관리형 노드 준비
-
/usr/share/doc/rhel-system-roles/kernel_settings/
디렉터리의README.html
및README.md
파일 - 인벤토리 빌드
- Ansible 구성
- 플레이북 작업
- 변수 사용
- 역할
7장. rhc 시스템 역할을 사용하여 시스템 등록
rhc
RHEL 시스템 역할을 통해 관리자는 RHSM(Red Hat Subscription Management) 및 Satellite 서버를 사용하여 여러 시스템의 등록을 자동화할 수 있습니다. 이 역할은 Ansible을 사용하여 Insights 관련 구성 및 관리 작업도 지원합니다.
7.1. rhc 시스템 역할 소개
RHEL 시스템 역할은 여러 시스템을 원격으로 관리할 수 있도록 일관된 구성 인터페이스를 제공하는 역할 집합입니다. 원격 호스트 구성(rhc
) 시스템 역할을 통해 관리자는 RHEL 시스템을 RHSM(Red Hat Subscription Management) 및 Satellite 서버에 쉽게 등록할 수 있습니다. 기본적으로 rhc
시스템 역할을 사용하여 시스템을 등록하면 시스템이 Insights에 연결됩니다. 또한 rhc
시스템 역할을 사용하면 다음을 수행할 수 있습니다.
- Red Hat Insights에 대한 연결 구성
- 리포지토리 활성화 및 비활성화
- 연결에 사용할 프록시 구성
- 인사이트 수정 및 자동 업데이트 구성
- 시스템 릴리스 설정
- Insights 태그 구성
7.2. rhc 시스템 역할을 사용하여 시스템 등록
rhc
RHEL 시스템 역할을 사용하여 시스템을 Red Hat에 등록할 수 있습니다. 기본적으로 rhc
RHEL 시스템 역할은 등록할 때 시스템을 Red Hat Insights에 연결합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
중요한 정보를 저장할 자격 증명 모음을 생성합니다.
$ ansible-vault create secrets.yml New Vault password: password Confirm New Vault password: password
ansible-vault create
명령은 암호화된 자격 증명 모음 파일을 생성하여 편집기에서 엽니다. 자격 증명 모음에 저장할 중요한 데이터를 입력합니다. 예를 들면 다음과 같습니다.activationKey: activation_key username: username password: password
변경 사항을 저장하고 편집기를 종료합니다. Ansible은 자격 증명 모음의 데이터를 암호화합니다.
나중에
ansible-vault edit secrets.yml
명령을 사용하여 자격 증명 모음의 데이터를 편집할 수 있습니다.선택 사항: 자격 증명 모음 콘텐츠를 표시합니다.
$ ansible-vault view
secrets.yml
플레이북 파일(예:
~/registration.yml
)을 생성하고 수행할 작업에 따라 다음 옵션 중 하나를 사용합니다.활성화 키 및 조직 ID(권장)를 사용하여 등록하려면 다음 플레이북을 사용합니다.
--- - name: Registering system using activation key and organization ID hosts: managed-node-01.example.com vars_files: - secrets.yml vars: rhc_auth: activation_keys: keys: - "{{ activationKey }}" rhc_organization: organizationID roles: - role: rhel-system-roles.rhc
사용자 이름과 암호를 사용하여 등록하려면 다음 플레이북을 사용합니다.
--- - name: Registering system with username and password hosts: managed-node-01.example.com vars_files: - secrets.yml vars: rhc_auth: login: username: "{{ username }}" password: "{{ password }}" roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/registration.yml --ask-vault-pass
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일
7.3. rhc 시스템 역할을 사용하여 Satellite로 시스템 등록
조직에서 Satellite를 사용하여 시스템을 관리하는 경우 Satellite를 통해 시스템을 등록해야 합니다. rhc
RHEL 시스템 역할을 사용하여 Satellite에 시스템을 원격으로 등록할 수 있습니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
중요한 정보를 저장할 자격 증명 모음을 생성합니다.
$ ansible-vault create secrets.yml New Vault password: password Confirm New Vault password: password
ansible-vault create
명령은 암호화된 파일을 생성하여 편집기에서 엽니다. 자격 증명 모음에 저장할 중요한 데이터를 입력합니다. 예를 들면 다음과 같습니다.activationKey: activation_key
변경 사항을 저장하고 편집기를 종료합니다. Ansible은 자격 증명 모음의 데이터를 암호화합니다.
나중에
ansible-vault edit secrets.yml
명령을 사용하여 자격 증명 모음의 데이터를 편집할 수 있습니다.선택 사항: 자격 증명 모음 콘텐츠를 표시합니다.
$ ansible-vault view
secrets.yml
-
~/registration-sat.yml
과 같은 플레이북 파일을 생성합니다. ~/registration-sat.yml
에서 다음 텍스트를 사용하여 활성화 키 및 조직 ID를 사용하여 시스템을 등록합니다.--- - name: Register to the custom registration server and CDN hosts: managed-node-01.example.com vars_files: - secrets.yml vars: rhc_auth: login: activation_keys: keys: - "{{ activationKey }}" rhc_organization: organizationID rhc_server: hostname: example.com port: 443 prefix: /rhsm rhc_baseurl: http://example.com/pulp/content roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/registration-sat.yml --ask-vault-pass
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일
7.4. rhc 시스템 역할을 사용하여 등록 후 Insights에 대한 연결 비활성화
rhc
RHEL 시스템 역할을 사용하여 시스템을 등록하면 기본적으로 Red Hat Insights에 연결할 수 있습니다. 필요하지 않은 경우 rhc
시스템 역할을 사용하여 비활성화할 수 있습니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 시스템이 이미 등록되어 있습니다.
절차
~/dis-insights.yml
과 같은 플레이북 파일을 생성하고 여기에 다음 내용을 추가합니다.--- - name: Disable Insights connection hosts: managed-node-01.example.com vars: rhc_insights: state: absent roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/dis-insights.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일
7.5. rhc 시스템 역할을 사용하여 리포지토리 활성화
rhc
RHEL 시스템 역할을 사용하여 관리 노드에서 리포지토리를 원격으로 활성화하거나 비활성화할 수 있습니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 관리형 노드에서 활성화하거나 비활성화하려는 리포지토리에 대한 세부 정보가 있습니다.
- 시스템을 등록했습니다.
절차
플레이북 파일을 만듭니다(예:
~/configure-repos.yml
).리포지터리를 활성화하려면 다음을 수행합니다.
--- - name: Enable repository hosts: managed-node-01.example.com vars: rhc_repositories: - {name: "RepositoryName", state: enabled} roles: - role: rhel-system-roles.rhc
리포지터리를 비활성화하려면 다음을 수행합니다.
--- - name: Disable repository hosts: managed-node-01.example.com vars: rhc_repositories: - {name: "RepositoryName", state: disabled} roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/configure-repos.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일
7.6. rhc 시스템 역할을 사용하여 릴리스 버전 설정
최신 RHEL 대신 특정 마이너 RHEL 버전에 대해서만 리포지토리만 사용하도록 시스템을 제한할 수 있습니다. 이렇게 하면 특정 마이너 RHEL 버전에 시스템을 잠글 수 있습니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 시스템을 잠글 마이너 RHEL 버전을 알고 있습니다. 호스트가 현재 실행 중인 RHEL 마이너 버전 또는 이후 마이너 버전에만 시스템을 잠글 수 있습니다.
- 시스템을 등록했습니다.
절차
플레이북 파일(예:
~/release.yml
)을 생성합니다.--- - name: Set Release hosts: managed-node-01.example.com vars: rhc_release: "8.6" roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/release.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일
7.7. rhc 시스템 역할을 사용하여 호스트를 등록할 때 프록시 서버 사용
보안 제한 사항이 프록시 서버를 통해서만 인터넷에 액세스할 수 있는 경우 rhc
RHEL 시스템 역할을 사용하여 시스템을 등록할 때 플레이북에 프록시 설정을 지정할 수 있습니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
중요한 정보를 저장할 자격 증명 모음을 생성합니다.
$ ansible-vault create secrets.yml New Vault password: password Confirm New Vault password: password
ansible-vault create
명령은 암호화된 파일을 생성하여 편집기에서 엽니다. 자격 증명 모음에 저장할 중요한 데이터를 입력합니다. 예를 들면 다음과 같습니다.username: username password: password proxy_username: proxyusernme proxy_password: proxypassword
변경 사항을 저장하고 편집기를 종료합니다. Ansible은 자격 증명 모음의 데이터를 암호화합니다.
나중에
ansible-vault edit secrets.yml
명령을 사용하여 자격 증명 모음의 데이터를 편집할 수 있습니다.선택 사항: 자격 증명 모음 콘텐츠를 표시합니다.
$ ansible-vault view
secrets.yml
플레이북 파일(예:
~/configure-proxy.yml
)을 생성합니다.프록시를 사용하여 RHEL 고객 포털에 등록하려면 다음을 수행합니다.
--- - name: Register using proxy hosts: managed-node-01.example.com vars_files: - secrets.yml vars: rhc_auth: login: username: "{{ username }}" password: "{{ password }}" rhc_proxy: hostname: proxy.example.com port: 3128 username: "{{ proxy_username }}" password: "{{ proxy_password }}" roles: - role: rhel-system-roles.rhc
Red Hat Subscription Manager 서비스 구성에서 프록시 서버를 제거하려면 다음을 수행합니다.
--- - name: To stop using proxy server for registration hosts: managed-node-01.example.com vars_files: - secrets.yml vars: rhc_auth: login: username: "{{ username }}" password: "{{ password }}" rhc_proxy: {"state":"absent"} roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/configure-proxy.yml --ask-vault-pass
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일
7.8. rhc 시스템 역할을 사용하여 Insights 규칙의 자동 업데이트 비활성화
rhc
RHEL 시스템 역할을 사용하여 Red Hat Insights의 자동 수집 규칙 업데이트를 비활성화할 수 있습니다. 기본적으로 시스템을 Red Hat Insights에 연결하면 이 옵션이 활성화됩니다. rhc
RHEL 시스템 역할을 사용하여 비활성화할 수 있습니다.
이 기능을 비활성화하면 오래된 규칙 정의 파일을 사용할 위험이 있으며 최신 검증 업데이트가 제공되지 않습니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 시스템을 등록했습니다.
절차
중요한 정보를 저장할 자격 증명 모음을 생성합니다.
$ ansible-vault create secrets.yml New Vault password: password Confirm New Vault password: password
ansible-vault create
명령은 암호화된 파일을 생성하여 편집기에서 엽니다. 자격 증명 모음에 저장할 중요한 데이터를 입력합니다. 예를 들면 다음과 같습니다.username: username password: password
변경 사항을 저장하고 편집기를 종료합니다. Ansible은 자격 증명 모음의 데이터를 암호화합니다.
나중에
ansible-vault edit secrets.yml
명령을 사용하여 자격 증명 모음의 데이터를 편집할 수 있습니다.선택 사항: 자격 증명 모음 콘텐츠를 표시합니다.
$ ansible-vault view
secrets.yml
~/auto-update.yml
과 같은 플레이북 파일을 생성하고 여기에 다음 내용을 추가합니다.--- - name: Disable Red Hat Insights autoupdates hosts: managed-node-01.example.com vars_files: - secrets.yml vars: rhc_auth: login: username: "{{ username }}" password: "{{ password }}" rhc_insights: autoupdate: false state: present roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/auto-update.yml --ask-vault-pass
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일
7.9. rhc RHEL 시스템 역할을 사용하여 Insights 수정 비활성화
rhc
RHEL 시스템 역할을 사용하여 동적 구성을 자동으로 업데이트하도록 시스템을 구성할 수 있습니다. 시스템을 Red hat Insights에 연결하면 기본적으로 활성화됩니다. 필요하지 않은 경우 비활성화할 수 있습니다.
rhc
시스템 역할을 사용하여 수정을 활성화하면 Red Hat에 직접 연결할 때 시스템을 수정할 준비가 됩니다. Satellite 또는 Capsule에 연결된 시스템의 경우 업데이트 활성화를 다르게 수행해야 합니다. Red Hat Insights 수정에 대한 자세한 내용은 Red Hat Insights 수정 가이드를 참조하십시오.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- Insights 수정이 활성화되어 있습니다.
- 시스템을 등록했습니다.
절차
수정을 활성화하려면 플레이북 파일(예:
~/remediation.yml
)을 생성합니다.--- - name: Disable remediation hosts: managed-node-01.example.com vars: rhc_insights: remediation: absent state: present roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/remediation.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일
7.10. rhc 시스템 역할을 사용하여 Insights 태그 구성
시스템 필터링 및 그룹화에 태그를 사용할 수 있습니다. 요구 사항에 따라 태그를 사용자 지정할 수도 있습니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
중요한 정보를 저장할 자격 증명 모음을 생성합니다.
$ ansible-vault create secrets.yml New Vault password: password Confirm New Vault password: password
ansible-vault create
명령은 암호화된 파일을 생성하여 편집기에서 엽니다. 자격 증명 모음에 저장할 중요한 데이터를 입력합니다. 예를 들면 다음과 같습니다.username: username password: password
변경 사항을 저장하고 편집기를 종료합니다. Ansible은 자격 증명 모음의 데이터를 암호화합니다.
나중에
ansible-vault edit secrets.yml
명령을 사용하여 자격 증명 모음의 데이터를 편집할 수 있습니다.선택 사항: 자격 증명 모음 콘텐츠를 표시합니다.
$ ansible-vault view
secrets.yml
플레이북 파일(예:
~/tags.yml
)을 생성하고 여기에 다음 내용을 추가합니다.--- - name: Creating tags hosts: managed-node-01.example.com vars_files: - secrets.yml vars: rhc_auth: login: username: "{{ username }}" password: "{{ password }}" rhc_insights: tags: group: group-name-value location: location-name-value description: - RHEL8 - SAP sample_key:value state: present roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/remediation.yml --ask-vault-pass
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일 - 자세한 내용은 Red Hat Insights 시스템 필터링 및 그룹을 참조하십시오.
7.11. RHC 시스템 역할을 사용하여 시스템 등록 취소
더 이상 서브스크립션 서비스가 필요하지 않은 경우 Red Hat에서 시스템 등록을 취소할 수 있습니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 시스템이 이미 등록되어 있습니다.
절차
등록 취소하려면 플레이북 파일(예:
~/unregister.yml
)을 생성하고 여기에 다음 내용을 추가합니다.--- - name: Unregister the system hosts: managed-node-01.example.com vars: rhc_state: absent roles: - role: rhel-system-roles.rhc
플레이북을 실행합니다.
# ansible-playbook ~/unregister.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.rhc/README.md
파일
8장. RHEL 시스템 역할을 사용하여 네트워크 설정 구성
관리자는 네트워크 RHEL 시스템 역할을 사용하여 네트워크 관련 구성 및 관리 작업을 자동화할 수 있습니다.
8.1. 인터페이스 이름이 있는 네트워크 RHEL System Role을 사용하여 고정 IP 주소로 이더넷 연결 구성
RHEL 시스템 역할을 사용하여 이더넷 연결을 원격으로 구성할 수 있습니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 서버 구성에 물리적 또는 가상 이더넷 장치가 있습니다.
- 관리 노드는 NetworkManager를 사용하여 네트워크를 구성합니다.
절차
다음과 같은 내용으로 플레이북 파일(예:
~/ethernet-static-IP.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure an Ethernet connection with static IP include_role: name: rhel-system-roles.network vars: network_connections: - name: enp1s0 interface_name: enp1s0 type: ethernet autoconnect: yes ip: address: - 192.0.2.1/24 - 2001:db8:1::1/64 gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com state: up
이러한 설정은 다음 설정을 사용하여
enp1s0
장치에 대한 이더넷 연결 프로필을 정의합니다.-
정적 IPv4 주소 -
/24
서브넷 마스크가 있는192.0.2.1
-
/64
서브넷 마스크가 포함된 정적 IPv6 주소 -2001:db8:1::1
-
IPv4 기본 게이트웨이 -
192.0.2.254
-
IPv6 기본 게이트웨이 -
2001:db8:1::fffe
-
IPv4 DNS 서버 -
192.0.2.200
-
IPv6 DNS 서버 -
2001:db8:1::ffbb
-
DNS 검색 도메인 -
example.com
-
정적 IPv4 주소 -
플레이북을 실행합니다.
# ansible-playbook ~/ethernet-static-IP.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.2. 장치 경로가 있는 네트워크 RHEL System Role을 사용하여 고정 IP 주소로 이더넷 연결 구성
RHEL 시스템 역할을 사용하여 이더넷 연결을 원격으로 구성할 수 있습니다.
다음 명령을 사용하여 장치 경로를 확인할 수 있습니다.
# udevadm info /sys/class/net/<device_name> | grep ID_PATH=
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 서버 구성에 물리적 또는 가상 이더넷 장치가 있습니다.
- 관리 노드는 NetworkManager를 사용하여 네트워크를 구성합니다.
절차
다음과 같은 내용으로 플레이북 파일(예:
~/ethernet-static-IP.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure an Ethernet connection with static IP include_role: name: rhel-system-roles.network vars: network_connections: - name: example match: path: - pci-0000:00:0[1-3].0 - &!pci-0000:00:02.0 type: ethernet autoconnect: yes ip: address: - 192.0.2.1/24 - 2001:db8:1::1/64 gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com state: up
이러한 설정은 다음 설정을 사용하여 이더넷 연결 프로필을 정의합니다.
-
정적 IPv4 주소 -
/24
서브넷 마스크가 있는192.0.2.1
-
/64
서브넷 마스크가 포함된 정적 IPv6 주소 -2001:db8:1::1
-
IPv4 기본 게이트웨이 -
192.0.2.254
-
IPv6 기본 게이트웨이 -
2001:db8:1::fffe
-
IPv4 DNS 서버 -
192.0.2.200
-
IPv6 DNS 서버 -
2001:db8:1::ffbb
-
DNS 검색 도메인 -
example.com
이 예제의
match
매개변수는 Ansible이 PCI ID0000:00:0[1-3].0
과 일치하는 장치에 플레이를 적용하지만0000:00:02.0
과 일치하도록 정의합니다. 사용할 수 있는 특수 수정자 및 와일드카드에 대한 자세한 내용은/usr/share/ansible/roles/rhel-system-roles.network/README.md
파일에서match
매개변수 설명을 참조하십시오.-
정적 IPv4 주소 -
플레이북을 실행합니다.
# ansible-playbook ~/ethernet-static-IP.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.3. 인터페이스 이름과 네트워크 RHEL 시스템 역할을 사용하여 동적 IP 주소로 이더넷 연결 구성
RHEL 시스템 역할을 사용하여 이더넷 연결을 원격으로 구성할 수 있습니다. 동적 IP 주소 설정으로 연결을 위해 NetworkManager는 DHCP 서버에서 연결에 대한 IP 설정을 요청합니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 서버 구성에 물리적 또는 가상 이더넷 장치가 있습니다.
- 네트워크에서 DHCP 서버를 사용할 수 있습니다.
- 관리 노드는 NetworkManager를 사용하여 네트워크를 구성합니다.
절차
다음과 같은 콘텐츠를 사용하여 플레이북 파일(예:
~/ethernet-dynamic-IP.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure an Ethernet connection with dynamic IP include_role: name: rhel-system-roles.network vars: network_connections: - name: enp1s0 interface_name: enp1s0 type: ethernet autoconnect: yes ip: dhcp4: yes auto6: yes state: up
이러한 설정은
enp1s0
장치에 대한 이더넷 연결 프로필을 정의합니다. 연결은 DHCP 서버와 IPv6 상태 비저장 주소 자동 구성(SLAAC)에서 IPv4 주소, IPv6 주소, 기본 게이트웨이, 경로, DNS 서버 및 검색 도메인을 검색합니다.플레이북을 실행합니다.
# ansible-playbook ~/ethernet-dynamic-IP.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.4. 장치 경로가 있는 네트워크 RHEL System Role을 사용하여 동적 IP 주소로 이더넷 연결 구성
RHEL 시스템 역할을 사용하여 이더넷 연결을 원격으로 구성할 수 있습니다. 동적 IP 주소 설정으로 연결을 위해 NetworkManager는 DHCP 서버에서 연결에 대한 IP 설정을 요청합니다.
다음 명령을 사용하여 장치 경로를 확인할 수 있습니다.
# udevadm info /sys/class/net/<device_name> | grep ID_PATH=
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 서버 구성에 물리적 또는 가상 이더넷 장치가 있습니다.
- DHCP 서버는 네트워크에서 사용할 수 있습니다.
- 관리 호스트는 NetworkManager를 사용하여 네트워크를 구성합니다.
절차
다음과 같은 콘텐츠를 사용하여 플레이북 파일(예:
~/ethernet-dynamic-IP.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure an Ethernet connection with dynamic IP include_role: name: rhel-system-roles.network vars: network_connections: - name: example match: path: - pci-0000:00:0[1-3].0 - &!pci-0000:00:02.0 type: ethernet autoconnect: yes ip: dhcp4: yes auto6: yes state: up
이러한 설정은 이더넷 연결 프로필을 정의합니다. 연결은 DHCP 서버와 IPv6 상태 비저장 주소 자동 구성(SLAAC)에서 IPv4 주소, IPv6 주소, 기본 게이트웨이, 경로, DNS 서버 및 검색 도메인을 검색합니다.
이 예제의
match
매개변수는 Ansible이 PCI ID0000:00:0[1-3].0
과 일치하는 장치에 플레이를 적용하지만0000:00:02.0
과 일치하도록 정의합니다. 사용할 수 있는 특수 수정자 및 와일드카드에 대한 자세한 내용은/usr/share/ansible/roles/rhel-system-roles.network/README.md
파일에서match
매개변수 설명을 참조하십시오.플레이북을 실행합니다.
# ansible-playbook ~/ethernet-dynamic-IP.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.5. 네트워크 RHEL 시스템 역할을 사용하여 VLAN 태그 지정 설정
네트워크
RHEL 시스템 역할을 사용하여 VLAN 태그를 구성할 수 있습니다. 이 예제에서는 이 이더넷 연결 상단에 ID 10
이 포함된 이더넷 연결과 VLAN을 추가합니다. 하위 장치로 VLAN 연결에는 IP, 기본 게이트웨이 및 DNS 구성이 포함됩니다.
환경에 따라 적절하게 재생을 조정합니다. 예를 들면 다음과 같습니다.
-
VLAN을 본딩과 같은 다른 연결의 포트로 사용하려면
ip
속성을 생략하고 하위 구성에서 IP 구성을 설정합니다. -
VLAN에서 팀, 브리지 또는 본딩 장치를 사용하려면 VLAN에서 사용하는 포트의
interface_name
및type
속성을 조정합니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
다음과 같은 콘텐츠로 플레이북 파일(예:
~/vlan-ethernet.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure a VLAN that uses an Ethernet connection include_role: name: rhel-system-roles.network vars: network_connections: # Add an Ethernet profile for the underlying device of the VLAN - name: enp1s0 type: ethernet interface_name: enp1s0 autoconnect: yes state: up ip: dhcp4: no auto6: no # Define the VLAN profile - name: enp1s0.10 type: vlan ip: address: - "192.0.2.1/24" - "2001:db8:1::1/64" gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com vlan_id: 10 parent: enp1s0 state: up
이러한 설정은
enp1s0
장치 상단에서 작동할 VLAN을 정의합니다. VLAN 인터페이스에는 다음과 같은 설정이 있습니다.-
정적 IPv4 주소 -
/24
서브넷 마스크가 있는192.0.2.1
-
/64
서브넷 마스크가 포함된 정적 IPv6 주소 -2001:db8:1::1
-
IPv4 기본 게이트웨이 -
192.0.2.254
-
IPv6 기본 게이트웨이 -
2001:db8:1::fffe
-
IPv4 DNS 서버 -
192.0.2.200
-
IPv6 DNS 서버 -
2001:db8:1::ffbb
-
DNS 검색 도메인 -
example.com
-
VLAN ID -
10
VLAN 프로필의
parent
속성은enp1s0
장치 위에서 작동하도록 VLAN을 구성합니다. 하위 장치로 VLAN 연결에는 IP, 기본 게이트웨이 및 DNS 구성이 포함됩니다.-
정적 IPv4 주소 -
플레이북을 실행합니다.
# ansible-playbook ~/vlan-ethernet.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.6. 네트워크 RHEL 시스템 역할을 사용하여 네트워크 브리지 구성
RHEL 시스템 역할을 사용하여 네트워크 브릿지를 원격으로 구성할 수 있습니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 두 개 이상의 물리적 또는 가상 네트워크 장치가 서버에 설치되어 있습니다.
절차
다음과 같은 내용으로 플레이북 파일(예:
~/bridge-ethernet.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure a network bridge that uses two Ethernet ports include_role: name: rhel-system-roles.network vars: network_connections: # Define the bridge profile - name: bridge0 type: bridge interface_name: bridge0 ip: address: - "192.0.2.1/24" - "2001:db8:1::1/64" gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com state: up # Add an Ethernet profile to the bridge - name: bridge0-port1 interface_name: enp7s0 type: ethernet controller: bridge0 port_type: bridge state: up # Add a second Ethernet profile to the bridge - name: bridge0-port2 interface_name: enp8s0 type: ethernet controller: bridge0 port_type: bridge state: up
이러한 설정은 다음 설정을 사용하여 네트워크 브리지를 정의합니다.
-
정적 IPv4 주소 -
/24
서브넷 마스크가 있는192.0.2.1
-
/64
서브넷 마스크가 포함된 정적 IPv6 주소 -2001:db8:1::1
-
IPv4 기본 게이트웨이 -
192.0.2.254
-
IPv6 기본 게이트웨이 -
2001:db8:1::fffe
-
IPv4 DNS 서버 -
192.0.2.200
-
IPv6 DNS 서버 -
2001:db8:1::ffbb
-
DNS 검색 도메인 -
example.com
브리지 포트 -
enp7s0
및enp8s0
참고브리지에서 IP 구성을 설정하고 Linux 브리지 포트에는 설정하지 않습니다.
-
정적 IPv4 주소 -
플레이북을 실행합니다.
# ansible-playbook ~/bridge-ethernet.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.7. 네트워크 RHEL 시스템 역할을 사용하여 네트워크 본딩 구성
RHEL 시스템 역할을 사용하여 네트워크 본딩을 원격으로 구성할 수 있습니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
- 두 개 이상의 물리적 또는 가상 네트워크 장치가 서버에 설치되어 있습니다.
절차
다음과 같은 콘텐츠로 플레이북 파일(예:
~/bond-ethernet.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure a network bond that uses two Ethernet ports include_role: name: rhel-system-roles.network vars: network_connections: # Define the bond profile - name: bond0 type: bond interface_name: bond0 ip: address: - "192.0.2.1/24" - "2001:db8:1::1/64" gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com bond: mode: active-backup state: up # Add an Ethernet profile to the bond - name: bond0-port1 interface_name: enp7s0 type: ethernet controller: bond0 state: up # Add a second Ethernet profile to the bond - name: bond0-port2 interface_name: enp8s0 type: ethernet controller: bond0 state: up
이러한 설정은 다음 설정으로 네트워크 본딩을 정의합니다.
-
정적 IPv4 주소 -
/24
서브넷 마스크가 있는192.0.2.1
-
/64
서브넷 마스크가 포함된 정적 IPv6 주소 -2001:db8:1::1
-
IPv4 기본 게이트웨이 -
192.0.2.254
-
IPv6 기본 게이트웨이 -
2001:db8:1::fffe
-
IPv4 DNS 서버 -
192.0.2.200
-
IPv6 DNS 서버 -
2001:db8:1::ffbb
-
DNS 검색 도메인 -
example.com
-
본딩 포트 -
enp7s0
및enp8s0
본딩 모드 -
active-backup
참고본딩에 IP 구성을 설정하고 Linux 본딩 포트에는 설정하지 않습니다.
-
정적 IPv4 주소 -
플레이북을 실행합니다.
# ansible-playbook ~/bond-ethernet.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.8. 네트워크 RHEL 시스템 역할을 사용하여 IPoIB 연결 구성
네트워크
RHEL 시스템 역할을 사용하여 IP over InfiniBand(IPoIB) 장치에 대한 NetworkManager 연결 프로필을 원격으로 생성할 수 있습니다. 예를 들어 Ansible 플레이북을 실행하여 다음 설정으로 mlx4_ib0
인터페이스에 대한 InfiniBand 연결을 원격으로 추가합니다.
-
IPoIB 장치 -
mlx4_ib0.8002
-
파티션 키
p_key
-0x8002
-
정적
IPv4
주소 -/24
서브넷 마스크가 있는192.0.2.1
-
/64
서브넷 마스크가 포함된 정적IPv6
주소 -2001:db8:1::1
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인했습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
-
mlx4_ib0
이라는 InfiniBand 장치가 관리 노드에 설치됩니다. - 관리 노드는 NetworkManager를 사용하여 네트워크를 구성합니다.
절차
다음과 같은 내용과 함께 플레이북 파일(예:
~/IPoIB.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure IPoIB include_role: name: rhel-system-roles.network vars: network_connections: # InfiniBand connection mlx4_ib0 - name: mlx4_ib0 interface_name: mlx4_ib0 type: infiniband # IPoIB device mlx4_ib0.8002 on top of mlx4_ib0 - name: mlx4_ib0.8002 type: infiniband autoconnect: yes infiniband: p_key: 0x8002 transport_mode: datagram parent: mlx4_ib0 ip: address: - 192.0.2.1/24 - 2001:db8:1::1/64 state: up
이 예제와 같이
p_key
매개변수를 설정하는 경우 IPoIB 장치에interface_name
매개변수를 설정하지 마십시오.플레이북을 실행합니다.
# ansible-playbook ~/IPoIB.yml
검증
managed-node-01.example.com
호스트에서mlx4_ib0.8002
장치의 IP 설정을 표시합니다.# ip address show mlx4_ib0.8002 ... inet 192.0.2.1/24 brd 192.0.2.255 scope global noprefixroute ib0.8002 valid_lft forever preferred_lft forever inet6 2001:db8:1::1/64 scope link tentative noprefixroute valid_lft forever preferred_lft forever
mlx4_ib0.8002
장치의 파티션 키(P_Key)를 표시합니다.# cat /sys/class/net/mlx4_ib0.8002/pkey 0x8002
mlx4_ib0.8002
장치의 모드를 표시합니다.# cat /sys/class/net/mlx4_ib0.8002/mode datagram
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.9. 네트워크 RHEL 시스템 역할을 사용하여 특정 서브넷에서 다른 기본 게이트웨이로 트래픽을 라우팅
정책 기반 라우팅을 사용하여 특정 서브넷의 트래픽에 대해 다른 기본 게이트웨이를 구성할 수 있습니다. 예를 들어 기본적으로 기본 경로를 사용하여 모든 트래픽을 인터넷 공급자 A로 라우팅하는 라우터로 RHEL을 구성할 수 있습니다. 그러나 내부 워크스테이션 서브넷에서 수신된 트래픽은 공급자 B로 라우팅됩니다.
RHEL 네트워크
시스템 역할을 사용하여 원격으로 및 여러 노드에 정책 기반 라우팅을 구성할 수 있습니다. Ansible 제어 노드에서 다음 프로세스를 수행합니다.
이 절차에서는 다음과 같은 네트워크 토폴로지를 가정합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는 해당 노드에 대한
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
-
관리 노드는
NetworkManager
및firewalld
서비스를 사용합니다. 구성하려는 관리형 노드에는 네 가지 네트워크 인터페이스가 있습니다.
-
enp7s0
인터페이스는 공급자 A의 네트워크에 연결되어 있습니다. 공급자 네트워크의 게이트웨이 IP는198.51.100.2
입니다. 네트워크에서/30
네트워크 마스크를 사용합니다. -
enp1s0
인터페이스는 공급자 B의 네트워크에 연결되어 있습니다. 공급자 네트워크의 게이트웨이 IP는192.0.2.2
이며 네트워크는/30
네트워크 마스크를 사용합니다. -
enp8s0
인터페이스는 내부 워크스테이션이 있는10.0.0.0/24
서브넷에 연결되어 있습니다. -
enp9s0
인터페이스는 회사의 서버가 있는203.0.113.0/24
서브넷에 연결되어 있습니다.
-
-
내부 워크스테이션 서브넷의 호스트는 기본 게이트웨이로
10.0.0.1
을 사용합니다. 이 절차에서는 이 IP 주소를 라우터의enp8s0
네트워크 인터페이스에 할당합니다. -
서버 서브넷의 호스트는
203.0.113.1
을 기본 게이트웨이로 사용합니다. 이 절차에서는 이 IP 주소를 라우터의enp9s0
네트워크 인터페이스에 할당합니다.
절차
다음과 같은 내용으로 플레이북 파일(예:
~/pbr.yml
)을 생성합니다.--- - name: Configuring policy-based routing hosts: managed-node-01.example.com tasks: - name: Routing traffic from a specific subnet to a different default gateway include_role: name: rhel-system-roles.network vars: network_connections: - name: Provider-A interface_name: enp7s0 type: ethernet autoconnect: True ip: address: - 198.51.100.1/30 gateway4: 198.51.100.2 dns: - 198.51.100.200 state: up zone: external - name: Provider-B interface_name: enp1s0 type: ethernet autoconnect: True ip: address: - 192.0.2.1/30 route: - network: 0.0.0.0 prefix: 0 gateway: 192.0.2.2 table: 5000 state: up zone: external - name: Internal-Workstations interface_name: enp8s0 type: ethernet autoconnect: True ip: address: - 10.0.0.1/24 route: - network: 10.0.0.0 prefix: 24 table: 5000 routing_rule: - priority: 5 from: 10.0.0.0/24 table: 5000 state: up zone: trusted - name: Servers interface_name: enp9s0 type: ethernet autoconnect: True ip: address: - 203.0.113.1/24 state: up zone: trusted
플레이북을 실행합니다.
# ansible-playbook ~/pbr.yml
검증
내부 워크스테이션 서브넷의 RHEL 호스트에서 다음을 수행합니다.
traceroute
패키지를 설치합니다.# yum install traceroute
traceroute
유틸리티를 사용하여 인터넷의 호스트에 대한 경로를 표시합니다.# traceroute redhat.com traceroute to redhat.com (209.132.183.105), 30 hops max, 60 byte packets 1 10.0.0.1 (10.0.0.1) 0.337 ms 0.260 ms 0.223 ms 2 192.0.2.1 (192.0.2.1) 0.884 ms 1.066 ms 1.248 ms ...
명령 출력은 라우터가 공급자 B의 네트워크인
192.0.2.1
을 통해 패킷을 전송함을 표시합니다.
서버 서브넷의 RHEL 호스트에서 다음을 수행합니다.
traceroute
패키지를 설치합니다.# yum install traceroute
traceroute
유틸리티를 사용하여 인터넷의 호스트에 대한 경로를 표시합니다.# traceroute redhat.com traceroute to redhat.com (209.132.183.105), 30 hops max, 60 byte packets 1 203.0.113.1 (203.0.113.1) 2.179 ms 2.073 ms 1.944 ms 2 198.51.100.2 (198.51.100.2) 1.868 ms 1.798 ms 1.549 ms ...
명령 출력은 라우터가 공급자 A의 네트워크인
198.51.100.2
를 통해 패킷을 전송함을 표시합니다.
RHEL 시스템 역할을 사용하여 구성한 RHEL 라우터에서 다음을 수행합니다.
규칙 목록을 표시합니다.
# ip rule list 0: from all lookup local 5: from 10.0.0.0/24 lookup 5000 32766: from all lookup main 32767: from all lookup default
기본적으로 RHEL에는
로컬
테이블, 기본 및기본값
에 대한 규칙이 포함되어 있습니다.다음 표
5000
에 경로를 표시합니다.# ip route list table 5000 0.0.0.0/0 via 192.0.2.2 dev enp1s0 proto static metric 100 10.0.0.0/24 dev enp8s0 proto static scope link src 192.0.2.1 metric 102
인터페이스 및 방화벽 영역을 표시합니다.
# firewall-cmd --get-active-zones external interfaces: enp1s0 enp7s0 trusted interfaces: enp8s0 enp9s0
외부
영역에 masquerading이 활성화되었는지 확인합니다.# firewall-cmd --info-zone=external external (active) target: default icmp-block-inversion: no interfaces: enp1s0 enp7s0 sources: services: ssh ports: protocols: masquerade: yes ...
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.10. 네트워크 RHEL 시스템 역할을 사용하여 802.1X 네트워크 인증을 사용하여 정적 이더넷 연결 구성
RHEL 시스템 역할을 사용하여 802.1X 네트워크 인증을 사용하여 이더넷 연결을 원격으로 구성할 수 있습니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹이 Ansible 인벤토리 파일에 나열됩니다.
- 네트워크는 802.1X 네트워크 인증을 지원합니다.
- 관리 노드는 NetworkManager를 사용합니다.
TLS 인증에 필요한 파일은 제어 노드에 있습니다.
-
클라이언트 키는
/srv/data/client.key
파일에 저장됩니다. -
클라이언트 인증서는
/srv/data/client.crt
파일에 저장됩니다. -
CA(인증 기관) 인증서는
/srv/data/ca.crt
파일에 저장됩니다.
-
클라이언트 키는
절차
다음과 같은 내용과 함께 플레이북 파일(예:
~/enable-802.1x.yml
)을 생성합니다.--- - name: Configure an Ethernet connection with 802.1X authentication hosts: managed-node-01.example.com tasks: - name: Copy client key for 802.1X authentication copy: src: "/srv/data/client.key" dest: "/etc/pki/tls/private/client.key" mode: 0600 - name: Copy client certificate for 802.1X authentication copy: src: "/srv/data/client.crt" dest: "/etc/pki/tls/certs/client.crt" - name: Copy CA certificate for 802.1X authentication copy: src: "/srv/data/ca.crt" dest: "/etc/pki/ca-trust/source/anchors/ca.crt" - include_role: name: rhel-system-roles.network vars: network_connections: - name: enp1s0 type: ethernet autoconnect: yes ip: address: - 192.0.2.1/24 - 2001:db8:1::1/64 gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com ieee802_1x: identity: user_name eap: tls private_key: "/etc/pki/tls/private/client.key" private_key_password: "password" client_cert: "/etc/pki/tls/certs/client.crt" ca_cert: "/etc/pki/ca-trust/source/anchors/ca.crt" domain_suffix_match: example.com state: up
이러한 설정은 다음 설정을 사용하여
enp1s0
장치에 대한 이더넷 연결 프로필을 정의합니다.-
정적 IPv4 주소 -
/24
서브넷 마스크가 있는192.0.2.1
-
/64
서브넷 마스크가 포함된 정적 IPv6 주소 -2001:db8:1::1
-
IPv4 기본 게이트웨이 -
192.0.2.254
-
IPv6 기본 게이트웨이 -
2001:db8:1::fffe
-
IPv4 DNS 서버 -
192.0.2.200
-
IPv6 DNS 서버 -
2001:db8:1::ffbb
-
DNS 검색 도메인 -
example.com
-
TLS
EAP(Extensible Authentication Protocol)를 사용한 802.1x 네트워크 인증
-
정적 IPv4 주소 -
플레이북을 실행합니다.
# ansible-playbook ~/enable-802.1x.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.11. 네트워크 RHEL 시스템 역할을 사용하여 기존 연결에서 기본 게이트웨이 설정
네트워크
RHEL 시스템 역할을 사용하여 기본 게이트웨이를 설정할 수 있습니다.
네트워크
RHEL 시스템 역할을 사용하는 플레이북을 실행하면 설정 값이 플레이에 지정된 값과 일치하지 않는 경우 시스템 역할은 동일한 이름의 기존 연결 프로필을 덮어씁니다. 따라서 IP 구성이 이미 존재하는 경우에도 항상 플레이에서 네트워크 연결 프로필의 전체 구성을 지정합니다. 그러지 않으면 역할은 이러한 값을 기본값으로 재설정합니다.
이미 존재하는지 여부에 따라 절차에서는 다음 설정으로 enp1s0
연결 프로필을 생성하거나 업데이트합니다.
-
정적 IPv4 주소 -
198.51.100.20
(/24
서브넷 마스크 포함) -
/64
서브넷 마스크가 포함된 정적 IPv6 주소 -2001:db8:1::1
-
IPv4 기본 게이트웨이 -
198.51.100.254
-
IPv6 기본 게이트웨이 -
2001:db8:1::fffe
-
IPv4 DNS 서버 -
198.51.100.200
-
IPv6 DNS 서버 -
2001:db8:1::ffbb
-
DNS 검색 도메인 -
example.com
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
다음과 같은 내용으로 플레이북 파일(예:
~/ethernet-connection.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure an Ethernet connection with static IP and default gateway include_role: name: rhel-system-roles.network vars: network_connections: - name: enp1s0 type: ethernet autoconnect: yes ip: address: - 198.51.100.20/24 - 2001:db8:1::1/64 gateway4: 198.51.100.254 gateway6: 2001:db8:1::fffe dns: - 198.51.100.200 - 2001:db8:1::ffbb dns_search: - example.com state: up
플레이북을 실행합니다.
# ansible-playbook ~/ethernet-connection.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.12. 네트워크 RHEL 시스템 역할을 사용하여 정적 경로 구성
네트워크
RHEL 시스템 역할을 사용하여 정적 경로를 구성할 수 있습니다.
네트워크
RHEL 시스템 역할을 사용하는 플레이북을 실행하면 설정 값이 플레이에 지정된 값과 일치하지 않는 경우 시스템 역할은 동일한 이름의 기존 연결 프로필을 덮어씁니다. 따라서 IP 구성이 이미 존재하는 경우에도 항상 플레이에서 네트워크 연결 프로필의 전체 구성을 지정합니다. 그러지 않으면 역할은 이러한 값을 기본값으로 재설정합니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
다음과 같은 내용과 함께 플레이북 파일(예:
~/add-static-routes.yml
)을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure an Ethernet connection with static IP and additional routes include_role: name: rhel-system-roles.network vars: network_connections: - name: enp7s0 type: ethernet autoconnect: yes ip: address: - 192.0.2.1/24 - 2001:db8:1::1/64 gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com route: - network: 198.51.100.0 prefix: 24 gateway: 192.0.2.10 - network: 2001:db8:2:: prefix: 64 gateway: 2001:db8:1::10 state: up
이미 존재하는지 여부에 따라 절차에서는 다음 설정으로
enp7s0
연결 프로필을 생성하거나 업데이트합니다.-
정적 IPv4 주소 -
/24
서브넷 마스크가 있는192.0.2.1
-
/64
서브넷 마스크가 포함된 정적 IPv6 주소 -2001:db8:1::1
-
IPv4 기본 게이트웨이 -
192.0.2.254
-
IPv6 기본 게이트웨이 -
2001:db8:1::fffe
-
IPv4 DNS 서버 -
192.0.2.200
-
IPv6 DNS 서버 -
2001:db8:1::ffbb
-
DNS 검색 도메인 -
example.com
고정 경로:
-
198.51.100.0/24
게이트웨이192.0.2.10
-
2001:db8:2::/64
게이트웨이2001:db8:1::10
-
-
정적 IPv4 주소 -
플레이북을 실행합니다.
# ansible-playbook ~/add-static-routes.yml
검증
관리형 노드에서 다음을 수행합니다.
IPv4 경로를 표시합니다.
# ip -4 route ... 198.51.100.0/24 via 192.0.2.10 dev enp7s0
IPv6 경로를 표시합니다.
# ip -6 route ... 2001:db8:2::/64 via 2001:db8:1::10 dev enp7s0 metric 1024 pref medium
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.13. 네트워크 RHEL 시스템 역할을 사용하여 ethtool 오프로드 기능 구성
네트워크
RHEL 시스템 역할을 사용하여 NetworkManager 연결의 ethtool
기능을 구성할 수 있습니다.
네트워크
RHEL 시스템 역할을 사용하는 플레이북을 실행하면 설정 값이 플레이에 지정된 값과 일치하지 않는 경우 시스템 역할은 동일한 이름의 기존 연결 프로필을 덮어씁니다. 따라서 IP 구성이 이미 존재하는 경우에도 항상 플레이에서 네트워크 연결 프로필의 전체 구성을 지정합니다. 그렇지 않으면 역할은 이러한 값을 기본값으로 재설정합니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
다음과 같은 콘텐츠를 사용하여
~/configure-ethernet-device-with-ethtool-features.yml
과 같은 플레이북 파일을 생성합니다.--- - name: Configure the network hosts: managed-node-01.example.com tasks: - name: Configure an Ethernet connection with ethtool features include_role: name: rhel-system-roles.network vars: network_connections: - name: enp1s0 type: ethernet autoconnect: yes ip: address: - 198.51.100.20/24 - 2001:db8:1::1/64 gateway4: 198.51.100.254 gateway6: 2001:db8:1::fffe dns: - 198.51.100.200 - 2001:db8:1::ffbb dns_search: - example.com ethtool: features: gro: "no" gso: "yes" tx_sctp_segmentation: "no" state: up
이 플레이북은 이미 존재하는지 여부에 따라 다음 설정으로
enp1s0
연결 프로필을 생성하거나 업데이트합니다.-
정적
IPv4
주소 -198.51.100.20
(/24
서브넷 마스크 포함) -
/64
서브넷 마스크가 포함된 정적IPv6
주소 -2001:db8:1::1
-
IPv4
기본 게이트웨이 -198.51.100.254
-
IPv6
기본 게이트웨이 -2001:db8:1::fffe
-
IPv4
DNS 서버 -198.51.100.200
-
IPv6
DNS 서버 -2001:db8:1::ffbb
-
DNS 검색 도메인 -
example.com
ethtool
기능:- GRO(Generic receive offload): 비활성화됨
- 일반 세그먼트 오프로드(GSO): 활성화됨
- TX SCTP(스트림 제어 전송 프로토콜) 세그먼트: 비활성화
-
정적
플레이북을 실행합니다.
# ansible-playbook ~/configure-ethernet-device-with-ethtool-features.yml
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
8.14. 네트워크 RHEL 시스템 역할의 네트워크 상태
네트워크
RHEL 시스템 역할은 플레이북의 상태 구성을 지원하여 장치를 구성합니다. 이를 위해 network_state
변수 다음에 상태 구성을 사용합니다.
플레이북에서 network_state
변수를 사용하는 이점:
- 상태 구성과 함께 선언적 메서드를 사용하여 인터페이스를 구성할 수 있으며 NetworkManager는 이러한 인터페이스에 대한 프로필을 백그라운드에서 만듭니다.
-
network_state
변수를 사용하면 변경해야 하는 옵션을 지정할 수 있으며 다른 모든 옵션은 그대로 유지됩니다. 그러나network_connections
변수를 사용하여 네트워크 연결 프로필을 변경하려면 모든 설정을 지정해야 합니다.
예를 들어 동적 IP 주소 설정으로 이더넷 연결을 생성하려면 플레이북에서 다음 vars
블록을 사용합니다.
상태 구성이 있는 플레이북 | 일반 플레이북 |
vars: network_state: interfaces: - name: enp7s0 type: ethernet state: up ipv4: enabled: true auto-dns: true auto-gateway: true auto-routes: true dhcp: true ipv6: enabled: true auto-dns: true auto-gateway: true auto-routes: true autoconf: true dhcp: true |
vars: network_connections: - name: enp7s0 interface_name: enp7s0 type: ethernet autoconnect: yes ip: dhcp4: yes auto6: yes state: up |
예를 들어 위와 같이 생성한 동적 IP 주소 설정의 연결 상태만 변경하려면 플레이북에서 다음 vars
블록을 사용합니다.
상태 구성이 있는 플레이북 | 일반 플레이북 |
vars: network_state: interfaces: - name: enp7s0 type: ethernet state: down |
vars: network_connections: - name: enp7s0 interface_name: enp7s0 type: ethernet autoconnect: yes ip: dhcp4: yes auto6: yes state: down |
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.network/README.md
file
9장. RHEL 시스템 역할을 사용하여 firewalld
구성
방화벽
시스템 역할을 사용하여 한 번에 여러 클라이언트에서 firewalld
서비스 설정을 구성할 수 있습니다. 이 해결 방법:
- 효율적인 입력 설정으로 인터페이스를 제공합니다.
-
의도된 모든
firewalld
매개변수를 한 곳에 유지합니다.
제어 노드에서 방화벽
역할을 실행한 후 System Role은 firewalld
매개변수를 관리 노드에 즉시 적용하여 재부팅 시에도 유지됩니다.
9.1. 방화벽
RHEL 시스템 역할 소개
RHEL 시스템 역할은 Ansible 자동화 유틸리티의 콘텐츠 집합입니다. 이 콘텐츠는 Ansible 자동화 유틸리티와 함께 여러 시스템을 원격으로 관리할 수 있는 일관된 구성 인터페이스를 제공합니다.
RHEL 시스템 역할의 rhel-system-roles.firewall
역할은 firewalld
서비스의 자동화된 구성을 위해 도입되었습니다. rhel-system-roles
패키지에는 이 시스템 역할 및 참조 문서가 포함되어 있습니다.
자동화된 방식으로 하나 이상의 시스템에서 firewalld
매개 변수를 적용하려면 플레이북의 firewall
시스템 역할 변수를 사용합니다. 플레이북은 텍스트 기반 YAML 형식으로 작성된 하나 이상의 플레이 목록입니다.
인벤토리 파일을 사용하여 Ansible에서 구성할 시스템 집합을 정의할 수 있습니다.
방화벽
역할을 사용하면 다음과 같이 다양한 firewalld
매개변수를 구성할 수 있습니다.
- 영역.
- 패킷을 허용해야 하는 서비스입니다.
- 포트에 대한 트래픽 액세스 권한 부여, 거부 또는 삭제.
- 영역의 포트 또는 포트 범위 전달.
추가 리소스
-
/usr/share/doc/rhel-system-roles/firewall/
디렉터리의README.md
및README.html
파일 - 플레이북 작업
- 인벤토리를 빌드하는 방법
9.2. RHEL 시스템 역할을 사용하여 firewalld
설정 재설정
방화벽
RHEL 시스템 역할을 사용하면 firewalld
설정을 기본 상태로 재설정할 수 있습니다. previous:replaced
매개변수를 변수 목록에 추가하면 System Role은 기존 사용자 정의 설정을 모두 제거하고 firewalld
를 기본값으로 재설정합니다. previous:replaced
매개변수를 다른 설정과 결합하는 경우 firewall
역할은 새 설정을 적용하기 전에 기존 설정을 모두 제거합니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는 해당 노드에 대한
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
다음과 같은 내용과 함께 플레이북 파일(예:
~/reset-firewalld.yml
)을 생성합니다.--- - name: Reset firewalld example hosts: managed-node-01.example.com tasks: - name: Reset firewalld include_role: name: rhel-system-roles.firewall vars: firewall: - previous: replaced
플레이북을 실행합니다.
# ansible-playbook ~/reset-firewalld.yml
검증
이 명령을 관리 노드에서
root
로 실행하여 모든 영역을 확인합니다.# firewall-cmd --list-all-zones
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.firewall/README.md
9.3. RHEL 시스템 역할을 사용하여 하나의 로컬 포트에서 다른 로컬 포트로 firewalld
에서 들어오는 트래픽 전달
방화벽
역할을 사용하면 여러 관리 호스트에 미치는 영향을 사용하여 firewalld
매개변수를 원격으로 구성할 수 있습니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는 해당 노드에 대한
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
다음과 같은 내용으로 플레이북 파일(예:
~/port_forwarding.yml
)을 생성합니다.--- - name: Configure firewalld hosts: managed-node-01.example.com tasks: - name: Forward incoming traffic on port 8080 to 443 include_role: name: rhel-system-roles.firewall vars: firewall: - { forward_port: 8080/tcp;443;, state: enabled, runtime: true, permanent: true }
플레이북을 실행합니다.
# ansible-playbook ~/port_forwarding.yml
검증
관리 호스트에서
firewalld
설정을 표시합니다.# firewall-cmd --list-forward-ports
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.firewall/README.md
9.4. RHEL 시스템 역할을 사용하여 firewalld
에서 포트 관리
RHEL 방화벽
시스템 역할을 사용하여 들어오는 트래픽에 대해 로컬 방화벽에서 포트를 열거나 닫고 재부팅 시 새 구성을 유지할 수 있습니다. 예를 들어 HTTPS 서비스에 대한 들어오는 트래픽을 허용하도록 기본 영역을 구성할 수 있습니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는 해당 노드에 대한
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
다음과 같은 내용과 함께 플레이북 파일(예:
~/opening-a-port.yml
)을 생성합니다.--- - name: Configure firewalld hosts: managed-node-01.example.com tasks: - name: Allow incoming HTTPS traffic to the local host include_role: name: rhel-system-roles.firewall vars: firewall: - port: 443/tcp service: http state: enabled runtime: true permanent: true
permanent: true
옵션은 재부팅 시 새 설정을 영구적으로 만듭니다.플레이북을 실행합니다.
# ansible-playbook ~/opening-a-port.yml
검증
관리 노드에서
HTTPS
서비스와 연결된443/tcp
포트가 열려 있는지 확인합니다.# firewall-cmd --list-ports 443/tcp
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.firewall/README.md
9.5. RHEL 시스템 역할을 사용하여 firewalld
DMZ 영역 구성
시스템 관리자는 방화벽
시스템 역할을 사용하여 enp1s0 인터페이스에서 dmz
영역을 구성하여 해당 영역에 HTTPS
트래픽을 허용할 수 있습니다. 이렇게 하면 외부 사용자가 웹 서버에 액세스할 수 있습니다.
Ansible 제어 노드에서 다음 프로세스를 수행합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는 해당 노드에 대한
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
다음과 같은 내용으로 플레이북 파일(예:
~/configuring-a-dmz.yml
)을 생성합니다.--- - name: Configure firewalld hosts: managed-node-01.example.com tasks: - name: Creating a DMZ with access to HTTPS port and masquerading for hosts in DMZ include_role: name: rhel-system-roles.firewall vars: firewall: - zone: dmz interface: enp1s0 service: https state: enabled runtime: true permanent: true
플레이북을 실행합니다.
# ansible-playbook ~/configuring-a-dmz.yml
검증
관리 노드에서
dmz
영역에 대한 자세한 정보를 봅니다.# firewall-cmd --zone=dmz --list-all dmz (active) target: default icmp-block-inversion: no interfaces: enp1s0 sources: services: https ssh ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks:
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.firewall/README.md
10장. 시스템 역할에서 postfix
역할의 변수
postfix
역할 변수를 사용하면 사용자가 postfix
mail Transfer Agent(MTA)를 설치, 구성, 시작할 수 있습니다.
다음 역할 변수는 이 섹션에 정의되어 있습니다.
-
postfix_conf
: 지원되는 모든postfix
구성 매개변수의 키/값 쌍을 포함합니다. 기본적으로postfix_conf
에는 값이 없습니다.
postfix_conf: relayhost: example.com
시나리오에 기존 구성을 제거하고 새 postfix
설치 위에 원하는 구성을 적용해야 하는 경우 postfix_conf
사전에서 previous: replaced
옵션을 지정합니다.
이전 예: 대체
옵션:
postfix_conf: relayhost: example.com previous: replaced
-
postfix_check
: 설정 변경 사항을 확인하기 위해postfix
를 시작하기 전에 검사가 실행되었는지 확인합니다. 기본값은 true입니다.
예를 들면 다음과 같습니다.
postfix_check: true
-
postfix_backup
: 구성의 단일 백업 사본이 생성되었는지 여부를 결정합니다. 기본적으로postfix_backup
값은 false입니다.
이전 백업을 덮어쓰려면 다음 명령을 실행합니다.
# *cp /etc/postfix/main.cf /etc/postfix/main.cf.backup*
postfix_backup
값이 true
로 변경되는 경우 postfix_backup_multiple
값도 false로 설정해야 합니다.
예를 들면 다음과 같습니다.
postfix_backup: true postfix_backup_multiple: false
-
postfix_backup_multiple
: 역할이 타임스탬프가 지정된 구성 백업 사본을 만들 것인지 결정합니다.
여러 백업 사본을 유지하려면 다음 명령을 실행합니다.
# *cp /etc/postfix/main.cf /etc/postfix/main.cf.$(date -Isec)*
기본적으로 postfix_backup_multiple
값은 true입니다. postfix_backup_multiple:true
설정은 postfix_backup
을 덮어씁니다. postfix_backup을 사용하려면
를 설정해야 합니다.
postfix_backup
_multiple:false
-
postfix_manage_
:firewall
postfix
역할을 firewall 역할과 통합하여 포트 액세스를 관리합니다. 기본적으로 변수는false
로 설정됩니다.postfix
역할의 포트 액세스를 자동으로 관리하려면 변수를true
로 설정합니다. -
postfix_manage_selinux
:postfix
역할을selinux
역할과 통합하여 포트 액세스를 관리합니다. 기본적으로 변수는false
로 설정됩니다.postfix
역할의 포트 액세스를 자동으로 관리하려면 변수를true
로 설정합니다.
구성 매개 변수는 제거할 수 없습니다. postfix
역할을 실행하기 전에 postfix_conf
를 모든 필수 구성 매개 변수로 설정하고 file 모듈을 사용하여 /etc/ECDHE/main.cf
를 제거합니다.
10.1. 추가 리소스
-
/usr/share/doc/rhel-system-roles/postfix/README.md
11장. 시스템 역할을 사용하여 SELinux 구성
11.1. selinux
시스템 역할 소개
RHEL 시스템 역할은 여러 RHEL 시스템을 원격으로 관리하는 일관된 구성 인터페이스를 제공하는 Ansible 역할 및 모듈의 컬렉션입니다. selinux
시스템 역할은 다음 작업을 활성화합니다.
- SELinux 부울, 파일 컨텍스트, 포트 및 로그인과 관련된 로컬 정책 수정 정리.
- SELinux 정책 부울 설정, 파일 컨텍스트, 포트 및 로그인.
- 지정된 파일 또는 디렉터리에서 파일 컨텍스트 복원.
- SELinux 모듈 관리.
다음 표에서는 selinux
시스템 역할에서 사용할 수 있는 입력 변수에 대한 개요를 제공합니다.
표 11.1. SELinux
시스템 역할 변수
역할 변수 | 설명 | CLI 대체 |
---|---|---|
selinux_policy | 대상 프로세스 또는 다단계 보안 보호 정책을 선택합니다. |
|
selinux_state | SELinux 모드를 전환합니다. |
|
selinux_booleans | SELinux 부울을 활성화 및 비활성화합니다. |
|
selinux_fcontexts | SELinux 파일 컨텍스트 매핑을 추가하거나 제거합니다. |
|
selinux_restore_dirs | 파일 시스템 트리에서 SELinux 레이블을 복원합니다. |
|
selinux_ports | 포트에 SELinux 레이블을 설정합니다. |
|
selinux_logins | 사용자를 SELinux 사용자 매핑으로 설정합니다. |
|
selinux_modules | SELinux 모듈을 설치, 활성화, 비활성화 또는 제거합니다. |
|
rhel-system-roles
패키지에서 설치한 /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml
예제 플레이북에서는 강제 모드에서 대상 정책을 설정하는 방법을 보여줍니다. Playbook은 또한 여러 로컬 정책 수정 사항을 적용하고 /tmp/test_dir/
디렉터리의 파일 컨텍스트를 복원합니다.
selinux
역할 변수에 대한 자세한 참조는 rhel-system-roles
패키지를 설치하고 /usr/share/doc/rhel-system-roles/selinux/
디렉터리의 README.md
또는 README.html
파일을 참조하십시오.
추가 리소스
11.2. selinux
시스템 역할을 사용하여 여러 시스템에 SELinux 설정 적용
이 단계에 따라 확인된 SELinux 설정으로 Ansible 플레이북을 준비하고 적용합니다.
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
플레이북을 준비합니다.
rhel-system-roles
패키지의 일부로 설치된 예제 플레이북을 처음부터 시작하거나 수정할 수 있습니다.# cp /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml my-selinux-playbook.yml # vi my-selinux-playbook.yml
시나리오에 맞게 플레이북의 내용을 변경합니다. 예를 들어 다음 부분에서는 시스템이
selinux-local-1.pp
SELinux 모듈을 설치하고 활성화합니다.selinux_modules: - { path: "selinux-local-1.pp", priority: "400" }
- 변경 사항을 저장하고 텍스트 편집기를 종료합니다.
host1, host 2 및 host3 시스템에서 플레이북을 실행합니다.
# ansible-playbook -i host1,host2,host3 my-selinux-playbook.yml
추가 리소스
-
자세한 내용은
rhel-system-roles
패키지를 설치하고/usr/share/doc/rhel-system-roles/selinux/
및/usr/share/ansible/roles/rhel-system-roles.selinux/
디렉터리를 참조하십시오.
12장. RHEL 시스템 역할을 사용하여 로깅 구성
시스템 관리자는 로깅 시스템 역할을 사용하여 RHEL 호스트를 로깅
서버로 구성하여 여러 클라이언트 시스템에서 로그를 수집할 수 있습니다.
12.1. 로깅
시스템 역할
로깅
시스템 역할을 사용하면 로컬 및 원격 호스트에 로깅 구성을 배포할 수 있습니다.
하나 이상의 시스템에 로깅
시스템 역할을 적용하려면 플레이북에서 로깅 구성을 정의합니다. 플레이북은 하나 이상의 플레이 목록입니다. 플레이북은 사람이 읽을 수 있으며 YAML 형식으로 작성됩니다. 플레이북에 대한 자세한 내용은 Ansible 설명서에서 플레이북 작업을 참조하십시오.
플레이북에 따라 구성하려는 시스템 세트는 인벤토리 파일에 정의되어 있습니다. 인벤토리 생성 및 사용에 대한 자세한 내용은 Ansible 문서에서 인벤토리를 빌드하는 방법을 참조하십시오.
로깅 솔루션은 로그를 읽는 여러 방법과 여러 로깅 출력을 제공합니다.
예를 들어 로깅 시스템은 다음과 같은 입력을 수신할 수 있습니다.
- 로컬 파일,
-
systemd/journal
, - 네트워크를 통한 다른 로깅 시스템
또한 로깅 시스템에는 다음과 같은 출력이 있을 수 있습니다.
-
/var/log
디렉토리의 로컬 파일에 저장된 로그 - Elasticsearch로 전송된 로그
- 로그는 다른 로깅 시스템으로 전달됩니다.
로깅
시스템 역할을 사용하면 입력 및 출력을 시나리오에 맞게 결합할 수 있습니다. 예를 들어 로컬 파일의 저널
입력을 저장하는 로깅 솔루션을 구성할 수 있지만 파일에서 읽은 입력은 모두 다른 로깅 시스템으로 전달되어 로컬 로그 파일에 저장됩니다.
12.2. 시스템 역할 매개변수 로깅
로깅 시스템 역할 플레이북에서는 logging
_inputs 매개변수의 입력
, logging_outputs
매개변수의 출력, logging_flows
매개변수의 입력과 출력 관계를 정의합니다. 로깅
시스템 역할은 로깅 시스템을 구성하기 위해 추가 옵션을 사용하여 이러한 변수를 처리합니다. 암호화 또는 자동 포트 관리를 활성화할 수도 있습니다.
현재 로깅 시스템 역할에서 사용 가능한 유일한 로깅
시스템은 Rsyslog 입니다.
logging_inputs
: 로깅 솔루션에 대한 입력 목록입니다.-
name
: 입력의 고유한 이름입니다.logging_flows
: 입력 목록 및 생성된구성
파일 이름의 일부에 사용됩니다. type
: 입력 요소의 유형입니다. 유형은roles/ECDHE/{tasks,vars}/inputs/의
디렉터리 이름에 해당하는 작업 유형을 지정합니다.기본 사항
:systemd
저널 또는unix
소켓에서 입력을 구성합니다.-
kernel_message
:true
로 설정된 경우imklog
를 로드합니다. 기본값은false
입니다. -
use_imuxsock
:imjournal
대신imuxsock
을 사용합니다. 기본값은false
입니다. -
ratelimit_burst
:ratelimit_interval
내에서 출력할 수 있는 최대 메시지 수입니다.use_imuxsock
이 false인 경우 기본값은 false입니다.use_imuxsock
이 true인 경우 기본값은200
입니다. -
ratelimit_interval
:ratelimit_burst
를 평가하기 위한 간격입니다.use_imuxsock
이 false인 경우 기본값은 600초입니다.use_imuxsock
이 true인 경우 기본값은 0입니다. 0은 속도 제한이 꺼져 있음을 나타냅니다. -
persist_state_interval
:sriov 상태가 모든값
메시지를 유지합니다. 기본값은10
입니다.use_imuxsock
이 false인 경우에만 유효합니다.
-
-
files
: 로컬 파일에서 입력을 구성하는 입력입니다. -
remote
: 네트워크를 통해 다른 로깅 시스템의 입력을 구성하는 입력을 입력합니다.
-
state
: 구성 파일의 상태present
또는absent
. 기본값은present
입니다.
-
logging_outputs
: 로깅 솔루션의 출력 목록입니다.-
files
: 로컬 파일에 출력을 구성하는 출력 출력 -
Forward
: 출력을 구성하는 출력을 다른 로깅 시스템으로 출력합니다. -
remote_files
: 다른 로깅 시스템의 출력을 로컬 파일로 구성하는 출력 출력입니다.
-
logging_flows
:logging_inputs
와logging_outputs
간의 관계를 정의하는 흐름의 목록입니다.logging_flows
변수에는 다음 키가 있습니다.-
name
: 흐름의 고유 이름 -
inputs
:logging_inputs
이름 값의 목록 -
outputs
:logging_outputs
이름 값의 목록입니다.
-
-
logging_manage_firewall
:true
로 설정된 경우로깅
역할은방화벽
역할을 사용하여 포트 액세스를 자동으로 관리합니다. -
logging_manage_selinux
:true
로 설정된 경우로깅
역할은selinux
역할을 사용하여 포트 액세스를 자동으로 관리합니다.
추가 리소스
-
/usr/share/ansible/roles/
패키지로 설치된 문서rhel-system-roles
.logging/README.html에서 rhel-system-roles
12.3. 로컬 로깅
시스템 역할 적용
Ansible 플레이북을 준비 및 적용하여 별도의 머신 세트에서 로깅 솔루션을 구성합니다. 각 머신은 로컬에서 로그를 기록합니다.
사전 요구 사항
-
로깅
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible
, ansible-playbook
, docker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스 문서를 다운로드하고 설치하는 방법을 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위에 대한 지식베이스 문서를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
배포 시 시스템 역할이 rsyslog
를 설치하므로 rsyslog
패키지가 설치되어 있을 필요가 없습니다.
절차
필요한 역할을 정의하는 플레이북을 생성합니다.
새 YAML 파일을 생성하고 텍스트 편집기에서 엽니다. 예를 들면 다음과 같습니다.
# vi logging-playbook.yml
다음 내용을 삽입합니다.
--- - name: Deploying basics input and implicit files output hosts: all roles: - rhel-system-roles.logging vars: logging_inputs: - name: system_input type: basics logging_outputs: - name: files_output type: files logging_flows: - name: flow1 inputs: [system_input] outputs: [files_output]
특정 인벤토리에서 플레이북을 실행합니다.
# ansible-playbook -i inventory-file /path/to/file/logging-playbook.yml
다음과 같습니다.
-
inventory-file
은 인벤토리 파일입니다. -
logging-playbook.yml
은 사용하는 플레이북입니다.
-
검증
/etc/ECDHE.conf 파일의 구문을 테스트합니다.
# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run... rsyslogd: End of config validation run. Bye.
시스템이 로그에 메시지를 전송하는지 확인합니다.
테스트 메시지를 보냅니다.
# logger test
/var/log/ECDHE 로그를 확인합니다.
예를 들면 다음과 같습니다.# cat /var/log/messages Aug 5 13:48:31 hostname root[6778]: test
여기서
hostname
은 클라이언트 시스템의 호스트 이름입니다. 로그에 logger 명령을 입력한 사용자의 사용자 이름이 포함됩니다(이 경우root
).
12.4. 로컬 로깅
시스템 역할에서 로그 필터링
rsyslog
속성 기반 필터를 기반으로 로그를 필터링하는 로깅 솔루션을 배포할 수 있습니다.
사전 요구 사항
-
로깅
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음을 수행합니다.
- Red Hat Ansible Core가 설치됨
-
rhel-system-roles
패키지가 설치되어 있습니다. - 관리 노드를 나열하는 인벤토리 파일.
배포 시 시스템 역할이 rsyslog
를 설치하므로 rsyslog
패키지가 설치되어 있을 필요가 없습니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - name: Deploying files input and configured files output hosts: all roles: - linux-system-roles.logging vars: logging_inputs: - name: files_input type: basics logging_outputs: - name: files_output0 type: files property: msg property_op: contains property_value: error path: /var/log/errors.log - name: files_output1 type: files property: msg property_op: "!contains" property_value: error path: /var/log/others.log logging_flows: - name: flow0 inputs: [files_input] outputs: [files_output0, files_output1]
이 구성을 사용하면
오류
문자열이 포함된 모든 메시지가/var/log/errors.log
에 기록되고 다른 모든 메시지는/var/log/others.log
에 기록됩니다.오류
속성 값을 필터링할 문자열로 교체할 수 있습니다.환경 설정에 따라 변수를 수정할 수 있습니다.
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
검증
/etc/ECDHE.conf 파일의 구문을 테스트합니다.
# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run... rsyslogd: End of config validation run. Bye.
시스템이
오류
문자열이 포함된 메시지를 로그로 전송하는지 확인합니다.테스트 메시지를 보냅니다.
# logger error
/var/log/errors.log
로그를 확인합니다. 예를 들면 다음과 같습니다.# cat /var/log/errors.log Aug 5 13:48:31 hostname root[6778]: error
여기서
hostname
은 클라이언트 시스템의 호스트 이름입니다. 로그에 logger 명령을 입력한 사용자의 사용자 이름이 포함됩니다(이 경우root
).
추가 리소스
-
/usr/share/ansible/roles/
패키지로 설치된 문서rhel-system-roles
.logging/README.html에서 rhel-system-roles
12.5. 로깅 시스템 역할을 사용하여 원격 로깅
솔루션 적용
다음 단계에 따라 Red Hat Ansible Core 플레이북을 준비 및 적용하여 원격 로깅 솔루션을 구성합니다. 이 플레이북에서 하나 이상의 클라이언트가 systemd-journal
에서 로그를 가져와서 원격 서버로 전달합니다. 서버는 remote_ECDHE 및
에서 원격 입력을 수신하고 원격 호스트 이름으로 이름이 지정된 디렉터리의 로컬 파일에 로그를 출력합니다.
remote_
files
사전 요구 사항
-
로깅
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다. - 관리 노드를 나열하는 인벤토리 파일.
-
배포 시 시스템 역할이 rsyslog
를 설치하므로 rsyslog
패키지가 설치되어 있을 필요가 없습니다.
절차
필요한 역할을 정의하는 플레이북을 생성합니다.
새 YAML 파일을 생성하고 텍스트 편집기에서 엽니다. 예를 들면 다음과 같습니다.
# vi logging-playbook.yml
다음 내용을 파일에 삽입합니다.
--- - name: Deploying remote input and remote_files output hosts: server roles: - rhel-system-roles.logging vars: logging_inputs: - name: remote_udp_input type: remote udp_ports: [ 601 ] - name: remote_tcp_input type: remote tcp_ports: [ 601 ] logging_outputs: - name: remote_files_output type: remote_files logging_flows: - name: flow_0 inputs: [remote_udp_input, remote_tcp_input] outputs: [remote_files_output] - name: Deploying basics input and forwards output hosts: clients roles: - rhel-system-roles.logging vars: logging_inputs: - name: basic_input type: basics logging_outputs: - name: forward_output0 type: forwards severity: info target: _host1.example.com_ udp_port: 601 - name: forward_output1 type: forwards facility: mail target: _host1.example.com_ tcp_port: 601 logging_flows: - name: flows0 inputs: [basic_input] outputs: [forward_output0, forward_output1] [basic_input] [forward_output0, forward_output1]
여기서
host1.example.com
은 로깅 서버입니다.참고플레이북의 매개변수를 필요에 맞게 수정할 수 있습니다.
주의로깅 솔루션은 서버 또는 클라이언트 시스템의 SELinux 정책에 정의된 포트에서만 작동하며 방화벽에서 엽니다. 기본 SELinux 정책에는 포트 601, 514, 6514, 10514 및 20514가 포함됩니다. 다른 포트를 사용하려면 클라이언트 및 서버 시스템에서 SELinux 정책을 수정합니다.
서버 및 클라이언트를 나열하는 인벤토리 파일을 생성합니다.
새 파일을 생성하고 텍스트 편집기에서 엽니다. 예를 들면 다음과 같습니다.
# vi inventory.ini
다음 내용을 인벤토리 파일에 삽입합니다.
[servers] server ansible_host=host1.example.com [clients] client ansible_host=host2.example.com
다음과 같습니다.
-
host1.example.com
은 로깅 서버입니다. -
host2.example.com
은 로깅 클라이언트입니다.
-
인벤토리에서 플레이북을 실행합니다.
# ansible-playbook -i /path/to/file/inventory.ini /path/to/file/_logging-playbook.yml
다음과 같습니다.
-
inventory.ini
는 인벤토리 파일입니다. -
logging-playbook.yml
은 사용자가 생성한 플레이북입니다.
-
검증
클라이언트와 서버 시스템 모두에서
/etc/ECDHE.conf 파일의 구문을 테스트합니다.
# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye.
클라이언트 시스템이 서버에 메시지를 전송하는지 확인합니다.
클라이언트 시스템에서 테스트 메시지를 보냅니다.
# logger test
서버 시스템에서
/var/log/ECDHE
로그를 확인합니다. 예를 들면 다음과 같습니다.# cat /var/log/messages Aug 5 13:48:31 host2.example.com root[6778]: test
여기서
host2.example.com
은 클라이언트 시스템의 호스트 이름입니다. 로그에 logger 명령을 입력한 사용자의 사용자 이름이 포함됩니다(이 경우root
).
추가 리소스
- RHEL 시스템 역할을 사용하도록 제어 노드 및 관리형 노드 준비
-
/usr/share/ansible/roles/
패키지로 설치된 문서rhel-system-roles
.logging/README.html에서 rhel-system-roles - RHEL System Roles KB 문서
12.6. TLS에서 로깅
시스템 역할 사용
TLS(Transport Layer Security)는 컴퓨터 네트워크를 통해 보안 통신을 허용하도록 설계된 암호화 프로토콜입니다.
관리자는 로깅
RHEL 시스템 역할을 사용하여 Red Hat Ansible Automation Platform을 사용하여 보안 로그 전송을 구성할 수 있습니다.
12.6.1. TLS를 사용하여 클라이언트 로깅 구성
로깅
시스템 역할과 함께 Ansible 플레이북을 사용하여 RHEL 클라이언트에 로깅을 구성하고 TLS 암호화를 사용하여 원격 로깅 시스템으로 로그를 전송할 수 있습니다.
이 절차에서는 개인 키 및 인증서를 생성하고 Ansible 인벤토리의 clients 그룹에 있는 모든 호스트에 TLS를 구성합니다. TLS 프로토콜은 네트워크를 통한 로그의 보안 전송을 위해 메시지 전송을 암호화합니다.
인증서를 생성하기 위해 플레이북에서 인증서
시스템 역할을 호출할 필요가 없습니다. 로깅
시스템 역할은 자동으로 호출합니다.
CA에서 생성된 인증서에 서명하려면 관리형 노드를 IdM 도메인에 등록해야 합니다.
사전 요구 사항
- TLS를 구성하려는 관리형 노드에서 플레이북을 실행할 수 있는 권한이 있습니다.
- 관리형 노드는 제어 노드의 인벤토리 파일에 나열됩니다.
-
ansible
및rhel-system-roles
패키지는 제어 노드에 설치됩니다. - 관리형 노드는 IdM 도메인에 등록됩니다.
절차
다음 내용으로
playbook.yml
파일을 생성합니다.--- - name: Deploying files input and forwards output with certs hosts: clients roles: - rhel-system-roles.logging vars: logging_certificates: - name: logging_cert dns: ['localhost', 'www.example.com'] ca: ipa logging_pki_files: - ca_cert: /local/path/to/ca_cert.pem cert: /local/path/to/logging_cert.pem private_key: /local/path/to/logging_cert.pem logging_inputs: - name: input_name type: files input_log_path: /var/log/containers/*.log logging_outputs: - name: output_name type: forwards target: your_target_host tcp_port: 514 tls: true pki_authmode: x509/name permitted_server: 'server.example.com' logging_flows: - name: flow_name inputs: [input_name] outputs: [output_name]
플레이북은 다음 매개 변수를 사용합니다.
logging_certificates
-
이 매개변수의 값은 인증서 역할의
certificate
_requests logging_pki_files
이 매개변수를 사용하여 로깅에서 사용하는 경로 및 기타 설정을 구성하여 로깅에서 사용하는 CA, 인증서 및 TLS에 사용되는 키 파일을 찾습니다.
ca_cert_src
,ca_cert
_src ,cert
,cert_src
, private_key ,
,private_key
_srctls
.참고logging_certificates
를 사용하여 대상 노드에서 파일을 생성하는 경우logging_certificates
에서 생성되지 않은 파일을 복사하는 데 사용되는ca_cert_src
,cert_src
및private_key_src
를 사용하지 마십시오.ca_cert
-
대상 노드의 CA 인증서 파일의 경로를 나타냅니다. 기본 경로는
/etc/pki/tls/certs/ca.pem
이며 파일 이름은 사용자가 설정합니다. cert
-
대상 노드의 인증서 파일의 경로를 나타냅니다. 기본 경로는
/etc/pki/tls/certs/server-cert.pem
이며 파일 이름은 사용자가 설정합니다. private_key
-
대상 노드의 개인 키 파일의 경로를 나타냅니다. 기본 경로는
/etc/pki/tls/private/server-key.pem
이며 파일 이름은 사용자가 설정합니다. ca_cert_src
-
ca_cert
에서 지정한 위치로 대상 호스트에 복사되는 제어 노드의 CA 인증서 파일의 경로를 나타냅니다.logging_certificates
를 사용하는 경우 이 사용하지 마십시오. cert_src
-
인증서에서 지정한 위치로 대상 호스트에 복사되는 제어 노드의 인증서 파일의 경로를
나타냅니다
.logging_certificates
를 사용하는 경우 이 사용하지 마십시오. private_key_src
-
private_key
에서 지정한 위치로 대상 호스트에 복사되는 제어 노드에서 개인 키 파일의 경로를 나타냅니다.logging_certificates
를 사용하는 경우 이 사용하지 마십시오. tls
-
이 매개변수를
true
로 설정하면 네트워크를 통한 로그 전송이 안전합니다. 보안 래퍼가 필요하지 않은 경우tls: false
를 설정할 수 있습니다.
플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file playbook.yml
추가 리소스
12.6.2. TLS를 사용하여 서버 로깅 구성
로깅
시스템 역할과 함께 Ansible 플레이북을 사용하여 RHEL 서버에 로깅을 구성하고 TLS 암호화를 사용하여 원격 로깅 시스템에서 로그를 수신하도록 설정할 수 있습니다.
이 절차에서는 개인 키 및 인증서를 생성하고 Ansible 인벤토리의 서버 그룹에 있는 모든 호스트에 TLS를 구성합니다.
인증서를 생성하기 위해 플레이북에서 인증서
시스템 역할을 호출할 필요가 없습니다. 로깅
시스템 역할은 자동으로 호출합니다.
CA에서 생성된 인증서에 서명하려면 관리형 노드를 IdM 도메인에 등록해야 합니다.
사전 요구 사항
- TLS를 구성하려는 관리형 노드에서 플레이북을 실행할 수 있는 권한이 있습니다.
- 관리형 노드는 제어 노드의 인벤토리 파일에 나열됩니다.
-
ansible
및rhel-system-roles
패키지는 제어 노드에 설치됩니다. - 관리형 노드는 IdM 도메인에 등록됩니다.
절차
다음 내용으로
playbook.yml
파일을 생성합니다.--- - name: Deploying remote input and remote_files output with certs hosts: server roles: - rhel-system-roles.logging vars: logging_certificates: - name: logging_cert dns: ['localhost', 'www.example.com'] ca: ipa logging_pki_files: - ca_cert: /local/path/to/ca_cert.pem cert: /local/path/to/logging_cert.pem private_key: /local/path/to/logging_cert.pem logging_inputs: - name: input_name type: remote tcp_ports: 514 tls: true permitted_clients: ['clients.example.com'] logging_outputs: - name: output_name type: remote_files remote_log_path: /var/log/remote/%FROMHOST%/%PROGRAMNAME:::secpath-replace%.log async_writing: true client_count: 20 io_buffer_size: 8192 logging_flows: - name: flow_name inputs: [input_name] outputs: [output_name]
플레이북은 다음 매개 변수를 사용합니다.
logging_certificates
-
이 매개변수의 값은 인증서 역할의
certificate
_requests logging_pki_files
이 매개변수를 사용하여 로깅에서 사용하는 경로 및 기타 설정을 구성하여 로깅에서 사용하는 CA, 인증서 및 TLS에 사용되는 키 파일을 찾습니다.
ca_cert_src
,ca_cert
_src ,cert
,cert_src
, private_key ,
,private_key
_srctls
.참고logging_certificates
를 사용하여 대상 노드에서 파일을 생성하는 경우logging_certificates
에서 생성되지 않은 파일을 복사하는 데 사용되는ca_cert_src
,cert_src
및private_key_src
를 사용하지 마십시오.ca_cert
-
대상 노드의 CA 인증서 파일의 경로를 나타냅니다. 기본 경로는
/etc/pki/tls/certs/ca.pem
이며 파일 이름은 사용자가 설정합니다. cert
-
대상 노드의 인증서 파일의 경로를 나타냅니다. 기본 경로는
/etc/pki/tls/certs/server-cert.pem
이며 파일 이름은 사용자가 설정합니다. private_key
-
대상 노드의 개인 키 파일의 경로를 나타냅니다. 기본 경로는
/etc/pki/tls/private/server-key.pem
이며 파일 이름은 사용자가 설정합니다. ca_cert_src
-
ca_cert
에서 지정한 위치로 대상 호스트에 복사되는 제어 노드의 CA 인증서 파일의 경로를 나타냅니다.logging_certificates
를 사용하는 경우 이 사용하지 마십시오. cert_src
-
인증서에서 지정한 위치로 대상 호스트에 복사되는 제어 노드의 인증서 파일의 경로를
나타냅니다
.logging_certificates
를 사용하는 경우 이 사용하지 마십시오. private_key_src
-
private_key
에서 지정한 위치로 대상 호스트에 복사되는 제어 노드에서 개인 키 파일의 경로를 나타냅니다.logging_certificates
를 사용하는 경우 이 사용하지 마십시오. tls
-
이 매개변수를
true
로 설정하면 네트워크를 통한 로그 전송이 안전합니다. 보안 래퍼가 필요하지 않은 경우tls: false
를 설정할 수 있습니다.
플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file playbook.yml
추가 리소스
12.7. RELP에서 로깅
시스템 역할 사용
RELP(Reliable Event Logging Protocol)는 TCP 네트워크를 통한 데이터 및 메시지 로깅을 위한 네트워킹 프로토콜입니다. 이벤트 메시지를 안정적으로 전달하며 메시지 손실을 허용하지 않는 환경에서 사용할 수 있습니다.
RELP 발신자는 명령 형태로 로그 항목을 전송하고 수신자는 처리되면 이를 승인합니다. 일관성을 보장하기 위해 RELP는 모든 종류의 메시지 복구에 대해 전송된 각 명령에 트랜잭션 번호를 저장합니다.
RELP Client와 RELP 서버 사이에서 원격 로깅 시스템을 고려할 수 있습니다. RELP 클라이언트는 로그를 원격 로깅 시스템으로 전송하고 RELP 서버는 원격 로깅 시스템에서 보낸 모든 로그를 수신합니다.
관리자는 로깅
시스템 역할을 사용하여 로그 항목을 안정적으로 보내고 수신하도록 로깅 시스템을 구성할 수 있습니다.
12.7.1. RELP를 사용하여 클라이언트 로깅 구성
로깅
시스템 역할을 사용하여 로컬 시스템에 기록된 RHEL 시스템의 로그인을 구성하고 Ansible 플레이북을 실행하여 RELP를 사용하여 원격 로깅 시스템으로 로그를 전송할 수 있습니다.
이 절차에서는 Ansible 인벤토리의 clients
그룹의 모든 호스트에서 RELP를 구성합니다. RELP 구성은 TLS(Transport Layer Security)를 사용하여 네트워크를 통한 로그의 안전한 전송을 위해 메시지 전송을 암호화합니다.
사전 요구 사항
- RELP를 구성하려는 관리형 노드에서 플레이북을 실행할 수 있는 권한이 있습니다.
- 관리형 노드는 제어 노드의 인벤토리 파일에 나열됩니다.
-
ansible
및rhel-system-roles
패키지는 제어 노드에 설치됩니다.
절차
다음 내용으로
playbook.yml
파일을 생성합니다.--- - name: Deploying basic input and relp output hosts: clients roles: - rhel-system-roles.logging vars: logging_inputs: - name: basic_input type: basics logging_outputs: - name: relp_client type: relp target: logging.server.com port: 20514 tls: true ca_cert: /etc/pki/tls/certs/ca.pem cert: /etc/pki/tls/certs/client-cert.pem private_key: /etc/pki/tls/private/client-key.pem pki_authmode: name permitted_servers: - '*.server.example.com' logging_flows: - name: example_flow inputs: [basic_input] outputs: [relp_client]
Playbook은 다음 설정을 사용합니다.
-
target
: 원격 로깅 시스템이 실행 중인 호스트 이름을 지정하는 필수 매개변수입니다. -
포트
: 원격 로깅 시스템이 수신 대기하는 포트 번호입니다. TLS
: 네트워크를 통한 로그의 안전한 전송을 보장합니다. 보안 래퍼를 원하지 않는 경우tls
변수를false
로 설정할 수 있습니다. 기본적으로tls
매개변수는 RELP로 설정되고 키/인증서 및 트립릿 {ca_cert
,private_key
} 및/또는 {ca_
,cert
_srccert_src
,private_key_src
}가 필요합니다.-
{
ca_cert_src
,cert_src
,private_key_src
} triplet가 설정되면 기본 위치/etc/pki/tls/certs
및/etc/pki/tls/private
이 제어 노드에서 파일을 전송하는 대상으로 사용됩니다. 이 경우 파일 이름은 번들의 원래 이름과 동일합니다. -
{
ca_cert
,cert
,private_key
} triplet가 설정되면 로깅 구성 전에 파일이 기본 경로에 있어야 합니다. - 두 트래블릿이 설정되어 있으면 파일이 로컬 경로에서 제어 노드에서 관리 노드의 특정 경로로 전송됩니다.
-
{
-
ca_cert
: CA 인증서의 경로를 나타냅니다. 기본 경로는/etc/pki/tls/certs/ca.pem
이며 파일 이름은 사용자가 설정합니다. -
인증서
의 경로를 나타냅니다.Represents the path to certificate. 기본 경로는/etc/pki/tls/certs/server-cert.pem
이며 파일 이름은 사용자가 설정합니다. -
private_key
: 개인 키의 경로를 나타냅니다. 기본 경로는/etc/pki/tls/private/server-key.pem
이며 파일 이름은 사용자가 설정합니다. -
ca_cert_src
: 대상 호스트에 복사되는 로컬 CA 인증서 파일 경로를 나타냅니다.ca_cert
를 지정하면 위치에 복사됩니다. -
cert_src
: 대상 호스트에 복사되는 로컬 인증서 파일 경로를 나타냅니다.cert
가 지정되면 해당 인증서가 위치에 복사됩니다. -
private_key_src
: 대상 호스트에 복사되는 로컬 키 파일 경로를 나타냅니다.private_key
가 지정되면 해당 키가 위치에 복사됩니다. -
pki_authmode
: 인증 모드를이름
또는지문
으로 수락합니다. -
allowed_servers
: 로깅 클라이언트에서 TLS를 통해 로그를 연결하고 전송할 수 있는 서버 목록입니다. -
inputs
: 로깅 입력 사전의 목록입니다. -
outputs
: 로깅 출력 사전 목록입니다.
-
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml
플레이북을 실행합니다.
# ansible-playbook -i inventory_file playbook.yml
12.7.2. RELP를 사용하여 서버 로깅 구성
로깅
시스템 역할을 사용하여 RHEL 시스템의 로그인을 서버로 구성하고 Ansible 플레이북을 실행하여 RELP로 원격 로깅 시스템에서 로그를 수신할 수 있습니다.
이 절차에서는 Ansible 인벤토리의 server
그룹에 있는 모든 호스트에서 RELP를 구성합니다. RELP 구성은 TLS를 사용하여 네트워크를 통한 로그의 보안 전송을 위해 메시지 전송을 암호화합니다.
사전 요구 사항
- RELP를 구성하려는 관리형 노드에서 플레이북을 실행할 수 있는 권한이 있습니다.
- 관리형 노드는 제어 노드의 인벤토리 파일에 나열됩니다.
-
ansible
및rhel-system-roles
패키지는 제어 노드에 설치됩니다.
절차
다음 내용으로
playbook.yml
파일을 생성합니다.--- - name: Deploying remote input and remote_files output hosts: server roles: - rhel-system-roles.logging vars: logging_inputs: - name: relp_server type: relp port: 20514 tls: true ca_cert: /etc/pki/tls/certs/ca.pem cert: /etc/pki/tls/certs/server-cert.pem private_key: /etc/pki/tls/private/server-key.pem pki_authmode: name permitted_clients: - '*example.client.com' logging_outputs: - name: remote_files_output type: remote_files logging_flows: - name: example_flow inputs: relp_server outputs: remote_files_output
플레이북은 다음 설정을 사용합니다.
-
포트
: 원격 로깅 시스템이 수신 대기하는 포트 번호입니다. TLS
: 네트워크를 통한 로그의 안전한 전송을 보장합니다. 보안 래퍼를 원하지 않는 경우tls
변수를false
로 설정할 수 있습니다. 기본적으로tls
매개변수는 RELP로 설정되고 키/인증서 및 트립릿 {ca_cert
,private_key
} 및/또는 {ca_
,cert
_srccert_src
,private_key_src
}가 필요합니다.-
{
ca_cert_src
,cert_src
,private_key_src
} triplet가 설정되면 기본 위치/etc/pki/tls/certs
및/etc/pki/tls/private
이 제어 노드에서 파일을 전송하는 대상으로 사용됩니다. 이 경우 파일 이름은 번들의 원래 이름과 동일합니다. -
{
ca_cert
,cert
,private_key
} triplet가 설정되면 로깅 구성 전에 파일이 기본 경로에 있어야 합니다. - 두 트래블릿이 설정되어 있으면 파일이 로컬 경로에서 제어 노드에서 관리 노드의 특정 경로로 전송됩니다.
-
{
-
ca_cert
: CA 인증서의 경로를 나타냅니다. 기본 경로는/etc/pki/tls/certs/ca.pem
이며 파일 이름은 사용자가 설정합니다. -
인증서
의 경로를 나타냅니다.Represents the path to the certificate. 기본 경로는/etc/pki/tls/certs/server-cert.pem
이며 파일 이름은 사용자가 설정합니다. -
private_key
: 개인 키의 경로를 나타냅니다. 기본 경로는/etc/pki/tls/private/server-key.pem
이며 파일 이름은 사용자가 설정합니다. -
ca_cert_src
: 대상 호스트에 복사되는 로컬 CA 인증서 파일 경로를 나타냅니다.ca_cert
를 지정하면 위치에 복사됩니다. -
cert_src
: 대상 호스트에 복사되는 로컬 인증서 파일 경로를 나타냅니다.cert
가 지정되면 해당 인증서가 위치에 복사됩니다. -
private_key_src
: 대상 호스트에 복사되는 로컬 키 파일 경로를 나타냅니다.private_key
가 지정되면 해당 키가 위치에 복사됩니다. -
pki_authmode
: 인증 모드를이름
또는지문
으로 수락합니다. -
allowed_clients
: 로깅 서버가 TLS를 통해 로그를 연결하고 전송할 수 있는 클라이언트 목록입니다. -
inputs
: 로깅 입력 사전의 목록입니다. -
outputs
: 로깅 출력 사전 목록입니다.
-
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml
플레이북을 실행합니다.
# ansible-playbook -i inventory_file playbook.yml
12.8. 추가 리소스
- RHEL 시스템 역할을 사용하도록 제어 노드 및 관리형 노드 준비
-
/usr/share/ansible/roles/
rhel-system-roles
.logging/README.html에서 rhel-system-roles 패키지로 설치된 문서입니다. - RHEL 시스템 역할
-
ansible-playbook(1)
도움말 페이지.
13장. journald
RHEL 시스템 역할을 사용하여 systemd
저널 구성
journald
시스템 역할을 사용하면 systemd
저널을 자동화하고 Red Hat Ansible Automation Platform을 사용하여 영구 로깅을 구성할 수 있습니다.
13.1. journald
RHEL 시스템 역할의 변수
journald
시스템 역할은 journald
로깅 서비스의 동작을 사용자 정의하는 일련의 변수를 제공합니다. 역할에는 다음 변수가 포함됩니다.
역할 변수 | 설명 |
---|---|
|
이 부울 변수를 사용하여 |
|
이 변수를 사용하여 저널 파일이 디스크에 할당될 수 있는 최대 크기(MB)를 지정합니다. |
|
저널의 |
| 이 변수를 사용하여 단일 저널 파일의 최대 크기(MB)를 지정합니다. |
|
이 부울 변수를 사용하여 각 사용자에 대해 로그 데이터를 분리하도록 |
|
이 부울 변수를 사용하여 기본 512바이트보다 큰 |
|
이 변수를 사용하여 |
추가 리소스
-
journald.conf(5)
매뉴얼 페이지.
13.2. journald
시스템 역할을 사용하여 영구 로깅 구성
시스템 관리자는 journald
시스템 역할을 사용하여 영구 로깅을 구성할 수 있습니다. 다음 예제는 다음 목표를 달성하기 위해 플레이북에서 journald
시스템 역할 변수를 설정하는 방법을 보여줍니다.
- 영구 로깅 구성
- 저널 파일의 최대 디스크 공간 지정
-
각 사용자에 대해 로그 데이터를 분리하도록
journald
구성 - 동기화 간격 정의
사전 요구 사항
- 제어 노드와 관리형 노드가 준비되었습니다.
- 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
-
관리형 노드에 연결하는 데 사용하는 계정에는
sudo
권한이 있습니다. - 이 플레이북을 실행하려는 관리형 노드 또는 관리형 노드 그룹은 Ansible 인벤토리 파일에 나열됩니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - hosts: all vars: journald_persistent: true journald_max_disk_size: 2048 journald_per_user: true journald_sync_interval: 1 roles: - linux-system-roles.journald ---
결과적으로
journald
서비스는 로그를 최대 2048MB의 디스크에 영구적으로 저장하고 각 사용자에 대해 로그 데이터를 분리합니다. 동기화는 매 분마다 수행됩니다.선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml -i inventory_file
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
13.3. 추가 리소스
-
journald.conf(5)
매뉴얼 페이지 -
ansible-playbook(1)
매뉴얼 페이지
14장. ssh
및 sshd
RHEL 시스템 역할을 사용하여 보안 통신 구성
관리자는 sshd
시스템 역할을 사용하여 SSH 서버를 구성하고 ssh
시스템 역할을 사용하여 Red Hat Ansible Automation Platform을 사용하여 동시에 여러 RHEL 시스템에서 SSH 클라이언트를 일관되게 설정할 수 있습니다.
14.1. SSH
Server 시스템 역할 변수
sshd
시스템 역할 플레이북에서는 기본 설정 및 제한 사항에 따라 SSH 구성 파일에 대한 매개변수를 정의할 수 있습니다.
이러한 변수를 구성하지 않으면 System Role은 RHEL 기본값과 일치하는 sshd_config
파일을 생성합니다.
모든 경우에 부울이 sshd
구성에서 yes
및 no
로 올바르게 렌더링됩니다. 목록을 사용하여 여러 줄 구성 항목을 정의할 수 있습니다. 예를 들면 다음과 같습니다.
sshd_ListenAddress: - 0.0.0.0 - '::'
다음과 같이 렌더링됩니다.
ListenAddress 0.0.0.0 ListenAddress ::
sshd
시스템 역할의 변수
sshd_enable
-
false
로 설정하면 역할이 완전히 비활성화됩니다. 기본값은true
입니다. sshd_skip_defaults
-
true
로 설정하면 시스템 역할이 기본값을 적용하지 않습니다. 대신sshd
사전 또는sshd_<OptionName
> 변수를 사용하여 전체 구성 기본값 세트를 지정합니다. 기본값은false
입니다. sshd_manage_service
-
false
로 설정하면 서비스가 관리되지 않으므로 부팅 시 활성화되지 않고 시작 또는 다시 로드되지 않습니다. Ansible service 모듈이 현재 AIX에 대해활성화되지
않기 때문에 컨테이너 또는 AIX 내부에서 실행되는 경우를 제외하고 기본값은true
입니다. sshd_allow_reload
-
false
로 설정하면 구성이 변경된 후sshd
가 다시 로드되지 않습니다. 이는 문제 해결에 도움이 될 수 있습니다. 변경된 구성을 적용하려면sshd
를 수동으로 다시 로드합니다. 기본값은 AIX를 제외한sshd_manage_service
와 동일한 값입니다. 여기서sshd_manage_service
기본값은false
이지만sshd_allow_reload
의 기본값은true
입니다. sshd_install_service
true
로 설정하면 역할이sshd
서비스에 대한 서비스 파일을 설치합니다. 이렇게 하면 운영 체제에 제공된 파일이 재정의됩니다. 두 번째 인스턴스를 구성하고sshd_service
변수도 변경하지 않는 한true
로 설정하지 마십시오. 기본값은false
입니다.역할은 다음 변수에서 가리키는 파일을 템플릿으로 사용합니다.
sshd_service_template_service (default: templates/sshd.service.j2) sshd_service_template_at_service (default: templates/sshd@.service.j2) sshd_service_template_socket (default: templates/sshd.socket.j2)
sshd_service
-
이 변수는 두 번째
sshd
서비스 인스턴스를 구성하는 데 유용한sshd
서비스 이름을 변경합니다. sshd
구성이 포함된 사전입니다. 예를 들면 다음과 같습니다.
sshd: Compression: yes ListenAddress: - 0.0.0.0
sshd_config(5)
는sshd
사전의 모든 옵션을 나열합니다.sshd_<OptionName>
사전 대신
sshd_
접두사 및 옵션 이름으로 구성된 간단한 변수를 사용하여 옵션을 정의할 수 있습니다. simple 변수는sshd
사전의 값을 재정의합니다. 예를 들면 다음과 같습니다.sshd_Compression: no
sshd_config(5)
는sshd
에 대한 모든 옵션을 나열합니다.sshd_manage_firewall
기본 포트
22
와 다른 포트를 사용하는 경우 이 변수를true
로 설정합니다.true
로 설정하면sshd
역할은firewall
역할을 사용하여 포트 액세스를 자동으로 관리합니다.참고sshd_manage_firewall
변수는 포트만 추가할 수 있습니다. 포트를 제거할 수 없습니다. 포트를 제거하려면방화벽
시스템 역할을 직접 사용합니다.방화벽
시스템 역할을 사용하여 포트를 관리하는 방법에 대한 자세한 내용은 시스템 역할을 사용하여 포트 구성을 참조하십시오.sshd_manage_selinux
기본 포트
22
와 다른 포트를 사용하는 경우 이 변수를true
로 설정합니다.true
로 설정하면sshd
역할은selinux
역할을 사용하여 포트 액세스를 자동으로 관리합니다.참고sshd_manage_selinux
변수는 포트만 추가할 수 있습니다. 포트를 제거할 수 없습니다. 포트를 제거하려면selinux
시스템 역할을 직접 사용합니다.sshd_match
및sshd_match_1
을sshd_match_9
로 재정의-
사전 목록 또는 일치 섹션의 사전만 표시합니다. 이러한 변수는
sshd
사전에 정의된 대로 일치 블록을 재정의하지 않습니다. 결과 구성 파일에 모든 소스가 반영됩니다. sshd_backup
-
false
로 설정하면 원래sshd_config
파일이 백업되지 않습니다. 기본값은true
입니다.
sshd
시스템 역할에 대한 보조 변수
이러한 변수를 사용하여 지원되는 각 플랫폼에 해당하는 기본값을 재정의할 수 있습니다.
sshd_packages
- 이 변수를 사용하여 설치된 패키지의 기본 목록을 재정의할 수 있습니다.
sshd_config_owner
,sshd_config_group
및sshd_config_mode
-
이 역할에서 이러한 변수를 사용하여 생성하는
openssh
구성 파일의 소유권 및 권한을 설정할 수 있습니다. sshd_config_file
-
이 역할이
openssh
서버 구성이 생성된 경로입니다. sshd_config_namespace
이 변수의 기본값은 null입니다. 즉, 역할이 시스템 기본값을 포함하여 구성 파일의 전체 콘텐츠를 정의함을 의미합니다. 또는 이 변수를 사용하여 드롭인 디렉터리를 지원하지 않는 시스템의 단일 플레이북에 있는 다른 역할 또는 여러 위치에서 이 역할을 호출할 수 있습니다.
sshd_skip_defaults
변수는 무시되며 이 경우 시스템 기본값이 사용되지 않습니다.이 변수를 설정하면 역할이 지정된 구성을 지정된 네임스페이스 아래에 기존 구성 파일의 구성 스니펫에 배치합니다. 시나리오에 역할을 여러 번 적용해야 하는 경우 각 애플리케이션에 대해 다른 네임스페이스를 선택해야 합니다.
참고openssh
구성 파일의 제한 사항은 계속 적용됩니다. 예를 들어 구성 파일에 지정된 첫 번째 옵션만 대부분의 구성 옵션에 적용됩니다.기술적으로, 역할은 기존 구성 파일의 이전 일치 블록과 관계없이 적용되도록 다른 일치 블록을 포함하지 않는 한 "Match all" 블록에 코드 조각을 배치합니다. 이를 통해 다양한 역할 호출에서 충돌하지 않는 옵션을 구성할 수 있습니다.
sshd_binary
-
openssh
의sshd
실행 파일의 경로입니다. sshd_service
-
sshd
서비스의 이름입니다. 기본적으로 이 변수에는 대상 플랫폼에서 사용하는sshd
서비스의 이름이 포함됩니다. 또한 역할에서sshd_install_service
변수를 사용하는 경우 사용자 지정sshd
서비스의 이름을 설정할 수도 있습니다. sshd_verify_hostkeys
-
기본값은
auto
입니다.auto
로 설정하면 생성된 구성 파일에 있는 모든 호스트 키가 나열되고 존재하지 않는 경로가 생성됩니다. 또한 권한 및 파일 소유자는 기본값으로 설정됩니다. 이 기능은 배포 단계에서 역할을 사용하여 첫 번째 시도에서 서비스를 시작할 수 있는지 확인하는 데 유용합니다. 이 확인을 비활성화하려면 이 변수를 빈 목록[]
으로 설정합니다. sshd_hostkey_owner
,sshd_hostkey_group
,sshd_hostkey_mode
-
이러한 변수를 사용하여
sshd_verify_hostkeys
에서 호스트 키에 대한 소유권 및 권한을 설정합니다. sshd_sysconfig
-
RHEL 8 및 이전 버전을 기반으로 하는 시스템에서 이 변수는
sshd
서비스에 대한 추가 세부 정보를 구성합니다.true
로 설정하면 이 역할은sshd_sysconfig_override_crypto_policy
및sshd_sysconfig_use_strong_rng
변수를 기반으로/etc/sysconfig/sshd
구성 파일도 관리합니다. 기본값은false
입니다. sshd_sysconfig_override_crypto_policy
RHEL 8에서
true
로 설정하면sshd
사전 또는sshd_<OptionName
> 형식에서 다음 구성 옵션을 사용하여 시스템 전체 암호화 정책을 덮어쓸 수 있습니다.-
암호화
-
macs
-
GSSAPIKexAlgorithms
-
GSSAPIKeyExchange
(FIPS 전용) -
KexAlgorithms
-
HostKeyAlgorithms
-
PubkeyAcceptedKeyTypes
CASignatureAlgorithms
기본값은
false
입니다.RHEL 9에서는 이 변수가 적용되지 않습니다. 대신
sshd
사전 또는sshd_<OptionName
> 형식에서 다음 구성 옵션을 사용하여 시스템 전체 암호화 정책을 덮어쓸 수 있습니다.-
암호화
-
macs
-
GSSAPIKexAlgorithms
-
GSSAPIKeyExchange
(FIPS 전용) -
KexAlgorithms
-
HostKeyAlgorithms
-
PubkeyAcceptedAlgorithms
-
HostbasedAcceptedAlgorithms
-
CASignatureAlgorithms
RequiredRSASize
sshd_config_file
변수에 정의된 드롭인 디렉터리의 사용자 지정 구성 파일에 이러한 옵션을 입력하면 암호화 정책이 포함된/etc/ssh/sshd_config.d/50-redhat.conf
파일 앞에 사전 정의된 파일 이름을 사용합니다.
-
sshd_sysconfig_use_strong_rng
-
RHEL 8 및 이전 버전을 기반으로 하는 시스템에서 이 변수는
sshd
가 인수로 지정된 바이트 수를 사용하여openssl
난수 생성기를 다시 만들 수 있습니다. 기본값은0
으로 이 기능을 비활성화합니다. 시스템에 하드웨어 임의 번호 생성기가 없는 경우 이 값을 설정하지 마십시오.
14.2. sshd
시스템 역할을 사용하여 OpenSSH 서버 구성
sshd
시스템 역할을 사용하여 Ansible 플레이북을 실행하여 여러 SSH 서버를 구성할 수 있습니다.
SSH 및 SSHD 구성을 변경하는 다른 시스템 역할에 sshd
시스템 역할을 사용할 수 있습니다(예: Identity Management RHEL 시스템 역할). 구성을 덮어쓰지 않으려면 sshd
역할이 네임스페이스(RHEL 8 및 이전 버전) 또는 RHEL 9( 드롭인 디렉터리)를 사용하는지 확인합니다.
사전 요구 사항
-
sshd
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible
, ansible-playbook
, docker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스 문서를 다운로드하고 설치하는 방법을 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위에 대한 지식베이스 문서를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
sshd
시스템 역할에 대한 예제 플레이북을 복사합니다.# cp /usr/share/doc/rhel-system-roles/sshd/example-root-login-playbook.yml path/custom-playbook.yml
텍스트 편집기를 사용하여 복사된 플레이북을 엽니다. 예를 들면 다음과 같습니다.
# vim path/custom-playbook.yml --- - hosts: all tasks: - name: Configure sshd to prevent root and password login except from particular subnet include_role: name: rhel-system-roles.sshd vars: sshd: # root login and password login is enabled only from a particular subnet PermitRootLogin: no PasswordAuthentication: no Match: - Condition: "Address 192.0.2.0/24" PermitRootLogin: yes PasswordAuthentication: yes
플레이북은 다음을 수행하도록 구성된 SSH 서버로 관리 노드를 구성합니다.
-
암호 및
root
사용자 로그인이 비활성화되어 있습니다 -
암호 및
root
사용자 로그인은 서브넷192.0.2.0/24
에서만 활성화됩니다.
환경 설정에 따라 변수를 수정할 수 있습니다. 자세한 내용은 sshd 시스템 역할 변수를 참조하십시오.
-
암호 및
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check path/custom-playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file path/custom-playbook.yml ... PLAY RECAP ************************************************** localhost : ok=12 changed=2 unreachable=0 failed=0 skipped=10 rescued=0 ignored=0
검증
SSH 서버에 로그인합니다.
$ ssh user1@10.1.1.1
다음과 같습니다.
-
user1
은 SSH 서버의 사용자입니다. -
10.1.1.1
은 SSH 서버의 IP 주소입니다.
-
SSH 서버에서
sshd_config
파일의 내용을 확인합니다.$ cat /etc/ssh/sshd_config … PasswordAuthentication no PermitRootLogin no … Match Address 192.0.2.0/24 PasswordAuthentication yes PermitRootLogin yes …
192.0.2.0/24
서브넷에서 root로 서버에 연결할 수 있는지 확인합니다.IP 주소를 확인합니다.
$ hostname -I 192.0.2.1
IP 주소가
192.0.2.1
-192.0.2.254
범위 내에 있는 경우 서버에 연결할 수 있습니다.root
로 서버에 연결합니다 :$ ssh root@10.1.1.1
추가 리소스
-
/usr/share/doc/rhel-system-roles/sshd/README.md
파일. -
ansible-playbook(1)
도움말 페이지.
14.3. SSH
시스템 역할 변수
ssh
시스템 역할 플레이북에서는 환경 설정 및 제한 사항에 따라 클라이언트 SSH 구성 파일에 대한 매개변수를 정의할 수 있습니다.
이러한 변수를 구성하지 않으면 System Role은 RHEL 기본값과 일치하는 글로벌 ssh_config
파일을 생성합니다.
모든 경우에 부울이 ssh
구성에서 yes
또는 no
로 올바르게 렌더링됩니다. 목록을 사용하여 여러 줄 구성 항목을 정의할 수 있습니다. 예를 들면 다음과 같습니다.
LocalForward: - 22 localhost:2222 - 403 localhost:4003
다음과 같이 렌더링됩니다.
LocalForward 22 localhost:2222 LocalForward 403 localhost:4003
구성 옵션은 대소문자를 구분합니다.
ssh
시스템 역할의 변수
ssh_user
-
시스템 역할이 사용자별 구성을 수정하는 기존 사용자 이름을 정의할 수 있습니다. 사용자별 구성은 지정된 사용자의
~/.ssh/config
에 저장됩니다. 기본값은 모든 사용자에 대한 글로벌 구성을 수정하는 null입니다. ssh_skip_defaults
-
기본값은
auto
입니다.auto
로 설정하면 System Role은 시스템 전체 구성 파일/etc/ssh/ssh_config
를 작성하고 RHEL 기본값을 여기에 정의합니다.ssh_drop_in_name
변수를 정의하여 드롭인 구성 파일을 생성하면ssh_skip_defaults
변수가 자동으로 비활성화됩니다. ssh_drop_in_name
시스템 전체 드롭인 디렉터리에 배치되는 드롭인 구성 파일의 이름을 정의합니다. 이름은
/etc/ssh/ssh_config.d/{ssh_drop_in_name}.conf
템플릿에서 수정할 구성 파일을 참조하는 데 사용됩니다. 시스템이 드롭인 디렉터리를 지원하지 않는 경우 기본값은 null입니다. 시스템이 드롭인 디렉터리를 지원하는 경우 기본값은00-ansible
입니다.주의시스템이 드롭인 디렉터리를 지원하지 않는 경우 이 옵션을 설정하면 플레이가 실패합니다.
제안된 형식은
NN-name
입니다. 여기서NN
은 구성 파일의 순서를 지정하는 데 사용되는 두 자리 숫자이고,name
은 파일의 콘텐츠 또는 소유자에 대한 설명이 포함된 이름입니다.ssh
- 구성 옵션과 해당 값이 포함된 dict입니다.
ssh_OptionName
-
dict 대신
ssh_
접두사 및 옵션 이름으로 구성된 간단한 변수를 사용하여 옵션을 정의할 수 있습니다. 단순 변수는ssh
dict의 값을 재정의합니다. ssh_additional_packages
-
이 역할은 가장 일반적인 사용 사례에 필요한
openssh
및openssh-clients
패키지를 자동으로 설치합니다. 추가 패키지를 설치해야 하는 경우(예: 호스트 기반 인증에openssh-keysign
) 이 변수에 지정할 수 있습니다. ssh_config_file
역할이 생성된 구성 파일을 저장하는 경로입니다. 기본값:
-
시스템에 드롭인 디렉터리가 있는 경우 기본값은
/etc/ssh/ssh_config.d/{ssh_drop_in_name}.conf
템플릿으로 정의됩니다. -
시스템에 드롭인 디렉터리가 없으면 기본값은
/etc/ssh/ssh_config
입니다. -
ssh_user
변수가 정의된 경우 기본값은~/.ssh/config
입니다.
-
시스템에 드롭인 디렉터리가 있는 경우 기본값은
ssh_config_owner
,ssh_config_group
,ssh_config_mode
-
생성된 구성 파일의 소유자, 그룹 및 모드입니다. 기본적으로 파일 소유자는
root:root
이며 모드는0644
입니다.ssh_user
가 정의되면 모드는0600
이고 소유자와 그룹은ssh_user
변수에 지정된 사용자 이름에서 파생됩니다.
14.4. ssh
시스템 역할을 사용하여 OpenSSH 클라이언트 구성
ssh
시스템 역할을 사용하여 Ansible 플레이북을 실행하여 여러 SSH 클라이언트를 구성할 수 있습니다.
SSH 및 SSHD 구성을 변경하는 다른 시스템 역할(예: ID 관리 RHEL 시스템 역할)에 ssh
시스템 역할을 사용할 수 있습니다. 구성을 덮어쓰지 않도록 하려면 ssh
역할이 드롭인 디렉터리(기본값: RHEL 8)를 사용하는지 확인합니다.
사전 요구 사항
-
ssh
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible
, ansible-playbook
, docker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스 문서를 다운로드하고 설치하는 방법을 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위에 대한 지식베이스 문서를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - hosts: all tasks: - name: "Configure ssh clients" include_role: name: rhel-system-roles.ssh vars: ssh_user: root ssh: Compression: true GSSAPIAuthentication: no ControlMaster: auto ControlPath: ~/.ssh/.cm%C Host: - Condition: example Hostname: example.com User: user1 ssh_ForwardX11: no
이 플레이북은 다음 구성을 사용하여 관리 노드에서
root
사용자의 SSH 클라이언트 기본 설정을 구성합니다.- 압축이 활성화됩니다.
-
ControlMaster 멀티플렉싱이
auto
로 설정되어 있습니다. -
example
.comuser1
입니다. -
example
.comuser1
사용자 이름으로 표시하는 호스트 별칭 예제가 생성됩니다. - X11 전달이 비활성화되어 있습니다.
선택적으로 환경 설정에 따라 이러한 변수를 수정할 수 있습니다. 자세한 내용은 ssh 시스템 역할 변수를 참조하십시오.
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check path/custom-playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file path/custom-playbook.yml
검증
텍스트 편집기에서 SSH 구성 파일을 열어 관리 노드에 올바른 구성이 있는지 확인합니다. 예를 들면 다음과 같습니다.
# vi ~root/.ssh/config
위에 표시된 예제 플레이북의 애플리케이션을 적용한 후에는 구성 파일에 다음 내용이 포함되어야 합니다.
# Ansible managed Compression yes ControlMaster auto ControlPath ~/.ssh/.cm%C ForwardX11 no GSSAPIAuthentication no Host example Hostname example.com User user1
14.5. 비독점 구성에 sshd
시스템 역할 사용
일반적으로 sshd
시스템 역할을 적용하면 전체 구성을 덮어씁니다. 이전에 구성을 조정한 경우(예: 다른 시스템 역할 또는 플레이북) 문제가 있을 수 있습니다. 다른 옵션을 배치하는 동안 선택한 구성 옵션에 대해서만 sshd
시스템 역할을 적용하려면 비독점 구성을 사용할 수 있습니다.
RHEL 8 이하에서는 구성 스니펫을 사용하여 비독점 구성을 적용할 수 있습니다.
사전 요구 사항
-
sshd
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음을 수행합니다.
-
ansible-core
패키지가 설치되어 있습니다. - 관리 노드를 나열하는 인벤토리 파일.
- 다른 RHEL 시스템 역할에 대한 플레이북입니다.
-
절차
sshd_config_namespace
변수가 있는 구성 스니펫을 플레이북에 추가합니다.--- - hosts: all tasks: - name: <Configure SSHD to accept some useful environment variables> include_role: name: rhel-system-roles.sshd vars: sshd_config_namespace: <my-application> sshd: # Environment variables to accept AcceptEnv: LANG LS_COLORS EDITOR
인벤토리에 플레이북을 적용하면 역할이 존재하지 않는 경우
/etc/ssh/sshd_config
파일에 다음 스니펫을 추가합니다.# BEGIN sshd system role managed block: namespace <my-application> Match all AcceptEnv LANG LS_COLORS EDITOR # END sshd system role managed block: namespace <my-application>
검증
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml -i inventory_file
추가 리소스
-
/usr/share/doc/rhel-system-roles/sshd/README.md
파일. -
ansible-playbook(1)
도움말 페이지.
15장. vpn
RHEL 시스템 역할을 사용하여 IPsec과 VPN 연결 구성
vpn
시스템 역할을 사용하면 Red Hat Ansible Automation Platform을 사용하여 RHEL 시스템에서 VPN 연결을 구성할 수 있습니다. 이를 사용하여 호스트 간, 네트워크-네트워크, VPN 원격 액세스 서버 및 메시 구성을 설정할 수 있습니다.
호스트 간 연결의 경우 역할은 필요에 따라 키 생성을 포함하여 vpn_connections
목록에 있는 각 호스트 쌍 간에 VPN 터널을 설정합니다. 또는 나열된 모든 호스트 간에 opportunistic 메시 구성을 생성하도록 구성할 수 있습니다. 이 역할은 호스트에
있는 호스트의 이름이 Ansible 인벤토리에 사용된 호스트의 이름과 동일하고 해당 이름을 사용하여 터널을 구성할 수 있다고 가정합니다.
vpn
RHEL 시스템 역할은 현재 IPsec 구현인 Libreswan만 VPN 공급자로 지원합니다.
15.1. vpn
시스템 역할을 사용하여 IPsec을 사용하여 호스트 간 VPN 생성
vpn
시스템 역할을 사용하여 제어 노드에서 Ansible 플레이북을 실행하여 호스트 간 연결을 구성할 수 있습니다. 이 연결은 인벤토리 파일에 나열된 모든 관리 노드를 구성합니다.
사전 요구 사항
-
vpn
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible
, ansible-playbook
, docker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스 문서를 다운로드하고 설치하는 방법을 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위에 대한 지식베이스 문서를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.- name: Host to host VPN hosts: managed_node1, managed_node2 roles: - rhel-system-roles.vpn vars: vpn_connections: - hosts: managed_node1: managed_node2: vpn_manage_firewall: true vpn_manage_selinux: true
이 Playbook은 시스템 역할로 자동 생성되는 키로 사전 공유 키 인증을 사용하여
managed_node1-to-managed_node2
연결을 구성합니다.vpn_manage_firewall
및vpn_manage_selinux
둘 다true
로 설정되므로vpn
역할은firewall
및selinux
역할을 사용하여vpn
역할에서 사용하는 포트를 관리합니다.선택 사항: 호스트
vpn_connections
목록에 다음 섹션을 추가하여 인벤토리 파일에 나열되지 않은 외부 호스트로의 연결을 구성합니다.vpn_connections: - hosts: managed_node1: managed_node2: external_node: hostname: 192.0.2.2
이렇게 하면 두 개의 추가 연결인
managed_node1-to-external_node
및managed_node2-to-external_node
가 구성됩니다.
연결은 관리형 노드에서만 구성되며 외부 노드에는 구성되어 있지 않습니다.
선택 사항:
vpn_connections
내의 추가 섹션(예: 컨트롤 플레인 및 데이터 플레인)을 사용하여 관리형 노드에 대해 여러 VPN 연결을 지정할 수 있습니다.- name: Multiple VPN hosts: managed_node1, managed_node2 roles: - rhel-system-roles.vpn vars: vpn_connections: - name: control_plane_vpn hosts: managed_node1: hostname: 192.0.2.0 # IP for the control plane managed_node2: hostname: 192.0.2.1 - name: data_plane_vpn hosts: managed_node1: hostname: 10.0.0.1 # IP for the data plane managed_node2: hostname: 10.0.0.2
-
선택 사항: 환경 설정에 따라 변수를 수정할 수 있습니다. 자세한 내용은
/usr/share/doc/rhel-system-roles/vpn/README.md
파일을 참조하십시오. 선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check /path/to/file/playbook.yml -i /path/to/file/inventory_file
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i /path/to/file/inventory_file /path/to/file/playbook.yml
검증
관리형 노드에서 연결이 성공적으로 로드되었는지 확인합니다.
# ipsec status | grep connection.name
connection.name을 이 노드의 연결 이름으로 교체합니다(예:
managed_node1-to-managed_node2
).
기본적으로 역할은 각 시스템의 관점에서 생성하는 각 연결에 대해 설명이 포함된 이름을 생성합니다. 예를 들어 managed_node1
과 managed_node2
간의 연결을 생성할 때 managed_node1
에 대한 이 연결의 설명 이름은 managed_node1-to-managed_node2
이지만 managed_node2
의 설명 이름은 managed_node2-to-managed_node1
입니다.
관리형 노드에서 연결이 성공적으로 시작되었는지 확인합니다.
# ipsec trafficstatus | grep connection.name
선택 사항: 연결이 성공적으로 로드되지 않은 경우 다음 명령을 입력하여 연결을 수동으로 추가합니다. 이렇게 하면 연결 설정 실패 이유를 나타내는 더 구체적인 정보를 제공합니다.
# ipsec auto --add connection.name
참고연결을 로드하고 시작하는 동안 발생한 모든 오류는 로그에 보고되며,
/var/log/pluto.log
에서 확인할 수 있습니다. 이러한 로그는 구문 분석하기 어렵기 때문에 대신 표준 출력에서 로그 메시지를 가져오기 위해 수동으로 연결을 추가합니다.
15.2. vpn
시스템 역할을 사용하여 IPsec과 opportunistic 메시 VPN 연결 생성
vpn
시스템 역할을 사용하여 제어 노드에서 Ansible 플레이북을 실행하여 인증에 대한 인증서를 사용하는 운영 체제 메시 VPN 연결을 구성할 수 있습니다. 이 연결은 인벤토리 파일에 나열된 모든 관리형 노드를 구성합니다.
인증서를 사용한 인증은 플레이북에서 auth_method: cert
매개 변수를 정의하여 구성됩니다. vpn
시스템 역할은 /etc/ipsec.d
디렉터리에 정의된 IPsec 네트워크 보안 서비스(NSS) 암호화 라이브러리에 필요한 인증서가 포함되어 있다고 가정합니다. 기본적으로 노드 이름은 인증서 닉네임으로 사용됩니다. 이 예에서는 managed_node1
입니다. 인벤토리의 cert_name
특성을 사용하여 다른 인증서 이름을 정의할 수 있습니다.
다음 예제 프로세스에서는 Ansible 플레이북을 실행할 시스템인 제어 노드는 관리 노드(1922.0.2.0/24)와 동일한 CIDR(Classless inter-domain routing) 번호를 공유하며 IP 주소가 192.0.2.7입니다. 따라서 제어 노드는 CIDR 192.0.2.0/24에 대해 자동으로 생성되는 개인 정책에 따릅니다.
플레이 중에 SSH 연결 손실을 방지하기 위해 제어 노드에 대한 명확한 정책이 정책 목록에 포함됩니다. CIDR이 기본값과 같은 정책 목록에도 항목이 있습니다. 이는 이 플레이북이 private-or-clear 대신 비공개로 만들기 위해 기본 정책의 규칙을 재정의하기 때문입니다.
사전 요구 사항
vpn
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한.-
모든 관리형 노드에서
/etc/ipsec.d
디렉터리의 NSS 데이터베이스에는 피어 인증에 필요한 모든 인증서가 포함되어 있습니다. 기본적으로 노드 이름은 인증서 닉네임으로 사용됩니다.
-
모든 관리형 노드에서
Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
제어 노드에서 다음이 있어야 합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible
, ansible-playbook
, docker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스 문서를 다운로드하고 설치하는 방법을 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위에 대한 지식베이스 문서를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.- name: Mesh VPN hosts: managed_node1, managed_node2, managed_node3 roles: - rhel-system-roles.vpn vars: vpn_connections: - opportunistic: true auth_method: cert policies: - policy: private cidr: default - policy: private-or-clear cidr: 198.51.100.0/24 - policy: private cidr: 192.0.2.0/24 - policy: clear cidr: 192.0.2.7/32 vpn_manage_firewall: true vpn_manage_selinux: true
참고vpn_manage_firewall
및vpn_manage_selinux
둘 다true
로 설정되므로vpn
역할은firewall
및selinux
역할을 사용하여vpn
역할에서 사용하는 포트를 관리합니다.-
선택 사항: 환경 설정에 따라 변수를 수정할 수 있습니다. 자세한 내용은
/usr/share/doc/rhel-system-roles/vpn/README.md
파일을 참조하십시오. 선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
15.3. 추가 리소스
-
vpn
시스템 역할에 사용되는 매개변수 및 역할에 대한 추가 정보는/usr/share/doc/rhel-system-roles/vpn/README.md
파일을 참조하십시오. -
ansible-playbook
명령에 대한 자세한 내용은ansible-playbook(1)
도움말 페이지를 참조하십시오.
16장. crypto-policies
RHEL 시스템 역할을 사용하여 사용자 정의 암호화 정책 설정
관리자는 crypto_policies
RHEL 시스템 역할을 사용하여 Ansible Core 패키지를 사용하여 여러 시스템에서 사용자 지정 암호화 정책을 신속하고 일관되게 구성할 수 있습니다.
16.1. crypto_policies
시스템 역할 변수 및 팩트
crypto_policies
시스템 역할 플레이북에서는 환경 설정 및 제한 사항에 따라 crypto_policies
구성 파일에 대한 매개변수를 정의할 수 있습니다.
변수를 구성하지 않으면 시스템 역할은 시스템을 구성하지 않고 팩트만 보고합니다.
crypto_policies
시스템 역할에 대해 선택한 변수
crypto_policies_policy
- 관리 노드에 적용되는 시스템 역할이 적용되는 암호화 정책을 결정합니다. 다양한 암호화 정책에 대한 자세한 내용은 시스템 전체 암호화 정책을 참조하십시오.
crypto_policies_reload
-
yes
로 설정되면 영향을 받는 서비스 (현재ipsec
,bind
,sshd
서비스)로 설정된 경우 암호화 정책을 적용한 후 다시 로드합니다. 기본값은yes
입니다. crypto_policies_reboot_ok
-
yes
로 설정하고 System Role에서 crypto 정책을 변경한 후 재부팅이 필요한 경우crypto_policies_reboot_required
를yes
로 설정합니다. 기본값은no
입니다.
crypto_policies
시스템 역할에 의해 설정된 사실
crypto_policies_active
- 현재 선택한 정책을 나열합니다.
crypto_policies_available_policies
- 시스템에서 사용 가능한 모든 정책을 나열합니다.
crypto_policies_available_subpolicies
- 시스템에서 사용 가능한 모든 하위 정책을 나열합니다.
추가 리소스
16.2. crypto_policies
시스템 역할을 사용하여 사용자 정의 암호화 정책 설정
crypto_policies
시스템 역할을 사용하여 단일 제어 노드에서 다수의 관리형 노드를 일관되게 구성할 수 있습니다.
사전 요구 사항
-
crypto_policies
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드에 대한 액세스 및 권한.
제어 노드에서 다음을 수행합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible
, ansible-playbook
, docker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스 문서를 다운로드하고 설치하는 방법을 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위에 대한 지식베이스 문서를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - hosts: all tasks: - name: Configure crypto policies include_role: name: rhel-system-roles.crypto_policies vars: - crypto_policies_policy: FUTURE - crypto_policies_reboot_ok: true
FUTURE 값을 기본 암호화 정책(예:
DEFAULT
,LEGACY
,FIPS:OSPP
)으로 교체할 수 있습니다.crypto_policies_reboot_ok: true
변수를 사용하면 시스템 역할에서 암호화 정책을 변경한 후 시스템이 재부팅됩니다.자세한 내용은 crypto_policies 시스템 역할 변수 및 팩트 를 참조하십시오.
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file playbook.yml
검증
제어 노드에서
verify_playbook.yml
과 같은 다른 플레이북을 생성합니다.- hosts: all tasks: - name: Verify active crypto policy include_role: name: rhel-system-roles.crypto_policies - debug: var: crypto_policies_active
이 플레이북은 시스템의 구성을 변경하지 않고 관리 노드의 활성 정책만 보고합니다.
동일한 인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file verify_playbook.yml TASK [debug] ************************** ok: [host] => { "crypto_policies_active": "FUTURE" }
"crypto_policies_active":
변수는 관리 노드에서 정책을 활성으로 표시합니다.
16.3. 추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md
파일 -
ansible-playbook(1)
도움말 페이지. - RHEL 시스템 역할을 사용하도록 제어 노드 및 관리형 노드 준비
17장. RHEL 시스템 역할을 사용하여 CloudEvent 구성
17.1. nbde_client
및 nbde_server
시스템 역할 소개(Clevis 및 Tang)
RHEL 시스템 역할은 여러 RHEL 시스템을 원격으로 관리하는 일관된 구성 인터페이스를 제공하는 Ansible 역할 및 모듈의 컬렉션입니다.
RHEL 8.3에서는 Clevis 및 Tang을 사용하여 PBD(Policy-Based Decryption) 솔루션의 자동 배포를 위해 Ansible 역할을 도입했습니다. rhel-system-roles
패키지에는 이러한 시스템 역할, 관련 예제 및 참조 문서가 포함되어 있습니다.
nbde_client
시스템 역할을 사용하면 자동화된 방식으로 여러 Clevis 클라이언트를 배포할 수 있습니다. nbde_client
역할은 Tang 바인딩만 지원하며 현재 TPM2 바인딩에는 사용할 수 없습니다.
nbde_client
역할에는 LUKS를 사용하여 이미 암호화된 볼륨이 필요합니다. 이 역할은 LUKS 암호화 볼륨을 하나 이상의 Network-Bound(NBDE) 서버 - Tang 서버에 바인딩하도록 지원합니다. 암호를 사용하여 기존 볼륨 암호화를 보존하거나 제거할 수 있습니다. 암호를 제거한 후 Clevis를 사용하여 볼륨의 잠금을 해제할 수 있습니다. 이 기능은 시스템을 프로비저닝한 후 제거해야 하는 임시 키 또는 암호를 사용하여 볼륨을 처음 암호화할 때 유용합니다.
암호와 키 파일을 둘 다 제공하는 경우 역할은 먼저 제공한 항목을 사용합니다. 이러한 유효한 항목이 없는 경우 기존 바인딩에서 암호를 검색하려고 합니다.
PBD는 장치를 슬롯에 매핑하는 것으로 바인딩을 정의합니다. 즉, 동일한 장치에 대한 여러 바인딩을 사용할 수 있습니다. 기본 슬롯은 슬롯 1입니다.
nbde_client
역할은 state
변수도 제공합니다. 새 바인딩을 생성하거나 기존 바인딩을 업데이트하려면 present
값을 사용합니다. clevis luks bind
명령과 반대로 state: present
를 사용하여 장치 슬롯의 기존 바인딩을 덮어쓸 수도 있습니다. absent
값은 지정된 바인딩을 제거합니다.
nbde_client
시스템 역할을 사용하면 Tang 서버를 자동화된 디스크 암호화 솔루션의 일부로 배포하고 관리할 수 있습니다. 이 역할은 다음 기능을 지원합니다.
- Tang 키 교체
- Tang 키 배포 및 백업
추가 리소스
-
NFV(Network-Bound Disk Encryption) 역할 변수에 대한 자세한 내용은
rhel-system-roles
패키지를 설치하고/usr/share/doc/rhel-system-roles/nbde_client/
및/usr/share/doc/rhel-system-roles/nbde_server/
디렉터리의README.md
및README.html
파일을 참조하십시오. -
예를 들어 system-roles 플레이북을
rhel-system-roles
패키지를 설치하고/usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/
디렉터리를 참조하십시오. - RHEL 시스템 역할에 대한 자세한 내용은 RHEL 시스템 역할을 사용하도록 컨트롤 노드 및 관리형 노드 준비를 참조하십시오.
17.2. nbde_server
시스템 역할을 사용하여 여러 Tang 서버 설정
단계에 따라 Tang 서버 설정이 포함된 Ansible 플레이북을 준비하고 적용합니다.
사전 요구 사항
-
nbde_server
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드에 대한 액세스 및 권한.
제어 노드에서 다음을 수행합니다.
-
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
-
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible
, ansible-playbook
, docker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스 문서를 다운로드하고 설치하는 방법을 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위에 대한 지식베이스 문서를 참조하십시오.
- 관리 노드를 나열하는 인벤토리 파일.
절차
Tang 서버에 대한 설정이 포함된 플레이북을 준비합니다. 처음부터 시작하거나
/usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/
디렉터리의 예제 플레이북 중 하나를 사용할 수 있습니다.# cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml
선택한 텍스트 편집기에서 플레이북을 편집합니다. 예를 들면 다음과 같습니다.
# vi my-tang-playbook.yml
필수 매개 변수를 추가합니다. 다음 예제 플레이북은 Tang 서버와 키 교체의 배포를 확인합니다.
--- - hosts: all vars: nbde_server_rotate_keys: yes nbde_server_manage_firewall: true nbde_server_manage_selinux: true roles: - rhel-system-roles.nbde_server
참고nbde_server_manage_firewall
및nbde_server_manage_selinux
가 모두true
로 설정되므로nbde_server
역할은firewall
및selinux
역할을 사용하여nbde_server
역할에서 사용하는 포트를 관리합니다.완료된 플레이북을 적용합니다.
# ansible-playbook -i inventory-file my-tang-playbook.yml
여기서: *
inventory-file
은 인벤토리 파일입니다. *logging-playbook.yml
은 사용하는 플레이북입니다.
Clevis가 설치된 시스템에서 grubby
툴을 사용하여 초기 부팅 시 Tang 핀의 네트워킹을 사용할 수 있도록 하려면 다음을 수행합니다.
# grubby --update-kernel=ALL --args="rd.neednet=1"
추가 리소스
-
자세한 내용은
rhel-system-roles
패키지를 설치하고/usr/share/doc/rhel-system-roles/nbde_server/
및usr/share/ansible/rhel-system-roles.nbde_server/
디렉터리를 참조하십시오.
17.3. nbde_client
시스템 역할을 사용하여 여러 Clevis 클라이언트 설정
단계에 따라 Clevis 클라이언트 설정이 포함된 Ansible 플레이북을 준비하고 적용합니다.
nbde_client
시스템 역할은 Tang 바인딩만 지원합니다. 즉, 현재 TPM2 바인딩에 사용할 수 없습니다.
사전 요구 사항
-
nbde_client
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. - Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드 액세스 및 사용 권한.
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
rhel-system-roles
패키지는 플레이북을 실행하려는 시스템에 설치되어 있어야 합니다.
절차
Clevis 클라이언트에 대한 설정을 포함하는 플레이북을 준비합니다. 처음부터 시작하거나
/usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/
디렉터리의 예제 플레이북 중 하나를 사용할 수 있습니다.# cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml
선택한 텍스트 편집기에서 플레이북을 편집합니다. 예를 들면 다음과 같습니다.
# vi my-clevis-playbook.yml
필수 매개 변수를 추가합니다. 다음 예제 플레이북은 두 개 이상의 Tang 서버 중 하나를 사용할 수 있는 경우 에서 두 개의 LUKS 암호화 볼륨의 잠금 해제를 자동화하도록 Clevis 클라이언트를 구성합니다.
--- - hosts: all vars: nbde_client_bindings: - device: /dev/rhel/root encryption_key_src: /etc/luks/keyfile servers: - http://server1.example.com - http://server2.example.com - device: /dev/rhel/swap encryption_key_src: /etc/luks/keyfile servers: - http://server1.example.com - http://server2.example.com roles: - rhel-system-roles.nbde_client
완료된 플레이북을 적용합니다.
# ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml
Clevis가 설치된 시스템에서 grubby
툴을 사용하여 초기 부팅 시 Tang 핀의 네트워킹을 사용할 수 있도록 하려면 다음을 수행합니다.
# grubby --update-kernel=ALL --args="rd.neednet=1"
추가 리소스
-
NBDE 클라이언트 시스템 역할에 대한 매개변수 및 추가 정보에 대한 자세한 내용은
rhel-system-roles
패키지를 설치하고/usr/share/doc/rhel-system-roles/nbde_client/
및/usr/share/ansible/ansible/roles.nbde_client/
디렉터리를 참조하십시오.
18장. RHEL System Roles를 사용하여 인증서 요청
인증서
시스템 역할을 사용하면 Red Hat Ansible Core를 사용하여 인증서를 발행하고 관리할 수 있습니다.
이 장에서는 다음 주제를 다룹니다.
18.1. 인증서
시스템 역할
인증서
시스템 역할을 사용하면 Ansible Core를 사용하여 TLS 및 SSL 인증서 발행 및 갱신을 관리할 수 있습니다.
이 역할은 인증서 공급자로 certmonger
를 사용하며 현재 자체 서명된 인증서 발행 및 갱신 및 IdM CA(통합 인증 기관)를 사용하는 기능을 지원합니다.
인증서
시스템 역할을 사용하여 Ansible 플레이북에서 다음 변수를 사용할 수 있습니다.
certificate_wait
- 작업이 인증서가 발행될 때까지 기다려야 하는지 지정하는 방법은 다음과 같습니다.
certificate_requests
- 발급될 각 인증서와 해당 매개 변수를 나타냅니다.
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
파일을 참조하십시오. - RHEL 시스템 역할을 사용하도록 제어 노드 및 관리형 노드 준비
18.2. 인증서 시스템 역할을 사용하여 새 자체 서명 인증서
요청
인증서
시스템 역할을 사용하면 Ansible Core를 사용하여 자체 서명된 인증서를 발행할 수 있습니다.
이 프로세스에서는 certmonger
공급자를 사용하고 getcert
명령을 통해 인증서를 요청합니다.
기본적으로 certmonger
는 만료되기 전에 인증서를 자동으로 갱신하려고 합니다. Ansible 플레이북의 auto_renew
매개변수를 no
로 설정하여 이 매개변수를 비활성화할 수 있습니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다.
절차
선택 사항: 인벤토리 파일(예:
inventory.file
)을 생성합니다.$ *touch inventory.file*
인벤토리 파일을 열고 인증서를 요청할 호스트를 정의합니다. 예를 들면 다음과 같습니다.
[webserver] server.idm.example.com
플레이북 파일(예:
request-certificate.yml
)을 생성합니다.-
인증서를 요청하려는 호스트 (예:
webserver
)를 포함하도록 호스트를 설정합니다. 다음을 포함하도록
certificate_requests
변수를 설정합니다.-
name
매개변수를mycert
와 같이 원하는 인증서 이름으로 설정합니다. -
dns
매개변수를 인증서에 포함할 도메인(예:*.example.com
)으로 설정합니다. -
ca
매개변수를self-sign
으로 설정합니다.
-
역할에서
rhel-system-
역할을 설정합니다.roles
.certificate이 예제의 플레이북 파일입니다.
--- - hosts: webserver vars: certificate_requests: - name: mycert dns: "*.example.com" ca: self-sign roles: - rhel-system-roles.certificate
-
인증서를 요청하려는 호스트 (예:
- 파일을 저장합니다.
플레이북을 실행합니다.
$ *ansible-playbook -i inventory.file request-certificate.yml*
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
파일을 참조하십시오. -
ansible-playbook(1)
매뉴얼 페이지를 참조하십시오.
18.3. 인증서 시스템 역할을 사용하여 IdM CA에서 새 인증서
요청
인증
시스템 역할을 사용하면 anible-core
를 사용하여 통합 인증 기관(CA)이 있는 IdM 서버를 사용하는 동안 인증서를 발행할 수 있습니다. 따라서 IdM을 CA로 사용할 때 여러 시스템의 인증서 신뢰 체인을 효율적이고 일관되게 관리할 수 있습니다.
이 프로세스에서는 certmonger
공급자를 사용하고 getcert
명령을 통해 인증서를 요청합니다.
기본적으로 certmonger
는 만료되기 전에 인증서를 자동으로 갱신하려고 합니다. Ansible 플레이북의 auto_renew
매개변수를 no
로 설정하여 이 매개변수를 비활성화할 수 있습니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다.
절차
선택 사항: 인벤토리 파일(예:
inventory.file
)을 생성합니다.$ *touch inventory.file*
인벤토리 파일을 열고 인증서를 요청할 호스트를 정의합니다. 예를 들면 다음과 같습니다.
[webserver] server.idm.example.com
플레이북 파일(예:
request-certificate.yml
)을 생성합니다.-
인증서를 요청하려는 호스트 (예:
webserver
)를 포함하도록 호스트를 설정합니다. 다음을 포함하도록
certificate_requests
변수를 설정합니다.-
name
매개변수를mycert
와 같이 원하는 인증서 이름으로 설정합니다. -
인증서에 포함할
dns
매개변수를 도메인(예: www.example.com)으로설정합니다
. -
Kerberos 주체를 지정하려면
principal
매개변수를 설정합니다(예:HTTP/www.example.com@EXAMPLE.COM
). -
ca
매개변수를ipa
로 설정합니다.
-
역할에서
rhel-system-
역할을 설정합니다.roles
.certificate이 예제의 플레이북 파일입니다.
--- - hosts: webserver vars: certificate_requests: - name: mycert dns: www.example.com principal: HTTP/www.example.com@EXAMPLE.COM ca: ipa roles: - rhel-system-roles.certificate
-
인증서를 요청하려는 호스트 (예:
- 파일을 저장합니다.
플레이북을 실행합니다.
$ *ansible-playbook -i inventory.file request-certificate.yml*
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
파일을 참조하십시오. -
ansible-playbook(1)
매뉴얼 페이지를 참조하십시오.
18.4. 인증서 시스템 역할을 사용하여 인증서 발급 전 또는 이후에 실행할 명령 지정
인증서
역할을 사용하면 Ansible Core를 사용하여 인증서를 발행하거나 갱신하기 전과 후에 명령을 실행할 수 있습니다.
다음 예에서 관리자는 www.example.com
에 대한 자체 서명된 인증서가 발행되거나 갱신되기 전에 httpd
서비스를 중지한 후 나중에 다시 시작합니다.
기본적으로 certmonger
는 만료되기 전에 인증서를 자동으로 갱신하려고 합니다. Ansible 플레이북의 auto_renew
매개변수를 no
로 설정하여 이 매개변수를 비활성화할 수 있습니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다.
절차
선택 사항: 인벤토리 파일(예:
inventory.file
)을 생성합니다.$ *touch inventory.file*
인벤토리 파일을 열고 인증서를 요청할 호스트를 정의합니다. 예를 들면 다음과 같습니다.
[webserver] server.idm.example.com
플레이북 파일(예:
request-certificate.yml
)을 생성합니다.-
인증서를 요청하려는 호스트 (예:
webserver
)를 포함하도록 호스트를 설정합니다. 다음을 포함하도록
certificate_requests
변수를 설정합니다.-
name
매개변수를mycert
와 같이 원하는 인증서 이름으로 설정합니다. -
인증서에 포함할
dns
매개변수를 도메인(예: www.example.com)으로설정합니다
. -
ca
매개변수를 인증서 발행에 사용할 CA(예:자체 서명
)로 설정합니다. -
이 인증서를 발행하거나 갱신하기 전에 실행할
run_before
매개변수를systemctl stop httpd.service
와 같이 설정합니다. -
이 인증서를 발행하거나 갱신하려는 명령(예:
systemctl start httpd.service
)으로run_after
매개변수를 설정합니다.
-
역할에서
rhel-system-
역할을 설정합니다.roles
.certificate이 예제의 플레이북 파일입니다.
--- - hosts: webserver vars: certificate_requests: - name: mycert dns: www.example.com ca: self-sign run_before: systemctl stop httpd.service run_after: systemctl start httpd.service roles: - rhel-system-roles.certificate
-
인증서를 요청하려는 호스트 (예:
- 파일을 저장합니다.
플레이북을 실행합니다.
$ *ansible-playbook -i inventory.file request-certificate.yml*
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
파일을 참조하십시오. -
ansible-playbook(1)
매뉴얼 페이지를 참조하십시오.
19장. kdump
RHEL 시스템 역할을 사용하여 자동 크래시 덤프 구성
Ansible을 사용하여 kdump를 관리하려면 RHEL 8에서 사용할 수 있는 RHEL 시스템 역할 중 하나인 kdump
역할을 사용할 수 있습니다.
kdump
역할을 사용하면 나중에 분석을 위해 시스템 메모리의 콘텐츠를 저장할 위치를 지정할 수 있습니다.
RHEL 시스템 역할 및 적용하는 방법에 대한 자세한 내용은 RHEL 시스템 역할 소개를 참조하십시오.
19.1. kdump
RHEL 시스템 역할
kdump
시스템 역할을 사용하면 여러 시스템에서 기본 커널 덤프 매개변수를 설정할 수 있습니다.
19.2. kdump
역할 매개변수
kdump
RHEL 시스템 역할에 사용되는 매개변수는 다음과 같습니다.
역할 변수 | 설명 |
---|---|
kdump_path |
|
추가 리소스
- makedumpfile(8) 매뉴얼 페이지.
-
kdump
에 사용되는 매개변수 및kdump
시스템 역할에 대한 추가 정보는/usr/share/ansible/roles/rhel-system-roles.tlog/README.md
파일을 참조하십시오.
19.3. RHEL 시스템 역할을 사용하여 kdump 구성
Ansible 플레이북을 실행하여 kdump
시스템 역할을 사용하여 여러 시스템에서 기본 커널 덤프 매개변수를 설정할 수 있습니다.
kdump
역할은 /etc/kdump.conf
파일을 교체하여 관리 호스트의 kdump 구성을 완전히 대체합니다. 또한 kdump
역할이 적용된 경우 /etc/sysconfig/kdump
파일을 교체하여 역할 변수에 의해 지정되지 않은 경우에도 모든 이전 kdump
설정도 교체됩니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. -
kdump
를 배포할 시스템을 나열하는 인벤토리 파일이 있습니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - hosts: kdump-test vars: kdump_path: /var/crash roles: - rhel-system-roles.kdump
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
추가 리소스
-
kdump
역할 변수에 대한 자세한 참조는 /usr/share/doc/rhel-system-roles/kdump 디렉터리의 README.md 또는 README.html 파일을 참조하십시오. - RHEL System Roles를 사용하도록 제어 노드 및 관리형 노드 준비에서 참조하십시오.
-
rhel-system-roles
패키지/usr/share/ansible/roles/rhel-system-roles.kdump/README.html
과 함께 설치된 문서
20장. RHEL 시스템 역할을 사용하여 로컬 스토리지 관리
Ansible을 사용하여 LVM 및 로컬 파일 시스템(FS)을 관리하려면 RHEL 8에서 사용할 수 있는 RHEL 시스템 역할 중 하나인 스토리지
역할을 사용할 수 있습니다.
스토리지
역할을 사용하면 RHEL 7.7부터 시작하여 여러 시스템의 디스크 및 논리 볼륨에서 파일 시스템 관리를 자동화할 수 있습니다.
RHEL 시스템 역할 및 적용하는 방법에 대한 자세한 내용은 RHEL 시스템 역할 소개를 참조하십시오.
20.1. 스토리지
RHEL 시스템 역할 소개
스토리지
역할은 다음을 관리할 수 있습니다.
- 분할되지 않은 디스크의 파일 시스템
- 논리 볼륨 및 파일 시스템을 포함한 전체 LVM 볼륨 그룹
- MD RAID 볼륨 및 파일 시스템
스토리지
역할을 사용하면 다음 작업을 수행할 수 있습니다.
- 파일 시스템 생성
- 파일 시스템 제거
- 파일 시스템 마운트
- 파일 시스템 마운트 해제
- LVM 볼륨 그룹 생성
- LVM 볼륨 그룹 제거
- 논리 볼륨 생성
- 논리 볼륨 제거
- RAID 볼륨 생성
- RAID 볼륨 제거
- RAID를 사용하여 LVM 볼륨 그룹 생성
- RAID를 사용하여 LVM 볼륨 그룹 제거
- 암호화된 LVM 볼륨 그룹 만들기
- RAID를 사용하여 LVM 논리 볼륨 생성
20.2. 스토리지 RHEL 시스템 역할에서 스토리지
장치를 식별하는 매개변수
스토리지
역할 구성은 다음 변수에 나열된 파일 시스템, 볼륨 및 풀에만 영향을 미칩니다.
storage_volumes
파티션되지 않은 모든 디스크의 파일 시스템 목록 관리.
storage_volumes
에는raid
볼륨도 포함될 수 있습니다.파티션은 현재 지원되지 않습니다.
storage_pools
관리할 풀 목록입니다.
현재 지원되는 유일한 풀 유형은 LVM입니다. LVM을 사용하면 풀은 볼륨 그룹(VG)을 나타냅니다. 각 풀에는 역할이 관리할 볼륨 목록이 있습니다. LVM을 사용하면 각 볼륨이 파일 시스템의 논리 볼륨(LV)에 해당합니다.
20.3. 블록 장치에서 XFS 파일 시스템을 생성하는 Ansible 플레이북의 예
예제 Ansible 플레이북은 기본 매개 변수를 사용하여 블록 장치에서 XFS 파일 시스템을 생성하는 데 storage
역할을 적용합니다.
스토리지
역할은 파티션되지 않은 전체 디스크 또는 논리 볼륨(LV)에만 파일 시스템을 생성할 수 있습니다. 파티션에 파일 시스템을 만들 수 없습니다.
예 20.1. /dev/sdb에서 XFS를 생성하는 플레이북
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs roles: - rhel-system-roles.storage
-
현재 예제의 볼륨 이름(예:
베어fs
)은 임의로 지정됩니다.스토리지
역할은disks:
속성에 나열된 디스크 장치에서 볼륨을 식별합니다. -
XFS는 RHEL 8의 기본 파일 시스템이므로
fs_type: xfs
행을 생략할 수 있습니다. LV에 파일 시스템을 생성하려면 enclosing 볼륨 그룹을 포함하여
disks:
속성 아래에 LVM 설정을 제공합니다. 자세한 내용은 논리 볼륨을 관리하는 Ansible 플레이북 예제를 참조하십시오.LV 장치의 경로를 제공하지 마십시오.
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.4. 파일 시스템을 영구적으로 마운트하는 Ansible Playbook의 예
예제 Ansible은 스토리지
역할을 XFS 파일 시스템에 즉시 영구적으로 마운트하는 데 적용합니다.
예 20.2. /dev/sdb의 파일 시스템을 /mnt/data에 마운트하는 플레이북
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data roles: - rhel-system-roles.storage
-
이 Playbook은 파일 시스템을
/etc/fstab
파일에 추가하고 파일 시스템을 즉시 마운트합니다. -
/dev/sdb
장치의 파일 시스템 또는 마운트 지점 디렉터리가 없으면 플레이북에서 생성합니다.
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.5. 논리 볼륨을 관리하는 Ansible Playbook 예
예제 Ansible 플레이북은 storage
역할을 적용하여 볼륨 그룹에 LVM 논리 볼륨을 생성합니다.
예 20.3. myvg 볼륨 그룹에 mylv 논리 볼륨을 생성하는 플레이북
- hosts: all vars: storage_pools: - name: myvg disks: - sda - sdb - sdc volumes: - name: mylv size: 2G fs_type: ext4 mount_point: /mnt/data roles: - rhel-system-roles.storage
myvg
볼륨 그룹은 다음 디스크로 구성됩니다.-
/dev/sda
-
/dev/sdb
-
/dev/sdc
-
-
myvg
볼륨 그룹이 이미 있는 경우 플레이북은 볼륨 그룹에 논리 볼륨을 추가합니다. -
myvg
볼륨 그룹이 없으면 플레이북에서 생성합니다. -
Playbook은
mylv
논리 볼륨에 Ext4 파일 시스템을 생성하고/mnt
에 파일 시스템을 영구적으로 마운트합니다.
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.6. 온라인 블록 삭제 활성화를 위한 Ansible Playbook의 예
예제 Ansible 플레이북은 스토리지
역할을 적용하여 온라인 블록 삭제가 활성화된 XFS 파일 시스템을 마운트합니다.
예 20.4. /mnt/data/에서 온라인 블록 삭제 가능 플레이북
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data mount_options: discard roles: - rhel-system-roles.storage
추가 리소스
- 파일 시스템을 영구적으로 마운트하는 Ansible Playbook의 예
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.7. Ext4 파일 시스템을 생성하고 마운트하는 Ansible Playbook의 예
예제 Ansible 플레이북은 Ext4 파일 시스템을 생성하고 마운트하는 스토리지
역할을 적용합니다.
예 20.5. /dev/sdb에서 Ext4를 생성하여 /mnt/data에 마운트하는 플레이북
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext4 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage
-
Playbook은
/dev/sdb
디스크에 파일 시스템을 생성합니다. -
플레이북은
/mnt/data
디렉터리에 파일 시스템을 영구적으로 마운트합니다. -
파일 시스템의 레이블은
label-name
입니다.
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.8. ext3 파일 시스템을 생성하고 마운트하는 Ansible Playbook의 예
예제 Ansible 플레이북은 Ext3 파일 시스템을 생성하고 마운트하는 스토리지
역할을 적용합니다.
예 20.6. /dev/sdb
에서 Ext3을 생성하여 /mnt/data
에 마운트하는 플레이북
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext3 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage
-
Playbook은
/dev/sdb
디스크에 파일 시스템을 생성합니다. -
플레이북은
/mnt/data
디렉터리에 파일 시스템을 영구적으로 마운트합니다. -
파일 시스템의 레이블은
label-name
입니다.
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.9. 스토리지
RHEL 시스템 역할을 사용하여 기존 Ext4 또는 Ext3 파일 시스템의 크기를 조정하는 Ansible 플레이북의 예
예제 Ansible 플레이북은 storage
역할을 적용하여 블록 장치에서 기존 Ext4 또는 Ext3 파일 시스템의 크기를 조정합니다.
예 20.7. 디스크에 단일 볼륨을 설정하는 플레이북
---
- name: Create a disk device mounted on /opt/barefs
- hosts: all
vars:
storage_volumes:
- name: barefs
type: disk
disks:
- /dev/sdb
size: 12 GiB
fs_type: ext4
mount_point: /opt/barefs
roles:
- rhel-system-roles.storage
-
이전 예제의 볼륨이 이미 존재하는 경우 볼륨 크기를 조정하려면 매개 변수
크기의
다른 값으로만 동일한 플레이북을 실행해야 합니다. 예를 들면 다음과 같습니다.
예 20.8. /dev/sdb
에서 ext4
의 크기를 조정하는 플레이북
---
- name: Create a disk device mounted on /opt/barefs
- hosts: all
vars:
storage_volumes:
- name: barefs
type: disk
disks:
- /dev/sdb
size: 10 GiB
fs_type: ext4
mount_point: /opt/barefs
roles:
- rhel-system-roles.storage
- 볼륨 이름(예:barefs)은 현재 임의입니다. 스토리지 역할은 disks: 속성에 나열된 디스크 장치에서 볼륨을 식별합니다.
다른 파일 시스템에서 크기 조정
작업을 사용하면 작업 중인 장치의 데이터를 삭제할 수 있습니다.
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.10. 스토리지
RHEL 시스템 역할을 사용하여 LVM의 기존 파일 시스템의 크기를 조정하는 Ansible 플레이북의 예
예제 Ansible 플레이북은 스토리지
RHEL 시스템 역할을 적용하여 파일 시스템으로 LVM 논리 볼륨의 크기를 조정합니다.
다른 파일 시스템에서 크기 조정
작업을 사용하면 작업 중인 장치의 데이터를 삭제할 수 있습니다.
예 20.9. myvg 볼륨 그룹의 기존 mylv1 및 myvl2 논리 볼륨의 크기를 조정하는 플레이북
--- - hosts: all vars: storage_pools: - name: myvg disks: - /dev/sda - /dev/sdb - /dev/sdc volumes: - name: mylv1 size: 10 GiB fs_type: ext4 mount_point: /opt/mount1 - name: mylv2 size: 50 GiB fs_type: ext4 mount_point: /opt/mount2 - name: Create LVM pool over three disks include_role: name: rhel-system-roles.storage
이 플레이북은 다음과 같은 기존 파일 시스템의 크기를 조정합니다.
-
/opt/mount1
에 마운트된mylv1
볼륨의 Ext4 파일 시스템의 크기 조정을 10GiB로 조정합니다. -
/opt/mount2
에 마운트된mylv2
볼륨의 Ext4 파일 시스템의 크기 조정을 50GiB로 조정합니다.
-
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.11. 스토리지
RHEL 시스템 역할을 사용하여 스왑 볼륨을 생성하는 Ansible 플레이북의 예
이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 스토리지
역할을 적용하여 스왑 볼륨이 없는 경우, 기본 매개 변수를 사용하는 블록 장치에 스왑 볼륨을 생성하거나 스왑 볼륨을 수정합니다.
예 20.10. /dev/sdb에서 기존 XFS를 생성하거나 수정하는 플레이북
--- - name: Create a disk device with swap - hosts: all vars: storage_volumes: - name: swap_fs type: disk disks: - /dev/sdb size: 15 GiB fs_type: swap roles: - rhel-system-roles.storage
-
볼륨 이름(예:
swap_fs
)은 현재 임의입니다.스토리지
역할은disks:
속성에 나열된 디스크 장치에서 볼륨을 식별합니다.
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.12. 스토리지 시스템 역할을 사용하여 RAID 볼륨 구성
스토리지
시스템 역할을 사용하면 Red Hat Ansible Automation Platform 및 Ansible-Core를 사용하여 RHEL에서 RAID 볼륨을 구성할 수 있습니다. 매개 변수로 Ansible 플레이북을 생성하여 요구 사항에 맞게 RAID 볼륨을 구성합니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. -
스토리지
시스템 역할을 사용하여 RAID 볼륨을 배포하려는 시스템을 자세히 설명하는 인벤토리 파일이 있습니다.
절차
다음 내용으로 새 playbook.yml 파일을 생성합니다.
--- - name: Configure the storage hosts: managed-node-01.example.com tasks: - name: Create a RAID on sdd, sde, sdf, and sdg include_role: name: rhel-system-roles.storage vars: storage_safe_mode: false storage_volumes: - name: data type: raid disks: [sdd, sde, sdf, sdg] raid_level: raid0 raid_chunk_size: 32 KiB mount_point: /mnt/data state: present
주의특정 상황에서 장치 이름이 변경될 수 있습니다(예: 시스템에 새 디스크를 추가할 때). 따라서 데이터 손실을 방지하려면 플레이북에서 특정 디스크 이름을 사용하지 마십시오.
선택 사항: 플레이북 구문 확인:
# ansible-playbook --syntax-check playbook.yml
플레이북을 실행합니다.
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
추가 리소스
- RAID 관리
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일 - RHEL 시스템 역할을 사용하도록 제어 노드 및 관리형 노드 준비
20.13. 스토리지
RHEL 시스템 역할을 사용하여 RAID로 LVM 풀 구성
스토리지
시스템 역할을 사용하면 Red Hat Ansible Automation Platform을 사용하여 RHEL에서 RAID로 LVM 풀을 구성할 수 있습니다. 사용 가능한 매개 변수로 Ansible 플레이북을 설정하여 RAID로 LVM 풀을 구성할 수 있습니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. -
스토리지
시스템 역할을 사용하여 RAID로 LVM 풀을 구성하려는 시스템을 자세히 설명하는 인벤토리 파일이 있습니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.- hosts: all vars: storage_safe_mode: false storage_pools: - name: my_pool type: lvm disks: [sdh, sdi] raid_level: raid1 volumes: - name: my_pool size: "1 GiB" mount_point: "/mnt/app/shared" fs_type: xfs state: present roles: - name: rhel-system-roles.storage
참고RAID를 사용하여 LVM 풀을 생성하려면
raid_level
매개변수를 사용하여 RAID 유형을 지정해야 합니다.선택 사항: 플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
추가 리소스
- RAID 관리.
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.14. 스토리지
RHEL 시스템 역할을 사용하여 LVM에서 VDO 볼륨을 압축 및 중복 해제하는 Ansible Playbook 예
예제 Ansible 플레이북은 스토리지
RHEL 시스템 역할을 적용하여 VDO(Virtual Data Optimizer)를 사용하여 LVM(Logical Volumes)을 압축하고 중복 제거할 수 있습니다.
예 20.11. myvg
볼륨 그룹에 mylv1
LVM VDO 볼륨을 생성하는 플레이북
--- - name: Create LVM VDO volume under volume group 'myvg' hosts: all roles: -rhel-system-roles.storage vars: storage_pools: - name: myvg disks: - /dev/sdb volumes: - name: mylv1 compression: true deduplication: true vdo_pool_size: 10 GiB size: 30 GiB mount_point: /mnt/app/shared
이 예에서는 압축
및 중복 제거
풀이 true로 설정되어 VDO를 사용하도록 지정합니다. 다음은 이러한 매개변수의 사용법을 설명합니다.
-
중복
제거는 스토리지 볼륨에 저장된 중복된 데이터를 중복 해제하는 데 사용됩니다. - 압축은 스토리지 볼륨에 저장된 데이터를 압축하는 데 사용되며, 이로 인해 스토리지 용량이 증가합니다.
-
vdo_pool_size는 볼륨이 장치에서 사용하는 실제 크기를 지정합니다. VDO 볼륨의 가상 크기는
size
매개변수로 설정됩니다. 참고: LVM VDO의 스토리지 역할 사용으로 인해 풀당 하나의 볼륨만 압축 및 중복 제거를 사용할 수 있습니다.
20.15. 스토리지
RHEL 시스템 역할을 사용하여 LUKS2 암호화된 볼륨 생성
storage
역할을 사용하여 Ansible 플레이북을 실행하여 LUKS로 암호화된 볼륨을 생성하고 구성할 수 있습니다.
사전 요구 사항
-
crypto_policies
시스템 역할로 구성하려는 시스템인 하나 이상의 관리형 노드에 대한 액세스 및 권한. - 관리 노드를 나열하는 인벤토리 파일입니다.
-
Red Hat Ansible Core가 기타 시스템을 구성하는 시스템인 제어 노드에 대한 액세스 및 권한. 제어 노드에서
ansible-core
및rhel-system-roles
패키지가 설치됩니다.
RHEL 8.0-8.5는 Ansible 기반 자동화를 위해 Ansible Engine 2.9가 포함된 별도의 Ansible 리포지토리에 대한 액세스를 제공했습니다. Ansible Engine에는 ansible
, ansible-playbook
, docker
및 podman
과 같은 커넥터, 여러 플러그인 및 모듈과 같은 명령줄 유틸리티가 포함되어 있습니다. Ansible Engine을 확보하고 설치하는 방법에 대한 자세한 내용은 Red Hat Ansible Engine 지식베이스 문서를 다운로드하고 설치하는 방법을 참조하십시오.
RHEL 8.6 및 9.0에서는 Ansible 명령줄 유틸리티, 명령 및 소규모의 기본 제공 Ansible 플러그인 세트가 포함된 Ansible Core( ansible-core
패키지로 제공)를 도입했습니다. RHEL은 AppStream 리포지토리를 통해 이 패키지를 제공하며 제한된 지원 범위를 제공합니다. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리 지식 베이스에 포함된 Ansible Core 패키지에 대한 지원 범위에 대한 지식베이스 문서를 참조하십시오.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.- hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs fs_label: label-name mount_point: /mnt/data encryption: true encryption_password: your-password roles: - rhel-system-roles.storage
playbook.yml 파일의
encryption_key
,encryption_cipher
,encryption_key_size
,encryption_luks
버전과 같은 다른 암호화 매개변수도 추가할 수 있습니다.선택 사항: 플레이북 구문 확인:
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
검증
암호화 상태를 확인합니다.
# cryptsetup status sdb /dev/mapper/sdb is active and is in use. type: LUKS2 cipher: aes-xts-plain64 keysize: 512 bits key location: keyring device: /dev/sdb [...]
생성된 LUKS 암호화된 볼륨을 확인합니다.
# cryptsetup luksDump /dev/sdb Version: 2 Epoch: 6 Metadata area: 16384 [bytes] Keyslots area: 33521664 [bytes] UUID: a4c6be82-7347-4a91-a8ad-9479b72c9426 Label: (no label) Subsystem: (no subsystem) Flags: allow-discards Data segments: 0: crypt offset: 33554432 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 4096 [bytes] [...]
스토리지
역할이 지원하는playbook.yml
파일에서cryptsetup
매개변수를 확인합니다.# cat ~/playbook.yml - hosts: all vars: storage_volumes: - name: foo type: disk disks: - nvme0n1 fs_type: xfs fs_label: label-name mount_point: /mnt/data encryption: true #encryption_password: passwdpasswd encryption_key: /home/passwd_key encryption_cipher: aes-xts-plain64 encryption_key_size: 512 encryption_luks_version: luks2 roles: - rhel-system-roles.storage
추가 리소스
- LUKS를 사용하여 블록 장치 암호화
-
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
파일
20.16. 스토리지
RHEL 시스템 역할을 사용하여 풀 볼륨 크기를 백분율로 표시하는 Ansible 플레이북의 예
예제 Ansible 플레이북은 스토리지
시스템 역할을 적용하여 논리 관리자 볼륨(LVM) 볼륨 크기를 풀의 총 크기의 백분율로 표시할 수 있습니다.
예 20.12. 볼륨 크기를 풀의 총 크기의 백분율로 나타내는 플레이북
--- - name: Express volume sizes as a percentage of the pool's total size hosts: all roles - rhel-system-roles.storage vars: storage_pools: - name: myvg disks: - /dev/sdb volumes: - name: data size: 60% mount_point: /opt/mount/data - name: web size: 30% mount_point: /opt/mount/web - name: cache size: 10% mount_point: /opt/cache/mount
이 예에서는 LVM 볼륨의 크기를 풀 크기의 백분율로 지정합니다(예: "60%"). 또한 LVM 볼륨의 크기를 사람이 읽을 수 있는 파일 시스템의 크기(예: "10g" 또는 "50GiB)에서 풀 크기의 백분율로 지정할 수도 있습니다.
20.17. 추가 리소스
-
/usr/share/doc/rhel-system-roles/storage/
-
/usr/share/ansible/roles/rhel-system-roles.storage/
21장. timesync
RHEL 시스템 역할을 사용하여 시간 동기화 구성
timesync
RHEL 시스템 역할을 사용하면 Red Hat Ansible Automation Platform을 사용하여 RHEL의 여러 대상 시스템에서 시간 동기화를 관리할 수 있습니다.
21.1. timesync
RHEL 시스템 역할
timesync
RHEL 시스템 역할을 사용하여 여러 대상 시스템에서 시간 동기화를 관리할 수 있습니다.
timesync
역할은 PTP 도메인의 NTP 서버 또는 경직 마스터와 시스템 시계를 동기화하기 위해 NTP 클라이언트 또는 PTP 복제본으로 작동하도록 NTP 또는 PTP 구현을 설치하고 구성합니다.
또한 timesync
역할을 사용하면 시스템이 ntp
또는 chrony를 사용하여 NTP 프로토콜을 구현하는지 여부와 관계없이 RHEL 6부터 모든 Red Hat Enterprise Linux 버전에서 동일한 플레이북을 사용할 수 있으므로 chrony
로 쉽게 마이그레이션할 수 있습니다.
21.2. 단일 서버 풀에 timesync
시스템 역할 적용
다음 예제에서는 서버 풀이 한 개뿐인 상황에서 timesync
역할을 적용하는 방법을 보여줍니다.
timesync
역할은 관리 호스트에서 지정된 공급자 서비스 또는 감지된 공급자 서비스의 구성을 대체합니다. 이전 설정은 역할 변수에 지정되지 않은 경우에도 손실됩니다. timesync_ntp_provider
변수가 정의되지 않은 경우 유일하게 보존된 설정은 provider 중에서 선택할 수 있습니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. -
timesync
시스템 역할을 배포하려는 시스템을 나열하는 인벤토리 파일이 있습니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - hosts: timesync-test vars: timesync_ntp_servers: - hostname: 2.rhel.pool.ntp.org pool: yes iburst: yes roles: - rhel-system-roles.timesync
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
21.3. 클라이언트 서버에 timesync
시스템 역할 적용
timesync
역할을 사용하여 NTP 클라이언트에서 Network Time Security (NTS)를 활성화할 수 있습니다. Network Time Security (NTS)는 NTP(Network Time Protocol)에 대해 지정된 인증 메커니즘입니다. 서버와 클라이언트 간에 교환된 NTP 패킷이 변경되지 않았는지 확인합니다.
timesync
역할은 관리 호스트에서 지정된 공급자 서비스 또는 감지된 공급자 서비스의 구성을 대체합니다. 이전 설정은 역할 변수에 지정되지 않은 경우에도 손실됩니다. timesync_ntp_provider
변수가 정의되지 않은 경우 유일하게 보존된 설정은 provider 중에서 선택할 수 있습니다.
사전 요구 사항
-
timesync
솔루션을 배포하려는 시스템에 Red Hat Ansible Automation Platform을 설치할 필요가 없습니다. -
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. -
timesync
시스템 역할을 배포하려는 시스템을 나열하는 인벤토리 파일이 있습니다. -
chrony
NTP 공급자 버전은 4.0 이상입니다.
절차
다음 내용으로
playbook.yml
파일을 생성합니다.--- - hosts: timesync-test vars: timesync_ntp_servers: - hostname: ptbtime1.ptb.de iburst: yes nts: yes roles: - rhel-system-roles.timesync
ptbtime1.ptb.de
는 공용 서버의 예입니다. 다른 공용 서버 또는 자체 서버를 사용할 수 있습니다.선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
검증
클라이언트 시스템에서 테스트를 수행합니다.
# chronyc -N authdata Name/IP address Mode KeyID Type KLen Last Atmp NAK Cook CLen ===================================================================== ptbtime1.ptb.de NTS 1 15 256 157 0 0 8 100
- 보고된 쿠키 수가 0보다 큰지 확인합니다.
추가 리소스
-
chrony.conf(5)
man page
21.4. timesync
시스템 역할 변수
다음 변수를 timesync
역할에 전달할 수 있습니다.
-
timesync_ntp_servers
:
역할 변수 설정 | 설명 |
---|---|
hostname: host.example.com | 서버의 호스트 이름 또는 주소 |
minpoll: 번호 | 최소 폴링 간격입니다. 기본값: 6 |
maxpoll: 번호 | 최대 폴링 간격입니다. 기본값: 10 |
iburst: yes | 빠른 초기 동기화를 활성화하는 플래그입니다. 기본값: no |
Pool: yes | 호스트 이름의 각 확인된 주소가 별도의 NTP 서버임을 나타내는 플래그입니다. 기본값: no |
NTS: yes | 네트워크 시간 보안(NTS) 활성화에 플래그입니다. 기본값: no. chrony >= 4.0에서만 지원됩니다. |
추가 리소스
-
timesync
역할 변수에 대한 자세한 참조는 rhel-system-roles 패키지를 설치하고/usr/share/doc/rhel-system-roles/timesync
디렉터리의 README.md 또는 README.html 파일을 참조하십시오.
22장. 지표
RHEL 시스템 역할을 사용하여 성능 모니터링
시스템 관리자는 메트릭
RHEL 시스템 역할을 Ansible Automation Platform 제어 노드와 함께 사용하여 시스템의 성능을 모니터링할 수 있습니다.
22.1. 메트릭
시스템 역할 소개
RHEL 시스템 역할은 여러 RHEL 시스템을 원격으로 관리하는 일관된 구성 인터페이스를 제공하는 Ansible 역할 및 모듈의 컬렉션입니다. 지표
시스템 역할은 로컬 시스템의 성능 분석 서비스를 구성하며 선택적으로 로컬 시스템에서 모니터링할 원격 시스템 목록을 포함합니다. 지표
시스템 역할을 사용하면 플레이북에서
를 설정 및 배포할 수 있으므로 pcp
pcp
를 별도로 구성하지 않고도 시스템 성능을 모니터링할 수 있습니다.
표 22.1. 메트릭
시스템 역할 변수
역할 변수 | 설명 | 사용 예 |
---|---|---|
metrics_monitored_hosts |
대상 호스트에서 분석할 원격 호스트 목록입니다. 이러한 호스트는 대상 호스트에 기록된 지표가 있으므로 각 호스트에 대해 |
|
metrics_retention_days | 삭제하기 전에 성능 데이터 보존의 일 수를 구성합니다. |
|
metrics_graph_service |
|
|
metrics_query_service |
|
|
metrics_provider |
지표를 제공하는 데 사용할 메트릭 수집기를 지정합니다. 현재 |
|
metrics_manage_firewall |
|
|
metrics_manage_selinux |
|
|
에 사용되는 매개변수 및 지표 시스템 역할에 대한 자세한 내용은 metrics
_connections/usr/share/ansible/roles/rhel-system-roles.metrics/README.md
파일을 참조하십시오.
22.2. 메트릭
시스템 역할을 사용하여 로컬 시스템에 시각화를 통해 모니터링
다음 절차에서는 Grafana
를 통해 데이터 시각화를 동시에 프로비저닝하는 동안 메트릭
RHEL 시스템 역할을 사용하여 로컬 시스템을 모니터링하는 방법을 설명합니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
모니터링하려는 머신에
rhel-system-roles
패키지가 설치되어 있습니다.
절차
인벤토리에 다음 콘텐츠를 추가하여
/etc/ansible/hosts
Ansible 인벤토리에서localhost
를 구성합니다.localhost ansible_connection=local
다음 내용으로 Ansible 플레이북을 생성합니다.
--- - name: Manage metrics hosts: localhost vars: metrics_graph_service: yes metrics_manage_firewall: true metrics_manage_selinux: true roles: - rhel-system-roles.metrics
Ansible Playbook을 실행합니다.
# ansible-playbook name_of_your_playbook.yml
참고metrics_graph_service
부울이value="yes"
로 설정되므로Grafana
는 데이터 소스로 추가된pcp
를 사용하여 자동으로 설치 및 프로비저닝됩니다.metrics_manage_firewall
및metrics_manage_selinux
가 모두true
로 설정되므로 지표 역할은firewall
및selinux
시스템 역할을 사용하여 metrics 역할에서 사용하는 포트를 관리합니다.-
시스템에서 수집되는 메트릭의 시각화를 보려면 Grafana 웹 UI 액세스에 설명된 대로
grafana
웹 인터페이스에 액세스 합니다.
22.3. 메트릭
시스템 역할을 사용하여 자체적으로 모니터링할 개별 시스템 설정
이 절차에서는 메트릭
시스템 역할을 사용하여 자체적으로 모니터링할 시스템 제품군을 설정하는 방법을 설명합니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하는 데 사용할 머신에
rhel-system-roles
패키지가 설치되어 있습니다. - SSH 연결이 설정되어 있습니다.
절차
플레이북을 통해 모니터링할 시스템의 이름 또는 IP 주소를 대괄호로 묶은 식별 그룹 이름 아래의
/etc/ansible/hosts
Ansible 인벤토리 파일에 추가합니다.[remotes] webserver.example.com database.example.com
다음 내용으로 Ansible 플레이북을 생성합니다.
--- - hosts: remotes vars: metrics_retention_days: 0 metrics_manage_firewall: true metrics_manage_selinux: true roles: - rhel-system-roles.metrics
참고metrics_manage_firewall
및metrics_manage_selinux
가 모두true
로 설정되므로 지표 역할은firewall
및selinux
역할을 사용하여metrics
역할에서 사용하는 포트를 관리합니다.Ansible Playbook을 실행합니다.
# ansible-playbook name_of_your_playbook.yml -k
원격 시스템에 연결하기 위한 암호 입력 프롬프트입니다.
22.4. 메트릭
시스템 역할을 사용하여 로컬 컴퓨터를 통해 중앙 집중적으로 시스템 모니터링
이 절차에서는 메트릭
시스템 역할을 사용하여 머신 함대를 중앙에서 모니터링하는 동시에 redis를 통해 데이터의 시각화를 프로비저닝하고 redis
를 통해 데이터를 쿼리하는 방법을 설명합니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하는 데 사용할 머신에
rhel-system-roles
패키지가 설치되어 있습니다.
절차
다음 내용으로 Ansible 플레이북을 생성합니다.
--- - hosts: localhost vars: metrics_graph_service: yes metrics_query_service: yes metrics_retention_days: 10 metrics_monitored_hosts: ["database.example.com", "webserver.example.com"] metrics_manage_firewall: yes metrics_manage_selinux: yes roles: - rhel-system-roles.metrics
Ansible Playbook을 실행합니다.
# ansible-playbook name_of_your_playbook.yml
참고metrics_graph_service
및metrics_query_service
부울이value="yes"
로 설정되므로grafana
는pcp
redis
로 인덱싱하여 데이터 소스로 추가되도록 자동으로 설치 및 프로비저닝되므로pcp
쿼리 언어를 사용하여 데이터의 복잡한 쿼리에 사용할 수 있습니다.metrics_manage_firewall
및metrics_manage_selinux
가 모두true
로 설정되므로지표
역할은firewall
및selinux
역할을 사용하여metrics
역할에서 사용하는 포트를 관리합니다.-
시스템에서 중앙에서 수집되는 지표의 그래픽 표현을 보고 데이터를 쿼리하려면 Grafana 웹 UI 액세스에 설명된 대로
grafana
웹 인터페이스에 액세스 합니다.
22.5. 메트릭
시스템 역할을 사용하여 시스템을 모니터링하는 동안 인증 설정
PCP는 SASL(Simple Authentication Security Layer) 프레임워크를 통해 scram-sha-256
인증 메커니즘을 지원합니다. 지표
RHEL 시스템 역할은 scram-sha-256
인증 메커니즘을 사용하여 인증을 설정하는 단계를 자동화합니다. 다음 절차에서는 메트릭
RHEL 시스템 역할을 사용하여 인증을 설정하는 방법을 설명합니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
플레이북을 실행하는 데 사용할 머신에
rhel-system-roles
패키지가 설치되어 있습니다.
절차
인증을 설정하려는 Ansible 플레이북에 다음 변수를 포함합니다.
--- vars: metrics_username: your_username metrics_password: your_password metrics_manage_firewall: true metrics_manage_selinux: true
참고metrics_manage_firewall
및metrics_manage_selinux
가 모두true
로 설정되므로지표
역할은firewall
및selinux
역할을 사용하여metrics
역할에서 사용하는 포트를 관리합니다.Ansible Playbook을 실행합니다.
# ansible-playbook name_of_your_playbook.yml
검증 단계
sasl
구성을 확인합니다.# pminfo -f -h "pcp://ip_adress?username=your_username" disk.dev.read Password: disk.dev.read inst [0 or "sda"] value 19540
ip_adress 는 호스트의 IP 주소로 교체해야합니다.
22.6. 시스템 역할에 대한 메트릭
을 사용하여 SQL Server에 대한 메트릭 수집 구성 및 활성화
다음 절차에서는 메트릭
RHEL 시스템 역할을 사용하여 로컬 시스템의 pcp
를 통해 Microsoft SQL Server에 대한 구성 및 메트릭 수집 활성화를 자동화하는 방법을 설명합니다.
사전 요구 사항
- Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
모니터링하려는 머신에
rhel-system-roles
패키지가 설치되어 있습니다. - Red Hat Enterprise Linux용 Microsoft SQL Server를 설치하고 SQL 서버에 '신뢰할 수 있는' 연결을 설정했습니다. Install SQL Server and create a database on Red Hat 에서 참조하십시오.
- Red Hat Enterprise Linux용 SQL Server용 Microsoft>-< 드라이버를 설치했습니다. Red Hat Enterprise Server 및 Oracle Linux 를 참조하십시오.
절차
인벤토리에 다음 콘텐츠를 추가하여
/etc/ansible/hosts
Ansible 인벤토리에서localhost
를 구성합니다.localhost ansible_connection=local
다음 콘텐츠가 포함된 Ansible 플레이북을 생성합니다.
--- - hosts: localhost vars: metrics_from_mssql: true metrics_manage_firewall: true metrics_manage_selinux: true roles: - role: rhel-system-roles.metrics
참고metrics_manage_firewall
및metrics_manage_selinux
가 모두true
로 설정되므로지표
역할은firewall
및selinux
역할을 사용하여metrics
역할에서 사용하는 포트를 관리합니다.Ansible Playbook을 실행합니다.
# ansible-playbook name_of_your_playbook.yml
검증 단계
pcp
명령을 사용하여 SQL Server PMDA 에이전트(mssql)가 로드되고 실행 중인지 확인합니다.Use the pcp command to verify that SQL Server PMDA agent (mssql) is loaded and running:# pcp platform: Linux rhel82-2.local 4.18.0-167.el8.x86_64 #1 SMP Sun Dec 15 01:24:23 UTC 2019 x86_64 hardware: 2 cpus, 1 disk, 1 node, 2770MB RAM timezone: PDT+7 services: pmcd pmproxy pmcd: Version 5.0.2-1, 12 agents, 4 clients pmda: root pmcd proc pmproxy xfs linux nfsclient mmv kvm mssql jbd2 dm pmlogger: primary logger: /var/log/pcp/pmlogger/rhel82-2.local/20200326.16.31 pmie: primary engine: /var/log/pcp/pmie/rhel82-2.local/pmie.log
23장. windows .sql.server Ansible 역할을
사용하여 Microsoft SQL Server 구성
관리자는ECDHE .sql.server
Ansible 역할을 사용하여 Microsoft SQL Server (SQL Server)를 설치, 구성 및 시작할 수 있습니다. 10.0.0.1 .sql.server
Ansible 역할은 운영 체제를 최적화하여 SQL Server의 성능과 처리량을 향상시킵니다. 이 역할은 SQL Server 워크로드를 실행하기 위한 권장 설정으로 RHEL 호스트의 구성을 단순화하고 자동화합니다.
23.1. 사전 요구 사항
- 2GB의 RAM
-
SQL ServerSQL Server를 구성하려는 관리 노드에 대한
루트
액세스 사전 구성된 방화벽
역할이 방화벽을 자동으로 관리할 수 있도록
mssql_manage_firewall
변수를true
로 설정할 수 있습니다.또는
mssql_tcp_port
변수로 설정된 SQL Server TCP 포트에서 연결을 활성화합니다. 이 변수를 정의하지 않으면 역할의 기본값은 TCP 포트 번호1443
입니다.새 포트를 추가하려면 다음을 사용합니다.
# firewall-cmd --add-port=xxxx/tcp --permanent # firewall-cmd --reload
xxxx 를 TCP 포트 번호로 교체한 다음 방화벽 규칙을 다시 로드합니다.
-
선택 사항: SQL 문 및 프로시저를 포함하는
.sql
확장자를 사용하여 파일을 SQL Server에 입력합니다.
23.2. skopeo .sql.server
Ansible 역할 설치
10.0.0.1 .sql.server
Ansible 역할은 ansible-collection-microsoft-sql
패키지의 일부입니다.
사전 요구 사항
-
루트
액세스
절차
RHEL 8 AppStream 리포지토리에서 사용할 수 있는 Ansible Core를 설치합니다.
# yum install ansible-core
skopeo
.sql.server
Ansible 역할을 설치합니다.# yum install ansible-collection-microsoft-sql
23.3. 기존 인증서 파일과 함께 Cryostat .sql.server
Ansible 역할을 사용하여 SQL Server 설치 및 구성
Cryostat .sql.server
Ansible 역할을 사용하여 SQL Server 버전 2019를 설치하고 구성할 수 있습니다. 이 예제의 플레이북은 TLS 암호화를 위해 기존 sql_cert
인증서 및 개인 키 파일을 사용하도록 서버를 구성합니다.
사전 요구 사항
- 인벤토리 파일이 제어 노드에 있습니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - name: Install and configure SQL Server hosts: all roles: - microsoft.sql.server vars: mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true mssql_accept_microsoft_sql_server_standard_eula: true mssql_version: 2019 mssql_manage_firewall: true mssql_tls_enable: true mssql_tls_cert: sql_crt.pem mssql_tls_private_key: sql_cert.key mssql_tls_version: 1.2 mssql_tls_force: false mssql_password: <password> mssql_edition: Developer mssql_tcp_port: 1443
< ;password& gt;를 SQL Server 암호로 바꿉니다.
인벤토리에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
23.4. 인증서
역할과 함께 Cryostat .sql.server
Ansible 역할을 사용하여 SQL 서버 설치 및 구성
Cryostat .sql.server
Ansible 역할을 사용하여 SQL Server 버전 2019를 설치하고 구성할 수 있습니다. 이 예제의 플레이북은 TLS 암호화를 사용하도록 서버를 구성하고 인증서 시스템 역할을 사용하여 자체 서명된 sql_cert
인증서 파일 및 개인 키를 만듭니다.
인증서를 생성하기 위해 플레이북에서 인증서
시스템 역할을 호출할 필요가 없습니다. Cryo stat.sql.server
Ansible 역할은 이를 자동으로 호출합니다.
CA에서 생성된 인증서에 서명하려면 관리형 노드를 IdM 도메인에 등록해야 합니다.
사전 요구 사항
- 인벤토리 파일이 제어 노드에 있습니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - name: Install and configure SQL Server hosts: all roles: - microsoft.sql.server vars: mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true mssql_accept_microsoft_sql_server_standard_eula: true mssql_version: 2019 mssql_manage_firewall: true mssql_tls_enable: true mssql_tls_certificates: - name: sql_cert dns: *.example.com ca: self-sign mssql_password: <password> mssql_edition: Developer mssql_tcp_port: 1443
< ;password& gt;를 SQL Server 암호로 바꿉니다.
인벤토리에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
추가 리소스
23.5. TLS 변수
다음 변수를 사용하여 TLS(Transport Level Security) 프로토콜을 구성할 수 있습니다.
표 23.1. TLS 역할 변수
역할 변수 | 설명 |
---|---|
mssql_version | 설치할 SQL Server 버전을 정의합니다. 가능한 값은 2017년 및 2022년입니다. |
mssql_tls_enable | 이 변수는 TLS 암호화를 활성화하거나 비활성화합니다.
변수
|
mssql_tls_certificates |
인증서 역할을 사용하여 TLS 암호화를 위한 중요
이 변수를 설정할 때 |
mssql_tls_cert | 지정된 경로에서 SQL ServerSQL Server로 인증서 파일을 복사하고 TLS 암호화에 사용합니다.Copies a certificate file from the specified path to SQL ServerSQL Server and uses it for TLS encryption. |
mssql_tls_private_key | 지정된 경로에서 SQL ServerSQL Server 로 개인 키 파일을 복사하고 TLS 암호화에 사용합니다.Copies a private key file from the specified path to SQL ServerSQL Server and uses it for TLS encryption. |
mssql_tls_remote_src |
역할이 mssql_tls_
기본
|
mssql_tls_version | 사용할 TLS 버전을 정의합니다.
기본값은 |
mssql_tls_force |
기본값은 |
23.6. MLServices 승인
필요한 SQL Server Machine Learning Services (MLServices)를 설치하려면 Python 및 R 패키지의 오픈 소스 배포를 위해 모든 ScanSetting을 수락해야합니다.
라이센스 용어는 /usr/share/doc/mssql-server
를 참조하십시오.
표 23.2. SQL Server Machine Learning Services ScanSetting 변수
역할 변수 | 설명 |
---|---|
mssql_accept_microsoft_sql_server_standard_eula |
이 변수는
약관을 수락하려면 이 변수를
기본값은 |
23.7. Microsoft>-< 17에 대한 dotnets 수락
Microsoft ODBC(Open Database Connectivity) 드라이버를 설치하려면 모든 dotnets를 수락해야 합니다.
라이센스 용어는 /usr/share/doc/msodbcsql17/LICENSE.txt
및 /usr/share/doc/mssql-tools/LICENSE.txt
를 참조하십시오.
표 23.3. Microsoft ScanSetting 17 ScanSetting 변수
역할 변수 | 설명 |
---|---|
mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula |
이 변수는
약관을 수락하려면 이 변수를
기본값은 |
mssql_accept_microsoft_cli_utilities_for_sql_server_eula |
이 변수는
약관을 수락하려면 이 변수를
기본값은 |
23.8. 고가용성 변수
아래 표의 변수를 사용하여 Microsoft SQL Server의 고가용성을 구성할 수 있습니다.
표 23.4. 고가용성 구성 변수
Variable | 설명 |
---|---|
|
기본값은
|
|
이 변수는 호스트에서 구성할 수 있는 복제본 유형을 지정합니다. 이 변수를 |
|
기본 포트는 이 역할은 이 TCP 포트를 사용하여 Always On 가용성 그룹의 데이터를 복제합니다. |
| Always On 가용성 그룹의 멤버 간 트랜잭션을 보호하려면 인증서 이름을 정의해야 합니다.You must define the name of the certificate to secure transactions between members of an Always On availability group. |
| 인증서와 함께 사용할 마스터 키의 암호를 설정해야 합니다. |
| 인증서에 사용할 개인 키의 암호를 설정해야 합니다. |
|
기본값은
|
| 구성할 끝점의 이름을 정의해야 합니다. |
| 구성할 가용성 그룹의 이름을 정의해야 합니다. |
| 복제할 데이터베이스 목록을 정의할 수 있습니다. 그러지 않으면 역할이 데이터베이스를 복제하지 않고 클러스터를 생성할 수 있습니다. |
| SQL Server Pacemaker 리소스 에이전트는 이 사용자를 사용하여 데이터베이스 상태 검사를 수행하고 복제본에서 주 서버로의 상태 전환을 관리합니다. |
|
SQL ServerSQL Server의 |
|
기본값은
이 변수는 이 역할이
이 제한을 해결하기 위해 CloudEvent
>-< |
이 역할은 데이터베이스를 /var/opt/mssql/data/
디렉터리에 백업합니다.
Microsoft SQL Server에 대해 고가용성 변수를 사용하는 방법에 대한 예제가 있습니다.
-
Automation Hub에서 역할을 설치하는 경우 서버의
~/.ansible/collections/ansible_collections/microsoft/sql/roles/server/README.md
파일을 참조하십시오. -
패키지에서 역할을 설치하는 경우 브라우저에서
/usr/share/microsoft/sql-server/README.html
파일을 엽니다.
24장. tlog
RHEL 시스템 역할을 사용하여 세션 레코딩을 위한 시스템 구성
tlog
RHEL 시스템 역할을 사용하면 Red Hat Ansible Automation Platform을 사용하여 RHEL에서 터미널 세션 레코딩을 위해 시스템을 구성할 수 있습니다.
24.1. tlog
시스템 역할
tlog
RHEL 시스템 역할을 사용하여 RHEL에서 터미널 세션 레코딩을 위해 RHEL 시스템을 구성할 수 있습니다.
SSSD
서비스를 통해 사용자 또는 사용자 그룹별로 수행되도록 레코딩을 구성할 수 있습니다.
추가 리소스
- RHEL의 세션 기록에 대한 자세한 내용은 세션 레코딩 을 참조하십시오.
24.2. tlog
시스템 역할의 구성 요소 및 매개변수
세션 레코딩 솔루션에는 다음과 같은 구성 요소가 있습니다.
-
tlog
유틸리티 - SSSD(System Security Services Daemon)
- 선택 사항: 웹 콘솔 인터페이스
tlog
RHEL 시스템 역할에 사용되는 매개변수는 다음과 같습니다.
역할 변수 | 설명 |
---|---|
tlog_use_sssd (기본값: yes) | 기록된 사용자 또는 그룹을 관리하는 기본 방법인 SSSD를 사용하여 세션 레코딩 구성 |
tlog_scope_sssd (기본값: none) | SSSD 레코딩 범위 구성 - all / some / none |
tlog_users_sssd (기본값: []) | 기록될 YAML 사용자 목록 |
tlog_groups_sssd (기본값: []) | 기록할 그룹의 YAML 목록 |
-
tlog에 사용된 매개변수 및
tlog
/usr/share/ansible/roles/rhel-system-roles.tlog/README.md
파일을 참조하십시오.
24.3. tlog
RHEL 시스템 역할 배포
다음 단계에 따라 세션 레코딩 데이터를 systemd 저널에 기록하도록 RHEL 시스템을 구성하기 위해 Ansible 플레이북을 준비하고 적용합니다.
사전 요구 사항
-
제어 노드에서
tlog
시스템 역할이 구성될 대상 시스템으로 액세스하기 위한 SSH 키를 설정해야 합니다. -
tlog
시스템 역할을 구성하려는 시스템이 하나 이상 있습니다. - Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
rhel-system-roles
패키지는 제어 시스템에 설치됩니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - name: Deploy session recording hosts: all vars: tlog_scope_sssd: some tlog_users_sssd: - recorded-user roles: - rhel-system-roles.tlog
여기서,
tlog_scope_sssd
:-
some
은 일부 또는none
이 아닌 특정 사용자 및 그룹만 기록할 것을 지정합니다.
-
tlog_users_sssd
:-
recorded-user
는 세션을 기록할 사용자를 지정합니다. 이 경우 사용자가 추가되지 않습니다. 사용자가 직접 설정해야합니다.
-
필요한 경우 플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i IP_Address /path/to/file/playbook.yml -v
결과적으로 Playbook은 사용자가 지정한 시스템에 tlog
RHEL 시스템 역할을 설치합니다. 역할에는 tlog-rec-session
, 사용자의 로그인 쉘 역할을 하는 터미널 세션 I/O 로깅 프로그램이 포함됩니다. 또한 사용자가 정의한 사용자 및 그룹에서 사용할 수 있는 SSSD 구성 드롭 파일을 생성합니다. SSSD는 이러한 사용자와 그룹을 구문 분석 및 읽고 사용자 쉘을 tlog-rec-session
으로 교체합니다. 또한 cockpit
패키지가 시스템에 설치된 경우 플레이북은 웹 콘솔 인터페이스에서 레코딩을 보고 재생할 수 있는 Cockpit
모듈인 cockpit-session-recording
패키지도 설치합니다.
검증 단계
SSSD 구성 드롭 파일이 시스템에 생성되었는지 확인하려면 다음 단계를 수행합니다.
SSSD 구성 드롭 파일이 생성되는 폴더로 이동합니다.
# cd /etc/sssd/conf.d
파일 내용을 확인합니다.
# cat /etc/sssd/conf.d/sssd-session-recording.conf
파일에 플레이북에서 설정한 매개변수가 포함되어 있음을 확인할 수 있습니다.
24.4. 그룹 또는 사용자 목록 제외에 대한 tlog
RHEL 시스템 역할 배포
tlog
시스템 역할을 사용하여 exclude_users
및 exclude_groups
의 SSSD 세션 레코딩 구성 옵션을 지원할 수 있습니다. 다음 단계에 따라 사용자 또는 그룹이 systemd 저널에 기록되고 로그인되어 있지 않도록 RHEL 시스템을 구성하도록 Ansible 플레이북을 준비하고 적용합니다.
사전 요구 사항
-
제어 노드에서
tlog
시스템 역할을 구성하려는 대상 시스템으로 액세스하기 위한 SSH 키를 설정해야 합니다. -
tlog
시스템 역할을 구성하려는 시스템이 하나 이상 있습니다. - Ansible Core 패키지는 컨트롤 시스템에 설치되어 있어야 합니다.
-
rhel-system-roles
패키지는 제어 시스템에 설치됩니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - name: Deploy session recording excluding users and groups hosts: all vars: tlog_scope_sssd: all tlog_exclude_users_sssd: - jeff - james tlog_exclude_groups_sssd: - admins roles: - rhel-system-roles.tlog
여기서,
tlog_scope_sssd
:-
all
: 모든 사용자 및 그룹을 기록할 것을 지정합니다.
-
tlog_exclude_users_sssd
:- 사용자 이름: 세션 레코딩에서 제외하려는 사용자의 사용자 이름을 지정합니다.
tlog_exclude_groups_sssd
:-
admins
는 세션 레코딩에서 제외할 그룹을 지정합니다.
-
선택적으로 플레이북 구문을 확인합니다.
# ansible-playbook --syntax-check playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i IP_Address /path/to/file/playbook.yml -v
결과적으로 Playbook은 사용자가 지정한 시스템에 tlog
RHEL 시스템 역할을 설치합니다. 역할에는 tlog-rec-session
, 사용자의 로그인 쉘 역할을 하는 터미널 세션 I/O 로깅 프로그램이 포함됩니다. 또한 /etc/sssd/conf.d/sssd-session-recording.conf
SSSD 설정 드롭 파일을 생성합니다. 이 구성 드롭 파일은 사용자 및 그룹에서 제외된 것으로 정의한 경우를 제외하고 사용자와 그룹에서 사용할 수 있습니다. SSSD는 이러한 사용자와 그룹을 구문 분석 및 읽고 사용자 쉘을 tlog-rec-session
으로 교체합니다. 또한 cockpit
패키지가 시스템에 설치된 경우 플레이북은 웹 콘솔 인터페이스에서 레코딩을 보고 재생할 수 있는 Cockpit
모듈인 cockpit-session-recording
패키지도 설치합니다.
검증 단계
SSSD 구성 드롭 파일이 시스템에 생성되었는지 확인하려면 다음 단계를 수행합니다.
SSSD 구성 드롭 파일이 생성되는 폴더로 이동합니다.
# cd /etc/sssd/conf.d
파일 내용을 확인합니다.
# cat sssd-session-recording.conf
파일에 플레이북에서 설정한 매개변수가 포함되어 있음을 확인할 수 있습니다.
추가 리소스
-
/usr/share/doc/rhel-system-roles/tlog/
및/usr/share/ansible/roles/rhel-system-roles.tlog/
디렉터리를 참조하십시오. - CLI에서 배포된 터미널 세션 기록 시스템 역할을 사용하여 세션을 기록합니다.
24.5. CLI에서 배포된 tlog
시스템 역할을 사용하여 세션 기록
지정한 시스템에 tlog
시스템 역할을 배포한 후 CLI(명령줄 인터페이스)를 사용하여 사용자 터미널 세션을 기록할 수 있습니다.
사전 요구 사항
-
tlog
시스템 역할을 대상 시스템에 배포했습니다. -
SSSD 구성 드롭 파일은
/etc/sssd/conf.d
디렉터리에 생성되었습니다. RHEL 시스템 역할 기록에 대한 터미널 세션 등록을 참조하십시오.
절차
사용자를 생성하고 이 사용자의 암호를 할당합니다.
# useradd recorded-user # passwd recorded-user
방금 만든 사용자로 시스템에 로그인합니다.
# ssh recorded-user@localhost
- 시스템에서 인증할 yes 또는 no를 입력하라는 메시지가 표시되면 "yes"를 입력합니다.
recorded-user의 암호를 삽입합니다.
시스템은 기록 중인 세션에 대한 메시지를 표시합니다.
ATTENTION! Your session is being recorded!
세션 녹화를 완료한 후 다음을 입력합니다.
# exit
시스템은 사용자가 로그아웃하고 localhost와의 연결을 종료합니다.
그 결과 사용자 세션이 기록되고 저장되고 저널을 사용하여 플레이할 수 있습니다.
검증 단계
저널에 기록된 세션을 보려면 다음 단계를 수행하십시오.
아래 명령을 실행하십시오.
# journalctl -o verbose -r
tlog-rec
기록 저널 항목의MESSAGE
필드를 검색합니다.# journalctl -xel _EXE=/usr/bin/tlog-rec-session
24.6. CLI를 사용하여 기록된 세션 감시
CLI(명령줄 인터페이스)를 사용하여 저널에서 사용자 세션 레코딩을 플레이할 수 있습니다.
사전 요구 사항
- 사용자 세션을 기록했습니다. CLI에서 배포된 tlog 시스템 역할을 사용하여 세션 기록을 참조하십시오.
절차
CLI 터미널에서 사용자 세션 레코딩을 재생합니다.
# journalctl -o verbose -r
tlog
레코딩을 검색합니다.$ /tlog-rec
다음과 같은 세부 정보를 볼 수 있습니다.
- 사용자 세션 레코딩의 사용자 이름
-
기록된 세션의 원시 출력 인코딩인
out_txt
필드 - 식별자 번호 TLOG_REC=ID_number
- 식별자 번호 TLOG_REC=ID_number 를 복사합니다.
식별자 번호 TLOG_REC=ID_number 를 사용하여 레코딩을 재생합니다.
# tlog-play -r journal -M TLOG_REC=ID_number
그 결과 사용자 세션 레코딩 터미널 출력이 다시 재생되는 것을 확인할 수 있습니다.
25장. ha_cluster RHEL 시스템 역할을 사용하여 고가용성 클러스터 구성
ha_cluster
시스템 역할을 사용하면 Pacemaker 고가용성 클러스터 리소스 관리자를 사용하는 고가용성 클러스터를 구성하고 관리할 수 있습니다.
25.1. ha_cluster
시스템 역할 변수
ha_cluster
시스템 역할 플레이북에서는 클러스터 배포 요구 사항에 따라 고가용성 클러스터에 대한 변수를 정의합니다.
ha_cluster
시스템 역할에 설정할 수 있는 변수는 다음과 같습니다.
ha_cluster_enable_repos
-
ha_cluster
시스템 역할에 필요한 패키지가 포함된 리포지토리를 활성화하는 부울 플래그입니다. 이 변수가true
로 설정된 경우 기본값인 RHEL 및 RHEL High Availability Add-On에 대해 클러스터 구성원 또는 System Role으로 사용할 시스템에 대해 유효한 서브스크립션 옵션이 제공됩니다. ha_cluster_manage_firewall
(RHEL 8.8 이상)
ha_cluster
시스템 역할이 방화벽을 관리하는지 여부를 결정하는 부울 플래그입니다.ha_cluster_manage_firewall
이true
로 설정되면 방화벽 고가용성 서비스와fence-virt
포트가 활성화됩니다.ha_cluster_manage_firewall
이false
로 설정되면ha_cluster
시스템 역할이 방화벽을 관리하지 않습니다. 시스템이firewalld
서비스를 실행하는 경우 플레이북에서 매개 변수를true
로 설정해야 합니다.ha_cluster_manage_firewall
매개변수를 사용하여 포트를 추가할 수 있지만 매개변수를 사용하여 포트를 제거할 수는 없습니다. 포트를 제거하려면방화벽
시스템 역할을 직접 사용합니다.RHEL 8.8부터는
ha_cluster_manage_firewall
이true
로 설정된 경우에만 방화벽이 기본적으로 구성되지 않습니다.ha_cluster_manage_selinux
(RHEL 8.8 이상)
ha_cluster
시스템 역할이selinux
시스템 역할을 사용하여 방화벽 고가용성 서비스에 속하는 포트를 관리하는지 여부를 결정하는 부울 플래그입니다.ha_cluster_manage_selinux
가true
로 설정된 경우 방화벽 고가용성 서비스에 속하는 포트는 SELinux 포트 유형cluster_port_t
와 연결됩니다.ha_cluster_manage_selinux
가false
로 설정된 경우ha_cluster
시스템 역할은 SELinux를 관리하지 않습니다.시스템에서
selinux
서비스를 실행하는 경우 플레이북에서 이 매개변수를true
로 설정해야 합니다. 방화벽 구성은 SELinux 관리를 위한 사전 요구 사항입니다. 방화벽이 설치되지 않은 경우 SELinux 관리 정책을 건너뜁니다.ha_cluster_manage_selinux
매개변수를 사용하여 정책을 추가할 수 있지만 매개변수를 사용하여 정책을 제거할 수는 없습니다. 정책을 제거하려면selinux
시스템 역할을 직접 사용합니다.ha_cluster_cluster_present
true
로 설정된 경우 역할에 전달된 변수에 따라 호스트에 HA 클러스터가 구성되도록 결정하는 부울 플래그입니다. 역할에 지정되지 않았으며 역할에 지원되지 않는 클러스터 구성이 손실됩니다.ha_cluster_cluster_present
가false
로 설정되면 모든 HA 클러스터 구성이 대상 호스트에서 제거됩니다.이 변수의 기본값은
true
입니다.다음 예제 Playbook은
node1
및node2
에서 모든 클러스터 구성을 제거합니다.- hosts: node1 node2 vars: ha_cluster_cluster_present: false roles: - rhel-system-roles.ha_cluster
ha_cluster_start_on_boot
-
부팅 시 클러스터 서비스를 시작하도록 구성할지 여부를 결정하는 부울 플래그입니다. 이 변수의 기본값은
true
입니다. ha_cluster_fence_agent_packages
-
설치할 fence 에이전트 패키지 목록입니다. 이 변수의 기본값은
fence-agents-all
,fence-virt
입니다. ha_cluster_extra_packages
설치할 추가 패키지 목록입니다. 이 변수의 기본값은 패키지가 없습니다.
이 변수는 역할에 의해 자동으로 설치되지 않은 추가 패키지(예: 사용자 정의 리소스 에이전트)를 설치하는 데 사용할 수 있습니다.
fence 에이전트를 이 목록의 멤버로 지정할 수 있습니다. 그러나
ha_cluster_fence_agent_packages
는 기본값을 덮어쓰도록 펜싱 에이전트를 지정하는 데 사용하는 권장 역할 변수입니다.ha_cluster_hacluster_password
-
hacluster
사용자의 암호를 지정하는 문자열 값입니다.hacluster
사용자는 클러스터에 대한 전체 액세스 권한을 갖습니다. Ansible Vault를 사용하여 콘텐츠 암호화에 설명된 대로 자격 증명 모음에서 암호를 암호화하는 것이 좋습니다. 기본 암호 값은 없으며 이 변수를 지정해야 합니다. ha_cluster_corosync_key_src
Corosync
authkey
파일의 경로입니다. 이는 Corosync 통신의 인증 및 암호화 키입니다. 각 클러스터에 대해 고유한authkey
값이 있는 것이 좋습니다. 키는 임의 데이터의 256바이트여야 합니다.이 변수의 키를 지정하는 경우 Ansible Vault로 콘텐츠 암호화에 설명된 대로 자격 증명 모음에서 키를 암호화하는 것이 좋습니다.
키가 지정되지 않은 경우 노드에 이미 존재하는 키가 사용됩니다. 노드에 동일한 키가 없는 경우 한 노드의 키가 다른 노드에 배포되므로 모든 노드에 동일한 키가 있습니다. 노드에 키가 없으면 새 키가 생성되어 노드에 배포됩니다.
이 변수가 설정되면 이 키로
ha_cluster_regenerate_keys
가 무시됩니다.이 변수의 기본값은 null입니다.
ha_cluster_pacemaker_key_src
Pacemaker 통신의 인증 및 암호화 키인 Pacemaker
authkey
파일의 경로입니다. 각 클러스터에 대해 고유한authkey
값이 있는 것이 좋습니다. 키는 임의 데이터의 256바이트여야 합니다.이 변수의 키를 지정하는 경우 Ansible Vault로 콘텐츠 암호화에 설명된 대로 자격 증명 모음에서 키를 암호화하는 것이 좋습니다.
키가 지정되지 않은 경우 노드에 이미 존재하는 키가 사용됩니다. 노드에 동일한 키가 없는 경우 한 노드의 키가 다른 노드에 배포되므로 모든 노드에 동일한 키가 있습니다. 노드에 키가 없으면 새 키가 생성되어 노드에 배포됩니다.
이 변수가 설정되면 이 키로
ha_cluster_regenerate_keys
가 무시됩니다.이 변수의 기본값은 null입니다.
ha_cluster_fence_virt_key_src
fence-virt
또는fence-xvm
차단 에이전트의 인증 키 위치인fence-virt
또는fence-xvm
사전 공유 키 파일의 경로입니다.이 변수의 키를 지정하는 경우 Ansible Vault로 콘텐츠 암호화에 설명된 대로 자격 증명 모음에서 키를 암호화하는 것이 좋습니다.
키가 지정되지 않은 경우 노드에 이미 존재하는 키가 사용됩니다. 노드에 동일한 키가 없는 경우 한 노드의 키가 다른 노드에 배포되므로 모든 노드에 동일한 키가 있습니다. 노드에 키가 없으면 새 키가 생성되어 노드에 배포됩니다.
ha_cluster
시스템 역할이 이러한 방식으로 새 키를 생성하는 경우 펜싱이 작동하는지 확인하기 위해 키를 노드의 하이퍼바이저에 복사해야 합니다.이 변수가 설정되면 이 키로
ha_cluster_regenerate_keys
가 무시됩니다.이 변수의 기본값은 null입니다.
ha_cluster_pcsd_public_key_srcr
,ha_cluster_pcsd_private_key_src
pcsd
TLS 인증서 및 개인 키 경로입니다. 이 값을 지정하지 않으면 노드에 이미 존재하는 인증서-키 쌍이 사용됩니다. 인증서-키 쌍이 없으면 임의의 새 쌍이 생성됩니다.이 변수에 대한 개인 키 값을 지정하는 경우 Ansible Vault로 콘텐츠 암호화에 설명된 대로 자격 증명 모음 암호화 키를 암호화하는 것이 좋습니다.
이러한 변수가 설정되면 이 인증서-키 쌍에 대해
ha_cluster_regenerate_keys
가 무시됩니다.이러한 변수의 기본값은 null입니다.
ha_cluster_pcsd_certificates
(RHEL 8.8 이상) 인증서 시스템 역할을 사용하여
pcsd
개인 키 및인증서를
생성합니다.시스템이
pcsd
개인 키와 인증서로 구성되지 않은 경우 다음 두 가지 방법 중 하나로 생성할 수 있습니다.-
ha_cluster_pcsd_certificates
변수를 설정합니다.ha_cluster_pcsd_certificates
변수를 설정하면인증서
시스템 역할이 내부적으로 사용되며 정의된pcsd
에 대한 개인 키와 인증서를 생성합니다. -
ha_cluster_pcsd_public_key_src
,ha_cluster_pcsd_key_src , 또는
변수를 설정하지 마십시오. 이러한 변수를 설정하지 않으면ha_
cluster_pcsd_certificatesha_cluster
시스템 역할은pcsd
자체를 통해pcsd
인증서를 생성합니다.ha_cluster_pcsd_
값은 인증서 시스템 역할에 지정된 대로certificate
scertificate_requests
변수 값으로 설정됩니다.인증서
시스템 역할에 대한 자세한 내용은 RHEL 시스템 역할을 사용하여 인증서 요청 을 참조하십시오.
-
다음 운영 고려 사항은
ha_cluster_pcsd_certificate
변수 사용에 적용됩니다.-
IPA를 사용하고 시스템을 IPA 도메인에 가입하지 않는 한, 시스템 역할은 자체 서명된 인증서를 생성합니다.
이 경우 RHEL 시스템 역할 외부에서 신뢰 설정을 명시적으로 구성해야 합니다. 시스템 역할은 신뢰 설정 구성을 지원하지 않습니다.
-
ha_cluster_pcsd_certificates
변수를 설정하는 경우ha_cluster_pcsd_public_key_src
및ha_cluster_pcsd_private_key_src
변수를 설정하지 마십시오. -
ha_cluster_pcsd_certificates
변수를 설정하면 이 인증서 - 키 쌍에 대해ha_cluster_regenerate_keys
가 무시됩니다.
-
IPA를 사용하고 시스템을 IPA 도메인에 가입하지 않는 한, 시스템 역할은 자체 서명된 인증서를 생성합니다.
이 변수의 기본값은
[]
입니다.고가용성 클러스터에서 TLS 인증서 및 키 파일을 생성하는
ha_cluster
시스템 역할 플레이북의 예는 고가용성 클러스터에 대한 pcsd TLS 인증서 및 키 파일 생성을 참조하십시오.ha_cluster_regenerate_keys
-
true
로 설정하면 사전 공유 키와 TLS 인증서가 다시 생성되도록 결정하는 부울 플래그입니다. 키 및 인증서가 다시 생성되는 경우ha_cluster_corosync_key_src
,ha_cluster_pacemaker_key_src
,ha_cluster_fence_key
변수에 대한 설명을 참조하십시오._src
, ha_cluster_pcsd_public
_key_src -
이 변수의 기본값은
false
입니다. ha_cluster_pcs_permission_list
pcsd
를 사용하여 클러스터를 관리하도록 권한을 설정합니다. 이 변수를 사용하여 구성하는 항목은 다음과 같습니다.-
유형
-사용자
또는그룹
-
이름
- 사용자 또는 그룹 이름 allow_list
- 지정된 사용자 또는 그룹에 대해 허용된 작업:-
read
- 클러스터 상태 및 설정 보기 -
write
- 권한 및 ACL을 제외한 클러스터 설정 수정 -
grant
- 클러스터 권한 및 ACL 수정 -
Full
- 노드 추가 및 제거 및 키 및 인증서에 대한 액세스 제한 없이 클러스터에 액세스
-
-
ha_cluster_pcs_permission_list
변수의 구조와 기본값은 다음과 같습니다.ha_cluster_pcs_permission_list: - type: group name: hacluster allow_list: - grant - read - write
ha_cluster_cluster_name
-
클러스터의 이름입니다. 이는 기본값이
my-cluster
인 문자열 값입니다. ha_cluster_transport
(RHEL 8.7 이상) 클러스터 전송 방법을 설정합니다. 이 변수를 사용하여 구성하는 항목은 다음과 같습니다.
-
유형
(선택 사항) - 전송 유형:knet
,udp
, 또는udpu
.udp
및udpu
전송 유형은 하나의 링크만 지원합니다.udp
및udpu
에 대해 암호화가 항상 비활성화되어 있습니다. 지정하지 않는 경우 기본값은knet
입니다. -
options
(선택 사항) - 전송 옵션을 사용하는 이름-값 사전 목록입니다. -
링크
(선택 사항) - 이름-값 사전 목록. 이름-값 사전의 각 목록에는 하나의 Corosync 링크에 대한 옵션이 있습니다. 각 링크에 대한linknumber
값을 설정하는 것이 좋습니다. 그렇지 않으면 첫 번째 사전 목록이 첫 번째 링크, 두 번째 링크에 기본적으로 할당되며, 두 번째 사전 목록은 기본적으로 두 번째 링크에 할당됩니다. -
압축
(선택 사항) - 전송 압축을 구성하는 이름-값 사전 목록입니다.knet
전송 유형에서만 지원됩니다. crypto
(선택 사항) - 전송 암호화를 구성하는 이름-값 사전 목록입니다. 기본적으로 암호화가 활성화됩니다.knet
전송 유형에서만 지원됩니다.허용되는 옵션 목록은
pcs -h 클러스터 설정
도움말 페이지 또는pcs
ECDHE man 페이지의cluster
섹션에 있는설정
설명을 참조하십시오. 자세한 내용은corosync.conf
(5) 매뉴얼 페이지를 참조하십시오.ha_cluster_transport
변수의 구조는 다음과 같습니다.ha_cluster_transport: type: knet options: - name: option1_name value: option1_value - name: option2_name value: option2_value links: - - name: option1_name value: option1_value - name: option2_name value: option2_value - - name: option1_name value: option1_value - name: option2_name value: option2_value compression: - name: option1_name value: option1_value - name: option2_name value: option2_value crypto: - name: option1_name value: option1_value - name: option2_name value: option2_value
전송 방법을 구성하는
ha_cluster
시스템 역할 플레이북의 예는 고가용성 클러스터에서 Corosync 값 구성을 참조하십시오.
-
ha_cluster_totem
(RHEL 8.7 이상)은 Corosync totem을 구성합니다. 허용되는 옵션 목록은
pcs -h 클러스터 설정
도움말 페이지 또는pcs
ECDHE man 페이지의cluster
섹션에 있는설정
설명을 참조하십시오. 자세한 내용은corosync.conf
(5) 매뉴얼 페이지를 참조하십시오.ha_cluster_totem
변수의 구조는 다음과 같습니다.ha_cluster_totem: options: - name: option1_name value: option1_value - name: option2_name value: option2_value
Corosync totem을 구성하는
ha_cluster
시스템 역할 플레이북의 예는 고가용성 클러스터에서 Corosync 값 구성을 참조하십시오.ha_cluster_quorum
(RHEL 8.7 이상) 클러스터 쿼럼을 구성합니다. 클러스터 쿼럼에 대해 다음 항목을 구성할 수 있습니다.
-
options
(선택 사항) - 쿼럼을 구성하는 이름-값 사전 목록입니다. 허용되는 옵션은auto_tie_breaker
,last_man_
kind ,last_man_window
,wait_for_all
입니다. 쿼럼 옵션에 대한 자세한 내용은votequorum
(5) 매뉴얼 페이지를 참조하십시오. 장치
(선택 사항) - (RHEL 8.8 이상)는 쿼럼 장치를 사용하도록 클러스터를 구성합니다. 기본적으로 쿼럼 장치는 사용되지 않습니다.-
model
(필수) - 쿼럼 장치 모델을 지정합니다.net
만 지원됨 model_options
(선택 사항) - 지정된 쿼럼 장치 모델을 구성하는 이름-값 사전 목록입니다. modelnet
의 경우host
및algorithm
옵션을 지정해야 합니다.pcs-address
옵션을 사용하여qnetd
호스트에 연결할 사용자 지정pcsd
주소 및 포트를 설정합니다. 이 옵션을 지정하지 않으면 역할은호스트
의 기본pcsd
포트에 연결됩니다.-
generic_options
(선택 사항) - 모델에 따라 지정되지 않은 쿼럼 장치 옵션을 설정하는 이름-값 사전 목록입니다. heuristics_options
(선택 사항) - 쿼럼 장치 이체를 구성하는 이름-값 사전 목록.쿼럼 장치 옵션에 대한 자세한 내용은
corosync-qdevice
>-< man 페이지를 참조하십시오. 일반 옵션은sync_
및 시간 초과입니다. modeltimeout
net
옵션은quorum.device.net
섹션을 참조하십시오. 추론 옵션은quorum.device.heuristics
섹션을 참조하십시오.쿼럼 장치 TLS 인증서를 다시 생성하려면
ha_cluster_regenerate_keys
변수를true
로 설정합니다.
-
-
ha_cluster_quorum
변수의 구조는 다음과 같습니다.ha_cluster_quorum: options: - name: option1_name value: option1_value - name: option2_name value: option2_value device: model: string model_options: - name: option1_name value: option1_value - name: option2_name value: option2_value generic_options: - name: option1_name value: option1_value - name: option2_name value: option2_value heuristics_options: - name: option1_name value: option1_value - name: option2_name value: option2_value
클러스터 쿼럼을 구성하는
ha_cluster
시스템 역할 플레이북의 예는 고가용성 클러스터에서 Corosync 값 구성을 참조하십시오. 쿼럼 장치를 사용하여 클러스터를 구성하는ha_cluster
System Role 플레이북의 예는 쿼럼 장치를 사용하여 고가용성 클러스터 구성을 참조하십시오.ha_cluster_sbd_enabled
(RHEL 8.7 이상) 클러스터가 SBD 노드 펜싱 메커니즘을 사용할 수 있는지 여부를 결정하는 부울 플래그입니다. 이 변수의 기본값은
false
입니다.SBD를 활성화하는
ha_cluster
시스템 역할 플레이북의 예는 SBD 노드 펜싱을 사용하여 고가용성 클러스터 구성을 참조하십시오.ha_cluster_sbd_options
(RHEL 8.7 이상) SBD 옵션을 지정하는 이름-값 사전 목록입니다. 지원되는 옵션은 다음과 같습니다.
-
delay-start
- 기본값은no
입니다. -
startmode
- defaults toalways
-
timeout-action
- 기본값은flush,reboot
watchdog-timeout
- 기본값은5
입니다.이러한 옵션에 대한 자세한 내용은
sbd
>-< 도움말 페이지의환경을 통한 구성
섹션을 참조하십시오.
-
SBD 옵션을 구성하는
ha_cluster
시스템 역할 플레이북의 예는 SBD 노드 펜싱을 사용하여 고가용성 클러스터 구성을 참조하십시오.SBD를 사용하는 경우 인벤토리의 각 노드에 대해 선택적으로 워치독 및 SBD 장치를 구성할 수 있습니다. 인벤토리 파일에서 워치독 및 SBD 장치를 구성하는 방법에 대한 자세한 내용은 ha_cluster 시스템 역할에 대한 인벤토리 지정을 참조하십시오.
ha_cluster_cluster_properties
Pacemaker 클러스터 전체 구성에 대한 클러스터 속성 세트 목록입니다. 하나의 클러스터 속성 세트만 지원됩니다.
클러스터 속성 집합의 구조는 다음과 같습니다.
ha_cluster_cluster_properties: - attrs: - name: property1_name value: property1_value - name: property2_name value: property2_value
기본적으로는 속성이 설정되지 않습니다.
다음 예제 플레이북은
node1
및node2
로 구성된 클러스터를 구성하고stonith-enabled
및no-quorum-policy
클러스터 속성을 설정합니다.- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_cluster_properties: - attrs: - name: stonith-enabled value: 'true' - name: no-quorum-policy value: stop roles: - rhel-system-roles.ha_cluster
ha_cluster_resource_primitives
이 변수는 stonith 리소스를 포함하여 시스템 역할에 의해 구성된 pacemaker 리소스를 정의합니다. 각 리소스에 대해 다음 항목을 구성할 수 있습니다.
-
ID
(필수) - 리소스 ID. -
에이전트
(mandatory) - 리소스 또는 stonith 에이전트의 이름입니다(예:ocf:pacemaker:Dummy
또는stonith:fence_xvm
). stonith 에이전트에stonith:
를 지정해야 합니다. 리소스 에이전트의 경우ocf:pacemaker:
Dummy
대신 Dummy와 같은 짧은 이름을 사용할 수 있습니다. 그러나 이름이 동일한 여러 에이전트가 설치된 경우 사용할 에이전트를 결정할 수 없으므로 역할이 실패합니다. 따라서 리소스 에이전트를 지정할 때 전체 이름을 사용하는 것이 좋습니다. -
instance_attrs
(선택 사항) - 리소스의 인스턴스 속성 세트 목록. 현재는 하나의 세트만 지원됩니다. 속성의 정확한 이름과 값은 필수인지 여부, 리소스 또는 stonith 에이전트에 따라 달라집니다. -
meta_attrs
(선택 사항) - 리소스의 메타 속성 세트 목록. 현재는 하나의 세트만 지원됩니다. 작업
(선택 사항) - 리소스 작업 목록입니다.-
작업
(필수) - pacemaker 및 리소스 또는 stonith 에이전트에 정의된 작업(작업)입니다. -
attrs
(필수) - Operation options, at least one option을 지정해야 합니다.
-
-
ha_cluster
시스템 역할로 구성하는 리소스 정의의 구조는 다음과 같습니다.- id: resource-id agent: resource-agent instance_attrs: - attrs: - name: attribute1_name value: attribute1_value - name: attribute2_name value: attribute2_value meta_attrs: - attrs: - name: meta_attribute1_name value: meta_attribute1_value - name: meta_attribute2_name value: meta_attribute2_value operations: - action: operation1-action attrs: - name: operation1_attribute1_name value: operation1_attribute1_value - name: operation1_attribute2_name value: operation1_attribute2_value - action: operation2-action attrs: - name: operation2_attribute1_name value: operation2_attribute1_value - name: operation2_attribute2_name value: operation2_attribute2_value
기본적으로 리소스는 정의되지 않습니다.
리소스 구성을 포함하는
ha_cluster
시스템 역할 플레이북의 예는 펜싱 및 리소스를 사용하여 고가용성 클러스터 구성을 참조하십시오.ha_cluster_resource_groups
이 변수는 시스템 역할에 의해 구성된 pacemaker 리소스 그룹을 정의합니다. 각 리소스 그룹에 대해 다음 항목을 구성할 수 있습니다.
-
ID
(필수) - 그룹의 ID입니다. -
resources
(필수) - 그룹 리소스 목록입니다. 각 리소스는 ID로 참조되며 리소스는ha_cluster_resource_primitives
변수에 정의해야 합니다. 하나 이상의 리소스가 나열되어야 합니다. -
meta_attrs
(선택 사항) - 그룹의 메타 속성 세트 목록입니다. 현재는 하나의 세트만 지원됩니다.
-
ha_cluster
시스템 역할로 구성하는 리소스 그룹 정의의 구조는 다음과 같습니다.ha_cluster_resource_groups: - id: group-id resource_ids: - resource1-id - resource2-id meta_attrs: - attrs: - name: group_meta_attribute1_name value: group_meta_attribute1_value - name: group_meta_attribute2_name value: group_meta_attribute2_value
기본적으로 리소스 그룹이 정의되지 않습니다.
리소스 그룹 구성을 포함하는
ha_cluster
시스템 역할 플레이북의 예는 펜싱 및 리소스를 사용하여 고가용성 클러스터 구성을 참조하십시오.ha_cluster_resource_clones
이 변수는 시스템 역할에 의해 구성된 pacemaker 리소스 복제본을 정의합니다. 리소스 복제에 대해 다음 항목을 구성할 수 있습니다.
-
resource_id
(필수) - 복제할 리소스입니다. 리소스는ha_cluster_resource_primitives
변수 또는ha_cluster_resource_groups
변수에 정의해야 합니다. -
promotable
(선택 사항) - 생성할 리소스 복제가true
또는false
로 표시된 승격 가능한 복제본인지 여부를 나타냅니다. -
ID
(선택 사항) - 복제본의 사용자 정의 ID입니다. ID를 지정하지 않으면 생성됩니다. 클러스터에서 이 옵션을 지원하지 않는 경우 경고가 표시됩니다. -
meta_attrs
(선택 사항) - 복제의 메타 특성 세트 목록입니다. 현재는 하나의 세트만 지원됩니다.
-
ha_cluster
시스템 역할로 구성하는 리소스 복제 정의의 구조는 다음과 같습니다.ha_cluster_resource_clones: - resource_id: resource-to-be-cloned promotable: true id: custom-clone-id meta_attrs: - attrs: - name: clone_meta_attribute1_name value: clone_meta_attribute1_value - name: clone_meta_attribute2_name value: clone_meta_attribute2_value
기본적으로 리소스 복제는 정의되지 않습니다.
리소스 복제 구성을 포함하는
ha_cluster
시스템 역할 플레이북의 예는 펜싱 및 리소스를 사용하여 고가용성 클러스터 구성을 참조하십시오.ha_cluster_constraints_location
이 변수는 리소스 위치 제약 조건을 정의합니다. 리소스 위치 제한 조건은 리소스를 실행할 수 있는 노드를 나타냅니다. 리소스 ID 또는 둘 이상의 리소스와 일치시킬 수 있는 패턴으로 지정된 리소스를 지정할 수 있습니다. 노드 이름 또는 규칙으로 노드를 지정할 수 있습니다.
리소스 위치 제약 조건에 대해 다음 항목을 구성할 수 있습니다.
-
Resource
(mandatory) - 제약 조건이 적용되는 리소스의 사양입니다. -
Node
(mandatory) - 리소스에서 선호하거나 피해야 하는 노드의 이름입니다. -
ID
(선택 사항) - 제약 조건의 ID입니다. 지정하지 않으면 자동으로 생성됩니다. options
(선택 사항) - 이름-값 사전 목록.score
- 제약 조건의 가중치를 설정합니다.-
양수
점수
값은 리소스가 노드에서 실행을 선호하는 것을 의미합니다. -
음수
점수
값은 리소스가 노드에서 실행되지 않도록 해야 함을 의미합니다. -
점수
값은-INFINITY
는 리소스가 노드에서 실행되지 않도록 해야 함을 의미합니다. -
점수를
지정하지 않으면 기본값은INFINITY
입니다.
-
양수
-
기본적으로 리소스 위치 제한 조건이 정의되지 않습니다.
리소스 ID 및 노드 이름을 지정하는 리소스 위치 제한 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_location: - resource: id: resource-id node: node-name id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
리소스 패턴을 지정하는 리소스 위치 제약 조건에 대해 구성하는 항목은 리소스 사양 자체를 제외하고 리소스 ID를 지정하는 리소스 위치 제약 조건에 대해 구성하는 것과 동일한 항목입니다. 리소스 사양에 지정하는 항목은 다음과 같습니다.
-
패턴
(필수) - POSIX 확장 정규식 리소스 ID와 대조됩니다.
-
리소스 패턴 및 노드 이름을 지정하는 리소스 위치 제한 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_location: - resource: pattern: resource-pattern node: node-name id: constraint-id options: - name: score value: score-value - name: resource-discovery value: resource-discovery-value
리소스 ID와 규칙을 지정하는 리소스 위치 제약 조건에 대해 다음 항목을 구성할 수 있습니다.
Resource
(mandatory) - 제약 조건이 적용되는 리소스의 사양입니다.-
ID
(필수) - 리소스 ID. -
role
(선택 사항) - 제약 조건이 제한된 리소스 역할:Started
,Unpromoted
,>-<d
.
-
-
rule
(필수) -pcs
구문을 사용하여 작성된 제약 조건 규칙. 자세한 내용은pcs
ECDHE man 페이지의제약 조건 위치
섹션을 참조하십시오. - 지정할 다른 항목은 규칙을 지정하지 않는 리소스 제약 조건에 대해 와 동일한 의미가 있습니다.
리소스 ID와 규칙을 지정하는 리소스 위치 제약 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_location: - resource: id: resource-id role: resource-role rule: rule-string id: constraint-id options: - name: score value: score-value - name: resource-discovery value: resource-discovery-value
리소스 위치 제약 조건에 대해 구성하는 항목이 리소스 패턴을 지정하고 규칙은 리소스 ID와 규칙을 지정하는 리소스 위치 제약 조건에 대해 구성하는 것과 동일한 항목입니다. 리소스 사양에 지정하는 항목은 다음과 같습니다.
-
패턴
(필수) - POSIX 확장 정규식 리소스 ID와 대조됩니다.
-
리소스 패턴 및 규칙을 지정하는 리소스 위치 제약 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_location: - resource: pattern: resource-pattern role: resource-role rule: rule-string id: constraint-id options: - name: score value: score-value - name: resource-discovery value: resource-discovery-value
리소스 제약 조건으로 클러스터를 생성하는
ha_cluster
시스템 역할 플레이북의 예는 리소스 제약 조건으로 고가용성 클러스터 구성을 참조하십시오.ha_cluster_constraints_colocation
이 변수는 리소스 공동 배치 제약 조건을 정의합니다. 리소스 공동 배치 제한 조건은 한 리소스의 위치가 다른 리소스의 위치에 따라 달라짐을 나타냅니다. 두 리소스에 대한 간단한 공동 배치 제약 조건 및 여러 리소스에 대한 공동 배치 제약 조건의 두 가지 유형의 공동 배치 제약 조건이 있습니다.
간단한 리소스 공동 배치 제약 조건에 대해 다음 항목을 구성할 수 있습니다.
resource_follower
(mandatory) -resource_leader
에 상대적으로 배치되어야 하는 리소스입니다.-
ID
(필수) - 리소스 ID. -
role
(선택 사항) - 제약 조건이 제한된 리소스 역할:Started
,Unpromoted
,>-<d
.
-
resource_leader
(mandatory) - 클러스터에서 이 리소스를 먼저 배치한 다음resource_follower
를 배치할 위치를 결정합니다.-
ID
(필수) - 리소스 ID. -
role
(선택 사항) - 제약 조건이 제한된 리소스 역할:Started
,Unpromoted
,>-<d
.
-
-
ID
(선택 사항) - 제약 조건의 ID입니다. 지정하지 않으면 자동으로 생성됩니다. options
(선택 사항) - 이름-값 사전 목록.score
- 제약 조건의 가중치를 설정합니다.-
양수
점수
값은 동일한 노드에서 리소스를 실행해야 함을 나타냅니다. -
음수
점수
값은 리소스를 다른 노드에서 실행해야 함을 나타냅니다. -
점수
값이+INFINITY
는 동일한 노드에서 리소스를 실행해야 함을 나타냅니다. -
score
값-INFINITY
는 리소스가 다른 노드에서 실행되어야 함을 나타냅니다. -
점수를
지정하지 않으면 기본값은INFINITY
입니다.
-
양수
기본적으로 리소스 공동 배치 제한 조건은 정의되지 않습니다.
간단한 리소스 공동 배치 제약 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_colocation: - resource_follower: id: resource-id1 role: resource-role1 resource_leader: id: resource-id2 role: resource-role2 id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
리소스 집합 공동 배치 제약 조건에 대해 다음 항목을 구성할 수 있습니다.
resource_sets
(필수) - 리소스 세트 목록.-
resource_ids
(필수) - 세트의 리소스 목록입니다. -
옵션
(선택 사항) - 이름-값 사전 목록이 제약 조건에 따라 세트의 리소스를 처리하는 방식을 미세 조정합니다.
-
-
ID
(선택 사항) - 간단한 공동 배치 제약 조건에 대한 값과 동일합니다. -
options
(선택 사항) - 간단한 공동 배치 제약 조건에 대한 값과 동일합니다.
리소스 세트 공동 배치 제약 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_colocation: - resource_sets: - resource_ids: - resource-id1 - resource-id2 options: - name: option-name value: option-value id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
리소스 제약 조건으로 클러스터를 생성하는
ha_cluster
시스템 역할 플레이북의 예는 리소스 제약 조건으로 고가용성 클러스터 구성을 참조하십시오.ha_cluster_constraints_order
이 변수는 리소스 순서 제약 조건을 정의합니다. 리소스 순서 제한 조건은 특정 리소스 작업이 발생하는 순서를 나타냅니다. 리소스 순서 제약 조건은 두 가지 리소스에 대한 간단한 순서 제한 조건과 여러 리소스에 대한 설정 순서 제약 조건의 두 가지 유형이 있습니다.
간단한 리소스 순서 제약 조건에 대해 다음 항목을 구성할 수 있습니다.
resource_first
(필수) -resource_ECDHE 리소스
가 의존하는 리소스입니다.-
ID
(필수) - 리소스 ID. -
action
(선택 사항) -resource_
ECDHE 리소스에 대해 작업을 시작하기 전에 완료해야 하는 작업입니다. 허용되는 값:start
,stop
,promote
,demote
.
-
resource_ECDHE
(필수) - 종속 리소스입니다.-
ID
(필수) - 리소스 ID. -
action
(선택 사항) -resource_first
리소스의 작업이 완료된 후에만 리소스를 실행할 수 있는 작업입니다. 허용되는 값:start
,stop
,promote
,demote
.
-
-
ID
(선택 사항) - 제약 조건의 ID입니다. 지정하지 않으면 자동으로 생성됩니다. -
options
(선택 사항) - 이름-값 사전 목록.
기본적으로 리소스 순서 제한 조건은 정의되어 있지 않습니다.
간단한 리소스 순서 제약 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_order: - resource_first: id: resource-id1 action: resource-action1 resource_then: id: resource-id2 action: resource-action2 id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
리소스 집합 순서 제약 조건에 대해 다음 항목을 구성할 수 있습니다.
resource_sets
(필수) - 리소스 세트 목록.-
resource_ids
(필수) - 세트의 리소스 목록입니다. -
옵션
(선택 사항) - 이름-값 사전 목록이 제약 조건에 따라 세트의 리소스를 처리하는 방식을 미세 조정합니다.
-
-
ID
(선택 사항) - 간단한 순서 제약 조건의 값과 동일합니다. -
options
(선택 사항) - 간단한 순서 제약 조건의 값과 동일합니다.
리소스 집합 순서 제약 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_order: - resource_sets: - resource_ids: - resource-id1 - resource-id2 options: - name: option-name value: option-value id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
리소스 제약 조건이 있는 클러스터를 생성하는
ha_cluster
시스템 역할 플레이북의 예는 리소스 제약 조건 을 사용하여 고가용성 클러스터 구성을 참조하십시오.ha_cluster_constraints_ticket
이 변수는 리소스 티켓 제약 조건을 정의합니다. 리소스 티켓 제약 조건은 특정 티켓에 의존하는 리소스를 나타냅니다. 리소스 티켓 제약 조건에는 하나의 리소스에 대한 간단한 티켓 제약 조건 및 여러 리소스에 대한 티켓 순서 제약 조건의 두 가지 유형이 있습니다.
간단한 리소스 티켓 제약 조건에 대해 다음 항목을 구성할 수 있습니다.
Resource
(mandatory) - 제약 조건이 적용되는 리소스의 사양입니다.-
ID
(필수) - 리소스 ID. -
role
(선택 사항) - 제약 조건이 제한된 리소스 역할:Started
,Unpromoted
,>-<d
.
-
-
티켓
(필수) - 리소스가 종속된 티켓의 이름입니다. -
ID
(선택 사항) - 제약 조건의 ID입니다. 지정하지 않으면 자동으로 생성됩니다. options
(선택 사항) - 이름-값 사전 목록.-
loss-policy
(선택 사항) - 티켓이 취소된 경우 리소스에서 수행할 작업입니다.
-
기본적으로 리소스 티켓 제약 조건이 정의되지 않습니다.
간단한 리소스 티켓 제약 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_ticket: - resource: id: resource-id role: resource-role ticket: ticket-name id: constraint-id options: - name: loss-policy value: loss-policy-value - name: option-name value: option-value
리소스 세트 티켓 제약 조건에 대해 다음 항목을 구성할 수 있습니다.
resource_sets
(필수) - 리소스 세트 목록.-
resource_ids
(필수) - 세트의 리소스 목록입니다. -
옵션
(선택 사항) - 이름-값 사전 목록이 제약 조건에 따라 세트의 리소스를 처리하는 방식을 미세 조정합니다.
-
-
티켓
(필수) - 간단한 티켓 제약 조건의 값과 동일합니다. -
ID
(선택 사항) - 간단한 티켓 제약 조건에 대한 값과 동일합니다. -
options
(선택 사항) - 간단한 티켓 제약 조건에 대한 값과 동일합니다.
리소스 세트 티켓 제약 조건의 구조는 다음과 같습니다.
ha_cluster_constraints_ticket: - resource_sets: - resource_ids: - resource-id1 - resource-id2 options: - name: option-name value: option-value ticket: ticket-name id: constraint-id options: - name: option-name value: option-value
리소스 제약 조건으로 클러스터를 생성하는
ha_cluster
시스템 역할 플레이북의 예는 리소스 제약 조건으로 고가용성 클러스터 구성을 참조하십시오.ha_cluster_qnetd
(RHEL 8.8 이상) 이 변수는 클러스터의 외부 쿼럼 장치로 사용할 수 있는
qnetd
호스트를 구성합니다.qnetd
호스트에 대해 다음 항목을 구성할 수 있습니다.-
present
(선택 사항) -true
인 경우 호스트에서qnetd
인스턴스를 구성합니다.false
인 경우 호스트에서qnetd
구성을 제거합니다. 기본값은false
입니다. 이true
를 설정하는 경우ha_cluster_cluster_present
를false
로 설정해야 합니다. -
start_on_boot
(선택 사항) - 부팅 시qnetd
인스턴스가 자동으로 시작되는지 여부를 구성합니다. 기본값은true
입니다. -
recreate_keys
(선택 사항) -qnetd
TLS 인증서를 다시 생성하려면 이 변수를true
로 설정합니다. 인증서를 다시 생성하는 경우 각 클러스터에 대해 역할을 다시 실행하여qnetd
호스트에 다시 연결하거나pcs
를 수동으로 실행해야 합니다.
-
펜싱으로 인해
qnetd
작업이 중단되므로 클러스터 노드에서qnetd
를 실행할 수 없습니다.쿼럼 장치를 사용하여 클러스터를 구성하는
ha_cluster
시스템 역할 플레이북의 예는 쿼럼 장치를 사용하여 클러스터 구성을 참조하십시오.
25.2. ha_cluster
시스템 역할의 인벤토리 지정
ha_cluster
시스템 역할 플레이북을 사용하여 HA 클러스터를 구성할 때 인벤토리에 클러스터의 노드의 이름과 주소를 구성합니다.
25.2.1. 인벤토리에서 노드 이름 및 주소 구성
인벤토리의 각 노드에 대해 선택적으로 다음 항목을 지정할 수 있습니다.
-
NODE_
NAME - 클러스터의 노드 이름입니다. -
pcs_address
-pcs
가 노드와 통신하는 데 사용하는 주소입니다. 이름, FQDN 또는 IP 주소일 수 있으며 포트 번호를 포함할 수 있습니다. -
corosync_addresses
- Corosync에서 사용하는 주소 목록입니다. 특정 클러스터를 구성하는 모든 노드는 동일한 수의 주소 수와 주소 순서가 중요해야 합니다.
다음 예제에서는 node1
및 node2
대상이 있는 인벤토리를 보여줍니다. node1
및 node2
는 정규화된 도메인 이름이어야 합니다. 그렇지 않으면 /etc/hosts
파일을 통해 이름을 확인할 수 있는 것처럼 노드에 연결할 수 있어야 합니다.
all: hosts: node1: ha_cluster: node_name: node-A pcs_address: node1-address corosync_addresses: - 192.168.1.11 - 192.168.2.11 node2: ha_cluster: node_name: node-B pcs_address: node2-address:2224 corosync_addresses: - 192.168.1.12 - 192.168.2.12
25.2.2. 인벤토리에서 워치독 및 SBD 장치 구성 (RHEL 8.7 이상)
SBD를 사용하는 경우 인벤토리의 각 노드에 대해 선택적으로 워치독 및 SBD 장치를 구성할 수 있습니다. 모든 SBD 장치를 공유하여 모든 노드에서 액세스할 수 있어야 하지만 각 노드는 장치에 서로 다른 이름을 사용할 수 있습니다. 워치독 장치는 노드마다 다를 수도 있습니다. 시스템 역할 플레이북에서 설정할 수 있는 SBD 변수에 대한 자세한 내용은ha_cluster
시스템 역할 변수의 ha_cluster_sbd_enabled
및 ha_cluster_sbd_
options 에 대한 항목을 참조하십시오.
인벤토리의 각 노드에 대해 선택적으로 다음 항목을 지정할 수 있습니다.
-
sbd_watchdog
- SBD에서 사용할 감시 장치. 설정되지 않은 경우 기본값은/dev/watchdog
입니다. -
sbd_devices
- SBD 메시지를 교환하고 모니터링에 사용할 장치입니다. 설정하지 않는 경우 기본값은 빈 목록입니다.
다음 예제에서는 node1
및 node2
대상에 대해 워치독 및 SBD 장치를 구성하는 인벤토리를 보여줍니다.
all: hosts: node1: ha_cluster: sbd_watchdog: /dev/watchdog2 sbd_devices: - /dev/vdx - /dev/vdy node2: ha_cluster: sbd_watchdog: /dev/watchdog1 sbd_devices: - /dev/vdw - /dev/vdz
25.3. 고가용성 클러스터를 위한 pcsd TLS 인증서 및 키 파일 생성 (RHEL 8.8 이상)
ha_cluster
시스템 역할을 사용하여 고가용성 클러스터에서 TLS 인증서 및 키 파일을 생성할 수 있습니다. 이 플레이북을 실행하면 ha_cluster
시스템 역할이 내부적으로 인증서를
사용하여 TLS 인증서를 관리합니다.
사전 요구 사항
ansible-core
및rhel-system-roles
패키지는 플레이북을 실행하려는 노드에 설치됩니다.참고클러스터 멤버 노드에
ansible-core
를 설치할 필요가 없습니다.- 클러스터 구성원에게 RHEL 및 RHEL 고가용성 애드온에 대한 활성 서브스크립션 적용 범위로 사용할 시스템이 있습니다.
ha_cluster
시스템 역할은 지정된 노드의 기존 클러스터 구성을 대체합니다. 역할에 지정되지 않은 모든 설정은 손실됩니다.
절차
- ha_cluster 시스템 역할에 대한 인벤토리 지정에 설명된 대로 클러스터의 노드를 지정하는 인벤토리 파일을 생성합니다.
플레이북 파일(예:
new-cluster.yml
)을 생성합니다.참고프로덕션용 플레이북 파일을 생성할 때 자격 증명 모음은 Ansible Vault로 콘텐츠 암호화에 설명된 대로 암호를 암호화합니다.
다음 예제 플레이북 파일은
firewalld
및selinux
서비스를 실행하는 클러스터를 구성하고 자체 서명된pcsd
인증서 및 개인 키 파일을/var/lib/pcsd
에 생성합니다.pcsd
인증서의 파일 이름은 10.0.0.1NAME.crt
이고 키 파일의 이름은 10.0.0.1NAME.key
입니다.- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_pcsd_certificates: - name: FILENAME common_name: "{{ ansible_hostname }}" ca: self-sign roles: - linux-system-roles.ha_cluster
- 파일을 저장합니다.
1단계에서 생성한 인벤토리 파일 인벤토리 의 경로를 지정하여 플레이북을 실행합니다.
# ansible-playbook -i inventory new-cluster.yml
25.4. 리소스 없이 실행 중인 고가용성 클러스터 구성
다음 절차에서는 ha_cluster
시스템 역할을 사용하여 펜싱이 구성되지 않고 리소스를 실행하지 않고 고가용성 클러스터를 생성합니다.
사전 요구 사항
플레이북을 실행할 노드에
ansible-core
가 설치되어 있어야 합니다.참고클러스터 멤버 노드에
ansible-core
를 설치할 필요가 없습니다.-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. - 클러스터 구성원에게 RHEL 및 RHEL 고가용성 애드온에 대한 활성 서브스크립션 적용 범위로 사용할 시스템이 있습니다.
ha_cluster
시스템 역할은 지정된 노드의 기존 클러스터 구성을 대체합니다. 역할에 지정되지 않은 모든 설정은 손실됩니다.
절차
- ha_cluster 시스템 역할에 대한 인벤토리 지정에 설명된 대로 클러스터의 노드를 지정하는 인벤토리 파일을 생성합니다.
플레이북 파일(예:
new-cluster.yml
)을 생성합니다.참고프로덕션용 플레이북 파일을 생성할 때 자격 증명 모음은 Ansible Vault로 콘텐츠 암호화에 설명된 대로 암호를 암호화합니다.
다음 예제 플레이북 파일은 펜싱이 구성되지 않고 리소스를 실행하지 않은
firewalld
및selinux
서비스를 실행하는 클러스터를 구성합니다.- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true roles: - rhel-system-roles.ha_cluster
- 파일을 저장합니다.
1단계에서 생성한 인벤토리 파일 인벤토리 의 경로를 지정하여 플레이북을 실행합니다.
# ansible-playbook -i inventory new-cluster.yml
25.5. 펜싱 및 리소스를 사용하여 고가용성 클러스터 구성
다음 절차에서는 ha_cluster
시스템 역할을 사용하여 펜싱 장치, 클러스터 리소스, 리소스 그룹, 복제된 리소스가 포함된 고가용성 클러스터를 생성합니다.
사전 요구 사항
플레이북을 실행할 노드에
ansible-core
가 설치되어 있어야 합니다.참고클러스터 멤버 노드에
ansible-core
를 설치할 필요가 없습니다.-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. - 클러스터 구성원에게 RHEL 및 RHEL 고가용성 애드온에 대한 활성 서브스크립션 적용 범위로 사용할 시스템이 있습니다.
ha_cluster
시스템 역할은 지정된 노드의 기존 클러스터 구성을 대체합니다. 역할에 지정되지 않은 모든 설정은 손실됩니다.
절차
- ha_cluster 시스템 역할에 대한 인벤토리 지정에 설명된 대로 클러스터의 노드를 지정하는 인벤토리 파일을 생성합니다.
플레이북 파일(예:
new-cluster.yml
)을 생성합니다.참고프로덕션용 플레이북 파일을 생성할 때 자격 증명 모음은 Ansible Vault로 콘텐츠 암호화에 설명된 대로 암호를 암호화합니다.
다음 예제 플레이북 파일은
firewalld
및selinux
서비스를 실행하는 클러스터를 구성합니다. 클러스터에는 펜싱, 여러 리소스, 리소스 그룹이 포함됩니다. 리소스 그룹에 대한 리소스 복제도 포함되어 있습니다.- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_resource_primitives: - id: xvm-fencing agent: 'stonith:fence_xvm' instance_attrs: - attrs: - name: pcmk_host_list value: node1 node2 - id: simple-resource agent: 'ocf:pacemaker:Dummy' - id: resource-with-options agent: 'ocf:pacemaker:Dummy' instance_attrs: - attrs: - name: fake value: fake-value - name: passwd value: passwd-value meta_attrs: - attrs: - name: target-role value: Started - name: is-managed value: 'true' operations: - action: start attrs: - name: timeout value: '30s' - action: monitor attrs: - name: timeout value: '5' - name: interval value: '1min' - id: dummy-1 agent: 'ocf:pacemaker:Dummy' - id: dummy-2 agent: 'ocf:pacemaker:Dummy' - id: dummy-3 agent: 'ocf:pacemaker:Dummy' - id: simple-clone agent: 'ocf:pacemaker:Dummy' - id: clone-with-options agent: 'ocf:pacemaker:Dummy' ha_cluster_resource_groups: - id: simple-group resource_ids: - dummy-1 - dummy-2 meta_attrs: - attrs: - name: target-role value: Started - name: is-managed value: 'true' - id: cloned-group resource_ids: - dummy-3 ha_cluster_resource_clones: - resource_id: simple-clone - resource_id: clone-with-options promotable: yes id: custom-clone-id meta_attrs: - attrs: - name: clone-max value: '2' - name: clone-node-max value: '1' - resource_id: cloned-group promotable: yes roles: - rhel-system-roles.ha_cluster
- 파일을 저장합니다.
1단계에서 생성한 인벤토리 파일 인벤토리 의 경로를 지정하여 플레이북을 실행합니다.
# ansible-playbook -i inventory new-cluster.yml
25.6. 리소스 제약 조건을 사용하여 고가용성 클러스터 구성
다음 절차에서는 ha_cluster
시스템 역할을 사용하여 리소스 위치 제약 조건, 리소스 공동 배치 제약 조건, 리소스 순서 제약 조건 및 리소스 티켓 제약 조건을 포함하는 고가용성 클러스터를 생성합니다.
사전 요구 사항
플레이북을 실행할 노드에
ansible-core
가 설치되어 있어야 합니다.참고클러스터 멤버 노드에
ansible-core
를 설치할 필요가 없습니다.-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. - 클러스터 구성원에게 RHEL 및 RHEL 고가용성 애드온에 대한 활성 서브스크립션 적용 범위로 사용할 시스템이 있습니다.
ha_cluster
시스템 역할은 지정된 노드의 기존 클러스터 구성을 대체합니다. 역할에 지정되지 않은 모든 설정은 손실됩니다.
절차
- ha_cluster 시스템 역할에 대한 인벤토리 지정에 설명된 대로 클러스터의 노드를 지정하는 인벤토리 파일을 생성합니다.
플레이북 파일(예:
new-cluster.yml
)을 생성합니다.참고프로덕션용 플레이북 파일을 생성할 때 자격 증명 모음은 Ansible Vault로 콘텐츠 암호화에 설명된 대로 암호를 암호화합니다.
다음 예제 플레이북 파일은
firewalld
및selinux
서비스를 실행하는 클러스터를 구성합니다. 클러스터에는 리소스 위치 제한 조건, 리소스 공동 배치 제약 조건, 리소스 순서 제약 조건, 리소스 티켓 제약 조건이 포함됩니다.- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true # In order to use constraints, we need resources the constraints will apply # to. ha_cluster_resource_primitives: - id: xvm-fencing agent: 'stonith:fence_xvm' instance_attrs: - attrs: - name: pcmk_host_list value: node1 node2 - id: dummy-1 agent: 'ocf:pacemaker:Dummy' - id: dummy-2 agent: 'ocf:pacemaker:Dummy' - id: dummy-3 agent: 'ocf:pacemaker:Dummy' - id: dummy-4 agent: 'ocf:pacemaker:Dummy' - id: dummy-5 agent: 'ocf:pacemaker:Dummy' - id: dummy-6 agent: 'ocf:pacemaker:Dummy' # location constraints ha_cluster_constraints_location: # resource ID and node name - resource: id: dummy-1 node: node1 options: - name: score value: 20 # resource pattern and node name - resource: pattern: dummy-\d+ node: node1 options: - name: score value: 10 # resource ID and rule - resource: id: dummy-2 rule: '#uname eq node2 and date in_range 2022-01-01 to 2022-02-28' # resource pattern and rule - resource: pattern: dummy-\d+ rule: node-type eq weekend and date-spec weekdays=6-7 # colocation constraints ha_cluster_constraints_colocation: # simple constraint - resource_leader: id: dummy-3 resource_follower: id: dummy-4 options: - name: score value: -5 # set constraint - resource_sets: - resource_ids: - dummy-1 - dummy-2 - resource_ids: - dummy-5 - dummy-6 options: - name: sequential value: "false" options: - name: score value: 20 # order constraints ha_cluster_constraints_order: # simple constraint - resource_first: id: dummy-1 resource_then: id: dummy-6 options: - name: symmetrical value: "false" # set constraint - resource_sets: - resource_ids: - dummy-1 - dummy-2 options: - name: require-all value: "false" - name: sequential value: "false" - resource_ids: - dummy-3 - resource_ids: - dummy-4 - dummy-5 options: - name: sequential value: "false" # ticket constraints ha_cluster_constraints_ticket: # simple constraint - resource: id: dummy-1 ticket: ticket1 options: - name: loss-policy value: stop # set constraint - resource_sets: - resource_ids: - dummy-3 - dummy-4 - dummy-5 ticket: ticket2 options: - name: loss-policy value: fence roles: - linux-system-roles.ha_cluster
- 파일을 저장합니다.
1단계에서 생성한 인벤토리 파일 인벤토리 의 경로를 지정하여 플레이북을 실행합니다.
# ansible-playbook -i inventory new-cluster.yml
25.7. 고가용성 클러스터에서 Corosync 값 구성
(RHEL 8.7 이상) 다음 절차에서는 ha_cluster
시스템 역할을 사용하여 Corosync 값을 구성하는 고가용성 클러스터를 생성합니다.
사전 요구 사항
플레이북을 실행할 노드에
ansible-core
가 설치되어 있어야 합니다.참고클러스터 멤버 노드에
ansible-core
를 설치할 필요가 없습니다.-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. - 클러스터 구성원에게 RHEL 및 RHEL 고가용성 애드온에 대한 활성 서브스크립션 적용 범위로 사용할 시스템이 있습니다.
ha_cluster
시스템 역할은 지정된 노드의 기존 클러스터 구성을 대체합니다. 역할에 지정되지 않은 모든 설정은 손실됩니다.
절차
- ha_cluster 시스템 역할에 대한 인벤토리 지정에 설명된 대로 클러스터의 노드를 지정하는 인벤토리 파일을 생성합니다.
플레이북 파일(예:
new-cluster.yml
)을 생성합니다.참고프로덕션용 플레이북 파일을 만들 때 Vault는 Ansible Vault로 콘텐츠 암호화에 설명된 대로 암호를 암호화합니다.
다음 예제 플레이북 파일은 Corosync 속성을 구성하는
firewalld
및selinux
서비스를 실행하는 클러스터를 구성합니다.- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_transport: type: knet options: - name: ip_version value: ipv4-6 - name: link_mode value: active links: - - name: linknumber value: 1 - name: link_priority value: 5 - - name: linknumber value: 0 - name: link_priority value: 10 compression: - name: level value: 5 - name: model value: zlib crypto: - name: cipher value: none - name: hash value: none ha_cluster_totem: options: - name: block_unlisted_ips value: 'yes' - name: send_join value: 0 ha_cluster_quorum: options: - name: auto_tie_breaker value: 1 - name: wait_for_all value: 1 roles: - linux-system-roles.ha_cluster
- 파일을 저장합니다.
1단계에서 생성한 인벤토리 파일 인벤토리 의 경로를 지정하여 플레이북을 실행합니다.
# ansible-playbook -i inventory new-cluster.yml
25.8. SBD 노드 펜싱을 사용하여 고가용성 클러스터 구성
(RHEL 8.7 이상) 다음 절차에서는 ha_cluster
시스템 역할을 사용하여 SBD 노드 펜싱을 사용하는 고가용성 클러스터를 생성합니다.
사전 요구 사항
플레이북을 실행할 노드에
ansible-core
가 설치되어 있어야 합니다.참고클러스터 멤버 노드에
ansible-core
를 설치할 필요가 없습니다.-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. - 클러스터 구성원에게 RHEL 및 RHEL 고가용성 애드온에 대한 활성 서브스크립션 적용 범위로 사용할 시스템이 있습니다.
ha_cluster
시스템 역할은 지정된 노드의 기존 클러스터 구성을 대체합니다. 역할에 지정되지 않은 모든 설정은 손실됩니다.
절차
- ha_cluster 시스템 역할에 대한 인벤토리 지정에 설명된 대로 클러스터의 노드를 지정하는 인벤토리 파일을 생성합니다. 인벤토리 파일의 클러스터 각 노드에 대해 선택적으로 워치독 및 SBD 장치를 구성할 수 있습니다.
플레이북 파일(예:
new-cluster.yml
)을 생성합니다.참고프로덕션용 플레이북 파일을 생성할 때 자격 증명 모음은 Ansible Vault로 콘텐츠 암호화에 설명된 대로 암호를 암호화합니다.
다음 예제 플레이북 파일은 SBD 펜싱을 사용하는
firewalld
및selinux
서비스를 실행하는 클러스터를 구성합니다.- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_sbd_enabled: yes ha_cluster_sbd_options: - name: delay-start value: 'no' - name: startmode value: always - name: timeout-action value: 'flush,reboot' - name: watchdog-timeout value: 5 roles: - linux-system-roles.ha_cluster
- 파일을 저장합니다.
1단계에서 생성한 인벤토리 파일 인벤토리 의 경로를 지정하여 플레이북을 실행합니다.
# ansible-playbook -i inventory new-cluster.yml
25.9. 쿼럼 장치(RHEL 8.8 이상)를 사용하여 고가용성 클러스터 구성
ha_cluster
시스템 역할을 사용하여 별도의 쿼럼 장치로 고가용성 클러스터를 구성하려면 먼저 쿼럼 장치를 설정합니다. 쿼럼 장치를 설정한 후 여러 클러스터에서 장치를 사용할 수 있습니다.
25.9.1. 쿼럼 장치 구성
ha_cluster
시스템 역할을 사용하여 쿼럼 장치를 구성하려면 다음 단계를 따르십시오. 클러스터 노드에서 쿼럼 장치를 실행할 수 없습니다.
사전 요구 사항
ansible-core
및rhel-system-roles
패키지는 플레이북을 실행하려는 노드에 설치됩니다.참고클러스터 멤버 노드에
ansible-core
를 설치할 필요가 없습니다.- 쿼럼 장치를 실행하는 데 사용할 시스템에는 RHEL 및 RHEL 고가용성 애드온에 대한 활성 서브스크립션 옵션이 있습니다.
ha_cluster
시스템 역할은 지정된 노드의 기존 클러스터 구성을 대체합니다. 역할에 지정되지 않은 모든 설정은 손실됩니다.
절차
플레이북 파일(예:
qdev-playbook.yml
)을 생성합니다.참고프로덕션용 플레이북 파일을 생성할 때 자격 증명 모음은 Ansible Vault로 콘텐츠 암호화에 설명된 대로 암호를 암호화합니다.
다음 예제 플레이북 파일은
firewalld
및selinux
서비스를 실행하는 시스템에서 쿼럼 장치를 구성합니다.- hosts: nodeQ vars: ha_cluster_cluster_present: false ha_cluster_hacluster_password: password ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_qnetd: present: true roles: - linux-system-roles.ha_cluster
- 파일을 저장합니다.
쿼럼 장치의 호스트 노드를 지정하여 플레이북을 실행합니다.
# ansible-playbook -i nodeQ, qdev-playbook.yml
25.9.2. 쿼럼 장치를 사용하도록 클러스터 구성
쿼럼 장치를 사용하도록 클러스터를 구성하려면 다음 단계를 따르십시오.
사전 요구 사항
플레이북을 실행할 노드에
ansible-core
가 설치되어 있어야 합니다.참고클러스터 멤버 노드에
ansible-core
를 설치할 필요가 없습니다.-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. - 클러스터 구성원에게 RHEL 및 RHEL 고가용성 애드온에 대한 활성 서브스크립션 적용 범위로 사용할 시스템이 있습니다.
- 쿼럼 장치를 구성했습니다.
ha_cluster
시스템 역할은 지정된 노드의 기존 클러스터 구성을 대체합니다. 역할에 지정되지 않은 모든 설정은 손실됩니다.
절차
- ha_cluster 시스템 역할에 대한 인벤토리 지정에 설명된 대로 클러스터의 노드를 지정하는 인벤토리 파일을 생성합니다.
플레이북 파일(예:
new-cluster.yml
)을 생성합니다.참고프로덕션용 플레이북 파일을 생성할 때 자격 증명 모음은 Ansible Vault로 콘텐츠 암호화에 설명된 대로 암호를 암호화합니다.
다음 예제 플레이북 파일은 쿼럼 장치를 사용하는
firewalld
및selinux
서비스를 실행하는 클러스터를 구성합니다.- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_quorum: device: model: net model_options: - name: host value: nodeQ - name: algorithm value: lms roles: - linux-system-roles.ha_cluster
- 파일을 저장합니다.
1단계에서 생성한 인벤토리 파일 인벤토리 의 경로를 지정하여 플레이북을 실행합니다.
# ansible-playbook -i inventory new-cluster.yml
25.10. ha_cluster
시스템 역할을 사용하여 고가용성 클러스터에서 Apache HTTP 서버 구성
이 절차에서는 ha_cluster
시스템 역할을 사용하여 2노드 Red Hat Enterprise Linux High Availability Add-On 클러스터에서 활성/수동 Apache HTTP 서버를 구성합니다.
사전 요구 사항
플레이북을 실행할 노드에
ansible-core
가 설치되어 있어야 합니다.참고클러스터 멤버 노드에
ansible-core
를 설치할 필요가 없습니다.-
플레이북을 실행하려는 시스템에
rhel-system-roles
패키지가 설치되어 있습니다. - 클러스터 구성원에게 RHEL 및 RHEL 고가용성 애드온에 대한 활성 서브스크립션 적용 범위로 사용할 시스템이 있습니다.
- 시스템에 Apache에 필요한 공용 가상 IP 주소가 포함되어 있습니다.
- 시스템에는 iSCSI, 파이버 채널 또는 기타 공유 네트워크 블록 장치를 사용하여 클러스터의 노드에 대한 공유 스토리지가 포함됩니다.
- Pacemaker 클러스터에서 XFS 파일 시스템으로 LVM 볼륨 구성에 설명된 대로 XFS 파일 시스템으로 LVM 논리 볼륨을 구성했습니다.
- Apache HTTP 서버 구성에 설명된 대로 Apache HTTP 서버를 구성했습니다.
- 시스템에는 클러스터 노드를 펜싱하는 데 사용할 APC 전원 스위치가 포함되어 있습니다.
ha_cluster
시스템 역할은 지정된 노드의 기존 클러스터 구성을 대체합니다. 역할에 지정되지 않은 모든 설정은 손실됩니다.
절차
- ha_cluster 시스템 역할에 대한 인벤토리 지정에 설명된 대로 클러스터의 노드를 지정하는 인벤토리 파일을 생성합니다.
플레이북 파일(예:
http-cluster.yml
)을 생성합니다.참고프로덕션용 플레이북 파일을 생성할 때 자격 증명 모음은 Ansible Vault로 콘텐츠 암호화에 설명된 대로 암호를 암호화합니다.
다음 예제 플레이북 파일은
firewalld
및selinux
서비스를 실행하는 활성/패시브 2-노드 HA 클러스터에 이전에 생성된 Apache HTTP 서버를 구성합니다.이 예에서는 호스트 이름이
zapc.example.com
인 APC 전원 스위치를 사용합니다. 클러스터에서 다른 펜싱 에이전트를 사용하지 않는 경우, 이 예제와 같이 클러스터에ha_cluster_fence_agent_packages
변수를 정의할 때 필요한 fence 에이전트만 나열할 수 있습니다.- hosts: z1.example.com z2.example.com roles: - rhel-system-roles.ha_cluster vars: ha_cluster_hacluster_password: password ha_cluster_cluster_name: my_cluster ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_fence_agent_packages: - fence-agents-apc-snmp ha_cluster_resource_primitives: - id: myapc agent: stonith:fence_apc_snmp instance_attrs: - attrs: - name: ipaddr value: zapc.example.com - name: pcmk_host_map value: z1.example.com:1;z2.example.com:2 - name: login value: apc - name: passwd value: apc - id: my_lvm agent: ocf:heartbeat:LVM-activate instance_attrs: - attrs: - name: vgname value: my_vg - name: vg_access_mode value: system_id - id: my_fs agent: Filesystem instance_attrs: - attrs: - name: device value: /dev/my_vg/my_lv - name: directory value: /var/www - name: fstype value: xfs - id: VirtualIP agent: IPaddr2 instance_attrs: - attrs: - name: ip value: 198.51.100.3 - name: cidr_netmask value: 24 - id: Website agent: apache instance_attrs: - attrs: - name: configfile value: /etc/httpd/conf/httpd.conf - name: statusurl value: http://127.0.0.1/server-status ha_cluster_resource_groups: - id: apachegroup resource_ids: - my_lvm - my_fs - VirtualIP - Website
- 파일을 저장합니다.
1단계에서 생성한 인벤토리 파일 인벤토리 의 경로를 지정하여 플레이북을 실행합니다.
# ansible-playbook -i inventory http-cluster.yml
apache
리소스 에이전트를 사용하여 Apache를 관리하는 경우systemd
를 사용하지 않습니다. 따라서 Apache를 다시 로드하는 데systemctl
을 사용하지 않도록 Apache와 함께 제공된 10.0.0.1 스크립트를 편집해야 합니다.클러스터의 각 노드의
/etc/logrotate.d/httpd
파일에서 다음 행을 제거합니다./bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
RHEL 8.6 이상에서는 제거한 행을 다음 세 줄로 교체하여
/var/run/httpd-website.pid
를 PID 파일 경로로 지정합니다. 여기서 website 는 Apache 리소스의 이름입니다. 이 예에서 Apache 리소스 이름은website
입니다./usr/bin/test -f /var/run/httpd-Website.pid >/dev/null 2>/dev/null && /usr/bin/ps -q $(/usr/bin/cat /var/run/httpd-Website.pid) >/dev/null 2>/dev/null && /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd-Website.pid" -k graceful > /dev/null 2>/dev/null || true
RHEL 8.5 이하의 경우 제거한 행을 다음 세 줄로 교체합니다.
/usr/bin/test -f /run/httpd.pid >/dev/null 2>/dev/null && /usr/bin/ps -q $(/usr/bin/cat /run/httpd.pid) >/dev/null 2>/dev/null && /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /run/httpd.pid" -k graceful > /dev/null 2>/dev/null || true
검증 단계
클러스터의 노드 중 하나에서 클러스터 상태를 확인합니다. 4개의 리소스 모두 동일한 노드
z1.example.com
에서 실행되고 있습니다.구성한 리소스가 실행되고 있지 않은 경우
pcs resource debug-start resource명령을 실행하여 리소스
구성을 테스트할 수 있습니다.[root@z1 ~]# pcs status Cluster name: my_cluster Last updated: Wed Jul 31 16:38:51 2013 Last change: Wed Jul 31 16:42:14 2013 via crm_attribute on z1.example.com Stack: corosync Current DC: z2.example.com (2) - partition with quorum Version: 1.1.10-5.el7-9abe687 2 Nodes configured 6 Resources configured Online: [ z1.example.com z2.example.com ] Full list of resources: myapc (stonith:fence_apc_snmp): Started z1.example.com Resource Group: apachegroup my_lvm (ocf::heartbeat:LVM-activate): Started z1.example.com my_fs (ocf::heartbeat:Filesystem): Started z1.example.com VirtualIP (ocf::heartbeat:IPaddr2): Started z1.example.com Website (ocf::heartbeat:apache): Started z1.example.com
클러스터가 가동되어 실행되면 브라우저에서
IPaddr2
리소스로 정의한 IP 주소를 가리켜 간단한 단어 "Hello"로 구성된 샘플 디스플레이를 볼 수 있습니다.Hello
z1.example.com
에서 실행 중인 리소스 그룹이z2.example.com
노드로 장애 조치(failover)되는지 여부를 테스트하려면 노드z1.example.com
을 준비 모드로 배치한 후 노드가 더 이상 리소스를 호스팅할 수 없게 됩니다.[root@z1 ~]# pcs node standby z1.example.com
노드
z1
을일괄
모드로 전환한 후 클러스터의 노드 중 하나에서 클러스터 상태를 확인합니다. 이제 리소스가 모두z2
에서 실행되어야 합니다.[root@z1 ~]# pcs status Cluster name: my_cluster Last updated: Wed Jul 31 17:16:17 2013 Last change: Wed Jul 31 17:18:34 2013 via crm_attribute on z1.example.com Stack: corosync Current DC: z2.example.com (2) - partition with quorum Version: 1.1.10-5.el7-9abe687 2 Nodes configured 6 Resources configured Node z1.example.com (1): standby Online: [ z2.example.com ] Full list of resources: myapc (stonith:fence_apc_snmp): Started z1.example.com Resource Group: apachegroup my_lvm (ocf::heartbeat:LVM-activate): Started z2.example.com my_fs (ocf::heartbeat:Filesystem): Started z2.example.com VirtualIP (ocf::heartbeat:IPaddr2): Started z2.example.com Website (ocf::heartbeat:apache): Started z2.example.com
정의된 IP 주소에 있는 웹 사이트는 중단 없이 계속 표시되어야 합니다.
CloudEvent 모드에서
z1
을
제거하려면 다음 명령을 입력합니다.[root@z1 ~]# pcs node unstandby z1.example.com
참고reliability 모드에서 노드를
제거해
도 리소스가 해당 노드로 다시 장애 조치되지 않습니다. 이는 리소스의resource-stickiness
값에 따라 달라집니다.resource-stickiness
meta 속성에 대한 자세한 내용은 현재 노드를 선호하도록 리소스 구성을 참조하십시오.
25.11. 추가 리소스
- RHEL 시스템 역할을 사용하도록 컨트롤 노드 및 관리형 노드 준비
-
/usr/share/ansible/roles/
패키지로 설치된 문서rhel-system-roles
.logging/README.html에서 rhel-system-roles - RHEL System Roles KB 문서
-
ansible-playbook(1)
매뉴얼 페이지.
26장. RHEL 시스템 역할을 사용하여 웹 콘솔 설치 및 구성
cockpit
RHEL 시스템 역할을 사용하면 시스템에 웹 콘솔을 설치하고 구성할 수 있습니다.
26.1. cockpit
시스템 역할
cockpit
시스템 역할을 사용하여 웹 콘솔을 자동으로 배포 및 활성화하므로 웹 브라우저에서 RHEL 시스템을 관리할 수 있습니다.
26.2. cockpit
RHEL 시스템 역할의 변수
cockpit
RHEL 시스템 역할에 사용되는 매개변수는 다음과 같습니다.
역할 변수 | 설명 |
---|---|
cockpit_packages: (기본값: default) | 사전 정의된 패키지 세트 중 하나를 설정합니다(default, minimal 또는 full. * cockpit_packages: (기본값: default) - 가장 일반적인 페이지 및 온 디맨드 설치 UI * cockpit_packages: (기본값: minimal) - 개요, 터미널, 로그, 계정 및 지표 페이지만 지원합니다. 최소한의 종속성 * cockpit_packages: (기본값: full) - 사용 가능한 모든 페이지 필요한 경우 설치할 cockpit 패키지의 자체 선택을 지정합니다. |
cockpit_enabled: (default:true) | 부팅 시 웹 콘솔 웹 서버가 자동으로 시작되도록 설정 |
cockpit_started: (default:true) | 웹 콘솔을 시작해야 하는 경우 설정 |
cockpit_config: (기본값: nothing) |
|
cockpit_port: (기본값: 9090) | 웹 콘솔은 기본적으로 포트 9090에서 실행됩니다. 이 옵션을 사용하여 포트를 변경할 수 있습니다. |
cockpit_manage_firewall: (기본값: false) |
|
cockpit_manage_selinux: (default: false) |
|
cockpit_certificates: (기본값: nothing) |
|
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.cockpit/README.md
파일. - Cockpit 구성 파일 도움말 페이지.
26.3. cockpit
RHEL 시스템 역할을 사용하여 웹 콘솔 설치
cockpit
시스템 역할을 사용하여 RHEL 웹 콘솔을 설치하고 활성화할 수 있습니다.
기본적으로 RHEL 웹 콘솔은 자체 서명된 인증서를 사용합니다. 보안상의 이유로 신뢰할 수 있는 인증 기관에서 발급한 인증서를 지정할 수 있습니다.
이 예제에서는 cockpit
시스템 역할을 사용하여 다음을 수행합니다.
- RHEL 웹 콘솔을 설치합니다.
-
웹 콘솔에서
firewalld
를 관리하도록 허용합니다. -
자체 서명된 인증서를 사용하는 대신
ipa
신뢰할 수 있는 인증 기관의 인증서를 사용하도록 웹 콘솔을 설정합니다. - 사용자 지정 포트 9050을 사용하도록 웹 콘솔을 설정합니다.
방화벽을 관리하거나 인증서를 생성하기 위해 플레이북에서
시스템 역할을 호출할 필요가 없습니다. 방화벽
또는 인증서cockpit
시스템 역할은 필요에 따라 자동으로 호출합니다.
사전 요구 사항
- 하나 이상의 관리 노드에 대한 액세스 및 권한.
제어 노드에 대한 액세스 및 권한.
제어 노드에서 다음을 수행합니다.
- Red Hat Ansible Engine이 설치되어 있어야 합니다.
-
rhel-system-roles
패키지가 설치되어 있어야 합니다. - 관리 노드를 나열하는 인벤토리 파일이 있습니다.
절차
다음 내용으로 새
playbook.yml
파일을 생성합니다.--- - hosts: all tasks: - name: Install RHEL web console include_role: name: rhel-system-roles.cockpit vars: cockpit_packages: default #cockpit_packages: minimal #cockpit_packages: full cockpit_port:9050 cockpit_manage_selinux: true cockpit_manage_firewall: true cockpit_certificates: - name: /etc/cockpit/ws-certs.d/01-certificate dns: ['localhost', 'www.example.com'] ca: ipa group: cockpit-ws
선택 사항: 플레이북 구문 확인:
# ansible-playbook --syntax-check -i inventory_file playbook.yml
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
27장. podman RHEL 시스템 역할을 사용하여 컨테이너 관리
podman
RHEL 시스템 역할을 사용하면 Podman 컨테이너를 실행하는 Podman 구성, 컨테이너 및 systemd
서비스를 관리할 수 있습니다.
27.1. podman RHEL 시스템 역할
podman
RHEL 시스템 역할을 사용하여 Podman 컨테이너를 실행하는 Podman 구성, 컨테이너 및 systemd 서비스를 관리할 수 있습니다.
추가 리소스
- RHEL 시스템 역할 설치
-
podman
에 사용되는 매개변수 및podman
RHEL 시스템 역할에 대한 자세한 내용은/usr/share/ansible/roles/rhel-system-roles.podman/README.md
파일을 참조하십시오.
27.2. podman RHEL 시스템 역할의 변수
podman
RHEL 시스템 역할에 사용되는 매개변수는 다음과 같습니다.
Variable | 설명 |
---|---|
| podman 포드 및 관리할 해당 systemd 단위를 설명합니다.
|
|
true인 경우 역할은 참고 역할을 관리하려면 디렉터리를 절대 경로(루트 컨테이너의 경우) 또는 홈 디렉터리(루트가 아닌 컨테이너의 경우) 상대 경로로 지정해야 합니다. 다른 모든 것은 무시됩니다.
이 역할은 기본 소유권 또는 권한을 디렉터리에 적용합니다. 소유권 또는 권한을 설정해야 하는 경우 |
|
이는 dict입니다. |
| 이 목록은 dict 목록입니다. 방화벽에서 역할을 관리할 포트를 지정합니다. 방화벽 RHEL 시스템 역할에서 사용하는 것과 동일한 형식을 사용합니다. |
| 이 목록은 dict 목록입니다. 역할에서 사용하는 포트에 대한 SELinux 정책을 관리할 포트를 지정합니다. 이 명령은 selinux RHEL 시스템 역할에서 사용하는 것과 동일한 형식을 사용합니다. |
|
모든 rootless 컨테이너에 사용할 사용자의 이름을 지정합니다. 참고 사용자가 이미 있어야 합니다. |
|
모든 rootless 컨테이너에 사용할 그룹의 이름을 지정합니다. 참고 그룹이 이미 있어야 합니다. |
|
모든 |
|
|
|
|
|
|
|
|
추가 리소스
- RHEL 시스템 역할 설치
-
podman
에 사용되는 매개변수 및podman
RHEL 시스템 역할에 대한 자세한 내용은/usr/share/ansible/roles/rhel-system-roles.podman/README.md
파일을 참조하십시오.
27.3. 추가 리소스
-
podman
에 사용되는 매개변수 및podman
RHEL 시스템 역할에 대한 자세한 내용은/usr/share/ansible/roles/rhel-system-roles.podman/README.md
파일을 참조하십시오. -
ansible-playbook
명령에 대한 자세한 내용은ansible-playbook(1)
도움말 페이지를 참조하십시오.
28장. RHEL 시스템 역할을 사용하여 RHEL 시스템과 직접 AD와 통합
ad_integration
System 역할을 사용하면 Red Hat Ansible Automation Platform을 사용하여 RHEL 시스템을 AD(Active Directory)와 직접 통합할 수 있습니다.
이 장에서는 다음 주제를 다룹니다.
28.1. ad_integration
시스템 역할
ad_integration
시스템 역할을 사용하여 RHEL 시스템을 AD(Active Directory)에 직접 연결할 수 있습니다.
역할은 다음 구성 요소를 사용합니다.
- 중앙 ID 및 인증 소스와 상호 작용하기 위한 SSSD
-
realmd
: 사용 가능한 AD 도메인을 감지하고 기본 RHEL 시스템 서비스(이 경우 SSSD)를 구성하여 선택한 AD 도메인에 연결합니다.
ad_integration
역할은 IdM(Identity Management) 환경 없이 직접 AD 통합을 사용하는 배포를 위한 것입니다. IdM 환경의 경우 ansible-freeipa
역할을 사용하십시오.
추가 리소스
28.2. ad_integration
RHEL 시스템 역할의 변수
ad_integration
RHEL 시스템 역할은 다음 매개변수를 사용합니다.
역할 변수 | 설명 |
---|---|
ad_integration_realm | 연결할 Active Directory 영역 또는 도메인 이름입니다. |
ad_integration_password | 시스템을 영역에 결합할 때 인증에 사용되는 사용자의 암호입니다. 일반 텍스트는 사용하지 마십시오. 대신 Ansible Vault를 사용하여 값을 암호화합니다. |
ad_integration_manage_crypto_policies |
기본값: |
ad_integration_allow_rc4_crypto |
이 변수를 제공하면
기본값: |
ad_integration_timesync_source |
시스템 시계를 동기화하기 위한 시간 소스의 호스트 이름 또는 IP 주소입니다. 이 변수를 제공하면 |
추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.ad_integration/README.md
파일
28.3. ad_integration
시스템 역할을 사용하여 RHEL 시스템을 AD에 직접 연결
ad_integration
System Role을 사용하여 Ansible 플레이북을 실행하여 RHEL 시스템과 AD 도메인 간의 직접 통합을 구성할 수 있습니다.
RHEL8부터 RHEL은 기본적으로 RC4 암호화를 더 이상 지원하지 않습니다. AD 도메인에서 AES를 활성화할 수 없는 경우 AD-SUPPORT
암호화 정책을 활성화하고 플레이북에서 RC4 암호화를 허용해야 합니다.
RHEL 서버와 AD 사이의 시간을 동기화해야 합니다. 플레이북에서 timesync
시스템 역할을 사용하여 이를 확인할 수 있습니다.
이 예에서 RHEL 시스템은 AD Administrator
사용자와 Ansible 자격 증명 모음에 저장된 이 사용자의 암호를 사용하여 domain.example.com
AD 도메인에 결합합니다. Playbook은 또한 AD-SUPPORT
암호화 정책을 설정하고 RC4 암호화를 허용합니다. RHEL 시스템과 AD 간의 시간 동기화를 보장하기 위해 플레이북은 adserver.domain.example.com
서버를 timesync
소스로 설정합니다.
사전 요구 사항
- 하나 이상의 관리 노드에 대한 액세스 및 권한.
제어 노드에 대한 액세스 및 권한.
제어 노드에서 다음을 수행합니다.
- Red Hat Ansible Engine이 설치되어 있어야 합니다.
-
rhel-system-roles
패키지가 설치되어 있어야 합니다. - 관리 노드를 나열하는 인벤토리 파일.
AD 도메인 컨트롤러의 다음 포트는 열려 있으며 RHEL 서버에서 액세스할 수 있습니다.
표 28.1.
ad_integration
시스템 역할을 사용하여 Linux 시스템을 AD에 직접 통합하는 데 필요한 포트소스 포트 대상 포트 프로토콜 Service 1024:65535
53
UDP 및 TCP
DNS
1024:65535
389
UDP 및 TCP
LDAP
1024:65535
636
TCP
LDAPS
1024:65535
88
UDP 및 TCP
Kerberos
1024:65535
464
UDP 및 TCP
Kerberos 변경/설정 암호(
kadmin
)1024:65535
3268
TCP
LDAP 글로벌 카탈로그
1024:65535
3269
TCP
LDAP 글로벌 카탈로그 SSL/TLS
1024:65535
123
UDP
NTP/Chrony (선택 사항)
1024:65535
323
UDP
NTP/Chrony (선택 사항)
절차
다음 콘텐츠를 사용하여 새
ad_integration.yml
파일을 생성합니다.--- - hosts: all vars: ad_integration_realm: "domain.example.com" ad_integration_password: !vault | vault encrypted password ad_integration_manage_crypto_policies: true ad_integration_allow_rc4_crypto: true ad_integration_timesync_source: "adserver.domain.example.com" roles: - linux-system-roles.ad_integration ---
선택사항: 플레이북 구문 확인.
# ansible-playbook --syntax-check ad_integration.yml -i inventory_file
인벤토리 파일에서 플레이북을 실행합니다.
# ansible-playbook -i inventory_file /path/to/file/ad_integration.yml
검증
관리자와
같은 AD 사용자 세부 정보를 표시합니다.getent passwd administrator@ad.example.com administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash
28.4. 추가 리소스
-
/usr/share/ansible/roles/rhel-system-roles.ad_integration/README.md
파일 -
man ansible-playbook(1)