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

2015-11-16

Cloud Foundry 百日行 #100+1 結言

終わりに

6月4日に始まった「Cloud Foundry 百日行」も,本日ついに最終回を迎えました。オープンソースの PaaS である Cloud Foundry 上に,オープンソースのアプリケーションをデプロイしてみる営みを百日間にわたって続けるというこの企画,中休みを挟んだものの,記事を落とすことなく予定通り走り切れたのは,記事執筆に協力してくださった方々,記事を広めていただいた方々,読んでくださった方々,皆様のおかげだと思います。

終わりにあたって,このプロジェクトに関する数字を幾つか書いてみたいと思います。

成功/失敗

まず,デプロイに成功したアプリケーションは97件,失敗したアプリケーションは3件でした。失敗したアプリケーションに興味を持つ方がおられるかもしれないので,以下にリンクを示しておきます。

それぞれに「失敗」の理由は異なるのですが,特に Milkode などは Heroku では動いている ようですので,単純に時間と能力の不足で,もう少しその2つが足りていればデプロイは成功するのではないかと思います。

もちろん,デプロイに「成功」したアプリも,全ての機能が正常に動作することを確認したわけではないことは,一応申し添えておきます。

Buildpack

次に,アプリケーションのデプロイに使った buildpack の種類ごとの使用回数は以下の通りでした。

Buildpack 使用回数
Go 4
Java 8
Node.js 22
Null 1
PHP 22
Python 3
Ruby 21
Staticfile 16
https://github.com/Altoros/jenkins-buildpack 1
https://github.com/ddollar/heroku-buildpack-apt 4
https://github.com/ddollar/heroku-buildpack-multi 6
https://github.com/ihuston/ipython-notebook-buildpack 1
https://github.com/nota-ja/heroku-buildpack-hugo 1
https://github.com/nota-ja/heroku-buildpack-ruby-jekyll 1
https://github.com/AdmitHub/meteor-buildpack-horse 2
Total 113

複数の buildpack を使うアプリケーションがあったので,合計は 100 とは一致していません。傾向としては,20を超えている Node.js, PHP, Ruby が三強で,それに続くのが Staticfile というかたちでした。Java や Python, Go については,もう少し頑張りたかったという感じです。

サービス

また,サービスの種類ごとの使用回数は以下のようになりました。

Service 使用回数
MongoDB 8
MySQL 27
MySQL (ClearDB) 1
PostgreSQL 12
Redis 3
SendGrid 1
Total 55

複数のサービスを使うアプリケーションが3つあったので,サービスを使ったアプリケーションの総数は52で,全体の約半分がサービスを使うという結果になりました。傾向は,見てわかる通り MySQL の人気が圧倒的で,それに PostgreSQL が続きました。意外に多かったのが MongoDB, 逆に意外と少なかったのが Redis でした。

当初の目的についての振り返り

最後に, #000 序言 で挙げた3つの目的について,どれくらい達成できたかを簡単に評価します。とはいえ,数字での評価でなく,あくまで感想レベルです。

  1. Cloud Foundry の特徴を知ってもらう
    ブログのアクセス数は,百日行開始前と比べると大幅に増えたのですが,絶対値(秘密です)としてはまだまだという印象です
    力不足を痛感します
  2. アプリケーションを Cloud Foundry 上で動かす際,どのような点に留意すべきかを知る
    これについては,今回記事を書いたメンバーの間では,かなり理解が進んだと思います
    個人的にも,さまざまなアプリケーションについて,だいたいどうやれば動きそうかという推測が立てられるようになったように思います
  3. Cloud Foundry に対して,どのようなニーズ/要望があるかを知る
    残念ながら記事へのリアクションはあまり得られなかったのですが,自分たちがアプリケーションをデプロイする中で,「こういう部分を強化してほしい」というところは見えてきたように思います

ということで,目的の達成度としては道半ばの感はありますが,まずは百日の荒行は一区切りとなります。改めて,執筆に協力してくださった方々,記事を広めていただいた方々,読んでくださった方々,関わった皆様にお礼を申し上げたいと思います。ありがとうございました。

Administration Web UI for Cloud Foundry NG (admin-ui) を Cloud Foundry で動かす

「Cloud Foundry 百日行」最終日の第100日目は、Cloud Foundry公式の運用管理用Sinatraアプリ、Administration Web UI for Cloud Foundry NG (以後 admin-ui)です。
admin-uiは、Cloud Foundryの各コンポーネントへアクセスし、そこから収集した稼働状況などの各種情報を表示します。 また、Organization, Spaceの追加・削除や簡単なアプリ操作、Feature Flagsの変更なども行うことができます。
Cloud Foundry Incubatorリポジトリにあるインキュベーション扱いのツールですが、現段階でもブラウザから簡単なCloud Foundaryの運用管理を行うことができる利便性を備えています。
Cloud Foundry Communityから、admin-ui用のBosh Releaseも出ているため、Boshでデプロイすることも可能ですが、リソースの関係上Cloud Foundryのアプリとして起動しておきたい場合等に今回の方法は有効かもしれません。

基本情報

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

  • 1) Cloud Foundryデプロイメント用マニフェストの修正及びbosh-liteの再デプロイ
  • 2) セキュリティグループの追加
  • 3) UAAへのadmin-ui用ユーザ登録
  • 4) ソースの取得
  • 5) ファイルの修正
  • 6) デプロイ
  • 7) 動作確認

1. Cloud Foundryデプロイメント用マニフェストの修正及びbosh-liteの再デプロイ

admin-uiは、Cloud Foundryの各コンポーネントへアクセスして情報を収集しますが、当然admin-uiのコンテナが起動しているホストのDEAにもアクセスを行います。
今回の検証環境として使用しているcf-release v211は、デフォルトでホストへのアクセスができない設定となっているため、本アプリをデプロイ予定のCloud Foundry環境のデプロイメント用マニフェストに設定を修正し、アクセスできるようにします。
具体的には、dea_next.allow_host_accessの設定をtrueに変更します。すでにtrueとなっている場合は、本手順を無視してください。

下記では本検証環境のパスで記述しますが、環境に応じて読み替えてください。

$ vi ./bosh-lite/manifests/cf-manifest.yml
properties:
    :
  dea_next:
    advertise_interval_in_seconds: 5
    allow_host_access: true     ← ここの値を "true" にする
    allow_networks: []

修正が完了しましたら、boshコマンドでCloud Foundryを再デプロイします。

$ bosh deployment ~/bosh-lite/manifests/cf-manifest.yml
$ bosh deploy
:
Started         2015-06-30 08:00:11 UTC
Finished        2015-06-30 08:00:50 UTC
Duration        00:00:39

Deployed `cf-manifest.yml' to `Bosh Lite Director'

[※ 補足]
すでに色々なアプリが起動中など、諸事情によりできるだけCloud Foundryの再デプロイを実施したくない場合、DEAが起動するコンテナ(runner)に直接ログインして設定ファイルを編集するやり方もあります。
* runnerコンテナにsshでログイン
* sudo権限で、/var/vcap/jobs/dea_next/config/warden.ymlを開き、allow_host_access:の設定をtrueに修正
* sudo権限で、monit restart allして、runner内のコンポーネントを再起動

2. セキュリティグループの追加

次に、Cloud Foundryへコンテナから各Cloud Foundryコンポーネントへアクセスを許可するために、セキュリティグループの設定を行います。

本操作は、admin権限のあるcfユーザで行います。
下記では本検証環境の設定で記述しますが、環境に応じて読み替えてください。

$ cf login -u admin -p admin -o admin -s svcs

セキュリティグループを定義したjsonファイルを作成します。
今回は、bosh-lite環境のネットワークに合わせて設定します。本来であれば、アクセス対象のportに絞るべきですが、今回は絞込みが間に合わなかったため、フルオープンにしています。

vi admin-ui.security-groups.json
[
    {
    "protocol": "tcp",
    "destination": "10.244.0.134",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.42",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.34",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.138",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.146",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.142",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.6",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.30",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.22",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.26",
    "ports": "1-65535"
    },
    {
    "protocol": "tcp",
    "destination": "10.244.0.130",
    "ports": "1-65535"
    }
]

定義したセキュリティグループの設定を登録します。

$ cf create-security-group admin-ui-security-groups admin-ui.security-groups.json
Creating security group admin-ui-security-groups as admin
OK
$ cf security-groups
Getting security groups as admin
OK

     Name                       Organization   Space
#0   public_networks
#1   dns
#2   admin-ui-security-groups

登録したセキュリティグループを、admin-uiをデプロイする予定のSpaceにバインドします。
以下の例では、admin-ui-security-groupsを、horiu-jnというOrganizationのhoriu-jnというSpaceにバインドしています。

$ cf bind-security-group admin-ui-security-groups horiu-jn horiu-jn
:
OK

3. UAAへのadmin-ui用ユーザ登録

UAAに、admin-ui用のグループやユーザの登録および権限の付与を行っていきます。

3-1. uaacのインストール

UAAへの操作は、UAA用クライアントであるuaacを介して実行します。
そのため、まずはuaacをインストールします。

$ gem install cf-uaac
$ rbenv rehash
$ uaac --version
UAA client 3.1.4

3-2. admin-ui用グループ及びユーザの登録

インストールしたuaacを使ってユーザ登録を行っていきます。
ここではadmin-uiのREADMEに記載されている手順をそのまま行います。

まずは、登録のための前準備を行います。

$ uaac target http://uaa.10.244.0.34.xip.io

Target: http://uaa.10.244.0.34.xip.io
$ uaac token client get admin -s admin-secret

Successfully fetched token via client credentials grant.
Target: http://uaa.10.244.0.34.xip.io
Context: admin, from client admin
$ uaac client update admin --authorities "`uaac client get admin | \
    awk '/:/{e=0}/authorities:/{e=1;if(e==1){$1="";print}}'` scim.write"

  scope: uaa.none
  client_id: admin
  resource_ids:
  authorized_grant_types: client_credentials
  autoapprove:
  action: none
  authorities: password.write scim.write clients.write clients.read scim.read
      uaa.admin clients.secret
$ uaac token client get admin -s admin-secret

Target: http://uaa.10.244.0.34.xip.io
Context: admin, from client admin

次に、グループ・ユーザを追加と権限の付与を行っていきます。

$ uaac group add admin_ui.admin

  id: 7c07bbc4-d4f4-47cb-ac2f-3370bde143cb
  schemas: urn:scim:schemas:core:1.0
  meta
    version: 0
    created: 2015-11-13T10:56:27.239Z
    lastmodified: 2015-11-13T10:56:27.239Z
  displayname: admin_ui.admin
$ uaac member add admin_ui.admin admin

success

最後に、admin-ui用クライアントを作成します。

uaac client add admin_ui_client \
 --authorities cloud_controller.admin,cloud_controller.read,cloud_controller.write,openid,scim.read \
 --authorized_grant_types authorization_code,client_credentials,refresh_token \
 --autoapprove true \
 --scope admin_ui.admin,admin_ui.user,openid \
 -s admin_ui_secret


  scope: admin_ui.admin openid admin_ui.user
  client_id: admin_ui_client
  resource_ids:
  authorized_grant_types: refresh_token client_credentials authorization_code
  autoapprove: true
  action: none
  authorities: cloud_controller.write openid scim.read cloud_controller.read
      cloud_controller.admin
  id: admin_ui_client

4. ソースの取得

admin-uiのソースを、GitHubから取得します。

$ git clone https://github.com/cloudfoundry-incubator/admin-ui.git
$ cd admin-ui/
admin-ui$ ls -a
.   bin     db       Gemfile.lock  .gitignore  lib      README.md     .ruby-version  .travis.yml
..  config  Gemfile  .git          images      LICENSE  .rubocop.yml  spec

5. ファイルの修正

admin-uiは、起動時に指定する設定ファイル(bosh-liteではconfig/default.yml)に記載されているポートを使って起動する仕様になっているため、Cloud Foundry用にPORT環境変数からポートを取得するように、lib/admin/config.rbを修正します。

admin-ui$ git diff --no-prefix
diff --git lib/admin/config.rb lib/admin/config.rb
index 2573bf6..5d6f6d4 100755
--- lib/admin/config.rb
+++ lib/admin/config.rb
@@ -195,7 +195,7 @@ module AdminUI
     end

     def port
-      @config[:port]
+      ENV["PORT"] || @config[:port]
     end

     def receiver_emails

これでやっとデプロイ前の作業は完了です。

6. デプロイ

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

admin-ui$ vi manifest.yml
---
applications:
- name: admin-ui-100
  memory: 512M
  instances: 1
  command: ~/bin/admin -c ~/config/default.yml

上記設定で、 commandにおいては、config/default.ymlがbosh-lite用の設定になっているので、そのまま設定ファイルとして指定します。

マニフェストの作成が完了したら、cf pushします。

admin-ui$ cf push
:
requested state: started
instances: 1/1
usage: 512M x 1 instances
urls: admin-ui-100.10.244.0.34.xip.io
last uploaded: Fri Nov 13 10:58:42 UTC 2015
stack: cflinuxfs2
buildpack: Ruby

     state     since                    cpu    memory        disk      detail                           s
#0   running   2015-11-13 07:59:36 PM   0.0%   80M of 512M   0 of 1G

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

7. 動作確認

ブラウザから払いだされたアプリのURLへアクセスすると、ログインページが表示されます。
初期ユーザは、bosh-lite用のCloud Foundryデプロイメント用マニフェストを修正していなければ、admin/adminになるはずなので、入力してログインします。

ログインに成功すると、上段に結構な数のタブが並んでいます。ここでは、いくつかカテゴリごとにピックアップして確認していきます。
まずは、Appsを開いてみると、全ユーザが上げているアプリの一覧が表示されます。
スクリーンショットはありませんが、上部のボタンでアプリのストップや削除操作も問題なく行えました。

次に、Service Brokersを開いてみます。
今回の百日行で活躍してくれたサービスの面々が表示されます。
労をねぎらいながら次に行きたいと思います。お疲れ様でした。

Cloud Foundryのコンポーネントの稼動状態を見たい場合は、Componentsのタブが便利です。
bosh vmsコマンドで確認できるレベルの内容を見ることができます。

各コンポーネントのタブで、より詳細な情報を見ることが出来ます。
Nameの値をクリックすると、下のスペースに詳細が表示されます。また、詳細のURLのリンクをクリックすると、varzのRawデータも表示できます。

また、起動時に指定した設定ファイル(今回はconfig/default.yml)内の設定により、指定したログファイルの内容が閲覧できます。
デフォルトでは、admin_ui自身のログのみですが、設定を追加することで各コンポーネントのログを表示させることも可能です。
設定方法については、READMEで確認することができます。

最後にFeature Flagのタブを確認します。
操作したいFeatureにチェックをいれて、Enable/Disableボタンで設定を変更することが出来ます。
ここでは、app_scalingDisableにしてみました。

Disableへ変更後、本アプリをスケールさせてみると、Feature Disabledで想定通りにスケールに失敗しました。

admin-ui$ cf scale admin-ui-100 -i 2
Scaling app admin-ui-100 in org horiu-jn / space horiu-jn as horiu-jn...
FAILED
Server error, status code: 403, error code: 330002, message: Feature Disabled: app_scaling

再度Enableに戻すと、問題なくスケールすることが出来ました。

admin-ui$ cf scale admin-ui-100 -i 2
Scaling app admin-ui-100 in org horiu-jn / space horiu-jn as horiu-jn...
OK

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



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

2015-11-13

SHIRASAGI を Cloud Foundry で動かす

「Cloud Foundry 百日行」第99日目は、中・大規模サイト向けのCMSのSHIRASAGI(シラサギ) です。

Rails製のアプリケーションで、開発は自治体向けCMSの”Joruri CMS”の元開発コアメンバーが設立した会社が開発を行っています。
“SHIRASAGI”も自治体向けサイト構築を意識したデモ画面が用意されているのが特徴です。

基本情報

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

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

1. ソースコードの取得

$ git clone https://github.com/shirasagi/shirasagi.git
$ cd shirasagi/
$ git checkout v1.0.0
$ ls
app  bin  config  config.ru  db  Gemfile  Gemfile.lock  Guardfile  lib  log  MIT-LICENSE  private  public  Rakefile  README.md  spec  vendor

2. 事前準備

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

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

2.2. 設定ファイルのコピー

README.mdの”SHIRASAGIのインストール”の手順を参考に設定ファイルをコピーします

$ cp -n config/samples/*.{yml,rb} config/

2.3. アプリの事前push

--no-startを付けてpushします

$ cf push shirasagi --no-start

2.4. サービスの紐付け

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

$ cf bind-service shirasagi shirasagi-mongo

2.5. MongoDB接続情報の設定

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

$ cf env shirasagi
:
    "credentials": {
     "uri": "mongodb://f6f4e92d-ce0f-445f-b75e-e69879e57b9c:
password@192.168.15.91:27017/6248441b-b375-4723-bb4e-befdab6
164da"
    },

mongoid.ymlにMongoDB接続用の設定を行います

$ vi config/mongoid.yml
# mongodb configuration

production:
  sessions:
    default:
      database: 6248441b-b375-4723-bb4e-befdab6164da
      username: f6f4e92d-ce0f-445f-b75e-e69879e57b9c
      password: password
      hosts:
        - 192.168.15.91:27017

2.6. 起動用スクリプトの作成

今回のアプリでは,初回起動時のみ実行する必要がある処理と,2回目以降通常の起動で必要な処理とに分けて起動スクリプトを作成します。

まずは初回起動用のスクリプトfirstrun.shを作成します
host:部分の値はアプリ名と統一させます
domains:部分はCloud Foundryのホスト名+ドメイン名の値と合わせます

$ vi firstrun.sh
#!/bin/bash -x
 
bundle exec rake db:drop
bundle exec rake db:create_indexes
bundle exec rake ss:create_site data='{name: "demo", host: "shirasagi", domains: "shirasagi.10.244.0.34.xip.io"}'

続いて通常起動用のスクリプトのstart.shを編集します

今回は自治体向けサイトのデモデータを利用する為、”demo”を指定します。
企業向けデモをロードする場合は”company”を指定します。

$ vi start.sh
#!/bin/bash -x

bundle exec rake db:seed name=demo site=shirasagi
bundle exec unicorn_rails -c /home/vcap/app/config/unicorn.rb -p $PORT

firstrun.shとstart.shに実行権を設定します

$ chmod a+x firstrun.sh
$ chmod a+x start.sh

2.7. manifest.ymlの作成

---
applications:
- name: shirasagi
  memory: 1G
  host: shirasagi
  domain: 10.244.0.34.xip.io
  command: './start.sh'
  timeout: 180

3. アプリの起動

初回push時は以下のように実行します

$ cf push -c './firstrun.sh && ./start.sh'
:
requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: shirasagi.10.244.0.34.xip.io
last uploaded: Tue Nov 10 08:13:48 UTC 2015
stack: cflinuxfs2
buildpack: Ruby

     state     since                    cpu    memory         disk      details
#0   running   2015-11-10 05:15:05 PM   0.2%   388.5M of 1G   0 of 1G

成功しました。

2回目以降のpush時は以下のように実行します

$ cf push

4. 動作確認

ブラウザで”http://shirasagi.10.244.0.34.xip.io”にアクセスすると、自治体向けなデモページが表示されます。

コンテンツの編集は”http://shirasagi.10.244.0.34.xip.io/.mypage”にアクセスし
公式サイトのオンラインデモの情報を元に、ログイン画面でIDをadmin、パスワードをpassと入力するとログインする事が出来ます。

ログインすると管理画面が表示されます

管理画面から新規コンテンツを管理画面から追加した後にcf restartで再起動を行った場合も正常にコンテンツが永続化されていました。

また、企業向けデモサイトをロードした場合は、このような企業サイト向けなデモページが表示されます。

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

2015-11-12

Mconf-Web を Cloud Foundry で動かす

「Cloud Foundry 百日行」第98日目は、RailsベースのWeb会議システム、Mconf-Webです。
Mconf-Webは、会議ごとに参加するユーザ間での情報共有やビデオ会議が行えるアプリです。
ビデオ会議の機能については、残念ながら、今回の検証時間内で動かすことができませんでしたが、会議自体の管理や会議毎の情報共有をする目的で利用する場合、便利だと思います。

基本情報

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

  • 1) ソースコードの取得
  • 2) サービスの作成
  • 3) ファイルの修正
  • 4) 設定ファイルの準備
  • 5) デプロイ
  • 6) 動作確認
  • 7) まとめ

1. ソースコードの取得

Mconf-Webのソースを、GitHubから取得します。
最新版はv2.0.0なので、チェックアウトします。

$ git clone https://github.com/mconf/mconf-web.git
$ cd mconf-web
mconf-web$ git checkout v2.0.0 -b mc-v2
Switched to a new branch 'mc-v2'
mconf-web$ ls -a
.    Cheffile       cookbooks-local  Gemfile.lock  LICENSE  .rails_footnotes  .ruby-version  tmp
..   Cheffile.lock  db               .git          log      Rakefile          .rvmrc         .travis.yml
app  config         doc              .gitignore    private  README.rdoc       script         Vagrantfile
bin  config.ru      Gemfile          lib           public   .rspec            spec           vendor

2. サービスの作成

Mconf-WebはMySQLRedisを使用するため、作成しておきます。

mconf-web$ cf create-service p-mysql 100mb mw-mysql
:
OK
mconf-web$ cf create-service p-redis shared-vm mw-redis
:
OK
mconf-web$ cf services
:
name       service   plan        bound apps   last operation
mw-mysql   p-mysql   100mb                    create succeeded
mw-redis   p-redis   shared-vm                create succeeded

後ほど、Redisの接続設定を取得するため、no-startcf pushした本アプリに作成したRedisサービスをバインドしておきます。
MySQLについては、Cloud Foundryのauto-reconfiguration機能で自動的に接続設定されるため、この操作は不要です。

mconf-web$ cf push --no-start mconf-100
:
Uploading 3.3M, 1708 files
Done uploading
OK
mconf-web$ cf bind-service mconf-100 mw-redis
:
OK

3. ファイルの修正

3-1. Gemfileファイルの修正

RailsアプリをCloud Foundryで動かす場合、画面が予期したスタイルにならない等などの不具合を解消するため、Gemfilerails_12factorを追加します。

mconf-web$ git diff --no-prefix Gemfile
diff --git Gemfile Gemfile
index c828719..9495583 100644
--- Gemfile
+++ Gemfile
@@ -100,6 +100,9 @@ gem "logstash-event"
 gem 'fineuploader-rails', git: 'https://github.com/mconf/fineuploader-rails.git'
 gem 'filesize'

+# for Cloud Foundry
+gem "rails_12factor"
+
 #
 # TODO: Gems to review if we can remove/update
 #

3-2. Gemfile.lockファイルの生成

修正したGemfileから、Gemfile.lockを再生成します。
.ruby-version2.2.0が指定されているので、予め環境にインストールしておいて下さい。

mconf-web$ bundle install --path vendor/bundle
mconf-web$ git diff --no-prefix Gemfile.lock
diff --git Gemfile.lock Gemfile.lock
index cf80c96..99952ac 100644
--- Gemfile.lock
+++ Gemfile.lock
@@ -397,8 +397,13 @@ GEM
       sprockets-rails (~> 2.0)
     rails-footnotes (4.0.2)
       rails (>= 3.2)
+    rails_12factor (0.0.3)
+      rails_serve_static_assets
+      rails_stdout_logging
     rails_autolink (1.1.6)
       rails (> 3.1)
+    rails_serve_static_assets (0.0.4)
+    rails_stdout_logging (0.0.4)
     railties (4.1.11)
       actionpack (= 4.1.11)
       activesupport (= 4.1.11)
@@ -622,6 +627,7 @@ DEPENDENCIES
   rack (~> 1.5.4)
   rails (~> 4.1.11)
   rails-footnotes
+  rails_12factor
   rails_autolink (~> 1.1.0)
   rake
   resque
@@ -658,3 +664,6 @@ DEPENDENCIES
   yui-compressor
   zip-zip
   zonebie
+
+BUNDLED WITH
+   1.10.6

副産物のvendor/bundle配下のファイルは、アプリのデプロイには不要ですので、削除するか、第89日目でも記述されているように.cfignoreでプッシュ対象から除外して下さい。

4. 設定ファイルの準備

デプロイに必要な各種設定ファイルの作成を行っていきます。

4-1. setup_conf.ymlの設定

Mconf-Web用の設定ファイル setup_conf.yml を作成します。
ベースは、Mconf-WebのDeploymentマニュアルに従って、用意されているsetup_conf.yml.exampleをコピーして作成します。

mconf-web$ cp config/setup_conf.yml.example config/setup_conf.yml

次に、RedisのCredential情報を設定します。
cf envで、RedisのCredential情報を確認します。

mconf-web$ cf env mconf-100
:
System-Provided:
{
 "VCAP_SERVICES": {
  "p-redis": [
   {
    "credentials": {
     "host": "10.244.3.46",
     "password": "1e03a94f-5bb1-42cd-9bd4-ce289b6f6dea",
     "port": 50120
    },
    "label": "p-redis",
    "name": "mw-redis",
    "plan": "shared-vm",
    "tags": [
     "pivotal",
     "redis"
    ]
   }
  ]
 }
}

config/setup_conf.ymlに、取得したCredential情報を設定します。

mconf-web$ git diff --no-prefix config/setup_conf.yml
diff --git config/setup_conf.yml config/setup_conf.yml
index 4ab5da0..6fba9b6 100644
--- config/setup_conf.yml
+++ config/setup_conf.yml
@@ -47,11 +47,11 @@ default:

   # If you're running redis on the same server and without a password, you
   # can leave this block commented
-  # redis:
-  #   host: 'localhost'
-  #   port: '6379'
-  #   db: 0
-  #   password: '1234567890'
+  redis:
+    host: '10.244.3.46'
+    port: '50120'
+    db: 0
+    password: '1e03a94f-5bb1-42cd-9bd4-ce289b6f6dea'

 # Configurations for each environment
 # You can find below the sections for each environment available.

4-2. Aptfileファイルの作成

Mconf-WebのDeploymentマニュアルに記述されているaptパッケージの中で、RootFSに入っていないと思われるものから、入れる必要があるパッケージをピックアップしてデプロイ時にインストールするようにします。
インストールは、heroku-buildpack-aptを使って行います。
インストールするパッケージは、本アプリのルートディレクトリにAptfileファイルを作成して定義します。

mconf-web$ vi Aptfile
aspell-es
aspell-en
nfs-common
libreadline-dev
libffi-dev
openjdk-7-jre
libapache2-mod-xsendfile

4-3. .buildpacksファイルの作成

複数のBuildPackを指定してデプロイをする必要があるため、heroku-buildpack-multiを使ってデプロイを行います。
使用するBuildPackは、アプリのルートディレクトリに.buildpacksファイルを作成して定義します。
ruby-buildpackのバージョンは、今回の検証環境として使用しているcf-release v211admin buildpack と同じものを指定しています。

mconf-web$ vi .buildpacks
https://github.com/ddollar/heroku-buildpack-apt.git
https://github.com/cloudfoundry/ruby-buildpack.git#v1.6.7

4-4. manifes.tymlファイルの作成

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

mconf-web$ vi manifest.yml
applications:
- name: mconf-100
  memory: 1G
  buildpack: https://github.com/ddollar/heroku-buildpack-multi.git
  command: 'bundle exec rake db:migrate && bundle exec rake db:seed && bundle exec rackup --port $PORT'
  domain: 192.168.15.91.xip.io
  timeout: 180
  services:
    - mw-mysql
    - mw-redis
  env:
    PATH: '$PATH:/tmp/staged/app/.apt/usr/lib/jvm/java-7-openjdk-amd64/bin'

設定について、特徴的な箇所について記述します。
* memory: デプロイ直後でメモリがデフォルトの256MBでギリギリでしたので、念のため1Gとしました。
* buildpack: heroku-buildpack-multiを指定します。
* timeout: 起動に若干時間がかかるため、Max値の180秒を指定しました。
* env: Aptfileで指定したjava-7の展開先が、heroku-buildpack-aptの想定箇所と異なるため、手動で指定します。

5. デプロイ

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

mconf-web$ cf push
:
OK

requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: mconf-100.192.168.15.91.xip.io
last uploaded: Wed Nov 11 10:23:21 UTC 2015
stack: cflinuxfs2
buildpack: https://github.com/ddollar/heroku-buildpack-multi.git

     state     since                    cpu    memory         disk      details
#0   running   2015-11-11 07:34:33 PM   0.0%   271.8M of 1G   0 of 1G

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

6. 動作確認

ブラウザから払いだされたアプリのURLへアクセスすると、トップページが表示されます。
初期ユーザは admin/adminなのでSign in to your account のほうに入力してログインすると、ホーム画面が表示されます。

まずは、上段にあるManageをクリックし、Site ManagementページからMconf-Webの設定を行ってみます。
各ユーザからの会議への参加申し込み・承認等ではメール通知が行われるため、SMTPサーバ等の設定が必要です。ただ、今回はGmailのアカウントを登録してみましたが、上手くメールが配信出来ませんでした。

次に、Spaceを作っていきます。Mconf-Webでは、各会議(Conference)はSpaceという単位で管理します。
ホーム画面の右側にあるCreate a new spaceボタンをクリックし、Spaceを作成します。

Space作成用のフォームに会議名や説明を入力し、Createボタンをクリックすると、Spaceが作成されます。

今度は、新しくユーザを作成してみます。ログアウトしてトップ画面に戻り、Create a new accountからユーザを作成すると、ホーム画面が表示されます。

自分で会議(Space)を新規作成することもできますが、公開されている会議があれば、へ参加申し込み(Join this space)を出すことができます。

各会議のページでは、コメント共有やビデオ会議(上手く起動しませんでしたが…)などが行えます。
コメントの共有は、Wallからメッセージを登録します。登録されたメッセージは、参加メンバーのホームにも表示されます。

ビデオ会議は、WebconferenceStartボタンを押すと開催できるはずですが、今回はエラーとなってしましました。

7. まとめ

公式サイトGithubの説明をみると、ビデオ会議を行うには Mconf-LiveBigBlueButton サーバが必要なようです。
今回、Docker Hubに登録されているBigBlueButtonで立ち上げ、以下のようにSite Managementページから設定しましたが、残念ながら上手く接続できない状態でタイムアップとなってしまいました…

今後、もう少し検証しよい結果がでましたら、本ページのほうを更新したいと思います。
もしも何か知見をお持ちの方は、 Twitter で @horiu_jnにmentionを飛ばして頂ければと思います。

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



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

2015-11-11

Moodle を Cloud Foundry で動かす

「Cloud Foundry 百日行」第97日目,今日は初の LMS (Learning Management System), Moodle です。Moodle は PHPで書かれており,OSS の LMS として歴史と人気を誇るアプリケーションのようです。

基本情報

  • 公式サイト
    https://moodle.org/

  • ソースコード
    git://git.moodle.org/moodle.git
    gitプロトコルでのアクセスしか提供されていないようです

  • その他参考情報

    • moodle.net
      Moodle 向けのコンテンツ/コースの共有サイトです
      デモもあります

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

  • 1) ソースコードの取得
  • 2) サービスの作成とバインド
  • 3) 各種設定
  • 4) アプリの起動
  • 5) 動作確認

1. ソースコードの取得

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

今回,リポジトリーのコミット数が多く,処理が重くなるのを避けるために --depth=1 -b MOODLE_29_STABLE を指定していますが,もちろん指定せずに全コミットを取得しても問題ありません。その場合,ディレクトリー移動後に git checkout MOODLE_29_STABLE することを忘れないでください。

$ git clone --depth=1 -b MOODLE_29_STABLE git://git.moodle.org/moodle.git
..
$ cd moodle/

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

本アプリの対応 DBMS は, 公式ドキュメント によると PostgreSQL, MariaDB, MySQL, MSSQL, Oracle ということです。中でも PostgreSQL について,公式サイト上の Arguments in favour of PostgreSQL というページで,PostgreSQLを勧める理由が述べられているので,今回は PostgreSQL サービスを使うことにしました。

以下,サービスを作成し,アプリにバインドします。今回は manifest.yml をあらかじめ作っておき,バインドはアプリのアップロード時に同時に行うようにしました。

manifest.yml の作成

以下のような manifest.yml を作成します。

applications:
- name: <APPNAME>
  buildpack: php_buildpack
  services:
  - <SERVICE-INSTANCE-NAME>

buildpack の項について:このアプリのトップ・ディレクトリーには package.json ファイルがあるので,何も指定しないと nodejs-buildpack が適用されてしまいます。それを避けるために,php_buildpack を使うよう,陽に指定しています。

今回は, <APPNAME> として moodle を, <SERVICE-INSTANCE-NAME> として pg-moodle を用いることにしたので,manifest.yml の内容は以下の通りになりました。

$ cat manifest.yml
applications:
- name: moodle
  buildpack: php_buildpack
  services:
  - pg-moodle

サービスの作成

PostgreSQL サービスを作成します。サービス・インスタンス名は manifest.yml に合わせて pg-moodle とします。

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

アプリのアップロード及びサービスとのバインド

アプリを停止状態で Cloud Foundry 上に push します。manifest.yml があるのでアプリ名のその他の指定は不要です。

$ cf push --no-start
Using manifest file /home/nota-ja/repos/moodle/manifest.yml

Creating app moodle in org nota-ja / space 100 as nota-ja...
OK

Using route moodle.10.244.0.34.xip.io
Binding moodle.10.244.0.34.xip.io to moodle...
OK

Uploading moodle...
Uploading app files from: /home/nota-ja/repos/moodle
Uploading 81.6M, 18768 files
Done uploading
OK
Binding service pg-moodle to app moodle in org nota-ja / space 100 as nota-ja...
OK

manifest.yml にサービス・インスタンスの記述があるので,バインドまで自動的に行われます。

3. 各種設定

アプリの実行に必要な各種の設定を行います。主要な設定項目は以下の通りです。

  • moodledata ディレクトリーの設定
  • データベース接続設定
  • アプリのルート URL の設定
  • PHP 拡張モジュールの設定
  • (optional) アップロード・ファイル・サイズ上限の変更

これらは複数のファイルにまたがっていますが,以下基本的にファイルごとに設定を行っていきます。

moodledata ディレクトリーの作成

「ファイルごと」と書きましたが,その前に事前作業を一つ。

公式ドキュメントの記述 によると,moodle はアップロードされたファイルや一時ファイル,キャッシュの置き場としてデータ・ディレクトリーを必要とします。

今回は,アプリのディレクトリー直下に moodledata というディレクトリーを作り,それをデータ・ディレクトリーとして使うことにします。

$ mkdir -p moodledata

.bp-config/options.json ファイル

Cloud Foundry の php-buildpack では,各種カスタマイズを .bp-config/options.json ファイルで行うことができます。今回は以下の内容のファイルを作成します。

$ cat .bp-config/options.json
{
    "PHP_EXTENSIONS": ["iconv", "mbstring", "curl", "openssl", "tokenizer", "xmlrpc", "soap", "ctype", "zip", "gd", "simplexml", "spl", "pcre", "dom", "xml", "intl", "json", "pgsql", "zlib"],
    "LIBDIR": "moodledata"
}

公式ドキュメントの記述 を参考に,PHP の拡張モジュールを, PHP_EXTENSIONS に設定しました。

なお, zlib はドキュメントに記載がありませんでしたが,初回実行時のチェックで必須とされたので追加しました。また xmlrpcPHP_EXTENSIONS に含まれているにもかかわらず,(後で再度述べますが) なぜか php-buildpack がインストールしてくれませんでした。

また,moodledata ディレクトリーをWeb公開ディレクトリー外におくために, LIBDIR として指定しています。これは, 公式ドキュメント で「このディレクトリーは(セキュリティ上) Web からアクセスできないようにせよ」とされているためです。

config.php ファイル

config.php ファイルを書き換えて,

  • データベース接続設定
  • moodledata ディレクトリーの設定
  • アプリの URL の設定

を行います。

データベース接続設定は, cf env <APPNAME> で得られた VCAP_SERVICES の情報に基づいて行います。

$ cf env moodle
Getting env variables for app moodle in org nota-ja / space 100 as nota-ja...
OK

System-Provided:
{
 "VCAP_SERVICES": {
  "PostgreSQL": [
   {
    "credentials": {
     "uri": "postgres://f6bf5e71-8b6c-4f36-a876-6041abc96f5f:1grrq433t7k81buh8l4iqreqq2@192.168.15.91:5432/f6bf5e71-8b6c-4f36-a876-6041abc96f5f"
    },
    "label": "PostgreSQL",
    "name": "pg-moodle",
    "plan": "Basic PostgreSQL Plan",
    "tags": [
     "PostgreSQL",
     "Database storage"
    ]
   }
  ]
 }
}
..

また,アプリのルート URL としてアップロード時にアサインされた moodle.10.244.0.34.xip.io を,データ・ディレクトリーとして先ほど作成した moodledata ディレクトリーを指定します。最終的には,変更箇所は以下のようになります(デフォルト設定である config-dist.php と比較)。

$ git diff --no-index -- config-dist.php config.php
diff --git a/config-dist.php b/config.php
index df033d9..58154ad 100644
--- a/config-dist.php
+++ b/config.php
@@ -40,10 +40,10 @@ $CFG = new stdClass();

 $CFG->dbtype    = 'pgsql';      // 'pgsql', 'mariadb', 'mysqli', 'mssql', 'sqlsrv' or 'oci'
 $CFG->dblibrary = 'native';     // 'native' only at the moment
-$CFG->dbhost    = 'localhost';  // eg 'localhost' or 'db.isp.com' or IP
-$CFG->dbname    = 'moodle';     // database name, eg moodle
-$CFG->dbuser    = 'username';   // your database username
-$CFG->dbpass    = 'password';   // your database password
+$CFG->dbhost    = '192.168.15.91';  // eg 'localhost' or 'db.isp.com' or IP
+$CFG->dbname    = 'f6bf5e71-8b6c-4f36-a876-6041abc96f5f';   // database name, eg moodle
+$CFG->dbuser    = 'f6bf5e71-8b6c-4f36-a876-6041abc96f5f';   // your database username
+$CFG->dbpass    = '1grrq433t7k81buh8l4iqreqq2';   // your database password
 $CFG->prefix    = 'mdl_';       // prefix to use for all table names
 $CFG->dboptions = array(
     'dbpersist' => false,       // should persistent database connections be
@@ -56,7 +56,7 @@ $CFG->dboptions = array(
                                 //  (please note mysql is always using socket
                                 //  if dbhost is 'localhost' - if you need
                                 //  local port connection use '127.0.0.1')
-    'dbport'    => '',          // the TCP port number to use when connecting
+    'dbport'    => '5432',      // the TCP port number to use when connecting
                                 //  to the server. keep empty string for the
                                 //  default port
 );
@@ -73,7 +73,7 @@ $CFG->dboptions = array(
 // If you need both intranet and Internet access please read
 // http://docs.moodle.org/en/masquerading

-$CFG->wwwroot   = 'http://example.com/moodle';
+$CFG->wwwroot   = 'http://moodle.10.244.0.34.xip.io';


 //=========================================================================
@@ -89,7 +89,7 @@ $CFG->wwwroot   = 'http://example.com/moodle';
 //
 // - On Windows systems you might specify something like 'c:\moodledata'

-$CFG->dataroot  = '/home/example/moodledata';
+$CFG->dataroot  = '/home/vcap/app/moodledata';


 //=========================================================================

.bp-config/php/php.ini ファイル

これはある意味 optional なのですが,今回動作確認に使った「コース」のバックアップ・ファイルをアップロードするために,アップロード・ファイル・サイズの上限の緩和が必要だったので,それを php.ini ファイルで設定しました。

Cloud Foundry の php-buildpack では,デフォルトの php.ini 設定を変更したい場合,変更後のファイルを .bp-config/php/ に置くとその設定が反映されるようになっています。

今回は,

  • https://github.com/cloudfoundry/php-buildpack/blob/62b2fca31516f3b94be84355660835db8269252c/defaults/config/php/5.5.x/php.ini

の php.ini ファイルをベースに,

  • http://www.amulet.co.jp/shop-blog/?p=6507 (section 2.1.)
  • https://docs.moodle.org/29/en/Administration_FAQ#How_do_the_limits_on_uploaded_files_work.3F

などを参考にして,2箇所の変更を行いました。

ベースにしたファイルとの差分は以下の通りです。

$ git diff --no-index -- ../php.ini.62b2fca31516f3b94be84355660835db8269252c .bp-config/php/php.ini
diff --git a/../php.ini.62b2fca31516f3b94be84355660835db8269252c b/.bp-config/php/php.ini
index 94f1511..73327c1 100644
--- a/../php.ini.62b2fca31516f3b94be84355660835db8269252c
+++ b/.bp-config/php/php.ini
@@ -669,7 +669,7 @@ auto_globals_jit = On
 ; Its value may be 0 to disable the limit. It is ignored if POST data reading
 ; is disabled through enable_post_data_reading.
 ; http://php.net/post-max-size
-post_max_size = 8M
+post_max_size = 50M

 ; Automatically add files before PHP document.
 ; http://php.net/auto-prepend-file
@@ -801,7 +801,7 @@ upload_tmp_dir = "@{TMPDIR}"

 ; Maximum allowed size for uploaded files.
 ; http://php.net/upload-max-filesize
-upload_max_filesize = 2M
+upload_max_filesize = 50M

 ; Maximum number of files that can be uploaded via a single request
 max_file_uploads = 20

上限値を 50MB にしたのは,動作確認で利用した「コース」バックアップ・ファイル (Scratch.mbz) のサイズが 47MB だったためです。

4. アプリの起動

準備が整ったので,アプリを起動します。manifest.yml があるので,単に cf push するだけです。

$ cf push
$ cf push
Using manifest file /home/nota-ja/repos/moodle/manifest.yml
..
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: moodle.10.244.0.34.xip.io
last uploaded: Wed Nov 11 09:30:10 UTC 2015
stack: cflinuxfs2
buildpack: php_buildpack

     state     since                    cpu    memory        disk      details
#0   running   2015-11-11 06:31:47 PM   1.3%   90M of 256M   0 of 1G

起動しました。

5. 動作確認

アプリ起動後,ブラウザーでアプリのURLにアクセスすると,まず著作権に関する注意が表示されます:

【Continue】をクリックして先に進みます。

次に表示されるのはサーバー・チェックの画面です:

おそらく xmlrpc に関するものと opcache.enable に関するもの,2つの警告が出ていると思いますが,今回は気にしないことにして,スクロール・ダウンして【Continue】をクリックします。

※xmlrpc については,options.json の PHP_EXTENSIONS に記述しているにもかかわらず,インストールされていないようです。今回は時間がなく原因の分析は断念しました。

すると処理中で画面が止まったままになり,しばらくすると「Service Unavailable」というメッセージが表示されると思います:

しかし,これは恐らく処理が重いためにリクエストがタイムアウトしてしまったことが原因と考えられ,アプリが止まってしまったわけではありません。

数分後にリロードすると,次のような画面が現れるはずです:

必須項目 (【Username】【New password】【First name】【Surname】【Email address】) のみ設定し,後はデフォルトのままで,スクロール・ダウンして【Update profile】をクリックします:

そうすると “Front page settings” 画面になるので,適当に入力:

スクロール・ダウンして【Save changes】をクリックします。

これでようやく初期作業が終わり,adminとしてログイン済みの画面に遷移します:

左の【Administration】ペインで【Site administration】-【Users】-【Accounts】と navigate し,【Add a new user】をクリックして新規ユーザー作成画面に移動し,ユーザーを作成します:

必須項目 (【Username】【New password】【First name】【Surname】【Email address】) 以外はとりあえずデフォルトのままで,スクロール・ダウンして【Create user】をクリックします。

ユーザーが作成されました:

次に,学習の「コース」を作成します。コースは「大学の学習単位のような一連の講義のシーケンス」というのが私の理解です。今回は,CC-BY-SA ライセンスで配布されている作成済みのコース Basic Scratch (プログラミング言語 Scratch の学習コース) を試してみることにしました。

上記リンク先ページの下方にある【ダウンロード】をクリックし,Scratch.mbz ファイルをダウンロードします。

次に,Moodleに戻って,左の【Administration】ペインで【Site administration】-【Courses】と navigate し,【Restore course】をクリックしてコースのリストア画面に移動し,今ダウンロードしたコースをリストアします:

Scratch.mbz ファイルを【Files】下のエリアにドラッグ&ドロップし,アップロード終了後【Restore】ボタンをクリックします。

以下,7ステップにわたるリストアを開始します (長いので全ての画面は記載せず省略):

リストアが完了すると,この画面に遷移します:

このコースの受講者を設定するために,左の【Administration】ペインで【Course administration】-【Users】と navigate し,【Enrolled users】をクリックして,コースのユーザー管理画面に遷移し,右上の【Enrol users】をクリックしてダイアログを出し, “Noburou Taniguchi” を “Student” に,”admin” を “Manager” に enrol します:

ここで一旦ログアウトし,先ほど Student にアサインしたユーザーでログインします:

ログイン直後の画面はこんな感じになっているはずです:

【Basic Scratch】をクリックして,コースのトップ画面に遷移します:

左の【Navigation】ペインで【Dashboard】-【Current course】-【Scratch】-【Topic 1】と navigate し,【Lesson Plan】をクリックしてみます。

Lesson Plan 画面に遷移し,講義の概要が表示されます:

まだまだコースの続きはあるのですが,動作確認はこれで終わりとします。

この後【Video tutorial: Bad joke】なども試してみたのですが,動画の再生は途切れ途切れになっていたので,動画コンテンツを使う場合は,bosh-lite 環境より性能的にリッチな環境で動かしたほうが良さそうです。

また,今回ユーザー・アカウント等の永続性については確認したのですが,moodledata の永続性については時間がなくて十分調査できませんでした。基本的には, 公式ドキュメントの Backup に関する記述 を参考に,必要に応じて 第65日目の UNICALE の回 で使用した sshfs を活用すればいいのではないかと考えていますが,今後リクエストがあればその辺りも調査したいと思います。

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

2015-11-10

NicoNico SPEENYAを Cloud Foundry で動かす

「Cloud Foundry 百日行」第96日目は、NicoNico SPEENYA です。
本アプリケーションはChromeの拡張機能を使って、プレゼンテーション中に参加者のリアクションをプレゼン画面に反映させる非常にユニークなアプリです。

基本情報

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

  • 1) ソースコードの取得
  • 2) Chromeエクステンションの準備
  • 3) アプリの起動
  • 4) 動作確認

1. ソースコードの取得

$ git clone https://github.com/chimerast/niconico-speenya
$ cd niconico-speenya/
$ ls
extension  LICENSE  make-package.sh  package.json  public  README.md  screenshot.png  server.js

2. Chromeエクステンションの準備

2.1. 作成

事前にChrome用のエクステンションの準備を行います。
まずはjsファイルを編集し、Cloud Foundry上でこの後にpushするアプリのURLを設定します。

$ vi extension/scripts/content-script.js
$ vi extension/scripts/content-script.js
$ git diff
diff --git a/extension/scripts/content-script.js b/extension/scripts/content-script.js
index 730bbef..f00775f 100644
--- a/extension/scripts/content-script.js
+++ b/extension/scripts/content-script.js
@@ -1,6 +1,6 @@
 var speenya = (function() {
   // change to your server url
-  var SERVER_URL = 'http://localhost:2525';
+  var SERVER_URL = 'http://nico.192.168.15.91.xip.io';
   var APP_ID = chrome.runtime.id;
   var APP_VERSION = chrome.runtime.getManifest().version;

Chromeエクステンションをパッケージ化するスクリプトを実行します。
※実行すると最初にNo such file of directoryが出ますが、初回は出るような作りになっています。

$ ./make-package.sh
rm: cannot remove ‘../dist/extension.zip’: No such file or directory
  adding: icons/ (stored 0%)
  adding: icons/icon128.png (deflated 0%)
  adding: icons/icon19.png (stored 0%)
  adding: icons/icon38.png (stored 0%)
  adding: icons/icon128_chromestore.png (deflated 4%)
  adding: icons/icon48.png (deflated 0%)
  adding: icons/icon38_disabled.png (stored 0%)
  adding: icons/icon16.png (deflated 3%)
  adding: icons/icon19_disabled.png (stored 0%)
  adding: icons/convert.sh (deflated 56%)
  adding: images/ (stored 0%)
  adding: images/thumb.png (deflated 2%)
  adding: images/newspicks.png (deflated 1%)
  adding: images/logo.png (deflated 0%)
  adding: images/Facebook_like_thumb.png (deflated 5%)
  adding: images/speenya.png (deflated 0%)
  adding: manifest.json (deflated 53%)
  adding: scripts/ (stored 0%)
  adding: scripts/content-script.js (deflated 67%)
  adding: scripts/background.js (deflated 65%)
  adding: scripts/socket.io-1.3.0.js (deflated 74%)

2.2. インストール

発表者側のChromeでextention.zipを解凍します。

Chromeの設定から『拡張機能』を選択、『デベロッパーモード』にチェックを付けます。

『パッケージ化されていない拡張機能を読み込む』をクリックします。

extention.zipを解凍して出来たフォルダを選択し”OK”をクリック

3. アプリの起動

$ cf push nico -d 192.168.15.91.xip.io -c 'npm start'
:
App started
 
 
OK
 
App nico was started using this command `npm start`
 
Showing health and status for app nico in org morika-t / space morika-t as morika-t...
OK
 
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: nico.192.168.15.91.xip.io
last uploaded: Thu Nov 5 06:50:58 UTC 2015
stack: cflinuxfs2
buildpack: Node.js
 
     state     since                    cpu    memory          disk      details
#0   running   2015-11-05 03:51:47 PM   0.0%   70.2M of 256M   0 of 1G

成功しました。

4. 動作確認

手順 プレゼン実施者側 参加者側
1 例として、以前に私が発表した資料のURLを開いてみます。
http://www.slideshare.net/morika-t/go-cfcloudfoundryrindoku1420131025
2 参加者側はpushしたアプリのURLにアクセスします
3 Commentに”Cloud Foundry!!!!!!!!” と入力し”Enter”キーを入力します
4 画面に”Cloud Foundry!!!!!!!!”が表示されます
5 今度は”Show Send Image Textbox”をクリックします
6 今回は百日行第78日目で紹介しましたEtherDrawで描かれた名画の画像URLを挿入してみます
URL: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6Z4_FWqsJgVDaOjsL8vqwh1OUgvmNqYGTNjtJ1WVs5nMPt2klFSL0xxEjbDLLU_pxUz62fCJR9SLa3T_lSLfe_4vL9dbEFvhodHuRDO8E-_IbJkpZyKYOmrNpqwn5aDqCRUu5yk1Swng/s1600/etherdraw-07-before-restart.png
7 スライド上に画が浮かび上がってきます

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



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