13년차의 서버실

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

[태그:] 클라우드 자동화

  • [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와 클라우드 인프라 자동화의 미래 비전 인포그래픽

  • [Cloud] Terraform vs Pulumi: IaC 도구 비교 및 선택 가이드

    IaC 도구 선택, 생각보다 중요한 문제입니다

    인프라를 코드로 관리하기 시작한 게 벌써 7~8년 전 일인데요, 그때만 해도 Terraform(테라폼)이 사실상 IaC(Infrastructure as Code, 인프라를 코드로 관리하는 방식)의 표준처럼 여겨졌습니다. 그런데 최근 몇 년 사이에 Pulumi(풀루미)가 치고 올라오면서 팀 내에서도 “우리 이제 Pulumi로 갈아타야 하는 거 아니야?“라는 얘기가 슬슬 나오기 시작하더라고요.

    저도 처음엔 “또 새로운 도구 나왔네” 하고 넘겼는데, 실제로 홈랩에서 Terraform과 Pulumi를 나란히 써보면서 생각이 좀 바뀌었습니다. 단순히 어느 게 더 낫다는 게 아니라, 팀 상황과 사용 목적에 따라 선택이 완전히 달라지는 도구라는 걸 직접 느꼈거든요.

    이 글에서는 Terraform vs Pulumi를 실제 사용 경험을 바탕으로 비교해드리려고 합니다. IaC 도구 비교 글들이 많긴 한데, 대부분 공식 문서 요약 수준이라 아쉬웠거든요. 실무에서 어떤 차이가 나는지 한번 풀어볼게요.

    ▲ Terraform과 Pulumi — 둘 다 훌륭한 IaC 도구지만, 철학이 다릅니다

    Terraform과 Pulumi, 각각 어떤 도구인가요?

    Terraform — HCL로 선언하는 인프라

    Terraform은 HashiCorp(해시코프)가 만든 오픈소스 IaC 도구입니다. HCL(HashiCorp Configuration Language, 해시코프 설정 언어)이라는 자체 DSL(Domain-Specific Language, 도메인 특화 언어)을 사용하는데요. 쉽게 말해 “이런 인프라가 존재해야 해”라고 선언하면 Terraform이 현재 상태와 비교해서 필요한 작업을 자동으로 처리하는 방식입니다.

    2014년에 처음 나왔으니까 이미 10년이 넘었네요. 덕분에 Provider(프로바이더, 클라우드/서비스 연동 플러그인) 생태계가 정말 풍부합니다. AWS, GCP, Azure는 물론이고 GitHub, Datadog, PagerDuty까지 대부분의 주요 서비스를 지원해요.

    다만 2023년에 HashiCorp가 라이선스를 BSL(Business Source License)로 변경하면서 커뮤니티가 반발했습니다. 이 때문에 OpenTofu(오픈토푸)라는 포크 프로젝트도 생겼어요. 라이선스 정책은 도구 선택 시 꼭 고려해야 할 사항입니다.

    Pulumi — 진짜 프로그래밍 언어로 인프라를

    Pulumi는 2018년에 등장한 IaC 도구인데, Terraform과는 완전히 다른 접근을 취합니다. Python, TypeScript, Go, C#, Java 같은 범용 프로그래밍 언어로 인프라를 정의한다는 게 핵심이에요.

    처음 들었을 땐 “그게 뭐가 좋아?” 싶었는데, 직접 써보니 차이가 꽤 크더라고요. 반복문, 조건문, 함수, 클래스 같은 프로그래밍 언어의 모든 기능을 인프라 코드에 그대로 쓸 수 있거든요. 기존 패키지 생태계(npm, pip 등)도 활용 가능합니다.

    State(상태, 인프라의 현재 상태를 저장하는 파일) 관리는 Pulumi Cloud를 이용하거나, AWS S3나 Azure Blob 같은 스토리지에 직접 저장할 수 있어요.

    핵심 철학 차이: 선언형 vs 명령형

    Terraform과 Pulumi의 가장 근본적인 차이는 선언형(Declarative) vs 명령형(Imperative) 접근 방식입니다. 이 차이가 실제 개발 경험에 큰 영향을 미칩니다.

    항목 Terraform Pulumi
    언어 HCL (자체 DSL) Python, TypeScript, Go, C#, Java 등
    패러다임 선언형 (Declarative) 선언형 + 명령형 혼합
    State 관리 로컬 파일 또는 원격 Backend Pulumi Cloud 또는 자체 Backend
    라이선스 BSL 1.1 (2023년 변경) Apache 2.0
    Provider 생태계 매우 풍부 (수천 개) 풍부 (Terraform Provider 재활용 가능)
    학습 곡선 HCL 문법 별도 학습 필요 기존 언어 지식 활용 가능
    테스트 별도 도구 필요 (Terratest 등) 기존 테스트 프레임워크 활용
    IDE 지원 플러그인 필요 언어별 IDE 지원 그대로

    실제 코드로 보는 Terraform vs Pulumi 차이

    말로만 설명하면 와닿지 않으니까, 같은 작업을 두 도구로 작성한 코드를 비교해볼게요. AWS S3 버킷 3개를 만드는 간단한 예시입니다.

    Terraform 방식 — count와 for_each

    Terraform에서 여러 리소스를 만들려면 count나 for_each를 써야 합니다. 처음엔 문법이 좀 낯설 수 있어요.

    # variables.tf
    variable "bucket_names" {
      type    = list(string)
      default = ["my-app-logs", "my-app-backups", "my-app-temp"]
    }
    
    # main.tf
    resource "aws_s3_bucket" "app_buckets" {
      for_each = toset(var.bucket_names)
      bucket   = each.value
    }
    
    resource "aws_s3_bucket_versioning" "app_buckets" {
      for_each = aws_s3_bucket.app_buckets
      bucket   = each.value.id
    
      versioning_configuration {
        status = "Enabled"
      }
    }

    Pulumi 방식 — 프로그래밍 언어처럼

    Pulumi에서는 Python으로 같은 작업을 이렇게 씁니다. 훨씬 직관적이죠?

    import pulumi
    import pulumi_aws as aws
    
    bucket_names = ["my-app-logs", "my-app-backups", "my-app-temp"]
    
    for bucket_name in bucket_names:
        bucket = aws.s3.Bucket(
            bucket_name,
            bucket=bucket_name
        )
        
        versioning = aws.s3.BucketVersioning(
            f"{bucket_name}-versioning",
            bucket=bucket.id,
            versioning_configuration={
                "status": "Enabled"
            }
        )

    Pulumi 코드가 더 간결하고 읽기 쉽지 않나요? 이게 바로 범용 프로그래밍 언어를 쓰는 장점입니다. 변수, 함수, 클래스 등 익숙한 개념들을 그대로 활용할 수 있거든요.

  • [Cloud] Ansible로 멀티 클라우드 인프라 자동화: AWS, Azure, GCP 통합 관리 가이드

    [Cloud] Ansible로 멀티 클라우드 인프라 자동화: AWS, Azure, GCP 통합 관리 가이드

    Ansible로 멀티 클라우드 인프라 자동화: AWS, Azure, GCP 통합 관리 가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 요즘 인프라 환경을 보면 단순히 한 클라우드에만 갇혀 있지 않죠? 멀티 클라우드(Multi-Cloud)는 이제 선택이 아니라 필수가 되어가는 시대인 것 같습니다. 저도 처음엔 AWS만 주력으로 썼었는데, 프로젝트가 커지고 요구사항이 다양해지면서 Azure나 GCP도 함께 다루게 되더라고요. 근데 이게 여러 클라우드를 동시에 관리하려니 여간 복잡한 게 아니었습니다. 각 클라우드마다 CLI도 다르고, API도 다르고… 수동으로 관리하다가는 퇴근은커녕 야근만 늘겠다 싶었죠. 😭

    이런 고민을 하던 중에 저의 든든한 동반자, Ansible(앤서블)을 떠올렸습니다. Ansible은 이미 온프레미스 환경에서 서버 자동화에 요긴하게 써왔던 도구거든요. ‘이걸로 멀티 클라우드도 통합 관리할 수 있지 않을까?’ 하는 생각에 홈랩에서 이것저것 실험해봤습니다. 결과는 대만족이었습니다! 오늘은 제가 직접 경험하며 삽질했던 내용과 함께, Ansible로 AWS, Azure, GCP 인프라를 한 번에 자동화하는 방법을 여러분께 알려드리려고 합니다. 이 글을 통해 멀티 클라우드 관리의 복잡성을 확 줄여보시길 바랍니다. 자, 그럼 시작해볼까요? 🎉

    Ansible을 활용한 멀티 클라우드 통합 관리 아키텍처 다이어그램.

    Ansible, 왜 멀티 클라우드 자동화에 최적일까요?

    먼저 Ansible이 어떤 녀석인지, 그리고 왜 멀티 클라우드 환경에 딱 맞는지 간단히 짚고 넘어가죠. 쉽게 말해 Ansible(앤서블)은 에이전트리스(Agentless) 기반의 자동화 도구(Automation Tool)입니다. 관리 대상 서버에 별도의 에이전트를 설치할 필요 없이 SSH(Secure Shell)나 WinRM(Windows Remote Management) 프로토콜을 이용해 명령을 실행하죠. 이게 멀티 클라우드 환경에서 엄청난 강점입니다.

    • 단일 제어 플레인(Single Control Plane): 각 클라우드 콘솔이나 CLI를 오갈 필요 없이, Ansible 컨트롤러 노드(Control Node) 하나에서 모든 클라우드 인프라를 관리할 수 있습니다.
    • 모듈(Modules) 기반의 추상화: Ansible은 각 클라우드 프로바이더(Cloud Provider)별로 수많은 모듈을 제공합니다. 예를 들어, AWS EC2 인스턴스를 만들 때는 amazon.aws.ec2_instance 모듈을, Azure VM을 만들 때는 azure.azcollection.azure_rm_virtualmachine 모듈을 사용하죠. 각 클라우드 API의 복잡성을 몰라도 모듈만 잘 사용하면 됩니다.
    • 멱등성(Idempotency): 플레이북(Playbook)을 여러 번 실행해도 항상 동일한 최종 상태(Desired State)를 보장합니다. 이미 생성된 리소스는 건드리지 않고, 필요한 변경사항만 적용되니 안심하고 재실행할 수 있습니다.
    • YAML(YAML Ain’t Markup Language) 기반의 쉬운 학습 곡선: 복잡한 프로그래밍 언어 대신 사람이 읽고 쓰기 쉬운 YAML 문법으로 플레이북을 작성합니다. 인프라 엔지니어에게는 정말 친숙한 방식이죠.

    결론적으로 Ansible은 코드로서의 인프라(Infrastructure as Code, IaC)를 구현하기에 아주 적합하며, 특히 이종 클라우드 환경을 통합 관리하는 데 강력한 성능을 발휘합니다.

    실전 구현: AWS, Azure, GCP 인프라 자동화

    자, 이제 직접 Ansible로 멀티 클라우드 인프라를 구축해볼 차례입니다. 목표는 각 클라우드에 웹 서버 역할을 할 가상 머신(Virtual Machine)을 하나씩 생성하고, 간단한 웹 서비스(Nginx)를 설치하는 것입니다.

    1. Ansible 및 클라우드 연동 환경 설정

    먼저 Ansible 컨트롤러 노드에 필요한 도구들을 설치해야 합니다. 저는 Ubuntu 환경에서 진행했습니다.

    #!/bin/bash
    # Ansible 설치
    sudo apt update && sudo apt install -y ansible python3-pip
    
    # AWS 연동을 위한 boto3 라이브러리 설치
    pip3 install boto3 botocore
    
    # Azure 연동을 위한 Azure CLI 및 모듈 설치
    sudo apt install -y azure-cli
    ansible-galaxy collection install azure.azcollection
    
    # GCP 연동을 위한 Google Cloud SDK 및 모듈 설치
    echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
    sudo apt update && sudo apt install -y google-cloud-sdk
    ansible-galaxy collection install google.cloud
    

    각 클라우드 인증 정보 설정도 중요합니다:

    • AWS: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY 환경 변수 설정 또는 ~/.aws/credentials 파일 설정
    • Azure: az login 명령으로 로그인 또는 서비스 주체(Service Principal) 생성 후 환경 변수 설정
    • GCP: 서비스 계정(Service Account) 키 파일 다운로드 후 GOOGLE_APPLICATION_CREDENTIALS 환경 변수 설정

    ⚠️ 인증 정보 관리 중요: 실제 운영 환경에서는 AWS Secrets Manager, Azure Key Vault, GCP Secret Manager 같은 비밀 관리 서비스(Secret Management Service)를 활용하거나 Ansible Vault를 사용하여 인증 정보를 안전하게 보관해야 합니다. 절대 민감한 정보를 플레이북에 직접 넣지 마세요!

    2. 동적 인벤토리(Dynamic Inventory) 설정

    클라우드 환경은 리소스가 수시로 생성/삭제되기 때문에 고정된 인벤토리 파일보다는 동적 인벤토리를 사용하는 것이 효율적입니다. Ansible은 각 클라우드 프로바이더를 위한 동적 인벤토리 플러그인을 제공하거든요.

    # aws_ec2.yml (AWS EC2 인스턴스 동적 인벤토리)
    plugin: amazon.aws.ec2
    regions:
      - ap-northeast-2
    keyed_groups:
      - key: tags.env
        prefix: env_
    
    # azure_rm.yml (Azure VM 동적 인벤토리)
    plugin: azure.azcollection.azure_rm
    include_vm_resource_groups:
      - my-ansible-rg
    
    # gcp_compute.yml (GCP Compute Engine 동적 인벤토리)
    plugin: google.cloud.gcp_compute
    projects:
      - your-gcp-project-id
    zones:
      - asia-northeast3-a
    

    이제 ansible-inventory -i aws_ec2.yml --list 등으로 각 클라우드의 인벤토리를 확인할 수 있습니다.

    Ansible으로 생성된 각 클라우드 가상 머신 목록.

    3. 클라우드 리소스 생성 플레이북 작성

    각 클라우드에 가상 머신을 생성하고 Nginx를 설치하는 플레이북입니다. 하나의 플레이북에서 여러 클라우드를 대상으로 할 수 있다는 점이 핵심입니다.

    ---
    # multi_cloud_infra.yml
    # AWS, Azure, GCP에 동시에 웹 서버를 배포하는 플레이북
    
    - name: AWS 인프라 준비
      hosts: localhost
      connection: local
      gather_facts: no
    
      vars:
        aws_region: ap-northeast-2
        ssh_key_path: ~/.ssh/id_rsa.pub
    
      tasks:
        # AWS Security Group 먼저 생성
        - name: AWS 보안 그룹 생성
          amazon.aws.ec2_security_group:
            name: ansible-sg-aws
            description: "Ansible managed AWS webserver security group"
            region: "{{ aws_region }}"
            rules:
              - proto: tcp
                ports: 22
                cidr_ip: 0.0.0.0/0
              - proto: tcp
                ports: 80
                cidr_ip: 0.0.0.0/0
            rules_egress:
              - proto: all
                cidr_ip: 0.0.0.0/0
          register: aws_sg_output
    
        # AWS EC2 인스턴스 생성
        - name: AWS EC2 인스턴스 생성
          amazon.aws.ec2_instance:
            name: ansible-aws-webserver
            image_id: ami-0c802847a7dd848c0  # Ubuntu 22.04 LTS (ap-northeast-2)
            instance_type: t2.micro
            region: "{{ aws_region }}"
            security_group: ansible-sg-aws
            key_name: your_aws_keypair
            tags:
              env: dev
              project: ansible-multi-cloud
            state: running
            wait: yes
          register: aws_ec2_output
    
    - name: Azure 인프라 준비
      hosts: localhost
      connection: local
      gather_facts: no
    
      vars:
        azure_resource_group: my-ansible-rg
        azure_location: koreacentral
        ssh_key_path: ~/.ssh/id_rsa.pub
    
      tasks:
        # Azure Virtual Network 생성 (필수 선행 작업)
        - name: Azure Virtual Network 생성
          azure.azcollection.azure_rm_virtualnetwork:
            resource_group: "{{ azure_resource_group }}"
            name: ansible-vnet
            location: "{{ azure_location }}"
            address_prefixes:
              - "10.0.0.0/16"
          register: azure_vnet_output
    
        # Azure Subnet 생성
        - name: Azure Subnet 생성
          azure.azcollection.azure_rm_subnet:
            resource_group: "{{ azure_resource_group }}"
            name: default
            address_prefix: "10.0.0.0/24"
            virtual_network: ansible-vnet
          register: azure_subnet_output
    
        # Azure NSG 생성
        - name: Azure 네트워크 보안 그룹 생성
          azure.azcollection.azure_rm_networksecuritygroup:
            resource_group: "{{ azure_resource_group }}"
            name: ansible-azure-nsg
            location: "{{ azure_location }}"
            rules:
              - name: AllowSSH
                protocol: Tcp
                destination_port_range: 22
                access: Allow
                priority: 100
                direction: Inbound
              - name: AllowHTTP
                protocol: Tcp
                destination_port_range: 80
                access: Allow
                priority: 110
                direction: Inbound
          register: azure_nsg_output
    
        # Azure VM 생성
        - name: Azure VM 생성
          azure.azcollection.azure_rm_virtualmachine:
            resource_group: "{{ azure_resource_group }}"
            name: ansible-azure-webserver
            vm_size: Standard_B1s
            admin_username: azureuser
            ssh_password_enabled: false
            ssh_public_keys:
              - path: /home/azureuser/.ssh/authorized_keys
                key_data: "{{ lookup('file', ssh_key_path) }}"
            image:
              offer: 0001-com-ubuntu-server-jammy
              publisher: Canonical
              sku: 22_04-lts-gen2
              version: latest
            location: "{{ azure_location }}"
          register: azure_vm_output
    
    - name: GCP 인프라 준비
      hosts: localhost
      connection: local
      gather_facts: no
    
      vars:
        gcp_project: your-gcp-project-id
        gcp_zone: asia-northeast3-a
        gcp_network: default
        ssh_key_path: ~/.ssh/id_rsa.pub
        gcp_user: ansible
    
      tasks:
        # GCP Firewall 규칙 생성
        - name: GCP 방화벽 규칙 생성
          google.cloud.gcp_compute_firewall:
            name: ansible-gcp-allow-http-ssh
            project: "{{ gcp_project }}"
            allowed:
              - IPProtocol: tcp
                ports: [ '22', '80' ]
            source_ranges: [ '0.0.0.0/0' ]
            target_tags: [ 'http-server' ]
            state: present
          register: gcp_fw_output
    
        # GCP Compute Engine 인스턴스 생성
        - name: GCP Compute Engine 인스턴스 생성
          google.cloud.gcp_compute_instance:
            name: ansible-gcp-webserver
            project: "{{ gcp_project }}"
            zone: "{{ gcp_zone }}"
            machine_type: e2-micro
            disks:
              - auto_delete: 'true'
                boot: 'true'
                initialize_params:
                  source_image: projects/ubuntu-os-cloud/global/images/family/ubuntu-2204-lts
                  disk_size_gb: 20
            network_interfaces:
              - name: "{{ gcp_network }}"
                access_configs:
                  - name: "External NAT"
                    type: "ONE_TO_ONE_NAT"
            metadata:
              ssh-keys: "{{ gcp_user }}:{{ lookup('file', ssh_key_path) }}"
            tags:
              items:
                - http-server
            state: present
          register: gcp_instance_output
    
    - name: 모든 클라우드 웹서버에 Nginx 설치
      hosts: all
      gather_facts: yes
    
      pre_tasks:
        - name: SSH 연결 대기
          ansible.builtin.wait_for_connection:
            timeout: 300
    
      tasks:
        - name: Nginx 설치
          ansible.builtin.apt:
            name: nginx
            state: present
            update_cache: yes
          become: yes
    
        - name: Nginx 서비스 시작
          ansible.builtin.service:
            name: nginx
            state: started
            enabled: yes
          become: yes
    

    위 플레이북은 각 클라우드별로 분리된 구조로 작성되어 있습니다. 첫 번째부터 세 번째까지는 각각 AWS, Azure, GCP 인프라를 생성하는 hosts: localhost 플레이북입니다. 마지막 플레이북은 동적 인벤토리에서 수집된 모든 호스트에 Nginx를 설치합니다.

    플레이북 실행은 간단합니다:

    ansible-playbook -i aws_ec2.yml -i azure_rm.yml -i gcp_compute.yml multi_cloud_infra.yml
    

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

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

    1. 클라우드 인증 실패

    문제: 플레이북 실행 시 Unauthorized, Access Denied, Credential Error 같은 메시지가 뜨면서 클라우드 리소스 생성이 안 되는 경우가 많았습니다.

    해결:

    • AWS: ~/.aws/credentials 파일의 내용이 정확한지, 또는 환경 변수(AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)가 올바르게 설정되었는지 확인했습니다. 그리고 해당 IAM 사용자에게 EC2 생성, Security Group 관리 등 필요한 권한이 제대로 부여되었는지 IAM 정책을 검토했습니다.
    • Azure: az login으로 로그인 세션이 유효한지 확인하거나, 서비스 주체(Service Principal)를 사용한다면 AZURE_CLIENT_ID, AZURE_SECRET, AZURE_TENANT, AZURE_SUBSCRIPTION_ID 환경 변수가 정확한지 확인했습니다. 해당 서비스 주체에 기여자(Contributor) 또는 그에 준하는 역할이 할당되어야 합니다.
    • GCP: 서비스 계정 키 파일(JSON)의 경로가 GOOGLE_APPLICATION_CREDENTIALS 환경 변수에 올바르게 지정되었는지 확인했습니다. 또한, 서비스 계정에 Compute Engine Instance Admin (v1), Service Account User 등 필요한 역할이 부여되어 있는지 GCP IAM 콘솔에서 확인했습니다.

    2. SSH 접속 문제 (Nginx 설치 단계)

    문제: 인스턴스는 잘 생성됐는데, Nginx 설치 단계에서 SSH Connection refused 또는 Timeout 에러가 발생했습니다.

    해결:

    • 보안 그룹/방화벽 규칙: 각 클라우드에서 생성된 가상 머신의 보안 그룹(AWS), 네트워크 보안 그룹(Azure), 방화벽 규칙(GCP)에 Ansible 컨트롤러 노드의 IP 주소 또는 0.0.0.0/0(테스트용)에서 22번 포트(SSH) 접속을 허용하는 규칙이 있는지 확인했습니다.
    • SSH 키페어: 플레이북에서 지정한 ssh_key_path의 퍼블릭 키가 각 클라우드 인스턴스에 올바르게 등록되었는지 확인했습니다. AWS는 키페어 이름을, Azure/GCP는 직접 퍼블릭 키 내용을 전달하는 방식이므로 차이에 유의했습니다.
    • 사용자 이름: 각 클라우드 인스턴스의 기본 사용자 이름이 다릅니다. AWS Ubuntu는 ubuntu, Azure Ubuntu는 azureuser, GCP Ubuntu는 ubuntu로 설정했습니다. 플레이북에 ansible_user: 사용자명으로 명시하면 더 안전합니다.
    • 인스턴스 부팅 시간: 가끔 인스턴스가 완전히 부팅되기 전에 Ansible이 SSH 접속을 시도하여 실패하는 경우가 있습니다. ansible.builtin.wait_for_connection 모듈을 사용해 SSH 포트가 열릴 때까지 기다리도록 플레이북에 추가했습니다. 이건 정말 중요해요!

    3. Azure 네트워크 구성 누락

    문제: Azure VM을 생성하려니 Virtual Network와 Subnet이 없다고 에러가 나왔습니다.

    해결: Azure는 AWS나 GCP와 달리 기본 네트워크 구조가 없으므로, VM 생성 전에 Virtual Network와 Subnet을 명시적으로 생성해야 합니다. 위의 플레이북에서 이를 추가했으니 참고하세요.

    검증 및 결과 확인 ✅

    플레이북 실행이 성공적으로 완료되었다면, 이제 각 클라우드 콘솔에 접속하여 리소스가 잘 생성되었는지 확인해볼 차례입니다. AWS EC2, Azure VM, GCP Compute Engine 목록에서 ansible-aws-webserver, ansible-azure-webserver, ansible-gcp-webserver라는 이름의 인스턴스가 실행 중인 것을 볼 수 있을 겁니다.

    각 인스턴스의 퍼블릭 IP 주소로 웹 브라우저에서 접속해보세요. Nginx 기본 페이지가 보인다면 성공입니다! 드디어 됐다! 🎉

    이 과정에서 여러분이 직접 각 클라우드의 콘솔을 열어 인스턴스를 생성하고, 보안 그룹을 설정하고, SSH로 접속해서 Nginx를 설치하는 수고를 덜 수 있었다는 것을 체감할 수 있을 겁니다. 자동화의 힘은 정말 대단하죠.

    성공적으로 배포된 Nginx 웹 서버 페이지.

    마무리하며: 클라우드 여정의 다음 단계

    오늘은 Ansible을 활용해서 AWS, Azure, GCP 멀티 클라우드 환경에 인프라를 자동화하고 웹 서버를 배포하는 과정을 함께 해봤습니다. 제가 직접 해보니, 처음엔 각 클라우드 모듈과 인증 방식에 적응하는 데 시간이 좀 걸렸지만, 한 번 체계를 잡아두니 그 이후부터는 정말 편하더라고요. 삽질 끝에 얻은 귀한 경험이었습니다. 💡

    이 글이 여러분의 멀티 클라우드 여정에 작은 등대가 되었기를 바랍니다. 여기서 멈추지 않고, 더 나아가 다음과 같은 내용들을 탐구해보시면 좋을 것 같습니다:

    • Ansible Vault: 민감한 정보를 안전하게 관리하는 방법.
    • CI/CD 파이프라인 통합: GitOps 워크플로우를 통해 변경 사항이 자동으로 배포되도록 구성.
    • Terraform과의 연동: Terraform으로 인프라를 프로비저닝하고, Ansible로 프로비저닝된 인스턴스에 소프트웨어를 구성하는 하이브리드 접근 방식.
    • 삭제 플레이북: 생성된 리소스를 깔끔하게 정리하는 삭제 플레이북 작성 (state: absent 활용).

    저도 홈랩에서 이런저런 실험을 계속하면서 새로운 인사이트를 얻고 있습니다. 다음번에는 더 재미있고 유익한 경험담으로 찾아뵙겠습니다. 혹시 이 글을 읽으시면서 궁금한 점이나 공유하고 싶은 삽질 경험이 있으시다면 언제든지 댓글로 남겨주세요! 감사합니다!

    Ansible을 통한 멀티 클라우드 자동화 요약.