bosh sample release를 개발하기 위해 사전 테스트 작업으로 apache를 bosh를 통해 배포하여 보자

 


1. Release 생성

# bosh init release test-release


root@jenkins:~/workspace/test-release# tree

├── blobs

├── config

   └── blobs.yml

├── jobs

├── packages

└── src



2. Package 생성 : 배포에 필요한 binary file과 job에서 사용할 src 및 dependency file 제공


# bosh generate package apache2


root@jenkins:~/workspace/bosh_install_test/packages# tree

└── apache2

    ├── packaging

    ├── pre_packaging

    └── spec


또.. 여러개 파일이 default로 생성된다...

1) spec 파일 수정

   - name : package name

   - dependencies : Package's dependencies

   - files :The location where BOSH can find the binaries and other files that the package needs at compile time


---

name: apache2


dependencies:


files:

  - apache2/httpd-2.2.25.tar.gz


 2) src 디렉토리에시 필요한 파일 download

# mkdir src/apache2

# cd src/apache2

# wget 'http://apache.tradebit.com/pub/httpd/httpd-2.2.25.tar.gz'


 3) packaging (compilation script) 작성

echo "Extracting apache https..."

tar xzf apache2/httpd-2.2.25.tar.gz


echo "Building apache https..."

(

   cd httpd-2.2.25

    ./configure \

    --prefix=${BOSH_INSTALL_TARGET} \

    --enable-so

    make

    make install

}

EOF 


release의 package 설정을 대강 마무리 됬고 pre_packaging의 용도는 모르겠다.

아래로 대망의 job 생성


3. job 생성

# bosh generate job apache2



create jobs/apache2

create jobs/apache2/templates

create jobs/apache2/spec

create jobs/apache2/monit


또 이것저것 만들고...


1) spec : spec 파일은 job metadata 정의한 파일로 bosh 통해 deploy 해석되어 사용된다

         name, description, templates, package, properties 구성 되어 있음

         spec 파일의 자세한 schema https://bosh.io/docs/jobs.html 참조


  • Compile 단계에 BOSH는 template들을 file 변환하여 JOB VM 복사함
  • Key/value 형식으로 선언되며, key template 폴더의 파일 name, value JOB VM 복사되는 PATH 파일 이름

    /var/vcap/jobs/<job_name>/bin/ctl on the job VM


---

name: apache2

 

description: This job runs a simple HTTP server.

 

templates:

  httpd.conf.erb: config/httpd.conf

 

packages:

  - apache2

 

properties:

  name:

     description: name set test

  age:

     description: age deafult set test

     default: 99



너무 길어지니.. 우선 여기까지~





 

'CloudFoundry' 카테고리의 다른 글

[bosh] job lifecycle  (0) 2016.06.02
[bosh] release, job  (0) 2016.06.02
bosh-lite 이용한 CloudFoundry deploy  (0) 2016.04.20
[CloudFoundry] cf push process(application 배포)  (0) 2016.04.20
CloudFoundry user-provide-service setting  (0) 2016.04.20
Posted by 뭉탁거림
,

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 뭉탁거림
,

[bosh] release, job

CloudFoundry 2016. 6. 2. 15:49

BOSH는 VM 내부의 SW 배포에 필요한 설치 파일/script/소스등의 모음 인 release라는 파일을 통해 Deploy를 수행합니다.



물론 그 과정에 Manifest라는 파일과 stemcell 이미지가 필요하지만요...


BOSH release 구성요소는 다음과 같습니다


1) Jobs describe pieces of the service or application you are releasing

2) Packages provide source code and dependencies to jobs

3) Source provides packages the non-binary files they need

4) Blobs provide packages the binaries they need, other than binaries that are checked into a source code repository


1. Release 생성


# bosh init release <release_name>

아래와 같이 Release의 기본 구조가 만들어짐

├── blobs

├── config

   └── blobs.yml

├── jobs

├── packages

└── src


2. jobs 생성


Release job 수행 work 묶음

예를 들어 dhcp Release라고 하면 dhcp_server job 있을테고 APM Release 라면 apache, mysql, php 설치/설정하는 3가지의 job으로 나눌 있지 않을까 싶다

 

아래 명령어로 job을 만들게 되면 아래 구조로 각각의 job의 골격이 만들어진다

# bosh generate job <job_name>


create        jobs/job_one

create        jobs/job_one/templates

create        jobs/job_one/spec

create        jobs/job_one/monit

 

jobs

   ├── job_one

   │   ├── monit

   │   ├── spec

   │   └── templates

   │       └── pre-start.sh.erb

   └── job_two

       ├── monit

       ├── spec

       └── templates


여기서

spec : spec 파일은 job metadata 정의한 파일로 bosh 통해 deploy 해석되어 사용된다

         name, description, templates, package, properties 구성 되어 있음

         spec 파일의 자세한 schema https://bosh.io/docs/jobs.html 참조

 

Templates : (ERB 기반의 Configuration file)

                Bosh에서 배포 파일의 Template 역할을 하는 기반임

                Monit에서 사용하는 ctl 파일이나 Hook scripts(pre-start, post-start, post-deploy)  

                참조  가 되는 디렉토리 또한 ERB 파일이기때문에 Basic ERB syntax 이용가능함

  • <%= "value" %>: Inserts string “value”.
  • <% expression %>: Evaluates expression but does not insert content into the template. Useful for if/else/end statements.

<%= p("some.property") %>: Insert the property some.property value, else a default 

 

Monit : process pid 정보와 start, stop 스크립트를 명시한 파일

          monit 설정을 ㅗㅇ해 bosh 해당 job 상태를 체크하고 점검함

Posted by 뭉탁거림
,

BOSH를 알아보면.. 그 종류? 구성 방법에 대한 이야기가 많습니다.

크게 2가지 bosh에 대한 내용이 주를 이루는데요.. 먼저 bosh-lite와 micro-bosh

 

1) bosh-lite

bosh lightweight 버전으로 IaaS VM 환경없이 로컬의 vagrant 환경에서 system deploy 할 수 있다 Warden Cloud Provider Interface (CPI) 사용하며 Container 방식으로 Cloud Foundry Component를 VM 내부에 배포하게 됩니다.

개발 용도의 버전이죠...

 

2) micro-bosh

single vm으로 구성된 bosh Cloud Foundy deploy하거나 IaaS상에 소프트웨어를 deploy 있습니다.

주로 micro-bosh를 통해 CloudFoundry를 배포하죠..


bosh-lite를 통해 CF 배포에 대해 다루도록 하겠습니다.


환경 : Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-90-generic x86_64)

 

1. Install Git

$ apt-get install git

 

2. Install VirtualBox

$ echo "deb http://download.virtualbox.org/virtualbox/debian precise contrib" >> /etc/apt/sources.list

or create a new .list file as described in this thread.

$ wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc -O- | sudo apt-key add -

$ sudo apt-get update

$ sudo apt-get install virtualbox-4.3

$ sudo apt-get install dkms

$ VBoxManage --version

4.3.10_Ubuntur93012

 

3. Install Vagrant (the known version to work with bosh-lite is 1.6.3 - link)

$ wget https://dl.bintray.com/mitchellh/vagrant/vagrant_1.6.3_x86_64.deb

$ sudo dpkg -i vagrant_1.6.3_x86_64.deb

$ vagrant --version

Vagrant 1.6.3

 

4. Check if vagrant is correctly working with the installed virtual box(테스트 이므로 UP 후 삭제)

$ vagrant init hashicorp/precise32

$ vagrant up

 

5. Install Ruby(using RVM) + RubyGems + Bundler(ruby 업데이트 및 버전관리를 위한 rvm 설치)

5.1. Install rvm

$ curl -sSL https://rvm.io/mpapis.asc | gpg --import -

$ curl -sSL https://get.rvm.io | bash -s stable

$ source /etc/profile.d/rvm.sh

$ rvm --version

5.2. Install latest ruby version

$ rvm install 1.9.3-p551

$ rvm use ruby --default 2.1.7

$ ruby -v

ruby 1.9.3p551 (2014-11-13 revision 48407) [x86_64-linux]

 

 

6. Install Bosh CLI (check the prerequisites for the target OS here) : bosh_cli 설치

- Note that Bosh CLI is not suppored on windows - github issue

$ sudo apt-get install build-essential libxml2-dev libsqlite3-dev libxslt1-dev libpq-dev libmysqlclient-dev

$ gem install bosh_cli

 

 

7. Install Bosh-Lite

$ git clone https://github.com/cloudfoundry/bosh-lite

$ cd bosh-lite

$ vagrant up --provider=virtualbox

 

8. bosh target 192.168.50.4 lite

Target set to `Bosh Lite Director'

Your username: admin

Enter password: admin

Logged in as `admin'

 

9. Setup a route between the laptop and the VMs running inside Bosh Lite

$ cd bosh-lite

$ ./bin/add-route(10.254.0.0/16 수정)

 

10. upload stemcell

Stemcell 이미지 다운로드

bosh upload stemcell bosh-stemcell-2776-warden-boshlite-centos-go_agent.tgz

 

Getting the template (“stemcell”) we use to deploy Cloud Foundry

# wget http://bosh-jenkins-gems-warden.s3.amazonaws.com/stemcells/latest-bosh-stemcell-warden.tgz

Uploading the stemcell to BOSH

# bosh upload stemcell latest-bosh-stemcell-warden.tgz

# bosh stemcells

 

 

11. OK, ready to install Cloud Foundry:

# git clone https://github.com/cloudfoundry/cf-release.git

 

Go into the cf-release directory and  update the cf-release using ./update command

12. Use the update helper script to update the cf-release submodules

# cd cf-release

# ./update

 

13 spiff 설치(gvm 을 이용한 go 언어 설치 후 spiff 설치하거나, 방법은 여러가지임)

# git spiff : https://github.com/cloudfoundry-incubator/spiff #installation

# cp spiff /usr/bin/

 

Spiff : To create a valid deployment file for the full deployment of CloudFoundry it is necessary to use Spiff. Spiff is a “A declarative YAML templating system tuned for BOSH deployment manifests.”

spiff is a command line tool and declarative YAML templating system, specially designed for generating BOSH deployment manifests.

14. create deployment manifest stub

 

# bosh status --uuid : bosh target uuid 확인

# vi cf-stub.yml

---

director_uuid: DIRECTOR-UUID

generate_deployment_manifest INFRASTRUCTURE MANIFEST-STUB > cf-deployment.yml

# ./generate_deployment_manifest warden cf-stub.yml > cf-deployment.yml

cf-deployment.yml 생성

 

generate_deployment_manifest : script template directory yml 파일 spiff

 

# bosh target : bosh target 서버 재확인

 

Use bosh deployment MANIFEST-NAME to set your deployment to the generated manifest. Replace MANIFEST-NAME with the name of your deployment manifest

# bosh deployment cf-deployment.yml

 

Run bosh create release to create a Cloud Foundry release. This command prompts you for a development release name.

# bosh create release

 

Run bosh create release to create a Cloud Foundry release.

# bosh upload release

 

uploaded Cloud Foundry release.

# bosh deploy

 

 

Deploy 완료 이후 테스트

# If not using AWS, but behind a proxy, make sure to run 'export no_proxy=192.168.50.4,xip.io'

$ cf api --skip-ssl-validation https://api.10.244.0.34.xip.io

$ cf auth admin admin

$ cf create-org test-org

$ cf target -o test-org

$ cf create-space test-space

$ cf target -s test-space

 

Go language 설치

# bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)

# gvm version

# gvm listall

# gvm install go1.4

'CloudFoundry' 카테고리의 다른 글

[bosh] job lifecycle  (0) 2016.06.02
[bosh] release, job  (0) 2016.06.02
[CloudFoundry] cf push process(application 배포)  (0) 2016.04.20
CloudFoundry user-provide-service setting  (0) 2016.04.20
CPI(Cloud Provider Interface) / bosh  (0) 2016.04.08
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 뭉탁거림
,

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




Posted by 뭉탁거림
,


BOSH Security: User Roles and the UAA identity management service

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


    Cloud 인프라 상에 대규모 서비스를 배포/관리하는 오픈 소스
    서비스에 필요한 VM을 deploy하고 software provisioning 중앙관리 도구
    Bosh 자체도 Cloud에 배포되어야 하는 서비스
    CloudFoundry 뿐만 아니라 추가 소프트웨어(hadoop, rabbitmq ~) 배포/관리
    Bosh-lite / Micro-bosh / Full-bosh

    Multiple IaaS 지원
    CPI(Cloud Provider interface) : Bosh를 통해 IaaS 인프라의 API를 호출 할 수 IaaS의 추상화 인터페이스
    AWS, OpenStack, vSphere, vCloud, etc
    Additional IaaS 인프라를 사용하기 위해선 Custom CPI 필요


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

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


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 뭉탁거림
,