2015年7月23日 (木)

ECMAScript 6で開発したアプリをHerokuにデプロイ

こんにちは、三宅です。
最近はSwiftによるiOSアプリ開発が多かったのですが、久しぶりにJavaScript。
ECMAScript 6の仕様が承認されたということで、ECMAScript 6で記述したアプリのHerokuへのデプロイを試してみました。

flect-miyake/heroku-es6

Deploy

Herokuボタンから、自分のアカウントで簡単に試してみることができます。

ECMAScript 6(ES6)について

ECMAScriptはEcma InternationalによるJavaScriptの標準です。
実装ごとの互換性が低かったJavaScriptの標準を定めたものであり、モダンブラウザやNode.jsはECMAScript 5(ES5)に基づいて実装されています。
その言語仕様であるECMA-262の最新バージョン、6thエディションの承認が2015年6月に発表されました。
ES6では、クラスやモジュール、アロー関数、let、constなどの新たな機能が追加され、従来よりも簡潔に安全なプログラムを書くことができるようになります。

ES6の新機能やどのように記述するかなどは、lukehoban/es6featuresが参考になります。

ES6を利用するには

現時点での実装状況をECMAScript compatibility tableで確認することができます。
一部の機能は先行実装されていますが、まだまだ対応しているブラウザやランタイムは多くありません。

しかし、ES6をES5に変換するトランスパイラやES5でES6の機能を実装したpolyfillライブラリを用いることで、今からでもES6の機能を用いて開発することができます。

今回は、トランスパイラであるBabelを用いています。

サンプルアプリケーションについて

Expressを利用した簡単なアプリケーションです。
Herokuボタンを使ってHeroku上で動作を確認できますし、ローカルでも以下の手順で実行することができます。

$ git clone https://github.com/flect-miyake/heroku-es6.git
$ cd heroku-es6
$ npm install
$ gulp build
$ npm start

「npm start」でサーバを起動後、ブラウザから「localhost:3000」でアクセスできます。

ディレクトリ構成は、「express-generator」で生成されるプロジェクトの構成をほぼ踏襲しています。
「src」にES6で記述するソースコードを配置し、「dist」にES5に変換されたコードが出力されます。
「src/public」に配置したコードはブラウザで動作し、それ以外のコードはサーバサイドで動作します。

タスクランナーとしてgulpを利用しています。
Node.jsではCommonJSによるモジュール化が可能なので、gulp-babelを用いて変換したものをそのまま出力。
ブラウザで実行されるスクリプトは、Browserifyを用いて、「bundle.js」にコンパイルしています。
BrowserifyはクラインアントサイドのJavaScriptでもCommonJSスタイルのモジュール化を実現するためのツールですが、「transform」を追加することでES6からES5へのトランスパイルや、CoffeeScriptで記述したコードの変換なども同時に行ってくれます。

Herokuデプロイ時のビルドタスクの実行

アプリケーションとして実際に動作するコードはES5に変換された「dist」以下のものになるのですが、このような構成のプロジェクトの場合、バージョン管理とHerokuへのデプロイの際に少し問題が出てきます。
「dist」ディレクトリ以下のコードは変換された結果であるため、バージョン管理の対象にはしたくないのですが、それではHerokuへのデプロイ時の対象からも外れてしまいます。
デプロイ用のブランチを作るなどいくつか方法はあるのですが、今回はHeroku上でビルドを実行する方法をとっています。

HerokuにNode.jsのプロジェクトをデプロイした際に、package.jsonに記述されたnpmが自動でインストールされるのですが、その後に「gulpfile.js」に定義したタスクを実行することができます。
方法は簡単で、「package.json」の「postinstall」を追加するだけ。

"scripts": {
  "start": "node ./bin/www",
  "postinstall": "gulp build"
}

これで、Heroku上で依存パッケージのインストールが完了した後に、gulpのビルドタスクが実行されます。
注意点としては、通常開発のみに利用するパッケージは「devDependencies」に記載するのですが、「Dependencies」に記載する必要があります。
Heroku上では、「Dependencies」に記載されたパッケージのみがインストールされるためです。


ES6の仕様が承認されたことにより、ブラウザなどの対応が今後加速していくことが予想されます。
しかし、Babelなどを用いることで今からでもES6を用いた開発を行うことが可能です。
ES6の新機能を用いることでより簡潔に安全なプログラムを書くことができるようになるため、積極的に利用してもよいのではと考えています。

2015年7月16日 (木)

【Herokuお絵かき】Herokuってな~に?

こんにちは、なかやまです。

この間のキャラクターが気に入ったので、引き続き使いまわします。

Heroku_01

 

キャラクター紹介

たろう

Heroku_02

 

じーちゃん

Heroku_03

 

#1 Herokuってな~に

インターネット中のたろう。

Heroku_04

 


とても素敵なアイデアが浮かんだようです。

Heroku_02

 

早くみんなに見せたくて仕方がありません。

Heroku_06

 

じーちゃんに聞いてみよう!

Heroku_07

 

Herokuの何がよいの?

Heroku_05

 

アプリ開発すると、インフラ構築にも人が必要だけど、、

Heroku_09

 

Herokuを使うと、インフラ部分はHerokuがやってくれるらしい。

Heroku_10

 

インフラ部分を面倒見なくて良い分、アプリを作ることだけに集中できるよね!

Heroku_08

 

だいたいのプログラム言語は動きます。

Heroku_12

Herokuが提供しているBuilpack(Herokuの環境のようなもの)

Ruby、Node.js、Coljure、Python、Java、Gradle、Grails、Scala、Play、PHP

https://devcenter.heroku.com/articles/buildpacks#default-buildpacks

最近はgoもはいったよ。

 

便利アドオンもいっぱい

Heroku_13_2

 

開発環境が無償で使えます。

ただし、1日6時間は休止させないといけませんが、普通に開発する分には問題なし。

Heroku_14

 

24時間稼動させたい場合は、$7でFreeからHobbyにプランを変えましょう!

Heroku_15

 

Heroku_16

 

今のリージョンはUSとEUにしかないのですが、

TOKYOリージョンができたらすごく便利だよね!ね!

Heroku_17

日本からの距離が遠いのでレイテンシ(遅延)が発生するそうです。

近場の日本にリージョンが欲しいですよね。

 

記事を書いている現在、142人の賛同者があつまっております!!

東京リージョンまってるよ!という方は、こちらも参加いただくとよいかも。

We ask for the Tokyo region of Heroku/東京リージョンに対応してください #heroku

 

 

私のHerokuの認識ってこんなかんじなんですけど、

あってますか?

Heroku_13_2

 

 

 

 

フィードバックいただけるとうれしいです。m(_ _)m

Heroku2_2_14

おたより(なかやま直通)

2015年7月 8日 (水)

麻婆春雨はじめました。Bluemixもはじめました。

はいどうも。 最近、麻婆春雨の作り方を訓練中のおっぴーです。

暑い夏にむけて、いいですよね、マーボー。 食欲をそそるごま油の香り、ピリッと爽快な辛さ、そして、少し濃い目の味。 夏でもご飯の最高のお供ですよね。 麻婆春雨と白いご飯でこれから来る夏でも夏バテ知らず、でゆきたいと思います。

ということで、今回はBluemixのご紹介です。

BluemixはHerokuのアドオンではありません。

IBMが提供するPaaSであり、Herokuの後発サービスにあたる競合サービスです。 競合サービスとして、調べる機会があったのでまずは基本のキ、アプリケーションのデプロイ、Herokuでいうところの

git push heroku master

を行うところまでを紹介したいと思います。

このチュートリアルを実行するまえには、このページにしたがってBluemixのフリートライアル用アカウントを作成してください。

さて、Bluemixのウリの1つはwatsonというIBMが誇るコグニティブコンピューティングの機能をAPIとして利用できることです。 そのAPIの1つであるPersonality Insightsのチュートリアルが紹介されているページを発見したので、これで試してみましょう。 このチュートリアルを完了すると、文章からその人の性格をわりだす、というサービスができあがります。

なお、Bluemixのフリートライアルアカウントの作成以外にも事前準備が必要な点があるかもしれません。 下記の手順でうまくいかない!など、お困りでしたらコメントをいただけると幸いです。

まずはCloudFoundryCLIのインストール

BluemixはSoftlayerというIaaSサービスを基盤として、Cloud Foundryを利用して構築されているPaaSです。

このため、デプロイにもCloudFoundryのCLIが提供するコマンドを用います。 なお、Bluemixのコンソール画面でも、アプリケーションを作成する際に、CloudFoundryをもちいるか、などを選択する箇所があります。

まずは、CloudFoundryのCLIのgithubから利用しているOSにあわせてStable Installersのなかから選んでダウンロードします。 ダウンロードをしたら、インストーラーを実行しましょう。

インストールが完了したら、ターミナルを立ち上げて下記のようにcf -v(CloudFoundryCLIのバージョンを表示)コマンドを打ってみましょう。

cf -v

下記のように表示されれば、正常にインストールされています。(※表示されている日時は実行時に変化します)

cf version 6.11.3-cebadc9-2015-05-20T18:59:33+00:00

次にBluemixを利用するために必要な初期設定を行います。

下記は、localeを日本語に設定しています。 デフォルトが英語になっているのですが、むしろ、そのほうがエラー内容から解決策が検索しやすかったり、設定してもメッセージが英語のままだったりするのであまり意味はないかもしれません。(が、設定できるよ、ということで紹介します。)

cf config --locale ja_JA

次はCLIを通じてアクセスするapiのエンドポイントを設定します。 APIのエンドポイントは、リージョン(現在は、米国と英国のみ)によってドメインが変わります。 今回は、米国のリージョンを利用したので、下記のように設定しました。

cf api https://api.ng.bluemix.net

次に、上記のエンドポイントのどこにあるアプリケーションを扱うのか、loginコマンドで指定します。

cf login -u アカウント名(Bluemixアカウント作成時に登録したメールアドレス) -o 組織名 -s スペース名

上記で何を入力するのか、という点は下記をご参照ください。

Ibm_bluemix_1

コマンドを実行するとパスワードの入力を求められますので、入力します。 認証が成功すると、APIのendpointや組織名やスペース名、などが表示されます。 一連の流れは下記のように、表示されます。

API endpoint: https://api.ng.bluemix.net

Password>
Authenticating...
OK

Targeted org 組織名

Targeted space スペース名

API endpoint:   https://api.ng.bluemix.net (API version: 2.27.0)
User:           アカウント名
Org:            組織名
Space:          スペース名

以上で、Cloud FoundryのCLIの導入と初期設定は完了です。

アプリケーションをつくる

アプリケーションの作成もサービスの追加も、コンソールから簡単に行えます。

まずは、「Cloud Foundryアプリ」の「アプリの作成」をクリック。

__ibm_bluemix2

今回はWebアプリを作成するので「WEB」を選択します。

__ibm_bluemix3

その後、プログラミング言語を選択します。今回はサンプルアプリケーションがnode.jsですので、それを選択しましょう。

__ibm_bluemix4

プログラミング言語を選択すると、下記の画面が表示されるので「続行」をクリックしましょう。

__ibm_bluemix6

最後にアプリ名を入力し、「完了ボタン」をクリックすればアプリケーションの作成は完了です。

__ibm_bluemix7

サービスを追加する

サービスの追加も同様にコンソールからやってみましょう。

まずはダッシュボードにもどり、作成したアプリケーションのアイコンをクリックしましょう。

__ibm_bluemix8

画面が切り替わったら、「サービスまたはAPIの追加」をクリックします。

__ibm_bluemix9

サービスの一覧が表示されますので、そこから「Personality Insights」をクリックします。

__ibm_bluemix10

どのスペースのどのアプリにサービスを追加するか、などが表示されますので、確認したのち「作成」をクリックします。

Personality_insights__ibm_bluemix11

最後に、アプリケーションを再ステージするか、の確認が行われますので、再ステージを押下します。

__ibm_bluemix13

これでPersonality Insightsが有効になります。

プログラムをデプロイする

さて、Personality Insightsのチュートリアルが紹介されているページの内容に戻ります。 まずは、githubからコードをcloneします。

git clone https://github.com/watson-developer-cloud/personality-insights-nodejs.git

次に、cloneしたディレクトリに移動して、manifest.yml を編集します。 これは、Bluemix上にデプロイするアプリケーションについての設定ファイルです。 manifest.yml自体は、Cloud Foundryの機能の一部ですので、詳しくはこちらあたりをご参照ください。

cd personality-insights-nodejs
vi manifest.yml

編集はそれほど面倒ではありません。 applicationsのnameをアプリ作成時のアプリケーション名に、servicesは追加したサービス名を記載します。

declared-services:
  personality-insights-service:
    label: personality_insights
    plan: 'IBM Watson Personality Insights Monthly Plan'

applications:
- name: 登録したアプリケーション名(※ここ編集します)
  command: node app.js
  path: .
  memory: 256M
  services:
  - 追加したサービス名(※ここ編集します)

ちなみにサービス名ですが、コンソールの下記の画面から確認できます。

__ibm_bluemix14

さて、編集が完了したらデプロイしましょう。 デプロイコマンドはcf pushです。さっそく打ってみましょう。

cf push

pushがうまくゆくとデプロイが開始されます。 デプロイ中はいろいろと表示されますが完了すると下記のような画面が表示されます。

Bluemix15

さて、urlsに表示されているURLにアクセスしてみましょう。 画面が表示されたら、デプロイは無事完了です。

Personality_insights16

最後の方は駆け足になってしまいましたが、Bluemixもアプリの作成から高機能なサービスの利用、デプロイが簡単できることはご理解いただけたのではないでしょうか。 サービスの料金体系は?リージョンは?Herokuとくらべてどうなの?など気になることはたくさんありますが、それはまた別の機会にご紹介したいと思います。

補足

ちなみに当初はこのURLで紹介されているチュートリアルを実行する予定でした。 が、途中まで行ったところで、Uesr ModelingがPersonality Insightsにサービス名が切り替わった(と思われる)ことに気づきブログの内容を変更しました。

ドキュメントはしっかりされているようなのですが、突然の変更によるハマりポイントもまだまだありそうな予感です。

2015年7月 2日 (木)

HerokuとGitHubの連携を考える

こんにちは、浅野です。

今日は、8月以降に始まる開発案件(Heroku上にWebアプリを乗せる)でこんな風に開発を進めよう、と考えている開発のフローについて書きます。

目的

このPOSTでは、GitHubのリポジトリとHerokuを使った開発で、手動でのHeroku環境へのデプロイを減らしつつ、開発・テスト等の活動の並行性を維持するために、HerokuのGitHub連携機能をどう使うか、を整理します。

書くこと

Heroku上に乗せるアプリは以下の3つの環境を用意する想定です。

  • dev 開発環境。開発の最新版
  • staging 検証環境。リリース候補のテストを行う
  • production 本番環境。リリースされたもの

これらの環境に、いつ、なにを、どうやってデプロイするのかを考えます。

ブランチ戦略

何をデプロイするか、はブランチ戦略に密に関わってくるので、まず想定しているブランチ戦略を書きます。

ブランチ戦略は基本的にgit-flowを踏襲します。 git-flowについてはこちら(A successful Git branching model を翻訳しました)が詳しいです。

踏襲しない所 * 元々はサポートブランチになっている release ブランチを、メインブランチと同じくずっと存在し続けるものとします(理由は後述します)。混同を防止するために名前をstagingブランチとします。 * hotfixブランチは上記の変更に伴って、stagingブランチから作ってマージする。

各ブランチ間での変更の取り込みは、全てプルリクエストを介して行うように想定します。

図にすると下記のようなイメージです。

ブランチ間の関連図

Branching


デプロイ戦略

メインブランチのデプロイ

基本的に、それぞれの環境に対応するブランチに対してプルリクエストが受け付けられたタイミングで自動デプロイするようにします。 これは、それぞれの環境に対応するHerokuアプリケーションを作って、GitHub Integrationの automatic-deploysを設定します。

各環境とブランチ、アプリ名の対応は以下のようにします。

環境対応ブランチアプリ名
devdevelopdev-xxxxxx.herokuapp.com
stagingstagingstaging-xxxxxx.herokuapp.com
productionmasterxxxxxx.herokuapp.com

ここで「後述します」と言っていたreleaseブランチをメインブランチ相当にする理由を説明します。 git-flowを踏襲すると releaseブランチはリリースの度に作られて消えてしまいます。Herokuの automatic-deploys で指定するブランチが都度作られて消えてだと毎回設定を変える必要あるので、 設定そのままで自動デプロイするためにstagingブランチをずっと保持し続けるようにしています。

サポートブランチのデプロイ

サポートブランチの自動デプロイは ReviewAppを使ってデプロイします。 このReviewAppは、dev環境のHerokuアプリケーションに設定して、DB接続先などの環境変数情報はdev環境のアプリケーションと同じ値を使用します。

少し悩ましいのは、development -> staging, staging -> master といったメインブランチからメインブランチへのプルリクエストもおそらくReviewAppで対応するHerokuアプリケーションが作られてしまう事ですが、マージされたタイミングでアプリが消滅するので気にしない事にします。

これを先ほどのブランチ戦略の図に重ねるとこのようになります。

ブランチ・デプロイの図

Deploy


まとめ

HerokuのGitHub Integration機能を使うとこのようにGitリポジトリのブランチとHeroku上のアプリケーションを自動で同期させることが可能です。「デプロイする」行為をほぼ意識しなくて済むのは楽でいいですね。

2015年6月24日 (水)

Herokuで静的コンテンツをホストしたい

こんにちは、三宅です。
フレクトでは、お客様への提案や短期間でのプロジェクトでは、なるべく早い段階から動くアプリケーションのイメージを持ってもらえるように、HTMLで作った静的コンテンツでデモやモックを作成することが多くあります。
そんな時、変更のたびにファイルをやり取りしているのではスピード感に欠けるため、Herokuにコンテンツをホストしてオンラインで確認してもらえるようにしています。
今回はそんな静的コンテンツを簡単にHerokuにホストするためのアセットの紹介となります。

flect-miyake/node-static-server

node-static-serverは静的リソースをホストすることを目的とした、シンプルなWebサーバです。
静的リソースをディレクトリに配置、コマンド1つでローカル環境にWebサーバを起動し、その動作を確認することができます。
Heroku上で動かすこともできるため、デモ環境の構築や複数のメンバー間でのWebデザインの確認などに用いることも可能です。

Deploy

Herokuへのデプロイ

Herokuボタンをクリックすると、自分のHerokuアカウントにデプロイし、動かすことができます。

ローカル環境での編集

任意のディレクトリに移動し、Herokuに作成されたアプリをローカルにクローンし、編集することができます。

heroku git:clone --app アプリ名

BASIC認証の設定

Herokuに公開の際に、アクセスできる人を制限するためにBASIC認証を設定することができます。
basic-auth-connectを使い、プロダクション環境でユーザ名とパスワードが設定されている時に、BASIC認証が有効になるようにしています。

Herokuの環境変数として

  • BASIC_AUTH_USERNAME
  • BASIC_AUTH_PASSWORD

上記の2つを設定することで、BASIC認証が有効になります。

ローカル環境での利用

ローカル環境へのクローン

$ git clone https://github.com/flect-miyake/node-static-server.git

Gitを用いて、ローカル環境にリポジトリをクローンします。

npmパッケージのインストール

Gitによってクローンされたディレクトリに移動し、npmパッケージのインストールコマンドを実行します。

$ cd node-static-server
$ npm install

node-static-serverはExpress4を用いています。

静的リソースの配置

publicディレクトリに、静的リソースを配置します。
Webサーバ起動時は、publicディレクトリがルートディレクトリとなります。

サーバの起動

リポジトリのルートディレクトリで次のコマンドを入力すると、Webサーバが起動します。

$ npm start

ブラウザからlocalhost:3000にアクセスすることで、publicディレクトリに配置されたコンテツを確認することができます。

Herokuの料金体系が変更となり、無料でWebサイトを公開するサーバとして使うことは難しくなってしまいましたが、デモやモックの共有や開発ではそのスピーディーさや手軽さを存分に生かすことができると思います。

続きを読む "Herokuで静的コンテンツをホストしたい" »

2015年6月17日 (水)

なかやまがゆくHeroku本社への道 no.3~Herokuコマンドお絵かき~

こんにちは、なかやまです!

Heroku2_1_01_3

 

「なかやまがゆくHeroku本社への道 no.3」というタイトルですが、

Heroku本社に行くためにはHerokuの知識は必要ですよね!

ということで、今回はHerokuアプリを作るための基礎となるHerokuコマンドについて振り返ってみました。

Heroku2_2_02

 

 

heroku toolbeltをインストールする!

Heroku2_2_03

herokuアプリを作るためには、heroku toolbeltのインストールが必須です!

自分のOSにあったものをインストールしてくださいね。

heroku toolbelt

herokuコマンドでgitを使うのですが、gitのバージョンが低いと警告がでます。

gitは1.9.5以上が推奨ですので、gitのバージョンも合わせて確認しましょう。

 

 

heroku login!!

Heroku2_2_04

heroku toolbeltのインストールができたら、heroku loginをしてみましょう!

作成したHerokuアカウント情報を途中で入力していきます。

メールアドレスとパスワードは間違えないように。。

https://devcenter.heroku.com/articles/heroku-command#logging-in

 

 

heroku --version

Heroku2_2_05

ツールのバージョンがわかるコマンドです。

https://devcenter.heroku.com/articles/heroku-command#installing-the-heroku-cli

 

heroku keys:add

Heroku2_2_06

鍵ファイルを追加するときに使います。

heroku loginをした際に追加しているはずですが、あとから追加することもできます。

https://devcenter.heroku.com/articles/keys#adding-keys-to-heroku

 

 

heroku create

Heroku2_2_07

herokuアプリを作るときに呼ぶコマンドです。

heroku createの後にアプリ名を指定します。アプリ名はユニークにする必要があるので、すでに存在していると怒られます。

名前を指定しない場合はherokuが命名してくれます。

あとからアプリ名を変更することもできるので、安心ですね。

https://devcenter.heroku.com/articles/creating-apps#creating-a-named-app

 

 

git push heroku master

Heroku2_2_08

これはherokuじゃなくてgitコマンドになりますが、作ったアプリを公開するコマンドです。

このコマンドを入力することで、ローカルで開発していたアプリケーションがherokuに展開されます。

リリースしたアプリケーションに問題がある場合は、ロールバックすることもできます。

https://devcenter.heroku.com/articles/releases#rollback

Heroku2_3_01_2


 

 

heroku addons:create

Heroku2_2_10

アプリにアドオンを追加するコマンドです。

ログ監視のPapertrailを追加する場合は、以下のようなコマンドになります。

heroku addons:create papertrail

アドオンの詳細画面の下のほうにコマンドがかいてあるので参考にしてみてください。

Papertrail_addons_heroku

https://devcenter.heroku.com/articles/managing-add-ons#creating-an-add-on

 

 

heroku addons:open

Heroku2_1_11

アドオンのダッシュボードを開くときのコマンドです。

ログ監視アプリであればログ情報の確認ができます。

heroku addons:open papertrail

https://devcenter.heroku.com/articles/managing-add-ons#open-an-add-on-dashboard

 

 

heroku apps:info

Heroku2_2_12

アプリの情報を見るコマンドです。

girリポジトリ、所有者、リポジトリサイズ、スラグサイズ、スタック、アプリのUrlを見ることができます。

https://devcenter.heroku.com/articles/using-the-cli#app-commands

 

 

今回は基本的なコマンドをご紹介しました。

Heroku2_2_13

これらのコマンドはHerokuのコンソールからも設定できるようになっています。

便利ですね。

 

 

 

フィードバックいただけるとうれしいです。m(_ _)m

Heroku2_2_14

おたより(なかやま直通)

2015年6月10日 (水)

CloudDesignPattern、それってHerokuでもできますよ!あ、でもそれはできません。

どうも、最近Herokuの勉強をさぼりがちのおっぴーです。 そのため今回は、「試してみた!」という内容ではなく、主観が多く含まれる内容となっております。

さてHerokuの勉強をサボっているさなか、改訂版が出版されたAmazonWebServiceの『クラウドデザインパターン設計ガイド』を週末に読みました。

クラウドデザインパターンを読んでいる(かつ、操作もしてみる)と、

  • Webサービスを運営するためのサーバー群の調達が早くできる
  • サーバー、ネットワーク、DBなど各コンポーネントに拡張性がある
  • IaaSのトップランナーとして進化し続けている

という点をしみじみと感じます。 実サービスでAWSを利用することが一般的になってきた今、いまさらな感想ですが、本当に便利なサービスだと感じます。

なにか新しいサービスを始めよう!と思った時に、まずはサービス規模を想定し、CPU、メモリ、ハードディスクの容量を予測し、消費電力を考え、回線使用量を見積もり、、、 それが終われば、各業者に相見積もりをとって、、、といったことを作業にまつわる悩みが減らせることは大きなメリットです。 さらにCloudDesignPatternというサーバー構成のパターン集は、ある特定の状況における十分に検証された解決策なので、「こんな問題に対処したいのだけど、どんなサーバー構成にすれば良のだろう?」と悩む時間を減らせます。

このことにより、「こんなサービスを始めよう!」と決めてから、「つくってみた!」までの期間を短くできます。意思決定から結果にいたるまでの時間が短くなることはビジネスのアジリティをあげることに直結します。

このように考えると、PaaS、Herokuの魅力とは、IaaSよりもさらにサービスの構想段階で悩むことを減らせる、というものだと感じています。 なぜならば、Herokuはサービスとして、いくつかのCloudDesignPatternに対応済みの環境を提供しているからです。

たとえば、CloudDesignPatternの基本パターンで紹介されている5つのパターンのうち、ScaleUpパターンScaleOutパターンはもちろん、可用性のパターンで紹介されるMulti-Serverパターンは、提供されているコンソールから2,3クリックで完了してしまいます。 また、動的コンテンツの処理パータンであるScheduled Scale OutパターンAPIと無料のAddOnであるHerokuSchedulerを組み合わせると簡単に設定できてしまいます。

くわえて、Ondemand Activationパターンのような機能は、One-Off Dynoが提供しています。

さらにさらに、CDPではありませんが、AWSをはじめとしてIaaSを利用することでサーバーの調達とセットアップの手軽になったことから実現できるようになったBlue-GreenDeployはどうでしょうか? これもPrebootという仕組みやAPIからリリースをロールバックできることから、簡単に実行できます。

いやいや、「Herokuではこんなことができないでしょ?AWSではできるけど」という部分はもちろんあります。 たとえば、有償のAddOnを利用しないと、HerokuではAutoScaleができません。LogAggregationパターンについても、Papertraillogentriesなどの有償AddOnの利用が必要です。 さらに、メモリやCPUの選択肢はほとんどないといって良いと思います。たとえば、10GB以上のメモリが必要になるシステムを動かしたい!と考えるとHerokuは選択肢に入りません。 Herokuでスペックが一番良いPX Dynoでも6GBまでしかメモリの提供がされていないからです。

Herokuを選択することはCloudDesignPatternに対応済みの環境を享受できる一方で、AWSなどのIaaSにある自由度や選択肢が狭めることになるのは事実です。 一方で、強引に良い方向に考えると、そもそもできないことは悩む必要がなくなる(というより、これもやりたい、という点を切り捨てる)、という点でもWebアプリケーションをつうじてサービスを提供したい、というゴールに到達するための悩みが減らせる、といえます。

上述したように、IaaSやPaaSに感じるメリットは、サービスが提供する拡張性を前提として「開発の前の悩みがすくなくなる」ことから、ビジネスのアジリティをあげられるというです。 ですので、IaaS?PaaS?、AWS?Heroku?など、どちらを選べばよいの?ということをお悩みなら、「どれだけ最初に悩むことを減らしてWebアプリケーションを利用したサービスを提供したいか」を軸に検討してみるのはいかがでしょうか。

たとえば、Ruby on RailsやSpringBootのようなWebアプリケーションのフレームワークを用いて開発を行うようサービスは、まずはHerokuを利用することを考えて良いと思います。 もちろん、厳しい非機能要件があらかじめ想定される場合は、おすすめできない部分もありますが、アイデアベースのサービスをはじめたい、という場合ならオススメできます。

ちなみに、Herokuのプラットフォームの背後にはThe twelve-factor appという考え方があります。 もしも、Herokuを検討する場合は、現状の機能がなぜこうなっているのか、今後はどのように発展しそうか、という点の参考になりますので目を通しておくと良いと思います。

あと、AWSにはElastic BeanstalkというPaaSに類するサービスもありますね。 これとの比較はまたこんど。(できたらいいな)

2015年6月 3日 (水)

Review Apps を試してみた の巻

こんにちは、浅野です。 前回からだいぶ時間が空いてしまいましたが、予告していたPullRequest Deploy改め Review Appsを実際に実行した手順を紹介します。

作業の流れ

今回の検証は以下の流れで作業をすすめました。

  1. 同期元Githubリポジトリを作成
  2. 同期先Herokuアプリの作成
  3. Github Integrationの設定
  4. PullRequestを送る

同期元Githubリポジトリを作成

まずGithubリポジトリを作ります。 今回は、heroku-pullrequest-deployのリポジトリを作りました。

同期先Herokuアプリの作成

ここでは、Herokuアプリを作成と、次ステップで app.json の生成ウィザードの挙動を確認する為に addon追加、環境変数の追加を行います。

herokuアプリの作成

herokuダッシュボードからgithub-pr-deploy-sample を作りました。(以降、実際に試される方はご自身のアプリ名に差し替えてください)

addonの設定

開発で馴染みのある下記2種類のアドオンを追加します。

  1. Heroku Postgresql
  2. Redis Cloud

この2つのアドオンを追加すると、下記の環境変数が自動的に追加されます。

  1. DATABASE_URL
  2. HEROKU_POSTGRESQL_BRONW_URL (BROWN部分は環境によって異なります)
  3. REDISCLOUD_URL

環境変数の追加

自動で追加される環境変数の他に、手動で追加した環境変数がapp.jsonの生成ウィザードでどう扱われるかを検証する為に手動で環境変数を設定します。環境変数名はHOGEHOGE, 値は piyopiyo とします。

Github PullRequest Deployの設定

ここからが本番。 PullRequest Deployを設定します。 ゼロの状態から始めるには以下の手順になります。

  1. 同期対象Githubリポジトリの選択
  2. PullRequest Deployの設定
  3. app.jsonの生成

同期対象Githubリポジトリの選択

まずは、HerokuからGitHubへアクセスする設定を行います。

Herokugithubdeploy


  1. Deployタブを選びます
  2. GitHubを選びます
  3. Connect to GitHubをクリックします

(初めてGithub Integrationを使う場合は、Githubで Heroku Dashboardアプリからのアクセスを許可するかの認証がでます。)

続いて、同期対象となるGithubリポジトリを選択します。

Herokugithubconnectrepo


  1. 対象となるリポジトリのオーナを選択(今回は yuasano )
  2. 対象となるリポジトリを検索
  3. 対象となるリポジトリの connect をクリック (今回は heroku-pullrequest-deploy )

PullRequest Deployの設定

続いて、PullRequest Deployを有効にします。

注意書きが2点あるので気をつけてください。 大胆に意訳すると

  1. PullRequest Deployは、development/test環境で使う想定で、production環境で使うことは推奨しない。
  2. PullRequestで生成されるアプリの Dyno Hour / Addon もこのユーザの課金対象となる

のような感じです。 問題なければ Enable Pull Request Deploys をクリックします。

次に自動デプロイを有効にします。今は、PullRequest Deployに必要な app.json がリポジトリにないので設定を有効にできないので、app.jsonを作成するウィザードが呼び出せるのでそちらを使って app.json を作成します。(作成は次ステップ)

Executeappjsonwizard


  1. Create new apps for new pull requests automatically にチェックを入れる
  2. リポジトリに app.json がないので設定できない、との旨のメッセージが表示される
  3. Create an app.json File... をクリック

app.jsonの生成

app.jsonの生成画面が開いて、app.jsonのスキーマ の必要最低限の項目が並んでいます。

今回は、環境変数の共通化を見てみたいのでEnvironment の箇所だけを変更して、リポジトリへapp.jsonを登録します。

Environmentの変更

環境変数のリストに DATABASE_URLHOGEHOGE それぞれどのように扱うかを指定します。

Editappjson_2


  • DATABASE_URL は Copy at build time
  • HOGEHOGE は Generate Secret

リポジトリへの登録

Output の箇所に、生成される app.json のプレビューが表示されているので、これを確認して問題なければ Commit to Repo and Enable Pull Request Deploys をクリックします。

これで、GitHubリポジトリのmasterブランチ(defaultブランチ)にapp.jsonがコミットされます。

補足

なお Config Varsのプルダウンで選択できる4種類は以下のように使い分けるのだと理解しています。

  • Copy at build time … ビルド(アプリを作る時)にその環境変数の値をコピーする。親アプリの環境変数の設定値をコピーする場合はこれを指定する。
    • Copy now ... 現時点での親アプリの環境変数の設定値をコピーします。選択すると警告が表示される通り、ここで入力した値は app.json に直接記載されてバージョン管理下に置かれるので、見られたくない情報は書かないでください。
    • Set value ... 右側テキストボックスに入力した文字列を設定します。これも Copy now同様 app.jsonに直接記載されるので取り扱い注意です。
    • Generate Secret ... ビルド(アプリを作る時)に生成されたランダムな文字列が設定されます。Ruby On Railsの SECRET_KEY_BASE などはこれを使うのだと思います。

PullRequestを送る

このリポジトリに対して送ったPullRequestがこちらです。

Pullrequestdeploy


リスのアイコンで、2回Herokuにデプロイされている様子がわかります。 1回めはPullRequestを送った直後のデプロイです。この時点ではこのアプリが動いておらず(InternalServerErrorが出ていた)、原因を調べたところ、 config/secrets.yml ファイルが .gitignore に含まれていてリポジトリに格納されていなかったのが原因でした。

これを修正してpushしたところ、自動的に github-pr-deploy-sample-pr-1 へのデプロイが動いて、無事問題が解決していることが確認できました。

このPullRequestをマージすると、 github-pr-deploy-sample-pr-1 アプリは削除されて Dashboardからも消えました。

PullRequestと自動で同期してくれるのは非常に便利で助かるな?と思いました。

みなさんも是非使ってみてください。

公式情報ソース

Heroku Review Apps Beta

2015年5月27日 (水)

Heroku基礎トレーニング 開催中

こんにちは、浅野です。

次はPullRequest Deployの手順について書くよ、と宣言したものの別のポストです、ごめんなさい。 (PullRequest Deployは Review Appsという名前が与えられたみたいです)

今回は、Salesforceさんが主催されているHeroku基礎トレーニングを紹介します。

というのも、5月22日(金)に、私がこのトレーニングの講師を担当させていただいていたのです。

このブログを見てくださる方は、Herokuに興味をお持ちの方だと思うので、 そういった方が「そのトレーニング、ここはどうなっているの?」 と疑問に思われる事に回答します。

どうしてSalesforceさんが開催される教育をFlectが?

Salesforceさんとはお仕事で密接な関係があり、Herokuのテクニカルなテーマでは何かとお手伝いさせていただいている御縁で協力させていただいております。昨年末に開催された、Salesforce World Tour TokyoのHerokuブースもFlectメンバーが協力していました。 @herokujpのPOST

このトレーニングの講師は、FlectでHerokuを使ったシステム開発を担当しているメンバーが務めています。

受講する為に必要な前提知識は?

必須となる知識はありません。講習の内容の理解をより深めるには下記の3つです。

  1. gitの基本的な操作(リポジトリをクローンする、変更をコミットする、リモートリポジトリへ変更をプッシュする)
  2. Java(演習で簡単なJavaのWebアプリケーションをつくるため)
  3. Windowsのコマンドプロンプト操作

どんな事をやっているの?

4章で構成されており、それぞれ以下のような内容になっています。

  • 第1章 Herokuの特徴・市場での位置づけ、Herokuを操作する環境の構築・アプリケーションのデプロイ
  • 第2章 Herokuの内部コンポーネントの動作
  • 第3章 Herokuのアドオン紹介
  • 第4章 Heroku開発でのトラブルシュート(開発編、運用編)

何ができるようになるの?

受講後には以下のようなことが可能になっている、と想定しています。

  • Heroku上に典型的なWebアプリケーションを作って公開する
  • 必要なアドオンが何かがわかる

でも、お高いんでしょう?

半日の講義で、受講料は3万円となっております。

会場はどんな感じ?

会場は、Salesforceさんのトレーニングルームで、とても綺麗な会場です。

Classroom1


教室の後ろには、 文房具やちょっとつまめるお菓子、空調が寒いと感じる方の為のひざ掛け等が用意されています。

Classroom2

こういった配慮は嬉しいですね。

会場のマシン環境はどんな感じ?

マシンはお一人様毎に1台、環境セットアップ済みのWindowsのノートPCが用意されています。 演習には問題のないスペックのマシンです。

演習時、自分で持ち込んだPCを使うのは可能?

環境が教室のマシンと違って演習が上手く進められない場合があるリスクはありますが、お使いいただいてもかまいません。

会場用のマシンには、JDK、Apache Maven, PostgreSQLがインストールされています。 (Herokuを操作するためのHeroku Toolbeltは演習時にセットアップします)

動作確認

それぞれ、下記のコマンドを実行してバージョンが表示されることを確認してください。

javac -version
mvn -version
psql --version

(psqlだけ、半角ハイフンが2つです。)

この他にもご質問ございましたら、ぜひコメント欄等でお知らせください。可能な範囲で回答いたします。

次回の開講は7月を予定しておりますので、興味のある方はぜひこちらをチェックしてみてくださいませ。

続きを読む "Heroku基礎トレーニング 開催中" »

2015年5月22日 (金)

なかやまがゆくHeroku本社への道 no.2

こんにちは。なかやまです。

今回も技術話ではないので、ゆるっと見てやってください。

Heroku2_01

前回の記事→no.1

順調に行けば、9月で終わるコーナーですが、今年行けない場合はさらに1年間続ける予定です。

Heroku2_02_2

パスポートの期限は大丈夫でした!2019年までチャレンジできそうです!

Heroku2_03_2

サンフランシスコに行ったことのある人に話を聞いてみる。

Heroku2_04_2

かに食べる、ゴールデンゲートブリッジに行く、チョコレートを買う。。

あと向こうで知り合って行動した人たちとは今も仲良しと聞いて、いいなぁと思いました。

(せっかくお会いしたのにWAZAの話を聞き逃しました。。)

Heroku2_05_2

そういえば、Salesforceユーザー会で自慢大会があるのですが、その景品がDreamforceご招待券だそうです。ユーザー会はSalesforceを利用してる会社さんが集まるコミュニティです。

(しかしパートナーが出て行くわけにもいかず、、Salesforceユーザーのみなさんはチャンスですよ~)

今年の「Dreamforceご招待」を手にするのは?

Heroku2_06_2

Herokuの日々のアップデートには感心します。

Salesforceは年3回なので、Herokuのupdateの速さについていくのが大変。

Heroku2_07_2

ちなみに、前回ポストのご案内をして終わったのですが。

なんと1通入ってました!(ありがとうございます!!)

Heroku2_08_2

なので今後も細々と続けていきます↓

Heroku_1_09

おたより(なかやま直通)

おたよりまってまーす!

なかやま。

採用情報

株式会社フレクトでは、事業拡大のため、
Salesforce/Force.comのアプリケーション
開発
HerokuやAWSなどのクラウドプラッ
トフォーム上でのWebアプリケーション開発

エンジニア、マネージャーを募集中です。

未経験でも、これからクラウドをやってみた
い方、是非ご応募下さい。

フレクト採用ページへ

会社紹介

株式会社フレクトは、
認定コンサルタント
認定上級デベロッパー
認定デベロッパー
が在籍している、
セールスフォースパートナーです。
heroku partnersにも登録されています。
herokuパートナー
株式会社フレクトのSalesforce/Force.com
導入支援サービス
弊社の認定プロフェッショナルが支援致します。
・Visualforce/Apexによるアプリ開発
・Salesforceと連携するWebアプリ開発
も承っております。
セールスフォースご検討の際は、
お気軽にお問合せください。
Powered by Six Apart