Nise-BOSH で Cloud Foundry を 1VM に構築

Nise-BOSH で CloudFoundry を 1VM に構築

2014/04/26 NEC ソフト大塚元央

Page 2 © NEC Corporation 2013

▌ 導入自己紹介モチベーションCloud Foundry 構成

▌ 1VM Cloud Foundry の構築流れNise-BOSH のインストールCloud Foundry のリリース作成Cloud Foundry のインストール

目次

目次

大塚元央 (Yuanying)

▌ 所属 : NEC ソフト IT システム事業部▌ Twitter: @yuanying

▌ 趣味トライアスロン

▌ 古い昔の趣味Mac

• iExtractMP3Ruby

• ConnectImporter (http://labs.3machinae.com/garmin2runkeeper)


導入

自己紹介

もっと気軽に Cloud Foundry の最新版を試したい▌ BOSHIaaS 統合は良いんだけど、ローカルで環境作るのどうするの？BOSH 自体で 1VM+ も使いたくない。

▌ Nise-BOSHこれがあれば Vagrant で試せる！複数ジョブテンプレートを一度にインストールすれば 1VM で Cloud

Foundry が動くんじゃ？• https://github.com/yuanying/nise_bosh#multi-monitrc-spike• https://github.com/yuanying/cf-release– cf-release もちょっと修正する必要があった。

参考• https://github.com/cloudfoundry/micro


導入

モチベーション

https://github.com/yuanying/nise_bosh%23multi-monitrc-spike

https://github.com/yuanying/cf-release

https://github.com/cloudfoundry/micro

Cloud Foundry の最低構成は？▌ cf-release/jobsたくさんあるけど全部使ったりしないよね？とりあえず service なんて無くて良い、動けば。最新のコンポーネントを使いたい。

• router より gorouter• cloud_controller_ng


導入

Cloud Foundry 構成

Cloud Foundry を構成する最低インタフェース


導入


じゃあこれらを cf-release の Job Template で実装すると？


導入


依存関係を調査してみた。( 実行時には上にあるコンポーネント

から )

© NEC Corporation 2013Page 8

導入


最新コンポーネントを試そうと思うと、

こうなる。


1. Nise-BOSH のインストール2. Cloud Foundry のリリース作成3. Cloud Foundry のインストール

1VM Cloud Foundry の構築

流れ


▌ 本家でなく、複数ジョブテンプレートインストールに対応したブランチを利用する。

後々もっと奇麗な形で複数ジョブテンプレートのインストールに対応するので、この手順は多分非推奨…。

dea_next 用に gen-stemcell する必要があるかと思いきや、、最新版の dea_next だと rootfs 用のパッケージが cf-release に用意してあるため必要ない模様。


Nise-BOSH のインストール

$ git clone https://github.com/yuanying/nise_bosh.git$ git checkout –b multi-monitrc-spike origin/multi-monitrc-spike$ bundle install$ ./bin/init$ apt-get install debootstrap runit

https://github.com/yuanying/nise_bosh.git



Cloud Foundry のリリース作成

$ git clone https://github.com/cloudfoundry/cf-release.git$ cd ./cf-release$ git remote add yuanying https://github.com/yuanying/cf-release.git$ git pull yuanying masterFrom https://github.com/yuanying/cf-release * branch master -> FETCH_HEADUpdating 4fd9c30..c9d596aFast-forward jobs/cloud_controller_ng/monit | 2 ++ jobs/dea_next/templates/dea.yml.erb | 12 ++++++++++++ jobs/dea_next/templates/warden_ctl | 18 ------------------ jobs/hbase_master/templates/+--hbase_zookeeper_ctl | 4 + packages/nginx/packaging | 1 + packages/nginx_next/packaging | 1 + packages/ruby/packaging | 1 + packages/ruby_next/packaging | 1 + 8 files changed, 20 insertions(+), 20 deletions(-)

1VM で動くように、いくつか cf-release を修正。

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

https://github.com/yuanying/cf-release.git

cloud_controller での nginx の無効化

▌ 何故か nginx が 1VM で CF 構築時に、 staging の邪魔をしていたのでよくわからないけど使うのを止めた。




--- a/jobs/cloud_controller_ng/monit+++ b/jobs/cloud_controller_ng/monit@@ -4,10 +4,8 @@ check process cloud_controller_ng stop program "/var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl stop" group vcap +<% if p("ccng.use_nginx", true) %> check process nginx_ccng with pidfile /var/vcap/sys/run/nginx_ccng/nginx.pid start program "/var/vcap/jobs/cloud_controller_ng/bin/nginx_ctl start" stop program "/var/vcap/jobs/cloud_controller_ng/bin/nginx_ctl stop" group vcap+<% end %>

warden_ctr から stemcell.tar.gz 関連を削除




--- a/jobs/dea_next/templates/warden_ctl+++ b/jobs/dea_next/templates/warden_ctl@@ -24,24 +24,6 @@ case $1 in ulimit -c unlimited - rootfs_path=$DATA_DIR/rootfs- rootfs_tgz=/var/vcap/stemcell_base.tar.gz-- # Extract rootfs if needed- if [ ! -d $rootfs_path ]- then- # Make sure its parent directory exists- mkdir -p $(dirname $rootfs_path)-- # Extract to temporary path, then rename to target path.- # This makes sure that it is not possible that we end up with directory- # that contains a partially extracted archive.- tmp_path=$(mktemp --tmpdir=$(dirname $rootfs_path) -d)- chmod 755 $tmp_path- tar -C $tmp_path -zxf $rootfs_tgz- mv $tmp_path $rootfs_path- fi

これはたぶん、本家の消し忘れ。

1VM なので nfs の利用を削除




--- a/jobs/serialization_data_server/templates/serialization_data_server_ctl+++ b/jobs/serialization_data_server/templates/serialization_data_server_ctl@@ -36,7 +36,9 @@ case $1 in <% end %> mkdir -p $SNAPSHOT_DIR+ <% unless properties.micro %> check_mount "$MT_OPTS" "$MT_EXPORT" "$SNAPSHOT_DIR"+ <% end %> mkdir -p $SDS_TMP_UPLOAD_DIR chown vcap:vcap $SDS_TMP_UPLOAD_DIR


▌ ここで Nise-BOSH にリクエスト最新のリリースを試したいだけな場合にわざわざ bosh create release

したくない！• bosh sync blobs だけで大丈夫なんじゃ？

Job Template と Package の取得方法がちょっとごっちゃになってる。• Job Template はリリースレポジトリのソース (jobs ディレクトリ ) そのまま

使うのに、• Package はなんで .dev_builds / .final_builds を使うのか？

リリースファイルを指定したら .dev_builds / .final_builds の jobs と package を使う、

リリースレポジトリを指定したら、レポジトリ下のソースを利用するようにして欲しい ( したい ) 。



$ ./update$ gem install –no-ri –no-rdoc bosh_cli$ bosh create release --force


▌ 最低構成の Job Template をインストール。問題は、 deployment manifest (micro_ng.yml) の内容…。cloudfoundry/micro を参考に

• https://github.com/cloudfoundry/micro/blob/master/deploy/manifest-ng.yml

実際に使った deployment manifest• https://gist.github.com/yuanying/2b41f8bd3819de0bd520


Cloud Foundry のインストール

$ bundle exec ./bin/nise-bosh ../cf-release ../micro_ng.yml -n 127.0.0.1 postgres$ bundle exec ./bin/nise-bosh ../cf-release ../micro_ng.yml -n 127.0.0.1 nats$ bundle exec ./bin/nise-bosh ../cf-release ../micro_ng.yml -n 127.0.0.1 gorouter$ bundle exec ./bin/nise-bosh ../cf-release ../micro_ng.yml -n 127.0.0.1 dea_next$ bundle exec ./bin/nise-bosh ../cf-release ../micro_ng.yml -n 127.0.0.1 health_manager_next$ bundle exec ./bin/nise-bosh ../cf-release ../micro_ng.yml -n 127.0.0.1 cloud_controller_ng$ bundle exec ./bin/nise-bosh ../cf-release ../micro_ng.yml -n 127.0.0.1 serialization_data_server$ bundle exec ./bin/nise-bosh ../cf-release ../micro_ng.yml -n 127.0.0.1 uaa$ bundle exec ./bin/nise-bosh ../cf-release ../micro_ng.yml -n 127.0.0.1 vcap_redis

https://github.com/cloudfoundry/micro/blob/master/deploy/manifest-ng.yml

https://gist.github.com/yuanying/2b41f8bd3819de0bd520


▌ properties.micro を true に▌ ドメインに xip.io を指定。IP アドレスベースのワイルドカード DNS 。便利。



---deployment: microproperties: micro: true domain: 192.168.33.10.xip.io cc_props: ccng hm_props: health_manager_ccng


▌ ｃｃｎｇ .use_nginx を false に▌ ccng のプロパティはデフォルト値が spec で決まっているものが

多いが、 Nise-BOSH がプロパティのデフォルト値に対応していないため、すべて指定する必要があり大変。。



ccng: &ccng use_nginx: false default_quota_definition: free srv_api_uri: http://api.192.168.33.10.xip.io logging_level: debug bulk_api_password: bulk_api_password staging_upload_user: staging staging_upload_password: staging external_host: api uaa_resource_id: cloud_controller quota_definitions: free: total_services: 10 memory_limit: 1024 non_basic_services_allowed: false … ( 以下略 )


▌ uaa.no_ssl を true に▌ cf クライアントを追加 (vmc の代わり )autoapprove に登録しないとブラウザベースの認証しないと使えない。cloud_controller.admin scope の追加。



uaa: spring_profiles: postgresql no_ssl: true autoapprove: - cf scim: users: - [email protected]|micro|scim.write,scim.read,openid clients: cf: override: true authorized-grant-types: implicit authorities: uaa.none scope: cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write

起動！




$ mkdir -p /var/vcap/shared$ chown vcap:vcap /var/vcap/shared$ mkdir -p /var/vcap/store

$ ./bin/run-job start postgres$ ./bin/run-job start nats$ ./bin/run-job start gorouter$ ./bin/run-job start dea_next$ ./bin/run-job start health_manager_next$ ./bin/run-job start cloud_controller_ng$ ./bin/run-job start serialization_data_server$ ./bin/run-job start uaa$ ./bin/run-job start vcap_redis


Technology

Nise-BOSH で Cloud Foundry を 1VM に構築