Bosh deployment process에는 몇가지 단계가 있다


1. 설치에 필요한 dependency package 다운

2. 모든 job VM parallel 하게 pre-start script 구동 , pre-start script finish 때가지 대기함

3. monit start 호출 되어 process 기동

4. 마찬가지로 post-start script 구동 되고 완료 떄가지 대기

5. all jobs in the deployments 마친 post-deploy script 수행

  • default director property에서 false 되어 있어서 enable 시켜줘야 사용 가능함

6. 추가로 monit에서 특정 job stop drain script 호출

Posted by 뭉탁거림
,

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 서비스



출처: http://docs.cloudfoundry.org/concepts/how-applications-are-staged.html

Posted by 뭉탁거림
,

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


 


Posted by 뭉탁거림
,

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)

Posted by 뭉탁거림
,

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


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


Posted by 뭉탁거림
,