소개
두 Linux 서버를 관리할 Ansible 제어 노드를 준비하고 있습니다. 자동화를 작성하기 전에 예측 가능한 설치 환경을 갖추고 컨트롤러가 두 대상 모두에서 Python 모듈을 실행할 수 있는지 확인해야 합니다.
이 실습에서는 프로젝트 가상 환경을 만들고, 오프라인 패키지 캐시에서 Ansible Core를 설치한 다음, Terminal에서 활성화하고 제공된 인벤토리로 두 실제 SSH 연결을 테스트합니다. 기본적인 명령줄 사용 지식만 있으면 되며 Ansible 경험은 필요하지 않습니다.
격리된 컨트롤러 환경 만들기
이 단계에서는 직접 설치할 Ansible을 담을 Python 환경을 만듭니다.
Ansible은 제어 노드에서 실행되며 SSH를 통해 관리 노드에 연결합니다. LabEx Terminal은 Ubuntu 제어 노드입니다. 미리 준비된 두 Linux 컨테이너 web1과 web2는 서로 별개의 관리 노드 역할을 합니다. 주소, 호스트 이름, 파일 시스템은 다르지만 VM의 커널을 공유합니다. Docker 명령을 사용하거나 플랫폼 로그인 설정을 변경할 필요는 없습니다.
Python 가상 환경은 프로젝트 패키지를 운영 체제 및 공용 과정 도구와 분리합니다. 이미지에는 기반 환경용 공용 Ansible 명령이 이미 있지만, 여러분의 작업은 /home/labex/project/.venv에 별도의 사본을 설치하는 것입니다.
Terminal을 여세요. cd를 사용하여 프로젝트 디렉터리로 이동합니다. 이후의 상대 경로는 이 디렉터리를 기준으로 해석됩니다.
cd /home/labex/project
pwd는 현재 작업 디렉터리를 출력합니다.
pwd
출력은 /home/labex/project여야 합니다. 실습 내내 이 디렉터리를 계속 사용하세요.
ansible-python은 과정에서 준비한 Python을 선택합니다. --version은 버전을 표시합니다.
ansible-python --version
Python 3.12.15가 출력되어야 합니다. 제어 노드의 시스템 Python은 별도로 유지되므로 바꾸지 마세요.
-m venv 옵션은 Python의 가상 환경 모듈을 실행합니다. 마지막 인수 .venv는 프로젝트 안에 만들 디렉터리 이름입니다. 이름 앞의 점은 일반적인 디렉터리 목록에서 숨겨지게 합니다.
ansible-python -m venv .venv
보통 출력 없이 완료됩니다. 이 명령은 환경과 Python 패키지 설치 도구인 pip를 만들지만, 아직 Ansible을 설치하지는 않습니다.
상대 경로를 사용하여 새 환경의 Python을 실행합니다. 이를 통해 먼저 활성화하지 않아도 격리된 인터프리터를 사용할 수 있음을 확인합니다.
.venv/bin/python --version
이 명령도 Python 3.12.15를 출력해야 합니다. 두 Python 명령은 같은 Python 릴리스를 사용하지만, .venv에 설치한 패키지는 이 프로젝트에 속합니다.
오프라인으로 Ansible 설치 및 활성화하기
이 단계에서는 버전이 고정된 Ansible Core 릴리스를 .venv에 설치하고 Terminal이 이를 사용하도록 설정합니다.
Ansible Core는 이 과정에서 사용하는 ansible 명령과 내장 모듈을 제공합니다. 미리 준비된 wheel 파일은 로컬 Python 패키지이므로 인터넷 다운로드에 의존하지 않고 설치할 수 있습니다. requirements 파일은 서로 호환되는 고정 버전을 지정합니다.
다음 명령은 프로젝트 Python으로 pip를 실행합니다. install은 패키지를 설치하고, --no-index는 온라인 패키지 인덱스를 비활성화하며, --find-links는 로컬 wheel 디렉터리를 선택하고, -r은 requirements 파일을 읽습니다.
.venv/bin/python -m pip install --no-index --find-links /opt/labex/ansible-course/wheels -r /opt/labex/ansible-course/requirements.txt
출력에는 로컬 캐시에서 처리한 패키지 목록이 표시되며, ansible-core-2.21.5를 포함하는 Successfully installed ...로 끝납니다. 다시 설치하면 대신 Requirement already satisfied가 표시될 수 있습니다.
활성화는 이 셸의 검색 경로 맨 앞에 환경의 명령 디렉터리를 배치합니다. source는 현재 Terminal에서 활성화 스크립트를 실행하므로 이후 명령에도 변경 사항이 유지됩니다.
source .venv/bin/activate
이제 프롬프트가 (.venv)로 시작할 수 있습니다. Terminal은 zsh를 사용합니다. rehash는 새 실행 파일을 설치한 후 캐시된 명령 위치를 새로 고칩니다.
rehash
command -v는 명령 이름으로 선택되는 실행 파일을 보여 줍니다.
command -v ansible
/home/labex/project/.venv/bin/ansible이 출력되어야 합니다. /usr/local/bin/ansible 같은 공용 경로는 프로젝트 설치가 활성화되었음을 증명하지 못합니다. 새 Terminal을 열면 프로젝트로 돌아와 다시 활성화하고 rehash를 실행하세요.
이제 실행 중인 Ansible 버전을 확인합니다.
ansible --version
출력에서 다음 필드를 찾으세요.
ansible [core 2.21.5]
config file = /home/labex/project/ansible.cfg
...
ansible python module location = /home/labex/project/.venv/lib/python3.12/site-packages/ansible
executable location = /home/labex/project/.venv/bin/ansible
python version = 3.12.15 ...
...
실행 파일과 모듈 경로는 프로젝트에 설치한 버전을 실행하고 있음을 보여 줍니다. 구성 파일은 실습에서 제공합니다. 다음 역량 학습 묶음에서 이를 구성하는 방법을 배웁니다.
마지막으로 pip의 check 명령으로 설치된 패키지 의존성이 호환되는지 테스트합니다.
.venv/bin/python -m pip check
No broken requirements found.가 출력되어야 합니다. 이제 시스템 패키지나 공용 도구 모음을 변경하지 않고도 작동하는 컨트롤러를 갖추었습니다.
두 관리 노드 모두에 연결하기
이 단계에서는 준비된 인벤토리를 살펴보고 두 SSH 대상 모두에서 Python 기반 연결 테스트를 실행합니다.
인벤토리는 Ansible이 관리할 수 있는 호스트를 알려 줍니다. cat은 파일 내용을 출력합니다. 제공된 프로젝트 인벤토리를 읽어 보세요.
cat inventory.ini
형식은 다음과 같습니다.
web1 ansible_host=...
web2 ansible_host=...
[all:vars]
ansible_user=automation
ansible_ssh_private_key_file=/home/labex/.local/share/ansible-course/id_ed25519
ansible_python_interpreter=/usr/bin/python3
실제 주소는 ... 자리에 있으므로 기존 값을 사용하세요. web1과 web2는 인벤토리 이름이고, ansible_host는 각 SSH 접속 대상을 지정합니다. [all:vars]는 그 아래 연결 설정을 두 호스트 모두에 적용합니다. automation은 관리 노드 내부의 일반 계정이며 제어 노드의 labex 로그인 계정과는 다릅니다. 실습에서 새로운 교육용 키와 신뢰할 수 있는 호스트 키를 제공하므로 키를 생성하거나 SSH 설정을 바꿀 필요가 없습니다.
대상 Python 경로 /usr/bin/python3는 각 관리 노드에 속합니다. 컨트롤러의 프로젝트 Python과는 다릅니다. 대부분의 Ansible 모듈은 컨트롤러뿐 아니라 대상에도 Python이 있어야 합니다.
제공된 ansible.cfg는 프로젝트에서 명령을 실행할 때 이 인벤토리를 선택합니다. all은 모든 인벤토리 호스트를 선택하며, --list-hosts는 모듈을 실행하지 않고 선택 결과를 미리 보여 줍니다.
ansible all --list-hosts
정확히 다음 두 호스트 이름이 표시되어야 합니다. 순서는 다를 수 있습니다.
hosts (2):
web1
web2
-m 옵션은 Ansible 작업 단위인 모듈을 선택합니다. ansible.builtin.ping은 내장 ping 모듈의 정규화된 전체 이름입니다. 이 모듈은 SSH로 연결하여 각 대상에서 Python을 실행하며, 네트워크 ICMP ping과는 다릅니다.
ansible all -m ansible.builtin.ping
두 호스트 모두 다음과 같은 고정 필드가 포함된 결과를 반환해야 합니다. 결과 순서는 다를 수 있습니다.
web1 | SUCCESS => {
"changed": false,
"ping": "pong"
}
web2 | SUCCESS => {
"changed": false,
"ping": "pong"
}
pong은 해당 호스트에서 SSH 인증과 대상 Python 실행에 성공했음을 증명합니다. changed: false는 이 연결 테스트가 구성 변경을 요청하지 않았음을 뜻합니다. 한 호스트만 성공해서는 충분하지 않습니다. 두 이름이 모두 있는지 확인하세요. UNREACHABLE은 연결 실패를, FAILED는 태스크 실패를 뜻합니다. 빈 호스트 목록으로도 연결 가능 여부를 증명할 수 없습니다.
명령이 실패하면 먼저 여전히 프로젝트 디렉터리에 있는지, command -v ansible이 .venv/bin/ansible을 선택하는지, 제공된 인벤토리에 원래의 두 대상이 여전히 포함되어 있는지 확인하세요. 플랫폼의 로그인, SSH, sudo 구성은 그대로 유지하세요.
요약
격리된 컨트롤러 환경을 만들고, 오프라인 캐시에서 버전이 고정된 Ansible Core 패키지를 설치했으며, 프로젝트 명령을 활성화하고 경로와 의존성을 확인했습니다. 제공된 인벤토리를 읽고 서로 다른 각 SSH 관리 노드로부터 Python pong 응답을 받았습니다. 이제 프로젝트 구성을 배우기에 앞서 컨트롤러 Python, 대상 Python, 인벤토리 이름을 구분할 수 있습니다.
