Cloud FoundryのDiegoという新アーキテクチャではDockerイメージをデプロイすることもできます。 前に紹介したMicroPCFではDiegoが使用されているので、Dockerイメージもpushできました。 (Pivotal Web Servicesではまだ使用できないようです)
Diegoについてはこちらの資料を。
http://www.slideshare.net/jacopen/diego-45603123
Dockerを使えるようにする
Dockerデプロイ機能はデフォルトでは無効になっています。
$ cf feature-flags
Retrieving status of all flagged features as admin...
OK
Features State
user_org_creation disabled
private_domain_creation enabled
app_bits_upload enabled
app_scaling enabled
route_creation enabled
service_instance_creation enabled
diego_docker disabled
set_roles_by_username enabled
unset_roles_by_username enabled
diego_docker
というfeatureがそれです。これを有効にします。
$ cf enable-feature-flag diego_docker
Setting status of diego_docker as admin...
OK
Feature diego_docker Enabled.
Dockerイメージをpushする
あとはDockerイメージをcf push
するだけです。イメージ名は-o
オプションで指定します。サンプルアプリとしてcloudfoundry/lattice-appを使ってみます。
$ cf push my-app -o cloudfoundry/lattice-app
Creating app my-app in org maki-org / space development as admin...
OK
Using route my-app.192.168.33.10.xip.io
Binding my-app.192.168.33.10.xip.io to my-app...
OK
Starting app my-app in org maki-org / space development as admin...
Creating container
Successfully created container
Staging...
Staging process started ...
Staging process finished
Exit status 0
Staging Complete
0 of 1 instances running, 1 starting
1 of 1 instances running
App started
OK
App my-app was started using this command `/lattice-app `
Showing health and status for app my-app in org maki-org / space development as admin...
OK
requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: my-app.192.168.33.10.xip.io
package uploaded: Wed Dec 30 18:09:29 UTC 2015
stack: cflinuxfs2
buildpack: unknown
state since cpu memory disk details
#0 running 2015-12-31 03:09:50 AM 0.0% 0 of 1G 0 of 1G
できました。cf apps
でも普通に見えます。
$ cf apps
Getting apps in org maki-org / space development as admin...
OK
name requested state instances memory disk urls
my-app started 1/1 1G 1G my-app.192.168.33.10.xip.io
http://my-app.192.168.33.10.xip.io にアクセスすると、
が表示されました。できましたね。ちなみに次の環境変数が設定されているようです。
スケールアウトにもcf scale
が使えます。
$ cf scale my-app -i 3
Scaling app my-app in org maki-org / space development as admin...
OK
$ cf app my-app
Showing health and status for app my-app in org maki-org / space development as admin...
OK
requested state: started
instances: 3/3
usage: 1G x 3 instances
urls: my-app.192.168.33.10.xip.io
package uploaded: Wed Dec 30 18:09:29 UTC 2015
stack: cflinuxfs2
buildpack: unknown
state since cpu memory disk details
#0 running 2015-12-31 03:09:50 AM 0.0% 0 of 1G 0 of 1G
#1 running 2015-12-31 03:12:42 AM 0.0% 0 of 1G 0 of 1G
#2 running 2015-12-31 03:12:43 AM 0.0% 0 of 1G 0 of 1G
アクセスするたびにインデックスが変わります(=別のインスタンスにアクセスできています)
使用されるポートに関しては、こちらに書かれています。
The CC will also run the start command as the user specified in the Docker image, and will currently tell Diego and the Gorouter to route traffic to the lowest-numbered port exposed in the Docker image. (We expect CC to support routing to multiple ports soon.)
現時点では、DockerfileでEXPOSEしている番号で最小のものを使うようです。また、環境変数PORT
が設定されてるのでアプリ側が環境変数PORT
を使っているパターンが一番Cloud Foundryにpushしやすいように思えます。Spring Bootアプリで、EXPOSE
の設定もPORT
も使用していない場合は、
$ cf set-env <APP> SERVER_PORT 8080
を実行して、Spring Bootアプリ側がデフォルトの8080
ポートを使うように環境変数を設定するのが良いと思います。
簡単ですが、Dockerイメージをデプロイする方法を紹介しました。ポートの仕組みはもう少し改善が欲しいのと、HTTP以外も扱えるようになるとなかなか夢が広がりそうですね(もう扱える?)。 MicroPCFはインストールも楽だし、開発面でもかなり使えそう。
Dockerは起動は簡単だけど、運用面は他製品頼りでどれを使えばいいかわかりづらい状況。Cloud Foundryを使えばCloud Foundryによる12 Factors Appの手法をそのまま使えるのでとても良い。