소개
Ansible이 올바르게 설치되어 있어도 잘못된 인벤토리, 인터프리터, 권한을 사용할 수 있습니다. 신뢰할 수 있는 프로젝트는 이러한 선택을 명시하고 실제 대상에서 그 효과를 확인합니다.
이 실습에서는 프로젝트 구성을 만들고, 로드된 값을 확인하며, 인벤토리를 통해 대상 Python을 설정하고, 준비된 두 SSH 노드에서 일반 실행과 명시적인 권한 상승을 비교합니다. 이 독립적인 환경에는 Ansible과 연결이 제공되므로 패키지를 설치하거나 SSH 서버를 변경할 필요가 없습니다.
프로젝트 구성 만들기 및 로드하기
이 단계에서는 프로젝트 구성을 만들고 Ansible이 실제로 이를 로드하는지 확인합니다.
앞선 실습에서 이미 Ansible을 설치했습니다. 이 독립적인 환경에서는 구성에 집중할 수 있도록 공용 과정 설치를 제공합니다. Terminal을 열고 작업 공간으로 이동하세요.
cd /home/labex/project
Ansible은 구성 파일 하나를 사용하며 ANSIBLE_CONFIG, 현재 디렉터리의 ansible.cfg, 사용자 홈 구성, 시스템 구성 순서로 처음 사용 가능한 파일을 선택합니다. 따라서 디렉터리를 바꾸면 로드되는 프로젝트 구성이 달라질 수 있습니다. 프로젝트 파일이 존재해도 환경 변수가 다른 파일을 선택할 수 있습니다.
준비된 connection-reference.cfg에는 원래의 교육용 연결 설정이 들어 있습니다. cat으로 내용을 표시합니다.
cat connection-reference.cfg
이 파일은 프로젝트 인벤토리와 신뢰할 수 있는 호스트 키 파일을 선택합니다. 실습에서 키와 노드를 이미 만들었으므로 플랫폼 로그인이나 SSH 서버를 변경하지 마세요.
아래와 같이 ansible.cfg를 만듭니다. cat >는 표준 입력을 파일에 쓰면서 기존 내용을 대체합니다. <<'EOF'는 히어 도큐먼트를 시작합니다. 마지막 EOF까지 모든 줄을 붙여 넣으세요. 구분자를 따옴표로 감싸면 텍스트가 문자 그대로 유지됩니다. 대괄호 안의 INI 섹션 이름은 설정을 묶으며 각 name = value 줄은 옵션을 설정합니다.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = /home/labex/project/inventory.ini
host_key_checking = True
interpreter_python = /usr/bin/python3
[privilege_escalation]
become = False
[ssh_connection]
ssh_args = -o UserKnownHostsFile=/home/labex/.local/share/ansible-course/known_hosts -o StrictHostKeyChecking=yes -o ControlMaster=auto -o ControlPersist=30s
EOF
inventory는 호스트 목록을 선택합니다. host_key_checking은 서버 신원 확인을 활성 상태로 유지합니다. interpreter_python은 컨트롤러 인터프리터가 아닌 기본 대상 Python을 설정합니다. become = False는 일반 태스크가 권한 상승 없이 실행되도록 합니다. 준비된 ssh_args는 교육용 known_hosts 파일을 사용하고 신뢰할 수 있는 키를 요구하며 수명이 짧은 SSH 연결을 재사용합니다.
버전 및 구성 정보를 표시합니다.
ansible --version
config file = /home/labex/project/ansible.cfg를 찾으세요. 이 실습에서 모듈 경로는 공용 과정 설치에 속합니다. 앞선 설치 실습에서는 별도의 학습자 환경을 사용했습니다.
ansible-config dump는 유효한 구성을 보여 줍니다. --only-changed는 기본값과 다른 설정만 표시하고 각 설정의 출처를 알려 줍니다.
ansible-config dump --only-changed
CONFIG_FILE() = /home/labex/project/ansible.cfg, 프로젝트의 DEFAULT_HOST_LIST, /usr/bin/python3로 설정된 INTERPRETER_PYTHON을 찾으세요. 출력에는 INI 표기와 다를 수 있는 내부 옵션 이름이 사용됩니다. 파일을 읽는 것만으로는 Ansible이 그 파일을 로드했음을 증명할 수 없습니다.
이미 알고 있는 Python ping 모듈로 프로젝트 구성을 테스트합니다.
ansible all -m ansible.builtin.ping
web1과 web2 모두 pong을 반환해야 합니다. 의도한 구성이 계속 활성화되도록 이 작업 공간에서 명령을 실행하세요.
인벤토리에서 대상 인터프리터 설정하기
이 단계에서는 두 호스트 모두에 연결 변수를 설정하고 프로젝트 기본값과의 관계를 이해합니다.
준비된 인벤토리를 읽습니다.
cat inventory.ini
이 파일에는 서로 다른 두 ansible_host 대상 뒤에 [all:vars]가 있습니다. 이 섹션 아래의 설정은 ansible_user=automation과 교육용 개인 키 경로를 포함하여 두 호스트 모두에 적용됩니다. 관리 노드의 SSH 계정과 인증을 설명하는 설정입니다.
ansible_python_interpreter라는 연결 변수는 해당 호스트에 대해 interpreter_python 구성 기본값을 덮어씁니다. 인벤토리에 특정 대상 인터프리터가 필요할 때 사용하세요. 인벤토리 변수가 존재하지 않는 실행 파일을 가리키면 올바른 기본값이 있어도 문제를 해결할 수 없습니다.
printf는 텍스트를 출력하며 \n은 줄바꿈을 뜻합니다. >>는 기존 인벤토리를 대체하지 않고 덧붙입니다. 기존 [all:vars] 섹션 아래에 인터프리터 변수를 추가합니다.
printf '\nansible_python_interpreter=/usr/bin/python3\n' >> inventory.ini
인벤토리를 다시 표시하고 [all:vars] 아래의 새 설정을 찾으세요.
cat inventory.ini
컨트롤러의 Python 설치는 그대로 유지됩니다. 이 경로는 각 관리 노드 내부에서 별도로 실행됩니다. 두 대상을 모두 테스트합니다.
ansible all -m ansible.builtin.ping
각 호스트는 여전히 pong과 changed: false를 반환해야 합니다. 이제 프로젝트 기본값뿐 아니라 작동하는 인벤토리별 인터프리터 설정도 갖추었습니다. 구성 출력은 기본값을 설명하며, 실행 시에는 연결 변수가 이를 덮어쓸 수 있습니다.
일반 실행과 권한 상승 실행 비교하기
이 단계에서는 명시적인 권한 상승 전후의 실제 원격 사용자를 관찰합니다.
command 모듈은 대상에서 프로그램을 실행합니다. -a는 모듈 인수를 제공합니다. 셸이 프로그램과 옵션을 하나의 인수 문자열로 전달하도록 id -un을 따옴표로 감싸세요. id -un은 유효 사용자 이름을 출력합니다.
ansible all -m ansible.builtin.command -a 'id -un'
두 호스트 모두 automation을 보고해야 합니다. 이는 인벤토리에서 선택한 관리 노드 계정이며 컨트롤러의 labex 사용자가 아닙니다.
--become은 이번 호출에 대한 권한 상승을 요청합니다. 교육용 노드는 automation 계정이 비밀번호 없이 sudo를 사용하도록 허용합니다. 프로젝트 기본값은 일반 실행에 대한 권한 상승을 여전히 비활성화합니다.
ansible all -m ansible.builtin.command -a 'id -un' --become
두 호스트 모두 root를 보고해야 합니다. Ansible의 command 모듈은 이러한 읽기 전용 신원 조회도 포함하여 명령을 실행할 때 보통 CHANGED를 보고합니다. 이 표시만으로 시스템 구성이 변경되었다고 볼 수는 없습니다. 실제 stdout과 반환 상태를 해석하세요.
--become 없이 다시 실행합니다.
ansible all -m ansible.builtin.command -a 'id -un'
출력은 다시 automation이 됩니다. 권한 상승은 로그인 계정을 영구 변경한 것이 아니라 한 번의 호출에 명시적으로 적용한 것입니다. 전역 권한 상승을 비활성 상태로 두고 플랫폼 계정 구성을 그대로 유지하세요.
요약
프로젝트 구성을 만들고 로드했으며 유효한 기본값을 점검하고 인벤토리를 통해 우선순위가 더 높은 대상 인터프리터를 제공했습니다. 실제 SSH 모듈 실행으로 두 대상을 확인했으며 신원 조회를 통해 일반 automation 접근과 명시적인 become의 차이를 확인했습니다. 이러한 확인은 플랫폼 접근을 변경하지 않고 연결 설정을 진단할 수 있는 기초가 됩니다.
