서버/인프라 실전 구축 가이드 : 모던 웹을 지탱하는

모던웹을 지탱하는

서버/인프라 실전 구축 가이드

책1.indb 1 2015-09-02 오후 7:22:51

01. 셰프와 베이그런트로 인프라의 코드화 12

인프라 구성의 자동화 12

사용 환경 15

베이그런트를 사용한 가상 서버 준비 15

셰프로 인프라의 코드화 20

요약 32

02. 서버스펙으로 테스트 주도 인프라 구축 33

서버 구성 테스트 만들기 33

서버스펙을 시작하며 35

서버스펙과 셰프 솔로를 이용한 테스트 주도 개발 41

서버스펙의 응용 49

서버스펙으로 어디까지 해야 할까? 53

요약 54

03. 아마존 웹 서비스 레이어별 비교 56

시작하며 56

AWS 서비스의 개요 56

컴퓨팅 서비스 59

네트워크 서비스 62

스토리지 서비스 62

데이터베이스 서비스 66

배포 69

요약 72

04. EC2와 VPC를 이용한 시스템 구축 73

이후의 장에 대해서 73

2부의 시스템 구성 73

네트워크 구성 74

VPC 마법사를 이용한 VPC 작성 75

자신의 VPC 만들기 78

EC2의 설정 80

PART 01.[입문] 코드를 이용한

인프라 구축

Part 02.아마존 웹 서비스

최신 활용

목차4

책1.indb 4 2015-09-02 오후 7:22:54

워드프레스 설치와 설정 82

ELB 생성 83

ELB 엔드포인트에 접속 84

AWS CLI에 태그값을 취득해 설정 파일 변경 85

요약 87

05. RDS를 이용한 데이터베이스 활용 88

시작하며 88

RDS의 개요 88

DB 생성 90

DB 내보내기와 가져오기 92

Provisioned IOPS(PIOPS) 구성 94

Multi-AZ 배포 95

리드 레플리카 97

백업과 복원 99

RDS 모니터링하기 101

06. 클라우드포메이션을 이용한 구축 자동화 103

시스템 구성 자동화의 이점 103

인프라 구축 자동화 103

미들웨어 구축 설정 자동화와의 조합 110

요약 115

07. 인프라 테스트와 그 중요성 118

3부를 시작하며 118

Infrastructure as Code - 인프라의 코드화 119

테스트 주도 인프라 121

인프라 CI 124

3부에서 사용할 도구와 서비스 125

3부의 구성 133

Part 03.테스트

주도 인프라와 CI

목차 5

책1.indb 5 2015-09-02 오후 7:22:54

08. 테스트 주도 인프라의 구현 134

테스트 주도 인프라의 시나리오 134

사용 환경 134

테스트 주도 인프라 준비 135

테스트 주도 인프라 구축 141

테스트 주도 인프라의 반복 144

작성한 파일을 깃으로 관리 148

한발 더 나아가기 148

정리 150

09. 인프라 CI 구축 151

인프라 CI의 흐름 151

인프라 CI 준비 152

인프라 CI 구축 164

한발 더 나아가기 166

정리 167

10. 인프라의 지속적인 개선 실현 168

깃헙을 활용한 워크플로우 168

워크플로우 시나리오 169

워크플로우의 구현 170

워크플로우 구현 요약 181

한 걸음 더 나아가기 182

요약 182

11. Immutable Infrastructure란 무엇인가 184

4부를 시작하며 184

II란 무엇인가 185

II의 해결 과제 187

II의 단점과 적용되지 않는 영역 189

II 등장 배경 191

Part 04.Immutable

Infrastructure

목차6

책1.indb 6 2015-09-02 오후 7:22:55

II에서 필요로 하는 기술 193

II가 개발, 운용, 배포 프로세스에 미치는 영향 196

요약 198

12. Immutable Infrastructure에서 사용하는 도구와 서비스 199

기본적인 II의 구성 199

클러스터 관리 도구를 이용한 II의 고도화 203

시스템 전체의 구성 예 207

도커와 아파치 메소스를 이용한 구성 208

요약 209

13. 컨테이너형 가상화와 클라우드를 이용한 구현 210

이 장의 예제 프로그램 210

II에서 사용하는 도커의 기능 211

도커와 HA프락시를 이용한 II 구현 217

아마존 EC2와 ELB를 이용한 II 223

도커를 이용한 II와 AWS를 이용한 II의 차이 228

요약 228

14. 클러스터 관리 도구를 이용한 구현 229

아파치 메소스와 아파치 주키퍼 229

아파치 메소스 환경구성 231

아파치 메소스를 이용한 II 구현 237

요약 247

맺음말 248

15. 엔진엑스 세계에 오신 것을 환영합니다 250

엔진엑스란 250

C10K 문제와 웹 서버의 주도 아키텍처 251

프로세스 주도 아키텍처 251

용도 253

Part 05.엔진엑스 상세 풀이

목차 7

책1.indb 7 2015-09-02 오후 7:22:55

엔진엑스를 사용했을 때의 장점 255

엔진엑스를 이용했을 때의 단점 256

5부의 구성 257

16. 엔진엑스를 시작하며 258

엔진엑스 설치 258

엔진엑스의 기동, 다시 불러오기, 종료 262

설정 파일의 구성 263

기본적인 지시어 264

요약 268

17. 일반적인 웹 서버 구성 269

가상 호스트 이용하기 269

접속 제한하기 272

SSL 통신 278

기본 인증 설정 279

로그 출력 제어 279

요약 281

18. 실제 웹 응용프로그램 서버의 구성 282

웹 응용프로그램 서버에서 엔진엑스의 역할 282

레일즈 응용프로그램의 구성 284

PHP 응용프로그램의 구성 291

웹 응용프로그램 서버의 튜닝 294

요약 297

19. 대규모 콘텐츠 배포 시스템 구축 299

대량의 콘텐츠를 제공하려면? 299

캐시 사용 301

로드 밸런싱 사용 304

캐시와 로드 밸런싱의 병행 사용 305

요약 308

목차8

책1.indb 8 2015-09-02 오후 7:22:55

20. 확장 모듈의 구조와 제작 방법 309

엔진엑스와 확장 모듈 309

확장 모듈을 만들기 위한 지식 310

확장 모듈을 만드는 방법 311

요약 317

맺음말 317

21. 유지보수란 320

유지보수는 필요한가? 320

유지보수의 종류 322

유지보수 방법 323

6부의 구성 325

22. 계획 유지보수의 흐름 326

유지보수 실전 330

사후 처리 332

요약 333

23. 긴급 유지보수의 흐름 334

논리적인 장애의 경향 334

물리 장애 경향 336

평소에 대비 337

실전 340

사후 처리 342

노하우 축적 342

요약 344

24. 유지보수 프리의 접근법 [인프라 편] 345

유지보수 프리란 345

인프라 설계 345

Part 06.유지보수 본격 입문

목차 9

책1.indb 9 2015-09-02 오후 7:22:55

데이터베이스 설계 349

장애 감지 357

요약 359

25. 유지보수 프리의 접근법 [응용프로그램 편] 360

릴리즈 360

응용프로그램의 설계 367

요약 371

26. 걸 프랜드(가칭)와 아메바 피그의 사례 372

걸 프랜드(가칭)의 경우 372

계획 유지보수 373

긴급 유지보수 377

유지보수 프리를 위한 노력 380

아메바 피그의 경우 383

계획 유지보수 384

긴급 유지보수 387

유지보수 프리를 위한 노력 388

요약 390

27. 리눅스 컨테이너로 인프라를 순식간에 구축하기 392

도커란 393

도커의 기동 395

도커 첫걸음 396

리눅스 컨테이너 속으로 398

실행 중인 컨테이너의 상태 확인 399

도커 이미지 402

Dockerfile 406

도커의 리모트 API 410

도커의 사용 예 411

Immutable Infrastructure 413

Part 07.도커를 이용한 경량

가상 환경

목차10

책1.indb 10 2015-09-02 오후 7:22:55

서버 구성 관리의 자동화를 구현하자

지금까지 서버를 운영하면서 업데이트나 버그 수정이 있을 때는 매뉴얼을 보고 변

경 작업을 했다. 하지만 도구가 발전하면서 가상 환경 위에 서버를 구축하고 코드

로 서버의 구성을 관리하는 기술을 이용하게 됐다. 책 앞부분의 기획에서는 이러

한 기술을 구현해 주는 도구인 셰프, 베이그런트, 서버스펙으로 도입부터 설정까지

알기 쉽게 설명하고 있다.

01PART

[입문] 코드를 이용한 인프라 구축

책1.indb 11 2015-09-02 오후 7:22:56

인프라 구성의 자동화

책의 첫머리인 1부 기획에서는 셰프1를 사용한 인프라 환경의 코드화와 코드화된 인프라를 서버스펙2을

사용해 테스트 주도로 구축하는 방법을 소개한다. 1장에서는 셰프의 기초와 셰프를 시험 삼아 써보는

데 편리한 베이그런트3라는 가상화 도구를 설명한다4. 2장에서는 셰프로 코드화된 서버를 테스트 프레

임워크인 서버스펙에서 테스트하는 방법을 설명한다.

Infrastructure as Code(코드로 작성하는 인프라)

▣ 프로비저닝 프레임워크 셰프

클라우드 환경이 본격적으로 보급된 요즘이지만 가상 서버를 다루다 보면 인스턴스를 생성하고 삭제하

는 작업이 자주 발생한다. 하지만 매번 서버 구성 매뉴얼에 따라서 엔진엑스를 설치하고 MySQL을 설

치하고 유저를 생성하고…… 또 하나하나 실행해서 직접 동작을 확인하기 때문에 운영상 실수가 발생

하는 일은 어쩔 수 없다.

1 http://www.getchef.com/chef/

2 http://serverspec.org/

3 http://www.vagrantup.com/

4 이번장의예제코드는위키북스사이트의'서버/인프라실전구축가이드'페이지에서내려받을수있다.http://wikibook.co.kr/building-server-infra

01셰프와 베이그런트로

인프라의 코드화

설정을 일괄적으로 관리해 작업을 간소화하자

KAIZEN platform Inc. 이토 나오야

책1.indb 12 2015-09-02 오후 7:22:56


최근에는 이러한 서버 구성(프로비저닝) 작업을 프로그램으로 자동화하는 것이 일반적이다. 하지만 자

동화를 처음부터 직접 구현하는 건 무척 어려운 일이다. 그래서 프로비저닝을 자동화하는 프레임워크

를 사용하게 된다.

이러한 프로비저닝을 자동화해주는 프레임워크의 대표주자가 셰프(Chef)다. 셰프는 셰프 사(Op-

scode에서 사명 변경)가 루비로 개발한 OSS(Open Source Software)다. 셰프를 사용하면 「레시피」

라는 파일에 대상이 되는 서버의 상태, 예를 들면 “엔진엑스가 설치돼 있고 80번 포트에 바인드하고 있

고….” 등을 루비로 작성해 실행하는 것만으로 서버를 그 상태로 구성할 수 있다.

예를 들면 엔진엑스를 설치하는 레시피 파일은 다음과 같다.

package "nginx" do

action :install

end

service "nginx" do

action [ :enable, :start ]

end

「루비로 작성한다」고는 하지만 미리 준비된 DSL(Domain Specific Language, 도메인 특화 언어)에

정의된 언어를 사용하는 것뿐이므로, 일반적인 설정 파일을 작성하는 방법과 크게 다르지 않다. OS나

배포판의 버전 차이는 셰프가 처리해 준다. 셰프로 위 레시피 파일을 사용해 해당 서버에 적용하면 엔

진엑스가 설치되고 서비스가 시작된다.

마찬가지로 MySQL 같은 다른 소프트웨어의 레시피나 유저를 생성하는 레시피 혹은 네트워크를 설정

하는 레시피 등을 작성해 서버에 적용해 보자. 모두 자동화돼 있으므로 두 번째 이후의 작업은 셰프를

실행하기만 하면 된다.

▣ 서버스펙으로 테스트

이렇게 코드로 표현된 서버 상태를 깃(Git) 등의 SCM(Software Configuration Management, 소프

트웨어 구성 관리)을 사용해 버전 관리를 해 보자. 지금까지의 서버 구성 프로세스는 취약한 매뉴얼에

의지할 수밖에 없었지만, 코드를 이용해 안정적인 버전 관리를 할 수 있게 됐다.

코드를 작성했다면 테스트를 작성해 보자. 2장에서 설명하는 서버스펙을 사용한 테스트 코드는 다음과

같다.

책1.indb 13 2015-09-02 오후 7:22:56

1부 [입문] 코드를 이용한 인프라 구축14

require 'spec_helper'

describe 'nginx' do

it { should be_installed }

it { should be_running }

end

describe 'port 80' do

it { should be_listening }

end

이런 형태로 실제 서버에 일어나는 동작을 RSpec으로 작성할 수 있다. 이 테스트를 실행해 보면 대상

서버에 ssh를 통해 다양한 서버 상태를 테스트에 작성된 대로 체크하고 결과를 보고해 준다. 지속적인

통합5으로 테스트를 돌린다면 언제나 셰프 레시피가 정상적인 상태로 관리된다고 보장할 수 있을 것

이다.

가상화 서버에 의해 하드웨어가 추상적 개념이 되면서 소프트웨어로써 취급할 수 있게 됐다. “소프트웨

어가 됐다면 코드로 관리하고 테스트를 작성하면 좋지 않을까?” 하는 것이 「Infrastructure as Code」

의 개념이다.

셰프의 용도

셰프와 같은 프로비저닝 프레임워크는 인력만으로는 관리가 어려운 대규모 서버 환경에 적합한 도구가

아닐까 생각된다. 실제로 수십만 규모의 서버를 가지고 있다고 알려진 페이스북도 셰프로 서버의 구성

관리를 하고 있다고 한다.

필자도 한 대부터 수십 대의 서버 구성에 셰프를 사용하고 있으며, 최근에는 간단한 개발용 호스트도

셰프로 관리하고 있다.

개인적으로 사용하는 서버는 점검을 자주 하지 않기 때문에 “오랜만에 만져볼까?” 하고 살펴볼 때 기존

의 구성을 잊어버리는 경우가 자주 있다. 이럴 때 셰프로 관리한다면 모든 것이 코드로 일괄 관리가 되

므로 무엇을 어떻게 변경했는지 알 수 있다. 깃으로 코드를 관리하고 깃헙(GitHub)에 올려두면 보기

편하게 관리할 수 있다.

5 소프트웨어로서의통합관리를의미한다.

책1.indb 14 2015-09-02 오후 7:22:57


팀으로 개발할 때 개발 환경의 표준화를 위해 셰프를 사용하는 사례도 늘고 있다고 한다. 루비나 루비

온 레일즈 또는 노드(Node.js)처럼 개발 속도가 빠른 플랫폼을 사용하면 어느새인가 팀원들끼리 다른

버전으로 개발하는 경우도 생긴다. 이럴 때는 개발 장비용 셰프 레시피를 공유함으로써 이런 실수를 줄

일 수 있고, 신입사원이 들어왔을 때도 셰프를 한번 실행하는 것만으로 환경 구성을 할 수 있다. 이상적

이지 않은가?

사용 환경

서론은 이 정도로 하고 실제로 테스트해 보자. 필자가 사용한 환경은 다음과 같다.

■■ 작업■환경

• 맥 OS X 10.9.4

• 루비 2.1.2

• knife-solo 0.4.2

■ 서버

• 버추얼박스 4.3.14

• 베이그런트 1.6.3

• CentOS 6.5

• 셰프 11.14.6

베이그런트를 사용한 가상 서버 준비

셰프를 설명하기 전에 셰프 검증 환경을 구성하고 테스트 주도 서버를 구성할 때 편리한 베이그런트

(Vagrant)라는 도구를 소개한다.

베이그런트는 버추얼박스6 같은 서버 가상화 소프트웨어의 프런트엔드가 되는 루비로 만들어진 OSS다

(그림 1-1). 베이그런트를 사용하면 명령줄에서 vagrant 명령을 실행하는 것만으로 간단히 새로운 가

상 서버를 구축할 수 있다.

6 https://www.virtualbox.org/

책1.indb 15 2015-09-02 오후 7:22:57


% vagrant init centos

% vagrant up

실제 이 두 가지 명령어만으로 내 PC에 새로운 가상 서버가 설치된다.

한번 만들고 지워도 상관없는 호스트를 구성하는 데 베이그런트는 매우 편리하다. 최근의 프로비저닝

프레임워크 쪽에서는 사실상 베이그런트를 같이 사용하는 건 정평이 나 있다.

그림 1-1 베이그런트

버추얼박스 설치

베이그런트는 버추얼박스(VirtualBox) 이외에 가상화 도구나 클라우드 서비스에서도 사용할 수 있지

만, 이번 사용 목적에는 버추얼박스가 적합하므로 우선 버추얼박스를 설치한다.

책1.indb 16 2015-09-02 오후 7:22:58


버추얼박스는 x86과 AMD6/intel64의 가상화 도구로 윈도나 맥 OS X에 리눅스나 다른 OS 서버를

설치하기 위한 OSS다.

그림 1-2 버추얼박스

설치 방법은 버추얼박스의 내려받기 페이지7에서 「VirtualBox platform packages」 중에 개인이 사용

하고 있는 OS와 맞는 패키지를 내려받고 설치 파일을 실행하면 된다. 버추얼박스만 쓸 일은 없으므로

설치가 끝났다면 베이그런트 설치에 대해 알아보자.

베이그런트 설치

베이그런트도 내려받기 페이지8에서 내려받아 설치하면 된다.

문제없이 설치가 끝났다면 셸에서 vagrant 명령을 사용할 수 있을 것이다.

7 https://www.virtualbox.org/wiki/Downloads

8 http://downloads.vagrantup.com/

책1.indb 17 2015-09-02 오후 7:22:59


$ vagrant -v

Vagrant 1.6.3

가상 이미지 받기 - vagrant box add

설치를 했으니 베이그런트를 사용할 수 있게 됐지만, 최초에 한번 베이그런트에서 사용할 OS 이미지

를 받아야 한다. 이번 장에서는 CentOS 6.5를 사용하도록 하자9.

베이그런트용 OS 이미지는 「box」라고 한다. Box를 얻는 방법은 여러 가지가 있지만 여기서는

Opscode를 관리하는 Bento라는 프로젝트 box를 가져오자.

목록에서 「opscode-centos-6.5」 URL을 복사하고 vagrant box add 명령으로 이미지를 가져온다.

% vagrant box add centos http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_

centos-6.5_chef-provisionerless.box (명령어는 한 줄로)

OS 이미지 내려받기가 시작되고 ~/.vagrant.d에 메타데이터와 함께 이미지가 저장된다. 위에서는

「centos」라는 이름으로 이미지를 add하고 있다.

가상 서버 기동 - vagrant up

이걸로 준비가 끝났다. 다음과 같이 적당한 작업 폴더를 만든다.


(생략)

% vagrant up

Bringing machine 'default' up with 'virtualbox' provider...

==> default: Importing base box 'centos'...

==> default: Matching MAC address for NAT networking...

==> default: Setting the name of the VM: webdb-chef_default_1408971563853_7882

(생략)

==> default: Machine booted and ready!

==> default: Checking for guest additions in VM...

==> default: Mounting shared folders...

default: /vagrant => /Users/naoya/work/webdb-chef

9 집필당시CentOS7이최신버전이었지만CentOS7에새로운기능이늘어서애매한곳이많기때문에여기서는CentOS6을사용한다.

책1.indb 18 2015-09-02 오후 7:23:00


이때 「Failed to mount folders in Linux guest. This is usually because the "vboxsf" file

system is not available.」이란 에러가 발생하면 다음 명령을 실행한다. 로컬 버추얼박스 버전이나 설

정 상태 때문에 발생한 에러일 수 있다.

$ vagrant ssh -c 'sudo /etc/init.d/vboxadd setup'

$ vagrant reload

vagrant init에 Vagrantfile이란 설정 파일을 만들고 vagrant up을 실행하면 파일 내용대로 가상 서

버가 시작된다.

시작됐으면 vagrant ssh 명령으로 ssh 로그인을 해보자.

% vagrant ssh

Last login: Fri Aug 1 09:45:51 2014 from 10.0.2.2

[vagrant@localhost ~]$ cat /etc/system-release

CentOS release 6.5 (Final)

문제없이 기동 됐나? 순식간에 검증 환경이 만들어졌다(정말 편해졌다).

나머지는 마음껏 만져 보자.

가상 서버의 정지와 삭제 - vagrant halt/destroy

가상 서버를 정지하거나 삭제하려면 다음 명령을 실행한다.

■■ 가상■서버의■정지: vagrant halt

■■ 가상■서버의■삭제: vagrant destroy

halt는 다시 vagrant up을 실행했을 때 이미지가 halt 한 시점으로 시작되지만, destroy는 새롭게 설

치된 상태로 돌아간다.

ssh 설정

베이그런트에 올린 호스트는 vagrant ssh로 로그인할 수 있지만, 만일을 대비해서 ssh <hostname>

으로도 로그인할 수 있게 해 두자.

책1.indb 19 2015-09-02 오후 7:23:00


vagrant ssh-config 명령으로 ssh config 설정값이 출력되므로, 설정값을 ~/.ssh/config에 리다이

렉트해 주자.

% vagrant ssh-config --host webdb >> ~/.ssh/config

이것으로 ssh webdb에서 가상 서버에 로그인할 수 있게 됐다.

셰프로 인프라의 코드화

베이그런트 설정이 끝났다면 셰프를 확인해 보자.

셰프에는 두 종류가 있다10. 하나는 어느 정도 이상의 서버 규모를 대상으로 하는 「셰프 서버(Chef

Server)」이고, 하나는 스탠드 얼론을 대상으로 하는 「셰프 솔로(Chef Solo)」다.

셰프 서버는 셰프 서버를 설치하고 구성 관리 대상이 되는 각 호스트가 클라이언트 형태로 서버에서 명

령을 받는 구조로 돼 있다. 셰프 솔로보다는 확장성이 좋지만 가볍게 사용하기에는 번거롭다. 간단하게

시작할 수 있는 셰프 솔로를 사용해 보자.

셰프 서버가 확장성이 좋다고 하지만, 셰프 솔로도 셰프의 기본적인 기능을 모두 지원하므로 단 몇 대

의 서버라면 문제없이 구성하고 관리할 수 있다.

노드 - 구성 관리 대상의 호스트/서버

셰프에서는 구성 관리 대상의 호스트/서버를 「노드(node)」라고 한다. 앞으로 이어지는 장에서도 노드

라고 하겠다.

chef-solo 다루기

앞서 준비한 Vagrant OS 이미지에는 셰프가 없다. 우선 수동으로 셰프를 설치하자.

셰프를 설치하려면 셰프 사가 제공하는 설치용 스크립트를 쓰는 게 빠르다. 다음 명령을 실행해 보자.

10 그외에도SaaS(SoftwareasaService)버전「HostedChef」가있지만,여기에서는다루지않는다.

책1.indb 20 2015-09-02 오후 7:23:00


% vagrant ssh

$ sudo bash -c "curl -L https://www.opscode.com/chef/install.sh | bash"

설치가 끝나면 chef-solo 명령을 실행해보자.

$ sudo chef-solo

레시피가 없다면 당연히 에러메시지가 나오고 종료되지만, 다음과 같이 셰프 솔로를 실행할 수 있다는

걸 알게 됐다.

■ 해당 노드에 ssh 로그인

■ sudo 권한으로 chef-solo 실행

레시피 작성

다음으로 노드에 httpd를 설치하고 레시피를 작성해 실행해 보자. 레시피 양식을 만드는 프런트엔드

작업에는 셰프와 함께 설치되는 knife 명령을 쓴다.

# 대상 노드 내

$ sudo knife cookbook create httpd

$ sudo vi /var/chef/cookbooks/httpd/recipes/default.rb

셰프에서는 레시피 파일이 있는 폴더를 「쿡북」이라 한다. knife cookbook create httpd 명령으로

httpd 쿡북 양식을 만든다. 기본값일 때는 /var/chef 아래에 만들어진다. 레시피 파일은 cookbooks/

httpd/recipes/default.rb다. 이 파일을 다음과 같이 편집한다.

package "httpd" do

action :install

end

레시피가 만들어졌다면 실행해 보자. chef-solo 명령 인수에 -o 옵션을 붙여 미리 만들어 둔 httpd

쿡북이 적용되게 설정한다.

$ sudo chef-solo -o httpd

(생략)

Recipe: httpd::default

책1.indb 21 2015-09-02 오후 7:23:00


* package[httpd] action install

- install version 2.4.6-18.el7.centos of package httpd

Running handlers:

Running handlers complete

Chef Client finished, 1/1 resources updated in 16.6092188 seconds

(생략)

여러 가지 경고는 나왔지만 httpd가 설치됐다. rpm -qa | grep httpd 명령으로 실제로 설치됐는지

확인할 수 있다.

knife-solo에서 셰프 실행

지금까지는 셰프 솔로의 실행 흐름을 이해시키려고 일부러 ssh로 로그인해서 chef-solo를 직접 실행

하는 방법을 소개했다. ssh는 번거롭고 레시피를 작성하는 데 sudo 권한이 필요하며 원격에서 편집할

때 사용하던 편집기를 사용할 수 없어서 꽤 번거롭다.

knife의 플러그인인 knife-solo를 사용하면 로컬 환경에서 편집한 쿡북을 rsync를 사용해 노드에 전

송해서 chef-solo를 실행할 수 있다. chef-solo의 실행 도구는 여러 가지가 있지만, 필자가 추천하는

도구는 knife-solo다.

▣ knife-solo 설치

이후에는 게스트 OS(CentOS)가 아닌 호스트 OS(필자) 환경에서 작업한다.

knife-solo는 RubyGems.org에 공개된 루비로 만들어진 도구다. 따라서 실행하려면 루비가 필요하

다. 루비 버전은 현재 지원되는 1.9 이후 버전이면 문제없다. 가능하면 새로운 버전(집필 시점 2014년

8월)인 2.1.2를 권장한다.

설치는 Bundler를 사용하면 편하다. Vagrantfile과 같은 폴더에 Gemfile을 만들고 다음과 같이 입력

해 설치한다.

source 'https://rubygems.org'

gem 'knife-solo'

% bundle

책1.indb 22 2015-09-02 오후 7:23:00


이제 knife 명령의 하위 명령으로 knife solo를 사용할 수 있게 됐다.

▣ knife-solo로 셰프 리포지토리 생성

게스트 OS에서 knife를 실행하면 /var/chef 아래에 쿡북이 만들어지지만, knife-solo를 사용하면 작

업 폴더 내에 초기화를 실행할 셰프용 폴더(셰프 리포지토리11)를 만든다.

Gemfile이 있는 폴더에서 다음 명령을 실행하자. 셰프와 관련된 폴더가 생성된다.

% bundle exec knife solo init .

# 폴더 구성 확인

% tree

.

├── Gemfile

├── Gemfile.lock

├── Vagrantfile

├── cookbooks

├── data_bags

├── environments

├── nodes

├── roles

└── site-cookbooks

리포지토리를 만들었다면 깃에서 관리를 해보자. 이때 베이그런트가 사용하는 vagrant 폴더는 관리가

필요 없으므로 .gitignore를 추가한다.

% git init .

% echo ".vagrant/" > .gitignore

% git add .

% git commit -m 'First commit'

▣ knife-solo prepare로 노드에 셰프 솔로 설치

조금 전 베이그런트 박스에 로그인해서 셰프를 수동으로 설치했다. knife-solo의 prepare 명령을 사

용하면 원격에서 대상 노드에 셰프 솔로를 한 번에 설치할 수 있다.

11 리포지토리는쿡북그룹을비롯한셰프를실행하는데필요한파일을모아놓은저장소를말한다.이책에서는리포지토리라고하겠다.

책1.indb 23 2015-09-02 오후 7:23:00


만약 셰프가 미리 설치된 서버를 사용할 경우에도, 버전을 맞추는 데 knife solo prepare를 실행해 보

자. 노드의 호스트명을 인수로 넣으면 knife가 ssh로 환경을 만들어 준다.

% bundle exec knife solo prepare webdb

knife solo prepare는 셰프 설치뿐 아니라 knife-solo용 rsync 설정과 그 외에 설정도 조정되므로

일단 한번 실행해 두자.

▣ 쿡북 작성과 적용

이제 준비가 끝났다. 조금 전과 같이 httpd 쿡북을 만들어 노드에 chef-solo를 실행하자. knife solo

cook <노드명> 명령으로 대상 노드의 쿡북 rsync와 셰프 솔로가 적용된다12.

# chef-repo 폴더에서 실행

# 직접 만든 것은 site-cookbooks에 만드는 것이 기본

% bundle exec knife cookbook create httpd -o site-cookbooks

# 자주 쓰는 편집기로 레시피 편집

% emacs site-cookbooks/httpd/recipes/default.rb

# 레시피를 webdb 노드에 적용

% bundle exec knife solo cook webdb -o httpd

(생략)

Converging 1 resources

Recipe: httpd::default

* package[httpd] action install (up to date)

Chef Client finished, 0 resources updated

문제가 없다면 작업이 실행되고 httpd가 설치된다. 여기서는 httpd를 이미 설치했으므로 실제로 실행

되지 않고 넘어갔다는 메시지가 나온다.

레시피가 잘 실행됐다면 깃에 전송하자. 이렇게 레시피 만들기가 끝날 때마다 커밋하면 서버 구성 내역

이 자연스럽게 깃에 모이게 된다.

그런데 knife solo를 실행할 때 「SSL validation of HTTPS requests is disabled.」라고 경고가 나올

수 있다. 경고가 귀찮다면 .chef/knife.rb 다음에 아래와 같이 한 줄을 추가하자.

12 쿡북을만드는건knife자체명령으로,셰프솔로를실행하는건knife-solo에추가한하위명령을쓴다.처음에는헷갈리는부분이므로주의하자.

책1.indb 24 2015-09-02 오후 7:23:01


ssl_verify_mode :verify_peer

▣ 노드 객체 편집

쿡북을 하나 더 만들어 적용해보자. base_packages라는 이름으로 자주 쓰는 패키지를 모아 쿡북을

만들어 보자. 다음 명령으로 새로운 쿡북을 만든다.

% bundle exec knife cookbook create base_packages -o site-cookbooks

레시피 site-cookbooks/base_packages/recipes/default.rb의 내용은 다음과 같다.

%w{gcc make git readline readline-devel}.each do |pkg|

package pkg do

action :install

end

end

이제 gcc와 make 그리고 깃 같은 필수 도구를 설치할 수 있다. 한 줄 한 줄 package 문에 적는 게 아

니고 루비 문법을 사용해 배열 형태로 정의하는 게 포인트다.

이 레시피를 knife solo cook 명령으로 노드에 다시 적용하려고 일일이 -o 옵션을 쿡북에 추가하는

건 번거롭다. 「webdb 노드에는 이런 쿡북을 적용하자」라는 명령이 「노드 객체」라는 설정 파일에 쓰여

있다.

chef-repo/nodes/webdb.json이라는 JSON(JavaScript Object Notation) 파일이 webdb 노드의

노드 객체다.

{

"run_list": [

"recipe[base_packages]",

"recipe[httpd]"

],

"automatic": {

"ipaddress": "webdb"

}

}

위와 같이 webdb 노드 상태를 노드 객체에 작성해서 다음과 같이 -o 옵션 없이 실행하면 실행될 쿡

북을 노드 객체가 판단하게 된다.

책1.indb 25 2015-09-02 오후 7:23:01


% bundle exec knife solo cook webdb

셰프 솔로로 httpd 프로비저닝

Chef Solo를 다루는 것도 꽤 익숙해졌을 것이다. 지금까지는 패키지를 설치만 해 보았다. 이번에는 구

성 변경도 해보자.

다음 두 가지를 해보자.

■ 설치한 httpd를 시작한다.

■ httpd 설정 파일을 수정한다.

우선 작성해 둔 httpd 쿡북 레시피를 다음과 같이 편집한다.

package "httpd" do

action :install

end

# httpd 시작

service "httpd" do

action [ :enable, :start ]

end

# 설정 파일 설치

template "httpd.conf" do

path "/etc/httpd/httpd.conf"

owner "root"

group "root"

mode 0644

# 파일을 변경했으므로 서비스 재로딩

notifies :reload, 'service[httpd]'

end

위에서 package 외에 service와 template이라는 구문을 사용했다. 이런 구문을 「리소스」라고 한다.

책1.indb 26 2015-09-02 오후 7:23:01


▣ 「리소스」 호칭의 유래 - 셰프에서의 개념

셰프는 서버 구성을 자동화하는 도구이지만 더 정확하게는 「노드에 상태를 정의하고 해당 노드의 상태

를 정리한 프레임워크」다. 노드 객체와 레시피에 쓰인 것은 「처리 단계」라기보다는 「노드 상태를 구성하

는 요소」다.

package와 service가 「리소스」라고 불리는 건 이와 같은 셰프의 콘셉트에서 유래됐다. 각 리소스에 정

의돼 있는 action, path, owner 같은 항목은 해당 리소스와 연관된 값이고 이를 「속성」이라 한다.

패키지와 서비스라는 각 리소스가 있고, 각 속성을 정의한다. 이렇게 정의된 리소스의 집합이 노드 상

태를 표현하고 있고 셰프를 적용하면 노드는 그 상태로 설치된다. 셰프는 이러한 개념을 바탕으로 한

프레임워크다.

▣ service 리소스

앞서 이야기한 service 리소스는 레드햇 계열 리눅스에서 말하는 /etc/init.d 아래에 있는 init 스크립

트의 상태를 말한다. 여기서는 다음과 같이 정의한다.

■ :enable OS가 기동될 때 시작되도록

■ :start 명령을 입력할 때 시작되도록

chkconfig 명령으로 OS 부팅 시 시작되게 하는 것과 /etc/init.d/httpd start 명령으로 시작하는 것

과 같은 방식이다.

▣ template 리소스

다음으로 template 리소스는 httpd.conf 같은 설정 파일을 배포할 때 쓴다. 템플릿은 site-

cookbooks/httpd/templates/default/httpd.conf.erb에 있는 파일이 사용된다.

httpd.conf.erb에는 다음과 같이 httpd의 최소한의 설정이 기록돼 있다. 이런 설정 템플릿 파일은 우

선 기존의 파일을 통째로 복사해서 사용해 보는 것도 좋다.

ServerRoot "/etc/httpd"

Listen <%= node['httpd']['port'] %>

User apache

Group apache

책1.indb 27 2015-09-02 오후 7:23:01


ServerAdmin root@localhost

ErrorLog "logs/error_log"

TypesConfig /etc/mime.types

Include conf.modules.d/*.conf

DocumentRoot "/var/www/html"

<Directory "/var/www/html">

Require all granted

</Directory>

IncludeOptional conf.d/*.conf

템플릿 파일 중 <%= node['httpd'] ['port'] %>라는 태그가 있다는 점을 주목하자. 템플릿 파일은 레

일즈 같은 친숙한 템플릿 엔진의 ERB를 사용할 수도 있다. 템플릿이기 때문에 내용 중에 <%= …… %>

에 설명된 태그 변수를 써서 그 값을 실행할 때 결정할 수 있다.

애트리뷰트(Attribute) 값을 정의하는 방법은 몇 가지 있지만 여기서는 노드 객체로 지정해 보자.

chefrepo/nodes/webdb.json을 다음과 같이 편집해 보자.

{

"httpd": {

"port": 80

},

"run_list": [

"recipe[base_packages]",

"recipe[httpd]"

],

"automatic": {

"ipaddress": "webdb"

}

}

셰프 관점에서 보면 「webdb 노드에 httpd 포트는 80번으로 한다」라고 정의됐다는 의미다.

이제 다시 knife solo cook 명령으로 쿡북을 적용하고 싶지만, 이왕 httpd가 올라왔으니 브라우저로

액세스되게 해 보자.

책1.indb 28 2015-09-02 오후 7:23:01


▣ 베이그런트의 host-only 네트워크 유효화

베이그런트의 초기 상태에서는 호스트 OS에서 ssh 같은 통신은 가능하지만 IP 주소를 직접 지정해서

통신할 수는 없다. IP 통신이 가능하도록 호스트 OS와 게스트 OS 사이에서만 유효한 네트워크 인터페

이스를 만들어보자.

Vagrantfile에 다음과 같이 네트워크 설정을 하자.

Vagrant.configure("2") do |config|

config.vm.box = "centos"

# 다음의 설정을 추가

config.vm.network :private_network, ip: "192.168.33.10"

（생략）

IP 주소는 호스트 OS의 다른 IP와 겹치지 않는 사설 IP 주소라면 어떤 것이든지 상관없다.

파일을 갱신하고 vagrant halt/vagrant up 명령으로 게스트 OS를 재시작해 주자. 호스트 OS에 가상

인터페이스가 추가돼서 그 인터페이스를 통해 게스트 OS와 IP 주소의 통신이 가능해진다.

▣ 셰프로 구성 관리를 하려면 전부 셰프로13

CentOS 6.5는 기본 iptables에 의해서 모든 네트워크 호스트가 차단돼 있다. 편의상 여기서는 해제하

자14.

베이그런트에 ssh로 접속해 /etc/init.d/iptables stop 명령으로 정지해도 되지만 셰프 솔로로 구성

관리를 한다면 직접 ssh로 접속해서 셰프를 사용하지 않고 구성을 변경하는 건 금물이다. 중요한 점이

므로 다시 한 번 강조한다. 직접 노드의 구성을 변경하지 않는다.

셰프는 앞서 설명했듯이 「현재의 서버 상태를 정의하고 그 상태를 설명하는 프레임워크」다. 노드의 상

태는 기본적으로 쿡북에 모두 정의돼 있어야만 한다.

예를 들어 httpd 설정 파일을 설치하는 레시피가 작성돼 있고 그 후에 셰프에서 배포한 설정 파일을

ssh로 로그인해서 직접 재작성했다고 하자. 그 후 다시 셰프를 적용하면 어떻게 될까? 셰프는 셰프에

13 사용하고있는셰프나knifesolo가오래된버전이라면호스트OSiptables설정에주의할필요가있으나최신판일때는문제없다.다음은iptables를설정할필

요가있었을때에대한설명으로이해하면된다.

14 단,절대로프로덕션서버에같은설정을하지않기를바란다.

책1.indb 29 2015-09-02 오후 7:23:01


정의된 상태로 설정 파일을 복원할 것이다. 즉, 직접 편집된 설정은 없어져 버린다.

셰프가 직접 편집한 설정을 원래대로 되돌린다. 어색하다고 생각할지도 모르겠지만 그렇지 않다. 셰프

의 이러한 특성 때문에 셰프는 해당 노드가 쿡북에 쓰인 대로 구성되는 것을 보장해 준다.

인프라를 관리하는 데 있어 무엇보다 귀찮은 것은 「수작업한 내용을 잊어버리거나」 또는 「서버가 너무

많아서 어떤 호스트에 어떤 설정을 했는지 나중에 잊어버리거나」 하는 일이다. 혹은 서버 설정을 누군

가의 머릿속에서만 기억하고 있는 경우도 있다. 모든 상태를 셰프에 기록해야 한다는 셰프의 정책을 지

킨다면 노드 고유의 정보는 모두 레시피에 기록되고 깃을 통해 버전 관리를 할 수 있게 된다. 이렇게 함

으로써 잊어버리거나 머릿속에 기억하고 있어서 생길 수 있는 운영상의 실수를 피할 수 있게 된다.

셰프를 실행하면 셰프는 레시피에 쓰인 상태로 노드에 반영한다. 몇 번을 수행해도 레시피에 적혀진 대

로 반영되는 것을 셰프가 보장해 준다. 셰프 레시피만 있으면 대상 노드를 원래대로 설정할 수 있다.

반복해서 얘기하고 있지만, 셰프는 단순한 자동화 도구가 아닌 「형상관리 프레임워크」라는 것을 기억하

라. 이 점이 셰프가 셸스크립트 자동화로는 구현할 수 없는 가치를 제공한다는 부분이다. 그 가치를 충

분히 활용하기 위해서는 셰프 문법에 맞춰서 모든 구성 변경을 셰프 레시피로 만들어 두는 게 좋다.

그러면 iptables에 대해 쿡북을 만들어 보자. 지금까지 했던 것처럼 knife cookbook create 명령으

로 iptables 쿡북을 만들고 레시피 site-cookbooks/iptables/recipes/default.rb에 다음과 같이 서

비스 리소스를 정의하자.

service "iptables" do

action [:disable, :stop]

end

노드 객체 webdb.json의 run_list에 추가하는 것도 잊지 말자15.

이제 httpd를 시작할 준비가 됐다. knife solo cook 명령으로 쿡북을 적용해보자. 문제가 없다면 브

라우저에서 http://192.168.33.10/으로 접근하면 httpd의 초기 화면이 나타날 것이다.

15 잘잊어버린다……

책1.indb 30 2015-09-02 오후 7:23:02


리소스의 정의 방법

지금까지 사용한 리소스 외에도 유저나 그룹을 만들거나 cron 설정을 하거나 깃 리포지토리에서 코드

를 받아서 배포하는 것처럼 셰프에는 다양한 리소스가 있다.

지면상 전부 소개할 수는 없지만, 목록과 사용법은 Opscode의 공식 문서16에서 확인할 수 있다.

공개된 쿡북 사용

지금까지는 쿡북을 직접 작성했지만, 제삼자가 공개한 커뮤니티 기반의 쿡북을 내려받아 사용할 수 있

다. 셰프 슈퍼마켓(Chef Supermarket)17에는 루비의 RubyGems.org처럼 업계의 개발자가 등록한

여러 쿡북이 공개돼 있다.

knife에는 쿡북을 받아서 사용하기 위한 명령어가 있다. 예를 들어 yum 쿡북을 사용해 레드햇 리눅스

용 애드온 패키지에 있는 EPEL을 유효화해보자.

# cookbooks 폴더에서 취득

% bundle exec knife cookbooks site vendor yum-epel

이제 쿡북을 받았으므로 대상 노드 객체에 다음과 같이 run_list에 실행 내용을 정의하면 OK다.

{

"run_list": [

"recipe[yum-epel]",

(생략)

]

}

공개된 쿡북을 적극적으로 사용하는 것이 맞는지에 대해서 현재로써는 의견이 분분하다. 필자는 yum

쿡북처럼 개인이 만들려면 귀찮지만 있으면 편한 것 같은 것들만 공개 쿡북을 쓰고 있다. 그 외에 것은

지금까지 본 레시피처럼 매우 단순하므로 일부러 제삼자(다른 사람)가 만든 걸 쓸 필요는 없다고 생각

한다.

16 http://docs.getchef.com/resource.html

17 https://supermarket.getchef.com

책1.indb 31 2015-09-02 오후 7:23:02


요약

지금까지 베이그런트와 셰프 솔로에 관해 설명했다.

이번 장에서는 몇 가지 패키지와 httpd를 설치하는 정도에 그쳤지만, 설명을 참고해 각자 평소에 사용

하는 소프트웨어의 레시피를 작성해 활용해 보자. 레시피가 쌓여가면 점점 구성 관리가 편해지는 걸 느

낄 수 있을 것이다.

이번에는 셰프 솔로에 관해서 노드의 역할별로 run_list와 애트리뷰트를 정의할 수 있는 Role 기능과

셰프에 넣고 싶은 데이터를 저장할 수 있는 Data Bags까지는 다루지 못했지만, 기본적인 것은 이번 장

의 내용을 보고 해 볼 수 있다고 생각한다. 만약 리소스 사용법을 좀 더 자세히 알고 싶거나 고급 사용

법을 알고 싶다면 공식 문서를 참고하자.

2장에서는 서버스펙을 사용한 테스트 작성법과 테스트 주도에서의 구성을 변경하는 법 그리고 지속적

인 통합 방법에 관해 설명하겠다.

책1.indb 32 2015-09-02 오후 7:23:02

1장에서는 셰프 솔로와 베이그런트를 사용해 코드로 서버의 구축과 구성을 자동화하는 방법을 소개했

다. 이번 장에서는 서버 환경과 관련된 테스트도 코드로 자동화하고 이른바 「테스트 주도 개발」에서 인

프라 구축을 수행하는 방법에 관해 설명한다.

서버 구성 테스트 만들기

직접 확인하고 있습니까?

“여러분은 서버 구성을 변경한 후 어떻게 확인하고 있습니까? 웹 서버 설정을 갱신하고 제대로 작동하

는지 직접 확인하고 있지는 않습니까?”

셰프 같은 프레임워크를 사용하면서도 실제 셰프를 적용한 후에는 제대로 변경 사항이 반영됐는지 매

번 직접 확인하는 사람도 적지 않을 것이다.

그렇다. 이런 반복 작업은 자동화돼야 한다. 애플리케이션 개발 분야에서는 이미 당연시되고 있는 테스

트 주도 개발을 서버에도 구현하는 것이다.

02서버스펙으로

테스트 주도 인프라 구축

설정 변경의 반영을 보장한다

KAIZEN platform Inc. 이토 나오야

책1.indb 33 2015-09-02 오후 7:23:02


서버 테스트를 작성하려면 지원되는 프레임워크가 필요할 것이다. 서버 테스트 프레임워크로 주목되는

서버스펙1을 사용해 보자.

서버스펙

서버스펙(Serverspec)은 서버 구성 테스트를 수행하는 루비로 만들어진 프레임워크다. 테스트

는 루비의 테스트 프레임워크인 RSpec으로 작성한다. 루비로 작성한다고 해도 셰프처럼 실제는

DSL(Domain Specific Language, 도메인특화 언어)이므로 어려운 건 없다.

서버스펙은 호스팅과 PaaS(Platform as a Service) 사업을 운영하던 미야시타 고우스케2가 개발한

OSS(Open Source Software)다. 셰프 같은 프로비저닝 프레임워크인 퍼펫(Puppet)의 마니아였던

어떤 사람이 퍼펫과 함께 쓸 수 있는 테스트 프레임워크가 필요해서 만들기 시작한 것이 개발하게 된

계기가 됐다고 한다.

서버스펙은 2013년 3월 처음으로 배포됐다. 쉽게 시작할 수 있고 테스트 편의성도 좋으며 특정 프로비

저닝 프레임워크에 의존하지 않고 사용하기 쉽다는 이유로 급속도로 주목받고 있다. 최근에는 해외 콘

퍼런스에서 소개되고 있으며, 『Test-Driven Infrastructure with Chef, 2nd Edition』3에도 소개되는

등 그 기세를 더해 가고 있다.

서버스펙에서의 테스트

앞서 언급했지만 서버스펙을 사용하면 서버 테스트를 RSpec으로 작성할 수 있다.

describe package('httpd') do

it { should be_installed }

end

describe service('httpd') do

it { should be_enabled }

it { should be_running }

end

1 http://serverspec.org/

2 이책의3부인「테스트주도인프라와CI」를집필했다.

3 Test-DrivenInfrastructurewithChef,2ndEdition:BringBehavior-DrivenDevelopmenttoInfrastructureasCode,StephenNelson-Smith,O’Reilly

Media,2013(한국어판미발매).

책1.indb 34 2015-09-02 오후 7:23:02

02. 서버스펙으로 테스트 주도 인프라 구축 35

어떤 테스트인지 한눈에 볼 수 있다. 「httpd 패키지가 설치돼 있고 httpd를 유효화해서 실행한다.」는

동작 테스트다.

다음과 같이 rake 명령을 실행하면 서버스펙이 테스트 대상 호스트에 실제 ssh로 로그인해서 httpd 테

스트를 한다.

% rake spec

매우 직관적이지 않은가.

서버스펙을 시작하며

서버스펙의 더 자세한 구조는 직접 다뤄보면서 설명하려고 한다. 우선 적용을 시작하자.

검증용 서버 준비

서버스펙을 적용하기 전에 검증용 서버를 만들어 두자. 앞서 소개했던 베이그런트를 사용하겠다. 임의

의 작업 폴더로 이동해 초기화한 뒤 vagrant up 명령을 실행한다.


% vagrant up

이렇게 새로 vagrantfile을 생성하고 CentOS VM을 만든다. 호스트명은 1장에서와 마찬가지로

「webdb」라고 하자. ssh webdb 명령으로 로그인이 가능하도록 해두자(이미 실행한 경우는 ~/.ssh/

config의 해당 항목을 삭제하고 다시 실행한다).

서버스펙의 적용

▣ 설치

서버스펙은 루비 gem에 공개돼 있으므로 보통은 gem으로 설치한다. 서버스펙은 ssh를 통해 대상 호

스트에 로그인해 테스트를 수행하는 도구이므로 설치는 테스트 대상의 호스트가 아니고 테스트 자체를

실행하는 쪽 호스트에 한다. 즉 조금 전에 베이그런트를 설치한 VM이 아니고 작업하고 있는 환경(필자

의 경우 앞에 놓인 맥 OS X)이다.

책1.indb 35 2015-09-02 오후 7:23:02


gem install serverspec 명령으로 직접 설치해도 되지만 여기서는 Bundler를 이용하자.

Vagrantfile을 생성하고 작업 폴더와 같은 폴더에 Gemfile을 다음과 같이 작성해 서버스펙을 설치하

자. Rake도 필요하므로 같이 설치해 두자.

source 'https://rubygems.org'

gem 'serverspec'

gem 'rake'

bundle 명령을 실행하면 설치가 완료된다.

% bundle

▣ 테스트 초기화

설치가 끝났다면 serverspec-init 명령으로 테스트 초기화를 수행하자. 명령을 실행하면 대화창이 나

타나고 결과에 따라 폴더에 Rakefile과 테스트 샘플 파일이 생성된다.

bundle exec serverspec-init

Select OS type:

1) UN*X

2) Windows

Select number: 1

Select a backend type:

1) SSH

2) Exec (local)

Select number: 1

Vagrant instance y/n: y

Auto-configure Vagrant from Vagrantfile? y/n: y

+ spec/

+ spec/default/

책1.indb 36 2015-09-02 오후 7:23:02

서버/인프라 실전 구축 가이드 : 모던 웹을 지탱하는

Documents

Transcript of 서버/인프라 실전 구축 가이드 : 모던 웹을 지탱하는