cloudfoundy 배포 도구 bosh

cloudfoundy 배포 도구 bosh [bosh outer shell]

CloudFoundry Platform 배포를 위해선 bosh라는 배포 도구를 반드시 익혀야 합니다.

결론부터 .. bosh는 Cloud 상의 VM의 Deploy/배포/모니터링/업데이트/라이프사이클 관리 등의 versitile한 도구입니다

Chef/puppet/ansible 등 CM Tool(Configutaion Tool)과는 다른 사상의 자동화 도구라고 볼 수 있지 않을까요?

 

정의

• BOSH was developed to deploy Cloud Foundry PaaS, it can also be used to deploy almost any other software (Hadoop, for instance)
• Cloud 환경의 VM deploy/managing 및 Software 배포 오픈소스 platform

bosh를 통해 다량의 VM을 deploy하고 software를 provisioning

 

 

CloudFoundry의 컴포넌트들이 독립적이고 확장적인 구조이기 때문에 bosh를 통해 중앙에서 설치/관리/운영하게 됩니다.

여기 CPI라는 개념이 나오는데요... 다음 편으로 ~

 

 

출처: https://wlstnans.tistory.com/107

cloudfoundy 배포 도구 bosh [bosh outer shell]

bosh, cpi, container, buildpack 등.. 생소했던 개념을 다루기 전에...

cloud 환경에서의 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 -> 프로젝트의 생명주기 동안 반복적인 개발/배포

출처: https://wlstnans.tistory.com/105

bosh를 통한 cloud 환경에 VM 배포 시 canary와 max_in_flight라는 개념 있다.

manifest 파일에서 해당 값을 어떻게 조절하냐에 따라서 배포 완료 시간에 차이가 생길텐데...

 

1. canary : VM 생성 이후 JOB에 설정 된 SW 배포 시 검증을 하는 Instance

2. max_in_flight : canary Instance를 제외하고 동시에 update 하는 Instance의 숫자

 

처음엔.. 이 2가지 개념이 도무지 이해가 안되던데...

결론은 해당 값들을 수정할 필요는 거의 없겠지만... 사용하고 있는 Cloud IaaS 인프라가 성능상에 문제가 있다면 max_in_flight 값을 수정할 필요가 있지 않을까 싶다.

 

아래 ntp sample deploy를 테스트 결과를 보고 이해에 도움이 되었다.

 

job : 6

canary : 1

max_in_flight : 3

 

  Started updating job ntpd

  Started updating job ntpd > ntpd/0 (canary). Done (00:00:44)

  Started updating job ntpd > ntpd/1

  Started updating job ntpd > ntpd/2

  Started updating job ntpd > ntpd/3

     Done updating job ntpd > ntpd/1 (00:00:50)

  Started updating job ntpd > ntpd/4

     Done updating job ntpd > ntpd/3 (00:00:50)

  Started updating job ntpd > ntpd/5

     Done updating job ntpd > ntpd/2 (00:00:50)

     Done updating job ntpd > ntpd/4 (00:00:48)

     Done updating job ntpd > ntpd/5 (00:00:47)

     Done updating job ntpd (00:02:22)

 

 

job: 6

canary : 2

max_in_flght : 4

 

Started updating job ntpd

  Started updating job ntpd > ntpd/0 (canary)

  Started updating job ntpd > ntpd/1 (canary). Done (00:00:48)

     Done updating job ntpd > ntpd/0 (canary) (00:00:49)

  Started updating job ntpd > ntpd/2

  Started updating job ntpd > ntpd/3

  Started updating job ntpd > ntpd/4

  Started updating job ntpd > ntpd/5

     Done updating job ntpd > ntpd/3 (00:00:51)

     Done updating job ntpd > ntpd/4 (00:00:51)

     Done updating job ntpd > ntpd/2 (00:00:51)

     Done updating job ntpd > ntpd/5 (00:00:53)

     Done updating job ntpd (00:01:42)

 

 

 

job: 6

canary : 1

max_in_flght : 6

 

Started updating job ntpd

  Started updating job ntpd > ntpd/0 (canary). Done (00:00:44)

  Started updating job ntpd > ntpd/1

  Started updating job ntpd > ntpd/2

  Started updating job ntpd > ntpd/3

  Started updating job ntpd > ntpd/4

  Started updating job ntpd > ntpd/5

     Done updating job ntpd > ntpd/4 (00:00:54)

     Done updating job ntpd > ntpd/5 (00:00:54)

     Done updating job ntpd > ntpd/2 (00:00:55)

     Done updating job ntpd > ntpd/1 (00:00:55)

     Done updating job ntpd > ntpd/3 (00:00:56)

     Done updating job ntpd (00:01:40)

 

출처: https://wlstnans.tistory.com/106

 

국내외 업체들을 포함해서 다양한 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 등등의 그 이상의 기능도 있지만 이번 주제에서는 여기까지~

출처: https://wlstnans.tistory.com/108

CloudFoundry user-provide-service setting

CloudFoundry 2016. 4. 20. 00:49

CloudFoundry에서는 service broker를 통한 marketplace 서비스 뿐만 아니라 외부의 3rd party 서비스를 broker 없에 플랫폼에서 사용할수 있다.

CloudFoundry 상의 app들이 외부의 서비스와 연동이 가능하다는 의미!

 

단. 조건이 custom user provided service 생성 작업을 해야지.. cf services 에 노출이 되고.. app binding이 가능하다

 

 

cf cups SERVICE_INSTANCE -p "host, port, dbname, username, password"

 

cf env app_name

 

 

  "credentials": {

     "hostname": "192.168.31.11",

     "jdbcUrl": "jdbc:mysql://172.27.31.11:3306/cf_6ced88bb_5078_4f00_b28b_55cdbfafe716?user=YYIbSHmkjuan5y8G\u0026password=vf8LA3kcOoiaa0OW",

     "name": "cf_6ced88bb_5078_4f00_b28b_55cdbfafe716",

     "password": "password",

     "port": 3306,

     "uri": "mysql://YYIbSHmkjuan5y8G:vf8LA3kcOoiaa0OW@192.168.31.11:3306/cf_6ced88bb_5078_4f00_b28b_55cdbfafe716?reconnect=true",

     "username": "password"

 

 

출처 : http://www.slideshare.net/SpringCentral/spring-one-extendingcf

출처: https://wlstnans.tistory.com/111

CloudFoundry user-provide-service setting

 

[CloudFoundry] cf push process(application 배포)

 

Application + MD(metadata? manifest.yml 파일)

 

manifest file : 소스코드를 올리기전에 application에 대한 사전 정의 파일로 예를 들어 instance 갯수나, 어플리케이션 메모리, 서비스 bind 정보등이 있는 파일

 

사용자가 cf push를 통한 application 배포 시

 

1. Cloud Controller 통해 Blobstore에 소스 코드 업로드, CCDB에 및 배포 정보 저장

2. 서비스 BIND 정보가 있다면 서비스 브로커 통해서 서비스 바인딩 할당 및 BIND

3. Staging 단계 -> 소스코드와 빌드팩을 통해 실행환경(런타임)을 구성하는 단계

   업로드된 어플리케이션이 기본적으로 확장자를 통해서 detect를 하고 app 실행환경 자동 구성

   이때 staging 용도의 임시의 Application이 생성되어 staging 과정에 관여함

4. droplet 생성 후 blobstore 캐싱 -> 컨테이너 증설 시 원본을 가지고 clone

5. dea 위에 application Container가 배포 완료

 

서비스 브로커는 REST API 형태로 구현된 형태로 Service instance 가 연동할수 있도록 역할

사용자가 CLI 명령어나 WEB UI를 통해 Create 서비스\

출처: https://wlstnans.tistory.com/114