Skip to content

Instantly share code, notes, and snippets.

@nota-ja
Last active August 29, 2015 14:20
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nota-ja/67b392a11a91b9a9b4b3 to your computer and use it in GitHub Desktop.
Save nota-ja/67b392a11a91b9a9b4b3 to your computer and use it in GitHub Desktop.
Major Updates of Cloud Foundry in the Last (approx.) One Year (3/3)

ここ1年ほどの Cloud Foundry の更新 後編

【この記事は, Cloud Foundry 情報発信強化週間 の記事の一つです】

 この記事は, https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/All-CF-Releases (※0) に基づいて,ここ1年くらいに Cloud Foundry (以下"CF") のソースコードに入った更新を簡単にまとめるものです。

 この中編では,2015年1月22日の v196 から,2015年4月16日の v207 (2015年5月9日時点での最新リリース) までについて記します。

◆ v196 (2015/01/22)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v196

▷ Service Audit Events 機能

 Service Audit Events 機能の実装が終わりました。

 ここ に情報が全くないので確信はないのですが,API エンドポイントとしては, このページ の "Events" の項の List Service Binding Create EventsList Service Plan Visibility Update Events が相当するものと思われます。

__VCAP_ID__ クッキーの暗号化

 Gorouter の生成する __VCAP_ID__ クッキーの暗号化に対応し,その有無を manifest から設定できるようになりました。デフォルトは互換性を考慮して false (暗号化しない) になっています。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85088076

▷ ユーザーのリストを返す API エンドポイントの仕様変更

 従来,ユーザーのリストを返す API エンドポイント (/v2/organizations/:guid/managers, /v2/spaces/:guid/developers 等) ではユーザーの guid のみを返していたが,その中にユーザー名も含めるようになりました。

 v207 環境で試した結果は以下の通りです。

$ cf curl /v2/spaces/`cf space demo --guid`/developers
{
   "total_results": 1,
   "total_pages": 1,
   "prev_url": null,
   "next_url": null,
   "resources": [
      {
         "metadata": {
            "guid": "c35a6ef6-fd30-443d-9c3f-6d96945d8863",
            "url": "/v2/users/c35a6ef6-fd30-443d-9c3f-6d96945d8863",
            "created_at": "2015-05-03T19:15:09Z",
            "updated_at": null
         },
         "entity": {
            "admin": false,
            "active": false,
            "default_space_guid": null,
            "username": "demo",
            "spaces_url": "/v2/users/c35a6ef6-fd30-443d-9c3f-6d96945d8863/spaces",
            "organizations_url": "/v2/users/c35a6ef6-fd30-443d-9c3f-6d96945d8863/organizations",
            "managed_organizations_url": "/v2/users/c35a6ef6-fd30-443d-9c3f-6d96945d8863/managed_organizations",
            "billing_managed_organizations_url": "/v2/users/c35a6ef6-fd30-443d-9c3f-6d96945d8863/billing_managed_organizations",
            "audited_organizations_url": "/v2/users/c35a6ef6-fd30-443d-9c3f-6d96945d8863/audited_organizations",
            "managed_spaces_url": "/v2/users/c35a6ef6-fd30-443d-9c3f-6d96945d8863/managed_spaces",
            "audited_spaces_url": "/v2/users/c35a6ef6-fd30-443d-9c3f-6d96945d8863/audited_spaces"
         }
      }
   ]
}

 真ん中より少し下に "username": "demo" が入っているのがわかります。

 これは一見大した変更ではないのですが,これまで CF CLI の cf org-userscf space-users というコマンドでは,ユーザーの guid を取得した後,名前を取るためだけにもう一度 CC にアクセスしていたので,無駄な手間を省くという点では意義のある変更だったと思います。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/63345104

▷ HAProxy 1.5.10

 CF で使用している HAProxy のバージョンが 1.5.10 に上がりました。

 これはもともと CF user のメイリングリストの この記事 が発端で,古い HAProxy では TUN (トンネル)モードでは毎回 X-Forwarded-For を送らない仕様になっていたことが問題でした。そこで,HAProxy がその時点でほぼ最新(1.5.10)のものにアップグレードされました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/82271326

▷ Warden 内での SIGCHLD の(再)有効化

 CF でアプリが実行される環境である Warden の内部で,シグナル SIGCHLD が(再)有効化されました。

 これはなかなか興味深い話で,もともとは一部の NodeJS アプリで子プロセスを呼び出すような処理が正常に動作しないという問題が発端でした。メイリングリストの この記事 に詳細が記されているのですが,CF のユーザーによる解析の結果,Warden コンテナー内で SIGCHLD がブロックされていたために問題が起きていたことがわかりました。

 最終的には SIGCHLD をブロックしないようにする修正が行われて解決したのですが,もともとなぜ SIGCHLD がブロックされていたかがわからないので,モヤモヤしたものは少し残りました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/83352380

▷ CC API の q パラメーターにおける bool 値の扱いの変更

 CC API の q パラメーターにおいて,bool 値に対する問い合わせ時に文字列 true, t, false, f も bool 値として扱われるようになりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/84942534

▷ HM9000 のログをファイルに出力

 HM9000 のログが STDOUT ではなくファイルに出力されるようになりました。

 これは,HM9000 のを起動するプロセスが死んでしまった時,起動された HM9000 が STDOUT を掴んだままzombieプロセス化してしまうのを防ぐためです。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/83879376

▷ Login Server で死活監視に /healthz を使う & UAA で stop ではなく restart スクリプトを使う

 Login Server の死活監視に /healthz が使われるようになりました。また UAA で stop ではなく restart スクリプトが使われるようになりました。理由はわかりません。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85561244

▷ Login Server の設定項目の変更

 Login Server の saml:providers 設定において, idpMetadata 項目が切り出されました。理由は..わかりません。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85740342

▷ アプリのインスタンスが自身のCF上でのIPアドレス/ポートを知ることが可能に

 アプリのインスタンスが実行されている環境に,環境変数 CF_INSTANCE_INDEX, CF_INSTANCE_IP, CF_INSTANCE_PORT, CF_INSTANCE_ADDR,CF_INSTANCE_PORTS が提供されることになりました。

 この変更により,例えばアプリのインスタンスが自身のIPアドレス/ポートを共有レジストリー(Redis, etcd 等)に登録し,CF の Gorouter を介さずに相互に通信するというようなことが可能になります。

 Pivotal Tracker での議論を読むと,Diego では CF_ 無しの環境変数名を使っていて,それに合わせるという動きもあったようなのですが,結局この名前に落ち着き,Diego 側で CF_ を付けるかどうかを選べるようにする,という方針になったようです。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/82311924

▷ Gorouter のログ出力の問題を修正

 設定ファイルを読み込む前にロガーを初期化していたために,ログ出力が想定通りになっていなかった問題が修正されました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85969214

▷ CCDB でアプリの created_at が更新されてしまうことがある問題を修正

 CCDB として MySQL を使っている場合,created_at カラムの設定がアプリの更新時に更新されてしまうことがあったため,修正されました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/82509564

▷ MySQL 5.6.6 で導入された非互換性に対応

 MySQL 5.6.6 で,--explicit_defaults_for_timestamp オプションを利用し,かつ TIMESTAMP 型のカラムに 非 Null 制約をかけている場合,デフォルト値の設定がないとエラーになるようになりました。これに対応するために,CCDB の created_at カラムにデフォルト値として Sequel::CURRENT_TIMESTAMP を明示的に設定するようになりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/78499982

▷ UAA / Login Server 1.11

 UAA と Login Server が共に 1.11 になりました。マイナー・バージョンの更新であるにもかかわらず,大きな変更はなかったようです。

◆ v197 (2015/01/28)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v197

 このリリースでは rootfs における GHOST 脆弱性対応も行われました。

▷ Cloud Controller (CC) におけるアクセス制御ポリシーの変更

 Cloud Controller は Authorization ヘッダーに不正なトークンを持つリクエストを全て拒否するようになりました。これまでは,アクセス制御不要なエンドポイント (例: /v2/services, /v2/service_plans, /v2/info 等) ではそのままレスポンスを返していました。Authorization ヘッダーを持たないリクエストに対しては,従来通りレスポンスを返します。

cf. https://www.pivotaltracker.com/n/projects/1211680/stories/78225098

▷ 非同期 Service インスタンス作成機能の開発開始

 Service インスタンスの作成を非同期に行える機能の開発が開始されました。

 参考URLには情報が一切ありませんが,これはもともとおそらく vcap-dev メイリングリストの このスレッド が発端で,のちに このスレッド で提案がなされたのぢ,このタイミングで開発が開始されました。

cf. https://www.pivotaltracker.com/n/projects/1211680/epics/1561148

▷ Service の orphan (孤児) インスタンス問題への対処の継続

 いつ始まったのかはわかりませんが,Service で Orphan (孤児) インスタンスが発生してしまう問題への対処が継続して行われています。これも参考URLには全く情報がないのですが,タイトルから察するに,「タイムアウトした時はインスタンスを消す」という取り組みではないかと思われます。

cf. https://www.pivotaltracker.com/n/projects/1211680/epics/1558230

▷ Service Broker が使用するライブラリーの変更

 リクエストがタイムアウトした時に意図せずリトライしてしまうのを防ぐために,Service Broker クライアントで使うライブラリーが net/http から httpclient に変更されました。リトライの処理は,上述の orphan 対処の中で扱われることになります。

cf. https://www.pivotaltracker.com/n/projects/1211680/stories/84037538

▷ monit スクリプトのログにタイムスタンプを追加

 CF のコンポーネント起動に使われる monit の *_ctl スクリプトのログに,タイムスタンプが入るようになりました。

 CF の運用者にとっては,非常にありがたい変更だと思います。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/80698234

▷ アプリを Org 指定で検索可能に

 CC の /v2/apps エンドポイントで,organization_guid によるフィルターが可能になりました。これにより,特定 Org に属するアプリのみの情報を取得できます。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85250536

▷ AWS 向け超最小構成 CF デプロイメント

 AWS 向け超最小構成 CF デプロイメントの例が cf-release に含まれるようになりました。これはけっこう力作で,開始から完成までに約1か月かかっています。

 CF のデプロイを簡単に試せるようにする取り組みの一環と思われます。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85732082

▷ Login Server 1.14

 Login Server が 1.14 に上がりましたが,更新内容の記述はありませんでした。

cf. https://github.com/cloudfoundry/login-server/releases/tag/1.14

◆ v198 (2015/02/10)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v198

 このリリースでは unzip 脆弱性に対する更新が入っています。
 また,Doppler に問題のある修正が入ってしまったようで,基本的には使うべきではないリリースのようです。

▷ Buildpack の更新

 以下の buildpack が更新されました。

  • Python Buildpack v1.1.2
    主な更新は upstream (Heroku) のマージで,その主な内容は以下です

    • PyPy 3 のサポート
    • 外部 URL の HTTPS 化
  • Go Buildpack v1.1.2

    • Go 1.4.1 がサポートされると同時に,デフォルトになりました
  • Java Buildpack v2.6.1
    依存ライブラリーの更新以外に目立った更新はないようでした

  • Ruby Buildpack v1.2.1

    • Ruby 2.2.0 がサポートされました

/v2/managed_service_instances が deprecated に

 CC の API エンドポイント /v2/managed_service_instances が deprecated になりました。

 Managed Service Instance という概念がなくなったわけではなく,もともと,

  • /v2/service_instances
  • /v2/managed_service_instances

という2つのエンドポイントが Managed Service Instance を指していたので,これを減らして1つにするというものです。

 当初は,まだこのエンドポイントがドキュメント化されていないということで,削除される予定だったようですが,CF の API ポリシーでは「何も削除しない」ことになっている(知らなかった!)ので,deprecated にすることになったようです。

cf. https://www.pivotaltracker.com/n/projects/1211680/stories/55946682

▷ Application Security Group におけるログのサポート

 Application Security Group で,outbound TCP 接続の最初のパケットがログに記録できるようになりました。

 用途の例として,不正な接続の試みの検出等が挙げられています。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/73905126

▷ Wildcard routes が利用可能に

 NATS に wildcard routes を publish できるようにすることで,wildcard routes が使えるようになりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/86083226

▷ より長い起動コマンドが利用可能に

 起動コマンドの従来の上限の 255 文字では,特に Java アプリでは制限がきつすぎるということで,CCDB のカラム定義が変更され,4096 文字まで使えるようになりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/86262896

▷ Routes を Org 指定で検索可能に

  /v2/routes の query parameter に organization guid が使えるようになり, Routes を Org 指定で検索できるようになりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85007712

▷ Org Auditors が /v2/events にアクセス可能に

 /v2/events は,従来は Space Auditor か Space に属するユーザーしかアクセスできないようになっていました。しかし,これではアクセス制限がきつすぎる(例えば,Space が削除されたら,その Space に関するイベントは admin しかアクセスできなくなる) ということで,OrgAuditor もアクセスできるよう変更されました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/84973576

▷ Loggregator のログ送信失敗時の DEA クラッシュ回避

 Loggregator が UDP でのログ送信に失敗した場合,DEA がクラッシュして再起動が必要でしたが,クラッシュしないようになりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/86646156

▷ Cloud Controller の worker と clock のログ出力先が STDOUT からファイルに

 CC の worker と clock のログ出力先が STDOUT だったことに起因する問題が何かあったようで,ログがファイルに出力されるよう変更されました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/76069390

◆ v199 (2015/02/12)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v199

 このリリースでは,前のリリース (v198) で導入されてしまった Doppler の問題がまだ残っているようで,基本的には使うべきではないリリースだと思われます。

▷ Admin (だけ)が全てにマッチする wildcard routes * を作成可能に

 どんな URL にもマッチする wildcard routes * の作成が可能になると同時に,それができるのは admin だけに制限されました。

 この route をアプリに割り当てた場合,これにマッチする全てのリクエストがそのアプリに転送されるようになります。ただし,exact match する route がある場合は,そちらが優先されます。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/84533566

▷ Warden container の file_descriptor 上限が設定可能に

 Warden container の file_descriptor 数の上限が deployment manifest から設定可能になりました。デフォルト値は従来の固定値である 16384 です。

 なお,この修正は,デプロイ済みのアプリのインスタンスには影響を与えません。なので,もしこの file_descriptor 数の上限の変更の恩恵を受けたければ,アプリを削除して再デプロイする必要があります。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85215352

▷ 環境変数 VCAP_SERVICES, VCAP_APPLICATION のエスケープ

 環境変数 VCAP_SERVICES, VCAP_APPLICATION 内の $\$ でエスケープするようになりました。

 もともとの問題は,VCAP_SERVICES 内に $ が含まれると Bash で変数置換が行われてしまうのでどうにかしたいということでした。結局この問題は上記の対処では完全に解決せず,v201 でさらなる対処が行われました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/77045902

▷ 認証エラーに対する長すぎるログの回避

 /v2/users 等,モデル最上位パスへのリクエストが認証エラーで失敗した場合,アクセス先のオブジェクトはテーブル全体になってしまうため,エラーログにテーブル全ての情報が書かれてしまうという問題がありました。この更新では,そうしたリクエストが失敗した場合は単にモデル名がログに書かれるだけに修正されました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/87860830

◆ v200 (2015/02/18)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v200

 このリリースのメインは Loggregator まわりでした。
 なお,次のリリース (v201) で,このリリースにおける Loggregator のデグレードが報告されているので,このリリースもスキップする方が賢明なようです。

▷ Doppler の安定化

 Doppler がアプリにつながっている syslog drain を扱っている時,そのアプリが restage された場合などで,Doppler が panic を発生させることがありました。原因はすでに閉じられた channel を繰り返し閉じようとすることだったので,channel の close 処理が冪等になるよう修正されました。

cf. https://www.pivotaltracker.com/n/projects/993188/stories/85813000

▷ Container metrics のサポート

 Traffic Controller が Doppler から container metrics を受信できるようになり,NOAA が Traffic Controller から container metrics を受信できるようになったことで,CF 環境から container metrics が取り出せるようになりました。

cf.

▷ Metron に系全体の累計値カウンター

 Metron が系全体の累計値のカウンターを持つようになり,系全体で一貫性のあるイベント数のカウントができるようになりました。

cf. https://www.pivotaltracker.com/n/projects/993188/stories/83072358

◆ v201 (2015/03/04)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v201

 このリリースの目玉は stack における cflinuxfs2 (Ubuntu 14.04.2 Trusty Tahr) のサポートでした。
 なお,これに伴い,このリリースにアップグレードする前に,2859 以降のバージョンの stemcell をデプロイしておくことが強く推奨されています。

▷ Ubuntu 14.04.2 (Trusty Tahr) ベースの stack cflinuxfs2 のリリース

 なお,Java Buildpack を覗いて,各 Buildpack の cflinuxfs2 対応はこの時点では完了していませんでした。

cf. https://www.pivotaltracker.com/n/projects/1042066/epics/1679516

 新たにデプロイされるアプリの stack のデフォルト値は lucid64 のままですが,デプロイ時に -s cflinuxfs2 を付けることで cflinuxfs2 へのデプロイが可能です。

▷ PHP Buildpack v3.0.4

 この更新は 旧来の PHP Buildpack を Daniel Mikusa による全く新しい buildpack に置き換えるものでした。これにより様々な変化がありましたが書ききれないので,詳細は以下の URL で。

cf. https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.0.4

▷ Java Buildpack 2.7

  cflinuxfs2 対応の他に,GemFile のサポートに焦点を当てたリリースでした。それ以外の詳細は以下の URL で。

cf. https://github.com/cloudfoundry/java-buildpack/releases/tag/v2.7

▷ Org 間での private domain の共有

 同一の Org Managers が管理する Org 間であれば,private domain を共有することが可能になりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/81780716

VCAP_SERVICES, DATABASE_URL, VCAP_APPLICATION が bash の変数置換の対象外に

 v199 で対処したはずの bash の変数置換問題ですが,完全に解決していなかったため,上記3つの環境変数が Ruby の Shellwords.escape を使ったより完全な形でエスケープされるようになりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/77045902

▷ cf-release: postgres と nfs の properties に networks 設定を追加

 cf-release の manifest の postgres と nfs の properties に networks 設定が追加されました。これらの job と/を collocate させる時に IP アドレスで collocation が行われることを認識できるようにすることが目的のようです。

cf.

▷ Cloud Controller: 複数 migration のロールバック

 CC の db:rollback で複数 migration のロールバックが可能になりました。

 この問題は,1年くらい前に自分たちで同様のことをやろうとして困った記憶があり,結局独自に修正を行って複数 migration のロールバックができるようにしたので,なんというか既視感があります。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/88148968

▷ DEA: アプリの起動スクリプトにおける .profile.d とユーザー環境変数の評価順序

 アプリの起動スクリプトにおいて .profile.d より前にユーザー環境変数の評価が行われるようになりました。これにより,例えば .profile.d で使われる PATHLD_LIBRARY_PATH などを override できます。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/88248306

▷ cf-release: コネクション数の上限のデフォルトが 64000 に

 HAProxy のコネクション数の上限のデフォルトが 64000 になりました。

 「自分のアプリでは 10K レベルの同時接続が必要」というユーザーの声 に応えたかたちです。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/88759360

router.start / router.greetpruneThresholdInSeconds が追加

 Gorouter が publish する router.start / router.greet に,「Gorouter が router.register を古いと判断するまでの秒数」を示す pruneThresholdInSeconds が追加されました。

 これにより,例えば Gorouter にルーティングを依存している独自 Service Broker が,router.register の間隔を動的に決めることができるようになります。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/86704346

▷ Gorouter: HTTP Keep-Alive 対応

 Gorouter ではこれまで HTTP Keep-Alive を無効化し,クライアントとの HTTP コネクションを1回ごとに切断する処理を行っていました。それらは意図的な変更であることが このコミットこのコミット からわかりますが,理由はよくわかりませんでした。

 しかし,この更新で HTTP Keep-Alive 対応が(約1年の時を経て)復活しました。その結果, HTTPS トラフィックの性能は4倍に,HTTP トラフィックの性能は1.2倍になった ようです。

cf.

◆ v202 (2015/03/09)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v202

▷ Ruby 1.9.3 の削除と Ruby 2.1.4 への移行

 Warden で Ruby 1.9.3 → 2.1.4 の移行が行われました。その他,ドキュメントからは DEA, collector, login, uaa でも同様の移行が行われたとされているのですが,下記参考 URL から辿れるコミットは Warden リポジトリーのもの しか確認できませんでした。

 1.9.3 の削除は,EOL が理由だと考えます。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/89148118

◆ v203 (2015/03/12)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v203

▷ Java Buildpack 2.7.1

 v2.7 には offline buildpack のパッケージングが正常に行えない問題があったようで,この更新でそれが解消されました。

cf. https://github.com/cloudfoundry/java-buildpack/releases/tag/v2.7.1

▷ [Experimental] Route API の開発開始

 Route API の開発が始まり,cf-release に初期実装が取り込まれました。

cf.

▷ [Experimental] 独自 CA 証明書対応の開発開始

 独自 CA 証明書を証明書ストアに格納できるようにする機能の開発が始まりました。ca_truster という job が cf-release に追加されていますが,まだ race condition 等の問題があり実用段階ではありません。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/83168476

▷ Gorouter の SSL 終端

 Gorouter 単体で SSL が終端できるようになりました。

 これで前面のロード・バランサーと Gorouter の間の通信が暗号化され,よりセキュアになります。また場合によっては,前面のロード・バランサーなしの構成でも HTTPS / WSS に対応できます。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/81988510

▷ TCP チューニング

 通信に関するいくつかの kernel parameter に手が入りました。参考 URL を見たのですが,理由はわかりませんでした。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/90005794

lucid64 stack なしの CF 環境構築が可能に

 lucid64 stack を DB migration から外し,deployment manifest 移すことで,lucid64 stack なしの CF 環境構築も可能になりました。Manifest に指定がない場合は,デフォルトの stack セット (この時点では lucid64cflinuxfs2) が DB に投入されます。既存環境の更新の場合,manifest の stack は "upsert" されます。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/89643092

▷ cf-release: X-Forwarded-Proto ヘッダーの追加

 UAA / Login job の monit スクリプトの /healthz のチェック時のリクエストに, X-Forwarded-Proto ヘッダーが追加されました。

 これは,uaa.require_https = truelogin.protocol = https という設定がなされているケースでも /healthz のチェックを行えるようにするための変更です。もともとは, この issue がきっかけになっています。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/89562892

▷ resource matching で一致したリソースのデータ量が多すぎてエラーになる問題の修正

 Cloud Foundry では,アプリをアップロードする際,アップロードの前にファイルごとに fingerprint を送って,それが一致するものはすでにキャッシュに入ったアップロード済みのものを使うことで,ファイル・アップロードの効率化を図る resource matching という仕組みがあります。

 その際,fingerprint が一致したファイル名は全てアップロードを受け取る処理を行う非同期ジョブ (delayed_job) に渡されるのですが,delayed_job はモデルなので,実際には DB の delayed_jobs テーブルの1行が1つの delayed_job インスタンスになります。つまり「fingerprint が一致したファイル名」は一旦全て DB に格納されることになるわけです。この「fingerprint が一致したファイル名」が多すぎて,DB のカラムに入りきらないというエラーが報告されたため,カラムのサイズ設定が拡大されました。

 実は私たちも別途この問題に遭遇していて,同様にカラム・サイズの拡張で対応しました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/89572944

▷ CC API への "min_cli_version", "min_recommended_cli_version" の追加

 ついに,CC の /v2/info エンドポイントに,"min_cli_version", "min_recommended_cli_version" の情報が付与されるようになりました。

 これまで,CF の API である CC API と,その API にアクセスする cf CLI は独立に進化していて,CC API のバージョンと cf CLI のバージョンの対応関係は明示されていませんでした。しかし,この更新でついにその対応関係が把握できるようになりました。

  • "min_cli_version" は,その CLI から発行されるコマンドが CC API でエラーにならない最小のバージョン
  • "min_recommended_cli_version" は,その時点の CC API に存在する機能を(全て)有効に使うことができる CLI の最小のバージョン

です。

cf.

▷ Space の Security Groups の可視性

 所属している Space の Security Groups が admin 以外のユーザーにも見えるようになりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/82055042

▷ cf-release: "uaa.issuer" を設定可能に

 "uaa.issuer" が deplooyment manifest で設定可能になりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/88835598

◆ v204 (2015/03/20)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v204

 このリリースの目玉は各種 buildpack の cflinuxfs2 rootfs サポートでした。

 なお,このリリースで cf-release のサイズが 5.1 GB となり,Bosh Director のデフォルトの上限値である 5 GB を超えたため,設定を変更するなどしないとデプロイに失敗する可能性があります。

▷ Buildpack の更新

 以下の buildpack が更新されました。
 全て cflinuxfs2 rootfs のサポートがメインになっています。
 それ以外の更新は以下の通りです。

  • PHP buildpack v3.1.0
    大きな更新はなし

  • Ruby buildpack v1.3.0

    • lucid64 stack での Ruby 1.9.2 のサポートを終了
    • manifest.yml に依存ライブラリーのチェックサムを追加
  • Python buildpack v1.2.0

    • manifest.yml に依存ライブラリーのチェックサムを追加
  • Nodejs buildpack v1.2.0

    • 0.8.6, 0.10.14, 0.11.4 の削除
    • manifest.yml に依存ライブラリーのチェックサムを追加
  • Go buildpack v1.2.0

    • manifest.yml に依存ライブラリーのチェックサムを追加

▷ Warden コンテナー内からホストへのアクセス

 cf-release の deployment manifest で dea_next.allow_host_accesstrue に設定することで, Warden コンテナー内からホスト OS にアクセス可能になりました。同一ホスト内の他のコンテナーと通信することもできます。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85565064

▷ v2 Directory server のポート変更

 v2 Directory server のポートが, bosh_agent が使うポートとの衝突を理由に,34567 から 32766 に変更されました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/87576478

◆ v205 (2015/03/25)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v205

 このリリースは脆弱性対応がメインでした。
 それ以外の主な更新は以下の通りです。

▷ quotacheck へのデバッグ出力の追加

 quotacheck にデバッグ出力が追加されました。これは,quotacheck に引っかかって Warden が落ちる問題の調査のための対処です。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/89756902

◆ v206 (2015/04/09)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v206

 rootfs の脆弱性対応が1件ありました。
 また,このリリースに同梱されている Python Buildpack に問題が見つかりました。これは次のリリースで解消されます。

 なお,このリリースから,Diego release との対応関係が記載されるようになりました。

▷ Arbitrary Parameters 機能の開発作業継続

 いつ始まったのかわかりませんが,Arbitrary Parameters という機能の開発が始まっています。これは,アプリケーションに任意のパラメーターを入れるためのフィールドを追加するものです。

cf. https://www.pivotaltracker.com/epic/show/1725984

▷ Service Keys 機能の開発作業継続

 同じくいつ始まったのかわかりませんが,Service Keys という機能の開発が始まっています。これは,アプリとバインドすることなくサービスの credentials (アクセスキー等) を取得できるようにする機能です。

cf. https://www.pivotaltracker.com/n/projects/1299870/epics/1743366

▷ cloud_controller_ng job の billing events のデフォルトが false に

 cf-release の cloud_controller_ng job の billing events のデフォルトが false に変更されました。これは,billing events 自体が deprecated に指定されたことに因るものです。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/85800284

▷ Nodejs Buildpack v1.2.1

 0.12.0, 0.10.38 がサポートされました。

cf. https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.2.1

▷ buildpack_cache の削除

 buildpack_cache が cf-release から削除されました。

 buildpack_cache はもともと DEA で Warden コンテナー内に system buildpack の依存ライブラリーをホストと受け渡しする場所として機能してきましたが,最近は buildpack が全て admin buildpack 化され,依存ライブラリーも内部に持つようになったので, deprecated になっていました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/88960548

▷ Org に所属するユーザーの権限/ロールの一覧の取得

 Org に所属するユーザーの権限/ロールの一覧が取得できるエンドポイント /v2/organizations/:guid/user_roles が追加されました。

cf.

▷ Staging に失敗したアプリの restart

 従来の実装では,staging に失敗したアプリを restart すると,

  • package_stateFAILED のまま,アプリの staging が始まる
  • CC は package_state を見て,再び FAILED を返す
  • Staging は続行される

という流れだったが,2番目の CC の振る舞いは誤解を与えるものであるため,最初の段階で package_statePENDING に戻して,以下の処理を続行するように変更された。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/88373814

◆ v207 (2015/04/16)

URL: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v207

 デフォルトの rootfs が cflinux2fs に変更されました。

▷ v206 で入ってしまった Python Buildpack のバグの解消

 v206 で入ってしまった Python Buildpack のバグが予定通り解消されました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/87752612

▷ Java buildpack v3.0

 もっとも重要な更新は,Java Buildpack 内で使用する Java や Tomcat などの言語/依存ライブラリーのバージョンが,環境変数で変更できるようになったことです。これまで Java Buildpack では,「最新のバージョンこそベスト」というポリシーで,原則としてデフォルトの最新バージョンのみが利用可能で,それ以外のバージョンを使いたいときは,Java Buildpack 自体をフォークしてソースコードを変更するしかありませんでした。しかし,このバージョンから環境変数でそれらの指定が可能になったので,言語/依存ライブラリーの組み合わせごとにフォークする手間が大幅に省けるようになりました。

 その他の更新の詳細については,以下をご覧ください。

cf. https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.0

▷ Space に所属するユーザーの権限/ロールの一覧の取得

 Space に所属するユーザーの権限/ロールの一覧が取得できるエンドポイント /v2/spaces/:guid/user_roles が追加されました。
 このエンドポイントを使えるのは Org のメンバーのみです。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/88712782

▷ アプリの stack_guid による検索

 SpaceDeveloper が,アプリを stack_guid で検索することが可能になりました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/91426186

▷ Gorouter が不要な drain のコネクションを 15 分維持する問題の修正

 Gorouter において,コネクションの状態 (active / inactive) を監視することで,不要な drain のコネクションはすぐに切断するように修正されました。

cf. https://www.pivotaltracker.com/n/projects/966314/stories/91218274

▷ Metron の statsd サポート

 Metron で statsd protocol 用のエンドポイントがリリースされました。

 statsd は metrics 用のプロトコル/サービスとして,最近少し話題になっているもののようです。

cf.

▷ Loggregator のコンポーネント UUID

 今まで Loggregator のコンポーネント UUID が空だったのが,ちゃんと値が入るように修正されました。

cf. https://www.pivotaltracker.com/n/projects/993188/stories/91691260

後編まとめ

 大きめの feature の追加としては,

  • Service Audit Events 機能

だけのような気がしますが,後編の時期でもっとも印象深かったのは,やはり

  • Ubuntu 14.04 Trusty Tahr stemcell

の導入です。

 また,今まで水面下で進められてきた Diego が,ここにきて次第に地表に姿を表しつつある感が有ります。

 あとは,

  • Application Process Type
  • Asynchronous Service Instance

辺りの feature は,ずっとやってる感じです (前者はもう10か月くらいにはなるはず)。

 その他,個人的に良い更新だと思ったのは,

  • CC API と CF CLI のバージョンの対応付け
  • Java Buildpack の環境変数による設定変更
  • HAProxy / Gorouter の HTTP keep-alive 対応

などでした。

 今後は,いよいよ Diego が視界に入ってくる一方,徐々に CF Foundation が実体をなしてきて,開発方法も変化してきているので,その辺りがどう影響してくるかに,個人的には興味があります。

 あと,割と最新のニュースですが, HP から CF Foundation に寄付された .Net stack の今後にも興味津々です。

 以上です。

(疲れた...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment