« 2015年6月 | メイン | 2015年8月 »

2015年7月

2015年7月30日 (木)

Wercker v2でHerokuっぽい環境を作ってテストを動かす

Wercker v2でHerokuっぽい環境を作ってテストを動かす

こんにちは、浅野です。

今日は、Dockerに対応したWercker v2(Ewok)でHeroku+Postgresqlっぽい環境を作ってテストを実行するまでの手順を紹介します。

言語は相変わらずJavaです。(Java8+Gradle)

Werckerとは

Werckerは、TravisCIやCircleCIのようなCIサービスです。 無償プランでGithubのPrivateリポジトリがビルドできるため、Flectではよく使用されています。

Wercker v2

元々はBoxと呼ばれる独自の実行環境を使っていたのですが、V2からは実行環境にDockerHubのイメージを指定するようになっています。

テストを実行するDockerイメージを作る

HerokuがDockerをサポートしたこともあり、DockerHub上にHeroku謹製のcedarイメージがあります。 これがそのまま使えるかと期待したものの、上手くいきませんでした。

原因は、heroku/cedar:14 に標準インストールされているJDKが 1.7.0_79 だったためです。 なので、 heroku/cedar:14 をベースにJDK8入りのイメージを作ります。

こんなDockerfileで作ったイメージをDockerHubへ登録します。 (DockerHubのここのタグ0.2にこれで作ったDockerイメージが置いてあります)

FROM heroku/cedar:14

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update
RUN apt-get -y install software-properties-common python-software-properties
RUN add-apt-repository -y ppa:openjdk-r/ppa
RUN apt-get update
RUN apt-get -y install openjdk-8-jdk

RUN update-alternatives --set java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
RUN update-alternatives --set javac /usr/lib/jvm/java-8-openjdk-amd64/bin/javac

wercker.ymlを書く

ここにテストを実行するための環境・テストの実行ステップを定義します。

ベースイメージを指定する

先ほどDockerHubにUpしたDockerイメージをBoxに指定します。

box: yuasano/heroku:0.2

Postgresqlを追加する

次にHeroku Postgresqlアドオン相当のものを追加します。Werckerでは外部サービスを追加する時は serviceを使います。 これは以下のようになります。 POSTGRES_USERは省略可で、省略した場合はpostgresユーザが作られます。

services:
   - id: postgres
     env:
       POSTGRES_PASSWORD: YOUR_PASSWORD
       POSTGRES_USER: YOUR_NAME

詳しくは公式ドキュメントを参照してください。

DB接続用の環境変数 DATABASE_URLを定義する

次に、HerokuPostgresで追加される環境変数DATABASE_URLを定義します。 これは、実行時に動的に決まる値なので、以下の環境変数群(どうもpostgresqlのDockerイメージがこういう環境変数を使うよう)を使って生成します。

POSTGRES_ENV_POSTGRES_USER=YOUR_NAME
POSTGRES_ENV_POSTGRES_PASSWORD=YOUR_PASSWORD
POSTGRES_PORT_5432_TCP_PORT=5432
POSTGRES_PORT_5432_TCP_ADDR=172.XX.X.XX

この値を組み合わせてDATABASE_URLを定義する手続きを、buildステップの最初に記述します。

build:
    steps:
        - script:
            name: set DATABASE_URL env
            code: |
                export DATABASE_URL="postgresql://${POSTGRES_ENV_POSTGRES_USER}:${POSTGRES_ENV_POSTGRES_PASSWORD}@${POSTGRES_PORT_5432_TCP_ADDR}:${POSTGRES_PORT_5432_TCP_PORT}/postgres"

Gradleのテストを実行するステップを作る

次に、 set DATABASE_URL envスクリプトの後にGradleのテストタスクを実行するステップを追加します。

- script:
    name: run test
    code: |
        ./gradlew test

これでWerckerV2の上で、Heroku+Postgresqlに近い環境でJava8+Gradleのテストが実行できるようになりました。

最終的に出来上がった wercker.yml は以下のようになります。

box: yuasano/heroku:0.2

services:
   - id: postgres
     env:
       POSTGRES_PASSWORD: mypage
       POSTGRES_USER: mypage

build:
    steps:
        - script:
            name: set DATABASE_URL env
            code: |
                export DATABASE_URL="postgresql://${POSTGRES_ENV_POSTGRES_USER}:${POSTGRES_ENV_POSTGRES_PASSWORD}@${POSTGRES_PORT_5432_TCP_ADDR}:${POSTGRES_PORT_5432_TCP_PORT}/postgres"
        - script:
            name: run test
            code: |
                ./gradlew test

Heroku謹製のcedarイメージがDockerHubに置かれて、よりHeroku環境に近い環境でテストができるのは安心ですね。(Cedar14がベータの頃にHerokuにデプロイした時だけ動かない機能があって、原因がCedar14側だった経験があるので...)

続きを読む "Wercker v2でHerokuっぽい環境を作ってテストを動かす" »

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上のアプリケーションを自動で同期させることが可能です。「デプロイする」行為をほぼ意識しなくて済むのは楽でいいですね。

採用情報

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

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

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

フレクト採用ページへ

会社紹介

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