26M25c

Young-Kyoo Kim·2026년 3월 26일

처음 AWX를 접하시면 용어와 설정 순서 때문에 막막하실 수 있습니다. 하지만 말씀하신 "Bitbucket(코드) → Credential(권한) → Project(연결) → Inventory(대상) → Template(실행)" 흐름이 정확합니다.

요청하신 내용을 바탕으로 가장 쉬운 Getting Started 가이드를 step-by-step으로 정리해 드립니다.

Step 1: Bitbucket에 코드 준비 (준비물)

Bitbucket 레포지토리 최상위에 아래 두 파일을 만드세요.

1. inventory.yml (대상 서버 목록)

all:
  hosts:
    minio-node-01:
      ansible_host: 192.168.1.10  # 실제 IP로 변경
    minio-node-02:
      ansible_host: 192.168.1.11

2. check_all.yml (실행할 작업)

---
- name: OS 및 서비스 상태 점검
  hosts: all
  gather_facts: yes
  tasks:
    - name: 1. OS 정보 및 시간 출력
      debug:
        msg: "OS: {{ ansible_distribution }} {{ ansible_distribution_version }}, Time: {{ ansible_date_time.iso8601 }}"

    - name: 2. MinIO 상태 확인 (mc admin info)
      shell: "mc admin info myminio"
      register: mc_out
    - debug: var=mc_out.stdout_lines

    - name: 3. K8s 노드 확인 (kubectl get node)
      shell: "kubectl get node"
      register: k8s_out
    - debug: var=k8s_out.stdout_lines

Step 2: AWX 설정 (등록 과정)

① 자격 증명(Credentials) 등록

AWX 왼쪽 메뉴 Resources > Credentials에서 3개를 만듭니다.
1. Bitbucket용: Type을 Source Control로 선택하고 ID/PW(또는 App Password) 입력.
2. 서버 접속용: Type을 Machine으로 선택하고 서버 SSH ID와 Private Key 입력.
3. K8s용: Type을 OpenShift or Kubernetes API로 선택하고 Kubeconfig 내용 입력.

② 프로젝트(Project) 등록

Bitbucket과 AWX를 연결합니다.
1. Resources > Projects > Add 클릭.
2. SCM Type: Git 선택.
3. SCM URL: Bitbucket 레포지토리 주소 입력.
4. Credential: 위에서 만든 Bitbucket용 선택 후 저장. (싱크가 성공하면 초록불이 들어옵니다.)

③ 인벤토리(Inventory) 등록

파일에서 서버 목록을 긁어옵니다.
1. Resources > Inventories > Add > Add inventory (이름 입력 후 저장).
2. 상단 Sources 탭 클릭 > Add 클릭.
3. Source: Sourced from a Project 선택.
4. Project: 위에서 만든 프로젝트 선택.
5. Inventory file: inventory.yml 선택 후 저장 및 Sync 클릭.

Step 3: Execution Environment (EE) 만들기

mc나 kubectl 같은 도구는 일반적인 앤서블 환경에 없습니다. 따라서 이 도구들이 들어있는 샌드박스(EE)를 만들어야 합니다.

1. 빌드 파일 준비 (로컬 PC나 빌드 서버)

execution-environment.yml 파일을 만듭니다.

version: 3
images:
  base_image:
    name: quay.io/ansible/ansible-runner:latest
additional_build_steps:
  append_base:
    - RUN curl https://dl.min.io/client/mc/release/linux-amd64/mc -o /usr/local/bin/mc && chmod +x /usr/local/bin/mc
    - RUN curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" && install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

2. 빌드 및 등록

  1. 명령어 실행: ansible-builder build -t my-custom-ee:v1
  2. 생성된 이미지를 도커 허브나 사내 레지스트리에 push.
  3. AWX UI: Administration > Execution Environments에서 해당 이미지 주소를 등록.

Step 4: 실행 (Job Template)

마지막으로 모든 것을 조립합니다.

  1. Resources > Templates > Add > Add job template.
  2. Inventory: 등록한 인벤토리 선택.
  3. Project: 등록한 프로젝트 선택.
  4. Playbook: check_all.yml 선택.
  5. Credentials: 서버 접속용(Machine)과 K8s용Credential 두 개 모두 선택.
  6. Execution Environment: 위 Step 3에서 만든 EE 선택.

이제 Launch 버튼을 누르면 Bitbucket에서 최신 코드를 가져와, 지정된 서버들에 접속하여 OS 정보를 뿌려주고, EE 안의 mc와 kubectl을 이용해 상태를 점검합니다.

다음으로 무엇을 도와드릴까요?

  • "EE 빌드 중에 에러가 나는데 어떻게 보나요?"
  • "Bitbucket에 푸시하면 자동으로 실행되게(Webhook) 하고 싶어요."

==

네, 정확한 질문입니다! ansible-builder의 정체와 동작 원리를 이해하면 EE(Execution Environment)를 자유자재로 다루실 수 있습니다. 궁금하신 내용을 하나씩 파헤쳐 드릴게요.

1. ansible-builder는 Python 패키지인가요?

네, 맞습니다. ansible-builder는 Python으로 작성된 도구이며, pip를 통해 설치합니다.

  • 설치 방법: pip install ansible-builder
  • 역할: 사용자가 읽기 쉬운 execution-environment.yml 파일을 작성하면, 이를 해석해서 복잡한 Dockerfile을 자동으로 생성하고 컨테이너 이미지(Docker 또는 Podman용)로 빌드해주는 "빌드 자동화 도구"입니다.

2. ansible-builder build -t my-custom-ee:v1의 의미

이 명령어는 컨테이너 이미지를 만드는 표준 명령어와 매우 유사합니다.

  • build: 이미지를 생성하라는 명령입니다.
  • -t (Tag): 생성될 이미지에 이름을 붙이는 옵션입니다.
  • my-custom-ee:v1: 이미지의 이름(my-custom-ee)과 버전 태그(v1)입니다.
    • 나중에 AWX에 이 이름을 등록해야 AWX가 "아, 이 샌드박스를 쓰면 되는구나!"라고 인식합니다.

3. execution-environment.yml을 어떻게 인지하나요?

ansible-builder는 명령어를 실행하는 현재 디렉토리에서 execution-environment.yml이라는 이름의 파일을 기본값으로 찾습니다.

빌드 과정 (내부 메커니즘):
1. 파일 로드: 실행 위치에 있는 execution-environment.yml을 읽습니다.
2. 임시 파일 생성: 이 설정 파일을 바탕으로 context라는 임시 폴더를 만들고, 그 안에 실제 빌드에 필요한 Dockerfile을 자동으로 작성합니다.
3. 컨테이너 엔진 호출: 시스템에 설치된 Docker 또는 Podman에게 "자, 내가 만든 이 Dockerfile로 이미지를 구워줘!"라고 요청합니다.
4. 이미지 완성: 최종적으로 my-custom-ee:v1이라는 이미지가 로컬 이미지 저장소에 저장됩니다.

4. Step-by-Step: EE 빌드부터 AWX 등록까지

실제로 따라 하실 수 있게 순서를 정리해 드릴게요.

Step 1: 환경 준비 (로컬 PC 혹은 빌드용 리눅스)

# 1. ansible-builder 설치
pip install ansible-builder

# 2. Docker 또는 Podman이 설치되어 있어야 합니다.
docker --version

Step 2: 설정 파일 작성

폴더를 하나 만들고 그 안에 execution-environment.yml 파일을 만듭니다. (이전에 드린 내용을 복사해서 붙여넣으세요.)

Step 3: 빌드 실행

# 해당 폴더 안에서 실행
ansible-builder build -t my-custom-ee:v1

Step 4: 이미지 푸시 (Push)

AWX가 이 이미지를 가져가려면 사내 레지스트리(예: Harbor)나 Docker Hub에 올려야 합니다.

docker tag my-custom-ee:v1 my-registry.com/my-custom-ee:v1
docker push my-registry.com/my-registry/my-custom-ee:v1

Step 5: AWX에 등록

  1. AWX 메뉴: Administration > Execution Environments > Add.
  2. Name: MinIO-K8s-Check-EE (자유롭게 입력).
  3. Image: my-registry.com/my-registry/my-custom-ee:v1 (방금 푸시한 주소).
  4. Pull: Always (이미지가 바뀌었을 때를 대비해 항상 새로 가져오도록 설정).

💡 한 줄 요약

ansible-builder는 "내가 원하는 도구(mc, kubectl)가 들어있는 커스텀 샌드박스 설계도(yml)를 실제 컨테이너 이미지로 구워주는 요리사"라고 생각하시면 됩니다.

다음으로 execution-environment.yml 파일 안에 ansible.builtin 모듈 외에 특정 collection이나 python 패키지를 추가하는 방법도 알려드릴까요? (MinIO 연동 시 community.general 같은 컬렉션이 필요할 수 있습니다.)

==

RHEL 10 기반의 최신 Cloud Native 환경(Cilium, K8s, MinIO AIStor)에서 운영하신다면, 단순히 mc나 kubectl만 있는 수준을 넘어 네트워크 디버깅, 스토리지 성능 측정, 보안 점검 도구가 포함된 전형적인(Robust) EE 구성이 필요합니다.

특히 RHEL 10은 최신 라이브러리를 사용하므로, 베이스 이미지 선택과 도구 설치 방식이 중요합니다.

1. 전형적인 Cloud Native 점검용 execution-environment.yml

이 구성은 OS 점검, Cilium 네트워크 확인, MinIO 상태 분석, 그리고 성능 측정을 위한 도구들을 모두 포함합니다.

version: 3

images:
  base_image:
    name: quay.io/ansible/ansible-runner:latest # 또는 rhel9/ansible-runner (RHEL 환경 호환)

dependencies:
  ansible_core:
    package_pip: ansible-core>=2.15.0
  ansible_network:
    collections:
      - kubernetes.core      # K8s 모듈
      - community.general    # 각종 시스템/파일 모듈
      - amazon.aws           # S3 호환 API 테스트용
  system:
    - python3-pip
    - iputils              # ping 등
    - bind-utils           # nslookup, dig (DNS 점검)
    - jq                   # JSON 파싱 (필수)
    - tar
    - unzip
  python:
    - kubernetes           # ansible k8s 모듈 의존성
    - openshift
    - pyyaml
    - boto3                # MinIO S3 API 테스트용

additional_build_steps:
  append_base:
    # 1. MinIO 클라이언트 (mc) 설치
    - RUN curl https://dl.min.io/client/mc/release/linux-amd64/mc -o /usr/local/bin/mc && chmod +x /usr/local/bin/mc
    
    # 2. kubectl 설치
    - RUN curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" && install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
    
    # 3. Cilium CLI 설치 (네트워크 점검용)
    - RUN CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) && curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz && tar xzvf cilium-linux-amd64.tar.gz -C /usr/local/bin && rm cilium-linux-amd64.tar.gz
    
    # 4. DirectPV CLI 설치
    - RUN curl -L https://github.com/minio/directpv/releases/latest/download/directpv_linux_amd64 -o /usr/local/bin/kubectl-directpv && chmod +x /usr/local/bin/kubectl-directpv

    # 5. 성능 측정 도구 (선택 사항: 사전 점검 시 Disk I/O 확인용)
    - RUN dnf install -o tsflags=nodocs -y fio smartmontools && dnf clean all

2. 이 EE가 제공하는 주요 점검 능력

이렇게 구성된 EE를 AWX에 등록하면 플레이북에서 다음과 같은 고수준 점검이 가능해집니다.

  • OS/Kernel 점검 (RHEL 10): fio를 이용해 DirectPV가 사용할 디스크의 Raw 성능(IOPS/Latency)을 사전에 측정하여 성능 병목을 예방합니다. smartmontools로 디스크 수명을 체크합니다.
  • 네트워크 점검 (Cilium): cilium connectivity test나 cilium status를 셸로 호출하여 노드 간 통신 및 eBPF 기반 네트워크가 정상인지 확인합니다.
  • K8s/DirectPV 점검: kubectl directpv list drives 명령으로 가용 드라이브 상태를 확인하고, kubernetes.core 모듈을 이용해 Pod 상태를 선언적으로 관리합니다.
  • MinIO AIStor 점검: mc admin info는 기본이며, boto3를 이용해 실제 데이터 업로드/다운로드 지연 시간을 Python 스크립트로 정밀 측정할 수 있습니다.

3. 빌드 및 등록 시 주의사항 (RHEL 10 대응)

  1. 이미지 태깅: 빌드 시 날짜를 포함하면 관리가 쉽습니다.
    ansible-builder build -t my-aistor-ee:20260326
  2. RHEL 호스트 권한: mc나 kubectl 실행 시 /root/.mc나 ~/.kube/config 파일을 찾게 되는데, AWX는 Credentials 메뉴에서 등록한 정보를 EE 내부의 /runner 경로에 임시로 매핑해줍니다. 따라서 플레이북 작성 시 경로를 하드코딩하지 않는 것이 좋습니다.
  3. Cilium 연동: Cilium 점검을 위해서는 EE가 실행되는 노드가 K8s 클러스터에 접근 권한이 있어야 하므로, AWX에서 Kubernetes Credential을 반드시 해당 Template에 연결해줘야 합니다.

다음 단계 제안

이 EE를 사용하여 "Cilium 네트워크 상태와 MinIO 디스크 I/O 성능을 한꺼번에 점검하는 통합 플레이북" 예시를 만들어 드릴까요? 아니면 AWX에서 이 EE를 등록할 때 발생하는 흔한 오류 해결 방법을 알려드릴까요?

===

RHEL 10, Cilium, 그리고 DirectPV 기반의 MinIO AIStor 환경을 위한 통합 상태 점검(Unified Health Check) 플레이북 예시를 작성해 드립니다.

이 플레이북은 앞서 만든 Custom EE에 포함된 cilium, kubectl-directpv, fio, mc 도구들을 한꺼번에 활용하여 인프라의 전체적인 건강 상태를 진단합니다.

통합 점검 플레이북 (playbooks/unified_health_check.yml)

---
- name: "Cloud Native 인프라 통합 상태 점검 (Cilium, DirectPV, MinIO)"
  hosts: aistor_nodes
  gather_facts: yes
  vars:
    # 성능 측정 기준값 (필요에 따라 조정)
    fio_test_size: "1G"
    fio_target_path: "/var/lib/directpv/mnt" # DirectPV 관리 경로 예시
    minio_alias: "myminio"

  tasks:
    # 1. Cilium 네트워크 상태 점검 (Cilium CLI 사용)
    - name: "[Network] Cilium 에이전트 상태 및 연결성 확인"
      shell: "cilium status --brief"
      register: cilium_status
      changed_when: false
      failed_when: "'OK' not in cilium_status.stdout"

    - name: "[Network] 노드 간 통신 지연 시간(Latency) 테스트"
      shell: "cilium connectivity test --count 1"
      register: cilium_conn
      ignore_errors: yes # 전체 중단을 막기 위해 에러 무시 설정 가능

    # 2. DirectPV 및 디스크 I/O 성능 점검 (fio 사용)
    - name: "[Storage] DirectPV 드라이브 목록 및 상태 조회"
      shell: "kubectl directpv list drives --format json"
      register: directpv_list
      delegate_to: localhost # K8s 컨트롤러 권한 필요
      changed_when: false

    - name: "[Storage] 디스크 I/O 성능 측정 (Random Write/Read)"
      shell: |
        fio --name=test --ioengine=libaio --direct=1 --group_reporting \
        --runtime=10 --time_based --rw=randrw --rwmixwrite=50 \
        --bs=4k --size={{ fio_test_size }} --numjobs=1 \
        --filename={{ item.path }}/test_file --output-format=json
      loop: "{{ (directpv_list.stdout | from_json) | selectattr('node', 'equalto', inventory_hostname) | list }}"
      register: fio_results
      ignore_errors: yes # 실제 데이터 영역일 경우 주의 필요

    # 3. MinIO 서비스 및 클러스터 점검 (mc 사용)
    - name: "[MinIO] AIStor 클러스터 헬스 체크"
      shell: "mc admin info {{ minio_alias }} --json"
      register: minio_info
      changed_when: false

    # 4. 결과 요약 보고 (AWX Output 창에 보기 좋게 출력)
    - name: "점검 결과 요약 리포트"
      debug:
        msg:
          - "-----------------------------------------------------"
          - "Node: {{ inventory_hostname }}"
          - "Cilium Status: {{ cilium_status.stdout }}"
          - "MinIO Version: {{ (minio_info.stdout | from_json).info.version }}"
          - "Storage Quorum: {{ (minio_info.stdout | from_json).info.backend.online_disks }}/{{ (minio_info.stdout | from_json).info.backend.total_disks }} Online"
          - "Disk Performance (IOPS): {{ fio_results.results | map(attribute='stdout') | map('from_json') | map(attribute='jobs') | flatten | map(attribute='mixed') | map(attribute='iops') | list }}"
          - "-----------------------------------------------------"

이 플레이북의 주요 포인트

  1. Cilium CLI 활용: cilium status를 통해 eBPF 네트워크 에이전트가 정상인지 가장 먼저 확인합니다. 네트워크가 불안정하면 MinIO 클러스터의 데이터 동기화(IAM broadcast) 등에 문제가 생기기 때문입니다.
  2. DirectPV 연계: kubectl directpv list 결과에서 현재 호스트(inventory_hostname)에 해당하는 드라이브 경로만 골라내어 성능 테스트를 수행합니다.
  3. fio 성능 측정: 단순한 '동작 여부'를 넘어, 실제 IOPS와 Latency를 측정합니다. Cloud Native 환경에서는 특정 노드의 디스크 성능 저하가 전체 클러스터의 테일 레이턴시(Tail Latency)를 유발하므로 매우 중요한 점검 항목입니다.
  4. JSON 데이터 처리: 모든 도구(mc, kubectl, fio)의 출력을 --json으로 받아 Ansible의 from_json 필터로 파싱합니다. 이를 통해 AWX 로그에서 수치 데이터를 정확하게 관리할 수 있습니다.

AWX에서 실행할 때 설정 팁

  • Credentials: 이 템플릿에는 Machine(SSH) 자격 증명과 Kubernetes API 자격 증명이 모두 연결되어 있어야 합니다. (Cilium과 DirectPV는 K8s API를 사용하고, fio는 노드 직접 접속을 사용하기 때문입니다.)
  • Execution Environment: 앞서 만든 커스텀 EE를 반드시 선택해야 cilium, fio, mc 명령어를 인식합니다.
  • Limit: 특정 노드만 점검하고 싶을 때는 AWX 실행 시 Limit 칸에 노드 이름을 적어 실행하세요.

이 플레이북을 Bitbucket에 올리고 AWX에서 실행해 보시면, 인프라의 모든 계층(네트워크-스토리지-애플리케이션)을 한 번에 스캔하는 강력한 도구가 될 것입니다.

혹시 이 플레이북의 실행 결과(JSON) 중에서 특정 수치(예: IOPS가 1000 이하일 때)가 낮으면 알람을 보내는 로직을 추가하고 싶으신가요?

==

Machine(SSH) Credential과 네트워크 성능 테스트 도구 추가에 대해 명확히 정리해 드립니다.

1. Machine(SSH) Credential 대상은 누구여야 하나요?

결론부터 말씀드리면, 점검하고 싶은 '모든 노드'에 접속할 수 있어야 합니다.

  • Control-plane만 등록하면 안 되나요?: 만약 플레이북의 hosts: aistor_nodes에 워커 노드(Worker Nodes)들이 포함되어 있다면, AWX는 각 워커 노드에 직접 SSH 접속을 시도합니다. 따라서 Control-plane 한 대만으로는 부족합니다.
  • 권장 설정:
    1. 모든 노드(Control-plane + Worker)에 동일한 SSH 키를 심어둡니다.
    2. AWX에는 그 키를 이용하는 하나의 Machine Credential만 만듭니다.
    3. 플레이북 실행 시 이 Credential을 선택하면, AWX가 인벤토리에 적힌 모든 IP로 해당 키를 사용해 알아서 접속합니다.

2. EE에 네트워크 성능 테스트 도구 추가 (iperf3, qperf)

Cloud Native 환경에서 노드 간 대역폭과 지연시간을 측정하기 위해 가장 표준적인 iperf3와 qperf를 추가합니다. execution-environment.yml의 append_base 부분을 다음과 같이 업데이트하세요.

    # 5. 성능 및 네트워크 측정 도구 추가
    - RUN dnf install -o tsflags=nodocs -y fio smartmontools iperf3 qperf && dnf clean all

3. 통합 플레이북 업데이트 (네트워크 성능 테스트 포함)

이제 iperf3를 사용하여 노드 간 실제 처리량(Throughput)을 측정하는 로직을 추가한 플레이북 예시입니다.

---
- name: "인프라 통합 점검 (네트워크 성능 포함)"
  hosts: aistor_nodes
  gather_facts: yes
  vars:
    minio_alias: "myminio"
    iperf_duration: 5  # 테스트 시간(초)

  tasks:
    # [네트워크 점검 추가] iperf3를 이용한 대역폭 측정
    # 한 노드를 서버로, 다른 노드를 클라이언트로 써야 하므로 간단히 self-test 방식으로 예시를 듭니다.
    - name: "[Network] iperf3 서버 실행 (백그라운드)"
      shell: "iperf3 -s -D"
      ignore_errors: yes

    - name: "[Network] 노드 간 대역폭 측정 (TCP)"
      shell: "iperf3 -c {{ groups['aistor_nodes'][0] }} -t {{ iperf_duration }} --json"
      register: iperf_raw
      failed_when: false

    # [Cilium 점검]
    - name: "[Network] Cilium 에이전트 상태 확인"
      shell: "cilium status --brief"
      register: cilium_status
      changed_when: false

    # [MinIO 점검]
    - name: "[MinIO] AIStor 클러스터 헬스 체크"
      shell: "mc admin info {{ minio_alias }} --json"
      register: minio_info
      changed_when: false

    # [결과 출력]
    - name: "최종 통합 리포트"
      debug:
        msg:
          - "-----------------------------------------------------"
          - "Node: {{ inventory_hostname }}"
          - "Cilium: {{ cilium_status.stdout }}"
          - "Network Throughput: {{ (iperf_raw.stdout | from_json).end.sum_received.bits_per_second | default(0) / 1024/1024 | round(2) }} Mbps"
          - "MinIO Drive Status: {{ (minio_info.stdout | from_json).info.backend.online_disks }} Online"
          - "-----------------------------------------------------"

    - name: "[Cleanup] iperf3 서버 종료"
      shell: "pkill iperf3"
      ignore_errors: yes

💡 운영 시 주의사항 (Cilium 환경)

  1. Cilium Policy: 만약 Cilium에서 강력한 Network Policy를 적용 중이라면, iperf3가 사용하는 포트(기본 5201)를 허용해 주어야 테스트가 성공합니다.
  2. qperf 사용: 만약 eBPF가 적용된 네트워크의 아주 미세한 지연시간(Latency)을 측정하고 싶다면 플레이북에서 qperf 명령어를 사용하여 tcp_lat를 측정하는 것도 좋은 방법입니다.
  3. Localhost 제어: kubectl이나 cilium cli를 실행할 때, 노드에 직접 접속해서 실행할 수도 있지만 AWX 실행 환경(EE) 자체에서 k8s API로 던지는 것이 더 깔끔할 때가 많습니다. 이 경우 delegate_to: localhost를 활용하세요.

이제 모든 도구가 준비되었습니다. 이 구조를 Bitbucket에 푸시하고 AWX에서 실행해 보시면서 노드별로 수집되는 데이터를 확인해 보세요! 추가로 특정 도구의 상세 옵션이 필요하시면 말씀해 주세요.

===

모든 노드에 동일한 SSH 키를 심는 과정은 AWX(Ansible)가 각 서버에 "열쇠"를 들고 들어가기 위한 사전 작업입니다. 보통 ssh-copy-id라는 도구를 사용하거나, 인프라 구축 시점에 Cloud-init 혹은 Terraform 등으로 자동화합니다.

수동으로 한 대씩 설정하는 방법부터 대량으로 처리하는 방법까지 단계별로 설명해 드릴게요.

1. AWX용 SSH 키 생성 (관리 PC 또는 Bastion)

먼저 AWX가 사용할 전용 키 쌍(Public/Private Key)을 만듭니다. 이미 있다면 건너뛰셔도 됩니다.

# 키 생성 (파일 경로: ~/.ssh/id_rsa_awx)
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_awx -N ""
  • id_rsa_awx: AWX Credential에 등록할 Private Key (비밀번호 절대 노출 금지)
  • id_rsa_awx.pub: 모든 노드에 뿌려야 할 Public Key (자물쇠 역할)

2. 모든 노드에 Public Key 배포하기

방법 A: ssh-copy-id 사용 (가장 쉬운 방법)

각 노드의 IP 주소를 알고 있고, 초기 비밀번호 접속이 가능한 경우 사용합니다.

# 모든 노드(Control-plane, Worker들)에 대해 반복 실행
ssh-copy-id -i ~/.ssh/id_rsa_awx.pub root@192.168.1.10
ssh-copy-id -i ~/.ssh/id_rsa_awx.pub root@192.168.1.11
...
  • 명령어를 실행하면 해당 서버의 root 비밀번호를 물어봅니다. 입력하면 ~/.ssh/authorized_keys 파일에 Public Key가 자동으로 등록됩니다.

방법 B: Ansible 자체를 이용한 배포 (서버가 많을 때)

만약 서버가 너무 많다면, 임시로 비밀번호를 사용하는 앤서블 실행으로 키를 뿌릴 수 있습니다.

# 임시 실행 예시 (password 접속 허용 상태여야 함)
ansible all -i 192.168.1.10,192.168.1.11 -m authorized_key \
-a "user=root state=present key='{{ lookup('file', '~/.ssh/id_rsa_awx.pub') }}'" \
-u root --ask-pass

3. AWX에 등록하기 (가장 중요)

키를 모든 노드에 다 뿌렸다면, 이제 AWX가 이 키를 사용하도록 설정해야 합니다.

  1. AWX UI > Resources > Credentials > Add 클릭.
  2. Name: Infra-SSH-Key (자유롭게 입력).
  3. Credential Type: Machine 선택.
  4. Username: root (키를 심은 계정명).
  5. SSH Private Key: 아까 생성한 id_rsa_awx (비밀키)의 내용을 메모장으로 열어 전체 복사해서 붙여넣습니다. (-----BEGIN RSA PRIVATE KEY-----부터 끝까지)
  6. Save 클릭.

4. 제대로 설정되었는지 확인하는 법 (Test)

AWX에서 Inventory를 만들고, 위에서 만든 Machine Credential을 선택한 뒤 Ad-hoc Command를 실행해 보세요.

  • Module: ping
  • Machine Credential: Infra-SSH-Key 선택

만약 모든 노드에서 SUCCESS가 뜬다면, 이제 AWX는 비밀번호 없이도 자유롭게 모든 노드(Control-plane + Worker)에 들어가서 Cilium이나 MinIO 점검을 수행할 수 있게 된 것입니다.

💡 실무 팁 (보안 강화)

  • root 계정 사용 제한: 보안상 root 직접 접속을 막아둔 환경이라면, ansible-user 같은 별도 계정을 만들고 해당 계정에 키를 심은 뒤, AWX Credential 설정에서 Privilege Escalation (sudo) 옵션을 켜서 사용하세요.
  • RHEL 10 특이점: RHEL 10은 최신 암호화 알고리즘을 선호하므로, 너무 오래된 방식의 키(예: 짧은 길이의 RSA)는 거부될 수 있습니다. 위 예시처럼 4096비트 RSA나 ED25519 방식을 권장합니다.

이제 SSH 키 설정까지 완료되면 진정한 자동화 준비가 끝납니다. 혹시 키 배포 과정에서 Permission denied 같은 에러가 발생하면 말씀해 주세요! 구체적인 해결책을 찾아드릴게요.

profile
Young-Kyoo Kim
engineer
이전 포스트

26M25b

다음 포스트

26M25d

0개의 댓글