(younjin.jeong@gmail.com, 정윤진) 

회사의 공식 블로그 계정을 얻었는데, 아무래도 거기는 정식 교육을 다 마친후에 포스팅을 하는것이 좋을 것 같아서 일단 여기에. Pivotal 에 입사한 이후에 회사가 가진 다양한 제품에 대해 이리저리 살펴보다 보니, 이 PaaS 라고 불리는 물건이 꽤나 재미있어서 포스팅을 한번. 

Pivotal 이라는데가 사실 제법 꽤 유명한 회사인데, 아직 잘 모르시는 개발자 분들을 많이 만남.  

https://spring.io/ 페이지 맨 아래 보시면. 

© 2015 Pivotal Software, Inc. All Rights Reserved. Terms of Use and Privacy  

앞으로 Spring 하시면서 Pivotal 모르기 없기. (Grails 와 Groovy 도..) :-) 

쭉 쓰다 보니 막상 Cloud Foundry PaaS 를 어떻게 쓰는지, 어떤 컨셉인지에 대한 설명이 잘 없는것 같아서 긴급 추가. Syntax highlight 는 살짝 귀찮아서 나중에 업데이트를 하기로 ㅎㅎ 

git clone [깃트허브에서원하는코드를클론]

cd [클론된코드디렉토리]

cf push [앱이름]

배포 끝. http://앱이름.도메인.컴 으로 접근해 보면 즉각 확인 ㅎㅎ 

내가 지금 MySQL이 내 어플리케이션에 필요하다. 그렇다면 

cf create-service mysql [서비스플랜] [내mysql이름]

cf bind-service [내mysql이름] [앱이름]

그럼 접근 정보는 어떻게 참조하냐. 서비스가 앱에 연결이 되어 있다면 환경 변수로 참조가 가능하겠다. 

https://docs.cloudfoundry.org/devguide/services/managing-services.html

백문이 불여일견. 백견이 불여일행. 이 포스팅을 다 읽고 궁금하시면 http://run.pivotal.io/ 로 고고씡. 60일 트라이얼. PCF 버전에서 현재 지원하는 언어는 아래와 같고, 현재 .NET 을 실험적으로 올려볼 수 있음. 

MacBook-Air:cf-release yjeong$ cf buildpacks

Getting buildpacks...

buildpack                position   enabled   locked   filename   

staticfile_buildpack     1          true      false    staticfile_buildpack-cached-v1.0.0.zip   

java_buildpack_offline   2          true      false    java-buildpack-offline-v3.0.zip   

ruby_buildpack           3          true      false    ruby_buildpack-cached-v1.3.1.zip   

nodejs_buildpack         4          true      false    nodejs_buildpack-cached-v1.2.1.zip   

go_buildpack             5          true      false    go_buildpack-cached-v1.2.0.zip   

python_buildpack         6          true      false    python_buildpack-cached-v1.2.0.zip   

php_buildpack            7          true      false    php_buildpack-cached-v3.1.1.zip  

일단 이 Pivotal 이란 회사가 가진 서비스와 제품의 카테고리는 크게 3가지 정도. 

1. Pivotal Labs 라고 불리는 Software 컨설팅 조직. 고객의 개발자와 모니터를 함께 보며 나란히 앉아 합의한 scope 에 따라 8주 - 12주 정도로 개발을 함께 한다. 이를통해 고객은 빠른 속도로 소프트웨어를 개발하는 방법을 습득 가능. 

2. PaaS. 다양한 클라우드 인프라 기반 위에서 쉽게 코드를 푸시하여 다양한 서비스와 함께 동작시킬 수 있는 서비스. Cloud Foundry 라 불리우는 플랫폼과 그 외의 Pivotal 이 지원하는 다양한 소프트웨어를 함께 구동하고, 서비스에 반영할 수 있다. 로컬 데이터센터 및 퍼블릭 클라우드, 프라이빗 클라우드 모두에서 동작이 가능. 

3. 빅데이터 관련 제품들. 제법 유명한 Greenplum 과 HAWQ, Pivotal Hadoop 등이 있다. Big Data Suite (BDS) 라 불리우는 패키지로 존재하기도. 

위의 세가지는, 빠르게 소프트웨어를 개발하는 플랫폼으로 PaaS 를 사용하고 -> 이를 통해서 얻어지는 로그 및 다양한 데이터를 분석해서 -> 다시 어플리케이션에 반영하는 구조에 최적화 되어 있다. 만약 IT 를 전문으로 하는 회사가 아니라면 Labs 과 함께 실제 어플리케이션 개발을 진행해 봄으로서 경험을 체득하는 형태로 구성된다. 

Pivotal Labs 에 대한 간략한 설명 

https://en.wikipedia.org/wiki/Pivotal_Labs

Case: http://pivotallabs.com/case-studies/

Pivotal Tracker : http://www.pivotaltracker.com/

PaaS 그 자체가 가진 기능도 기능이겠지만, eco system 도 살펴볼 필요가 있다. 어떤 도구들을 함께 PaaS 에서 사용할 수 있는지는 개발자들에게는 매우 중요하니까.  https://pivotal.io/platform-as-a-service/pivotal-cloud-foundry/services

그니까 간단하게 몇가지만 소개를 해 보자면. 

- Redis 

- RabbitMQ

- MySQL 

- Gemfire : 이게 제법 엄청난 물건. 글로벌 레벨로 동기화가 가능한 인-메모리 NoSQL : http://pivotal.io/big-data/pivotal-gemfire 

- Pivotal Hadoop 

- Cassandra with Datasax 

- Riak CS, S3 compatible storage

- MongDB

- Neo4j 

- Jenkins 

- Mobile 관련 : Data sync, App Gateway, Push Notifications, App Distribution 

이것들은 모두 Pivotal 의 Cloud Foundry 라 불리는 PaaS 안에서 서비스의 형태로 자연스럽게 연동되며, 여기에 없는 서비스라도 service broker 라는 메커니즘을 통해 외부의 서비스와 연동이 가능하다. 따라서 개발자는 원하는 서비스를 입맛에 맞게 선택하고 이를 코드로 작성하여 바로 배포하여 사용할 수 있는, 그것도 우리 회사의 데이터센터와 AWS, 이후에는 Azure 및 GCE 등에도 코드 변경없이 그대로 푸시가 가능하다는 점. 

Pivotal 은 역시 또 그 자체로 다양한 오픈소스의 공헌자이기도 하다. 아래는 Pivotal 이 씨게 지원하고 있는 OSS 리스트. 

http://pivotal.io/oss

HP나 IBM의 PaaS 관련 제품들이 Cloud Foundry 기반이라는 것은 이미 널리 알려진 사실. 그리고 이 오픈 소스 버전의 Cloud Foundry 에 commit 되는 code 의 90% 이상이 Pivotal 에서 나온다는 점. 그리고 그 오픈소스에 대한 지원과 사용의 편의성을 구현한 것이 바로 Pivotal Cloud Foundry. 

만약 VMware 기반의 vCenter 환경이 있거나, AWS에 계정이 있거나, 또는 OpenStack 을 구성했다면 Pivotal CF 를 다운받아서 설치해 볼 수 있다. 관련 제품의 다운로드는 https://network.pivotal.io/ 에서. 

아니 그래서 그게 뭔데 라고 아직도 궁금해 하시는 분들을 위해 설명을 조금 보태자면. 

코드는 일반적으로 어떤 서비스를 사용하느냐에 따라 종속성을 가지게 되는데, 이는 클라우드 서비스 공급자 별로 제공하는 SDK 는 물론이거니와 코드 내에서도 어떤 WAS 를 사용하는가, 또는 어떤 캐시클러스터를 사용하는가에 따라 어떠한 환경에 종속적이게 된다. 이러한 제약은 이전에는 뭐 그래, 우리가 그런 소프트웨어와 인프라를 구매 했으니까 라고 생각 될 수 있겠지만, 클라우드 시대에는 각 퍼블릭 클라우드가 제공하는 가격에 따라, 그리고 지역적인 요건, 네트워크의 성능등 다양한 사업 요구 조건에 따라 어플리케이션을 배포하고 구동할 수 있어야 한다는 것. 그러나 이럴때마다 매번 각 환경에 맞도록 코드를 다시 써야한다면 엄청난 수고가 아닐 수 없다. 

단순히 멀티클라우드에 대한 요구 사항 뿐만 아니라, 작성된 코드의 동작 여부를 빠르게 확인하고, 이를 prod / stag / dev 환경의 변화에 따른 코드 변화 없이 바로 서비스에 반영할 수 있다는 장점을 얻을 수 있는것. 

이 모든것은 '스피드'와 연관이 있으며, 개발이 빨라질 수록 사업의 혁신도 빨라진다는 이야기. 

한가지 더 추가 하자면, Cloud Foundry 에 배포되는 앱은 컨테이너 기반이라는 것. - 재밌겠쥬? 

아래는 PCF 의 화면. run.pivotal.io 

그리고 이것은 AWS에 설치한 PCF. 

Cloud Foundry 에 대한 더 쉬운 설명은... 흠. 

"On-premise 와 AWS, GCE, Azure, OpenStack, VMware 를 지원하는 확장된 Heroku"

간단 데모 

STS + Cloud Foundry  

백견이 불여일행. 

https://run.pivotal.io

더 재미있는것은 공식 블로그 오픈과 함께 고고씡! 

추가. 

Cloud Foundry on AWS 

http://blog.pivotal.io/pivotal-cloud-foundry/products/pivotal_cloud_foundry_on_amazon_web_services

Cloud Foundry on Azure 

https://azure.microsoft.com/blog/2015/05/29/try-cloud-foundry-on-azure-today/ 

Cloud Foundry on GCE 

http://blog.pivotal.io/pivotal-cloud-foundry/products/deploy-and-update-your-google-compute-engine-vms-using-cloud-foundry-bosh

Cloud Foundry on OpenStack 

http://blog.pivotal.io/pivotal-cloud-foundry/products/migrating-a-cloud-foundry-paas-to-run-on-openstack

(younjin.jeong@gmail.com, 정윤진) 

( younjin.jeong@gmail.com, 정윤진 ) 

최근에는 클라우드를 사용한 온라인 개발 도구가 늘어나고 있다. 이미 좀 오래 되었지만 github 라던가, Cloud9IDE, 그리고 최근 firejune 에 의해 커스터마이즈된 JSbin 과 같은 도구들은 클라우드의 기능성과 더불어 언제 어디서나 개발이 가능한 환경을 만들어 주고 있다. 

국내 클라우드 업체들에서는 모두 아마존 꽁무니 쫒아 가느라 가랑이가 찢어지는 사이에, 이러한 도구들은 개발자들에게 가뭄의 단비와 같은 솔루션이 되고 있지 않나 싶다. 기실 조금만 생각 해 보면 서비스로서의 가치가 충분한데도, 아마존은 쫒아가려 하면서 구글은 쫒지 않는, 즉 바꿔 말하면 호스팅 서비스 그 이상의 무엇이 없지 않나 생각 해 볼 일이다. 

호스팅 서비스 역시 지난날의 웹 콘솔을 통한 관리를 넘어, 이제 oAuth 나 OpenID 등을 통한 인증, 그리고 이 인증을 바탕으로 한 API 의 지원이 필수적인 요소가 되어가고 있다. 클라우드로 만드는 서비스를 이제 서비스 업체의 웹 브라우저 콘솔만으로 제어하는 것은 이제 바가지에 밥떠먹는 것과 같은 시대가 되어 버렸다. 

오늘 소개할  Heroku, 그리고 Joyent 와 같은 클라우드 기반 호스팅은 사용자가 서버를 설정 할 필요 없이, 제공되는 클라이언트 도구 또는 다른 서비스와의 연동을 통해 온라인으로 언제 어디에서나 코드를 작성하고, 이를 배포하여 서비스 동작 여부의 확인이 가능하다. 따라서, 기존 node.js 또는 기타 여러가지의 서비스를 온라인에서 사용하려는 경우, 서버를 설치하고, 코드 저장소를 설정하는 등의 노력 없이 그저 서비스에 로그인하고, 사용하다가 일정 수준 이상의 사용량이 되면 금액을 지불하면 된다. 

사실 개발자에게 개발이 가능한 전체 환경의 설정은 매우 피곤한 일이 아닐 수 없다. 물론 내가 개발자는 아니지만, 대다수의 많은 개발자 분들이 환경 설정하는데 꽤 애를 먹으며, 이게 코드가 문제인지 인프라가 문제인지 알쏭달쏭한 경우에 빠지는 경우도 많다고 생각한다. 이러한 난제를 해결하는데 클라우드만큼 좋은게 없으며, 사용자 또는 개발자는 그저 서비스 신청, 개발환경 접근, 배포의 과정을 아주 쉽게 처리 할 수 있어 개발에만 전념 할 수 있도록 도와준다. 

오늘 소개할 조합은 바로 온라인 개발도구 Cloud9IDE ( http://c9.io ) 와 일종의 PaaS 서비스 Heroku ( http://www.heroku.com )  이다. 일단 사용량이 많지 않은 경우에는 무료로 사용 할 수 있으며, 처음 가입시 별도의 카드 정보와 같은 결재 정보도 필요 없다. 환경을 설정 해 보고, 코드를 개발 하면서 개발 된 코드가 정상적으로 동작 하는지 확인 하는데 사용하면 좋을 것 같다는 생각에 포스팅 해 본다. 물론, 이미 알고 계신 분들도 많겠지만. 

먼저, Heroku 에 가입한다. 가입 절차는 매우 간단하며, 메일 주소와 비밀번호 정도만 입력 하면 된다. 홈페이지에 접근하면 한 가운데 떵그머니 있는 Sign Up 버튼을 이용하자. 가입이 완료되면 로컬 머신에서의 환경 설정이 나타나는데, 이건 필요하면 하고 Cloud9 의 서비스와 연동할 거라면 굳이 하지 않아도 된다. 개발자에게는 골치 아픈 일일 뿐이다. 

가입을 완료 했으면 일단 두고, 이제 Cloud9IDE 에 가입하자. 역시 동일하게 계정을 생성하고, 로그인 후에 대시보드를 통해 프로젝트를 생성해 본다. 프로젝트를 생성했으면 "Start Edit" 을 살포시 눌러 실제 코드의 작성이 가능한 브라우저로 이동한다. 

이제, 아래와 같은 화면을 볼 수 있다. 

Cloud9IDE Project Page

화면 구성을 보면 일반적인 IDE 환경과 크게 다르지 않다. 가장 왼쪽에는 파일 브라우저, 배포, 설정, 테스트 등의 기능의 선택이 가능하고, 나머지는 온라인 코드를 수정하기 위한 공간이다. 새로운 파일은 왼쪽 상단의 파일 메뉴에서 생성이 가능하며, 원하는 경우 각종 코드 템플릿을 선택하여 사용 할 수도 있다. 생성된 코드는 일반적인 에디터의 저장 단축키와 같은 Cntl+s, 맥에서는 command+s 로도 잘 동작한다. 

여기까지는 일반 개발환경의 설정이며, 이제 Heroku 서비스로의 연결이 가능하다. 먼저, 왼쪽 기구 모양의 Deploy 버튼을 누른다. 

파일 브라우저의 모양이 바뀌면서, 상단에 -, + 버튼이 생긴다. 여기에서 + 버튼을 눌러 보면 다음과 같은 화면을 볼 수 있다. 

C9IDE, Select deploy site

위의 버튼을 눌러보면, Cloud9 이 지원하는 클라우드 기반 서비스를 확인 할 수 있다. 다른것은 모르겠는데, Windows Azure 를 지원한다. 이는 곧, 기존의 닷넷 개발자 분들도 git, Azure 에 대한 가벼운 이해만 있다면 C# 코딩을 그대로 하실 수 있다는 말이 되겠다. 아직 안해봐서 나는 모르겠지만, 아무튼 지금의 목적은 Heroku 로의 연결이므로, heroku 를 선택하고 아까 만들었던 Heroku 의 계정을 입력한다. 그리고 오른편의 Create New 버튼을 누르면, heroku 로 부터 코드 배포에 사용할 인스턴스를 만들 수 있다. 원하는 이름을 주고 하나 만들어 두자. 

생성을 완료하고 페이지에서 나오면, 이제 Deploy 탭에 Heroku 에서 생성한 인스턴스의 이름이 나타나는 것을 볼 수 있다. 이 인스턴스 이름을 클릭하면, 배포가 가능하다. 하지만 아직 배포할 코드가 아무것도 없으므로, 하나 작성해 보도록 하자. 

코드를 작성하기 전에, 다음과 같은 주요 내용을 이해해야 한다. 

1. Heroku 는 git 를 사용하여 동작한다. 코드를 생성하고, git push heroku master 와 같은 방법으로 동작하지만, Cloud9 에서는 그런 별도의 과정 없이 Cloud9 의 로컬 저장소에 commit 한 후에 인스턴스에 Deploy 하면 쉽게 적용 된다. 

2. Heroku 에서 Node.js 를 동작하기 위해서는 필요한 패키지, 실행 할 인스턴스의 수량 또는 종류 등을 지정해야 한다. 이는 Heroku 의 문서에 잘 나와 있으므로 여기를 참조 하도록 한다. 

https://devcenter.heroku.com/articles/nodejs

3. 기본적으로 Node.js 의 동작에 대해 이해하고 있어야 Heroku 를 손쉽게 사용 할 수 있다. 

Cloud9IDE 의 왼족 상단의 Project Files 를 클릭하고, 신규 파일을 다음과 같이 저장하자. 

파일: .gitignore 

 node_modules 

package.json

{
    "name": "node-example",
    "version": "0.0.1",
    "engines": {
        "node": "0.6.15",
        "npm": "1.1.9"
    },
    "dependencies": {
        "express": "2.5.9"
    }
}

Procfile

 web: node web.js

web.js

var express = require("express");

var app = express.createServer(express.logger());

app.get('/', function(request, response) {
    response.send('Hello Firejune!');
});

var port = process.env.PORT || 3000;
app.listen(port, function() {
    console.log("Listening on " + port); 
});

대충 보면 감이 잡힐지도 모르겠다. 

.gitignore 는 git 로 작업할때 무시할 디렉토리이다. 여기에 node_modules 가 지정된 것은 node_modules 디렉토리를 heroku 에 업로드 하지 않아도 되기 때문이다. 업로드 하지 않아도 되는 이유는 바로 package.json 에서 필요한 패키지를 명시하였기 때문이며, 여기에 필요한 패키지 리스트를 잘 지정하였다면 별 문제 없다. 물론 여기서 애플리케이션 동작에 필요한 각종 모듈 및 node, npm 의 버전 명시가 가능하다. 사용 가능한 버전은 Heroku 페이지를 통해 공개되고 있으니 구글링을 통해 참고 하면 된다. 사용 방법은 위에 명시된 것과 같다.  Procfile 은 Heroku 에서 구동할 애플리케이션의 용도와 파일을 지정한다. 마지막으로 web.js 는 실제 node.js 를 사용하여 작성한 코드가 된다. 

Cloud9IDE 의 아랫쪽을 보면, console 이 있다. 이는 각종 커맨드의 사용을 위해 존재하는데, 여기서 우리는 npm 으로 필요한 모듈의 설치가 가능하다. 위의 예제는 heroku 로 부터 제공된 것으로서, express 모듈을 사용하고 있다. 따라서 이 콘솔에 다음과 같이 입력한다. 

npm install express@2.9.5 

이후 설치 메세지가 나타나는 것을 확인 할 수 있으며, 만약 현재 Cloud9IDE 의 버전과 맞지 않는다면 npm info 등을 통해 적절한 버전으로 변경 해 주면 된다. 

이제, 작성한 코드가 잘 동작하는지 확인 할 필요가 있다. Cloud9IDE 의 아랫편에 보면 Console 이 있는데, 여기에 커맨드를 입력하여 원하는 작업을 할 수 있다. 다른건 됬고, git 관련 커맨드만 넣도록 한다. 

git init
git add .
git commit -m "First commit for Heroku"

모두 다 실행이 완료 되었다면, 다시 제일 왼편의 Deploy 를 클릭한다. 생성된 애플리케이션 인스턴스를 클릭하면 Deploy 버튼이 나타난다. 클릭하자. 

자, 그러면 이제 Cloud9IDE 의 로컬 repo 에서 Heroku 로 코드가 업로드 되고, 이후 애플리케이션이 준비되는 과정을 로그로 볼 수 있다. 정상적으로 잘 수행하였다면, 다음과 같은 화면을 볼 수 있을 것이다. 

제일 아래 나타난 링크를 클릭하면, 배포된 애플리케이션이 동작 하는지 아닌지를 잘 알 수 있다. 

만약 기존에 개발한 애플리케이션이 다른 버전의 node 와 npm 을 사용한다면, 아래의 링크를 통해 현재 Heroku 에서 지원하는 버전의 지정이 가능하다. 

node.js version manifest

npm version manifest

아마 클라우드라는 환경을 가장 생산적으로 사용이 가능한 사용자군은 개발자들일 것이다. 적절한 방법과 사용성만 있다면, 아이폰의 앱 결재 하듯 한달에 1~2 만원 지불하면서 본인의 자가 발전을 위해 사용해도 아깝지 않을 정도이다. 다만 Cloud9IDE 가 현재 국내에 서버가 없으므로 망의 영향을 받을 가능성이 충분하긴 하지만. 

이런 서비스를 만들어 내는것은 아무것도 아니다 라고 말하기는 좀 그렇지만, 그렇다고 엄청나게 어려운 것은 아니다. 원하는 기능을 적절히 믹스하고, 한번에 잘 동작하게 만든다면 쓸데없이 VM 생성해 두고 뭐할까 고민하는 일은 없을 것이다. 

국내의 각종 클라우드 서비스들도 미국에 비해 일반인의 클라우드에 대한 인식이 현저히 떨어지는 한국에서 매출이 안나온다고 고민하고 있을게 아니라, 위와 같은 서비스의 런칭이 필요하지 않나 생각 해 본다. 

아무튼 준호형과 관련된 재미진 프로젝트를 해 보면 어떨까 한다. 이와 비슷한, 그러나 뭔가 다른. 

( younjin.jeong@gmail.com, 정윤진 )