オープンソースのPaaSソフトウェア CloudFoundry の技術情報やイベント告知などを掲載します

2015-10-30

Firepoker を Cloud Foundry で動かす

「Cloud Foundry 百日行」第90日目、本日はアジャイル開発等のストーリーポイントを決定する際に利用する Planning poker を ブラウザ上で実行できる Firepoker です。

アジャイル開発のチケットのポイント決めも開発メンバーが1箇所に揃っていれば、その場で「せーの!」でカードを見せ合ってポイント決定ということが出来ます。しかし最近の開発スタイルでは1箇所に全員集合というのは少ないかもしれません。
そんな時にこのツールを利用すればメンバーが何処にいても実施できます。またコメントや条件を入れ合って再度実施も可能です。一度試してみてはいかがでしょうか。

基本情報

手順の概要は以下の通りです。

  • 1) ソースコードの取得
  • 2) アプリのデプロイ
  • 3) 動作確認

1. ソースコードの取得

まずはソースコードを取得します。

$ git clone https://github.com/Wizehive/Firepoker
$ cd Firepoker
Firepoker$ ls
app  bower.json  CNAME  Gruntfile.js  karma.conf.js  karma-e2e.conf.js  LICENSE  package.json  README.md  test

2. アプリのデプロイ

README にも書かれていますがソースコードダウンロード後の手順は以下の3つです。

  • Install with NPM: npm install
  • Install with Bower: bower install
  • To run the local server: grunt server

では手順通りすすめていきましょう。

2.1 npm installとbower install

出来れば手元の環境でのインストール作業は極力さけたいことろですが、 cf push-c オプションで実施するにはいろいろと修正が必要そうなので今回はあきらめて手元の環境で実施します。
その為、インストール前に node -v , npm -v , bower -v でそれぞれのコマンドが利用出来ることを確認しておいて下さい。

Firepoker$ npm install
Firepoker$ bower install

それぞれ準備された package.jsonbower.json に沿ってインストールが実行されます。
その後フォルダを確認すると node_modulesapp/components が作成されています。

2.2 index.htmlの修正

app/index.html の中で bower でインストールされたファイル名の指定に誤りがあるので修正します。

Firepoker$ vi app/index.html
Firepoker$ git diff
: 
diff --git a/app/index.html b/app/index.html
index a1d574d..bc46819 100644
--- a/app/index.html
+++ b/app/index.html
@@ -54,7 +54,7 @@
     <script src="components/angular-sanitize/angular-sanitize.js"></script>
     <script src="components/angular-truncate/src/truncate.js"></script>
     <script src="components/firebase/firebase.js"></script>
-    <script src="components/angularfire/angularfire.js"></script>
+    <script src="components/angularfire/angularFire.js"></script>
     <!-- endbuild -->
  
     <!-- build:js scripts/scripts.js -->

2.3 Gruntfiles.jsへの編集

今回もデフォルトではポート番号が9000固定になっています。環境変数からポート番号を取得する必要があるので Gruntfiles.js に修正を加えます。
また grunt で起動する際に --force を加えてもいいのですが compassopen のエラーによる起動の中断をさける為に compassopen をコメントアウトします。そして外部からアクセス出来るように hostname の修正もあわせて実施します。

Firepoker$ vi Gruntfile.js 
Firepoker$ git diff
diff --git a/Gruntfile.js b/Gruntfile.js
index 7a5ca60..475cc23 100644
--- a/Gruntfile.js
+++ b/Gruntfile.js
@@ -45,9 +45,9 @@ module.exports = function (grunt) {
     },
     connect: {
       options: {
-        port: 9000,
+        port: (process.env.VCAP_APP_PORT || 9000),
         // Change this to '0.0.0.0' to access the server from outside.
-        hostname: 'localhost'
+        hostname: '0.0.0.0'
       },
       livereload: {
         options: {
@@ -270,10 +270,10 @@ module.exports = function (grunt) {
   grunt.registerTask('server', [
     'clean:server',
     'coffee:dist',
-    'compass:server',
+//    'compass:server',
     'livereload-start',
     'connect:livereload',
-    'open',
+//    'open',
     'watch'
   ]);

2.4 マニフェストの作成

最後に manifest.yml を作成します。指定するのは -c のコマンドオプションと time です。

Firepoker$ vi manifest.yml
Firepoker$ cat manifest.yml 
---
applications:
- name: firepoker
  command: npm install grunt-cli -g && cd /home/vcap/app/ && grunt server 
  time: 180

grunt コマンドを実行する為に必要となる grunt-cli を追加インストールして grunt server コマンドで起動します。
なお cdGruntfile.js が存在するディレクトリに念の為、移動しています。

2.5 デプロイの実行

では cf push しましょう。

Firepoker$ cf push
Using manifest file /home/k-nagai/work/Firepoker/manifest.yml
 
Creating app firepoker in org k-nagai / space work as k-nagai...
OK
 
Creating route firepoker.10.244.0.34.xip.io...
OK
 
Binding firepoker.10.244.0.34.xip.io to firepoker...
OK
 
Uploading firepoker...
Uploading app files from: /home/k-nagai/work/Firepoker
Uploading 28.8M, 9760 files
Done uploading               
OK
 
Starting app firepoker in org k-nagai / space work as k-nagai...
-----> Downloaded app package (26M)
-------> Buildpack version 1.3.1
       Node.js Buildpack v64
-----> Reading application state
       package.json...
 
:
:
       WARNING: Avoid semver ranges starting with '>' in engines.node
       WARNING: Avoid checking node_modules into source control
       WARNING: No Procfile, package.json start script, or server.js file found
-----> Uploading droplet (31M)
 
1 of 1 instances running
 
App started
 
 
OK
 
App firepoker was started using this command `npm install grunt-cli -g && cd /home/vcap/app/ && grunt server`
 
Showing health and status for app firepoker in org k-nagai / space work as k-nagai...
OK
 
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: firepoker.10.244.0.34.xip.io
last uploaded: Tue Oct 20 04:32:14 UTC 2015
stack: cflinuxfs2
buildpack: Node.js
 
     state     since                    cpu    memory           disk      details   
#0   running   2015-10-20 01:33:09 PM   0.0%   130.7M of 256M   0 of 1G     

動作確認

ブラウザでURLへアクセスします。

Play now をクリックして Create a new game でストーリー等を作って行きましょう。

その後に取得したURLをメンバーに共有します。

メンバー各々が join してストーリーに対してポイントを選択し終えるとカードの値が表示されます。

未選択のユーザがいる場合は相手のカードは裏返した状態で見えません。

動作は問題ないようです。

おまけ

今回のアプリでステータスはスタート状態になったのにブラウザでアクセスしたら画面が真っ白という方へ。
まず1つは bower install 。単純なことなのですがインストール途中にインストールするバージョンを聞いてきたりします。アプリによっては新しいバージョンを入れる場合が正しいこともあるのですが、今回は bower.json に書かれたバージョンを選択して下さい。
もう1つは手順の index.html の修正。初歩的な問題として Cloud Foundry の実行環境は Ubuntu がベースになっているので、Windows がベースのアプリを動かしたい場合は大文字・小文字に注意しましょう。特に今回のアプリのように読み込みファイルのアドレスがエラーになってしまうと元も子もありません。
最後に別のブラウザでもアクセスを試して下さい。検証中に「別のブラウザだったら見えた」ということもありました。

今回使用したソフトウェア

2015-10-29

Sphinx を Cloud Foundry で動かす

「Cloud Foundry 百日行」第89日目,今日は3回シリーズ「静的サイト・ジェネレーター」の最終回,Python ベースのドキュメンテーション生成ツール Sphinx です。前2回の Jekyll, Hugo がブログ寄りであったのに対し,Sphinx はマニュアル等のドキュメンテーションを意識したツールということで,若干毛色は異なる印象です。

基本情報

手順の概要は以下の通りです。

  • 1) 静的サイトのサンプルの取得
  • 2) Cloud Foundry 向けのカスタマイズ
  • 3) Cloud Foundry へのデプロイ
  • 4) 動作確認
  • 5) まとめ

1. 静的サイトのサンプルの取得

前々回, 前回 同様,Cloud Foundry にデプロイするサイトのサンプルとして,百日行シリーズの最初の2つの記事を使います。元のフォーマットは Markdown で,それを reStructuredText に手動で書き直しましたが,内容的には同等です。

サンプルは GitHub に置いてあるので,試してみられる方は以下の手順で clone してください。

$ git clone https://github.com/nota-ja/cf-sphinx-example.git
..
$ cd cf-sphinx-example/

2. Cloud Foundry 向けのカスタマイズ

今回はカスタム buildpack を使わず,Cloud Foundry 標準の buildpack である python-buildpack だけを使ってサイト作成 / serve を行います。作業としては以下の3つのファイルを追加するだけです。

  1. pip を使って sphinx をインストールするための requirements.txt を用意する
  2. 起動時にサイトのビルドと Web サーバーの起動を行うための Procfile を用意する
  3. (optional) Cloud Foundry 環境に余分なファイルをアップロードしないために,.cfignore ファイルを用意する

2.1. requirements.txt

以下の内容の requirements.txt をリポジトリーのトップ・ディレクトリーに置きます。

$ cat requirements.txt
sphinx

2.2. Procfile

make html でサイトをビルドしたあと,build ディレクトリーに移動して Python の Web サーバーを起動する Procfile を作成し,リポジトリーのトップ・ディレクトリーに置きます。

$ cat Procfile
web: make html && cd build/html && python -m SimpleHTTPServer $PORT

2.3. .cfignore

不要なファイルが Cloud Foundry にアップロードされるのを避けるため,cfignore を追加します。Sphinx のデフォルトのビルド・ディレクトリーは build なので,build を含めておきます。

$ cat .cfignore
*~
.*~
/build

3. Cloud Foundry へのデプロイ

以上で準備が整ったので,Cloud Foundry にデプロイします。

$ cf push sphinx-example
Creating app sphinx-example in org nota-ja / space prod as nota-ja...
OK
..
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: sphinx-example.10.244.0.34.xip.io
last uploaded: Wed Oct 28 11:16:54 UTC 2015
stack: cflinuxfs2

     state     since                    cpu    memory          disk      details
#0   running   2015-10-28 08:17:36 PM   0.0%   63.3M of 256M   0 of 1G

起動しました。これもメモリはデフォルトの 256MB のままにしていますが,もう少し減らしても大丈夫そうです。

4. 動作確認

ブラウザーでアクセスしてみた時のトップ画面はこんな感じです:

各ページを表示させてみます:

画像の表示も確認しました:

以上で動作確認は終わりです。

5. まとめ

「静的サイト・ジェネレーター」シリーズ第3弾,最終回は Sphinx を試してみました。本記事はカスタマイズを極力減らす方針での試行だったのですが,いかがだったでしょうか?

今回「静的サイト・ジェネレーター」という同種のアプリのくくりで,さまざまなデプロイのパターンを試してみましたが,まとめるとおおよそ以下のようになると思います。

Generator Buildpack(s) Web server site generation
Jekyll custom, multi custom(*1) on staging
Hugo custom built-in(*2) on startup
Sphinx standard built-in on startup

(*1) メインの buildpack に含まれない Web サーバーを使用
(*2) メインの buildpack 内で調達できる Web サーバーを使用

各サイト・ジェネレーターは今回のシリーズで試したパターンでしかデプロイできないわけではなく,上記のさまざまな組み合わせでデプロイできると思います。どのパターンが良いかは,使っているツールや,サイトの更新頻度,負荷の状況等によって変わってくると思いますので,ご自分のサイトに適したパターンを試してみてください。

今回使用したソフトウェア

2015-10-28

Hugo を Cloud Foundry で動かす

「Cloud Foundry 百日行」第88日目,今日は3回シリーズ「静的サイト・ジェネレーター」の2日目, Golang ベースで高速性が特徴の Hugo です。

基本情報

手順の概要は以下の通りです。

  • 1) 静的サイトのサンプルの取得
  • 2) Cloud Foundry 向けの修正/カスタマイズ
  • 3) Cloud Foundry へのデプロイ
  • 4) 動作確認
  • 5) まとめ

1. 静的サイトのサンプルの取得

前回 の Jekyll 同様,Cloud Foundry にデプロイするサイトのサンプルとして,百日行シリーズの最初の2つの記事を使います。

サンプルは GitHub に置いてあるので,試してみられる方は以下の手順で clone してください。このリポジトリーはテーマのリポジトリーを submodule として持つので,clone の際に --recursive が必要です。

$ git clone --recursive https://github.com/nota-ja/cf-hugo-example.git
..
$ cd cf-hugo-example/

2. Cloud Foundry 向けの修正/カスタマイズ

今回のデプロイでは,heroku-buildpack-hugo を使います。この buildpack を使えば,通常はほとんど何もしなくても Hugo でサイトを生成して serve することができるはず,なのですが,今回は以下の理由で修正/カスタマイズを行いました。

  1. heroku-builcpack-hugo の bin/ 下のスクリプトに実行権が付与されていないためステージングに失敗する
    → buildpack を修正して実行権を付与
  2. サイトを Python の Web サーバーではなく Hugo 自身で serve させたい
    → buildpack の release スクリプトをカスタマイズ
  3. Golang の net/url の問題でパスの先頭に // がある URL リダイレクトが正常に機能しない
    → テーマのコード内のパスを修正

2.1. スクリプトに実行権を付与

今回使用する heroku-buildpack-hugo では, bin/ 下の3つのスクリプト (detect, compile, release) に実行権が付いていません。 Heroku ではこれで問題ないのかもしれませんが(未確認),(少なくとも今回利用した) Cloud Foundry 環境では BuildpackCompileFailed というエラーが出てステージングに失敗するので,実行権を付与します。

$ chmod a+x bin/*

2.2. サイトを Hugo で serve

オリジナルの heroku-buildpack-hugo では,生成したサイトを Python の Web サーバーで serve するようになっています。

https://github.com/roperzh/heroku-buildpack-hugo/blob/b678e649e9b8d0529a9f65525ad1946b5a1cca42/bin/release#L6

  web: "cd public && python -m SimpleHTTPServer \$PORT"

しかし,せっかくシンプルだが高性能な Web サーバー である hugo があるのに,それを使わない手はありません。ということで,ここを hugo server を使うように書き換えます。ついでに,baseUrl と theme をそれぞれ環境変数 HUGO_BASE_URL, HUGO_THEME から取得するようにしました。

https://github.com/nota-ja/heroku-buildpack-hugo/commit/d155fbccdd2cdb87ce18fd83f74ca0f73471a194

 cat << EOF
 ---
 default_process_types:
-  web: "cd public && python -m SimpleHTTPServer \$PORT"
+  web: "./hugo server --baseUrl=\$HUGO_BASE_URL --bind=0.0.0.0 --port=\$PORT --appendPort=false --log=true --theme=\$HUGO_THEME"
 EOF

2.3. テーマのコード内のパスを修正

Golang の net/url に存在する問題 により,Golang で書いたプログラムでは,パス部分の先頭に // がある URL が正常に解釈されません。 Cloud Foundry の Gorouter もその影響を受ける ため,該当 URL のリダイレクトに失敗します。

本質的な解決は Golang 自体の修正を待つしかないので,workaround として URL に // が含まれないよう,該当箇所を修正することにしました。調査の結果,該当箇所は,今回 Hugo のテーマとして使っている material-design 内にあることがわかったので,そこを全て修正しました。

具体的な修正内容については以下の URL をご覧ください (修正箇所が多く,かつ単純なので,ここに記載するよりリンク先を見ていただいた方が良いと判断しました)。

https://github.com/nota-ja/material-design/commit/4c96e2b868ca938855ab39f0747a4ae0c20ffb33

2.4. その他 optional だが利便性向上のためのカスタマイズ

.cfignore の追加

不要なファイルが Cloud Foundry にアップロードされるのを避けるため,cfignore を追加しました。

$ cat .cfignore
/public
*~
.*~

manifest.yml の追加

今回,push前/push時の設定が多い (buidlpack 及び環境変数 HUGO_BASE_URL, HUGO_THEME) ので,manifest.yml にまとめました。

$ cat manifest.yml
---
applications:
  - name: hugo-example
    domain: 10.244.0.34.xip.io
    buildpack: "https://github.com/nota-ja/heroku-buildpack-hugo.git#cf-100-day-challenge-088"
    env:
      HUGO_BASE_URL: http://hugo-example.10.244.0.34.xip.io
      HUGO_THEME: material-design

3. Cloud Foundry へのデプロイ

以上で準備が整ったので,Cloud Foundry にデプロイします。manifest.yml があるので, cf push だけで OK です。

$ cf push
Using manifest file /home/nota-ja/repos/cf-hugo-example/manifest.yml

Creating app hugo-example in org nota-ja / space prod as nota-ja...
OK
..
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: hugo-example.10.244.0.34.xip.io
last uploaded: Tue Oct 27 18:42:13 UTC 2015
stack: cflinuxfs2

     state     since                    cpu    memory        disk      details
#0   running   2015-10-28 03:42:32 AM   0.0%   30M of 256M   0 of 1G

起動しました。メモリはデフォルトの 256MB のままにしていますが,減らしても良さそうです。

4. 動作確認

ブラウザーでアクセスしてみた時のトップ画面はこんな感じです:

各ページを表示させてみます:

画像も表示されていることを確認しました:

以上で動作確認は終わりです。

5. まとめ

「静的サイト・ジェネレーター」シリーズ第2弾,今回は Hugo サイトを生成&表示してみました。

本記事では heroku-buildpack-hugo をカスタマイズし, hugo 自身を使ってサイトを serveしました。カスタマイズの結果,ステージング時と起動時の2回,サイトのビルドが行われることになってしまいました。Hugo はサイトのビルドが非常に高速なので,起動時のビルド自体は問題ないと考えているのですが,ステージング時に無駄にビルドしているのが少し気になっています。気が向いたらその辺の修正を行うかもしれませんが,今回はここまでとしたいと思います。

今回使用したソフトウェア

2015-10-27

Jekyll を Cloud Foundry で動かす

「Cloud Foundry 百日行」第87日目,今日から3日間は,少し趣向を変えて「静的サイト・ジェネレーター」を Cloud Foundry 上で動かしてみたいと思います。

「静的サイト」であれば,手元で生成して staticfile-buildpack を使えばそれで終わりなのですが,このシリーズでは生成も Cloud Foundry 上で行うという趣旨で, Jekyll, Hugo, Sphinx の3つを紹介していきます。

今回はまず,blog のツールとしても多く使われている Jekyll を取り上げます。

基本情報

手順の概要は以下の通りです。

  • 1) 静的サイトのサンプルの取得
  • 2) Cloud Foundry 向けの設定
  • 3) Cloud Foundry へのデプロイ
  • 4) 動作確認
  • 5) まとめ

1. 静的サイトのサンプルの取得

当たり前の話ですが,今回は Jekyll を Cloud Foundry にデプロイするわけではなく,Jekyll で生成したサイトをデプロイするので,生成対象のサンプルが必要です。もともとこの百日行シリーズの記事は Jekyll を使って HTML を生成していたので,今回はそこから冒頭の2記事をサンプルとして使うことにしました。

サンプルは GitHub に置いてあるので,試してみられる方は以下の手順で clone して,ディレクトリーを移動してください。

$ git clone https://github.com/nota-ja/cf-jekyll-example.git
..
$ cd cf-jekyll-example/

2. Cloud Foundry 向けの設定

今回のデプロイでは,

  • heroku-buildpack-ruby-jekyll でコンテンツを生成した後,
  • staticfile-buildpack で nginx を使って静的コンテンツを serve する

という方法をとります。

heroku-buildpack-ruby-jekyll 単体でも,Ruby の Web サーバーを使えば静的コンテンツの serve はできるのですが,

  • さまざまな方法を試したい
  • サーバーの性能的には nginx の方が有利

という考えで,こうなりました。

複数の buildpack を使うので, heroku-buildpack-multi も使います。

では,順次見ていきましょう。

2.1. heroku-buildpack-multi 用の設定

.buildpacks ファイルを作り,以下の内容を記述します。

$ cat .buildpacks
https://github.com/nota-ja/heroku-buildpack-ruby-jekyll#update
https://github.com/cloudfoundry/staticfile-buildpack

最初の buildpack は, heroku-buildpack-ruby-jekyll を fork して jekyll コマンド周りを更新したものです。

heroku 向けの Jekyll 用 buildpack は,上記も含め幾つか見つけたのですが,ステージング時にサイトの生成を行うシンプルなものは古いものが多く, 最新の jekyll gem ではエラーが起きてしまったので,fork してその部分だけ修正しました。修正したのは1行だけです。

$ git diff a4be7db dc20140
diff --git a/lib/language_pack/ruby.rb b/lib/language_pack/ruby.rb
index 5db862a..f3f2172 100644
--- a/lib/language_pack/ruby.rb
+++ b/lib/language_pack/ruby.rb
@@ -597,7 +597,7 @@ params = CGI.parse(uri.query || "")

   def generate_jekyll_site
     puts "Building jekyll site"
-    pipe("env PATH=$PATH bundle exec jekyll --no-server --no-auto 2>&1")
+    pipe("env PATH=$PATH bundle exec jekyll build 2>&1")
     unless $? == 0
       error "Failed to generate site with jekyll."
     end

2.2. staticfile-buildpack 用の設定

staticfile-buildpack を使うためには,detect スクリプトが成功するよう,Staticfile というファイルがディレクトリーのルートに存在する必要があります。通常は空のファイルが存在すれば良いのですが,jekyll コマンドでサイトを生成すると,_site というディレクトリー下にコンテンツが生成されるので,そこを serve するよう,staticfile-buildpack の機能を使って指定します。具体的には, staticfile-buildpack の README に従って,Staticfile 内に以下のような記述を行います。

$ cat Staticfile
root: _site

2.3. Staticfile を Jekyll のサイト生成対象から除外

この記事を読んでいる方の多くは Jekyll に慣れた方だと思うので,釈迦に説法ではあるかと思いますが,Jekyll はサイト生成の際,名前が _ 及び . で始まるもの以外の全てのファイル/ディレクトリーをサイト生成の対象にしようとします。したがって, bundle install を使って Gemfile 内の gem を vendor/bundle にインストールしてから jekyll でサイトの生成を行う今回のようなケースでは,vendor ディレクトリーや Gemfile, Gemfile.lock 等のファイルをサイト生成の対象から除外する必要があります。具体的には,_config.yml の exclude に除外対象のファイル/ディレクトリーの名前を記述しておきます。

今回,前項で新たに Staticfile というファイルを作りましたが,これも静的サイトとして serve するべきではないので,_config.yml の exclude にこれを追加します。

$ git diff -- _config.yml
diff --git a/_config.yml b/_config.yml
index efba535..8f716d5 100644
--- a/_config.yml
+++ b/_config.yml
@@ -16,4 +16,4 @@ markdown: kramdown
 kramdown:
   input: GFM

-exclude: [vendor, Gemfile, Gemfile.lock]
+exclude: [vendor, Gemfile, Gemfile.lock, Staticfile]

2.4. .cfignore の追加

ローカルで jekyll build を行ったりした場合,Cloud Foundry 上でのデプロイには不要なファイルが生成されます。これらをいちいちデプロイ前に削除するのも面倒なので,.cfignore ファイルを書いて cf push 時にアップロードされないようにします。

$ cat .cfignore
_site
.sass-cache
/vendor/bundle/
/.bundle/

3. Cloud Foundry へのデプロイ

以上で準備が整ったので,Cloud Foundry にデプロイします。Buildpack として heroku-buildpack-multi を指定するのを忘れないようにしてください。

$ cf push jekyll-example -b https://github.com/ddollar/heroku-buildpack-multi.git
Creating app jekyll-example in org nota-ja / space prod as nota-ja...
OK
..
1 of 1 instances running
 
App started
 
 
OK
 
App jekyll-example was started using this command `sh boot.sh`
 
Showing health and status for app jekyll-example in org nota-ja / space prod as nota-ja...
OK
 
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: jekyll-example.10.244.0.34.xip.io
last uploaded: Fri Oct 23 12:17:08 UTC 2015
stack: cflinuxfs2
 
     state     since                    cpu    memory        disk      details
#0   running   2015-10-23 09:19:24 PM   0.0%   24M of 256M   0 of 1G

起動しました。メモリはデフォルトの 256MB のままにしていますが,これより少なくても良さそうです。

4. 動作確認

ブラウザーでアクセスした時のトップ画面はこんな感じです:

各ページを表示させてみます:

画像も表示されていることを確認しました:

以上で動作確認は終わりです。

5. まとめ

「静的サイト・ジェネレーター」シリーズ第1弾,まずは Jekyll で生成したサイトをデプロイしてみました。

今回は heroku-buildpack-multi を使って nginx による serve を試しましたが,それほど負荷の大きくないサイトであれば,Ruby の Web サーバーを使った方がシンプルにデプロイできると思います。実際, このページの “Setting Up rack-jekyll” を参考にセットアップを行ってデプロイを試してみましたが,問題なく動作しました。文末にそのコミットへのリンクも記載しているので,興味のある方は試してみてください。

今回使用したソフトウェア

2015-10-26

GroupSession を Cloud Foundry で動かす

「Cloud Foundry 百日行」第86日目は、日本トータルシステム株式会社が開発した国産グループウェア製品GroupSession です。

GroupSession の ライセンス は,厳密には The Open Source Initiative の定める The Open Source Definition (日本語訳) から外れている可能性がありますが、ソースコードが公開されており、独自にカスタムが可能で、グループウェアとしての機能が十分に備わったアプリケーションです。

基本情報

手順の概要は以下の通りです。

  • 1) ソースコードの取得
  • 2) アプリの起動
  • 3) 動作確認
  • 4) 補足情報

1. ソースコードの取得

Download URLにアクセスし
記事執筆時点の最新版である”Ver4.5.4”のwarファイルをダウンロードします。

$ mkdir groupsession
$ cd groupsession
$ wget http://dl1.gs.sjts.co.jp/v4/download/files/4.5.4/gsession.war

2. アプリの起動

検証時にメモリ使用量を確認した際に450MB程の使用量で有った為、念の為メモリ指定を1Gに指定してアプリをpushします。

$ cf push gsession -m 1G -p gsession.war

:

App started


OK

App gsession was started using this command `JAVA_HOME=$PWD/.java-buildpack/open_jdk_jre JAVA_OPTS="-buildpack/open_jdk_jre/bin/killjava.sh -Xmx768M -Xms768M -XX:MaxMetaspaceSize=104857K -XX:Metaspaceport=$PORT" $PWD/.java-buildpack/tomcat/bin/catalina.sh run`

Showing health and status for app gsession in org morika-t / space morika-t as morika-t...
OK

requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: gsession.10.244.0.34.xip.io
last uploaded: Thu Oct 15 06:51:45 UTC 2015
stack: cflinuxfs2
buildpack: java-buildpack=v3.0-https://github.com/cloudfoundry/java-buildpack.git#3bd15e1 open-jdk-jmcat-instance=8.0.27 tomcat-lifecycle-support=2.4.0_RELEASE tomcat-logging-support=2.4.0_RELEASE

     state     since                    cpu    memory         disk      details
#0   running   2015-10-15 03:53:12 PM   3.4%   650.9M of 1G   0 of 1G

成功しました。

3. 動作確認

GroupSessionの運用前設定に記載の設定用管理者ユーザの情報を元にブラウザーでアクセスし、IDとPASS共に”admin”を入力しログインします。

ログイン後:

4. 補足情報

今回のアプリは、データベースとして『H2 Database Engine』を使用しています。
データはファイルとして保存されるようになっている為、アプリが再起動すると登録したデータが消えてしまいます。

GroupSessionのソースコードを入手し、H2 Databaseを別のサーバ上に立ててリモート接続を行う方法や、こちらに記載されている内容のようにPostgreSQL対応の実装を追加する事で、PaaS上での利用として実用可能なレベルになると思われますが、まずは手軽にグループウェアとして試したいという際には非常に簡単に起動させる事が出来るのでオススメです。

今回使用したソフトウェア



投稿者:NTTソフトウェア株式会社 森川 健

2015-10-23

mViewer を Cloud Foundry で動かす

「Cloud Foundry 百日行」第85日目、本日は Mongo DB の管理ツール mViewer です。

Mongo DB については、この百日行では、 第68日目 に Cloud Foundry 上で動く Mongo DB のサービスブローカ spring-boot-cf-service-broker-mongo を紹介しました。そして、それを使ってデプロイするアプリの例として、 PullUp 等も取り上げました。そんな中、Mongo DB を使い始めたら欲しくなってくるのが、その Mongo DB を Web で簡単に管理できるツールですね。Mongo DB の管理ツールは沢山出回っています( MongoDB Admin UIs )。その中で、本日の mViewer は、手軽にすぐに使える便利な OSS になっています。

基本情報

手順の概要は以下の通りです。

  • 1) ソースコードの取得
  • 2) アプリのデプロイ
  • 3) 動作確認

1. ソースコードの取得

まずはソースコードを取得します。

~$ git clone https://github.com/Imaginea/mViewer
~$ cd mViewer/
~/mViewer$ ls
build.xml  LICENSE.txt  mViewer.properties  pom.xml  README.md  scripts  src  target

src ディレクトリの中を探っていくと、これは Java のアプリであることがわかります。

2. アプリのデプロイ

Deploying to Other Servlet-Containers によると、 Apache Maven を使って、WAR ファイルを作り、 tomcat 7x 上にデプロイするとのこと。Cloud Foundry へのデプロイの場合は、アプリケーションサーバを特に気にすることは無いので、WAR ファイルを作り、デプロイを進めて行きましょう。

2.1 WAR ファイルの作成

Deploying to Other Servlet-Containers の手順に従って、 mvn clean package を実行します。

~/mViewer$ mvn clean package
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building mViewer 0.9.2
[INFO] ------------------------------------------------------------------------
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom (4 KB at 5.6 KB/sec)

:

Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-api/2.14/surefire-api-2.14.jar (153 KB at 653.4 KB/sec)
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/maven-surefire-common/2.14/maven-surefire-common-2.14.jar (228 KB at 632.4 KB/sec)
[INFO] Tests are skipped.
[INFO] 
[INFO] --- maven-war-plugin:2.2:war (default-war) @ mViewer ---
[INFO] Packaging webapp
[INFO] Assembling webapp [mViewer] in [/home/ueno/mViewer/target/mViewer-0.9.2]
[INFO] Processing war project
[INFO] Copying webapp resources [/home/ueno/mViewer/src/main/webapp]
[INFO] Webapp assembled in [495 msecs]
[INFO] Building war: /home/ueno/mViewer/target/mViewer-0.9.2.war
[INFO] WEB-INF/web.xml already added, skipping
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23.861s
[INFO] Finished at: Tue Aug 25 20:29:41 JST 2015
[INFO] Final Memory: 17M/194M
[INFO] ------------------------------------------------------------------------

ビルドが成功しました。

target ディレクトリ配下に WAR ファイルが生成されているかどうか、確認します。

~/mViewer$ ls target
classes  generated-sources  generated-test-sources  maven-archiver  mViewer-0.9.2  mViewer-0.9.2.war  test-classes

mViewer-0.9.2.war が生成されています。

2.2 Mongo DB サービスの作成とバインド

まずは --no-start で生成された WAR ファイルをプッシュしておきます。特定のファイルやディレクトリを指定してデプロイするには、 -p のオプションを使います。

~/mViewer$ cf push mviewer -p target/mViewer-0.9.2.war --no-start
Creating app mviewer in org ueno / space test1 as ueno...
OK
 
Creating route mviewer.10.244.0.34.xip.io...
OK
 
Binding mviewer.10.244.0.34.xip.io to mviewer...
OK
 
Uploading mviewer...
Uploading app files from: target/mViewer-0.9.2.war
Uploading 8.7M, 790 files
Done uploading               
OK

続いて、作成する Mongo DB サービスのブローカをまず確認します。

~/mViewer$ cf marketplace
Getting services from marketplace in org ueno / space test1 as ueno...
OK
 
service      plans                     description   
Mongo DB     Default Mongo Plan*       A simple mongo implementation   
PostgreSQL   Basic PostgreSQL Plan*    PostgreSQL on shared instance.   
p-mysql      100mb, 1gb                MySQL databases on demand   
p-redis      shared-vm, dedicated-vm   Redis service to provide a key-value store   
 
* These service plans have an associated cost. Creating a service instance will incur this cost.
 
TIP:  Use 'cf marketplace -s SERVICE' to view descriptions of individual plans of a given service.

Mongo DB が登録されていますね。
ではこれを使って、サービス mongodb01 を作成します。

~/mViewer$ cf cs 'Mongo DB' 'Default Mongo Plan' mongodb01
Creating service instance mongodb01 in org ueno / space test1 as ueno...
OK
 
Attention: The plan `Default Mongo Plan` of service `Mongo DB` is not free.  The instance `mongodb01` will incur a cost.  Contact your administrator if you think this is in error.

上記で cf cs ... とありますが、これは、 cf create-service ... と同じです。タイピングが短くて済みますね。

では、アプリ mviewer とサービス mongodb01 をバインドします。

~/mViewer$ cf bs mviewer mongodb01
Binding service mongodb01 to app mviewer in org ueno / space test1 as ueno...
OK
TIP: Use 'cf restage mviewer' to ensure your env variable changes take effect

2.3 アプリの起動

ではアプリを起動します。
既に --no-start でデプロイした状態であるので、 restart して起動します。

~/mViewer$ cf restart mviewer
Starting app mviewer in org ueno / space test1 as ueno...
-----> Downloaded app package (5.3M)
-----> Java Buildpack Version: v3.0 | https://github.com/cloudfoundry/java-buildpack.git#3bd15e1
-----> Downloading Open Jdk JRE 1.8.0_60 from https://download.run.pivotal.io/openjdk/trusty/x86_64/openjdk-1.8.0_60.tar.gz (2.7s)
       Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (0.9s)
-----> Downloading Tomcat Instance 8.0.26 from https://download.run.pivotal.io/tomcat/tomcat-8.0.26.tar.gz (1.0s)
       Expanding Tomcat to .java-buildpack/tomcat (0.1s)
-----> Downloading Tomcat Lifecycle Support 2.4.0_RELEASE from https://download.run.pivotal.io/tomcat-lifecycle-support/tomcat-lifecycle-support-2.4.0_RELEASE.jar (0.1s)
-----> Downloading Tomcat Logging Support 2.4.0_RELEASE from https://download.run.pivotal.io/tomcat-logging-support/tomcat-logging-support-2.4.0_RELEASE.jar (0.0s)
-----> Downloading Tomcat Access Logging Support 2.4.0_RELEASE from https://download.run.pivotal.io/tomcat-access-logging-support/tomcat-access-logging-support-2.4.0_RELEASE.jar (0.0s)
 
-----> Uploading droplet (56M)
 
1 of 1 instances running
 
App started
 
 
OK
 
App mviewer was started using this command `JAVA_HOME=$PWD/.java-buildpack/open_jdk_jre JAVA_OPTS="-Djava.io.tmpdir=$TMPDIR -XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh -Xmx160M -Xms160M -XX:MaxMetaspaceSize=64M -XX:MetaspaceSize=64M -Xss853K -Daccess.logging.enabled=false -Dhttp.port=$PORT" $PWD/.java-buildpack/tomcat/bin/catalina.sh run`
 
Showing health and status for app mviewer in org ueno / space test1 as ueno...
OK
 
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: mviewer.10.244.0.34.xip.io
last uploaded: Tue Sep 29 06:14:31 UTC 2015
stack: cflinuxfs2
buildpack: java-buildpack=v3.0-https://github.com/cloudfoundry/java-buildpack.git#3bd15e1 open-jdk-jre=1.8.0_60 tomcat-access-logging-support=2.4.0_RELEASE tomcat-instance=8.0.26 tomcat-lifecycle-support=2.4.0_RELEASE tomcat-logging-support=2.4.0_RELEASE
 
     state     since                    cpu    memory           disk      details   
#0   running   2015-09-29 03:16:05 PM   0.0%   166.4M of 256M   0 of 1G  

無事、アプリが起動しました。

3. 動作確認

ブラウザからアプリにアクセスします。

Mongo DB へ接続するための情報を入力する必要があるので、まずは環境変数に格納されている情報を取得します。

~/mViewer$ cf env mviewer
Getting env variables for app mviewer in org ueno / space test1 as ueno...
OK
 
System-Provided:
{
 "VCAP_SERVICES": {
  "Mongo DB": [
   {
    "credentials": {
     "uri": "mongodb://b78942cd-54b8-4996-81c7-016c00c5be7e:password@192.168.15.91:27017/29b47616-2f6c-43fb-b84b-2d8321392382"
    },
    "label": "Mongo DB",
    "name": "mongodb01",
    "plan": "Default Mongo Plan",
    "tags": [
     "mongodb",
     "document"
    ]
   }
  ]
 }
}

:
 

上記の Mongo DB の URL である mongodb://b78942cd-54b8-4996-81c7-016c00c5be7e:password@192.168.15.91:27017/29b47616-2f6c-43fb-b84b-2d8321392382 の箇所から、 mongodb://<Username>:<Password>@<Host>:<Port>/<Databases> のフォーマットに従い、それぞれの情報を抜き出します。

Host → 192.168.15.91
Port → 27017
Username → b78942cd-54b8-4996-81c7-016c00c5be7e
Password → password
Databases → 29b47616-2f6c-43fb-b84b-2d8321392382

これらの情報を画面に入力して、 Connect をクリックすると、

DB に接続できました。

Mongo DB なので、JSON 形式で DB の情報が登録されています。

DB 追加してみます。
左側にある「+」のボタンをクリックし、DB test01 を追加します。

DB test01 が追加され、DB 情報が表示されています。

DB test01 にコレクション col01 を追加します。

コレクション col01 にドキュメント {"name":"taro"} を追加します。

ドキュメント {"name":"taro"} が登録されて表示されています。

Server Statistics をクリックすると、ホストの情報が表示されます。

Mongo Graphs をクリックすると、DB に対して query 実行されている状況がコマンド毎にグラフ表示されています。

このアプリを更に使っていきたい読者は、 ドキュメント を参考にしてください。

まとめ

本日は、Mongo DB 管理ツール mViewer を取り上げました。アプリ自体は Java 製でしたが、Cloud Foundry へのデプロイは、ローカルで WAR ファイルを作成してからそれをプッシュ、Mongo DB サービスとバインドしてからアプリ再起動、という比較的簡単な手順でした。手軽にデプロイして、Web 上で Mongo DB をビジュアルに管理できる、という素敵なアプリ。今後も是非活用してください。

今回使用したソフトウェア

2015-10-22

Fat Free CRM を Cloud Foundry で動かす

「Cloud Foundry 百日行」第84日目,今日は SugarCRM (記事URL) 以来の CRM アプリ Fat Free CRM です。「Sugar」に対抗して「Fat Free」という名前の通り,シンプルさが特徴の CRM のようですが,CRM に詳しくない自分にとっては充分多機能に見えました。

Ruby on Rails ベースのアプリで, Heroku でのデプロイも考慮されている ので,Cloud Foundry でも簡単に動かす事ができました。

基本情報

手順の概要は以下の通りです。

  • 1) ソースコードの取得
  • 2) 起動スクリプトの作成
  • 3) サービスの作成とバインド
  • 4) アプリのデプロイ
  • 5) 動作確認

1. ソースコードの取得

GitHub からソースコードを clone して,ディレクトリーを移動します。

$ git clone https://github.com/fatfreecrm/fat_free_crm.git
..
$ cd cd fat_free_crm/

2. 起動スクリプトの作成

http://guides.fatfreecrm.com/Setup-Heroku.html の「Set up a Fat Free CRM Instance on Heroku」に合わせて起動スクリプトを作成します。

このアプリには Procfile があるので,それを使えばよさそうに見えますが,上のページを読むと,アプリの起動前に

heroku run rake db:migrate
heroku run rake ffcrm:demo:load (if you want demo data)
heroku run rake ffcrm:setup:admin USERNAME=admin PASSWORD=admin EMAIL=admin@example.com

の3つの操作が行われています。 Cloud Foundry には, heroku run に相当する機能がないので,これらは起動時にまとめて実行する必要があります。Procfile を変更する方法もあるのですが,起動スクリプトの方がデバッグがしやすいので,私はそちらを好んで用いています。

最終的な起動スクリプト (ファイル名は start.sh) は以下のようになりました。

$ emacs start.sh
..
$ cat start.sh
#!/bin/bash
 
set -x
 
bundle exec rake db:migrate
bundle exec rake ffcrm:demo:load
bundle exec rake ffcrm:setup:admin USERNAME=admin PASSWORD=admin EMAIL=admin@example.com

bundle exec unicorn -p $PORT -c ./config/unicorn.rb

【注記】

なお, bundle exec rake ffcrm:demo:load はデータベースを初期化してしまうので,実用に供する場合はこの行を削除してください。

3. サービスの作成とバインド

本アプリはデータの永続化に DBMS を使います。 http://guides.fatfreecrm.com/Setup-Linux-or-Mac-OS.html の「Set Up Configuration (Database & Settings)」を読むと,対応しているデータベースは PostgreSQL, MySQL, SQLite の3つですが,ソースコードの config.rake というファイルを見ると,

      filename = "config/database.#{ENV['DB'] || 'postgres'}.yml"

となっていて,デフォルトでは PostgreSQL を使うことを想定しているようなので,今回は PostgreSQL を使うことにしました。

以下,いつものように,アプリのアップロード→サービスの作成→アプリとサービスのバインドという手順を実施します。

アプリのアップロード

アプリを停止状態で Cloud Foundry 上に push します。アプリ名は ffcrm としました。

$ cf push ffcrm --no-start
Creating app ffcrm in org nota-ja / space 100 as nota-ja...
..
Done uploading
OK

サービスの作成

PostgreSQL サービスを作成します。サービス・インスタンス名は pg-ffcrm としました。

$ cf create-service PostgreSQL "Basic PostgreSQL Plan" pg-ffcrm
Creating service instance pg-ffcrm in org nota-ja / space 100 as nota-ja...
OK
..

サービスのバインド

アプリとサービスをバインドします。

$ cf bind-service ffcrm pg-ffcrm
Binding service pg-ffcrm to app ffcrm in org nota-ja / space 100 as nota-ja...
OK
..

今回のアプリではサービスの auto-reconfiguration が機能するので,接続情報を別途ファイルや環境変数に転記する必要はありません。

4. アプリのデプロイ

準備が整ったので,アプリをデプロイします。

調査の結果,

  • メモリを少し多めに取った方が良さそう
  • デモデータのロードに時間がかかるので,タイムアウトを長めに取る必要がある

ということがわかったので,push コマンドのオプションは以下のようになりました。

$ cf push ffcrm -c './start.sh' -m 384m -t 180
Updating app ffcrm in org nota-ja / space 100 as nota-ja...
OK`
..
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running

App started


OK

App ffcrm was started using this command `./start.sh`

Showing health and status for app ffcrm in org nota-ja / space 100 as nota-ja...
OK

requested state: started
instances: 1/1
usage: 384M x 1 instances
urls: ffcrm.10.244.0.34.xip.io
last uploaded: Wed Oct 21 06:16:04 UTC 2015
stack: cflinuxfs2
buildpack: Ruby

     state     since                    cpu     memory           disk      details
#0   running   2015-10-21 03:18:48 PM   34.1%   210.9M of 384M   0 of 1G

先ほど述べたように,起動に時間がかかるため, 0 of 1 instances running, 1 starting が続いてドキドキしますが,しばらくすると起動するはずです。

【注記】

この cf push の最中に,以下の2種類のメッセージが出力されると思いますが,

       fatal: Not a git repository (or any of the parent directories): .git
       rake aborted!
       PG::ConnectionBad: could not connect to server: Connection refused
       Is the server running on host "192.168.15.91" and accepting
       TCP/IP connections on port 5432?
       /tmp/staged/app/vendor/bundle/ruby/2.2.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:655:in `initialize'
..

両方ともアプリのデプロイ/実行上問題にはなりません。

前者については,bundle コマンドが実行される際,fat_free_crm.gemspec ファイルが評価されて,その中の

https://github.com/fatfreecrm/fat_free_crm/blob/0424d3ee1d9073f322d60a4b97d71dfc703a16a4/fat_free_crm.gemspec#L12

  gem.files = `git ls-files`.split("\n")

という行で git コマンドが実行されることが原因なのですが,この gemspec ファイルは Cloud Foundry 上でアプリをデプロイする際は使われていないので,このメッセージを気にする必要はありません。

実際,Fat Free CRM の Issues でも何度か取り上げられていますが,

  • https://github.com/fatfreecrm/fat_free_crm/issues/389
  • https://github.com/fatfreecrm/fat_free_crm/issues/352

アプリの作者側はこのメッセージを問題視していないようです。

後者のデータベース接続エラーも,やはり無視しても大丈夫です。

このエラーは,アプリのステージング中にデータベースに接続しようとして, Cloud Foundry の Application Security Group 設定で接続が許可されていないために発生しているものです。しかし,今回データベース周りの処理はアプリの起動時に行っているので,ステージング時にデータベース接続できなくても問題ありません。

5. 動作確認

アプリ起動後,ブラウザーでアプリのURLにアクセスすると,ログイン画面に遷移するので,ユーザー名とパスワードを入力してログインします:

ユーザー名とパスワードは,start.sh の以下の行に書いたものを使います:

bundle exec rake ffcrm:setup:admin USERNAME=admin PASSWORD=admin EMAIL=admin@example.com

ログインに成功すると以下の画面ような画面になります:

【Campaigns】タブを表示させてみました:

【Tasks】タブに移動して【Create new task】をクリックし:

新しいタスクを作ってみます:

タスクが作られました:

タスク名の左のチェックボックスにチェックを入れるとタスクは自動的に消えます:

左ペインの【Completed】をクリックすると,完了したタスクが表示されます:

以上で動作確認は終わりです。

Heroku へのデプロイ手順が提供されているだけあって,Cloud Foundry でも簡単に動きました。データベース接続も自動設定で済むので,本当に簡単です。

今回使用したソフトウェア

2015-10-21

Brackets を Cloud Foundry で動かす

「Cloud Foundry 百日行」第83日目は、プレビュを見ながらHTML/JS/CSSを編集できるWebデザイン用エディタBracketsです。IDEほどの機能はありませんが、コードヒントが出たり構文エラー時にアラートが出たりと、シンプルですが使いやすいエディタだと思います。
Bracketsは、nodejs-buildpackを使ってCF上で動かすことも出来ますが、ソースへの修正が多少必要であることと、Brackets自体がHTML/JS/CSSで出来たアプリであるため、今回はシンプルにstaticfile-buildpackで起動してみました。

基本情報

デプロイ準備から動作確認までの手順は以下の通りです。

  • 1) ソースの取得
  • 2) ビルド準備
  • 3) アプリのビルド
  • 4) デプロイ準備
  • 5) デプロイ
  • 6) 動作確認

1. ソースの取得

Bracketsのソースを、GitHubから取得します。
submoduleがあるので、--recursiveをつけてgit cloneして下さい。

$ git clone https://github.com/humphd/brackets.git --recursive
$ cd brackets/
brackets$ ls
CONTRIBUTING.md  Gruntfile.js  NOTICE        README.md  src    test
env.dist         LICENSE       package.json  samples    tasks  tools

2. ビルド準備

まずは作業環境にnpmgruntをインストールします。
先に、npmコマンドをインストールします。

brackets$ sudo apt-get install nodejs

次に、npmコマンドを使ってgruntコマンドをインストールします。

brackets$ sudo npm install -g grunt-cli
brackets$ grunt -v
grunt-cli: The grunt command line interface. (v0.1.13)
:

3. アプリのビルド

READMEに従って、npmコマンドとgruntコマンドを使ってアプリをビルドします。

brackets$ npm install
:
Running "less:dist" (less) task
File src/styles/brackets.min.css created.

Done, without errors.
brackets$ grunt build-browser
Running "jshint:src" (jshint) task
>> 363 files lint free.
:
Done, without errors.

ビルドが完了し、作成されたdistディレクトリに以下のようなファイルが出来ていれば成功です。

brackets$ ls dist
bramble.js   dependencies.js  hosted.html  index.html       main.js  styles      xorigin.js
config.json  extensions       hosted.js    LiveDevelopment  nls      thirdparty

4. デプロイ準備

アプリのビルドが完了したら、デプロイに必要な設定ファイルを作成していきます。
まずは、staticfile_buildpack用の設定です。staticfile_buildpackREADMEを確認すると、アプリのルートフォルダを指定したい場合、Staticfileファイルで定義することができるようです。
本アプリは、ビルドで作成されたdistがルートフォルダとなるため、以下のように指定します。

brackets$ vi Staticfile
root: dist

次に、デプロイ用のマニフェストを作成します。

brackets$ vi manifest.yml
applications:
- name: brackets
  buildpack: staticfile_buildpack

マニフェストは、buildpack:指定のみです。
今回は、CF環境に標準で含まれているAdmin Buildpackのstaticfile_buildpackを使うので、URLではなくBuildpack名を指定します。
Buildpack名については、cf buildpacksコマンドで確認することができます。

brackets$ cf buildpacks
Getting buildpacks...

buildpack              position   enabled   locked   filename
staticfile_buildpack   1          true      false    staticfile_buildpack-cached-v1.0.0.zip
java_buildpack         2          true      false    java-buildpack-v3.0.zip
ruby_buildpack         3          true      false    ruby_buildpack-cached-v1.4.2.zip
nodejs_buildpack       4          true      false    nodejs_buildpack-cached-v1.3.1.zip
go_buildpack           5          true      false    go_buildpack-cached-v1.3.1.zip
python_buildpack       6          true      false    python_buildpack-cached-v1.3.2.zip
php_buildpack          7          true      false    php_buildpack-cached-v3.2.1.zip
binary_buildpack       8          true      false    binary_buildpack-cached-v1.0.0.zip

上記までの設定で、ひとまずアプリのデプロイは成功します。しかし、Bracketsのトップページファイルはhosted.htmlという名前であるため、払いだされたアプリのURLへアクセスすると以下のようなページが表示され、直接アクセスできません。

そのため、staticfile_buildpackが起動するNginxの設定を変更することで、hosted.htmlがトップページとして表示されるようにしていきます。
staticfile_buildpackREADMEを確認すると、ルートフォルダにnginx.confを置いておくと、そちらの設定が優先されるようです。
そこで、staticfile-buildpackのリポジトリで管理しているnginx.confをGitHubから取得しdistフォルダに置き、indexの設定にhosted.htmlを追加します。

brackets$ vi dist/nginx.conf
worker_processes 1;
daemon off;

error_log <%= ENV["APP_ROOT"] %>/nginx/logs/error.log;
events { worker_connections 1024; }

http {
  log_format cloudfoundry '$http_x_forwarded_for - $http_referer - [$time_local] "$request" $status $body_bytes_sent';
  access_log <%= ENV["APP_ROOT"] %>/nginx/logs/access.log cloudfoundry;
  default_type application/octet-stream;
  include mime.types;
  sendfile on;
  gzip on;
  tcp_nopush on;
  keepalive_timeout 30;
  port_in_redirect off; # Ensure that redirects don't include the internal container PORT - <%= ENV["PORT"] %>

  server {
    listen <%= ENV["PORT"] %>;
    server_name localhost;

    location / {
      root <%= ENV["APP_ROOT"] %>/public;
      index hosted.html index.html index.htm Default.htm;  # ← ここに hosted.html を追加
      <% if File.exists?(File.join(ENV["APP_ROOT"], "nginx/conf/.enable_directory_index")) %>
      autoindex on;
      <% end %>
      <% if File.exists?(auth_file = File.join(ENV["APP_ROOT"], "nginx/conf/.htpasswd")) %>
      auth_basic "Restricted";                                #For Basic Auth
      auth_basic_user_file <%= auth_file %>;  #For Basic Auth
      <% end %>
      <% if ENV["FORCE_HTTPS"] %>
      if ($http_x_forwarded_proto = http) {
        return 301 https://$host$request_uri;
      }
      <% end %>
    }
  }
}

これで、デプロイ準備は完了です。

4. デプロイ

デプロイ準備が完了したら、cf pushします。

brackets$ cf push
:
1 of 1 instances running

App started


OK

App brackets was started using this command `sh boot.sh`

Showing health and status for app brackets in org horiu-jn / space horiu-jn as horiu-jn...
OK

requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: brackets.10.244.0.34.xip.io
last uploaded: Mon Oct 19 08:21:23 UTC 2015
stack: cflinuxfs2
buildpack: staticfile_buildpack

     state     since                    cpu    memory          disk      details
#0   running   2015-10-19 05:21:52 PM   0.0%   54.4M of 256M   0 of 1G

無事、デプロイは成功しました。

7. 動作確認

ブラウザから払いだされたアプリのURLへアクセスすると、無事トップページであるhosted.htmlの画面が表示されました。

デフォルトでいくつかのファイルがすでに作成されています。
試しに、CSSファイルのstyle.cssを修正して、設定したスタイルをindex.htmlへ反映してみましょう。
ここでは、font-size:を追加し、color:を変更してみます。
お使いになるとすぐに分かると思いますが、キーを入力するとコードヒントが即座にでます。またcolor:の定義を変更してみると、色のサンプルも合わせて表示されます。

次に、index.htmlに修正したCSSファイルを指定します。
href属性にファイル名を指定の際、候補のファイル一覧が表示されるので便利です。

入力し終わると、画面右のサンプル表示部分の文字が、CSSで設定したスタイルに変更されたことが確認できます。

ここで、わざと誤った文法を入力してみると、警告の意味で行番号のバックが赤く表示されるのが分かります。

次に、index.htmlにイメージを挿入してみましょう。
今回は百日行第78日目で紹介しましたEtherDrawで描かれた名作を挿入してみます。
イメージファイルのアップロードは、画面左に表示されるファイル一覧にドラック&ドロップするだけで完了です。

index.htmlimgタグでアップロードしたイメージのファイル名を指定すると、画面右のサンプル表示部分に反映されます。

また、ファイルの作成・削除やディレクトリの作成などは、画面左のファイル一覧上で右クリックすることで行えます。

今回使用したソフトウェア



投稿者:NTTソフトウェア株式会社 堀内 純

2015-10-20

Wekanを Cloud Foundry で動かす

「Cloud Foundry 百日行」第82日目は、Meteor製アプリケーション第二弾のWekan(旧名: Libreboard) です。
WekanはオープンソースのTrello風かんばんアプリケーションです。
こちらも昨日のRocket.Chat同様に綺麗なUIで、閉じたNW内でTrelloのように管理をしたい時にお勧めなアプリケーションです。

基本情報

手順の概要は以下の通りです。

  • 1) ソースコードの取得
  • 2) 事前準備
  • 3) アプリの起動
  • 4) 動作確認

1. ソースコードの取得

$ git clone https://github.com/wekan/wekan
$ cd wekan

2. 事前準備

2.1. MongoDBのサービスインスタンス作成

$ cf create-service "Mongo DB" "Default Mongo Plan" wekan-mongo

2.2. アプリの事前push

buildpackのURLをapp.json(Heroku Button用の設定ファイル)から確認します。

$ cat app.json
  "env": {
      "BUILDPACK_URL": "https://github.com/AdmitHub/meteor-buildpack-horse.git",

-bで先ほど調べたbuildpackのURLを指定し、–no-startを指定します。

$ cf push wekan -b https://github.com/AdmitHub/meteor-buildpack-horse.git --no-start

2.3. サービスの紐付け

作成したサービスインスタンスをアプリに紐づけます

$ cf bind-service wekan wekan-mongo

2.4. 環境変数設定

紐づけたサービスの情報を得るために『cf env』を実行し、credentialsのuri部分をメモします。

$ cf env wekan
:
    "credentials": {
     "uri": "mongodb://68608217-650b-4b26-91df-e70ad5105a34:password@192.168.15.82:27017/f9d8d716-8426-42a6-bd62-585aecfe43d1"
    },

cf set-envでMONGO_URLという変数に先ほどメモしたcredentialsの値を設定します。

$ cf set-env wekan MONGO_URL "mongodb://68608217-650b-4b26-91df-e70ad5105a34:password@192.168.15.82:27017/f9d8d716-8426-42a6-bd62-585aecfe43d1"

cf set-envでROOT_URLという変数にアプリのURLと同じ値を設定します。

$ cf set-env wekan ROOT_URL https://wekan.10.244.0.34.xip.io

3. アプリの起動

$ cf start wekan
:
App started
 
 
OK
 
App wekan was started using this command `.meteor/heroku_build/bin/node .meteor/heroku_build/app/main.js`
 
Showing health and status for app wekan in org develop / space develop-space as admin...
OK
 
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: wekan.10.244.0.34.xip.io
last uploaded: Thu Sep 17 08:06:58 UTC 2015
stack: cflinuxfs2
buildpack: https://github.com/AdmitHub/meteor-buildpack-horse.git
 
     state     since                    cpu    memory           disk      details
#0   running   2015-09-17 05:15:12 PM   0.0%   152.2M of 256M   0 of 1G

成功しました。

4. 動作確認

ブラウザーでアクセス。
Sign up:

Sing in後:

ボードとリスト作成しカードを作成:

今回使用したソフトウェア