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

Nise-BOSHでCloudFoundryを1VMに構築
2014/04/26 NECソフト大塚元央

© NEC Corporation 2013
▌ 導入
 自己紹介
 モチベーション
 Cloud Foundry 構成
▌ 1VM Cloud Foundry の構築
 流れ
 Nise-BOSH のインストール
 Cloud Foundry のリリース作成
 Cloud Foundry のインストール
目次
目次

大塚元央 (Yuanying)
▌ 所属: NECソフト ITシステム事業部
▌ Twitter: @yuanying
▌ 趣味
 トライアスロン
▌ 古い昔の趣味
 Mac
• iExtractMP3
 Ruby
• ConnectImporter (http://labs.3machinae.com/garmin2runkeeper)
Page 3 © NEC Corporation 2010
導入
自己紹介

もっと気軽に Cloud Foundry の最新版を試したい
▌ BOSH
 IaaS統合は良いんだけど、ローカルで環境作るのどうするの？
 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
導入
モチベーション

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

Cloud Foundry を構成する最低インタフェース
導入
じゃあこれらをcf-release の Job Template で実装すると？

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

導入
最新コンポーネントを試そうと思う
と、
こうなる。

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 –bmulti-monitrc-spike origin/multi-monitrc-spike
$ bundle install
$ ./bin/init
$ apt-get install debootstraprunit

Cloud Foundry のリリース作成
$ git clone https://github.com/cloudfoundry/cf-release.git
$ cd ./cf-release
$ git remote add yuanyinghttps://github.com/yuanying/cf-release.git
$ git pull yuanying master
From https://github.com/yuanying/cf-release
* branch master -> FETCH_HEAD
Updating 4fd9c30..c9d596a
Fast-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 を
修正。

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
chownvcap: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-rdocbosh_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

▌ properties.microを true に
▌ ドメインにxip.ioを指定。
 IP アドレスベースのワイルドカードDNS。便利。
---
deployment: micro
properties:
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:
- micro@vcap.me|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
$ chownvcap: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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Último

Último (9)

Destaque

Destaque (20)

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