System Compleat.

'클라우드 파운드리'에 해당되는 글 1건

  1. Pivotal Cloud Foundry - PaaS 3

Pivotal Cloud Foundry - PaaS

Techs


(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, 정윤진)