書籍「コンテナ・ベース・オーケストレーション」の紹介

はじめに

3/15に「コンテナ・ベース・オーケストレーション」が刊行されてから2ヶ月たちました。脱稿まで時間がかかってしまい、編集担当の方には大変ご苦労をかけてしまいましたが、そこそこ売れているようでホッとしております。

紙版

編集担当の方の創意工夫により、ページ数が多い割にはコンパクトに仕上がっています。

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

Kindle

少し遅れて刊行されましたが、ちゃんとリフロー対応になっていました。素晴らしい!

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

書籍の位置づけ

まえがきにも記載がありますが、自分としては企画段階で「プロダクション環境でコンテナを使う人のためのカタログ」ということを念頭に置いていました。そのため、DockerとKubernetesというデファクトスタンダードを重点とし、特にオーケストレーション機能の中心となるKubernetesについては多くの紙面を割いています。

背景

「2018年はコンテナ元年」=日本でもプロダクション環境をコンテナベースで運用する時代が到来する、という確信がありました。これは

  • 前職での経験(IoTプラットフォーム)から、長期的にはハイブリッドクラウドがメインストリームになるという予想
  • ハイブリッドクラウド、特にエッジコンピューティングとクラウドの併用のためにはアプリケーションのポータビリティが不可欠で、現時点での最適解はコンテナ
  • 2017年初頭の時点でコンテナオーケストレーションプラットフォームとして完成度が高いのはKubernetes
  • グローバルのユーザー動向を見ると、この数年でコンテナ(特にKubernetes)へのシフトが顕著になってきている
  • 分散システムの基盤としてコンテナ(特にKubernetes)が主流になりつつある

ということを総合的に判断して、自分なりに立てたビジョンです。

執筆した箇所について補足

自分は4章「Kubernetes概要」の執筆を担当しましたが、4章ではKubernetesの各種マネージド・サービスやディストリビューションを選択する前提知識としての「Vanilla Kubernetes」を理解し、そのエッセンスを体得していただくことを目的としました。
そのため、環境依存の大きいネットワークについてはあえて割愛*1し、逆に、重要である割には情報の少ないPersistent VolumeやConfigMapについての解説を厚めにしています。

また、自分のマシンでKubernetesが一通り試せるように、Minikubeによるチュートリアルにも多くの紙面を割いています。執筆開始時点での取り決めによりKubernetes1.7ベースの内容になっていますが、最新バージョンとの差分情報は適宜補足していますので、読者の皆様にぜひ確認していただければと思っています。

執筆者ごとの担当章

書籍をご購入いただいた方から必ず聞かれるので、こちらにまとめておきます。(著者紹介に書いておくべきでしたが、脱稿作業に追われてそこまで気が回りませんでした。申し訳ありません。)

著者(敬称略) タイトル 内容
前佛雅人 第1章 コンテナ管理技術の普及とオーケストレーションを取りまく動向 コンテナに至る技術動向の整理と現状の解説
前佛雅人 第2章 Docker コンテナの基礎とオーケストレーション Docker(Swarm含む)の技術解説
山田修司 第3章 CaaS(Container as a Service) さくらインターネットのArukasの開発者としてのCaaSの解説
須江信洋 第4章 Kubernetesによるオーケストレーション概要 Vanilla Kubernetesの基礎の理解と体験
佐藤聖規/福田潔 第5章 GKE(Google Kubernetes Engine) マネージドサービスのパイオニアであるGKEとGCPの解説
青山尚暉/市川豊/矢野哲朗 第6章 Rancher Rancher1.xと2.x(Kubernetesベース)の最速解説
境川章一郎 第7章 Kubernetes on IBM Cloud Container Service IBMが提供するマネージドKubernetesの解説
橋本直 第8章 OpenShift Networking & Monitoring Kubernetes商用ディストリビューションであるOpenShiftのOps向け紹介
平岡大祐 第9章 OpenShift for Developers 同じく0penShiftでDevOpsするための解説とチュートリアル

著者各位へ

内容は須江の独断でまとめておりますので、修正のご要望があればお知らせください。

さいごに

企画したタイミングの都合で、比較対象として当然含めるべきマネージドサービスやディストリビューションが入っていないことが心残りです。
改訂するチャンスがあれば、AKS(Azure)やEKS(AWS)などのマネージド・サービスや、PCR(Pivotal)などのディストリビューションに関する解説も追加して、プロダクション環境でコンテナを使う人にとって有益な内容にアップデートできると嬉しいです。

*1:このへんの補足情報は特典コンテンツに記載しましたので、ご興味があれば翔泳社のサイトからダウンロードしてみてください。 https://www.shoeisha.co.jp/book/detail/9784798155371

OpenShift Origin 3.7でIstioを動かす

このエントリは Kubernetes Advent Calendar 2017 - Qiita の12/8分です。(ちょっとハマってしまって公開が遅くなってすみません。)

2017/11/30にOpenShift3.7がGAになりました。OpenShift3.7はKubernetes1.7ベースなのでようやくIstioが普通に動かせるようになりましたが、デフォルトのセキュリティ設定が厳し目になっていることもあり、適切な権限設定をしてやらないと動きません。そこで、こちらの情報を参考に、minishiftから起動したOpenShift Origin 3.7上でIstioのbookinfoサンプルを動かす手順を紹介します。
blog.openshift.com

注意) OpenShift3.7はまだIstioを正式にサポートしていませんが、将来のバージョンでサポートする予定になっています。現時点ではRed Hatにお問い合わせいただいてもサポートできかねますのでご了承ください。

なお、以下手順はすべてmacOS Sierra(10.12.6)で動作確認しています。

minishiftインストール手順 for macOS

homebrewで入れますので、入っていなければ事前にインストールしておいてください。

xhyve driverインストール

minishiftから起動するVMをxhyveにするために入れておきます。

$ brew install docker-machine-driver-xhyve
$ sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
$ sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve

minishiftインストール

minishiftの本体です。ローカルマシン上でOpenShift Originを起動するのに使います。

$ brew cask install minishift

詳細: Installing Minishift - Getting Started | Minishift | OpenShift Origin Latest

ocコマンドインストール

OpenShiftのCLIです。(Kubernetesでのkubectl相当)

$ brew install openshift-cli

minishiftの基本的なオペレーション

minishift起動

$ minishift start

minishift VMのIP確認

$ minishift ip

Webコンソールアクセス

$ minishift console 
$ minishift console —url  #url表示のみ

CLIログイン

$ oc login -u developer -p developer  #一般ユーザー
$ oc login -u admin -p admin  #管理ユーザー(cluster-admin)

Istio環境構築

OpenShift Origin 3.7起動 on minishift

$ minishift start --openshift-version v3.7.0 --iso-url centos --cpus 4 --memory 8GB --disk-size 40GB

CentOS7のVM上にOpenShift Origin 3.7を起動します。
CPU/MEM/DISKは環境に合わせて適宜調整してください。MEMはなるべく多めに確保しておいたほうがうよいです。

Istio稼働用環境設定

Istioをデプロイするためのプロジェクトを作成し、必要な権限を設定しておきます。(ほぼザル設定。。。)

$ oc login -u admin -p admin
$ oc new-project istio-system 
$ oc project istio-system 
$ oc adm policy add-scc-to-user anyuid -z istio-ingress-service-account 
$ oc adm policy add-scc-to-user privileged -z istio-ingress-service-account 
$ oc adm policy add-scc-to-user anyuid -z istio-egress-service-account 
$ oc adm policy add-scc-to-user privileged -z istio-egress-service-account 
$ oc adm policy add-scc-to-user anyuid -z istio-pilot-service-account 
$ oc adm policy add-scc-to-user privileged -z istio-pilot-service-account 
$ oc adm policy add-scc-to-user anyuid -z default 
$ oc adm policy add-scc-to-user privileged -z default 
$ oc adm policy add-cluster-role-to-user cluster-admin -z default

Istioインストール

istioctlコマンドおよびサンプルコードをインストールしておきます。

$ curl -L https://git.io/getLatestIstio | sh - 
$ ISTIO_HOME=$(pwd)/$(ls | grep istio) 
$ export PATH="$PATH:$ISTIO_HOME/bin" 
$ cd $ISTIO_HOME 
$ oc apply -f install/kubernetes/istio.yaml

関連プロダクトのデプロイ

PrometheusやGrafanaなど、モニタリングに利用するプロダクトをデプロイします。

$ oc create -f install/kubernetes/addons/prometheus.yaml 
$ oc create -f install/kubernetes/addons/grafana.yaml 
$ oc create -f install/kubernetes/addons/servicegraph.yaml 
$ oc create -f install/kubernetes/addons/zipkin.yaml 
$ oc expose svc grafana 
$ oc expose svc servicegraph 
$ oc expose svc zipkin

また、この後の作業用に、各プロダクトのURLを環境変数を設定しておきます。

$ SERVICEGRAPH=$(oc get route servicegraph -o jsonpath='{.spec.host}{"\n"}')/dotviz
$ GRAFANA=$(oc get route grafana -o jsonpath='{.spec.host}{"\n"}')
$ ZIPKIN=$(oc get route zipkin -o jsonpath='{.spec.host}{"\n"}')

bookinfoサンプルアプリケーションのデプロイ

サンプルアプリケーションは $ISTIO_HOME/samples/bookinfo 以下にあります。このエントリでは触れませんが、他にもサンプルがあるので試してみてください。

インストール

$ cd $ISTIO_HOME
$ oc apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo.yaml) 
$ oc expose svc productpage

本当はプロジェクトを分けたいところですが、ちと面倒なのでまずはistio-systemプロジェクト内にデプロイしてしまいます。
デプロイ完了まで少し時間がかかるので、以下コマンドを実行して放置しておきましょう。

$ PRODUCTPAGE=$(oc get route productpage -o jsonpath='{.spec.host}{"\n"}') 
$ watch -n 1 curl -o /dev/null -s -w %{http_code} $PRODUCTPAGE/productpage

200が返ってくるようになったら起動完了です。

起動確認

念のため、すべてのPodがRunning状態になっているか確認します。

$ oc get po
NAME                              READY     STATUS    RESTARTS   AGE
details-v1-2818760093-rfsvf       2/2       Running   0          8m
grafana-2460282047-df7kt          1/1       Running   0          17m
istio-ca-293181461-bkvqw          1/1       Running   0          22m
istio-egress-2098918753-xwrzp     1/1       Running   0          22m
istio-ingress-3288103321-fnwcd    1/1       Running   0          23m
istio-mixer-4195966866-ssbr4      2/2       Running   0          23m
istio-pilot-1168925427-c5qq8      1/1       Running   3          23m
productpage-v1-1172091313-99m8f   2/2       Running   0          8m
prometheus-4086688911-7ztkb       1/1       Running   0          17m
ratings-v1-3016823457-cdhn9       2/2       Running   0          8m
reviews-v1-3334602649-msgkb       2/2       Running   0          8m
reviews-v2-2474208031-t8rfj       2/2       Running   0          8m
reviews-v3-471783377-ms9k7        2/2       Running   0          8m
servicegraph-4072321759-h7ccm     1/1       Running   0          17m
zipkin-3660596538-kmlsd           1/1       Running   0          17m

起動に失敗しているPodがあったら、ログやイベントで原因を確認しましょう。

bookinfoアプリケーションでIstioの機能を確認

単純ルーティング

$ open http://$PRODUCTPAGE

"Normal user"をクリックすると一般ユーザー向けの画面が表示されます。適当にリロードすると、赤星(v3)/黒星(v2)/星無し(v1)の3種類の画面がランダムに表示され、バックエンドのReviewサービスの各バージョンにランダムにルーティングされていることが確認できます。
f:id:nobusue:20171211053151p:plain
f:id:nobusue:20171211053224p:plain

サービスグラフ

$ open http://$SERVICEGRAPH

サービスの呼び出し経路と、レスポンスタイムなどの統計情報が確認できます。
f:id:nobusue:20171211053257p:plain

メトリクスモニタリング

$ open http://$GRAFANA

ダッシュボード"Istio"を選択すると、サービスに関する各種メトリクスを可視化することができます。便利。
f:id:nobusue:20171211053345p:plain

分散トレース

$ open http://$ZIPKIN

検索条件を指定して"find trace"を実行すると、サービス呼び出しの履歴やコールツリーを確認できます。
f:id:nobusue:20171211053410p:plain

インテリジェントルーティング

細かい条件を指定してルーティングを制御できます。ここではratingsサービスに対して、デフォルトではv1へ、ユーザー"jason"のみv2へルーティングしてみます。

$ oc create -f samples/bookinfo/kube/route-rule-all-v1.yaml 
$ oc create -f samples/bookinfo/kube/route-rule-reviews-test-v2.yaml
$ oc get routerule -o yaml

ログインしていない状態では星なし(v1)のページしか見えなくなりますが、jasonでログインすると黒星(v2)が見えます。

ディレイ

httpFaultを利用して意図的な遅延を挿入することができます。障害時の動作をエミュレートするときなどに有用です。
ここではratingsにjasonユーザーのみ7secのdelayを挿入しています。

oc create -f samples/bookinfo/kube/route-rule-ratings-test-delay.yaml

アクセスしてみると、jason以外のユーザーには影響がないことが確認できます。

タイムアウト

httpReqTimeoutを指定することで、サービス呼び出しのタイムアウトを設定することができます。

重み付きバージョンルーティング

サービスのバージョン毎に重みを指定してリクエストを分散できます。
ここでは、reviewsサービスに対するデフォルトのルーティングルールをv1:v3=50:50に変更しています。

$ cat samples/bookinfo/kube/route-rule-reviews-50-v3.yaml 
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  precedence: 1
  route:
  - labels:
      version: v1
    weight: 50
  - labels:
      version: v3
    weight: 50

$ oc replace -f samples/bookinfo/kube/route-rule-reviews-50-v3.yaml

クォータ

サービス呼び出しのrate limitを設定できます。memquotaオブジェクトで設定値を指定し、quataオブジェクトでカウント方法を指定、ruleオブジェクトでmemquotaとquataを結びつけます。

$ cat samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml 
apiVersion: "config.istio.io/v1alpha2"
kind: memquota
metadata:
  name: handler
  namespace: istio-system
spec:
  quotas:
  - name: requestcount.quota.istio-system
    maxAmount: 5000
    validDuration: 1s
    # The first matching override is applied.
    # A requestcount instance is checked against override dimensions.
    overrides:
    # The following override applies to 'ratings' when
    # the source is 'reviews'.
    - dimensions:
        destination: ratings
        source: reviews
      maxAmount: 1
      validDuration: 1s
    # The following override applies to 'ratings' regardless
    # of the source.
    - dimensions:
        destination: ratings
      maxAmount: 100
      validDuration: 1s

---
apiVersion: "config.istio.io/v1alpha2"
kind: quota
metadata:
  name: requestcount
  namespace: istio-system
spec:
  dimensions:
    source: source.labels["app"] | source.service | "unknown"
    sourceVersion: source.labels["version"] | "unknown"
    destination: destination.labels["app"] | destination.service | "unknown"
    destinationVersion: destination.labels["version"] | "unknown"

---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: quota
  namespace: istio-system
spec:
  actions:
  - handler: handler.memquota
    instances:
    - requestcount.quota

$ oc create -f samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml

Egressルーティング

Istio proxyをインジェクトしたサービス(Istio-enabledなサービス)は、デフォルトではクラスタ外のURLにアクセスできません。外部アクセスが必要な場合は、EgressRuleを設定します。EgressRuleで定義したRouteに対して、RouteRuleのhttp_req_timeoutを指定することも可能。
外向けトラフィックのsource IPをegress routerで指定することや、-includeIPRangesフラグを指定することで istioctl kubectl-inject で注入するenvoy sidecarコンテナのCIDRを指定することもできます。

アクセスコントロール

ルールによる明示的なアクセス拒否や、ホワイトリスト方式によるアクセス拒否ができます。

まとめ

マイクロサービスをプロダクション運用する場合、従来であればNetflix OSSなどがよく使われていましたが、「Javaに限定される」「アプリケーションコードに非機能要件が入り込む」という課題がありました。
Istioのようなサービスメッシュ層を設けることで、実装言語によらずに、マイクロサービスの運用や問題判別に必要な機能を外付けすることができるようになります。特にKubernetesのPodとの相性が良いので、今後はIstio+Kubernetesの組み合わせでマイクロサービスをデプロイすることが多くなりそうです。

HBase徹底入門はCloudera Managerユーザーの必読書

仕事でOpenTSDBを使っていることもあり、HBase徹底入門を購入しました。

HBase徹底入門 Hadoopクラスタによる高速データベースの実現

HBase徹底入門 Hadoopクラスタによる高速データベースの実現

まだざっとしか読んでいませんが、

  • HBaseの概要/アーキテクチャの解説
  • HBaseのインストールとアプリケーション開発
  • スキーマ設計のポイント
  • Cloudera Managerによるクラスタ環境構築
  • Cloudera Managerによる運用監視
  • トラブルシューティング

などなど、HBaseに限らず、CDH5ベースでHadoopクラスタを運用している人(もしくはこれから運用しようとしている人)にとっては必読の書です。
少なくとも俺得であることは間違いありません。

今までなんとなくHadoopに尻込みしていた人におすすめです。

Lazybonesによるプロジェクトテンプレート管理(1): Lazybones概要/Hello Lazybones

Lazybonesとは?

Lazybonesはプロジェクトテンプレートからプロジェクトのひな形を自動作成するツールです。

Railsのscaffoldや、Mavenarchetype:generateに近いメージですが、特定のフレームワークやビルドツールに依存しない汎用的なテンプレート管理ツールになっています。(元々はRatpackにプロジェクト新規作成用のコマンドラインツールが提供されていないことを不満に思って作成したそうです。)
とはいえ、Lazybonesのテンプレート作成機能がGradleベースであることや、post-installスクリプトをGroovyで記述することなどから、Gradleプロジェクトのテンプレート管理ツールとして使われることを想定していると考えてよいのではないかと思います。

Lazybones概要

  • テンプレートはzip形式のアーカイブで、基本的にはプロジェクトのひな形となるファイル・ディレクトリをアーカイブに含めます。
  • テンプレートはBintrayから配布できます(バージョン管理可能)。
  • テンプレートには静的なファイルだけでなく、テンプレートエンジンによって生成する動的なファイルを含めることができます。テンプレートエンジンの処理はpost-installスクリプト(Groovyスクリプト)に記述します。
  • post-installスクリプトには対話処理を含めることができます。例えば、自動生成するクラスファイルのパッケージ名などをユーザーに入力させることができます。
  • サブテンプレート機能によって、プロジェクトの初期生成後にファイルを追加生成できます。(例えば後からコントローラークラスを追加するなど。)

テンプレート配布方法

デフォルトではBintrayの pledbrook/lazybones-templates リポジトリが検索対象となります。
コンフィグレーションでカスタムリポジトリを追加することができるので、例えば自分のBintrayリポジトリを検索対象に追加することも可能です。
また、Bintrayにアップロードせずに、テンプレートのzipファイルをWebサーバーやファイルサーバーにアップロードしておき、URLを直接指定する方法もあります。(いちいちURLを指定するのが面倒なら、コンフィグレーションでURLに別名をつけることもできます。)
テンプレートの開発方法は後日紹介しようと思いますが、興味のある方はこちらを参照してみてください。静的なファイルのみであれば、テンプレート作成はそれほど難しくないです。
Template developers guide · pledbrook/lazybones Wiki · GitHub

インストール方法

2014/12/28現在の最新バージョンは0.8です。
GVMが利用可能であれば、以下でインストールするのが簡単でよいでしょう。

$ gvm install lazybones

バイナリのzipファイルを展開してもよいです。以下からダウンロードして展開し、bin/以下にパスを通してください。
https://bintray.com/pledbrook/lazybones-templates/lazybones/0.8/view/files

使ってみる

以下のコマンドで公式リポジトリのテンプレート一覧を取得できます。

$ lazybones list
Available templates in pledbrook/lazybones-templates

aem-multimodule-project
afterburnerfx
afterburnergfx
angular-grails
asciidoctor-gradle
dropwizard
gaelyk
gradle-plugin
gradle-quickstart
groovy-app
groovy-lib
java-basic
lazybones-project
nebula-plugin
ratpack
ratpack-lite
spring-boot-actuator

試しにSpring Bootのプロジェクトを生成してみましょう。
テンプレートの詳細情報を確認するには「info」コマンドを利用します。

$ lazybones info spring-boot-actuator
Fetching package information for 'spring-boot-actuator' from Bintray
Name: spring-boot-actuator
Latest: 1.0.1.RELEASE
Owner: pledbrook
Versions: 0.1, 1.0.1.RELEASE, 0.2

提供されているバージョンが確認できましたので、1.0.1.RELEASEからプロジェクトを生成してみます。
プロジェクトの生成には「create」コマンドを利用します。「help <コマンド名>」で各コマンドの詳細が確認できます。

$ lazybones help create
Creates a new project from a template.

USAGE: create <template> <version>? <dir>

where template = The name of the project template to use.
version = (optional) The version of the project template to use. Uses
the latest version of the template by default.
dir = The name of the directory in which to create the project
structure. This can be '.' to mean 'in the current
directory.'

Option Description
------ -----------
-P Add a substitution variable for file
filtering.
-h, --help Displays usage.
--spaces Sets the number of spaces to use for
indent in files.
--with-git Creates a git repository in the new
project.

プロジェクトを生成したいディレクトリに移動し、以下を実行して「mybootapp」ディレクトリ以下にプロジェクトを新規生成します。

$ lazybones create spring-boot-actuator 1.0.1.RELEASE mybootapp

もしくは、以下のようにしてもかまいません。

$ mkdir mybootapp
$ cd mybootapp
$ lazybones create spring-boot-actuator 1.0.1.RELEASE .

プロジェクトのファイル一式が生成され、最後にREADME.mdの内容が表示されます。

# Spring Boot Actuator Sample

You have just created a simple Spring Boot project in Groovy incorporating the
Actuator. This includes everything you need to run the application. In this
case, that's a simple JSON endpoint.

In this project you get:

* A Gradle build file
* An application class, `SampleApplication`, implementing a single JSON endpoint
* A JUnit test case for `SampleApplication`

You can build and run this sample using Gradle (>1.6):

```
$ gradle run
```

If you want to run the application outside of Gradle, then first build the JARs
and then use the `java` command:

```

生成されたファイル一式は以下のようになっています。

$ tree
.
├── README.md
├── build.gradle
└── src
├── main
│   ├── groovy
│   │   └── sample
│   │   └── SampleApplication.groovy
│   └── resources
│   └── application.properties
└── test
└── groovy
└── sample
└── SampleApplicationTests.groovy

README.mdに従って実行してみます。(このテンプレートにはGradle Wrapperが含まれていないので、別途Gradleを導入しておく必要があります。)

$ gradle run
:compileJava UP-TO-DATE
:compileGroovy
:processResources
:classes
:run

. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v1.0.1.RELEASE)

2014-12-28 01:05:53.866 INFO 51749 --- [ main] sample.SampleApplication : Starting SampleApplication on nobusue-MacBookPro.local with PID 51749 (/Users/nobusue/work/mybootapp/build/classes/main started by nobusue)
2014-12-28 01:05:53.924 INFO 51749 --- [ main] ationConfigEmbeddedWebApplicationContext : Refreshing org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@6ae0286d: startup date [Sun Dec 28 01:05:53 JST 2014]; root of context hierarchy
・・・
[org.springframework.boot:type=Endpoint,name=configurationPropertiesReportEndpoint]
2014-12-28 01:05:57.278 INFO 51749 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080/http
2014-12-28 01:05:57.279 INFO 51749 --- [ main] sample.SampleApplication : Started SampleApplication in 4.282 seconds (JVM running for 4.92)
> Building 80% > :run

無事Spring Bootアプリケーションが起動しました。

まとめ

spring-boot-actuatorテンプレートではアプリケーションのクラス名などは決め打ちになっていますが、post-installスクリプトを追加すればユーザーの入力に従ってクラス名を変更することなどが可能です。そのため、GitHubなどでテンプレートプロジェクトを公開するより、より使いやすい形で提供することができそうです。
なぜか日本語情報の少ないLazybonesですが、シンプルながら要所をおさえた作りになっており、なかなか使えそうです。
次回以降、テンプレート作成と公開について紹介していく予定です。

GroovyでApache Sparkアプリケーションを作る #gadvent

このエントリは G*Advent Calendar(Groovy,Grails,Gradle,Spock...) Advent Calendar 2014 - Qiita の12/20担当分です。

Apache Sparkとは?

Hadoopエコシステムにおける次世代の分散処理基盤として注目されています。インメモリ処理とDAGによるタスクスケジューリングを特徴とし、分散処理に必要な耐障害性を備えています。また、RDDという共通のプログラミングモデルの上で機械学習やストリーミング処理が統一的に扱えるため、複雑なビッグデータ処理を実装するのに有利です。
概要をつかむにはこのへんの資料がよいかと思います。

Groovyから使ってみようと思った動機

公式サイト Apache Spark™ - Lightning-Fast Cluster Computing を見ていただくとわかりますが、Spark自体はScalaで開発されており、アプリケーション開発は Scala / Java / Python で行えるようにAPIが提供されています。(機能の実装状況には差異があり、例えばPythonではSpark1.2でやっとStreamingがサポートされたり、と言った状況です。)
せっかくJavaAPIがあるのでぜひ使いたいところなのですが、Scala/Pythonに比べて以下のようなビハインドがあります。

  • ラムダが使えないのでコードが冗長(Java8を使えばマシにはなりますが、ClouderaがJava8をサポートするまで自分は使えません・・)
  • 対話型シェル(REPL)がない

JavaAPIをGroovyから使うことでこれらの課題に対処できないか試行錯誤していますので、まだ道半ばではありますが現在までの状況をまとめておきます。

コードの簡略化

いくらか成果が上がったので、本エントリで記載します。ただし、Sparkの挙動に起因する癖がありますので注意が必要です。

REPL(Groovy Shell)

こちらはSparkの挙動に起因する癖によって壁にぶつかりました。現時点では解決策が見つかっていません。
具体的にはタスク実行時に以下の例外が発生します。

ERROR org.apache.spark.SparkException:
Task not serializable
at org.apache.spark.util.ClosureCleaner$.ensureSerializable (ClosureCleaner.scala:166)

GroovyでSpark Wordcountを実行してみる

Quick Start - Spark 1.2.0 Documentation にあるWord CountのJavaサンプルをGroovyで書き換えてみました。
プロジェクト全体はnobusue/groovy-spark-sample · GitHubにあげてあります。

Sparkアプリケーション本体

テキストファイルを読み込んで、指定した単語を含む行数をカウントするだけの簡単なサンプルです。適当なテキストファイルを用意して、「sc.textFile("YOUR_TEXT_FILE_PATH")」のところを置き換えてください。

import org.apache.spark.*
import org.apache.spark.api.java.*
import org.apache.spark.api.java.function.*

public class SparkGroovySample {

  public static void main(String[] args) {

    def conf = new SparkConf().setMaster("local[2]").setAppName("WordCount")
    def sc   = new JavaSparkContext(conf)
    def file = sc.textFile("YOUR_TEXT_FILE_PATH").cache()

    def filterFunc = new Function<String,Boolean>() {
      public Boolean call(String s) {
        return s.contains('spark')
    }}

    def filterFunc2 = { it.contains('hadoop') } as Function

    def countsOfSpark = file.filter(filterFunc).count()
    def countsOfHadoop = file.filter(filterFunc2).count()

    println "Count of Spark:${countsOfSpark}, Count of Hadoop:${countsOfHadoop}"
  }
}

例えばSparkのREADME.mdに対して上記を実行すると、

Count of Spark:8, Count of Hadoop:10

みたいになるはずです。
フィルタ関数の定義は、SparkのJava APIでは以下のようにFunctionインターフェースを実装する必要があります。

    def filterFunc = new Function<String,Boolean>() {
      public Boolean call(String s) {
        return s.contains('spark')
    }}

Groovyの場合はクロージャから変換することで多少楽ができます。

    def filterFunc2 = { it.contains('hadoop') } as Function

注意点

コードを眺めているだけでは分かりづらいのですが、sc.textFile()で読み込んだファイルはRDD(JavaRDD)というオブジェクトに格納されています。
RDDに対する操作はワーカーノードで分散処理されるため、filter()などの操作で利用するオブジェクトはすべてシリアライズしてリモートに送信できなければいけません。上記サンプルをGroovyスクリプトではなくGroovyクラスとして実装しているのはこの条件を満たすためです。(実際に試してみると、Groovyスクリプトとして実装した場合にはfilterFunc()がシリアライザブルでないと判断されて例外が発生します。)

おまけ:ログ設定

SparkはLog4jを使っており、デフォルトではSpark自体の動作に関するログがINFOレベルで大量に出力されます。普段は必要ないので、以下のようにして消しておきましょう。

# Set everything to be logged to the console
#log4j.rootCategory=INFO, console
log4j.rootCategory=WARN, console
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.target=System.err
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n

まとめ

素直にScalaPythonを勉強した方が楽かもしれませんが、それぞれ一長一短があるのでJava(Groovy)で使う方法も引き続き試行錯誤していきます。

GroovyでAWS SDK for Javaを使う #gadvent

このエントリは G*Advent Calendar(Groovy,Grails,Gradle,Spock...) Advent Calendar 2014 - Qiita の12/13担当分です。

AWS SDK for Javaとは?

パブリッククラウドサービスであるAmazon Web ServicesにはWebAPIが提供されていますが、生のAPIでは使いにくいため、各言語用からAPIを利用するためのライブラリが提供されています。
AWS SDK for Javaは読んで字のごとくJava用のライブラリです。
AWS SDK for Java | アマゾン ウェブ サービス(AWS 日本語)

Groovyから使うと何が嬉しいの?

http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html を眺めてみていただくとわかりますが、AWS SDK for JavaAPIドメイン指向に設計されておりクラス構造が複雑です。
実際に使おうとするといろいろ試行錯誤が必要になるので、Groovyを使ってあらかじめAPIの挙動を調べておくと便利です。(もちろん、そのままGroovyでプロダクションコードを書いてもいいでしょう。)

例) EC2のインスタンス一覧を取得する

簡単な例として、EC2の指定リージョンのインスタンス一覧を取得してみましょう。
いろいろ試行錯誤するにはインタラクティブシェルの方がやりやすいので、
Gradle Groovy Shellプラグインを使って依存ライブラリ込みのREPLを起動する #gadvent - nobusueの日記
で紹介したGradle Groovy Shellプラグインを利用します。

事前準備

AWSAPIを利用するためには、Access KeyとSecret Keyを取得しておく必要があります。APIからのアクセス専用にIAMアカウントを新しく作成し、EC2のみ権限を与えておくとよいかと思います。

ビルドスクリプト作成

適当なディレクトリで build.gradle 作成します。

apply plugin: 'com.github.tkruse.groovysh'
apply plugin: 'java'

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.tkruse.gradle:gradle-groovysh-plugin:1.0.2'
    }
}

repositories {
    jcenter()
}

dependencies {
  compile 'com.amazonaws:aws-java-sdk:1.9.10'
}

Groovy Shell起動

以下のコマンドでGroovy Shellを起動します。

$ gradle -q shell
This is a gradle Application Shell.
You can import your application classes and act on them.
Groovy Shell (2.3.6, JVM: 1.7.0_72)
Type ':help' or ':h' for help.
-------------------------------------------------------------------------------
groovy:000>

このGroovy ShellはAWS SDK for Javaのライブラリがダウンロードされ、クラスパスに追加された状態になっています。

EC2インスタンス一覧取得

Groovy Shellで以下を入力します。ここでは例としてOregonリージョン(us-west-2)を指定しています。

groovy:000> import com.amazonaws.services.ec2.*
groovy:000> import com.amazonaws.auth.*
groovy:000> import com.amazonaws.regions.*
groovy:000> credentials = new BasicAWSCredentials("<YOUR_ACCESS_KEY>","<YOUR_SECRET_KEY>")
groovy:000> ec2 = new AmazonEC2Client(credentials)
groovy:000> ec2.setRegion(Region.getRegion(Regions.US_WEST_2))
groovy:000> result = ec2.describeInstances()
groovy:000> result.each{ println "Instance ID: ${it.reservations.instances.instanceId}" }
Instance ID: [[i-50aaf05b]]

実際には実行毎に結果(レスポンス)がダンプされますので、見失わないようにしてください。例えば、最後の行の実行結果の後には以下が出力されます。

===> {Reservations: [{ReservationId: r-a8f079a3,OwnerId: 574167580182,Groups: [],GroupNames: [],Instances: [{InstanceId: i-50aaf05b,ImageId: ami-d13845e1,State: {Code: 16,Name: running},PrivateDnsName: ip-10-0-0-200.us-west-2.compute.internal,PublicDnsName: ec2-xx-xx-xx-xx.us-west-2.compute.amazonaws.com,StateTransitionReason: ,KeyName: xxx,AmiLaunchIndex: 0,ProductCodes: [],InstanceType: t2.micro,LaunchTime: Sun Aug 31 09:12:33 JST 2014,Placement: {AvailabilityZone: us-west-2a,GroupName: ,Tenancy: default},Monitoring: {State: disabled},SubnetId: subnet-xxxxxxx,VpcId: vpc-xxxxxx,PrivateIpAddress: 10.0.0.200,PublicIpAddress: xx.xx.xx.xx,Architecture: x86_64,RootDeviceType: ebs,RootDeviceName: /dev/xvda,BlockDeviceMappings: [{DeviceName: /dev/xvda,Ebs: {VolumeId: vol-eb315aea,Status: attached,AttachTime: Sun Aug 31 09:12:36 JST 2014,DeleteOnTermination: true}}],VirtualizationType: hvm,ClientToken: xxxxxxxxxx,Tags: [{Key: Name,Value: jenkins}],SecurityGroups: [{GroupName: xxx,GroupId: sg-xxxxxxxx}, {GroupName: xxx,GroupId: sg-xxxxxxx}],SourceDestCheck: true,Hypervisor: xen,NetworkInterfaces: [{NetworkInterfaceId: eni-34684351,SubnetId: subnet-xxxxxx,VpcId: vpc-xxxxxx,Description: Primary network interface,OwnerId: 574167580182,Status: in-use,MacAddress: 02:7b:60:ba:d1:ee,PrivateIpAddress: 10.0.0.200,PrivateDnsName: ip-10-0-0-200.us-west-2.compute.internal,SourceDestCheck: true,Groups: [{GroupName: xxx,GroupId: sg-xxxxxxx}, {GroupName: xxx,GroupId: sg-xxxxxxx}],Attachment: {AttachmentId: eni-attach-5aafb86d,DeviceIndex: 0,Status: attached,AttachTime: Sun Aug 31 09:12:33 JST 2014,DeleteOnTermination: true},Association: {PublicIp: xx.xx.xx.xx,PublicDnsName: ec2-xx-xx-xx-xx.us-west-2.compute.amazonaws.com,IpOwnerId: amazon},PrivateIpAddresses: [{PrivateIpAddress: 10.0.0.200,PrivateDnsName: ip-10-0-0-200.us-west-2.compute.internal,Primary: true,Association: {PublicIp: xx.xx.xx.xx,PublicDnsName: ec2-xx-xx-xx-xx.us-west-2.compute.amazonaws.com,IpOwnerId: amazon}}]}],EbsOptimized: false,}]}],}

毎回ダンプが出るのはややうっとおしいですが、レスポンスのどこに必要な情報が含まれているか確認するだけなら、これを眺めるだけで問題が解決する場合もあったりします。

Groovy Shellは「Ctrl+D」で終了します。

Groovy Shell以外で実行する場合の注意事項

「ec2 = new AmazonEC2Client(credentials)」のように変数定義を省略しているのはGroovy Shellの制約によるものです。
通常のGroovyスクリプトで実行する場合は「def ec2 = new AmazonEC2Client(credentials)」のようにしてください。

2015/1/29追記

Groovy2.4でgroovyshのinterpreterModeが追加されました。
http://jira.codehaus.org/browse/GROOVY-6623

groovysh起動後に

:set interpreterMode true

を実行すれば、groovysh上でも普通に「def x=3」とかで変数定義できるようになりました。めでたい。

まとめ

AWS SDKで悩んだら、とりあえずGroovyで試してみるのがおすすめです。

Gradle Groovy Shellプラグインを使って依存ライブラリ込みのREPLを起動する #gadvent

このエントリは G*Advent Calendar(Groovy,Grails,Gradle,Spock...) Advent Calendar 2014 - Qiita の12/8担当分です。

Gradle Groovy Shellプラグインとは?

Groovyには"groovysh"(Groovy Shell)という機能があります。これはGroovyのインタラクティブシェルを起動するもので、いわゆるREPL相当の機能です。
それなりに便利な機能なのですが、残念ながらGroovyの標準ライブラリ以外を読み込むことができず、ライブラリを追加する場合には自力でクラスパスを通す必要があります。

Gradle Groovy Shellプラグインを利用すると、Gradleを利用して依存関係を解決した状態でgroovyshを起動することができます。

Gradle Groovy Shellプラグインの利用方法

Gradleのビルドスクリプトでgradle-groovysh-pluginを追加するだけです。
詳細はこちらを参照いただくとよいかと思います。

tkruse/gradle-groovysh-plugin · GitHub

V1.0.2での注意点

2014/12/8時点での最新バージョン(1.0.2)では、Gradle Groovy Shellプラグインのみを適用するとビルドエラーになります。
Javaプラグインのプロパティを参照していることが原因のようです。Javaプラグインもあわせて適用するようにしてください。

例) Twitter4Jを使ってみる

ここでは例として Twitter4J - A Java library for the Twitter API を使ってみましょう。
事前に https://apps.twitter.com/ でConsumer KeyやAccess Tokenを取得しておいてください。

適当なディレクトリで build.gradle 作成します。

apply plugin: 'com.github.tkruse.groovysh'
apply plugin: 'java'

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.tkruse.gradle:gradle-groovysh-plugin:1.0.2'
    }
}

repositories {
    jcenter()
}

dependencies {
    compile 'org.twitter4j:twitter4j-core:4.0+'
}

そして、次のコマンドでGroovy Shellを起動します。

$ gradle -q shell
This is a gradle Application Shell.
You can import your application classes and act on them.
Groovy Shell (2.3.6, JVM: 1.7.0_72)
Type ':help' or ':h' for help.
-------------------------------------------------------------------------------
groovy:000>

"groovy:000>"というプロンプトが表示されたら、おもむろにGroovyコードをタイプしていきましょう。(完全ではありませんが、TABキーによる補完もそれなりに効きます。)
なお、groovyshでは"def"で定義した変数は参照できないので、何もつけずに定義するようにしてください。

groovy:000> import twitter4j.*
===> twitter4j.*

groovy:000> import twitter4j.conf.*
===> twitter4j.*, twitter4j.conf.*

groovy:000> cb = new ConfigurationBuilder()
===> twitter4j.conf.ConfigurationBuilder@6c01e903

groovy:000> cb.setOAuthConsumerKey("<YOUR_CONSUMER_KEY>")
===> twitter4j.conf.ConfigurationBuilder@6c01e903

groovy:000> cb.setOAuthConsumerSecret("<YOUR_CONSUMER_SECRET>")
===> twitter4j.conf.ConfigurationBuilder@6c01e903

groovy:000> cb.setOAuthAccessToken("<YOUR_OAUTH_TOKEN>")
===> twitter4j.conf.ConfigurationBuilder@6c01e903

groovy:000> cb.setOAuthAccessTokenSecret("<YOUR_OAUTH_SECRET>")
===> twitter4j.conf.ConfigurationBuilder@5a8fddea

groovy:000> tf = new TwitterFactory(cb.build())
===> twitter4j.TwitterFactory@6bffa4b9

groovy:000> twitter = tf.getInstance()
===> TwitterImpl{INCLUDE_MY_RETWEET=PostParameter{name='include_my_retweet', value='true', file=null, fileBody=null}}

groovy:000> query = new Query("gradle")
===> Query{query='gradle', lang='null', locale='null', maxId=-1, count=-1, since='null', sinceId=-1, geocode='null', until='null', resultType='null', nextPageQuery='null'}

groovy:000> result = twitter.search(query)
[Mon Dec 08 02:35:38 JST 2014]Request: 
[Mon Dec 08 02:35:38 JST 2014]GET https://api.twitter.com/1.1/search/tweets.json?q=gradle&with_twitter_user_id=true&include_entities=true
・・・

groovy:000> result.tweets.each{ println "@${it.user.screenName}: ${it.text}" }
@csterwa: RT @danveloper: What if bootstrapping a cloud full of @NetflixOSS was as easy as typing "initCloud"? Now it is. https://t.co/44OVUgfKG4
@IndieGameDevBot: RT @lastpoke: Way to download Utility classes with Gradle http://t.co/suUwF0xSyj #Android #AndroidDev #lastpoke
・・・

Ctrl+Dで終了します。

2015/1/29追記

Groovy2.4でgroovyshのinterpreterModeが追加されました。
http://jira.codehaus.org/browse/GROOVY-6623

groovysh起動後に

:set interpreterMode true

を実行すれば、groovysh上でも普通に「def x=3」とかで変数定義できるようになりました。めでたい。

まとめ

簡単ですが、Gradle Groovy Shellプラグインについて紹介しました。
Groovy Shellプラグインは主にGradleのビルドスクリプト開発を支援するために使われることが多いようですが、それ専用ではなくもう少し汎用的に作られているということがわかります。他の言語処理系におけるREPLに比べるとやや機能不足な感は否めませんが、JavaのREPLが登場するまではこれで凌ぐというのもアリかと思います。

また、Groovyには言語機能としてGrape(@Grab)が用意されているのですが、Grapeはスクリプト実行以外の使い方ではうまく動かない場合もありますので、うまく使い分けるとよいのではないでしょうか。