この投稿は Open PaaS Advent Calendar 2015 の7日目の記事です。
先月末， ”10 common errors when pushing apps to cloud foundry” というプレゼンテーション資料の日本語訳を， 『Cloud Foundry にアプリケーションを push する際の典型的な10のエラー』 として公開しました。
翻訳に至った経緯は，瓢箪から駒というか，
- ある Cloud Foundry ユーザーから Node.js アプリに関する質問が Slack 上で来る
- それに答える過程で，「Cloud Foundry 上でのデバッグについてはこの資料なんか有用ですよ」みたいに情報提供
- 同じチャネルにいた別の人から「それ翻訳して公開してくれないかな」という声
- 「やってもいいけど許諾とらないと」と言う
- 同じチャネルにいたさらに別の人が，日本 Cloud Foundry グループや PaaS 勉強会に参加している IBM の方に連絡 (原著者が IBM の方だったので)
- 上記 IBM の方が原著者の方に連絡＆許諾取得
- 翻訳＆公開
という感じでした。1〜6まではたぶん1日経っておらず，インターネット商用化前後に社会人になった者としては，なんというか今の時代の展開の速さを実感する次第です。
さて，この資料の内容は，タイトルの通り「Cloud Foundry にアプリケーションを push する際の典型的なエラー」を，エラーが発生するフェーズに分けて説明し，併せてその一般的な解決方法を示すものです。詳細を説明するには Advent Calendar より，デモやハンズオンの方が効果的だと思いますので，この記事では説明しません。別途機会があれば PaaS 勉強会 等で説明させていただくことがあるかもしれません。実際のところ，元の資料がよくできているので，(濃いとは言っても) Cloud Foundry を使ったことがある方であれば，読めばだいたいわかるようになっていると思います。
ただ翻訳している過程で，数箇所「これはどういうことだろう？」と感じたところがあり，それらについては原著者の方に質問して回答をいただいたので，ここではそれについて書きたいと思います。
具体的には，以下の3点を質問し，回答をいただきました。
以下，順に説明していきます。
Cloud Foundry ではアプリのデプロイを行う際に buildpack というものを使っています。これはもともと Heroku が開発/公開 しているものを，Cloud Foundry で使うようにしたものです。Buildpack の詳細についてはここでは説明しませんが，その 処理過程は大きく以下の3つ に分かれます。
- detect: buildpack が適用されるべきかどうかを判定する
- compile: アプリの実行環境を整える
- release: 必要に応じて，buildpack の処理結果等を含むメタデータを (戻り値として) 返す
上述の通り，detect 処理は単なる判定なので，原則的にアプリのファイルを読むことはあっても書くことはないはずです。しかし，実際は detect も含めこれらの処理は単にスクリプトとして呼び出されるだけなので，内部で何をする／しないという制約はなく，どのように作るかは buildpack の作者に委ねられています。
原著者の Jack-Junjie Cai 氏によると，detect でアプリのコードを書き換えたことによってデプロイが正常に動作しない例が幾つかあったため，このような注意を書いたとのことでした。
前述のように，buidpack の detect 処理では当該 buildpack が適用されるべきかどうかの判定を行います。この判定は「特定のファイルの有無」で判断されることが一般的です。
例：
| buildpack | sign file(s) |
|---|---|
| ruby-buildpack | Gemfile [1] |
| nodejs-buildpack | package.json [2] |
| go-buildpack | *.go [3] |
| python-buildpack | requirements.txt, setup.py [[4]][a4] |
| php-buildpack | composer.json, *.php, etc. [[5]][a5] |
| staticfile-bildpack | Staticfile [[6]][a6] |
[a4]:https://github.com/cloudfoundry/python-buildpack/blob/84ffebd8087b424c3280a980aa8dd0785baa9cb4/bin/detect#L19) [a5]:https://github.com/cloudfoundry/php-buildpack/blob/9577756cb738791169427692dc4e65d9549efabf/scripts/detect.py#L25-L40 [a6]:https://github.com/cloudfoundry/staticfile-buildpack/blob/e81f609a954cac89bd5f15386462f3881f2152a4/bin/detect#L6
「サイン・ファイル」は，このような「判定に使われる特定のファイル」を表す言葉とのことでした。
"security group" というと，最近であれば， Amazon EC2 のセキュリティ・グループ，あるいはそれに類する IaaS の network security groups 的なものを思い浮かべる方も多いと思います。
しかし（紛らわしいのですが）本資料でいう security group は，それとは別の， Cloud Foundry の Application Security Groups を指しています。
Cloud Foundry の Application Security Groups では，特定の ＜CIDR, ポート＞ の組み合わせへの outbound の接続が制限されます。
スライド#14, スライド#19 の例でいうと，外部のリポジトリーにファイル等を取りに行こうとして失敗する原因として，Application Security Groups が適切に設定されていない可能性をチェックすべき，ということになります。
以上， 『Cloud Foundry にアプリケーションを push する際の典型的な10のエラー』 についての簡単な補足説明でした。
Cloud Foundry へのアプリのデプロイでトラブルが起きた時，何が起こっていて，どうすれば解決できるかを知る上で，本資料はとても良い資料だと思います。困った時はちょっと目を通してみていただけると，お役に立つかもしれません。