まっしろけっけ

めもてきなやーつ

技術書をまとめ買いしたよ

ネタがあまりないので雑談
なぜか2週間くらい暇になり、
なぜか会社でRubyを教えたm君にAmazonギフト券を貰ったので
3冊ほどまとめ買いしたものと最近読んだ1冊をまとめておく。
本当はkindleのセールの際に買おうと思ったのだがセールが終わってしまい買えなかったので
このタイミングで買った

買った本

自分はインフラエンジニアではないが、いろいろやったりしているので
一般的なインフラエンジニアと認識の違いがないかを知りたかったので基本的な本を選んでみた。
大きな認識の違いがなかったが、細かい部分を知れたことと幾つかのコマンドやオプションを新しく知れたのでよかった。

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

ネットワーク関連があまり得意ではないので
勉強したくて読んでいる(もう少しで読み終わる)
図解が多くイメージがしやすい。

Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services パターン別構築・運用ガイド

AWSを知らないで許されるのは小学生までだよねー」と最近思っている(危機感を感じている)ので
買った上記のネットワーク本が終わったら読む予定

クラウドつながりでOpenStackも面白そうなので買った。

まとめ

インフラの本ばかりになってしまいましたが、
インフラエンジニアに転向する訳ではありません。
(いずれそっち方向に進むのは結構ありだと思っているけど)
Serverspec本を書い忘れていたので、
上記の本を読み終わったらServerspec本を購入する予定

golangのフレームワークkochaを使ってみた その2

shiro-16.hatenablog.com
こちらの続き

modelを作成する

今回はmysqlを使用します。
今回作成したtableは下記です。

CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

modelを自動生成する。

$ kocha g model user
    create directory app/model
              create app/model/user.go
    create directory db
              create db/config.go

dbのconfigの変更
デフォルトではsqlite3の設定が記述してあるようです。

$ vi db/config.go
- Driver: kocha.Getenv("KOCHA_DB_DRIVER", "sqlite3"),
- DSN:    kocha.Getenv("KOCHA_DB_DSN", filepath.Join("db", "db.sqlite3"))
+ Driver: kocha.Getenv("KOCHA_DB_DRIVER", "mysql"),
+ DSN:    DSN:    kocha.Getenv("KOCHA_DB_DSN", "user:password@/kocha"), // 各時の環境に合わせてuser名とpassword,db名を設定

modelを変更

$ vi app/model/user.go
- Id int64 `db:"pk" json:"id"`
+ Id   int64
+ Name string

controllerを作成

$ kocha g controller users
              create app/controller/users.go
              create app/view/users.html

controllerを変更

$ vi app/controller/users.go
func (us *Users) GET(c *kocha.Context) error {
        var users []model.User
        err := db.Get("default").Select(&users)
        if err != nil {
                return c.RenderError(500, nil, nil)
        }

        return c.Render(map[string]interface{}{
                "ControllerName": "Users",
                "users": users,
        })
}

viewを変更

$ vi app/view/users.html
<h1>This is Users</h1>

<ul>
  {{ range $.users }}
    <li>{{ .Name }}</li>
  {{ end }}
</ul>

動作確認

$ kocha run
kocha: you can be setting for your app by the following environment variables at the time of launching the app:

    KOCHA_ADDR="127.0.0.1:9100"
    KOCHA_DB_DRIVER="mysql"
    KOCHA_DB_DSN="user:password@/kocha"

Starting...

Listening on 127.0.0.1:9100
Server PID: xxxx

上記が表示されたら前回同様http://127.0.0.1:9100/で「Welcome to Kocha」が表示され
http://localhost:9100/usersで「This is Users」 + 「user.nameのリスト」が表示されます。

Routingに関しての補足

routingに関してはcontrollerを作成したときに自動で追記されていました。

var routes = RouteTable{
        {
                Name:       "root",
                Path:       "/",
                Controller: &controller.Root{},
        }, {
                Name:       "users",
                Path:       "/users",
                Controller: &controller.Users{},
        },
}

疑問 + その3に関して

1.Railsのshowとかその他get methodを追加したい場合とかは
各controllerのGETで処理を分岐させたりするのだろうか?

2.Migrationの機能もあるようなのでその辺の使い方

上記2点をその3で書ければいいかなと思っていますが、
その3に関しては未定です...mm

golangのフレームワークkochaを使ってみた その1

経緯

golangを学習し始めて2週間〜3週間くらい、
ちょっとわかってきたので
そろそろフレームワーク使ってみたいなと思い調べ始めた。
ちなみにgolangの学習は下記のページや書籍など

A Tour of Go
web上でさくっと出来る

Effective Go — プログラミング言語 Go ドキュメント v0.1 documentation
ドキュメントてきな

Go For Perl Mongers
すごくためになった

taizo - Qiita
会社の先輩のqiita初心者がつまずく点がいっぱいまとまってあった

Amazon.co.jp: 基礎からわかる Go言語: 古川 昇: 本
基本的なことはこれ読めばわかる気がする

kochaを選択した理由

Kocha web application framework for Go

サンプルをチラっと見た感じだとRailsっぽいじゃんという理由で要はなんとなくです。
強いて言うならRails好きだからです。ちなみに和製らしいです。

ほかにもmartini,revelあたりは使ってみようと思っているので後々記事を書くかもしれない。

serverを立ち上げる

$ go get github.com/naoina/kocha

これでkochaを取得してくる

$ go get github.com/naoina/kocha/cmd/...

これでkochaコマンドが使える

今回はアプリケーション名をexample-kochaで作成します。
※GOPATH部分は各自の環境によってかわります。

$ kocha new example-kocha
    create directory /GOPATH/src/example-kocha/app/controller
              create /GOPATH/src/example-kocha/app/controller/root.go
    create directory /GOPATH/src/example-kocha/app/view/error
              create /GOPATH/src/example-kocha/app/view/error/404.html.tmpl
              create /GOPATH/src/example-kocha/app/view/error/500.html.tmpl
    create directory /GOPATH/src/example-kocha/app/view/layout
              create /GOPATH/src/example-kocha/app/view/layout/app.html.tmpl
              create /GOPATH/src/example-kocha/app/view/root.html.tmpl
    create directory /GOPATH/src/example-kocha/config
              create /GOPATH/src/example-kocha/config/app.go
              create /GOPATH/src/example-kocha/config/routes.go
              create /GOPATH/src/example-kocha/main.go
    create directory /GOPATH/src/example-kocha/public
              create /GOPATH/src/example-kocha/public/robots.txt

初めてrails newした時と同じ気持ちを味わえましたね!

serverを立ち上げる

$ cd /GOPATH/src/example-kocha
$ kocha run
kocha: you can be setting for your app by the following environment variables at the time of launching the app:

    KOCHA_ADDR="127.0.0.1:9100"

Starting...

Listening on 127.0.0.1:9100
Server PID: xxxxx

これでhttp://127.0.0.1:9100/にアクセスすると
「Welcome to Kocha」が表示されると思います。

処理の流れをざっくりと追う

config/routes.go内で下記のようにrouting周りの記述されている。
routingを追加する場合はここに追記する感じになるっぽい

var routes = RouteTable{
        {
                Name:       "root",
                Path:       "/",
                Controller: &controller.Root{},
        },
}

Path(今回の場合は/)へのアクセスの際にControllerに格納された各controllerを呼ぶ。

Controllerのinterfaceがどのようになっているのかは下記を参照
https://github.com/naoina/kocha/blob/master/controller.go#L27-L64

HTTPの各methodでcontroller側のどのmethodを呼ぶかを解決しているのが下記
https://github.com/naoina/kocha/blob/master/router.go#L93-L121

今回の場合はapp/controller/root.goが対象のcontrollerになり
GETでアクセスしているので下記のmethodが呼ばれる。

func (r *Root) GET(c *kocha.Context) error {
        return c.Render(map[string]interface{}{
                "ControllerName": "Root",
        })
}

表示されているviewはapp/view/root.html.tmpl

ざっくりしすぎですがこんな感じ

今後

controller, model周りの実装もあるのですが
長くなりそうなのでその2にて書いていきます。

kochaのソースを読むと構成とかとても勉強になる
間違いがあればご指摘いただけますと幸いです。

画像の色解析を行うrmagick-image_colorsというgemを作った

経緯

shiro-16.hatenablog.com

こちら経緯にもある通りデザイナーさんに言われたことを実現するため。

rmagickというgemがあるのでそれの拡張的な感じで書ければいいなー
と思い設計してみた。

概要

rmagick-image_colors | RubyGems.org | your community gem host

github.com

画像のURLもしくはpathを指定し、
その画像で使われている画像の色を解析し
多い色の順番に配列としてカラーコードとpointを返してくれる

install

gemなのでgemコマンドでinstallできます。
Gemfileに追記でもおk

$ gem install rmagick-image_colors

※RMagickを使っているのでImageMagickが必要になります。

使い方
image_colors = Magick::ImageColors.new('spec/fixtures/test.jpg')
image_colors.colors
=> [["#9AAEC9", 5], ["#9DAEC8", 4], ["#FDFDFD", 4].......

test.jpgの猫は同僚の実家で買っているとら様です

まとめ

RMagickはCで実装されている部分が多いのでRuby読むよりつらい・・・
大きい画像だとパフォーマンスがひどいことになる・・・
作成した後にMagick::Image#colorsをC言語で実装して
issue作成して本体にpull request送ってあわよくば取り込んで貰うとかやった方が良かったのかもと思った。時間があればやってみたい。

色を扱うColorCodeというgemを作った

経緯

デザイナーさんに「こんなことやりたいんですけど・・?できます・・?」と聞かれ
ちょっと調べたら出来そうだったので「出来そうですよ!」と返事したらやることになった。

実装方法を考えてたら今回作成したようなロジックを思いつき
gemとして作ればいいんじゃね?ってなった。

設計も終わり作り始める直前に、もしかしたら同じようなgemあるのでは?と思いつき調べたら
colorというgemがあった。軽く見ただけだが同じような設計になっている気がした。
がしかしメンテされてない + 自分と他人のRubyのコードを比較する機会が
今の仕事てきな環境だと少ないので作ってからcolorの方のソースも読んで比較すれば
勉強になるかなと思って作ることにした。

※デザイナーさんがやりたいことはこのColorCodeと
これから作るもう一つのgemを使って行う予定

概要

color_code | RubyGems.org | your community gem host

github.com

RGBとHSL色空間を相互に変換出来るClassです。

install

gemなのでgemコマンドでinstallできます。
Gemfileに追記でもおk

$ gem install color_code
使い方

RGB class

rgb = ColorCode::RGB.new(r: 255, g: 0, b: 0)
rgb.to_s # => '#ff0000'
rbg.to_hash # => { r: 255, g: 0, b: 0 }
rgb.to_hsl # => #<ColorCode::HSL>

HSL class

hsl = ColorCode::HSL.new(h: 0, s: 100, l: 50)
hsl.to_s # => '#ff0000'
hsl.to_hash # => { h: 0, s: 100, l: 50 }
hsl.to_rgb # => #<ColorCode::RGB>

その他に関して後々examplesとかを追加しようと思います。
コード量が少ないのでコードを読んだ方が早い気もしますが・・・

まとめ

RGBはもちろん知っていましたが
HSL色空間に関して知識が乏しかったのでこの機会に学べたのはよかった。
たぶんcolorのgemを使っていたらそこまでHSL色空間を理解せずに使ってしまった気がする。
gemのcolorがどのように実装しているのかはこれから見るので実装の違いを見つけて
楽しもうと思いますw

初心者じゃなくても役に立つかもしれないRailsのroutingの記述方をまとめてみた

まとめようと思った経緯


と思って書き始めたのが1月の中頃
何を言っているのかわからねーと思うが
気づいたら違う記事をいくつか書いて公開していた。
(いつのまにかRuby2.2.1もリリースされていた・・・)

環境

Ruby - 2.2.1
Rails - 4.2.0

urlを直接指定する

get '/games',      to: 'games#index'
get '/games/:id',  to: 'games#show'
get '/games/test', to: 'games#test', as: :test

下記のようにも書ける

get '/games'      => 'games#index'
get '/games/:id'  => 'games#show'
get '/games/test' => 'games#test', as: :test

resource

scaffoldを使用した際にroutes.rbに追記される
複数のroutingを作成してくれやつ

resource :users

これだけで下記のようなroutingが生成される(簡単!)

Prefix Verb URI Pattern Controller#Action
users GET /users(.:format) users#index
POST /users(.:format) users#create
new_user GET /users/new(.:format) users#new
edit_user GET /users/:id/edit(.:format) users#edit
user GET /users/:id(.:format) users#show
PATCH /users/:id(.:format) users#update
PUT /users/:id(.:format) users#update
DELETE /users/:id(.:format) users#destroy
一部のroutingがいらない場合

resourceで作成されるroutingでindexとshowは必要だけどcreateいらないとかのパターンは
下記の用にonly,exceptで絞ることが可能

resource :sports, only: [:index] # indexのみ有効
resource :posts, except: [:index, :show] # index,show以外有効
向き先のcontrollerを変更

下記のようにcontrollerを指定することも可能
この場合「GET /hoge」へのリクエストが「users#index」に

resources :hoge, controller: :users
Prefix Verb URI Pattern Controller#Action
hoge POST /hoge(.:format) users#create
new_hoge GET /hoge/new(.:format) users#new
edit_hoge GET /hoge/edit(.:format) users#edit
GET /hoge(.:format) users#show
PATCH /hoge(.:format) users#update
PUT /hoge(.:format) users#update
DELETE /hoge(.:format) users#destroy
ネストしてみると・・・

resourceをネストしてみると下記のようなroutingが生成される
※結果が長くなってしまうのでonlyで絞っています。

resource :authors, only: [:index, :show, :create] do
  resource :books, only: [:index, :show, :create]
end
Prefix Verb URI Pattern Controller#Action
authors_books POST /authors/books(.:format) books#create
GET /authors/books(.:format) books#show
authors POST /authors(.:format) authors#create
GET /authors(.:format) authors#show
collection
resources :dogs, only: [:index, :show, :create] do
  get 'test1', on: :collection
  get 'test2', on: :collection
end

下記のようにも書ける

resources :dogs, only: [:index, :show, :create] do
  collection do
    get 'test1'
    get 'test2'
  end
end
Prefix Verb URI Pattern Controller#Action
test1_dogs GET /dogs/test1(.:format) dogs#test1
test2_dogs GET /dogs/test2(.:format) dogs#test2
dogs GET /dogs(.:format) dogs#index
POST /dogs(.:format) dogs#create
dog GET /dogs/:id(.:format) dogs#show
member
resources :cats do
  get 'test1', on: :member
  get 'test2', on: :member
end

下記のようにも書ける

resources :cats do
  member do
    get 'test1'
    get 'test2'
  end
end
Prefix Verb URI Pattern Controller#Action
test1_cat GET /cats/:id/test1(.:format) cats#test1
test2_cat GET /cats/:id/test2(.:format) cats#test2
cats GET /cats(.:format) cats#index
POST /cats(.:format) cats#create
new_cat GET /cats/new(.:format) cats#new
edit_cat GET /cats/:id/edit(.:format) cats#edit
cat GET /cats/:id(.:format) cats#show
PATCH /cats/:id(.:format) cats#update
PUT /cats/:id(.:format) cats#update
DELETE /cats/:id(.:format) cats#destroy
new

上記のcollection, memberの他にnewも指定可能

resources :companies, only: [:index, :show, :create] do
  get 'test1', on: :new
  get 'test2', on: :new
end

下記のようにも書ける

resources :companies, only: [:index, :show, :create] do
  new do
    get 'test1'
    get 'test2'
  end
end
Prefix Verb URI Pattern Controller#Action
test1_new_company GET /companies/new/test1(.:format) companies#test1
test2_new_company GET /companies/new/test2(.:format) companies#test2
companies GET /companies(.:format) companies#index
POST /companies(.:format) companies#create
company GET /companies/:id(.:format) companies#show
param
resources :hoge, only: [:index, :show], param: :user_id
Prefix Verb URI Pattern Controller#Action
hoge_index GET /hoge(.:format) hoge#index
hoge GET /hoge/:user_id(.:format) hoge#show

namespace

URI Patternとcontrollerにnamespace Admin::を付ける

namespace :admin do
  resources :users, only: [:index, :show]
end
Prefix Verb URI Pattern Controller#Action
admin_users GET /admin/users(.:format) admin/users#index
admin_user GET /admin/users/:id(.:format) admin/users#show

scope

controllerにのみnamespace Adminを付ける

scope module: 'admin' do
  resources :authors
end

下記のようにも書ける

resources :authors, module: 'admin'
Prefix Verb URI Pattern Controller#Action
authors GET /authors(.:format) admin/authors#index
author GET /authors/:id(.:format) admin/authors#show

concern

同じような記述をgroup化しておけるイメージ(?)
DRYに書けてすっきりする気がする

concern :categorize do
  resources :large_categories, only: [:index, :show] do
    get 'test'
  end
end

resources :dogs, only: [:index], concerns: :categorize
resources :dogs, only: [:index], concerns: :categorize
Prefix Verb URI Pattern Controller#Action
dog_large_category_test GET /dogs/:dog_id/large_categories/:large_category_id/test(.:format) large_categories#test
dog_large_categories GET /dogs/:dog_id/large_categories(.:format) large_categories#index
dog_large_category GET /dogs/:dog_id/large_categories/:id(.:format) large_categories#show
dogs GET /dogs(.:format) dogs#index
cat_large_category_test GET /cats/:cat_id/large_categories/:large_category_id/test(.:format) large_categories#test
cat_large_categories GET /cats/:cat_id/large_categories(.:format) large_categories#index
cat_large_category GET /cats/:cat_id/large_categories/:id(.:format) large_categories#show
cats GET /cats(.:format) cats#index

constraints

routingに色々な条件を付与できる
デフォルトでは{id: /[^\/]+/}このような指定になっているようです。

:idを正規表現でチェック

下記のように記述すると:idが数字の場合のみ対応するactionが呼ばれる

resources :small_categories, constraints: {id: /\d+/}

下記のような記述方法もある

constraints(id: /\d+/) do
  resources :small_categories
end
Prefix Verb URI Pattern Controller#Action
small_categories GET /small_categories(.:format) small_categories#index
POST /small_categories(.:format) small_categories#create
new_small_category GET /small_categories/new(.:format) small_categories#new
edit_small_category GET /small_categories/:id/edit(.:format) small_categories#edit {:id=>/\d+/}
small_category GET /small_categories/:id(.:format) small_categories#show {:id=>/\d+/}
PATCH /small_categories/:id(.:format) small_categories#update {:id=>/\d+/}
PUT /small_categories/:id(.:format) small_categories#update {:id=>/\d+/}
DELETE /small_categories/:id(.:format) small_categories#destroy {:id=>/\d+/}

下記のような場合に便利

resources :small_categories, constraints: {id: /\d+/}, only:[:show]
get '/small_categories/test', to: "small_categories#test"

もしこのようにroutingを書いていた場合に「/small_categories/test」にアクセスすれば「small_categories#test」が呼ばれるが、
constraintsがないと「params[:id]に"test"」が格納されている状態で「small_categories#show」が呼ばれる。

記述する順番を逆にすれば回避出来るが毎回順番を気にしなければいけないのでつらめだと個人的には思う。
また、controller側で:idの値を使用する際もどのようなデータが渡ってくるのかある程度予想出来るので
考えることが減る気がする。

subdomainでチェック

下記のように記述するとアクセスしたsubdomainがadminの場合のみ
該当のmethodが呼ばれるようです。(未確認)

resources :books, only: [:index, :show], constraints: {subdomain: 'admin'}
Prefix Verb URI Pattern Controller#Action
books GET /books(.:format) books#index {:subdomain=>"admin"}
book GET /books/:id(.:format) books#show {:subdomain=>"admin"}
matches?を使用してチェック

constraintsに渡したclassのmatches? methodがtrueを返す場合に
該当のactionが呼ばれる。

例)下記のような処理ではuaがpcの場合に該当のactionが呼ばれる。

class PcConstraint 
  def matches?(request)
    # ua check処理
    # uaがpcの場合にtrueを返す
  end
end
 
Rails.application.routes.draw do
  get '/', to: 'pc#index', constraints: PcConstraint.new
end
lambdaを使用してチェック

下記のようにlambdaでもチェック可能

get '/', to: 'iphone#index', constraints: lambda {|request| request.user_agent =~ /iPhone/}
Prefix Verb URI Pattern Controller#Action
GET / pc#index
GET / iphone#index

defaults

get '/users/:id/default' => 'users#default', defaults: { format: :json}                                                                                                        
get '/posts/:id/default' => 'posts#default', defaults: { default_value: :hoge } 
Prefix Verb URI Pattern Controller#Action
GET /users/:id/default(.:format) users#default {:format=>:json}
GET /posts/:id/default(.:format) posts#default {:default_value=>:hoge}

redirect

get "user"        => redirect("/users")
get "user/:id"    => redirect("/users/%{id}")
get 'user/*other' => redirect { |params| "/users/#{params[:other]}"}
Prefix Verb URI Pattern Controller#Action
users GET /users(.:format) users#index
user GET /users/:id(.:format) users#show
GET /user(.:format) redirect(301, /users)
GET /user/:id(.:format) redirect(301, /users/%{id})
GET /user/*other(.:format) redirect(301)

まとめ

今回使用したサンプルは下記で公開していますので
routing周りをいじって色々試してみてください。

shiro16/blog-samples · GitHub

この記事書いてる間にRailsGuidesのRouting周りの話の日本語版が公開されているので
特に初心者はそっちを見た方がいいとかいう話があるかもしれない・・・

Kibanaを3から4にしてみた

環境

環境は下記記事参照


fluentd + elasticsearch + kibanaを導入したので手順をメモ - まっしろけっけ

Kibana3でしたがkibana4がリリースされたのでKibanaを4にしてみた。
事前情報としては「白いらしい」「複数のindexのグラフを一つのdashboardに表示できるらしい」程度です。
Kibana4に関しては大谷さんが日本語に訳してくれているので下記を参照するといいかと思います。

Kibana 4(日本語訳) - @johtaniの日記 2nd

Elasticsearchのversion up

Kibana4はElasticsearch 1.4.4以上じゃないとダメなのでversion upします。
ちなみに構築済みの環境では1.3.5のElasticsearchを使ってました。
Elasticsearchのversionの確認はhttp://elasticsearch.host:9200/とかで確認するのが早いかも

yumリポジトリの変更(1.3.xから1.4.x)

$ sudo vi /etc/yum.repos.d/elasticsearch.repo
- [elasticsearch-1.3]
- name=Elasticsearch repository for 1.3.x packages
- baseurl=http://packages.elasticsearch.org/elasticsearch/1.3/centos
+ [elasticsearch-1.4]
+ name=Elasticsearch repository for 1.4.x packages
+ baseurl=http://packages.elasticsearch.org/elasticsearch/1.4/centos

Elasticsearchをupdate

$ sudo /etc/init.d/elasticsearch stop
$ yum update elasticsearch
$ sudo /etc/init.d/elasticsearch start

これでElasticsearchの更新は完了するかと思います。

Kibana4のセットアップ

Kibana4はweb serverとしての機能を持っているのでKibana3で起動していたnginxを止める。

$ sudo /etc/init.d/nginx stop
# nginxがもう必要ないならremove
$ sudo yum remove nginx
# Kibana3もいらないので削除する
$ sudo rm -rf /usr/share/nginx

Kibana4をインストールする

$ wget https://download.elasticsearch.org/kibana/kibana/kibana-4.0.0-linux-x64.tar.gz
$ tar xvzf kibana-4.0.0-linux-x64.tar.gz
$ sudo mv kibana-4.0.0-linux-x64 /etc/kibana # /etcにとりあえず置いてみる

これでとりあえずインストール完了
起動してみる

$ cd /etc/kibana
$ ./bin/kibana 

http://kibana.host:5601/
上記にアクセスすればKibana4にアクセス出来るかと思います。
こんな感じ(し、しろい・・・)
f:id:shiro-16:20150314231843p:plain

起動スクリプトを書いて見る

下記のようなスクリプト書いてみた。
どこかに他にやり方あれば教えてほしい・・・

$ sudo vi /etc/init.d/kibana4
+ #!/bin/bash
+
+ export NAME=kibana
+ export LOG_DIR=/var/log/${NAME}
+ export PID=/var/run/${NAME}.pid
+ export LOG=${LOG_DIR}/${NAME}.log
+
+ test -d $LOG_DIR || mkdir $LOG_DIR
+
+ case $1 in
+   'start' )
+     $0 status >/dev/null 2>&1 && echo "${NAME} is already running." && exit 1
+     nohup /etc/${NAME}/bin/${NAME} 0<&- &> $LOG &
+     echo $! > $PID
+     ;;
+   'stop' )
+     $0 status >/dev/null 2>&1 || echo "${NAME} is not running." || exit 1
+     test -f $PID && cat $PID | xargs kill -s SIGKILL && rm $PID
+     ;;
+   'restart' )
+     $0 stop
+     sleep 1
+     $0 start
+     ;;
+   'status' )
+     test -f $PID || echo "${NAME} not running." || exit 1
+     PID=`cat $PID`
+     kill -s 0 $PID >/dev/null 2>&1 && echo "${NAME} is running." && exit 0
+     echo "${NAME} not running."
+     exit 1
+     ;;
+   *)
+     echo "Usage: $0 start|stop|restart|status"
+     ;;
+ esac

環境変数は各々の環境に合わせて設定してください。

$ sudo chmod 755 /etc/init.d/kibana4
$ sudo /etc/init.d/kibana4 start # 起動
$ sudo /etc/init.d/kibana4 restart # 再起動
$ sudo /etc/init.d/kibana4 stop # 停止

まとめ

これでKibana3からKibana4への変更ができました。
事前情報通り全体的に黒い画面だったのが白くなりました。(個人的に白好きなのでうれしいw)
複数のindexのグラフを一つのdashboardに表示でき見やすい。
他にも色々出来るみたいですがまだ全然使いこなせていない感がやばい・・・

結構簡単にKibana4への移行が完了しました。
実際にはプロビジョニングツール(自分の場合はChef)で管理を行っているので
recipeを変更して反映するだけだったのですが。