【この記事は， Cloud Foundry 情報発信強化週間 の記事の一つです】
この記事は， https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/All-CF-Releases (※0) に基づいて，ここ1年くらいに Cloud Foundry (以下"CF") のソースコードに入った更新を簡単にまとめるものです。
この中編では，2014年9月2日の v182 から，2014年12月29日の v195 までについて記します。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v182
Feature Flags 機能が導入されました。
- http://docs.cloudfoundry.org/adminguide/listing-feature-flags.html
- http://apidocs.cloudfoundry.org/207/feature_flags/set_a_feature_flag.html
- http://apidocs.cloudfoundry.org/207/feature_flags/get_all_feature_flags.html
この機能は，CF 管理者が，以下の6つの機能の on / off の切り替えを行うことを可能にします(カッコ内はデフォルト値)。
- user_org_creation (false): true の場合，API 経由で一般ユーザーが organization を作ることが可能
- private_domain_creation (true): true の場合，OrgManager は自分の管理する org に対して private domain を作ることが可能
- app_bits_upload (true): true の場合，SpaceDeveloper はアプリをアップロード可能
- app_scaling (true): true の場合，SpaceDeveloper はアプリの scale (メモリー割り当てやインスタンス数の変更)が可能
- route_creation (true): true の場合，SpaceDeveloper は space 内に route を作ることが可能
- service_instance_creation (true): true の場合，SpaceDeveloper は space 内に service を作ることが可能
環境変数グループ機能が導入されました。
この機能は，CF 管理者が，ステージング時/アプリ実行時の環境に独自に環境変数を設定することを可能にします。
以下，v207 環境で試した例です。
管理者としてログインし，staging-environment-variable-group / running-environment-variable-group を設定します。
$ cf login admin
..
API endpoint: https://api.10.244.0.34.xip.io (API version: 2.25.0)
User: admin
Org: demo
Space: demo
$ cf set-staging-environment-variable-group '{"name1":"value","name2":"value"}'
Setting the contents of the staging environment variable group as admin...
OK
$ cf set-running-environment-variable-group '{"name3":"value","name4":"value"}'
Setting the contents of the running environment variable group as admin...
OK
設定値を確認します。
$ cf staging-environment-variable-group
Retrieving the contents of the staging environment variable group as admin...
OK
Variable Name Assigned Value
name1 value
name2 value
$ cf running-environment-variable-group
Retrieving the contents of the running environment variable group as admin...
OK
Variable Name Assigned Value
name3 value
name4 value
一般ユーザーでも，設定値を確認することはできます。
nota@NotaBookPro:~/repos/My/cf-example-ruby-ver[2015-05-06T00:05:51]!2051$ cf login -u demo
..
API endpoint: https://api.10.244.0.34.xip.io (API version: 2.25.0)
User: demo
Org: demo
Space: demo
$ cf sevg
Retrieving the contents of the staging environment variable group as demo...
OK
Variable Name Assigned Value
name1 value
name2 value
$ cf revg
Retrieving the contents of the running environment variable group as demo...
OK
Variable Name Assigned Value
name3 value
name4 value
nota@NotaBookPro:~/repos/My/cf-example-ruby-ver[2015-05-06T00:07:00]!2054$
アプリごとの環境変数設定を見る env コマンドでも確認できます。
$ cf env rv
Getting env variables for app rv in org demo / space demo as demo...
OK
System-Provided:
{
"VCAP_APPLICATION": {
"application_name": "rv",
"application_uris": [
"rv.10.244.0.34.xip.io"
],
"application_version": "39dd88ea-cb81-4d7e-b617-304404b350ff",
"limits": {
"disk": 1024,
"fds": 16384,
"mem": 256
},
"name": "rv",
"space_id": "3251672c-c8b6-4070-9254-b421a2ad2694",
"space_name": "demo",
"uris": [
"rv.10.244.0.34.xip.io"
],
"users": null,
"version": "39dd88ea-cb81-4d7e-b617-304404b350ff"
}
}
No user-defined env variables have been set
Running Environment Variable Groups:
name3: value
name4: value
Staging Environment Variable Groups:
name1: value
name2: value
一般ユーザーでは，値を設定することはできません。
$ cf ssevg '{"name1":"value","name2":"value"}'
Setting the contents of the staging environment variable group as demo...
FAILED
Server error, status code: 403, error code: 10003, message: You are not authorized to perform the requested action
アプリの実行環境で使用される環境変数が出力されるファイル env.log が廃止されました。廃止はセキュリティ上の理由によるものです。当初はアプリごとに選択可能にするという pull request だったようですが，残す理由がなさそうということで廃止になりました。
Gorouter でのプロキシー方法が多少変わりました。従来は，受け取った URL のパス部分をデコードし，upstream にアクセスするときに再度エンコードしていたのですが，一部の文字コードの変換に問題があったため，URLをデコード/エンコードせず，そのまま渡すようになりました。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v183
アプリの実行環境である Warden コンテナー内で，FUSE を使ってファイルシステムのマウントができるようになりました。これを使ったファイルシステムの例としては， sshfs を使った stackato-service-filesystem があるようです。
大きな更新はないようでした。詳細は こちら で。
問題があると判断され，タグが削除されました。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v186
Buildpack の DEA へのダウンロードが，最初のアプリのデプロイ時から，DEA の起動時に変更されました。これは最初のアプリのステージング／実行に時間がかかりすぎてタイムアウトしてしまう現象を回避するための修正です。
以下の buildpack が更新されました。目立った変更はないようだったので，詳細はそれぞれ以下で。
Login Server 1.8.5 で，複数 SAML IDP がサポートされるようになりました。
これまでユーザーのデフォルト・スコープは固定だったのですが，UAA 1.8.3 で，uaa.yml ファイルから設定可能になりました。
これまで login クライアントの redirect 時のプロトコルは HTTPS 固定だったのですが，証明書を使用しないでデプロイしてログインできないというトラブルが多かったため， login.protocol というプロパティで指定可能になりました。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v187
このリリースは "Shellshock" 脆弱性の対応が主で，機能更新らしいものはあまりありませんでした。
詳細は こちら で。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v188
このリリースも "Shellshock" 脆弱性の対応が主だったようです。
詳細は こちら で。
重要な更新としては，Java 8 / Tomcat 8 がデフォルトになったことです。この時点ではまだ本家の Java Buildpack で Java や Tomcat のバージョンを簡単に変更できなかった(変更するには fork してデフォルトを書き換える必要があった)ので，この更新は大きな影響がありました。
詳細は こちら から。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v189
それぞれにそれほど大きな更新は入っていませんでした。
- go buildpack v1.0.4
- python buildpack v1.0.5
- php buildpack v1.0.2
- nodejs buildpack v1.0.4
従来，アプリのインスタンスが1つもない DEA は router.register を送らなかったのですが，常に送るようになりました。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v19
あまり大きな更新はなかったようです。詳細は こちら 。
この時期の CF では，logging と metrics を新しく metron / dropsonde / NOAA ベースのものに移行する取り組みが続いていました。この変更もその一環です。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v19
このリリースは POODLE 脆弱性対応も大きなウェイトを占めていました。
v207環境で試した結果はこんな感じです。
$ cf curl /v2/apps/7d03e5a8-c1b7-4012-9193-2400db8b262b/env
{
"staging_env_json": {
"name1": "value",
"name2": "value"
},
"running_env_json": {
"name3": "value",
"name4": "value"
},
"environment_json": {},
"system_env_json": {
"VCAP_SERVICES": {}
},
"application_env_json": {
"VCAP_APPLICATION": {
"limits": {
"mem": 256,
"disk": 1024,
"fds": 16384
},
"application_version": "39dd88ea-cb81-4d7e-b617-304404b350ff",
"application_name": "rv",
"application_uris": [
"rv.10.244.0.34.xip.io"
],
"version": "39dd88ea-cb81-4d7e-b617-304404b350ff",
"name": "rv",
"space_name": "demo",
"space_id": "3251672c-c8b6-4070-9254-b421a2ad2694",
"uris": [
"rv.10.244.0.34.xip.io"
],
"users": null
}
}
}
あるアプリのソースコードを別のアプリにコピーすることができる API が追加されました。
v207 環境で試した例は以下の通りです。
空の Gemfile だけのアプリを CF にデプロイします。起動はしないよう --no-start を付けています。
$ ll
total 0
drwxr-----+ 3 nota staff 102 5 6 14:43 ./
drwxr-----+ 21 nota staff 714 5 6 14:42 ../
-rw-r-----+ 1 nota staff 0 5 6 14:43 Gemfile
$ cf push rv2 --no-start
Creating app rv2 in org demo / space demo as demo...
OK
Creating route rv2.10.244.0.34.xip.io...
OK
Binding rv2.10.244.0.34.xip.io to rv2...
OK
Uploading rv2...
Uploading app files from: /Users/nota/work/dummy
Uploading 128, 1 files
Done uploading
OK
copy_bits API を使ってアプリのコピーを行います。デフォルトではコピー先のアプリは自動再起動されます。
$ CF_TRACE=true cf copy-source rv rv2
VERSION:
6.11.2-2a26d55
(..略..)
REQUEST: [2015-05-06T14:44:52+09:00]
POST /v2/apps/08849d0a-537f-41ea-9f4c-cd8545b4746c/copy_bits?async=true HTTP/1.1
Host: api.10.244.0.34.xip.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.11.2-2a26d55 / darwin
{"source_app_guid":"7d03e5a8-c1b7-4012-9193-2400db8b262b"}
RESPONSE: [2015-05-06T14:44:52+09:00]
HTTP/1.1 201 Created
Content-Length: 270
Content-Type: application/json;charset=utf-8
Date: Wed, 06 May 2015 05:44:52 GMT
Server: nginx
X-Cf-Requestid: 24312889-264a-4f4f-54fb-2dd0071ca689
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 6c0a5de6-ba05-48c8-5f67-cc6da2138885::85553e10-5398-41cb-b7e8-7b83e1d45398
{
"metadata": {
"guid": "1e365ff3-18cf-4d16-979e-107726d642b0",
"created_at": "2015-05-06T05:44:52Z",
"url": "/v2/jobs/1e365ff3-18cf-4d16-979e-107726d642b0"
},
"entity": {
"guid": "1e365ff3-18cf-4d16-979e-107726d642b0",
"status": "queued"
}
}
(..略..)
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: rv2.10.244.0.34.xip.io
package uploaded: Wed May 6 05:44:56 UTC 2015
stack: cflinuxfs2
state since cpu memory disk details
#0 running 2015-05-06 02:45:20 PM 0.0% 43.4M of 256M 0 of 1G
OK
コピー元だけでなく，コピー先のアプリもあらかじめ存在している必要があるので，使い方としては，新バージョンのアプリを別名で起動しておいて，それを旧バージョンのアプリにコピーするなどが考えられると思います。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v19
このリリースからリリース情報の構造がシステマティックになり，情報量も増えました。主な更新は以下の通りです。
HM9000 が Cloud Countroller と通信する方法が，NATS から HTTP に変更されました。これは HM9000 の API が無応答状態になってしまうのを解決するための修正です。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/80850336
Cloud Controller の AppEvent API は意味のある情報を持たなくなって久しかったので，deprecated になりました。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/77626184
login server を spiff template から無効にすることが可能になりました。これにより login server を使わず UAA のみを使うデプロイが簡単になりました。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/81069846
大きな更新はありませんでした。詳細は こちら 。
Procfile で Web 以外の Process Type をサポートするための開発が始まりました。Process Type については(ここで紹介することは難しいので)詳細は CF の design document や Heroku のこのページ をご覧ください。なお現時点 (v207) ではまだ正式リリースされていません。
Service Broker API に「プラン変更」が追加されました。Broker が対応していれば，ユーザーは作成済みの service instance のプランを変更することができるようになります。なお，これは API 仕様の更新であり，実際のコードの更新はこの後のリリースで入ります。
cf. http://docs.cloudfoundry.org/services/api.html#updating_service_instance
CF のコンポーネントや CF 上のアプリの log / metrics を取り出す(統一的な) streaming API "firehose" がリリースされました。これも大きな変更で，ここで紹介することは困難なので，詳細については こちら や こちら などをご覧ください。
Loggregator streaming endpoint で cookie を使って oauth token が取得できるようになりました。
比較的大きな幾つかの修正が Login Server 1.9.0 で入りました。
- Email アドレス変更が可能に ただし UAA 内部のユーザーのみで，LDAP / SAML 等の外部ユーザーは対象外です
- Notifications Server との統合 CF の Notifications Server と統合され，ユーザーへのメイル通知を Notifications Server を使って送れるようになりました
- Spring Security OAuth が 1.0.5 から 2.0.3 に
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v19
このリリースは NFS のマウントに問題があるため，複数 CC 間のデータ共有に NFS を使っている環境では使えません。なおこの問題は次のリリース (v193) で修正されました。
CC の API (参照系) には，inline-relations-depth というパラメーターがあり，深さを指定することでモデルをまたいで再帰的に情報を取得することが可能になっています。その処理の性能を改善するために，以下の三つのパラメーターが追加されました。
orphan-relationsこれを指定すると，リレーションがネストではなくルートに埋め込む形で返されます
パースが楽になるのがメリットだと思われますexclude-relations指定されたの名前のリレーションを除外します
,区切りで複数指定することも可能ですinclude-relations指定された名前のリレーションのみを取得します
,区切りで複数指定することも可能です
cf. https://www.pivotaltracker.com/story/show/79917792
Org 全体でどれだけのメモリを消費しているかを取得する API endpoint /v2/organizations/:guid/memory_usage が追加されました。
v207 環境で試した結果は以下の通りです。
$ cf org demo --guid
69d95c47-2e8c-42af-ac1d-7d99154eaa8d
$ cf curl /v2/organizations/69d95c47-2e8c-42af-ac1d-7d99154eaa8d/memory_usage
{
"memory_usage_in_mb": 512
}
cf. https://www.pivotaltracker.com/story/show/81065364
Gorouter に router.register を行う際，expire 期間を指定することが可能になりました。NATS プロトコルの話なので，ユーザーではなく運用者機能ですが，service broker を NATS を使って冗長化/並列化する際には有用であると思われます(実際にそもそもの動機も MySQL service broker の負荷分散でした)。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/81878766
request_timeout_in_seconds のデフォルト値が300秒(5分)から900秒(15分)に変更されました。理由はわかりません。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/80931258
staging の状態が PENDING になっているパッケージが定期的に整理されて FAILED にされることになりました。期間の指定は cc.pending_packages.expiration_in_seconds で行うことが可能で，デフォルト値は1200秒(20分)です。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/80259334
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v19
CC の bin/console が gem 関連の問題で正常に動作しなかったのが修正されました。bin/console は，CC を pry のコンソール・モードで起動するもので，デバッグの時などに有用なツールです。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/81126332
大きな更新はありませんでした。詳細は こちら 。
CC が HM9000 にアクセスする際のユーザーのデフォルト値として，CC のテンプレートで使われているのと同じ internal_user が設定されました。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/82901242
Notification Service のデフォルト・スコープが，将来含め全ての admin ユーザーに適用されるようになりました。
cf. https://www.pivotaltracker.com/n/projects/1107230/stories/80596206
Gorouter の GOMAXPROCS のデフォルト値が，固定値の 8 から runtime.NumCPU() を使うように変更されました。
以前 Gorouter の性能評価をした ことがあって，性能的に割と残念だったのですが，その原因の一つにこの GOMAXPROCS が (8 に固定されていることが) あるかもしれないと考えていました。どこかで時間があったらもう一度性能評価をしたいと考えています。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/82480664
UAA と Login Server が共に 1.9.1 になりました。大きな変更はなかったようです。
URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v19
このリリースはかなり大型で，調査が大変でした。
以下の buildpack が更新されました。マイナー・バージョンが変わった Java と Ruby 以外は，大きな変更はありませんでした。
- Java Buildpack v2.6
ハイライトは以下の通り
OutOfMemoryを Loggregator に出力するようになった- カスタム CA certificate のサポート 等
- nodejs buildpack v1.1.1
- go buildpack v1.1.1
- python buildpack v1.1.1
- ruby buildpack v1.2.0
- 新たな offline 依存パッケージ管理手法の導入 (NodeJS Buildpack と同等に) なお， こういう design document が提案されているので，将来的に buildpack の依存パッケージ管理は統一的に扱えるようになる可能性があります
- 新たな runtime 拡張パッケージコンパイル管理手法の導入 (NodeJS Buildpack と同等に)
Warden コンテナーの rlimit_core を設定可能にすることで，設定に基づいて core ファイルが出力できるようになりました。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/83102260
UAA / Login Server に IP アドレスに基づくアクセス制御機能が追加されました。
cf. https://github.com/cloudfoundry/cf-release/pull/547/files
Collector のログレベルが設定可能になりました。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/83468558
ネットワークが非常に遅い環境などでもアプリのデプロイが行えるよう，CCの request_timeout_in_seconds を 0 にすると「タイムアウトなし」にできるようになりました。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/84079612
DEA が，デプロイされるアプリが必要とするリソースを過剰に見積もってしまう問題が修正されました。これは，リソースのチェック前に，これからデプロイされるアプリがレジストリーに登録されてしまっていたことによるものです。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/81721664
以下のようなルールに基づき，より柔軟にドメイン名を生成することが可能になりました。
- 共有ドメインのサブドメインをプライベート/共有ドメインとして生成できる
- プライベート/共有ドメインの親ドメインを共有ドメインとして生成できる
- 同じOrg内であれば，プライベート・ドメインのプライベートなサブ/親ドメインを生成できる
- ドメインが生成される時は，適合するルートのチェックが行われる
- ルートが生成される時は，適合するドメインのチェックが行われる
- 親のプライベート・ドメインに対して，共有ドメインを生成することはできない
cf. https://www.pivotaltracker.com/n/projects/966314/stories/83505974
cf app などで取得される HM9000 のインスタンス情報が正しく表示されるよう，アプリのインスタンスの有無にかかわらず DEA から HM9000 にハートビートが送られるようになりました。これにより，全てのインスタンスが正常であるにもかかわらず，インスタンス数が ?/2 のように表示されるのを避けることができるようになります。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/84509968
Droplet のアップロード後にポーリングを行った際，エラーが HTTP timeout であればポーリングを再試行するようになりました。これにより，droplet のアップロードが成功しているにもかかわらず staging が FAILED と判断されてしまうのを防ぐことができるようになります。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/81065428
Delayed job 用の gem を変更することにより，delayed job worker が deadlock してしまう問題が修正されました。
cf. https://www.pivotaltracker.com/n/projects/966314/stories/84346198
Service のプラン更新機能の実装が完了，したようなのですが，下記の URL を見ても何も情報がないので，詳細は不明です。
cf. https://www.pivotaltracker.com/n/projects/1211680/epics/1533368
Service の操作監視イベントを記録する "Service Audit Events" 機能の実装が行われています。この機能は v196 で実装が完了したようです。
UAA と Login Server のバージョンが 1.11 になりました。大きな更新はないようでした。
大きめの feature の追加としては，
- Feature Flags
- Environment Variable Groups
- Service のプラン更新
- Loggregator firehose
などでしょうか。
そのほか，
- FUSE を使ったファイルシステム・サービスの実現
- copy_bits API の追加
- CC の inlined relations 関連処理の高速化
- Org のメモリ消費量の取得
- 柔軟なドメイン生成ルール
などが便利そうです。
全般的な印象としては，
- Logging / metrics
- Buildpack
等への注力が大きく，本体の更新はバグ修正が中心になっていると感じました。
Diego (CF v3) という大きなアーキテクチャの更改を前に，そちらにリソースが振り分けられていること，及び Diego のリリースに伴って旧版となる DEA / HM9000 等はメインテナンス・モードに入っているのかもしれません。