별 볼일있는 공간

국내외 업체들을 포함해서 다양한 Cloud 서비스 제공자가 있죠,,, 대표적으로 아마존 AWS 등등 ~

이러한 Cloud Provider를 추상화 하여 API 형태로 만든 것이 CPI 입니다

즉 Cloud Provider Interface :  IaaS Layer를 추상화 시켜 API 형태로 제공하는 셈이죠..

•CPI : Bosh와 IaaS 간의 API Interface

-create_vm, create_disk, attach_disk 등 VM Lifecycle 관리를 위한 method 모음

bosh는 CPI를 통해서 Cloud 상의 인프라를 제어 합니다.

VM , Guest network, volume 등등~ 

bosh가 CPI라는 개념을 쓰는 목적은 무엇일까요?

가장 먼저 Cloud Foundry의 Architecture를 살펴보면 그 이유?를 찾을 수 있다고 생각합니다.

1) 여러 개의 Component? VM으로 독립적으로 구성 -> 분산 배포 시스템

2) 이러한 분산배포 시스템을 Cloud 상의 배포를 위해선 ... 자동화 도구가 필요

3) 다양한 Cloud Provider를 Cover 하기 위해서 CPI라는 추상화 구조체 도입!

개인적인 생각으로는 이런한 요구 사항으로 인해 CloudFoundry에서는 bosh라는 배포도구를 개발하였고 이를 통해 배포를 진행하지 않을까 싶네요...

또한 부가적으로 Chef/puppet 등의 배포도구 처럼 VM 생성 뿐만 아니라 SW 배포하는 역할, VM 모니터링, VM Resurrecter / Alert 등등의 그 이상의 기능도 있지만 이번 주제에서는 여기까지~

CloudFoundry 기반 PaaS 플랫폼 배포를 진행 하면서 모은 자료를 하나하나 정리하려고 합니다 

Why PaaS

o Cloud 환경으로의 IT Infra(Compute/Storage/Network)의 Shift

o IaaS 넘어 개발 환경 및 서비스 플랫폼까지 제공/관리 PaaS 등장

o 신속한 Business를 위한 Application 중심의 Cloud Infra 필요 대두

CloudFoundry

o Open source PaaS platform

o 어플리케이션의 배포/운영을 간소화하기 위한 PaaS Platform

Capability

o Abstraction(추상화,CPI)

• 폭 넓은 Infrastructure 선택(IaaS 독립적)
• 실행되는 언어/프래임워크에 중립적(자유도)

o Automation(Bosh)

• Automated Virtual Infrastructure를 통한 Application의 중앙 대규모 설치/관리/운영
• 큰 규모의 Application의 배포, 실행이 수월

o Scalability(확장성)

• 각 컴포넌트들이 독립적으로 구성 -> 빠른 확장성에 용이

Effect

o Application Platform 및 관리시스템 도입

• Cloud 환경에서의 애플리케이션을 효율적으로 개발·배포·관리(CICD)

o 빠른 인프라 확장성

• 개발 환경의 Re-build 없이 손쉬운 어플리케이션 배포

o 개발자의 요구 만족

• VM Provisioing의 목적이 아닌 Application 개발의 Focus -> 프로젝트의 생명주기 동안 반복적인 개발/배포