안녕하세요, 화해팀에서 데브옵스 엔지니어로 일하고 있는 곽요한입니다. packer   지난 10월 화해 개발팀에서는 전체 엔지니어들이 모이는 제1회 테크 밋업 행사가 있었습니다. 매주 플랫폼 단위로 밋업 행사들이 진행되고 있지만 전체 개발팀이 모두 모인 Meetup Day는 처음 열린 것 같습니다. CTO이신 재광님의 화해에서 개발팀이 추구하는 애자일의 가치와 이를 실현하는 방법 세션을 시작으로 각 플랫폼별로 뽐내고 싶은 주제를 가지고 자유롭게 선정해서 발표하고 이야기 나누는 시간을 가졌습니다.   데브옵스 플랫폼은 서비스 도메인별로 표준화되고 자동화된 서비스 환경을 제공하기 위해 동료들과 많은 고민을 나누며 개발해오고 있습니다. 기존 관리방식의 문제점을 효율적으로 개선하고자 서버 템플릿 도구를 도입했던 내용을 주제로 발표를 했고, 이때 발표했던 내용을 조금 다듬어 이번 콘텐츠를 작성해보았습니다.       표준 서비스 환경의 목적 화해의 서비스 기술 환경은 OS 기반에 각종 애플리케이션 환경을 구성하여 코드를 배포하는 방식으로 구성되어 있습니다.     이러한 환경은 새로운 인프라를 추가할 때 동일하게 구성해야 하는 상황이 빈번하게 발생했기 때문에 자동화가 필요했습니다. 그리고 눈송이 서버(Snowflakes Server)가 되지 않도록 구성하는 모든 과정을 코드로 작성하거나 문서화하여 사전에 인스턴스 이미지로 만들고, 언제든 같은 형태의 인스턴스가 생성될 수 있도록 관리해 나가는 방법이 필요합니다.     SNOWFLAKES SERVER와 PHOENIX SERVER 서버를 구성하고 나면 시간이 지날수록 초기 설정 이후에 변경과 패치 사항이 생겨서 버전별 정보를 관리하기 위해서는 많은 노력이 필요합니다. 하지만 각 개발자가 이를 신경 쓰면서 운영한다는 것은 지속 가능하지 않은 운영 방식인 것 같습니다. 만약 이렇게 이력관리가 되지 않은 상태에서 담당자가 변경되기라도 한다면 더 이상 과거 이력을 추적할 수 없게 되고 눈송이처럼 녹아버려서 다시는 동일한 형태의 서버로 구성할 수 없게 되는데 이를 눈송이 서버(Snowflakes Server)라고 부릅니다. 이와 반대 개념으로 매번 동일한 구성으로 재생성(Re-born)이 가능한 서버를 피닉스 서버(Phoenix Server)라고 부르고 변하지 않는 인프라(Immutable Infrastructure)를 구성하는데 중요한 요소가 됩니다.         기존 방식의 한계점 이처럼 지속적으로 관리가 가능한 인프라를 유지하기 위해 표준 서비스 환경이 필요합니다. 기존에는 표준 서비스 환경을 제공하기 위해 서버 구성에 필요한 내용을 문서와 애드혹 스크립트로 작성해서 관리하고 있었습니다.   구성 내용 문서화  /  애드혹 스크립트       작성된 문서와 애드혹 스크립트를 이용해서 다음 과정을 통해 인스턴스 이미지를 생성합니다.   1. 개발자의 로컬 PC에서 CLI 이용해 표준 AMI 생성을 위한 인스턴스를 생성한다. 2. 인스턴스 생성이 완료되면 SSH로 접근 후 초기 설정 스크립트를 실행해서

Hashicorp에서 제공하는 Packer라는 툴을 사용하여 AWS, Azure, GCP 등의 클라우드 플랫폼에서 서버 이미지 생성을 자동화 할 수 있는 기능이 있습니다.네이버 클라우드 플랫폼에서도 내 서버 이미지 생성을 자동화할 수 있는 Packer Plugin Builder를 제공하고 있습니다.[ 사진 출처 : www.packer.io ]이번 글에서는 Packer Plugin Builder를 활용해 네이버 클라우드 플랫폼에서내 서버 이미지 생성을 손쉽게 자동화하는 방법에 대해 소개합니다.들어가며..기존에 네이버 클라우드 플랫폼 콘솔을 사용하여 내 서버 이미지를 생성하는 단계를 살펴보면 아래 그림과 같습니다.[ 콘솔을 사용하여 내 서버 이미지를 생성하는 단계 ]각 단계마다 설정이 완료될 때까지 기다려야 하고, 서버 인스턴스가 생성된 후 해당 서버에 들어가서 필요한 작업을 별도로 진행해야 하는 등 수동으로 작업해야 하는 부분이 매우 많았습니다. 하지만, Packer를 이용하면 사용자는 아래와 같은 단 한 줄의 command 실행 후 커피 한잔 마시는 여유를 가질 수 있습니다.$ packer build template.json실행결과 아래와 같습니다.네이버 클라우드 플랫폼 콘솔에서는 아래 화면과 같이 내 서버 이미지가 생성되었음을 알 수 있습니다.인자로 전달되는 `template.json` 은 아래 샘플과 같이 구성할 수 있습니다.{ variables: { ncloud_access_key: {{env `NCLOUD_ACCESS_KEY`}}, ncloud_secret_key: {{env `NCLOUD_SECRET_KEY`}} }, builders: [ { type: ncloud, access_key: {{user `ncloud_access_key`}}, secret_key: {{user `ncloud_secret_key`}},server_image_product_code: SPSW0LINUX000045, server_product_code: SPSVRSSD00000003, server_image_name: packer-test-{{timestamp}}, server_image_description: server description,communicator: ssh, ssh_username: root } ], provisioners: [ { type: shell, inline: [yum -y install httpd, systemctl enable httpd.service] } ] }위 샘플은 OS 는 `Cent OS 7.264` , 서버 스펙은 `[Standard] 2vCPU, 4GB Mem, 50GB Disk]` , 그리고 apache 서버 까지 설치되어 생성된 내 서버 이미지입니다. apache 서버는 `init script(user_data)`를 사용할 수 도 있지만 `provisioning` 단계에서 설치하도록 `provisioners` 을 추가했습니다.아래에서는 생성된 내 서버 이미지를 이용해서 서버 인스턴스를 생성해 보겠습니다.생

안녕하세요 저는 작년 우아한테크캠프 2기를 마치고 10월에 시스템신뢰성개발팀에 입사한 김규남이라고 합니다. 이번 글에서는 팀 내에서 Packer와 Ansible을 이용해 AMI를 코드레벨로 어떻게 관리하고 있는지에 대해 공유드리려고 합니다. 용어설명 저는 처음 입사할 당시에 인프라와 관련된 지식이 전혀 없었습니다. 처음 들어보는 용어들이 많았었기에 많이 혼란스러웠는데, 이 글을 보시는 분들 중에도 혹시 저와 같은 분이 계실 수 있어 간략히 용어를 정리하고 넘어가겠습니다. AMI(Amazon Machine Image) AMI(Amazon Machine Image)란 아래처럼 인스턴스를 처음 셋업할 때 지정하는 소프트웨어 구성이 기재된 템플릿입니다. Amazon에서 인스턴스를 셋업했을 때 aws-cli가 설치되어 있는 건 Amazon에서 제공하는 AMI들에 그 부분이 프로비저닝 되어 있기 때문입니다. 프로비저닝(Provisioning) 프로비저닝이란 사용자의 요구에 맞게 서버를 설정해 두었다가 필요 시 서버를 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말합니다. ex) 인스턴스에 JDK를 설치해두거나 MySQL을 설치하고 DB를 생성해두는 작업 등이 여기에 해당됩니다. Packer Packer는 여러 플랫폼에 대해 동일한 시스템 이미지를 작성하기위한 오픈 소스 도구입니다. AWS의 AMI, Azure Image, Google Cloud Image 등을 스크립트 파일을 이용해서 생성할 수 있습니다. Ansible Ansible은 프로비저닝에 대한 자동화를 제공하는 소프트웨어입니다. Ansible은 Docker, Vagrant, EC2등에 대한 프로비저닝을 제공합니다. yaml 문법으로 작성한 ansible 파일을 통해서 프로비저닝 설정들을 관리할 수 있습니다. Scale Out 서버의 대수를 늘려서 처리 능력을 향상시키는 것을 말합니다. ex) 트래픽이 많아 1대의 인스턴스로 처리가 어려울 경우 1대의 인스턴스를 증설해 2대로 요청을 처리하는 경우가 이에 해당합니다. AWS Auto Scaling Group 인스턴스 조정 및 관리 목적으로 구성된 Amazon EC2 인스턴스들의 묶음입니다. 토이 프로젝트를 진행하거나, 간단한 어플리케이션을 구동 할 때는 단일 인스턴스를 셋업해서 개발을 진행하게 됩니다. 하지만 운영 환경에서는 Scale Out이 빈번하게 일어나기 때문에 Auto Scaling Group을 사용하게 됩니다. 개발 환경 / 아키텍처 AMI를 생성할 때 직접 인스턴스를 생성한 뒤 인스턴스 내부에서 수동으로 작업을 하고 해당 인스턴스를 이용해 AMI를 만들 수도 있습니다. 하지만 그런 경우 해당 AMI에 어떤 내용이 적용되어 있는지에 대해 관리하기 어렵다는 단점이 있습니다. 그런 단점을 극복하고자 HashiCorp의 Packer를 이용해 AMI를 셋업하고, Ansible을 이용해 프로비저닝을 진행하기로 방향을 잡았습니다. 아키텍처 구상했던 아키텍처는 아래 이미지와 같습니다. Jenkins에서 AMI 빌드 Job을 실행한다.