aws 클라우드 선택 과정에 대한 고찰. 사실 digital ocean 이 나음.

http://www.cloudping.info/

CloudPing.info

서울 리전에서 opsworks 가 안된다. 물론 이미지 떠서 auto scaling 하거나 beanstalk 을 사용해도 된다. 오토 스케일링은 직접 EC2 한 개 생성하고 거기에 필요한 패키지 설치 및 설정 파일 들 고치고 해서 이미지를 뜬다. 그리고 부하에 따라 그 이미지가 자동으로 생성되도록 하는 방식이고 빈스톡은 기본 제공되는 이미지 nodejs 일 경우 nodejs application 용 빈스톡을 사용하여 app 의 리포지터리를 제공하여 EC2 를 생성하는 방식이다. 물론 오토 스케일링 방식을 사용해도 레디스 슬레이브를 깔고 해서 사용하면 되지만 일단 범용적이지 못하다. 수정이라도 할려고 치면 이미지를 다시 떠야 하고 이미 떠 있는 인스턴스 들을 수정이라도 할려치면 죽이고 다시 띄워야 하는 등... 한계가 있다.
opsworks 는 cloud formation 보다는 디테일 하지는 않지만 cloud formation 은 아마존 의존적인 자원을 매우 디테일하게 할려면 사용해도 되지만 너무 복잡하고 배보다 배꼽이 크기에 아마존을 떠나서도 사용할 수 있는 chef 를 이용한 opsworks 를 이용하면 학습에 대한 비용이 아깝지도 않으면서 충분한 커스터 마이징 가능한 서버 자동화가 가능하다. 또한 kitchen 을 통해 로컬에서 테스트를 해보면서 그렇게 검증된 쿡북을 opsworks 에 적용할 수 있으므로 모든 것이 전천 후이다.
한국 리전에서 opsworks 가 지원이 아직 안되므로 어차피 국내 서비스만 할 것이 아니기에 Oregon 을 사용해야 겠다.

 

사실 digitalocean 이 낫다. 스케일링 생각할 경우이고 그냥 자그마한 서비스는 디지털 오션으로 on premise 비슷하게 사용하는 것이 낫다.

http://www.cloudping.info/ 로 테스트 해보았을 때 싱가포르 보다도 빠르네... 도쿄랑 그리 차이도 안나면서... 오레곤을 기준으로 해야겠다.

 

 

 

 

참고용 글

 

http://docs.aws.amazon.com/opsworks/latest/userguide/cookbooks-101-opsworks-berkshelf.html

berkshelf Berksfile on AWS opsworks

http://docs.aws.amazon.com/opsworks/latest/userguide/cookbooks-101-opsworks-berkshelf.html

berkshelf 란 자바로 따지면 메이븐 로컬 리포지터리와 비슷하다고 볼 수 있는 것이다.
source 부분에 보통 https://supermarket.chef.io/ 를 지정해주고 metadata 를 지정해주거나 cookbook 'mongodb' 와 같이 지정해준다. metadata 는 해당 쿡북의 metadata.rb 의 depends 를 참조하여 source 로 부터 다운로드 받아 ~/.berkshelf/cookbooks 에 넣어준다. 또한 cookbook 으로 지정한 쿡북도 다운로드 받아 넣어준다. 이렇게 로컬 전역 쿡북 리포지터리를 참고할 수 있도록 한다.

opsworks 에서는 루트에 Berksfile 을 넣어주면 이를 실행한다. 대신 cookbook 으로 지정하는 방식만 사용한다. metadata 방식은 해당 쿡북 안에서 실행하는 방식. opsworks 의 경우 쿡북 하나하나의 Berksfile 을 참고하지 않는다. 로컬에서야 해당 디렉토리에서 berks install 하면 되지만 opsworks 는 그런게 없다.

이렇게 Berksfile 을 사용하지 않으려면 미리 knife 로 supermarket.chef.io 로 부터 knife cookbook site download mongodb 나 knife cookbook site install mongodb 같이 해서 직접 다운받아서 모두 포함시켜주어야 한다.

nodejs 앱 배포의 경우 deploy 라는 쿡북은 이제 supermarket 에는 없는 듯 하다. application_javascript 라는 쿡북이 nodejs 배포 및 실행 용 쿡북이다.

 

 

 

 

 

https://github.com/awslabs/opsworks-linux-demo-nodejs

opsworks 의 기본 샘플은 
https://github.com/awslabs/opsworks-linux-demo-nodejs 이 녀석을 사용한다.
nodejs_demo 쿡북을 opsworks layer 의 Recipes 의 Deploy 부분에 적어주면 default 레시피가 실행된다.

custom cookbook 을 수행하지 않는 기본 layer 로 인스턴스 생성 후 app 에 위와 같이 demo-nodejs 앱을 Deploy 로 수행하여도 실행되지 않았다. 

opsworks 의 app 은 nodejs_demo 의 default 레시피에서 보면 
search(:aws_opsworks_app).first
app_path = "/srv/#{app['shortname']}"
이런 코드들로 보아 app 을 찾아서 수행해주는 듯 하다. 아직 앱이라는 것, 아마존 의존적인 application_javascript 의 사용법은 몰라서 위와 같이 app 을 찾는 방식도 있다는 정도만 참고하자.

Layer 마다
Setup, Configure, Deploy, Undeploy, Shutdown 단계별로 수행될 recipe 들을 설정할 수 있다. 
• Setup 새로운 인스턴스가 성공적으로 부팅하고 난 뒤.
• Configure 인스턴스가 online 상태로 enter 하거나 leave 할 때.
• Deploy 앱 디플로이 시.
• Undeploy 앱 삭제 시.
• Shutdown 인스턴스를 stop 할 때.

따라서 redis slave 관련 레시피는 Setup 에 nodejs app 관련 레시피는 Deploy 에 넣어주어야 한다. Deploy 부분에 앱을 배포 후에 실행할 레시피를 넣어주면 된다. 앱은 /srv 를 절대 경로로 하며 보통은 app_path = "/srv/#{app['shortname']}" 이런식으로 app 의 shortname 을 바탕으로 그 경로에 배포하도록 한다. 하지만 이는 전적으로 Deploy 에 설정한 레시피에 따른다. 즉 opsworks 상의 app 이란 것은 단지 소스 레포지토리를 바라보고 있는 정보일 뿐이며 그것의 정보를 app = search(:aws_opsworks_app).first 이런식으로 가져올 수 있도록 해놓은 것이다. 따라서 앱을 git 이든 s3 저장소이든 뭐든 간에 그것을 가져와서 /srv/... 에 넣고 그것을 npm install 하고 실행시키고 하는 행위는 모두 Deploy 에 설정된 레시피에 따른다.

apt, ntp, build-essential, git, firewall, fail2ban, imagemagick, redis, poise, openssl, mysql, mariadb, postgresql, database 등등 과 같은 쿡북들이 많이 존재한다. https://supermarket.chef.io/

knife, berkshelf, kitchen 과 같은 툴 들이 있는데

knife 는 chef.io 의 management 콘솔과 연관이 많다. 기본적으로 제공되는 chef master 라고 보면 되는데 여기에 쿡북 들을 업로드하고 이를 통해 리모트 서버들에 프로비저닝하고 레시피를 적용하는 일을 하며 data bags 를 통해 암호화 하는 등의 작업 등을 할 수 있다. 한마디로 요리용 칼이다.

berkshelf 는 Berksfile 에 source 가 보통 수퍼마켓.chef.io 이고 metadata 를 넣어놓는데 이게 수퍼마켓을 소스 레포지터리로 바라보면서 메타데이타 파일을 참고하여 거기의 dependency 들을 자동으로 ~/.berkshelf/cookbooks 에 다운받아 놓고 또한 이를 업로드 할 수도 있으면서 공동으로 사용할 수 있도록 한다. 이미 누군가가 만들어 놓은 공식적인 쿡북들을 사용하기 위한 책장이다.

kitchen 은 이들을 적용해 볼 수 있도록 로컬에서 가상서버에 바로 프로비저닝하고 요리책을 적용해서 실제로 kitchen login 을 통해 접속도 하고 테스트 해볼 수 있다.

http://serebrov.github.io/html/2014-12-19-aws-opsworks-mongo-and-nodejs.html

여기의 글을 바탕으로 

https://github.com/dmarcelino/aws-cookbook-boilerplate

이 코드를 적용할 것이며, 레디스 슬레이브를 추가해 주어야 한다.

레디스 마스터를 위한 쿡북을 하나 작성해야 하며 

https://supermarket.chef.io/cookbooks/redis 를 사용.

6379 (redis), 27017 (mongodb), 80 (HTTP), 443 (SSL)
를 Security 에 추가.

아마존의 opsworks 에서는 chef.io 의 management 콘솔은 필요없으며 knife 를 사용할 일도 없다. 하지만 디렉토리 규칙을

https://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-installingcustom-repo.html

에 따라 적용해야 한다.

knife cookbook site install mongodb 와 같이 로컬 쿡북 개발 중에는 knife kitchen 등 모두 사용 될 것이다.

클라이언트, 서버, 쿡북 모두의 리포지터리는 아마존의 CodeCommit 을 사용할 것이다.

여기는 chef 11.10 11.4, 0.9 용의 쿡북들이 있다. 12 버전대는 직접 작성 하란다.
https://github.com/aws/opsworks-cookbooks

아마존의 샘플 nodejs 앱을 위한 쿡북들
https://s3.amazonaws.com/opsworks-demo-assets/opsworks-linux-demo-cookbooks-nodejs.tar.gz

실제 코드는 여기.
https://github.com/awslabs/opsworks-linux-demo-cookbook-nodejs

application_javascript 라는 쿡북을 의존하는데
https://supermarket.chef.io/cookbooks/application_javascript
으로서 수퍼마켓에 등록된 것이다. 
Berkshelf 로 인스톨하고 하라고 나온다. Berkshelf 동작 관련 chef 코드가 
https://github.com/awslabs/opsworks-linux-demo-cookbook-nodejs 단독으로는 없어서 이미 다 받아놓은 것을 압축한 
https://s3.amazonaws.com/opsworks-demo-assets/opsworks-linux-demo-cookbooks-nodejs.tar.gz
을 사용해야 한다. 즉, 저렇게 의존하는 것은 미리 다 받아서 동일 레벨의 디렉토리에 존재하면 참조할 수 있는 듯 하다. Berkshelf 인스톨도 가능한지는 모르겠다. 아마도 가능할 듯 하다. 안 그러면 복잡하니깐.
https://github.com/awslabs/opsworks-windows-demo-nodejs.git
이건 샘플 앱 저장소.