13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] AWX

  • [Cloud] AWX를 활용한 클라우드 인프라 자동화 1년 회고: 운영 효율성과 도전 과제

    [Cloud] AWX를 활용한 클라우드 인프라 자동화 1년 회고: 운영 효율성과 도전 과제

    AWX 클라우드 인프라 자동화 1년 회고: 운영 효율성과 도전 과제

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 제가 지난 1년간 AWX를 활용한 클라우드 인프라 자동화를 경험하며 느꼈던 점들을 솔직하게 회고해 보려고 해요. 클라우드 환경이 복잡해질수록 수동 작업의 한계를 뼈저리게 느끼곤 하잖아요? 저도 처음엔 정말 막막했습니다. 혹시 여러분도 이런 고민 해보신 적 있으신가요? “수동 작업 줄이고 싶은데, Ansible 플레이북은 많아지고 관리도 어렵고…” 딱 제가 그랬거든요. 그래서 이 녀석, AWX를 도입하게 됐습니다.

    AWX 클라우드 자동화 아키텍처 개요 다이어그램

    AWX 클라우드 자동화 아키텍처 개요 다이어그램

    AWX, 너는 누구니? (핵심 개념)

    자, 그럼 AWX가 뭔지부터 간단히 짚고 넘어갈게요. AWX는 Ansible Tower의 오픈소스 버전이라고 생각하시면 됩니다. 쉽게 말해, Ansible(앤서블) 플레이북(Playbook)을 웹 UI(User Interface)로 관리하고 실행할 수 있게 해주는 도구예요. 단순히 플레이북 실행뿐만 아니라, 인벤토리(Inventory, 관리 대상 호스트 목록), 크리덴셜(Credential, 자격 증명), 프로젝트(Project, 플레이북 저장소), 작업 템플릿(Job Template, 실행 단위), 그리고 워크플로우(Workflow, 여러 작업 템플릿 연결)까지 체계적으로 관리할 수 있게 해줍니다. 💡 특히 팀 단위로 Ansible을 활용할 때, 누가 어떤 작업을 언제 실행했는지, 성공 여부는 어땠는지 한눈에 파악할 수 있어서 정말 편하더라고요.

    AWX 도입 및 초기 셋업 경험

    저도 처음엔 “이거 설치부터 만만치 않겠는데?” 하고 살짝 긴장했었는데, 생각보다 어렵지 않았어요. 저는 주로 Docker Compose(도커 컴포즈)를 이용해서 컨테이너 환경에 AWX를 배포했습니다. 공식 문서에 잘 나와 있어서 따라 하는 데 큰 무리는 없었죠. 하지만 역시 초반 삽질은 피해 갈 수 없더라고요. 😅

    • 인벤토리 구성: 클라우드 환경이다 보니, 정적인 인벤토리보다는 동적 인벤토리(Dynamic Inventory) 스크립트를 활용해야 했습니다. AWS EC2 같은 경우는 플러그인을 활용해서 현재 떠 있는 인스턴스 목록을 자동으로 가져오게 설정했죠. 처음엔 필터링 규칙 잡는 게 좀 헷갈렸는데, 몇 번 해보니 감이 오더라고요.
    • 자격 증명(Credential) 관리: SSH 키나 클라우드 API 키 같은 민감 정보를 안전하게 관리하는 게 중요했습니다. AWX의 크리덴셜 기능을 사용해서 암호화된 형태로 저장하고, 필요한 작업 템플릿에만 연결해서 사용했습니다.
    • Git(깃) 연동: 저희 팀은 모든 Ansible 플레이북을 Git 저장소에 관리하고 있었거든요. AWX 프로젝트와 Git을 연동해서, Git에 푸시(Push)만 하면 AWX가 자동으로 최신 플레이북을 가져오도록 설정했습니다. 이 부분이 정말 편리했어요!

    클라우드 인프라 자동화, 이렇게 해봤습니다

    AWX를 도입하고 나서 저희 팀의 클라우드 인프라 자동화는 날개를 달았습니다. 지난 1년간 다양한 작업들을 AWX를 통해 자동화했는데요, 몇 가지 대표적인 사례를 소개해 드릴게요.

    1. EC2(혹은 VM) 프로비저닝 및 초기 설정 자동화: 새로운 서버를 띄울 때마다 수동으로 OS 설정, 보안 설정, 기본 에이전트 설치 등을 하는 게 큰일이었거든요. AWX에 작업 템플릿을 만들어두고, 인스턴스 ID만 입력하면 모든 초기 설정이 자동으로 완료되도록 했습니다.
    2. 보안 그룹(Security Group) 변경 자동화: 개발자들이 특정 IP를 열어달라고 요청할 때마다 일일이 AWS 콘솔에 들어가서 작업했었는데, 이젠 AWX 작업 템플릿에 IP와 설명을 입력하고 실행하면 끝! 휴먼 에러도 줄고, 작업 속도도 훨씬 빨라졌죠.
    3. 로드밸런서(Load Balancer) 대상 그룹(Target Group) 등록/해제: 배포 시 서비스 인스턴스를 로드밸런서에서 빼고 다시 넣는 작업을 AWX 워크플로우로 묶어 자동화했습니다.
    4. 주기적인 서버 패치 및 재부팅 관리: 매달 특정 요일에 정해진 서버 그룹에 OS 패치를 적용하고 필요시 재부팅하는 작업을 스케줄러(Scheduler) 기능을 활용해서 자동화했습니다.

    간단한 Ansible 플레이북 예시를 하나 보여드릴게요. 특정 EC2 인스턴스의 특정 포트를 보안 그룹에 추가하는 플레이북입니다.

    - name: Add a specific IP to security group
      hosts: localhost
      connection: local
      gather_facts: no
    
      vars:
        instance_id: 'i-xxxxxxxxxxxxxxxxx'
        port_to_open: 8080
        ip_to_allow: '192.168.1.1/32'
        description: 'Allow access from specific IP'
    
      tasks:
        - name: Get security group ID from instance
          amazon.aws.ec2_instance_info:
            instance_ids: "{{ instance_id }}"
          register: ec2_info
    
        - name: Set security group ID fact
          set_fact:
            sg_id: "{{ ec2_info.instances[0].security_groups[0].group_id }}"
    
        - name: Authorize ingress rule
          amazon.aws.ec2_group:
            group_id: "{{ sg_id }}"
            region: ap-northeast-2
            rules:
              - proto: tcp
                ports:
                  - "{{ port_to_open }}"
                cidr_ip: "{{ ip_to_allow }}"
                rule_desc: "{{ description }}"
            purge_rules: no
    

    이런 플레이북을 AWX에 등록하고, instance_id, port_to_open, ip_to_allow 같은 변수들만 작업 템플릿에서 설정하면 되는 거죠. 정말 편하더라고요! 🚀

    AWX 작업 템플릿 설정 화면 예시

    AWX 작업 템플릿 설정 화면 예시

    1년 회고: AWX가 가져온 운영 효율성

    지난 1년간 AWX를 운영하면서 가장 크게 체감한 건 바로 운영 효율성의 극대화였습니다. 🎉

    • 수동 작업 시간 획기적으로 감소: 과거에 1시간씩 걸리던 수동 설정 작업들이 이제는 AWX 작업 템플릿 한 번 클릭으로 5분 안에 끝나는 마법을 경험했습니다.
    • 휴먼 에러(Human Error) 감소: 정형화된 작업 템플릿을 사용하니, 사람이 실수할 여지가 거의 없어졌습니다. 특히 야간 작업이나 긴급 상황에서 빛을 발하더라고요.
    • 작업 표준화 및 가시성 확보: 모든 자동화 작업이 AWX를 통해 이루어지면서, 어떤 팀원이든 동일한 절차로 작업을 수행할 수 있게 되었고, 대시보드에서 모든 작업 이력을 한눈에 볼 수 있게 되었습니다.
    • 팀원 간 협업 용이: Ansible 플레이북을 공유하고, 각자의 권한에 맞춰 작업 템플릿을 실행할 수 있으니 팀원 간의 협업이 훨씬 부드러워졌어요.

    AWX 대시보드를 보면 성공률이 압도적으로 높은 걸 확인할 수 있는데, 정말 뿌듯하더라고요. 👍

    AWX 대시보드 자동화 작업 성공률 통계

    AWX 대시보드 자동화 작업 성공률 통계

    마주했던 도전 과제와 삽질 (Feat. 해결 과정)

    물론 AWX와 함께한 1년이 장밋빛만 있었던 건 아닙니다. 저도 꽤 많은 삽질을 했습니다. ⚠️ 특히 다음과 같은 부분에서 도전 과제가 있었어요.

    1. 자격 증명(Credential) 관리의 복잡성: 초기에는 AWS IAM(Identity and Access Management) 역할(Role)을 AWX에 연동하는 데 애를 먹었습니다. AWX가 EC2 인스턴스에서 실행될 때 IAM 역할을 상속받아 사용하는 방식과, 직접 AWS Access Key를 등록하는 방식 중 보안과 편리성을 저울질하는 데 시간이 걸렸죠. 결국, IAM 역할 기반 인증을 적극 활용하는 방향으로 정착했습니다.
    2. 동적 인벤토리(Dynamic Inventory) 스크립트 작성의 어려움: 클라우드 환경은 인스턴스가 수시로 뜨고 꺼지기 때문에, 항상 최신 인벤토리 정보를 유지하는 게 중요합니다. AWX에 내장된 클라우드 플러그인들을 최대한 활용했지만, 특정 태그(Tag)나 조건에 맞는 인스턴스만 필터링하는 복잡한 스크립트를 작성할 때는 시행착오가 많았습니다. 파이썬(Python)으로 직접 스크립트를 짜면서 디버깅하는 과정이 꽤 힘들었네요.
    3. 워크플로우(Workflow) 설계의 난이도: 여러 작업 템플릿을 연결해서 복잡한 배포 파이프라인(Pipeline)이나 운영 절차를 자동화할 때, 조건부 실행이나 실패 시 롤백(Rollback) 같은 로직을 AWX 워크플로우로 구현하는 게 생각보다 쉽지 않았습니다. 처음에는 너무 복잡하게 얽혀서 디버깅도 어려웠는데, 점차 작은 단위의 작업 템플릿으로 쪼개고, 명확한 성공/실패 조건을 정의하면서 해결해 나갔습니다.
    4. AWX 업그레이드의 험난함: 오픈소스 프로젝트이다 보니, 새로운 버전이 나올 때마다 업그레이드 가이드라인이 명확하지 않거나, 의존성 문제로 애를 먹는 경우가 있었습니다. 특히 컨테이너 환경에서 볼륨(Volume)이나 데이터베이스 마이그레이션(Migration) 과정에서 여러 번 백업/복구를 반복하며 땀 좀 흘렸습니다. 💦

    이 모든 과정들이 저를 더 단단하게 만들어주었네요. 역시 인프라는 삽질하면서 배우는 게 최고인 것 같습니다! ㅎㅎ

    AWX, 앞으로의 방향은? (마무리)

    지난 1년간 AWX 클라우드 자동화를 경험하면서 정말 많은 것을 배우고, 팀의 운영 효율성을 크게 향상시킬 수 있었습니다. 수동 작업을 줄이고, 휴먼 에러를 방지하며, 표준화된 절차를 통해 안정적인 서비스 운영을 할 수 있게 된 것이 가장 큰 성과라고 생각합니다.

    물론 아직 가야 할 길이 멀지만, 앞으로는 AWX를 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인에 더욱 깊숙이 통합하고, GitOps(깃옵스) 철학을 도입하여 모든 인프라 변경 사항을 Git을 통해 관리하는 시스템을 구축하고 싶습니다. IaC(Infrastructure as Code, 코드형 인프라)를 넘어, 모든 것이 코드로 정의되고 자동으로 배포되는 이상적인 환경을 꿈꾸고 있거든요.

    혹시 여러분도 AWX를 활용한 클라우드 자동화 경험이 있으시다면, 어떤 점이 좋았고 어떤 어려움이 있었는지 댓글로 공유해 주시면 좋겠습니다. 다음 글에서는 AWX와 CI/CD 연동에 대한 좀 더 구체적인 내용을 다뤄볼까 합니다. 기대해주세요! 😊

    AWX와 클라우드 인프라 자동화의 미래 비전 인포그래픽

    AWX와 클라우드 인프라 자동화의 미래 비전 인포그래픽

  • [Proxmox] Ansible로 Proxmox 자동화, 실패 없는 10가지 베스트 프랙티스

    [Proxmox] Ansible로 Proxmox 자동화, 실패 없는 10가지 베스트 프랙티스

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’ 운영자입니다. 오늘은 제가 홈랩과 실무 환경에서 늘 고민하고 적용해왔던 주제, 바로 Ansible로 Proxmox 자동화에 대해 이야기해보려고 합니다. 많은 분들이 Proxmox VE(Virtual Environment)를 사용하시면서 가상 머신(VM)이나 컨테이너(LXC)를 수동으로 생성하고 설정하는 데 시간을 많이 쏟으셨을 거예요. 저도 처음엔 그랬습니다. 매번 클릭하고 타이핑하고… 그러다 어느 순간 ‘이거 자동화할 수 없을까?’ 하는 생각이 머리를 스치더군요. 그래서 Ansible을 들고 Proxmox에 뛰어들었고, 수많은 삽질 끝에 얻은 귀한 경험들을 여러분과 나누고자 합니다.

    오늘 제가 준비한 내용은 ‘실패 없는 Proxmox 자동화를 위한 10가지 베스트 프랙티스’입니다. 단순한 기능 소개를 넘어, 제가 직접 부딪히고 해결했던 문제들과 그 과정에서 배운 노하우를 멘토처럼 알려드릴게요. 이 글을 읽고 나면 여러분의 홈랩 자동화는 물론, 실제 인프라 관리 효율도 한층 더 높아질 거라고 확신합니다. 자, 그럼 시작해볼까요? 🎉

    Ansible과 Proxmox 연동 아키텍처 다이어그램

    Ansible 컨트롤러가 Proxmox 호스트들을 관리하며 VM, LXC, 스토리지, 네트워크 등을 자동화하는 아키텍처 다이어그램입니다.

    Proxmox와 Ansible, 왜 함께해야 할까요? (개념 설명)

    Proxmox VE(프로모스 VE)는 강력한 오픈소스 가상화 플랫폼입니다. KVM(Kernel-based Virtual Machine) 기반의 가상 머신과 LXC(Linux Container) 컨테이너를 지원하며, 웹 기반 GUI로 손쉽게 관리할 수 있죠. 하지만 아무리 GUI가 편해도 수십, 수백 대의 VM을 일일이 설정하는 건 비효율적이거든요. 여기서 Ansible(앤서블)이 등장합니다. Ansible은 IT 자동화를 위한 오픈소스 도구로, SSH 기반의 Agentless(에이전트리스) 방식이라 별도의 에이전트 설치 없이도 원격 서버를 제어할 수 있더라고요. YAML(야믈) 기반의 플레이북(Playbook)으로 인프라의 ‘상태’를 정의하면, Ansible이 그 상태를 맞춰주죠.

    쉽게 말해, Proxmox가 튼튼한 서버실이라면 Ansible은 이 서버실을 알아서 척척 관리해주는 유능한 비서인 셈입니다. VM 생성, 네트워크 설정, 스토리지 연결 등 반복적이고 오류 발생 가능성이 높은 작업들을 Ansible로 자동화하면, 시간을 절약하고 휴먼 에러(human error)를 크게 줄일 수 있거든요. 특히 저처럼 홈랩 자동화에 관심이 많은 분들에게는 정말 최고의 조합이라고 할 수 있습니다.

    실패 없는 Proxmox 자동화를 위한 10가지 베스트 프랙티스 (실전 구현)

    제가 13년 동안 쌓아온 경험과 숱한 삽질 끝에 얻은 Proxmox 자동화 팁들을 공유합니다. 이 원칙들을 지키면 여러분의 Ansible Proxmox 자동화 여정이 훨씬 수월할 거예요.

    1. 동적 인벤토리(Dynamic Inventory) 활용하기

    가장 먼저 강조하고 싶은 건 바로 동적 인벤토리입니다. VM이 수시로 생성되고 삭제되는 환경에서는 정적 인벤토리(Static Inventory) 파일을 매번 수정하기가 어렵거든요. Proxmox의 API를 활용해서 현재 떠 있는 VM 목록을 동적으로 가져오는 스크립트를 사용하면 정말 편합니다. community.general 컬렉션에 Proxmox 동적 인벤토리 플러그인이 있으니 활용해보세요. 저는 주로 Python 스크립트를 직접 짜서 사용했는데, 이게 훨씬 유연하더라고요.

    # ansible.cfg 예시
    [inventory]
    enable_plugins = proxmox
    
    # inventory/proxmox.yml
    plugin: community.proxmox.proxmox
    base_url: https://your-proxmox-host:8006/api2/json
    api_user: root@pam
    api_password: your_password_or_token
    validate_certs: False # 실제 환경에서는 True 권장
    

    이렇게 설정하면 ansible-inventory -i inventory/proxmox.yml --list 명령으로 현재 Proxmox에 있는 VM들을 Ansible 인벤토리로 불러올 수 있습니다. 💡 팁: 보안을 위해 API 토큰을 사용하는 것을 강력히 추천합니다.

    2. 항상 멱등성(Idempotency)을 지키세요

    Ansible의 핵심 철학은 멱등성입니다. 즉, 플레이북을 여러 번 실행해도 항상 동일한 결과를 내고, 이미 목표 상태에 도달했다면 아무 작업도 하지 않아야 한다는 뜻이거든요. Proxmox VM 생성/수정 시 이 멱등성을 지키는 것이 매우 중요합니다. 예를 들어, VM이 이미 존재하면 생성하지 않거나, 설정이 동일하면 변경하지 않도록 플레이북을 작성해야 하더라고요. Proxmox 모듈들은 대부분 멱등성을 지원하지만, 스크립트나 커맨드를 직접 사용할 때는 주의가 필요합니다. 저도 초기에 이 부분을 간과해서 이미 생성된 VM에 또 생성 명령이 들어가 오류가 나던 경험이 많았거든요.

    3. 변수 관리, 이렇게 해야 깔끔합니다

    플레이북 내에 하드코딩된 값은 피하고, 변수(Variables)를 적극적으로 활용하세요. 특히 group_vars와 host_vars 디렉토리를 사용하면 VM의 종류나 호스트별로 유연하게 설정을 관리할 수 있더라고요. 민감한 정보(API 키, 비밀번호 등)는 Ansible Vault(앤서블 볼트)를 사용해서 암호화하세요. 보안은 아무리 강조해도 지나치지 않습니다. 저도 한때 vars 파일에 비밀번호를 그냥 넣었다가 식겁한 적이 있습니다. 😅

    # group_vars/all.yml
    pve_api_user: 'root@pam'
    pve_api_token_id: 'ansible-token'
    pve_api_token_secret: '{{ vault_pve_api_token_secret }}' # vault로 관리
    
    # host_vars/my-vm.yml
    vm_id: 101
    vm_name: 'web-server-01'
    vm_memory: 2048
    vm_cores: 2
    vm_net_bridge: 'vmbr0'
    vm_ip: '192.168.1.101'
    

    4. Proxmox 전용 모듈, 똑똑하게 쓰기

    Ansible은 community.proxmox 컬렉션을 통해 Proxmox를 위한 다양한 모듈을 제공합니다. proxmox_kvm, proxmox_lxc, proxmox_storage 등 목적에 맞는 모듈을 사용하세요. 이 모듈들은 Proxmox API를 활용하여 안정적이고 멱등성 있는 작업을 수행할 수 있도록 설계되었더라고요. 셸 스크립트(shell script)로 API를 직접 호출하는 것보다 훨씬 안전하고 관리하기 편합니다. 예전에는 uri 모듈로 직접 HTTP 요청을 날리기도 했는데, 전용 모듈이 훨씬 편리하더라고요.

    - name: Create a new KVM virtual machine
      community.proxmox.proxmox_kvm:
        api_host: "{{ pve_api_host }}"
        api_user: "{{ pve_api_user }}"
        api_token_id: "{{ pve_api_token_id }}"
        api_token_secret: "{{ pve_api_token_secret }}"
        vmid: "{{ vm_id }}"
        name: "{{ vm_name }}"
        memory: "{{ vm_memory }}"
        cores: "{{ vm_cores }}"
        net:
          net0: 'model=virtio,bridge={{ vm_net_bridge }}'
        state: present
      delegate_to: localhost
    

    5. 오류 핸들링(Error Handling), 미리미리 대비하기

    자동화 작업은 예상치 못한 문제로 실패할 수 있습니다. 네트워크 문제, Proxmox API 응답 지연, 잘못된 변수 값 등 다양한 원인이 있죠. failed_when, ignore_errors, block/rescue를 활용하여 견고한 플레이북을 만드세요. 특히 중요한 작업은 block으로 묶고, 실패 시 rescue 블록에서 정리 작업을 하도록 구성하면 정말 안전하더라고요. 저도 처음에 에러가 나면 그냥 멈추게 만들었는데, 나중에는 중단된 상태를 수동으로 정리하는 게 더 힘들더라고요. ⚠️

    - name: Critical VM creation block
      block:
        - name: Create VM
          community.proxmox.proxmox_kvm:
            # ... VM 생성 설정 ...
            state: present
          delegate_to: localhost
        - name: Configure VM network
          ansible.builtin.shell: 'some_network_config_command {{ vm_ip }}'
      rescue:
        - name: Clean up VM if creation failed
          community.proxmox.proxmox_kvm:
            api_host: "{{ pve_api_host }}"
            api_user: "{{ pve_api_user }}"
            api_token_id: "{{ pve_api_token_id }}"
            api_token_secret: "{{ pve_api_token_secret }}"
            vmid: "{{ vm_id }}"
            state: absent
          delegate_to: localhost
    

    6. 태그(Tags)로 원하는 작업만 골라 실행하기

    플레이북이 점점 커지면 특정 작업만 실행하거나 건너뛰고 싶을 때가 많습니다. 이때 태그(Tags)를 사용하면 정말 유용하더라고요. 각 태스크(task)에 의미 있는 태그를 부여하고, --tags 또는 --skip-tags 옵션으로 플레이북 실행을 제어할 수 있습니다. 예를 들어, ‘network’ 태그를 부여한 태스크만 실행하거나, ‘cleanup’ 태그가 붙은 태스크는 건너뛰는 식이죠. 저도 처음엔 플레이북 전체를 매번 돌렸는데, 태그를 사용하니 개발 및 테스트 시간이 엄청 단축되더라고요. ✅

    # 'create_vm' 태그가 붙은 작업만 실행
    ansible-playbook -i inventory/proxmox.yml playbook.yml --tags create_vm
    
    # 'cleanup' 태그가 붙은 작업만 건너뛰고 실행
    ansible-playbook -i inventory/proxmox.yml playbook.yml --skip-tags cleanup
    

    7. 역할(Roles) 기반으로 플레이북 구조화하기

    복잡한 Proxmox 스크립트와 플레이북은 역할(Roles) 기반으로 구조화하는 것이 좋습니다. 역할은 변수, 태스크, 핸들러(handler), 파일, 템플릿(template) 등을 논리적으로 묶어 재사용성을 높여주거든요. 예를 들어, ‘proxmox-vm-create’ 역할, ‘proxmox-net-config’ 역할 등으로 나누어 관리하면 가독성이 높아지고 유지보수가 훨씬 쉬워집니다. 저의 홈랩에서도 VM 생성, 네트워크 설정, 특정 애플리케이션 설치 등을 각각의 역할로 만들어서 사용하고 있습니다.

    # roles/proxmox-vm-create/tasks/main.yml
    - name: Create VM
      community.proxmox.proxmox_kvm:
        # ... VM 생성 설정 ...
    
    # playbook.yml
    - name: Deploy web server VM on Proxmox
      hosts: localhost
      connection: local
      roles:
        - role: proxmox-vm-create
          vars:
            vm_name: 'web-server-02'
            vm_id: 102
            # ... 기타 변수 ...
        - role: proxmox-net-config
          vars:
            vm_ip: '192.168.1.102'
    

    8. 플레이북 실행 전 반드시 테스트하기 (–check –diff)

    실제 변경 사항을 적용하기 전에 --check (dry run, 드라이 런) 모드로 플레이북을 실행하여 어떤 변경이 일어날지 미리 확인하세요. --diff 옵션을 함께 사용하면 변경될 내용을 자세히 볼 수 있더라고요. 이 두 옵션은 실제 환경에 적용하기 전에 발생할 수 있는 잠재적인 문제를 미리 발견하는 데 정말 중요한 역할을 합니다. 저의 수많은 ‘대형 사고’를 막아준 고마운 기능입니다. 😅

    # 실제로 변경하지 않고, 어떤 변경이 일어날지 미리 확인
    ansible-playbook -i inventory/proxmox.yml playbook.yml --check --diff
    

    9. 버전 관리 시스템(Git)은 필수입니다

    모든 플레이북, 인벤토리, 역할 파일은 Git과 같은 버전 관리 시스템에 저장해야 합니다. 변경 이력을 추적하고, 여러 사람이 협업하며, 필요할 경우 이전 버전으로 되돌릴 수 있게 해주거든요. Ansible Proxmox 자동화 스크립트는 인프라의 ‘코드’와 같으므로, 코드 관리의 모범 사례를 따르는 것이 중요합니다. 저도 처음엔 그냥 로컬 폴더에 저장해두고 관리했는데, 실수로 파일을 날리거나 변경 이력을 잃어버려서 다시 처음부터 작성했던 뼈아픈 경험이 있습니다.

    10. AWX/Tower(자동화 컨트롤러)로 더 강력하게

    Ansible 자동화가 복잡해지고 규모가 커지면, AWX(앤서블 워크스)나 Ansible Tower(앤서블 타워)와 같은 자동화 컨트롤러의 도입을 고려해보세요. 웹 기반 UI를 통해 플레이북 실행, 인벤토리 관리, 사용자 권한 제어, 스케줄링, 로깅 등 모든 자동화 작업을 중앙에서 관리할 수 있거든요. AWX Proxmox 연동은 특히 강력합니다. 저는 홈랩에서 AWX를 구축해서 복잡한 VM 배포 파이프라인을 만들었는데, 이젠 버튼 하나로 모든 게 되니 정말 편하더라고요. 이젠 홈랩 자동화의 끝판왕이라고 부르고 싶을 정도입니다.

    AWX 대시보드에서 성공적으로 실행된 Proxmox 자동화 작업 목록

    AWX 대시보드에서 Proxmox 관련 자동화 작업이 성공적으로 실행된 모습을 보여주는 스크린샷입니다.

    ⚠️ 삽질 경험담: 제가 겪었던 문제들 (주의사항/트러블슈팅)

    제가 Ansible Proxmox 자동화를 하면서 가장 많이 겪었던 문제들을 몇 가지 공유해 드릴게요. 여러분은 저처럼 삽질하지 마시라고요! ㅎㅎ

    권한 문제 (Permission Denied)

    Proxmox API를 사용할 때 가장 많이 만나는 에러 중 하나가 바로 권한 문제입니다. root@pam 계정을 직접 사용하는 것은 보안상 좋지 않고, 특정 권한만 가진 API 토큰을 생성해서 사용하는 것이 모범 사례거든요. Proxmox의 ‘Datacenter -> Permissions -> API Tokens’에서 필요한 권한(예: VM.Audit, VM.PowerMgmt, VM.Allocate)만 부여된 토큰을 만들고, 이 토큰 ID와 시크릿(secret)을 Ansible Vault로 안전하게 관리해야 합니다. 처음엔 root 권한으로 대충 했는데, 나중에 보안 감사 때 혼쭐이 날 뻔했습니다. 😱

    네트워크 설정 복잡성

    Proxmox의 네트워크 설정은 처음엔 좀 복잡하게 느껴질 수 있습니다. 특히 브리지(bridge) 설정이나 VLAN(Virtual Local Area Network) 태깅 같은 부분이요. Ansible로 VM을 생성하고 네트워크를 붙일 때, Proxmox 호스트의 네트워크 설정(/etc/network/interfaces)과 정확히 일치하는지 확인해야 합니다. 잘못된 브리지 이름을 사용하거나, VLAN ID를 놓치면 VM이 네트워크에 연결되지 않아 한참을 헤맸던 적이 많습니다. 네트워크 자동화는 항상 신중하게 테스트하는 게 정말 중요해요.

    이 외에도 Proxmox API 응답 지연, 모듈 인자(argument) 오류, 템플릿(Template) 이미지 경로 문제 등 다양한 변수들이 있었습니다. 중요한 건 에러 메시지를 꼼꼼히 읽고, Proxmox 공식 문서와 Ansible 모듈 문서를 참고하며 차분하게 해결해나가는 인내심입니다. 저도 처음엔 ‘이게 왜 안 돼!’ 하면서 키보드를 던질 뻔한 적이 한두 번이 아니었거든요. 하지만 포기하지 않고 해결했을 때의 쾌감은 정말 짜릿합니다! ✨

    Ansible로 자동화된 Proxmox 가상 머신 및 컨테이너 목록

    Ansible로 자동 생성 및 설정된 Proxmox 가상 머신(VM) 및 컨테이너(LXC) 목록을 보여주는 Proxmox 웹 인터페이스 화면입니다.

    마치며: 자동화, 결국 시간을 벌어주는 일 (마무리)

    오늘은 13년차 인프라 엔지니어의 시선으로 Ansible Proxmox 자동화의 베스트 프랙티스 10가지를 자세히 소개해 드렸습니다. 동적 인벤토리, 멱등성, 변수 관리, Proxmox 모듈 활용, 오류 핸들링, 태그, 역할, 테스트, 버전 관리, 그리고 AWX/Tower까지, 이 모든 것이 여러분의 홈랩 자동화와 실무 인프라 관리에 큰 도움이 될 거라고 생각합니다.

    처음에는 복잡해 보일 수 있지만, 한 번 구축해두면 반복적인 작업에서 정말 완전히 해방될 수 있습니다. Proxmox 스크립트를 일일이 작성하고 실행하는 시간 대신, 더 중요하고 창의적인 일에 집중할 수 있게 되는 거죠. 자동화는 결국 우리에게 ‘시간’이라는 가장 소중한 자원을 벌어다 줍니다. 여러분도 오늘 배운 내용을 바탕으로 자신만의 Ansible Proxmox 자동화 시스템을 구축해보시고, 그 편리함을 직접 경험해보시길 바랍니다. 다음 글에서는 AWX를 활용한 Proxmox VM 배포 파이프라인 구축에 대해 더 자세히 다뤄볼 예정이니 기대해주세요! 😉

    Ansible과 Proxmox 연동의 이점을 요약한 인포그래픽

    Ansible과 Proxmox 로고를 중심으로 자동화, 효율성, 확장성, 홈랩, 인프라 관리 등 주요 이점을 시각적으로 요약한 인포그래픽입니다.

  • [k8s] K3s와 AWX 통합 사례 연구: 경량 Kubernetes 자동화 워크플로우 구축

    [k8s] K3s와 AWX 통합 사례 연구: 경량 Kubernetes 자동화 워크플로우 구축

    안녕하세요, 13년차의 서버실입니다. 오늘은 제가 홈랩에서 직접 경험하고 삽질하면서 얻은 지식 하나를 여러분과 공유해볼게요. 바로 K3s(케이쓰리쓰)와 AWX(에이더블유엑스)를 통합하여 경량 Kubernetes(쿠버네티스) 환경에서 자동화 워크플로우를 구축하는 사례입니다.

    작은 규모의 인프라나 홈랩에서 Kubernetes를 운영하다 보면, 리소스 제약 때문에 고민이 많아지죠. 게다가 반복적인 배포나 설정 변경 작업을 수동으로 하다 보면 시간 낭비는 물론이고 휴먼 에러 발생 확률도 높아지고요. 저도 “이걸 어떻게 하면 좀 더 효율적으로 관리할 수 있을까?” 하는 고민에 빠져있었거든요. 그러다가 경량 Kubernetes인 K3s와 Ansible(앤서블) 기반의 자동화 플랫폼인 AWX의 조합을 떠올리게 됐습니다.

    이 둘을 잘 엮으면 리소스 효율적인 환경에서 강력한 자동화 시스템을 만들 수 있겠다는 확신이 들었죠. 그래서 직접 부딪혀가며 구축해봤고, 그 과정과 삽질 경험을 솔직하게 풀어보려 합니다. 혹시 여러분도 비슷한 고민을 하고 계셨다면, 이 글이 좋은 가이드가 될 수 있을 거예요. 💡

    K3s와 AWX를 통합한 자동화 워크플로우의 전체 아키텍처 다이어그램

    K3s 클러스터 위에 AWX가 배포되어 외부 Git 리포지토리의 Ansible 플레이북을 가져와 다른 K3s/Kubernetes 클러스터에 배포하는 통합 아키텍처 다이어그램입니다.

    K3s와 AWX, 왜 이 조합일까요?

    먼저, 이 두 가지 기술이 무엇인지, 그리고 왜 함께 사용하면 시너지가 나는지 간단하게 짚고 넘어가겠습니다.

    K3s: 가볍지만 강력한 경량 Kubernetes

    K3s(케이쓰리쓰)는 Rancher Labs(랜처 랩스)에서 만든 경량 Kubernetes(쿠버네티스) 배포판입니다. 이름에서 알 수 있듯이 ‘K8s(케이츠) – 5 = K3s’라는 유머러스한 의미를 가지고 있어요. 그만큼 바이너리 크기가 작고, 메모리 사용량도 적으니까요. 일반적인 Kubernetes는 컨트롤 플레인(Control Plane) 구성 요소들이 많은 리소스를 요구하는데, K3s는 SQLite를 기본 데이터베이스로 사용하고 불필요한 기능을 제거해서 엣지 컴퓨팅(Edge Computing), IoT(사물 인터넷), 또는 저사양 환경에 정말 딱 맞습니다. 제가 홈랩에서 운영하는 라즈베리 파이(Raspberry Pi) 클러스터 같은 곳에 정말 찰떡이더라고요. ✅

    AWX: Ansible 자동화 플랫폼의 중앙 허브

    AWX(에이더블유엑스)는 Red Hat(레드햇)의 Ansible Tower(앤서블 타워)의 오픈소스 업스트림 프로젝트입니다. Ansible(앤서블)은 강력한 IT 자동화 도구인데, AWX는 이 Ansible 플레이북(Playbook)들을 웹 UI를 통해 중앙에서 관리하고 실행할 수 있게 해줍니다. 그냥 복잡한 커맨드 라인(Command Line) 없이도 프로젝트, 인벤토리(Inventory), 자격 증명(Credential) 등을 관리하고, 잡 템플릿(Job Template)을 만들어 반복적인 작업을 예약하거나 실행 결과를 쉽게 확인할 수 있죠. 특히 팀 단위로 자동화 작업을 공유하고 접근 제어를 해야 할 때 진짜 빛을 발합니다. 🎉

    통합의 시너지: 경량 K3s 위의 자동화 플랫폼

    저는 K3s의 가벼움 위에 AWX를 올려서 경량 Kubernetes 환경을 위한 자동화 허브를 구축하고 싶었습니다. K3s에서 돌아가는 애플리케이션의 배포나 설정을 AWX를 통해 관리하려는 거였거든요. 예를 들어, 새로운 컨테이너 이미지를 빌드하면 AWX가 자동으로 K3s 클러스터에 배포하도록 하거나, 특정 서비스의 스케일링(Scaling) 작업을 AWX 잡 템플릿으로 만들어서 필요할 때마다 클릭 한 번으로 실행하는 식입니다. 이렇게 하면 인프라 관리가 정말 수월해지더라고요. 💡

    실전 구현: K3s 위에 AWX 배포하기

    이제 제가 직접 K3s 클러스터에 AWX를 배포했던 과정을 단계별로 설명해 드릴게요. 저는 이미 K3s 클러스터가 구성되어 있다는 가정하에 진행했습니다. 아직 K3s 설치가 안 되어 있다면, 다음 명령어로 간단하게 설치할 수 있습니다.

    curl -sfL https://get.k3s.io | sh -

    1. AWX Operator 설치

    AWX는 Kubernetes 환경에 AWX Operator(오퍼레이터)를 통해 배포하는 것이 가장 일반적입니다. Operator는 특정 애플리케이션(여기서는 AWX)을 Kubernetes의 컨트롤러처럼 관리해주는 도구라고 생각하시면 돼요. 배포부터 업데이트, 스케일링까지 알아서 처리해주니까요.

    AWX Operator를 설치하려면 공식 AWX Operator 저장소에서 최신 설치 가이드를 확인하시고, 다음 명령어로 설치합니다.

    kubectl apply -f https://raw.githubusercontent.com/ansible/awx-operator/devel/deploy/operator.yaml

    이 명령어가 AWX Operator와 필요한 CRD(Custom Resource Definition, 사용자 정의 리소스 정의)를 모두 설치해줍니다. CRD는 Kubernetes가 AWX라는 새로운 리소스 타입을 이해할 수 있도록 해주는 설정 파일이거든요. 이 과정을 거치면 awx-operator 파드(Pod)가 실행되면서 AWX 인스턴스를 배포할 준비가 완료됩니다.

    2. AWX 인스턴스 배포

    Operator가 준비되었다면, 이제 우리가 원하는 AWX 인스턴스를 생성할 차례입니다. AWX라는 Custom Resource(CR) 객체를 생성하면, Operator가 이 CR을 감지하고 실제 AWX 애플리케이션을 배포해줍니다. 저는 awx.yaml이라는 파일을 만들어서 다음과 같이 설정했습니다.

    apiVersion: awx.ansible.com/v1beta1
    kind: AWX
    metadata:
      name: my-awx
    spec:
      # AWX Operator가 배포할 AWX 인스턴스의 이름
      # 여기서는 my-awx로 지정했습니다.
    
      # ingressType: Ingress를 사용하여 Kubernetes Ingress를 통해 AWX에 접근하도록 설정합니다.
      # K3s는 기본적으로 Traefik Ingress Controller를 포함하고 있어 편리합니다.
      ingressType: Ingress
      # ingress_host: AWX에 접근할 호스트 이름을 지정합니다.
      # 실제 환경에서는 DNS에 이 호스트를 등록해야 합니다.
      ingress_host: awx.myhomelab.local
      
      # 기타 설정 (필요에 따라 주석 해제 및 수정)
      # postgres_storage_class: AWX 데이터베이스를 위한 Persistent Volume Claim(PVC)의 StorageClass를 지정합니다.
      # 홈랩 환경에서는 hostPath나 local-storage 등을 사용할 수 있습니다.
      # postgres_storage_class: standard
      
      # web_extra_volume_mounts: AWX 웹 파드에 추가 볼륨을 마운트할 때 사용합니다.
      # e.g., 인증서 마운트 등
      # tasks_extra_volume_mounts: AWX 태스크 파드에 추가 볼륨을 마운트할 때 사용합니다.
      
      # image_version: 사용할 AWX 이미지 버전 (특정 버전을 고정할 경우)
      # image_version: "23.3.0"
      
      # resource_requirements: AWX 파드들의 리소스 요청/제한을 설정합니다.
      # 작은 환경에서는 이 부분을 적절히 조절해야 합니다.
      # web_resource_requirements:
      #   requests:
      #     cpu: 500m
      #     memory: 1Gi
      #   limits:
      #     cpu: 1000m
      #     memory: 2Gi
    

    이 파일을 저장하고 kubectl apply -f awx.yaml 명령어를 실행하면 AWX Operator가 AWX 인스턴스에 필요한 Deployment(디플로이먼트), Service(서비스), Ingress(인그레스), Persistent Volume Claim(PVC) 등을 자동으로 생성하기 시작합니다.

    K3s 클러스터에 AWX 파드들이 정상적으로 실행 중임을 나타내는 터미널 화면

    AWX 웹 UI의 로그인 화면 또는 kubectl get pods -n awx 명령어를 실행했을 때 AWX 관련 파드들이 모두 Running 상태인 것을 보여주는 스크린샷입니다.

    ⚠️ 삽질 경험과 트러블슈팅

    제가 이 과정을 진행하면서 겪었던 몇 가지 삽질 경험과 해결 방법을 공유합니다. 여러분은 저처럼 헤매지 않으시길 바라요! 😂

    1. 리소스 부족 문제

    K3s는 가볍지만, AWX는 생각보다 많은 리소스를 필요로 합니다. 특히 데이터베이스(PostgreSQL)와 웹, 태스크 파드들이 동시에 돌아가기 때문에, 2GB RAM 이하의 시스템에서는 버벅이거나 파드가 계속 재시작되는 문제가 발생할 수 있어요. 최소 4GB RAM, 2코어 CPU 이상을 권장합니다. 저도 처음엔 라즈베리 파이 4(4GB 모델)에서 돌렸는데, 다른 서비스들과 함께 돌리니 정말 아슬아슬하더라고요. 결국 8GB 모델로 업그레이드하거나, AWX 전용 노드를 따로 두는 것을 고려하게 됐습니다.

    해결책: awx.yaml 파일의 resource_requirements 섹션을 통해 각 파드의 리소스 요청(requests)과 제한(limits)을 조절할 수 있습니다. 하지만 너무 낮추면 성능 문제가 발생하니, 하드웨어 사양을 충분히 확보하는 것이 최고의 방법입니다.

    2. Persistent Volume(영구 볼륨) 설정

    AWX는 데이터베이스(PostgreSQL)와 작업 실행 로그 등을 저장하기 위해 Persistent Volume(PV, 영구 볼륨)이 필요합니다. K3s는 기본적으로 local-path-provisioner(로컬 패스 프로비저너)를 내장하고 있어서 별도의 StorageClass(스토리지 클래스) 설정 없이도 PVC(Persistent Volume Claim)를 생성하면 자동으로 PV가 프로비저닝(Provisioning)됩니다. 하지만 이 방식은 특정 노드에 데이터가 종속되기 때문에 노드 장애 시 데이터 손실 위험이 있습니다.

    해결책: 홈랩 환경에서는 간단하게 hostPath 타입을 사용하여 특정 경로에 데이터를 저장할 수 있지만, 좀 더 안정적인 환경을 원한다면 NFS(네트워크 파일 시스템) 서버를 구축하고 NFS CSI Driver(드라이버)를 설치하여 공유 스토리지를 사용하는 것이 좋습니다. 저도 NFS를 사용해서 여러 노드에서 AWX 파드들이 유연하게 움직일 수 있도록 구성했거든요.

    3. Ingress(인그레스) 접근 문제

    ingress_host를 설정했지만, 웹 브라우저에서 접속이 안 되는 경우가 있었습니다. K3s는 기본적으로 Traefik(트래픽) Ingress Controller(인그레스 컨트롤러)를 내장하고 있어 편리합니다. 하지만 제 경우에는 다음과 같은 문제가 있었습니다.

    • DNS 설정: awx.myhomelab.local과 같은 호스트 이름을 사용하려면, 홈랩 내 DNS 서버에 해당 호스트를 등록하거나, 접속하려는 PC의 /etc/hosts (Linux/macOS) 또는 C:\Windows\System32\drivers\etc\hosts (Windows) 파일에 IP 주소와 호스트 이름을 직접 매핑해주어야 합니다.
      # /etc/hosts 예시
      192.168.1.100 awx.myhomelab.local # K3s 마스터 노드의 IP 주소
    • Traefik 설정: 가끔 Traefik이 외부 트래픽을 제대로 라우팅(Routing)하지 못하는 경우가 있는데, K3s 설치 시 Traefik 관련 옵션을 확인하거나, Traefik 대시보드(보통 http://<k3s_master_ip>:8080/dashboard/)에서 Ingress Route(인그레스 라우트)가 제대로 생성되었는지 확인해야 합니다.

    해결책: 저는 /etc/hosts 파일을 수정하고, kubectl get ingress -n awx 명령어로 AWX Ingress 리소스가 정상적으로 생성되었는지 확인하면서 문제를 해결했습니다.

    검증 및 결과: AWX로 K3s 자동화하기

    여러 삽질 끝에 드디어 AWX가 K3s 클러스터 위에 성공적으로 배포되었습니다! 🎉 이제 웹 브라우저를 열고 설정했던 ingress_host로 접속하면 AWX 로그인 화면이 보일 겁니다. 초기 관리자 비밀번호는 AWX Operator가 Secret(시크릿)으로 생성해두는데, 다음 명령어로 확인할 수 있습니다.

    kubectl get secret my-awx-admin-password -o jsonpath='{.data.password}' | base64 --decode

    로그인 후, 저는 간단한 Ansible 플레이북을 만들어서 K3s 클러스터의 노드 목록을 조회하는 작업을 자동화해봤습니다. AWX에서 Project(프로젝트), Inventory(인벤토리), Credential(자격 증명)을 설정하고 Job Template(잡 템플릿)을 생성한 뒤 실행하니, 깔끔하게 K3s 노드 정보가 출력되는 것을 확인할 수 있었습니다. 이 화면을 보는 순간, 그동안의 고생이 눈 녹듯 사라지더라고요! 정말 뿌듯했어요. 😄

    AWX 웹 UI에서 K3s 노드 목록을 조회하는 Ansible 잡이 성공적으로 실행된 결과 화면

    AWX 웹 UI에서 Ansible 플레이북이 성공적으로 실행되어 K3s 클러스터의 노드 목록을 출력하는 잡 실행 결과 화면 스크린샷입니다. 초록색 성공 메시지와 함께 결과가 표시됩니다.

    마무리: 경량 Kubernetes 자동화, 여러분도 해보세요!

    K3s와 AWX를 통합하여 경량 Kubernetes 환경에서 자동화 워크플로우를 구축한 경험은 저에게 정말 값진 시간이었습니다. 비록 중간중간 삽질도 많이 했지만, 그 과정에서 얻은 지식과 해결 능력은 어떤 책에서도 배울 수 없는 것이었거든요.

    주요 배운 점:

    • K3s는 가볍지만, AWX처럼 리소스를 많이 쓰는 애플리케이션을 올릴 때는 충분한 하드웨어 리소스 계획이 필요하다는 것.
    • Persistent Volume 설정은 안정적인 운영을 위한 핵심이라는 것. (홈랩이라도 NFS는 정말 중요합니다.)
    • Kubernetes Ingress와 DNS 설정은 항상 꼼꼼하게 확인해야 한다는 것.
    • AWX Operator를 사용하면 복잡한 AWX 배포를 Kubernetes 스타일로 정말 간단하게 할 수 있다는 것.

    이 조합은 특히 저처럼 홈랩을 운영하거나, 소규모 팀에서 효율적인 인프라 자동화를 목표로 할 때 정말 강력한 솔루션이 될 수 있다고 확신합니다. 여러분도 직접 K3s와 AWX를 설치하고 이것저것 만져보면서 자신만의 자동화 워크플로우를 구축해보시길 강력히 추천합니다. 직접 해보면서 얻는 경험만큼 값진 건 없으니까요! 💪

    다음 글에서는 AWX를 이용한 좀 더 복잡한 GitOps(깃옵스) 파이프라인 구축에 대해 더 깊이 다뤄볼 예정입니다. 기대해주세요! 😄

    K3s와 AWX 통합으로 얻을 수 있는 주요 장점을 시각적으로 요약한 인포그래픽

    K3s와 AWX 통합의 주요 장점 (예: 리소스 효율성, 중앙 집중식 자동화, 빠른 배포, 간편한 관리)을 시각적으로 요약한 인포그래픽입니다.

  • [k8s] AWX로 쿠버네티스 워크플로우 자동화: 실전 가이드

    [k8s] AWX로 쿠버네티스 워크플로우 자동화: 실전 가이드

    안녕하세요, 13년차 인프라 엔지니어 ’13년차의 서버실’ 주인장입니다. 오늘은 많은 분들이 고민하시는 쿠버네티스(Kubernetes) 워크플로우 자동화에 대해 이야기해보려고 해요. 특히 AWX를 활용해서 어떻게 복잡한 배포 과정을 효율적으로 관리할 수 있는지, 제가 직접 겪었던 경험과 실전 사례를 중심으로 풀어볼까 합니다. Ansible과 DevOps 문화에 관심 있는 분들이라면 이번 글이 정말 도움이 될 거예요.

    저도 처음엔 쿠버네티스 클러스터에 애플리케이션을 배포하는 과정이 꽤나 번거롭더라고요. 매번 kubectl apply -f 명령어를 입력하고, 버전 관리하고, 환경별로 설정 바꾸고… 반복적인 작업은 언제나 실수의 여지를 남기기 마련이잖아요. 그러다 보니 자연스럽게 자동화의 필요성을 느끼게 됐고, 홈랩에서 AWX(Ansible Workflow eXecutor)를 활용한 솔루션을 모색하게 됐습니다. 직접 삽질해가며 구축했던 과정, 지금부터 솔직하게 공유해볼게요.

    AWX와 쿠버네티스 연동을 통한 워크플로우 자동화 개요 아키텍처 다이어그램, AWX가 Git에서 Ansible Playbook을 가져와 쿠버네티스에 배포하는 과정을 보여줍니다.

    AWX와 쿠버네티스 연동을 통한 워크플로우 자동화 개요 아키텍처 다이어그램. AWX가 Git 저장소에서 Ansible Playbook을 가져와 쿠버네티스 API를 통해 리소스를 배포하는 과정을 보여줍니다.

    AWX와 쿠버네티스, 왜 함께 써야 할까요?

    먼저 핵심 개념부터 짚고 넘어갈게요. AWX는 Ansible Automation Platform의 업스트림 오픈소스 프로젝트로, 웹 기반 UI를 통해 Ansible Playbook을 실행하고 관리해주는 도구예요. 쉽게 말해, 터미널에서 명령어로 실행하던 Ansible 작업을 UI로 편하게 스케줄링하고, 권한을 관리하고, 실행 결과를 모니터링할 수 있다는 거죠. 제가 홈랩에서 다양한 자동화 실험을 할 때 정말 유용하게 써먹고 있는 녀석입니다.

    그리고 쿠버네티스(Kubernetes, K8s)는 컨테이너화된 워크로드와 서비스를 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템이에요. 컨테이너 오케스트레이션(Container Orchestration)의 사실상 표준이 되었죠. 선언적(Declarative) 방식으로 원하는 상태를 정의하면, 쿠버네티스가 그 상태를 유지하도록 알아서 관리해줍니다. 저는 주로 Deployment(디플로이먼트)와 Service(서비스), Ingress(인그레스, 외부 트래픽 진입점) 같은 리소스들을 YAML 파일로 정의해서 사용하고 있어요.

    이 둘을 함께 쓰면 어떤 시너지가 생길까요? 바로 선언적 인프라(Declarative Infrastructure) 관리가 가능해진다는 거예요. Ansible Playbook으로 쿠버네티스 리소스의 최종 상태를 정의하고, AWX가 이 Playbook을 실행해서 클러스터에 배포하는 방식이죠. 이렇게 하면 수동 작업으로 인한 오류를 줄이고, 배포 과정을 표준화하며, 지속적인 통합/배포(CI/CD) 워크플로우를 구축하는 데 정말 큰 도움이 돼요. 실제 운영 환경에서 이 조합은 정말 강력하더라고요.

    실전 구현: AWX로 쿠버네티스 워크플로우 자동화하기

    자, 그럼 이제 제가 직접 구축했던 방법을 단계별로 보여드릴게요. 목표는 AWX를 통해 간단한 Nginx 웹 서버를 쿠버네티스 클러스터에 배포하고, 외부에 노출시키는 거예요.

    1단계: AWX 환경 설정

    1. 인벤토리(Inventory) 생성: AWX에서 Playbook을 실행할 대상(Host)을 정의합니다. 여기서는 쿠버네티스 클러스터의 API 서버에 접근해야 하므로, 로컬 호스트를 대상으로 하거나, 쿠버네티스 API 엔드포인트를 지정해요. 저는 주로 localhost를 대상으로 하고, kubeconfig 파일을 통해 클러스터에 접근하는 방식을 선호합니다.
    2. 자격 증명(Credential) 생성: 쿠버네티스 클러스터에 접근하기 위한 자격 증명이 필요해요. kubeconfig 파일을 AWX에 등록하는 방법이 가장 일반적입니다.
    # AWX Credential 설정 예시 (Kubeconfig Type)
    # --- Kubeconfig 내용 --- (실제 파일 내용)
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: ...
        server: https://your-kubernetes-api-server:6443
      name: my-cluster
    contexts:
    - context:
        cluster: my-cluster
        user: my-user
      name: my-context
    current-context: my-context
    kind: Config
    preferences: {}
    users:
    - name: my-user
      user:
        client-certificate-data: ...
        client-key-data: ...
    

    2단계: Ansible Playbook 작성

    쿠버네티스 리소스를 배포하기 위한 Playbook을 작성해요. Ansible이 제공하는 kubernetes.core.k8s 모듈로 쿠버네티스 리소스 관리가 정말 쉬워진다니까요. 저는 Nginx Deployment와 Service를 배포하는 Playbook을 만들었어요.

    # playbook.yaml
    ---
    - name: Deploy Nginx to Kubernetes
      hosts: localhost
      connection: local
      collections:
        - kubernetes.core
    
      vars:
        namespace: default
        app_name: my-nginx
        image_version: 1.25.3
    
      tasks:
        - name: Ensure Namespace exists
          kubernetes.core.k8s:
            api_version: v1
            kind: Namespace
            name: "{{ namespace }}"
            state: present
    
        - name: Deploy Nginx Deployment
          kubernetes.core.k8s:
            state: present
            definition: |
              apiVersion: apps/v1
              kind: Deployment
              metadata:
                name: "{{ app_name }}-deployment"
                namespace: "{{ namespace }}"
                labels:
                  app: "{{ app_name }}"
              spec:
                replicas: 2
                selector:
                  matchLabels:
                    app: "{{ app_name }}"
                template:
                  metadata:
                    labels:
                      app: "{{ app_name }}"
                  spec:
                    containers:
                    - name: "{{ app_name }}"
                      image: nginx:"{{ image_version }}"
                      ports:
                      - containerPort: 80
    
        - name: Expose Nginx Service
          kubernetes.core.k8s:
            state: present
            definition: |
              apiVersion: v1
              kind: Service
              metadata:
                name: "{{ app_name }}-service"
                namespace: "{{ namespace }}"
                labels:
                  app: "{{ app_name }}"
              spec:
                selector:
                  app: "{{ app_name }}"
                ports:
                  - protocol: TCP
                    port: 80
                    targetPort: 80
                type: NodePort # 또는 LoadBalancer, ClusterIP 등 환경에 맞게
    

    이 Playbook을 Git 저장소(예: GitHub, GitLab)에 커밋해요. AWX가 이 저장소에서 Playbook을 가져와 실행할 거거든요.

    3단계: AWX 프로젝트 및 작업 템플릿(Job Template) 설정

    AWX UI에서 다음을 설정합니다.

    1. 프로젝트(Project) 생성: Git 저장소를 연결하여 Playbook을 가져와요.
    2. 작업 템플릿(Job Template) 생성: 이 템플릿에 위에서 만든 인벤토리, 자격 증명, 프로젝트, 그리고 실행할 Playbook 파일(playbook.yaml)을 연결합니다.
    AWX 작업 템플릿 설정 화면 스크린샷, Git 프로젝트, 인벤토리, 쿠버네티스 자격 증명, 실행할 Playbook 파일을 지정하는 모습

    AWX 작업 템플릿 설정 화면 스크린샷. Git 프로젝트, 인벤토리, 쿠버네티스 자격 증명, 실행할 Playbook 파일을 지정하는 모습을 보여줍니다.

    ⚠️ 삽질 경험 & 워크플로우 자동화 트러블슈팅

    제가 이 AWX와 쿠버네티스 자동화 과정을 진행하면서 겪었던 몇 가지 삽질과 그 해결책을 공유할게요. 혹시 비슷한 문제를 겪는 분들이 있다면 도움이 될 거예요.

    • 인증 오류 (Authentication Error): 가장 흔한 문제 중 하나예요. kubeconfig 파일의 권한 문제, 또는 파일 내용 자체가 잘못된 경우가 많았어요. 특히 client-certificate-data와 client-key-data가 정확한 base64 인코딩 값인지 여러 번 확인했거든요. AWX가 실행되는 컨테이너 환경에서 kubeconfig 파일에 접근 권한이 없어서 생기는 경우도 있었고요. 💡 팁: AWX 컨테이너 내부에서 kubectl get pods를 직접 실행해보며 인증 문제를 디버깅해보세요.
    • YAML 문법 오류: 쿠버네티스 리소스 정의는 YAML 파일로 하는데, 들여쓰기나 오타 하나로도 워크플로우가 실행 안 돼요. 특히 Ansible Playbook 내 definition 블록 안에 YAML을 넣을 때는 더욱 주의해야 합니다. ⚠️ 경고: definition: | 다음 줄부터는 반드시 두 칸 이상 들여쓰기 해야 합니다!
    • Ansible kubernetes.core.k8s 모듈 문제: 처음에는 이 모듈을 쓰는 게 익숙하지 않아서 헤맸어요. 특히 state: present로 리소스를 생성하고, state: absent로 삭제하는 방식에 익숙해지는 데 시간이 좀 걸렸거든요. 그리고 kubeconfig 파일 경로를 명시적으로 지정해야 하는 경우도 있었습니다 (kubeconfig: /path/to/kubeconfig).
    • 네트워크 연결 문제: AWX가 쿠버네티스 API 서버에 접근할 수 없는 네트워크 환경일 경우 당연히 실패하죠. 방화벽 규칙이나 네트워크 정책을 다시 확인해야 해요.

    ✅ 결과 검증 및 자동화의 힘!

    모든 설정이 끝나면, AWX UI에서 작업 템플릿을 실행(Launch)해요. Playbook이 성공적으로 실행되면 AWX 작업 로그에서 초록색 SUCCESS 메시지를 확인할 수 있어요. 저도 이 메시지를 처음 봤을 때, “드디어 됐다!” 하고 쾌재를 불렀던 기억이 생생해요.

    이제 쿠버네티스 클러스터에서 실제로 리소스가 배포되었는지 확인해볼 차례입니다.

    
    kubectl get deployments -n default
    # NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
    # my-nginx-deployment   2/2     2            2           2m
    
    kubectl get services -n default
    # NAME              TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
    # my-nginx-service   NodePort   10.96.123.456   <none>        80:3xxxx/TCP   2m
    

    정상적으로 Nginx Deployment와 Service가 생성된 걸 확인할 수 있어요. 이제 NodePort로 할당된 포트를 통해 Nginx 웹 서버에 접속하면 “Welcome to Nginx!” 페이지를 볼 수 있을 거예요. 🎉 정말 편리하지 않나요? 몇 번의 클릭만으로 쿠버네티스에 애플리케이션을 배포하는 워크플로우 자동화가 완성된 거죠.

    AWX 작업 성공 로그와 kubectl get pods/deployments 명령 결과 비교 화면, AWX의 성공적인 Task 완료와 쿠버네티스 배포 리소스 확인

    AWX 작업 성공 로그와 kubectl get pods/deployments 명령 결과 비교 화면. AWX의 Job Output에서 Task가 성공적으로 완료된 것을 보여주고, 터미널에서 kubectl 명령어로 배포된 리소스들을 확인하는 모습을 나란히 보여줍니다.

    마무리하며: 자동화, 멈추지 않는 여정

    이번 AWX와 쿠버네티스 연동 사례를 통해 워크플로우 자동화가 얼마나 강력한지 다시 한번 느꼈어요. 단순한 배포를 넘어, IaC(Infrastructure as Code, 코드형 인프라)의 개념을 실현하고, DevOps 파이프라인의 핵심 구성 요소로 활용할 수 있다는 것이 핵심이죠.

    인프라 엔지니어로서 제가 얻은 가장 큰 교훈은 “반복되는 작업은 무조건 자동화하라”는 거예요. 처음엔 자동화 스크립트 작성에 시간이 들지언정, 장기적으로는 시간과 노력을 아끼고, 휴먼 에러를 줄여준다는 걸 뼈저리게 경험했거든요. 이 경험이 여러분의 인프라 관리에도 작은 영감이 되기를 바랍니다.

    다음 글에서는 이 워크플로우를 확장해서 Ingress 컨트롤러를 배포하고, 외부 도메인으로 서비스에 접근하는 방법을 다뤄볼까 해요. 기대해주세요!

    AWX, Ansible, Kubernetes, DevOps 로고들이 원형으로 배치된 인포그래픽. 각 로고들이 서로 연결되어 워크플로우 자동화를 이루는 모습을 시각적으로 보여줍니다.