Namiking.net

パーサーコンビネーターを使って自然言語風のテキストからパラメーターを抽出する

Mon, 27 Nov 2017 18:00:00 +0900

CLI と違い、引数を渡す方法が標準化しておらず、パースを実装する必要があった。Slack の /remind スラッシュコマンドのように、自然言語風に Bot へのパラメーターを抽出したい。

/remind me to drink water at 3pm every day
/remind me on June 1st to wish Linda happy birthday
/remind #team-alpha to update the project status every Monday at 9am
/remind @jessica about the interview in 3 hours

正規表現を使うと複雑になりがちな上のようなパラメーター抽出のため、パーサーコンビネーターを使って、パーサーを実装してみる。

実装したいこと

例えば、CircleCI の特定のジョブを Bot を通じて Slack から起動するために、自然言語風のテキストからパラメーターを抽出したい。

post build to (username)/(reponame) [on (ブランチ名)] [at (コミットハッシュ)] [for (ジョブ名)]

パラメーター抽出例

post build to namikingsoft/namikingsoft.github.io on master for deploy

{
  "repo": "namikingsoft/namikingsoft.github.io",
  "branch": "master",
  "job": "deploy"
}

実装してみる

上の要件を実装したコード例と軽い解説。

00. ソースコード全体

const P = require('parsimmon');
const R = require('ramda');

// map functions
const mapToThirdArg = (_1, _2, _3) => _3;
const mapToRepo = (_1, _2, _3, _4, _5) => `${_1}/${_5}`;
const reduceNodeToObj = R.reduce((acc, x) => R.merge({ [x.name]: x.value })(acc), {});
const transForSentence = R.pipe(mapToThirdArg, reduceNodeToObj);

// atoms
const _ = P.whitespace;
const _o = P.optWhitespace;
const to = P.string('to');
const on = P.string('on');
const at = P.string('at');
const fr = P.string('for'); // TODO: alt `for`
const slash = P.string('/');
const command = P.regex(/post +build/i);
const digit = P.digit;
const letterSmall = P.range('a', 'z');
const letterLarge = P.range('A', 'Z');
const letter = P.alt(letterSmall, letterLarge);
const hex = P.alt(P.range('a', 'f'), digit);
const symbolForSep = P.oneOf('._-');
const symbolForBranch = P.oneOf('._-/#+');

// parameters
const username = P.alt(letter, digit, symbolForSep).many().tie();
const reponame = P.alt(letter, digit, symbolForSep).many().tie();
const branch = P.alt(letter, digit, symbolForBranch).many().tie();
const job = P.alt(letter, digit, symbolForSep).many().tie();
const repo = P.seqMap(username, _o, slash, _o, reponame, mapToRepo);
const revision = hex.many().tie();

// nodes
const nodeRepo = P.seqMap(to, _, repo, mapToThirdArg).node('repo');
const nodeJob = P.seqMap(fr, _, job, mapToThirdArg).node('job');
const nodeBranch = P.seqMap(on, _, branch, mapToThirdArg).node('branch');
const nodeRevision = P.seqMap(at, _, revision, mapToThirdArg).node('revision');
const node = P.alt(nodeRepo, nodeJob, nodeBranch, nodeRevision);
const sentence = P.seqMap(command, _, node.sepBy(_), transForSentence);

// parse
const text1 =
  'post build to namikingsoft/namikingsoft.github.io on master at abcd1234 for deploy';
const text2 =
  'pOSt  BuilD   for   deploy on   master to  namikingsoft  /  namikingsoft.github.io';

sentence.tryParse(text1);
// {
//   "job": "deploy",
//   "revision": "abcd1234",
//   "branch": "master",
//   "repo":"namikingsoft/namikingsoft.github.io"
// }

sentence.tryParse(text2);
// {
//   "job": "deploy",
//   "branch": "master",
//   "repo":"namikingsoft/namikingsoft.github.io"
// }

sentence.tryParse('illegal text example');
// -> Exception!

RunKit でコードを実行する
https://runkit.com/namikingsoft/parse-text-for-bot-using-parsimmon

01. 使っている npm モジュール

const P = require('parsimmon');
const R = require('ramda');

Parsimmon - パーサーコンビネーターライブラリ

JS のパーサーコンビネーターライブラリの１つ。Haskell の Parserc ライクに使える。

GitHub: jneen/parsimmon
https://github.com/jneen/parsimmon

Ramda - 関数型プログラミング支援ライブラリ

関数型プログラミングライブラリの１つ。今回はパーサーの戻り値調整のみに使った。

Ramda Documentation
http://ramdajs.com/

02. 字句の定義

入力文を構成する要素を BNF のような感覚で字句の定義を行っていく。

// atoms
const _ = P.whitespace;
const _o = P.optWhitespace;
const to = P.string('to');
const on = P.string('on');
const at = P.string('at');
const fr = P.string('for'); // TODO: alt `for`
const slash = P.string('/');
const command = P.regex(/post +build/i);
const digit = P.digit;
const letterSmall = P.range('a', 'z');
const letterLarge = P.range('A', 'Z');
const letter = P.alt(letterSmall, letterLarge);
const hex = P.alt(P.range('a', 'f'), digit);
const symbolForSep = P.oneOf('._-');
const symbolForBranch = P.oneOf('._-/#+');

// parameters
const username = P.alt(letter, digit, symbolForSep).many().tie();
const reponame = P.alt(letter, digit, symbolForSep).many().tie();
const branch = P.alt(letter, digit, symbolForBranch).many().tie();
const job = P.alt(letter, digit, symbolForSep).many().tie();
const repo = P.seqMap(username, _o, slash, _o, reponame, mapToRepo);
const revision = hex.many().tie();

03. パーサーの構築

パーサーを構成する字句を組み合わせたり、関数出力の調整を行う。ノード定義は alt を使っても、どの要素が該当したか識別できるするために node で名前をつけていくイメージ。

// map functions
const mapToThirdArg = (_1, _2, _3) => _3;
const mapToRepo = (_1, _2, _3, _4, _5) => `${_1}/${_5}`;
const reduceNodeToObj = R.reduce((acc, x) => R.merge({ [x.name]: x.value })(acc), {});
const transForSentence = R.pipe(mapToThirdArg, reduceNodeToObj);

// nodes
const nodeRepo = P.seqMap(to, _, repo, mapToThirdArg).node('repo');
const nodeJob = P.seqMap(fr, _, job, mapToThirdArg).node('job');
const nodeBranch = P.seqMap(on, _, branch, mapToThirdArg).node('branch');
const nodeRevision = P.seqMap(at, _, revision, mapToThirdArg).node('revision');
const node = P.alt(nodeRepo, nodeJob, nodeBranch, nodeRevision);
const sentence = P.seqMap(command, _, node.sepBy(_), transForSentence);

04. パーサーを使う

定義した構文に沿ったテキストが入力された場合は、ノードの名前をキーとしたオブジェクトとして返され、そうでない場合は例外が発生する。

// parse
const text1 =
  'post build to namikingsoft/namikingsoft.github.io on master at abcd1234 for deploy';
const text2 =
  'pOSt  BuilD   for   deploy on   master to  namikingsoft  /  namikingsoft.github.io';

sentence.tryParse(text1);
// {
//   "job": "deploy",
//   "revision": "abcd1234",
//   "branch": "master",
//   "repo":"namikingsoft/namikingsoft.github.io"
// }

sentence.tryParse(text2);
// {
//   "job": "deploy",
//   "branch": "master",
//   "repo":"namikingsoft/namikingsoft.github.io"
// }

sentence.tryParse('illegal text example');
// -> Exception!

まとめ

頑張れば正規表現で書けなくもなさそうなテキストパースを、パーサーコンビネーターで書いてみて、思ったこといくつか。

各要素に名前を付けられる＆組み合わせることができる

正規表現で複雑なパーサーを書くと、意味不明な文字列の羅列になりやすく、リーダブルに書くことが難しいが、字句レベルから変数にできて、再利用もしやすい点が良いと感じた。

Parsimmon ドキュメントが Parsec より簡潔でわかりやすい

Haskell の Parsec でパーサーを実装していたときは、Hackage を見ても、ググっても、いまいち使い方がわからず、入門用にまとまっているドキュメントを探すのに苦労したが、Parsimmon ドキュメントはコード例とともに簡潔にまとまっていて、実装がしやすかった。Parsec の練習用にも良いかもしれない。

Examples には、軽量スクリプト言語のパーサーや JS Linter の実装例もあったので、より複雑なパーサーを構築したくなったときに参照したい。

静的型チェッカーflowでReact+Reduxのサンプルアプリを組んでみた

Sun, 22 May 2016 20:00:00 +0900

JavaScript型チェッカーflowを使って、React+Reduxで簡単なカウンターのサンプルアプリケーションを組んでみたので、その際のいくつかのポイントなどをまとめておきます。

サンプルアプリについて

ボタンを押したら数字がインクリメントされるタイプのよくあるサンプルプログラム。

GitHub: namikingsoft/react-redux-using-flow-example https://github.com/namikingsoft/react-redux-using-flow-example

ソース周りのファイル構成

react-redux-using-flow-example
|-- src
|   |-- actions
|   |   `-- counter.js         # カウンターアクションの定義
|   |-- components
|   |   `-- Button.js          # ボタン用コンポーネント
|   |-- containers
|   |   `-- LayoutContainer.js # 各ページの側端コンテナ
|   |-- declares               # 外部モジュールの型定義 (ほぼanyをexports)
|   |   `-- ****.js
|   |-- index.html             # ベースHTML
|   |-- index.js               # フロント側エンドポイント
|   |-- pages
|   |   |-- CounterPage.js     # カウンターページ
|   |   |-- HelloPage.js       # 挨拶用ページ
|   |   `-- TopPage.js         # トップページ
|   |-- reducers
|   |   |-- counter.js         # カウンターReducer
|   |   `-- index.js           # Reducerのインデックス
|   |-- sagas
|   |   |-- counter.js         # カウンターの非同期処理
|   |   `-- index.js           # 非同期処理のインデックス
|   |-- server.js              # サーバー側エンドポイント
|   `-- types
|       |-- Action.js          # Action(Fluxスタンダード)の型定義
|       `-- Counter.js         # カウンター関連の型定義
`-- package.json

非同期周りの処理にredux-sagaを使ってますが、今回はその辺りの解説は省きます。

ポイントいくつか

サンプルアプリ実装の際に、工夫した点/苦労した点を以下にまとめておきました。

StateやActionの型定義をする

ReduxのStateやActionのPayload値は、動的言語らしく何でも入れる事が可能です。一人で開発するのなら良いですが、複数人で開発する場合、Action->Reducer->Viewで引き回す型の認識が合わず、思わぬバグが発生しかねません。

なるべく一つの型定義を使いまわし、値の引き回しに規約を与える必要があります。

FluxスタンダードなAction型の定義

// src/types/Action.js
export interface Action {
  type: string;
  error?: boolean;
  meta?: any;
}

export interface PayloadAction<T> extends Action {
  payload: T;
}

Action関数が返すべきオブジェクトの型定義をします。

GitHub: acdlite/flux-standard-action
https://github.com/acdlite/flux-standard-action

非公式ではありますが、HumanフレンドリーなAction型として定評のあるFluxスタンダードに沿う形のAction型を組みました。

個人的に、PayloadがあるActionとないActionとで、型を分けたかったので、分離してあります。Payloadに使う型は以下項目のように、ジェネリクスで指定できます。

Counter関連の型を定義する

// src/types/Counter.js
import type { Action, PayloadAction } from "types/Action"

export interface CounterState {
  num: number;
}

export interface IncrementPayload {
  num: number;
}

export interface IncrementAction extends PayloadAction<IncrementPayload> {}
export interface ResetAction extends Action {}
export type CounterAction = IncrementAction & ResetAction

StateやActionの型を一つのファイルに定義しておきます。

定義した型をActionやReducerで使い回す

上で定義した共通の型設定をAction関数やReducer関数で読み込みます。

Action関数の定義で使い回す

// src/actions/counter.js
import type { IncrementAction, ResetAction } from "types/Counter"

export const REQUEST_INCREMENT = "COUNTER__REQUEST_INCREMENT"
export const EXECUTE_INCREMENT = "COUNTER__EXECUTE_INCREMENT"
export const RESET = "COUNTER__RESET"

export function requestIncrement(num: number): IncrementAction {
  return { type: REQUEST_INCREMENT, payload: { num } }
}

export function executeIncrement(num: number): IncrementAction {
  return { type: EXECUTE_INCREMENT, payload: { num } }
}

export function reset(): ResetAction {
  return { type: RESET }
}

src/types/Counter.jsで定義したものを返り値の型として使いまわしています。Action関数ごとに型定義をするかしないかは、個人の好みとなります。

Reducer関数の定義で使い回す

import { EXECUTE_INCREMENT, RESET } from "actions/counter"
import type { CounterState, CounterAction } from "types/Counter"

export const initialState: CounterState = { num: 0 }

export default function counter(
  state: CounterState = initialState,
  action: CounterAction,
): CounterState {
  switch (action.type) {
    case EXECUTE_INCREMENT: {
      return { num: state.num + action.payload.num }
    }
    case RESET: {
      return { ...initialState }
    }
    default: {
      return state
    }
  }
}

Actionで使っているCounterActionは全てのAction関数の返り値型をIntersectionした型です。

export type CounterAction = IncrementAction & ResetAction

以下のように、Unionにしてもよいのですが、

export type CounterAction = IncrementAction | ResetAction

payloadキーが存在するかしないか、逐一チェックする必要があるため、めんどうです。

case EXECUTE_INCREMENT: {
  const incrementNum = action.payload ? action.payload.num || 0 : 0
  return { num: state.num + incrementNum }
}

コンポーネントのProps型はプロパティ変数で定義

propsというプロパティ変数に型をつけることで、ReactのPropTypesのようなチェックをできます。PropTypesは定義方法(isRequredとか)が独特な点、ランタイムエラーしかでない点で、個人的には使いづらい印象でした。

flowのpropsプロパティを利用すれば、実行前の型チェック時にエラーが出るため、見逃しづらいのと、型定義もflowと同様な方法でできるので、統一感が出ます。

コンポーネントのプロパティ変数でPropsの型定義ができる

// src/pages/CounterPage.js を改変
class CounterPage extends Component {
  props: {
    counter: CounterState, // クラス型やオブジェクト型も指定しやすい
    dispatch: (action: Action) => any, // 関数型も定義可能
    num?: number, // 任意項目については、プロパティ名後ろに`?`をつける
  };
  // ...
  render() {
    const { counter } = this.props // connectしたCounterState型
    const { hoge } = this.props // Err! 未定義のプロパティは取り出せない
    // ...
  }
}

// 使う側の例
render() {
  return <CounterPage num="String" /> // Err! 型に合わないプロパティは設定できない
}

コンポーネント内で使うActionはconnectしない

react-reduxのconnectで、Action関数をpropsに関連付けてしまうと、自分で定義した型情報が消し飛んでしまうので、コンポーネントのPropsで、Action関数の型を再定義する必要があります。

それは面倒＆冗長なので、直接Action関数を使い、その返り値をdispatchすれば、Action関数の元の型定義を使いまわせます。

dispatch関数を直接propsに回す

// src/pages/CounterPage.js
export default connect(
  ({ counter }) => ({ counter }),
)(CounterPage)
// 第二引数に何も書かなければ、dispatch関数が直接、propsに渡される

action関数をconnectを通さないことで、元の型定義のまま使える

// src/pages/CounterPage.js
import * as actions from "actions/counter"

handlePressIncrement() {
  const { dispatch } = this.props
  dispatch(actions.executeIncrement(1)) // ここ
}

まとめ

React+Reduxでflowを使った型定義の方法をまとめました。

StateやActionの型定義をする
定義した型をActionやReducerで使い回す
コンポーネントのProps型はプロパティ変数で定義
コンポーネント内で使うActionはconnectしない

今回はあまり使いませんでしたが、業務ドメイン関係の型定義(ActionのPayloadやStateの中で使う型)は、Reduxなどのフレームワークに依存せず、別フレームワークでも使いまわせる可能性があるので、積極的に型定義をしていきたいです。

静的型チェッカーflowのクラスでPrivateなフィールドを定義するメモ

Thu, 12 May 2016 08:00:00 +0900

flowはJavaScriptの型チェッカーだが、TypeScriptみたくPrivateフィールドを定義できるわけではなく、ちょっとした工夫が必要だったので、メモ。

なんでPrivateフィールドが必要？

インスタンス生成後に外部からフィールド値を変更させたくないため。
- ドメイン駆動設計(DDD)的なクラス設計をしていると、イミュータブル(不変)のエンティティや値オブジェクトのようなものを多用する。
- イミュータブルであることを保証できれば、安心してインスタンスを参照で保持できる。(DeepCopyをする必要がなくなる)
Public箇所(API)を最小限にしておおきたい。
- リファクタリングやテスト記述が楽になる。

などなど。

flowのmunge_underscoresオプションを使う方法

flowオプションのmunge_underscoresを有効にすると、先頭に_(アンダースコア)を付けたフィールド/メソッドは、継承先で使えない。というルールを追加することができる。

.flowconfig 追記

[options]
+ munge_underscores=true

実装例

GitHub上の使用例を参考にして、Privateフィールドを実現してみる。

// @flow

type Param = {
  field1: number,
  field2: string,
}

class PrivateSample {
  _param: Param;

  constructor(param: Param) {
    this._param = param;
  }

  getField1(): number {
    return this._param.field1;
  }

  _getField2(): string {
    return this._param.field2;
  }
}

export default class Sample extends PrivateSample {}

実際にflowをかけると、以下の様なエラーになる。

const sample = new Sample({
  field1: 5,
  field2: "test",
})
assert(sample.getField1() === 5) // OK
assert(sample._getField2() === "test") // NG
assert(sample._param.field1 === 5) // NG

error| property `_param` Property not found in (:0:1,0) Sample
error| property `_getField2` Property not found in (:0:1,0) Sample

先頭に_(アンダースコア)、ハンガリアン記法的なキモさがあって、あまり使いたくないが、一番flowっぽい解決法といえる。

継承元のクラスを直接インスタンス化すると使えちゃう

ちなみに、継承元のPrivateSampleを直接使うと、エラーは出ない。継承しないと効果がないみたいなので、継承元のクラスはexportしないほうが良さそう。

const sample = new PrivateSample({
  field1: 5,
  field2: "test",
})
assert(sample.getField1() === 5) // OK
assert(sample._getField2() === "test") // OK
assert(sample._param.field1 === 5) // OK

ES6のWeakMapを使う方法

flowに限ったものではないが、ES6でPrivateなフィールドを定義する方法論がある。

ES6 class での private プロパティの定義
http://qiita.com/k_ui/items/889ec276fc04b1448674

Symbolアクセスを使う方法は、Object.getOwnPropertySymbolsを使えば、外部から値を変更することが可能なため、今回は避けた。

WeakMapでも同じファイル内ならアクセスできるが、インスタンスを作るのは概ね別ファイルなので、あまり問題ないと思った。

実装例

// @flow

type Param = {
  field1: number,
  field2: string,
}

const privates: WeakMap<Object, Param> = new WeakMap();

export default class Sample {

  constructor(param: Param) {
    privates.set(this, param);
  }

  getField1(): number {
    return privates.get(this).field1;
  }

  getField2(): string {
    return privates.get(this).field2;
  }
}

コンソールデバッグがしづらい

WeakMapの方法で、Privateフィールド化していると、コンソールでのデバッグに苦労する。

const sample = new Sample({
  field1: 5,
  field2: "test",
});
console.log(sample);

としても、フィールドの内容は表示されず、以下の様なダンプに。

Sample {}

実質、インスタンス内のプロパティには含まれていないので、表示出ないのは当たり前ではある。privatesのWeakMapをダンプすれば、以下の様な表示はされるが、ファイル外からでは参照できないので、厳しい。

WeakMap {Sample {} => Object {field1: 1234, field2: "test"}}

[おまけ] Privateなメソッドも定義できる？

同ファイル内のClass外に関数を定義して、Classメソッド内で使えば実現できなくもない。

const privates: WeakMap<Object, Param> = new WeakMap();

export default class Sample {

  constructor(param: Param) {
    privates.set(this, param);
  }

  getField1(): number {
    return privates.get(this).field1;
  }

  getField2(): string {
    return privates.get(this).field2;
  }
+
+  getPowField1(num: number) {
+    return powField1(this, num);
+  }
}

+// Private method
+function powField1(instance: Sample, num: number) {
+  return Math.pow(privates.get(instance).field1, num);
+}

ただ、ESLintを併用していると、no-use-before-defineに引っかかったりする。ちとまどろっこしいね。

備考・注意点

コンストラクタ引数にObjectを渡して、WeakMapにそのままセットする。名前引数的に使えるので、コードの見通しがよくなる。

const sample = new Sample({
  field1: 1234,
  field2: "Text",
});

ただし、コンストラクタ引数へ渡すObjectを変更可能にしておくと、イミュータブルじゃなくなってしまうので、注意。

let param = {
  field1: 1234,
  field2: "Text",
};
const sample = new Sample(param);

// non-immutable
param.field1 = 2345;

コンストラクタ内で、ObjectのShallowCopyを行うなどして、対策すると良いかもしれない。

constructor(param: Param) {
  // ES7の`object-rest-spread`を使うと楽
  Sample.privates.set(this, { ...param });
}

まとめ

JavaScriptの言語仕様上、Private関係は実装しにくく、どうしてもまどろっこしい書き方になってしまう。それでも、TypeScriptを含め、様々なトランスパイラが生まれた今、以前に比べれば、ずいぶんとPrivateを実現しやすくなったと思う。

JavaScriptとprivateの見果てぬ夢
http://blog.tojiru.net/article/238901975.html

言語仕様を超える夢を見て、戦い続けた男たちに敬意を表したい。

静的型チェッカーflowを使ってみて、微妙に気になったこと４つ

Thu, 12 May 2016 07:00:00 +0900

flowはJavaScriptの静的型チェックツールの一つ。

同じような静的型関連ツールであるTypeScriptと比較して、ESLintやBabelとの併用がしやすかったり、型付けが強めだったり(初期からnon-nullableに対応)と、受ける恩恵も多い。

が、使っていて「おやっ？」っと思う点もいくつかあったので、まとめてみた。

気になったこと４つ

ESLintとの併用でめんどうな事が多かった

babel-eslintというBabelパーサーを用いれば、概ねのESLintルールがflow文法でも適応できるが、例外もあった。

例えば、インターフェイスの定義の場合、

interface I {
  field: number;
  method(): string;
}

ESLintのno-undefルールを有効にしていると、以下のエラーが発生する。

error| 'I' is not defined. (no-undef)

ESLintの誤爆ではあるが、そもそも、interfaceなんて文法はECMAScriptにはないので、対応しろっていうのも無茶な話。

ESLintのno-undefまわりを無効にすればエラーは出ないが、有志の方が、flow用のBabelカスタムルールを実装してくれているので、ありがたく利用させていただく。

GitHub: zertosh/eslint-plugin-flow-vars
https://github.com/zertosh/eslint-plugin-flow-vars

このBabelプラグインを使ってカスタムルールを有効にすれば、no-undefを無効にすることなく、ESLintとflowを併用できる。

// .eslintrc.jsの修正例
module.exports = {
  "parser": "babel-eslint",
+ "plugins":
+   "flow-vars",
+ ],
  "rules": {
    "no-undef": 1,
+   "flow-vars/define-flow-type": 1,
+   "flow-vars/use-flow-type": 1,
  },
};

その他、いろいろ試行錯誤している時にTwitter上でご教示いただいたPluginも、いくつかのflow用カスタムルールがあった。何かflow+ESLintで不都合があり次第、逐一有効にしていく必要があるかも。

@namikingsoft eslint-plugin-babel はすでにお試しでしょうか？ eslint 組込ルールの中で、ECMA標準外の構文に起因する誤検知などに対処しているプラグインです。https://t.co/CD5p5ejHIq
— Toru Nagashima (@mysticatea) 2016年5月5日

Babelを通しても、ES6文法で使えないものがある

例えば、ES6のget/setプロパティが使えなかった。

イミュータブルなオブジェクトを作って、Privateな値を返すゲッターを作った際、プロパティのように扱えるので、好んで使っていたが、

class A {
  get field(): number {
    return 1234
  }
}

const a = new A()
console.log(a.field)

flowに通すと、怒られる。

error| get/set properties not yet supported

yetってあるので、いずれサポートされるのだろうか。

ジェネリクスなクラス/関数の使い方次第でエラー

flow的にはPolymorphismというのかな？
TypeScriptやJava感覚で以下のように書くと、flowだとSyntaxエラーになった。

const map = new Map<string, number>()

error| Parsing error: Unexpected token

そもそもBabelがエラーを吐く。babel-plugin-transform-flow-strip-typesの限界っぽい。

以下のように書くのがflow流っぽいが、なんか冗長な感じがして、あまり好みじゃない。

// 変数定義で型を決めとく
const map: WeakMap<string, number> = new WeakMap()

// 型のキャスト
const map = (new WeakMap(): WeakMap<string, number>)

関数の場合も似たようなSyntaxエラーを吐くが、以下の様な型推論が効く例だと、逆にスマートな感じで良い。

function toArray<T>(x: T): Array<T> {
  return [x]
}

// 引数の型(number)を元に、返り値の型(Array<number>)が推論される
const nums = toArray(2)

クラスのフィールド定義などでセミコロンが強制

クラスやインタフェースの定義などで、以下のように書くと、

class A {
  num: number

  constructor(num: number) {
    this.number = num
  }
}

次のエラーが、constructorの行で発生する。

error| Unexpected identifier

フィールド定義の行末尾にセミコロン(;)を入れれば、エラーは出ない。

class A {
- num: number
+ num: number;

  constructor(num: number) {
    this.number = num
  }
}

アンチ・セミコロン派には吐きそうなほどキツイ仕様。
https://github.com/facebook/flow/issues/825

まとめ

flowを使ってみて、以下４つの気になったことをまとめてみた。

ESLintとの併用でめんどうな事が多かった
Babelを通しても、ES6文法で使えないものがある
ジェネリクスなクラス/関数の使い方次第でエラー
クラスのフィールド定義などでセミコロンが強制

flowは現在も、定期的にVerUPされているツールなので、今回上げた点もいつの間に修正されているかもしれない。今後も細かく見ていきたい。

サーバーサイドReactをwebpackを使って最小構成で試す (ES6 ＆ TypeScript)

Sat, 13 Feb 2016 07:30:00 +0900

サーバーサイドのReactに触れたことがなかったので、React+Express+webpackで試してみた。今回試行した手順をチュートリアル的にまとめておく。まずは、シンプルにできそうなECMAScript6で試して、後半にTypeScriptで組んだソースも、おまけ的に載せておきます。

この記事の方針

クライアント -> サーバーサイド -> 結びつける。の順に実装を行う
なるべくシンプルにするために、実用構成というよりは、最小構成で動かす。
- コンポーネントのプリレンダやState遷移の確認までを行う。
- サーバーAPIとの通信や画面遷移は、今回扱わない。

実装するサンプルアプリの内容

チュートリアルでよくありそうな、シンプルなカウンターアプリを動かす。

事前に必要なソフトウェア

node.js (v5.6.0)
npm (v3.6.0)

現時点の安定版を使ってみたが、そこまで新しくなくても問題ない。

[Memo] 利用したnpmパッケージのバージョン

"dependencies": {
  "express": "^4.13.4",
  "react": "^0.14.7",
  "react-dom": "^0.14.7"
},
"devDependencies": {
  "babel-cli": "^6.5.1",
  "babel-loader": "^6.2.2",
  "babel-preset-es2015": "^6.5.0",
  "babel-preset-react": "^6.5.0",
  "dtsm": "^0.13.0",
  "ts-loader": "^0.8.1",
  "typescript": "^1.7.5",
  "webpack": "^1.12.13"
}

バージョンが新しくなったりすると、この記事の書き方と変わってくる可能性があるので、注意。

ECMAScript6 版 (チュートリアル)

ReactドキュメントのGetting Startedでも、Babelを利用しているようなので、まずは、Babelを使って、ECMAScript6で記述できるようにしてみる。なお、サンプルソースの完成版を以下のリポジトリに置いといたので、参考にされたい。

ECMAScript6版サンプルソースの完成版
https://github.com/namikingsoft/sample-react-server/tree/typescript

まずはクライアント側で動かしてみる

ファイル構成は以下の様な感じになるように、作業をすすめる。

react-server
|-- .babelrc            # Babel設定
|-- package.json        # npm設定
|-- public
|   |-- client.js       # webpackによって吐き出されたフロント用のJS
|   `-- test.html       # クライアント確認用
|-- src
|   |-- client.js       # クライアントJSエントリーポイント
|   `-- components
|       `-- Counter.js  # カウンター用Reactコンポネント
`-- webpack.config.js   # webpack設定

npm init

mkdir react-server
cd react-server

npm init

適当なディレクトリを作り、package.jsonのテンプレートを作っておく。npm initの選択肢も全て空Enterで問題ない。

必要なnpmパッケージをインストール

npm install --save react react-dom
npm install --save-dev webpack babel-loader babel-preset-es2015 babel-preset-react

モダンブラウザによっては、babel-preset-es2015はいらないかもだが、一応。

webpack.config.js

var webpack = require('webpack');

module.exports = {
  entry: {
    client: "./src/client.js",
  },
  output: {
    filename: '[name].js',
    path: "./public",
  },
  module: {
    loaders: [
      {
        test: /\.jsx?$/,
        loaders: ['babel'],
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: ['', '.js', '.jsx'],
    modulesDirectories: ['node_modules'],
  },
};

なるべくシンプルにするため、HotLoaderなど記述は入れていない。

.babelrc

{
  "presets": ["es2015", "react"],
}

Babelの設定ファイル。React -> ES6 -> ES5のような感じで、どのブラウザでも割りかし動作するように変換する。

public/test.html

<!DOCTYPE html>
<html>
  <head>
    <title>App</title>
  </head>
  <body>
    <div id="app"></div>
    <script src="app.js"></script>
  </body>
</html>

クライアントJSの動作確認用HTML。app.jsが実行された後に、<div id="app"></div>の中身がCounterコンポーネントに置き換わる。

src/client.js

import React from 'react'
import ReactDOM from 'react-dom'
import Counter from './components/Counter'

ReactDOM.render(
  <Counter />,
  document.getElementById('app')
)

Counterコンポーネントを<div id="app" />に表示する。

src/components/Counter.js

import React, {Component} from 'react'

export default class Counter extends Component {

  constructor() {
    super()
    this.state = {
      count: 0
    }
  }

  render() {
    return (
      <div>
        <p>Count: {this.state.count}</p>
        <button onClick={e => this.increment()}>Increment</button>
      </div>
    )
  }

  increment() {
    this.setState({
      count: this.state.count + 1
    })
  }
}

Incrementボタンを押したら、内部Stateが変化して、コンポーネントを再描写される。

webpack実行

./node_modules/.bin/webpack

これで、public/client.jsにブラウザで動作するJSが生成される。

webpackコマンドについては、npm run buildコマンドで実行できるように、package.jsonのscriptsに登録しておくと良いかも。

"scripts": {
  "build": "webpack"
}

npm run build

動作確認

Incrementボタンを押して、Stateの変動やコンポーネントの再描写が確認できる。

サーバーサイドからコンポーネントを描写する

ファイル構成としては以下。src/server.jsが追加されただけ。

react-server
|-- package.json
|-- public
|   |-- client.js
|   `-- test.html
|-- src
|   |-- client.js
|   |-- components
|   |   `-- Counter.js
|   `-- server.js     # 追加: ExpressでCounterコンポーネントをプリレンダリング
`-- webpack.config.js

必要なnpmパッケージをインストール

npm install --save express
npm install --save-dev babel-cli

軽量Webフレームワークのexpressと、node.jsの実行をbabelに通すためのbabel-cliをインストールする。

src/server.js

import express from 'express'
import React from 'react'
import ReactDOMServer from 'react-dom/server'
import Counter from './components/Counter'

// init express
const app = express()

// add top page routing
app.get('/', (req, res) => {
  res.send(
    ReactDOMServer.renderToString(
      <Counter />
    )
  )
})

// start listen
app.listen(3000, () => {
  console.log('Example app listening on port 3000!');
})

ReactDOMServer.renderToString()を使って、コンポーネントをプリレンダリングできる。
(HTMLの側端は端折ってます)

サーバー起動

node_modules/.bin/babel-node src/server.js

babel-nodeはbabel-cliでインストールされるコマンドで、実行対象のJSを自動的にBabel変換した上でnodeコマンドを実行してくれる便利なラッパー。

ビルドと同じく、npm startコマンドで実行できるように、package.jsonのscriptsに登録しておくと良い。

"scripts": {
  ...
  "start": "babel-node src/server.js"
}

npm start

動作確認

open http://localhost:3000

クライアントのみの実行と、全く同じ画面が表示される。ブラウザのソース表示やcurlなどからも、コンポーネントの中身がプリレンダリングされたHTMLを確認できた。

しかし。

サーバーサイドでプリレンダしただけで、クライアントでは何もしてないし、react.jsも読み込んでないため、と思われる。

サーバーサイドとクライアントの処理をつなげる

Fluxフレームワークで有名なReduxのドキュメントのServer Renderingを見るに、サーバーサイドでプリレンダした要素に、再度クライアントからレンダリングをかけている様な処理になっていたので、試してみる。

src/server.js の修正

import express from 'express'
import React from 'react'
import ReactDOMServer from 'react-dom/server'
import Counter from './components/Counter'

// init express
const app = express()

+ // add static path
+ app.use(express.static('public'))

// add top page routing
app.get('/', (req, res) => {
  res.send(
    ReactDOMServer.renderToString(
-      <Counter />
+      <div>
+        <div id="app">
+          <Counter />
+        </div>
+        <script src="client.js" />
+      </div>
    )
  )
})

// start listen
app.listen(3000, () => {
  console.log('Example app listening on port 3000!');
})

app.use(express.static('public'))で、publicディレクトリ以下のファイルを静的ファイルとして、読み込み可能として、プリレンダする内容をクライアント側の時に試したtest.htmlと同じような記述に変更する。

再度、動作確認

npm start
open http://localhost:3000

今度は、Incrementボタン押下で、正常動作を確認できるはず。

TypeScript 版 (要約)

型がついていないと落ち着かない自分のためにも、TypeScriptで導入できるようにもしておきたい。クライアント側はts-loaderを挟むぐらいで概ね対応できるが、サーバーサイドはbabel-nodeに相当するものがないようので、一度コンパイルしてから実行するようなイメージ。

Typescript版サンプルソースの完成版
https://github.com/namikingsoft/sample-react-server/tree/typescript
ECMAScript6版との差分
https://github.com/namikingsoft/sample-react-server/compare/typescript

要約

TypeScript版については、上のようにチュートリアル形式にはせず、要約解説にしたい。詳しくは上のECMAScript6版との差分を見ていただいたほうが、早いかもしれない。

型定義ファイルマネージャにはdtsmを使った。

npmとほぼ同じインタフェースなので使いやすい。以下コマンド例。

npm install --save-dev dtsm
export PATH=./node_modules/.bin:$PATH

dtsm init
dtsm install --save react.d.ts
dtsm install --save react-dom.d.ts
dtsm install --save express.d.ts

サーバーサイドのコンパイルはtscを直接使った。

babel-nodeのようなラッパーコマンドがあることを期待したが、観測内ではなさそうなので、通常通り、distディレクトリあたりに、コンパイル済みのJSを展開して、node dist/server.jsみたいにする作戦にした。

tsconfig.jsonは以下のとおり。

{
  "compilerOptions": {
    "target": "es5",
    "jsx": "react",
    "module": "commonjs",
    "moduleResolution": "node",
    "experimentalDecorators": true,
    "outDir": "dist"
  },
  "files": [
    "typings/bundle.d.ts",
    "src/server.tsx"
  ]
}

なお、tsconfig.jsonはクライアント側のコンパイルにも使いまわしたいので、React変換なども有効にしてある。experimentalDecoratorsはいらないかもだが、ReduxなどのFluxフレームワークで、割りとデコレータ(@connectなど)が使われていたりするので、一応有効にしてある。

コンパイルについては、package.jsonのscriptsを以下のように修正して、npm run buildでやると良い。

"scripts": {
  ...
- "build": "webpack",
+ "build": "webpack && tsc -p .",
  ...
},

npm run build

クライアントのコンパイルにはwebpackのts-loaderを使った。

webpack.config.jsの修正差分は以下の様な感じになる。なお、TypeScript自体が、React -> ES6 -> ES5変換機能を備えているので、無理にBabelに通さなくてもよい。

var webpack = require('webpack');

module.exports = {
  entry: {
-   client: "./src/client.js",
+   client: "./src/client.tsx",
  },
  output: {
    filename: '[name].js',
    path: "./public",
  },
  module: {
    loaders: [
      {
        test: /\.jsx?$/,
        loaders: ['babel'],
        exclude: /node_modules/,
      },
+     {
+       test: /\.tsx?$/,
+       loaders: ['ts'],
+       exclude: /node_modules/,
+     },
    ],
  },
  resolve: {
-   extensions: ['', '.js', '.jsx'],
+   extensions: ['', '.js', '.jsx', 'ts', '.tsx'],
    modulesDirectories: ['node_modules'],
  },
};

あとがき

なるべくシンプルな構成で、サーバーサイドReactを試してみた。

今回はサーバーサイドにExpressを使ってみたが、Railsなどでも、react-railsのようなgemを利用して、クライアントとの連携ができるはず。

ReduxやReactRouterなどを利用した、もうちょっと実践的なやり方については、以下のReduxドキュメントやQiita記事が詳しそうだったので、載せておきます。

Redux: Server Rendering
https://github.com/rackt/redux/blob/master/docs/recipes/ServerRendering.md

Qiita: React + Expressでのサーバーサイドレンダリング方法のまとめ
http://qiita.com/hmarui66/items/4f75e624c4f70d596873

Sparkで機械学習：回帰モデルで値を予測する

Sun, 31 Jan 2016 23:15:00 +0900

Apache Spark上にて、簡単なCSVのサンプルデータを取り込み、線形回帰や決定木回帰を利用して、穴が空いた項目を予測するサンプルプログラムを書いてみる。

サンプルデータ (身体情報から結婚時期を予測する)

実データではありません。入門用にシンプルで法則性のあるデータを探したのですが、なかなか見つからなかったので、自分で訓練用のデータを作ってみた。

題材としては、性別や血液型、身長、体重から、結婚適齢期を予測するみたいなことをやってみる。例えば、以下の様なデータを学習用データとして取り込み、

結婚した歳	血液型	性別	身長(cm)	体重(kg)
32歳	O	女	152	60
42歳	A	男	180	80
26歳	O	男	155	55
20歳	B	女	166	55
…	…	…	…	…

以下の「？」になっているところの値を予測する、みたいなことをやってみる。

結婚する歳	血液型	性別	身長(cm)	体重(kg)
？	O	女	152	60
？	A	男	180	80

サンプルデータ：身体情報から結婚時期を予測する
CSV形式のダウンロード

データの傾向

ただ無差別にデータを作っても、予測が合ってるかどうかの判断がつかないため、
以下の様な事実無根な法則で値をでっちあげてみた。

B型は早婚
O型は晩婚
AB型はとても早婚
女性は早婚
肥満とモヤシは晩婚
男性の高身長はとても晩婚

コーディング前の準備

Apache Zeppelinのインストール

Spark(ScalaやPython)の記述やその他細かいシェルスクリプトなどの操作をWeb上でインタラクティブに行えるノートブック系OSS¹。この記事では、Sparkの操作は基本的にこのソフトを用いてコーディングを行っている。Sparkも一緒に含まれているので、これをローカルにインストールするだけで概ね動くはず。

Apache Zeppelin (incubating)
https://zeppelin.incubator.apache.org/

サンプルデータの取り込み

ここからは、Zeppelin上での作業となる。事前にZeppelinを起動して、適当な新しいノートブックを作成しておく。

サンプルデータのダウンロード

%sh
curl -Lo /tmp/training.csv \
  "http://blog.namiking.net/files/post/2016/01/spark-mllib-regression/training.csv"

先ほどのCSV形式のサンプルデータを一時保存領域にダウンロードするシェルスクリプトを記述する。

１レコード毎のCaseクラスを作成

case class Profile(
  marriedAge: Option[Double],
  blood: String,
  sex: String,
  height: Double,
  weight: Double
)

CSVデータなどをDataFrame形式に変換する際に必要になる。 marriedAgeをOption型にしているのは、テストデータを取り込む際に入れる値が無いため。

CSVをパースして、DataFrame形式に変換

var csvRDD = sc.textFile("/tmp/training.csv")
var csvHeadRDD = sc.parallelize(Array(csvRDD.first))
var training = csvRDD
  .subtract(csvHeadRDD) // ヘッダ除去
  .map { line =>
    val cols = line.split(',')
    Profile(
      marriedAge = Some(cols(0).toDouble),
      blood = cols(1),
      sex = cols(2),
      height = cols(3).toDouble,
      weight = cols(4).toDouble
    )
  }.toDF

RDDだと、tailやslice関数みたいなものがなくて、ヘッダ除去程度でもちょっとまどろっこしい。分散処理を考えるとしかたないのだろうか。

[おまけ] spark-csvモジュールを使ったサンプルデータの取り込み

先ほどの手順で、サンプルデータの取り込みは完了だが、もう１パターン、CSVのパースやDataFrame変換を手伝ってくれるspark-csvモジュールを使ったCSV取り込みを書いておく。

Zeppelinはパラグラフごとに実行するしないを制御できるので、別パターンのコードや使わなくなったコードも、そのまま残しておいても支障はない。後になって再利用できたりするので、残しておくと便利かも。

依存モジュールロード

%dep
z.reset()
z.load("com.databricks:spark-csv_2.11:1.3.0")

%dep(Dependency)については、Sparkが起動する前に行わないと、以下の様なエラーが出る。

Must be used before SparkInterpreter (%spark) initialized
Hint: put this paragraph before any Spark code and restart Zeppelin/Interpreter

既に起動してしまっている場合は、Zeppelinを再起動するか、InterpreterページのSpark欄のrestartボタンを押下する。

spark-csvを使ったCSVの取り込み

import org.apache.spark.sql.types.{
  StructType,
  StructField,
  StringType,
  DoubleType
}
val customSchema = StructType(Seq(
  StructField("marriedAge", DoubleType, true),
  StructField("blood", StringType, true),
  StructField("sex", StringType, true),
  StructField("height", DoubleType, true),
  StructField("weight", DoubleType, true)
))
val training = sqlContext.read
  .format("com.databricks.spark.csv")
  .option("header", "true")
  .schema(customSchema)
  .load("/tmp/training.csv")

CSVのパースやヘッダ除去(項目名に利用)まで自動で行ってくれる。型指定まで自動で行うオプション(inferSchema)もあるが、Double型がInteger型になってしまったので、今回は手動で指定した。

サンプルデータの前処理

Sparkの機械学習ライブラリでは、各分析アルゴリズムにデータを引き渡す前処理として、特徴データ(血液型、性別、身長、体重)を、まとめてベクトル形式に変換する必要がある。

そういった前処理を楽にするために、前処理や回帰モデル設定、訓練データ取り込みを一貫して行えるspark.mlのPipelineを利用してみる。Pipelineについては、公式のドキュメントが詳しい。別サイトに日本語訳もあった。

文字列インデクサ

import org.apache.spark.ml.feature.StringIndexer

val bloodIndexer = new StringIndexer()
  .setInputCol("blood")
  .setOutputCol("bloodIndex")
val sexIndexer = new StringIndexer()
  .setInputCol("sex")
  .setOutputCol("sexIndex")

StringIndexerはパイプラインをつなぐための部品の一つ。A,B,O,ABといった文字列のカテゴリデータを0.0,1.0,2.0,3.0みたいに実数のインデックスに変換してくれる。

複数項目のベクトル化

import org.apache.spark.ml.feature.VectorAssembler

val assembler = new VectorAssembler()
  .setInputCols(Array(
    "bloodIndex",
    "sexIndex",
    "height",
    "weight"
  ))
  .setOutputCol("features")

VectorAssemblerはパイプラインをつなぐための部品の一つ。複数項目の実数データを一つの特徴ベクトルデータに変換してくれる。

ベクトル標準化

import org.apache.spark.ml.feature.StandardScaler

val scaler = new StandardScaler()
  .setInputCol(assembler.getOutputCol)
  .setOutputCol("scaledFeatures")

StandardScalerはパイプラインをつなぐための部品の一つ。基準が違うデータを取り込むと予測が不安定になるため、特徴ベクトルデータを標準化する。

これで前処理のためのパイプライン部品は揃った。

線形回帰モデルの作成して、予測値を得る

まずは線形回帰を用いて、値の予測を行うためのモデルを作成する。

線形回帰

import org.apache.spark.ml.regression.LinearRegression

val regression = new LinearRegression()
  .setLabelCol("marriedAge")
  .setFeaturesCol(scaler.getOutputCol)

パイプライン部品の一つ。setLabelColには、予想したい項目を指定する。

パイプライン作成

import org.apache.spark.ml.Pipeline

val pipeline = new Pipeline()
  .setStages(Array(
    bloodIndexer,
    sexIndexer,
    assembler,
    scaler,
    regression
  ))

今までのパイプライン部品を繋げて、パイプラインを作成する。

クロス検証でチューニング設定をして、モデルを作成

import org.apache.spark.ml.evaluation.RegressionEvaluator
import org.apache.spark.ml.tuning.{
  ParamGridBuilder,
  CrossValidator
}

val paramGrid = new ParamGridBuilder()
  .addGrid(regression.regParam, Array(0.1, 0.5, 0.01))
  .addGrid(regression.maxIter, Array(10, 100, 1000))
  .build()

val evaluator = new RegressionEvaluator()
  .setLabelCol(regression.getLabelCol)
  .setPredictionCol(regression.getPredictionCol)

val cross = new CrossValidator()
  .setEstimator(pipeline)
  .setEvaluator(evaluator)
  .setEstimatorParamMaps(paramGrid)
  .setNumFolds(3)

val model = cross.fit(training)

モデルの精度を検証するために、クロス検証の設定をする。以下のような、めんどくさいチューニング処理を自動で行ってくれる便利な機能。

paramGridで設定した配列のチューニング値で、全組み合わせのモデルを作成する。
サンプルデータを訓練データと検証データに分けて、一番精度の高いモデルを選択する。

最終的にはmodel変数に最適なモデルが束縛される。

ちなみに、クロス検証を行わない場合は

val model = pipeline.fit(training)

パイプラインに直接学習データを突っ込む。

テストデータ作成

var test = sc.parallelize(Seq(
  // A型標準体型男
  Profile(None, "A", "男", 170, 65),
  // B型標準体型男
  Profile(None, "B", "男", 170, 65),
  // O型標準体型男
  Profile(None, "O", "男", 170, 65),
  // AB型標準体型男
  Profile(None, "AB", "男", 170, 65),
  // A型標準体型女
  Profile(None, "A", "女", 160, 50),
  // B型標準体型女
  Profile(None, "B", "女", 160, 50),
  // O型標準体型女
  Profile(None, "O", "女", 160, 50),
  // AB型標準体型女
  Profile(None, "AB", "女", 160, 50),
  // A型もやし男
  Profile(None, "A", "男", 170, 35),
  // A型でぶ男
  Profile(None, "A", "男", 170, 100),
  // A型もやし女
  Profile(None, "A", "女", 170, 35),
  // A型でぶ女
  Profile(None, "A", "女", 170, 100),
  // A型高身長男
  Profile(None, "A", "男", 190, 80),
  // A型小人(男)
  Profile(None, "A", "男", 17, 6),
  // A型巨人(男)
  Profile(None, "A", "男", 17000, 6500)
)).toDF

学習データの特徴データから大幅に外れるデータの予測も下の方に入れてみた。

モデルから予測値を得る

model.transform(test)
  .select("blood", "sex", "height", "weight", "prediction").show

+-----+---+-------+------+------------------+
|blood|sex| height|weight|        prediction|
+-----+---+-------+------+------------------+
|    A|  男|  170.0|  65.0| 32.79763046781005|
|    B|  男|  170.0|  65.0|32.810260236687924|
|    O|  男|  170.0|  65.0|   32.803945352249|
|   AB|  男|  170.0|  65.0| 32.79131558337113|
|    A|  女|  160.0|  50.0|  28.7197777975515|
|    B|  女|  160.0|  50.0|28.732407566429345|
|    O|  女|  160.0|  50.0|28.726092681990423|
|   AB|  女|  160.0|  50.0| 28.71346291311255|
|    A|  男|  170.0|  35.0|36.194018649003766|
|    A|  男|  170.0| 100.0|28.835177589750728|
|    A|  女|  170.0|  35.0| 36.18913457728998|
|    A|  女|  170.0| 100.0| 28.83029351803694|
|    A|  男|  190.0|  80.0|  42.6417617554965|
|    A|  男|   17.0|   6.0|-48.82159525304273|
|    A|  男|17000.0|6500.0|  9017.13917142714|
+-----+---+-------+------+------------------+

結果考察

男性/女性の結婚時期の違いは、うまいこと現れた。
血液型による違いが、ほとんど現れなかった。
肥満/標準/もやしの違いは、よくわからない。
男性高身長のルールはうまく反映されている。

ちなみに、南くんの恋人は生まれる50年前に結婚しており、巨神兵は結婚までに100世紀かかるらしい。突拍子もない結果に見えるが、身長が高いほど結婚が遅いというルールを線形的に捉えてくれているようにも見える。

決定木回帰モデルを作成して、予測値を得る

決定木はクラス分類が得意な手法なので、今回のような細かいルールの設定でも、うまく予測してくれるかもしれない。

解析手法を変わるとはいえ、インタフェースが変わるわけではないので、大幅にコードを変える必要はなく、試行錯誤が楽。

クロス検証からモデルの作成まで

import org.apache.spark.ml.regression.DecisionTreeRegressor
import org.apache.spark.ml.Pipeline
import org.apache.spark.ml.evaluation.RegressionEvaluator
import org.apache.spark.ml.tuning.{
  ParamGridBuilder,
  CrossValidator
}

val regression = new DecisionTreeRegressor()
  .setLabelCol("marriedAge")
  .setFeaturesCol(scaler.getOutputCol)

val pipeline = new Pipeline()
  .setStages(Array(
    bloodIndexer,
    sexIndexer,
    assembler,
    scaler,
    regression
  ))

val paramGrid = new ParamGridBuilder()
  .addGrid(regression.maxBins, Array(2, 3, 4))
  .addGrid(regression.maxDepth, Array(10, 20, 30))
  .build()

val evaluator = new RegressionEvaluator()
  .setLabelCol(regression.getLabelCol)
  .setPredictionCol(regression.getPredictionCol)

val cross = new CrossValidator()
  .setEstimator(pipeline)
  .setEvaluator(evaluator)
  .setEstimatorParamMaps(paramGrid)
  .setNumFolds(3)

val model = cross.fit(training)

Regressorクラスの種類、paramGridで設定する項目が変わるぐらいで、その他は線形回帰のコードと変わらない。

評価実行

model.transform(test)
  .select("blood", "sex", "height", "weight", "prediction").show

+-----+---+-------+------+------------------+
|blood|sex| height|weight|        prediction|
+-----+---+-------+------+------------------+
|    A|  男|  170.0|  65.0|41.666666666666664|
|    B|  男|  170.0|  65.0|22.857142857142858|
|    O|  男|  170.0|  65.0|              47.0|
|   AB|  男|  170.0|  65.0|19.666666666666668|
|    A|  女|  160.0|  50.0|              34.0|
|    B|  女|  160.0|  50.0|              20.0|
|    O|  女|  160.0|  50.0|              29.5|
|   AB|  女|  160.0|  50.0|              19.0|
|    A|  男|  170.0|  35.0|              35.0|
|    A|  男|  170.0| 100.0|41.666666666666664|
|    A|  女|  170.0|  35.0|              35.0|
|    A|  女|  170.0| 100.0|              41.0|
|    A|  男|  190.0|  80.0|              44.0|
|    A|  男|   17.0|   6.0|29.333333333333332|
|    A|  男|17000.0|6500.0|              44.0|
+-----+---+-------+------+------------------+

結果考察

どのルールも学習データの値に近い形で、うまいこと予測された。
ただ、下２つの人外データに関しても、学習データに近い値が出てしまっているので、学習データの特徴値から大きくハズレるレコードの予測値は大味になってしまう？

まとめ

今回は、CSV形式のサンプルデータを線形回帰と決定木回帰を用いて、値の予測を行った。

線形回帰

細かいルールまでは予測しきれなかったが、学習データにない特徴を持つデータでも、うまく特徴を捉えようと、努力していた感があった。

決定木回帰

細かいルールに基づいた値をうまく予測してくれていたが、学習データにない特徴を持つデータに関しては、諦めていた感があった。

分析手法によって、予測結果の傾向が変わることを確認できた。今後、ランダムフォレスト回帰、勾配ブースト木回帰、生存回帰など色々な手法も試してみたい。

類似のOSSに、Jupyter(iPython Notebook)やspark-notebookがある。データの加工やモデルのチューニングで試行錯誤することが多いので、こういうソフトはかなり重宝する。 ^[return]

クラウドとローカルをVPNでガッチャンコしたDockerネットワークを組んでみる

Fri, 22 Jan 2016 02:30:00 +0900

クラウド上で組んだDockerのオーバーレイネットワークの中に、屋内ファイアウォール内のマシンで組んでたDockerを参加させることができないか、試してみた。

なぜに？ (余談)

例えば、以前の記事のようにクラウドで組んだSparkクラスタを利用するために、Apache Zeppelin¹を使ってみたい。最初は、SSHトンネルやSocksプロキシで手軽にできないだろうかと色々やってみたが、Sparkは一方通行な通信ではなく、双方向な通信を行うため、クラウドからローカルのネットワークに直接アクセス(pingなど)できる必要があるようで、動作するには至らなかった。

Spark関連は基本的に同じネットワーク内で動かすのが前提の仕様なため、Swarmクラスタと同じネットワーク内に入れる必要があるが、Zeppelinは、

割りとメモリ食い(推奨4GBほど)のため、Sparkクラスタと同じホストでは、動かしたくない。かといって、専用のホストを用意するできるブルジョアではない。
クラウドのSparkクラスタは使い終わったらすぐに破壊したいが、Zeppelinはnotebookや設定のデータを内部で持つため、作った後や消す前の同期が少し面倒。

なので、できれば、ローカルネットワーク内にZeppelinを持っておきたい。

この記事でやること

上のApache Sparkの例は置いといて、今回は取り急ぎクラウドとローカルを跨いだSwarmクラスタを構築して、Dockerオーバーレイネットワークの疎通確認を行いたい。検証のため、以下の図の様な構成を準備して、オーバーレイネットワークの疎通を確認する。

要点

ローカル環境とクラウドのDockerをVPNを用いて、オーバーレイネットワークで繋ぎたい。
VPN接続には、SoftEther VPN²を使ってみる。
ローカル側とクラウド側１台ずつ、Swarm Masterをレプリケーションした。
- クラウドのみでも、Swarmクラスタとして機能させたかったため。
- ローカルの作業用PCは、いちいちVPNに接続しなくても、Swarmクラスタを操作できるようにするため。

事前準備

必要なソフトウェアのインストール

作業で使うPC(またはホスト)に以下のソフトウェアをインストールしておく。

docker (バージョン1.9以上, オーバーレイネットワーク機能を使う)
docker-compose (動作検証に使うだけなので任意)
Virtualbox (vagrantを併用してもよい)

DigitalOceanの登録とアクセストークンの取得

登録後、管理画面からdocker-machineとの連携に必要なアクセストークンを発行できる。

https://www.digitalocean.com/

ノード用のホストを用意する

今回の例では、DigitalOceanでノードを２台とローカルでVirtualbox１台を用意する。

Type	Host	OS	Mem	VPNのIP
DigitalOcean	swarm-node0	ubuntu-15-10-x64	512MB	192.168.30.2 (手動)
DigitalOcean	swarm-node1	ubuntu-15-10-x64	512MB	192.168.30.x (自動)
Vitualbox(local)	swarm-local	ubuntu-15-10-x64	-	192.168.30.y (自動)

備考

swarm-node0はマスターノードとして使う
ホスト名(hostname)は別になんでもよい
プライベートネットワークは無効にしておく
VPNのIPについては、VPN接続後に割り当てる。

SoftEther VPN Serverを動かす

swarm-node0にSSHなどでログインして、作業を行う。

Linux版については、SoftEther VPNのサイトからソースコードをダウンロードして、コンパイルする。後で自動化しやすいように、GUIやインタラクティブCUIを使わないように書いておく。

ダウンロード

# 必要なパッケージのインストール
apt-get install -y curl gcc make

# SoftEther VPN ソースのダウンロード
cd /usr/local/src
curl -LO http://jp.softether-download.com/files/softether/v4.19-9599-beta-2015.10.19-tree/Linux/SoftEther_VPN_Server/64bit_-_Intel_x64_or_AMD64/softether-vpnserver-v4.19-9599-beta-2015.10.19-linux-x64-64bit.tar.gz
tar xzf softether-vpnserver-v4.19-9599-beta-2015.10.19-linux-x64-64bit.tar.gz

コンパイルとインストール

# コンパイル
cd vpnserver
make i_read_and_agree_the_license_agreement

# PATH設定
export PATH="/usr/local/src/vpnserver:$PATH"
echo 'export PATH="/usr/local/src/vpnserver:$PATH"' >> /etc/profile

サービス登録と起動 (systemd)

# サービス登録
cat << EOS > /lib/systemd/system/vpnserver.service
[Unit]
Description=SoftEther VPN Server
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/src/vpnserver/vpnserver start
ExecStop=/usr/local/src/vpnserver/vpnserver stop

[Install]
WantedBy=multi-user.target
EOS

# 自動起動設定＆起動
systemctl enable vpnserver
systemctl start vpnserver

VPNサーバー設定

# 各種設定項目 (値は任意で決める)
export HUBNAME=cluster
export HUBPASS=password
export USERNAME=user
export USERPASS=something
export SHAREDKEY=sharedkey

# 仮想HUB作成
vpncmd localhost /SERVER /CMD HubCreate $HUBNAME \
  /PASSWORD:$HUBPASS && true

# SNAT＆DHCP有効化
vpncmd localhost /SERVER /HUB:$HUBNAME /PASSWORD:$HUBPASS /CMD \
  SecureNatEnable

# ユーザー登録
vpncmd localhost /SERVER /HUB:$HUBNAME /PASSWORD:$HUBPASS /CMD \
  UserCreate $USERNAME \
  /GROUP:none \
  /REALNAME:none \
  /NOTE:none

# ユーザーパスワード設定
vpncmd localhost /SERVER /HUB:$HUBNAME /PASSWORD:$HUBPASS /CMD \
  UserPasswordSet $USERNAME \
  /PASSWORD:$USERPASS

# IPsec VPN有効化
vpncmd localhost /SERVER /CMD \
  IPsecEnable \
  /L2TP:yes \
  /L2TPRAW:no \
  /ETHERIP:yes \
  /PSK:$SHAREDKEY \
  /DEFAULTHUB:$HUBNAME

VPN設定のリファレンスは以下を参照。
https://ja.softether.org/4-docs/1-manual/6/6.4

SoftEther VPN Clientを動かす

全てのノードにSSHなどでログインして、作業を行う。
Serverと同じく、SoftEther VPNのサイトからソースコードをダウンロードして、コンパイルする。

ダウンロード

# 必要なパッケージのインストール
apt-get install -y curl gcc make

# SoftEther VPN ソースのダウンロード
cd /usr/local/src
curl -LO http://jp.softether-download.com/files/softether/v4.19-9599-beta-2015.10.19-tree/Linux/SoftEther_VPN_Client/64bit_-_Intel_x64_or_AMD64/softether-vpnclient-v4.19-9599-beta-2015.10.19-linux-x64-64bit.tar.gz
tar xzf softether-vpnclient-v4.19-9599-beta-2015.10.19-linux-x64-64bit.tar.gz
rm softether-vpnclient-v4.19-9599-beta-2015.10.19-linux-x64-64bit.tar.gz

コンパイルとインストール

# コンパイル
cd vpnclient
make i_read_and_agree_the_license_agreement

# PATH設定
export PATH="/usr/local/src/vpnclient:$PATH"
echo 'export PATH="/usr/local/src/vpnclient:$PATH"' >> /etc/profile

サービス登録と起動 (systemd)

# サービス登録
cat << EOS > /lib/systemd/system/vpnclient.service
[Unit]
Description=SoftEther VPN Client
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/src/vpnclient/vpnclient start
ExecStop=/usr/local/src/vpnclient/vpnclient stop

[Install]
WantedBy=multi-user.target
EOS

# 自動起動設定＆起動
systemctl enable vpnclient
systemctl start vpnclient

VPNサーバー設定

# 各種設定項目 (基本的にはServerの値と合わせる)
ACCOUNT=private
NICNAME=vlan0
SERVER="(swarm-node0のグローバルIP):443"
HUBNAME=cluster
USERNAME=user
USERPASS=something

# クライアント管理へのリモートログインを無効
vpncmd localhost /CLIENT /CMD RemoteDisable

# NIC作成 (この例だと、vpn_vlan0というインタフェースが作成される)
vpncmd localhost /CLIENT /CMD NicCreate $NICNAME

# アカウント作成
vpncmd localhost /CLIENT /CMD AccountCreate $ACCOUNT \
  /SERVER:$SERVER \
  /HUB:$HUBNAME \
  /USERNAME:$USERNAME \
  /NICNAME:$NICNAME

# アカウントパスワード設定
vpncmd localhost /CLIENT /CMD AccountPasswordSet $ACCOUNT \
  /PASSWORD:$USERPASS \
  /TYPE:standard

# アカウント自動起動設定
vpncmd localhost /CLIENT /CMD AccountStartupSet $ACCOUNT

# アカウント接続
vpncmd localhost /CLIENT /CMD AccountConnect $ACCOUNT

# swarm-node0では固定IP割り当て
ip addr add 192.168.30.2/24 dev vpn_$NICNAME

# その他ノードは自動割り当て
dhclient vpn_$NICNAME

swarm-node0だけは、DHCPでIPを振らずに固定IPを設定する。

VPN接続確認

SoftEther VPNのClientのセッティングが完了すると、以下の様な成果が出る。

各ノードにvpn_vlan0というインタフェースができる。
- vpn_vlan0を通して、pingなどの疎通ができるようになる。
各ノードに192.168.30.0/24のネットワークのIPが割り当てられる。
- 192.168.30.0/24はSoftEther VPNのデフォルト設定。
- DHCPで割り当てると、192.168.30.10〜が振られる。

これから設置するConsulやDockerは、このネットワークにのせるように設定する。

各ノードでConsulを動かす

インストールとサービス登録手順については、以前の記事にまとめてあるので参照されたい。ここではConsulサーバーの設定手順を示す。

swarm-node0にてサーバーモードで動かす設定

SSHでログインして、作業を行う。

# 自分自身のVPNのIPを取得
export MY_VPN_IP=$(
  ip addr show vpn_vlan0 \
  | grep -o -e '[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+' \
  | head -n1
)

# 設定ファイルに書き出す
cat << EOS > /etc/consul.d/config.json
{
  "server": true,
  "bootstrap": true,
  "bind_addr": "$MY_VPN_IP",
  "datacenter": "swarm0",
  "ui_dir": "/var/local/consul/webui",
  "data_dir": "/var/local/consul/data",
  "log_level": "INFO",
  "enable_syslog": true
}
EOS

VPNネットワークであるvpn_vlan0のIPにバインドする。
設定が終わったら、自動起動設定と起動を行っておく。

systemctl enable consul
systemctl start consul

swarm-node1とswarm-localにてクライアントモードで動かす設定

SSHでログインして、作業を行う。

# 自分自身のvpnのipを取得
export my_vpn_ip=$(
  ip addr show vpn_vlan0 \
  | grep -o -e '[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+' \
  | head -n1
)

# 設定ファイルに書き出す
cat << eos > /etc/consul.d/config.json
{
  "server": false,
  "start_join": ["192.168.30.2"],
  "bind_addr": "$MY_VPN_IP",
  "datacenter": "swarm0",
  "ui_dir": "/var/local/consul/webui",
  "data_dir": "/var/local/consul/data",
  "log_level": "INFO",
  "enable_syslog": true
}
EOS

joinするIPは固定で割り当てたswarm-node0のものを指定。
設定が終わったら、自動起動設定と起動を行っておく。

systemctl enable consul
systemctl start consul

メンバー確認

各ノードのConsulが連携できているかを確認する。

$ consul members

Node     Address            Status  Type    Build  Protocol  DC
******  192.168.30.2:8301   alive   server  0.6.1  2         swarm0
******  192.168.30.10:8301   alive   client  0.6.1  2         swarm0
******  192.168.30.11:8301   alive   client  0.6.1  2         swarm0

WebUIで確認する場合、ローカルPCのOS設定などから、swarm-node0へVPN接続を行えば、ブラウザで閲覧できる。

open http://192.168.30.2:8500

各ノードでDockerを動かす

全3ノードに対して、SSHでログインして作業を行う。
リモートからDockerを操作するため、TCPの2375ポートを使う。
リモートからSwarmマスターを操作するために、TCPの3375ポートを使う。
VPNネットワークがあるので、TLS認証は使わない。
ただし、vpn_vlan0以外はポートをファイアウォールで閉じておく。

インストール

wget -qO- https://get.docker.com/ | sh

ファイアウォール設定

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 2375 -j DROP
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 3375 -j DROP

DigitalOceanのノードのみでよい。

Dockerデーモン起動時の引数設定

vi /lib/systemd/system/docker.service

# 変更前
ExecStart=/usr/bin/docker daemon -H fd://
# 変更後
ExecStart=/usr/bin/docker daemon \
  -H=0.0.0.0:2375\
  --cluster-store=consul://localhost:8500 \
  --cluster-advertise=vpn_vlan0:2375 \
  -H fd://

変更後は見やすさのため複数行で書いているが、\を消して1行ぶっ続けで記述する。

Docker再起動

service docker restart

各ノードでSwarmコンテナを動かす

各ノードにSSHでログインして、Swarmコンテナを起動させる。

swarm-node0, swarm-local

# Swarm Manager
docker run -d --name=swarm-agent-master \
  -v=/etc/docker:/etc/docker --net=host --restart=always \
  swarm manage -H=0.0.0.0:3375 --replication \
    --strategy=spread --advertise=192.168.30.2:3375 consul://localhost:8500

# Swarm Agent
docker run -d --name=swarm-agent --net=host --restart=always \
  swarm join --advertise=192.168.30.2:2375 consul://localhost:8500

Swarm Managerについては、双方レプリケーションするために--replication引数をつける。

swarm-node1

# Swarm Agent
docker run -d --name=swarm-agent --net=host --restart=always \
  swarm join --advertise=192.168.30.x:2375 consul://localhost:8500

192.168.30.xのところには、swarm-node1がVPNのDHCPに割り当てられたのIPを入れる。

swarm-local

# Swarm Manager
docker run -d --name=swarm-agent-master \
  -v=/etc/docker:/etc/docker --net=host --restart=always \
  swarm manage -H=0.0.0.0:3375 --replication \
    --strategy=spread --advertise=192.168.30.y:3375 consul://localhost:8500

# Swarm Agent
docker run -d --name=swarm-agent --net=host --restart=always \
  swarm join --advertise=192.168.30.y:2375 consul://localhost:8500

192.168.30.yのところには、swarm-localがVPNのDHCPに割り当てられたIPを入れる。

動作確認

ローカルPCのOS設定にて、VPN接続を行う

Macであれば、SoftEther VPNのドキュメントを参考にして、設定を行う。入力値に関しては、この記事の通りにやった場合は以下のようになる。

サーバーアドレス: (swarm-node0のグローバルIP)
ユーザーID: user
パスワード: something
共有シークレット： sharedkey

ローカルPCから、Swarmマスターに接続してみる

ターミナルなどから以下のコマンドを入力して、Swarmクラスタの接続状況を確認してみる。

$ docker -H=192.168.30.2:3375 info

Containers: 4
Images: 4
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 3
 swarm-local: 192.168.30.11:2375
  └ Status: Healthy
  └ Containers: 1
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 4.053 GiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.2.0-25-generic, operatingsystem=Ubuntu 15.10, storagedriver=aufs
 swarm-node0: 192.168.30.2:2375
  └ Status: Healthy
  └ Containers: 2
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 513.4 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.2.0-16-generic, operatingsystem=Ubuntu 15.10, storagedriver=aufs
 swarm-node1: 192.168.30.10:2375
  └ Status: Healthy
  └ Containers: 1
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 513.4 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.2.0-16-generic, operatingsystem=Ubuntu 15.10, storagedriver=aufs
CPUs: 3
Total Memory: 5.055 GiB
Name: swarm-node0

ノードが３つ接続されていれば、クラウドとローカルを跨いだSwarmクラスタの構築に成功している状態になる。

ちなみに、-H=192.168.30.2:3375の部分は、環境変数DOCKER_HOSTに192.168.30.2:3375と設定しておけば省略できる。

各ノードにコンテナを置いてみる

オーバーレイネットワークの作成

export DOCKER_HOST="192.168.30.2:3375"
docker network create testnet

Swarmマスターへの接続であれば、デフォルトでドライバがoverlayに設定される。

docker-compose.yml

nginx:
  image: nginx
  net: testnet
  ports:
    - "8080:80"

portsを設定しておけば、コンフリクトを防ぐため、コンテナ配置が自然とバラける。

docker-compose up & scale

docker-compose up -d
docker-compose scale nginx=3

コンテナ配置確認

$ docker ps --format "{{.Names}}"

swarm-node0/****_nginx_3
swarm-node1/****_nginx_2
swarm-local/****_nginx_1

ちゃんとすべてのホストにコンテナが配置できることを確認。http://192.168.30.x:8080/各々をブラウザで打ちこめば、nginxのデフォルトページが表示されるはず。

あとは、コンテナの中にdocker execで入って、/etc/hostsの中を見れば、他のコンテナのIPが書いてあるはずなので、pingを打ってみたりで、オーバーレイネットワークの疎通を確認できる。

ZeppelinはWeb上からSparkの操作をインタラクティブに行えたり、結果をビジュアライズできたりする、ノートブック系Webアプリ ^[return]
TCP/IPベースのVPNで、動かしてみたら割とすんなり動作したので、これを使ってみた。PPTPdも試したが、Ubuntu15.10で上手く動作しなかったので、見送り ^[return]

TLS認証なDocker Swarmクラスタを構築 (docker-machineなしで)

Mon, 18 Jan 2016 20:00:00 +0900

TSL認証なSwarmクラスタはdocker-machineで構築すると、勝手に設定してくれて非常に楽だが、ホストのネットワークを事前に弄りたかったり、Terraformなどの他オーケストレーションツールを組み合わせたいときに、ちょっと融通がきかない。

なので、TSL認証を用いたDocker Swarmクラスタを自力で構築できるように、手順をまとめておきたい。また、docker-machineの代替としてTerraformを使い、自動化できるようにしたい。

作業の流れ

概ね以下の様な流れでSwarmクラスタの構築を行う。基本的には、docker-machineで行われていることを模倣している。docker-machine自体ではサービスディスカバリの準備は行わないので、そこら辺の手順も残しておく。

[付録] SwarmクラスタをTerraformで構築するサンプル

今回の記事で行う作業をTerraformで自動化したものを、以下のリポジトリに置いておくので、ご参考までに。terraform.tfのcountの値を弄ることで、指定数のノードを自動で作成するので、大量にノードが必要な場合に便利かも。

Build docker swarm cluster over TLS using Terraform https://github.com/namikingsoft/sample-terraform-docker-swarm-over-tls

事前準備

必要なソフトウェアのインストール

作業で使うPC(またはホスト)に以下のDocker関連のソフトウェアをインストールしておく。

docker (Engine)
OpenSSL (Linux系やOSXなら、デフォルトで入っているはず)

DigitalOceanの登録とアクセストークンの取得

この記事の例では、ホストにDigitalOceanを使うが、AWSとかでも可能と思います。

https://www.digitalocean.com/
登録後、管理画面からdocker-machineとの連携に必要なアクセストークンを発行できる。

ノード用のホストを用意する

今回の例では、DigitalOceanでノードを２台用意して、Swarmクラスタの連携を確認した。

Host	OS	Mem	IP (eth0)	IP (eth1)
swarm-node0	ubuntu-15-10-x64	512MB	x.x.x.1	y.y.y.1
swarm-node1	ubuntu-15-10-x64	512MB	x.x.x.2	y.y.y.2

備考

swarm-node0はマスターノードとして使う
ホスト名(hostname)は別になんでもよい
プライベートネットワークを有効にしておく
eth0はグローバルネットワークに繋がるインタフェース
eth1はプライベートネットワークに繋がるインタフェース

各ノードでConsulを動かす

Swarmクラスタのサービスディスカバリー(分散KVS)であるConsulを各ノードにインストールする。使わないでもSwarmクラスタは構築できるが、マルチホスト間でオーバーレイ・ネットワークを作れるようになったりと色々利点が多いので。(etcdやZookeeperでも構築可能)

swarm-node0にてConsulをサーバーモードで動かす

SSHでログインして作業を行う。

インストール

# 必要なパッケージのインストール
apt-get install -y curl zip

# Consulインストール
cd /tmp
curl -LO https://releases.hashicorp.com/consul/0.6.1/consul_0.6.1_linux_amd64.zip
unzip consul_0.6.1_linux_amd64.zip
mv consul /usr/local/bin

# ConsulのWebUIを設置(任意)
curl -LO https://releases.hashicorp.com/consul/0.6.1/consul_0.6.1_web_ui.zip
unzip consul_0.6.1_web_ui.zip -d consul-webui

サービス登録

# service
cat << EOS > /lib/systemd/system/consul.service
[Unit]
Description=consul agent
After=network-online.target

[Service]
ExecStart=/usr/local/bin/consul agent -config-dir=/etc/consul.d
Type=simple
Restart=always

[Install]
WantedBy=multi-user.target
EOS

設定

# 自分自身のプライベートIPを取得
export MY_PRIVATE_IP=$(
  ip addr show eth1 \
  | grep -o -e '[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+' \
  | head -n1
)

# 設定ファイルに書き出す
cat << EOS > /etc/consul.d/config.json
{
  "server": true,
  "bootstrap": true,
  "bind_addr": "$MY_PRIVATE_IP",
  "node_name": "consul0",
  "datacenter": "dc0",
  "ui_dir": "/var/local/consul/webui",
  "data_dir": "/var/local/consul/data",
  "log_level": "INFO",
  "enable_syslog": true
}
EOS

１台構成のサーバーモードをWebUI付き(任意)で起動する。プライベートネットワークであるeth1のIPにバインドする。

自動起動設定＆起動

systemctl enable consul
systemctl start consul

swarm-node1にてConsulをクライアントモードで動かす

SSHでログインして作業を行う。設定以外は同じなので割愛。

設定

# 自分自身のプライベートIPを取得
export MY_PRIVATE_IP=$(
  ip addr show eth1 \
  | grep -o -e '[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+' \
  | head -n1
)

# 設定ファイルに書き出す
cat << eos > /etc/consul.d/config.json
{
  "server": false,
  "start_join": ["y.y.y.1"],
  "bind_addr": "$MY_PRIVATE_IP",
  "datacenter": "dc0",
  "ui_dir": "/var/local/consul/webui",
  "data_dir": "/var/local/consul/data",
  "log_level": "INFO",
  "enable_syslog": true
}
EOS

swarm-node0のプライベートIPにジョインする。
設定が終わったら、自動起動設定と起動を行っておく。

メンバー確認

各ノードのConsulが連携できているかを確認する。

$ consul members

Node     Address            Status  Type    Build  Protocol  DC
consul0  y.y.y.1:8301   alive   server  0.6.1  2         dc1
consul1  y.y.y.2:8301   alive   client  0.6.1  2         dc1

WebUIで確認する場合、ローカルPCと各ノードの間に8500ポートのSSHトンネルを開ければ、ブラウザで閲覧できる。

ssh root@x.x.x.1 -L8500:localhost:8500

open http://localhost:8500

各ノードにDockerをインストール

各ノードのSSHにて、以下のコマンドを実行する。

wget -qO- https://get.docker.com/ | sh

デーモン起動時の引数設定などは後ほど行う。

TLS認証用の鍵を生成する

クライアント側(ローカルPC)で生成する。後ほど各ノードに必要なファイルを転送する。

CAの証明書を生成

openssl genrsa -out ca-key.pem 4096
openssl req -subj "/CN=ca" -new -x509 -days 365 -key ca-key.pem -out ca.pem

CommonName(CN)は任意。

クライアントの秘密鍵と証明書を生成

# extfile
echo "extendedKeyUsage = clientAuth" >> extfile-client.cnf

# client cert
openssl genrsa -out key.pem 4096
openssl req -subj '/CN=client' -new -key key.pem -out client.csr
openssl x509 -req -days 365 -sha256 -in client.csr -out cert.pem \
  -CA ca.pem -CAkey ca-key.pem -CAcreateserial -extfile extfile-client.cnf

CommonName(CN)は任意。

swarm-node0(master)の秘密鍵と証明書を生成

# extfile
echo "subjectAltName = IP:x.x.x.1" > extfile.cnf
echo "extendedKeyUsage = clientAuth,serverAuth" >> extfile.cnf

# server cert
openssl genrsa -out node0-key.pem 4096
openssl req -subj "/CN=node0" -new -key node0-key.pem -out node0.csr
openssl x509 -req -days 365 -sha256 -in node0.csr -out node0-cert.pem \
  -CA ca.pem -CAkey ca-key.pem -CAcreateserial -extfile extfile.cnf

Swarm Managerを動かすノードなので、clientAuthも設定しておく。subjectAltNameにグローバルIPを設定するので、CommonName(CN)は割と何でもよいが、ドメイン名があれば、それを設定するとよい。

swarm-node1の秘密鍵と証明書を生成

# extfile
echo "subjectAltName = IP:x.x.x.2" > extfile.cnf

# server cert
openssl genrsa -out node1-key.pem 4096
openssl req -subj "/CN=node1" -new -key node1-key.pem -out node1.csr
openssl x509 -req -days 365 -sha256 -in node1.csr -out node1-cert.pem \
  -CA ca.pem -CAkey ca-key.pem -CAcreateserial -extfile extfile.cnf

CommonName(CN)は任意。

TLS認証鍵を各ノードへアップロード

SFTPやSCPなどを使って、各ノードの/etc/docker¹あたりにアップロードする。

swarm-node0
- ca.pem
- node0-cert.pem
- node0-key.pem
swarm-node1
- ca.pem
- node1-cert.pem
- node1-key.pem

各ノードのDockerの設定を変更する

各ノードにSSHでログインして、設定を行う。

Dockerデーモン起動時の引数設定

swarm-node0

vi /lib/systemd/system/docker.service

# 変更前
ExecStart=/usr/bin/docker daemon -H fd://
# 変更後
ExecStart=/usr/bin/docker daemon \
  --tlsverify \
  --tlscacert=/etc/docker/ca.pem \
  --tlscert=/etc/docker/node0-cert.pem \
  --tlskey=/etc/docker/node0-key.pem \
  -H=0.0.0.0:2376 \
  --cluster-store=consul://localhost:8500 \
  --cluster-advertise=eth0:2376 \
  -H fd://

swarm-node1

vi /lib/systemd/system/docker.service

# 変更前
ExecStart=/usr/bin/docker daemon -H fd://
# 変更後
ExecStart=/usr/bin/docker daemon \
  --tlsverify \
  --tlscacert=/etc/docker/ca.pem \
  --tlscert=/etc/docker/node1-cert.pem \
  --tlskey=/etc/docker/node1-key.pem \
  -H=0.0.0.0:2376 \
  --cluster-store=consul://localhost:8500 \
  --cluster-advertise=eth0:2376 \
  -H fd://

備考

変更後は見やすさのため複数行で書いているが、\を消して1行ぶっ続けで記述する。
この設定はUbuntu15.10の場合なので、他のOSの場合は/etc/default/dockerのDOCKER_OPTSに引数を付け加えたりなど、やり方が違ってくると思うので、各々調節する。
cluster-storeとcluster-advertiseの指定は、オーバーレイ・ネットワーク機能のためなので、使わない場合は特に指定しなくても、Swarmクラスタの動作は可能。

Docker再起動

service docker restart

TLS接続確認

ローカルPCから、TLS(TCP)でホストのDockerを利用できるか確認してみる。

# swarm-node0
docker --tlsverify \
  --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem \
  -H=x.x.x.1:2376 \
  version

# swarm-node1
docker --tlsverify \
  --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem \
  -H=x.x.x.2:2376 \
  version

ClientとServerのDockerバージョンが表示されれば、正しく設定できている。

また、以下の様な環境変数を設定することで、いちいちTLS認証鍵やIP指定をしなくても、普通にdockerコマンドが扱えるようになる。

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://(dockerホストのIP):2376"
export DOCKER_CERT_PATH="/path/to/クライアント認証鍵があるディレクトリ"

docker version

DOCKER_CERT_PATHについては、~/.docker/にクライアント認証鍵(ca.pem, cert.pem, key.pem)を設置すれば、省略可能。

各ノードでSwarmコンテナを動かす

各ノードにSSHでログインして、Swarmコンテナを起動させる。

swarm-node0

# Swarm Manager
docker run -d --name=swarm-agent-master \
  -v /etc/docker:/etc/docker --net=host --restart=always \
  swarm manage --tlsverify \
    --tlscacert=/etc/docker/ca.pem \
    --tlscert=/etc/docker/node0-cert.pem \
    --tlskey=/etc/docker/node0-key.pem \
    -H=tcp://0.0.0.0:3376 --strategy=spread \
    --advertise=x.x.x.1:2376 consul://localhost:8500

# Swarm Agent
docker run -d --name=swarm-agent --net=host --restart=always \
  swarm join --advertise=x.x.x.1:2376 consul://localhost:8500

swarm-node1

# Swarm Agent
docker run -d --name swarm-agent --net=host --restart=always \
  swarm join --advertise=x.x.x.2:2376 consul://localhost:8500

備考

ネットワークのホストと共有する必要があるので、--net=hostを指定している。
Swarm Managerで/etc/dockerを共有Volume指定しているのは、TLS認証鍵の共有だけではなく、/etc/docker/key.jsonの共有のため。DockerユニークIDの識別に必要とのこと。

動作確認

クライアント側(ローカルPC)から、Swarmクラスタへの接続を試みる。

Swarm MasterにTLS接続

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://x.x.x.1:3376"
export DOCKER_CERT_PATH="/path/to/クライアント認証鍵があるディレクトリ"

$ docker info

Containers: 3
Images: 2
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 2
 swarm-node0: x.x.x.1:2376
  └ Status: Healthy
  └ Containers: 2
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 513.4 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.2.0-16-generic, operatingsystem=Ubuntu 15.10, storagedriver=aufs
 swarm-node1: x.x.x.2:2376
  └ Status: Healthy
  └ Containers: 1
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 513.4 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.2.0-16-generic, operatingsystem=Ubuntu 15.10, storagedriver=aufs
CPUs: 2
Total Memory: 1.003 GiB
Name: swarm-node0

上のように、ノードが2つ接続されていることが確認できれば、Swarmクラスタの構築がうまく行えている。DOCKER_HOSTのポート指定を2376ではなく、3376にすることで、dockerコマンドでSwarm関連の操作を行うことができる。

Swarmクラスタにコンテナを配置してみる

$ docker run -d --name container1 nginx
$ docker run -d --name container2 nginx
$ docker ps --format "{{.Names}}"

swarm-node1/container1
swarm-node2/container2

Swarm Masterのストラテジーがspreadなので、各ノードにコンテナが分散配置される。

TLS認証鍵の置き場所は任意。Dockerデーモン起動時の引数で指定する。 ^[return]

Docker SwarmでApache Sparkクラスタを構築してみる

Tue, 12 Jan 2016 23:30:23 +0900

前回の記事でSwarmクラスタを構築したので、Apache Sparkのクラスタを載せてみる。

本来ならオンプレでクラスタを組んだり、AmazonのEMRを使うのが一般的かもだが、安めのクラウドでもできないかなーという試み。

まずはシンプルに、Standaloneモードから動かしてみたい。

事前準備

マルチホスト同士の通信が可能なSwarmクラスタを構築しておく

Sparkのクラスタ同士は、一方通行な通信ではなく、割りと親密な双方向通信をするため、オーバーレイ・ネットワーク上に構築しないとうまく動作しない。

オーバーレイ・ネットワーク構築するには、Consul, etcd, Zookeeperのようなキーストアを自身で導入する必要があるので、 DigitalOceanでマルチホストなDockerSwarmクラスタを構築を参考に、以下の様なSwarmクラスタを構築しておいた。

Sparkクラスタをコンテナで構築する

docker-composeを用いて、各ノードにSparkクラスタを構築する。

Apache SparkのDockerイメージ

Standaloneモードで動くシンプルなものが使いたかったので、SparkのDockerイメージは自前で用意したものを使った。

namikingsoft/docker-spark
https://github.com/namikingsoft/docker-spark

masterならbin/start-master.shを実行し、workerならbin/start-slave.sh ${MASTER_HOSTNAME}:7077を実行するだけのシンプルなもの。

docker-compose.yml

master:
  image: namikingsoft/spark
  hostname: master
  container_name: master
  environment:
    - constraint:node==/node0/
  privileged: true
  command: master

worker:
  image: namikingsoft/spark
  environment:
    - MASTER_HOSTNAME=master
    - constraint:node!=/node0/
    - affinity:container!=/worker/
  privileged: true
  command: worker

environmentからのconstraintやaffinityの指定によってコンテナの配置をコントロールできる。コンテナの数をスケールするときもこのルールに沿って配置される。
>> 指定方法の詳細

イメージ各コンテナはDockerのオーバーレイネットワークで繋がるので、ポートも特に指定しなくてもよい。WebUIなどは後ほど、Socksプロキシ経由で確認する。

Swarm Masterの環境変数を設定

eval "$(docker-machine env --swarm swarm-node0)"

docker-compose up

docker-compose --x-networking up -d

--x-networkingを引数で指定すれば、各コンテナがDockerのオーバーレイ・ネットワークで繋がる。--x-network-driver overlayを省略しているが、デフォルトで指定されるみたい。

docker-compose up直後の状態では、ワーカーコンテナが１つしか立ち上がらないので、以下の様な感じになっている。

ワーカーをスケールしてみる

docker-composeのscaleコマンドでワーカーノードを指定数分スケールすることができる。

docker-compose scale worker=2

コンテナ配置の確認

docker ps --format "{{.Names}}"

swarm-node0/master
swarm-node1/dockerspark_worker_1
swarm-node2/dockerspark_worker_2

各ノードにコンテナが配置されたのがわかる。

ちなみに、MasterとWorkerを一緒のノードで動かしたら
spark-shell起動時にCannot allocate memory的なエラーを吐いた。チューニング次第かもだが、DigitalOcean 2GBだとリソース的には厳しそう。

Sparkシェルを動かしてみる

仮にSparkマスターコンテナをドライバーとして、動かしてみる。 (ワーカーでも動作可能)

docker-exec -it master bash
spark-shell --master spark://master:7077

scala> sc.parallelize(1 to 10000).fold(0)(_+_)
res0: Int = 50005000

Spark UIを確認

SparkのWebUIから、ワーカーが接続されているか確認したいが、docker-compose.ymlではポートを開けていない。(本来閉じたネットワークで動かすので、ポートを開放するのはあまりよろしくない)

なので、新たにSSHdコンテナを設置して、Socksプロキシ経由でWebUIを確認する。

SSHdコンテナを追加

先ほどのdocker-compose.ymlに追加する。

master:
  image: namikingsoft/spark
  hostname: master
  container_name: master
  environment:
    - constraint:node==/node0/
  privileged: true
  command: master

worker:
  image: namikingsoft/spark
  hostname: woker
  environment:
    - constraint:node!=/node0/
    - affinity:container!=/worker/
  privileged: true
  command: worker

# SSHdコンテナを追加
sshd:
  image: fedora/ssh
  ports:
    - "2222:22"
  environment:
    SSH_USERNAME: user
    SSH_USERPASS: something

以下のコマンドで、SSHdコンテナが起動する。

docker-compose --x-networking up -d

ローカルPCでSocksプロキシを起動

swarm-masterのIPを確認。

docker-machine ls

Socksプロキシの起動。

ssh user@(swarm-masterのIP) -p2222 -D1080 -fN
Password: something

Socksプロキシを止めるときはCtrl-cを押下。

ローカルPCにてSocksプロキシを設定

ローカルPCのSocksプロキシ設定をlocalhost:1080に設定する。 SSHのSocks周りについては以下のページが参考になった。

ssh経由のSOCKSプロキシを通じてMac上のGoogle Chromeでブラウジング
 ssh -D と tsocks - 京大マイコンクラブ (KMC)

ブラウザで確認

open http://(swarm-masterのIP):8080

先ほど、スケールした2つのワーカーコンテナがマスターに接続されているのがわかる。 IPや名前解決はSSH接続先のものを参照してくれて便利。(OSX10.9+Chromeで確認)

DigitalOceanでマルチホストなDockerSwarmクラスタを構築するときのポイント

Sun, 10 Jan 2016 18:00:23 +0900

Docker公式のGet started with multi-host networkingを参考に、DigitalOceanでSwarmクラスタを構築してみたが、いくつか工夫が必要なポイントがあったので、まとめておく。

事前準備

必要なソフトウェアのインストール

作業で使うPC(またはホスト)に以下のDocker関連のソフトウェアをインストールしておく。Dockerのオーバーレイネットワーク機能を使うので、それを利用できるバージョンを入れる。

docker (1.9以上)
docker-compose (1.5以上)
docker-machine

DigitalOceanの登録とアクセストークンの取得

登録後、管理画面からdocker-machineとの連携に必要なアクセストークンを発行できる。

https://www.digitalocean.com/

気をつけたいポイント４つ

01. ホストOSはKernel3.16以上のものを使う

例えば、ホストOSにUbuntu14.04を選んでいると、オーバーレイ・ネットワーク上にのコンテナを立ち上げる時にエラーが出る。

$ docker-compose up -d -x-networking

Creating network "xxx" with driver "overlay"
Creating yyy
ERROR: Cannot start container (container_id):
  subnet sandbox join failed for "10.0.0.0/24":
  vxlan interface creation failed for
  subnet "10.0.0.0/24": failed in prefunc:
  failed to set namespace on link "vxlanf9ac2ad": invalid argument

Get started with multi-host networkingによると、「A host with a 3.16 kernel version or higher.」とのこと。DigitalOceanのUbuntu14.04はカーネルが古いようなので、14.10とか15.04以上を使う必要がある。

02. cluster-advertiseはeth0にするか、PrivateNetworkを有効にする

Get started with multi-host networkingのサンプルをそのまま使うと、docker-machine create時に概ね次のようなエラーに遭遇する。

$ docker-machine create \
  ...
  --engine-opt "cluster-advertise=eth1:2376" \
  ...

Error creating machine: Error running provisioning:
Unable to verify the Docker daemon is listening: Maximum number of retries (10) exceeded

現状、DigitalOceanのeth1はプライベートネットワークのインタフェースで、デフォルト設定では、プライベートネットワークにIPが割り当てられない。

なので、公開ネットワークのeth0を使うか、docker-machine create時に、全てのノードに--digitalocean-private-networkingをつけて、プライベートネットワークを有効にする。

docker-machine create
  ...
  --engine-opt "cluster-advertise=eth0:2376" \
  ...

docker-machine create
  ...
  --engine-opt "cluster-advertise=eth1:2376" \
  --digitalocean-private-networking \
  ...

03. ConsulはSwarmクラスタ上に置いて節約する

公式ドキュメントのサンプルでは、Consulキーストアで専用のホストを用意しているが、安いとはいえ、DigitalOceanでConsulキーストア専用にもつのは守銭奴らしからぬので、Swarmクラスタのノードに含めてしまおう。

Swarmクラスタのノードを作成するときに、ConsulのURLを指定する場所があるが、作成時にはConsulキーストアが存在しなくても、Swarmが後々定期的にキーストアを更新してくれるようなので、割りと気にせずにノード構築後にConsulを導入できる。

ただ、サンプルのように、ConsulをDockerコンテナで導入してしまうと、docker ps時に、いつもリストに出てきてしまうので、気になる方はDocker上ではなく、ホストに直接インストールしてしまったほうが良い。(バイナリファイル１つだし)

あと、Consulらしく全ノードに設置して、ヘルスチェックなどが出来ると良さそう。

04. Consulはプライベートネットワークに置く

公式ドキュメントの感覚で、DigitalOceanにConsulキーストアを導入すると、グローバルにWebUIが公開されてしまい、精神的によろしくない。

DigitalOceanには、一応プライベートネットワーク機能が用意されていて、管理画面やdocker-machineの引数から有効にできる。Consulはプライベートネットワーク側(eth1)のIPをバインドするとよい。

プライベートネットワークにConsulを置くと、WebUIなどはグローバルIPから確認できなくなる。ブラウザからWebUIを確認したくなった場合は、SSHトンネルを利用して、8500ポートをフォワーディングしてやると楽。

ssh root@(マシンIP) \
  -i ~/.docker/machine/machines/(マシンID)/id_rsa \
  -L8500:localhost:8500

# ブラウザから開く
open http://localhost:8500

注意
プライベートネットワークといっても、リージョンごとのネットワークのようなので、あまり過信しないほうがよいみたい。

使う前に知りたかったDigitalOceanまとめ http://pocketstudio.jp/log3/2015/04/13/digitalocean_introduction/

具体的な実行手順

自動化しやすいように、上のポイント４つを踏まえたシェルの実行手順を以下にまとめる。

# マスターノード作成
docker-machine create \
  --driver digitalocean \
  --digitalocean-access-token ${DIGITALOCEAN_TOKEN} \
  --digitalocean-image "ubuntu-15-10-x64" \
  --digitalocean-region "sgp1" \
  --digitalocean-size "512mb" \
  --digitalocean-private-networking \
  --swarm --swarm-master \
  --swarm-discovery \
    "consul://localhost:8500" \
  --engine-opt \
    "cluster-store=consul://localhost:8500" \
  --engine-opt "cluster-advertise=eth1:2376" \
  swarm-node0

# マスターノードにConsulを設置
docker-machine ssh swarm-node0 "
  apt-get install -y at zip &&\
  cd /tmp &&\
  curl -LO https://releases.hashicorp.com/consul/0.6.1/consul_0.6.1_linux_amd64.zip &&\
  unzip consul_0.6.1_linux_amd64.zip &&\
  mv consul /usr/local/bin &&\
  curl -LO https://releases.hashicorp.com/consul/0.6.1/consul_0.6.1_web_ui.zip &&\
  unzip consul_0.6.1_web_ui.zip -d consul-webui &&\
  echo \"
    consul agent \
      -server -bootstrap-expect=1 \
      -node=consul00 \
      -data-dir=/tmp/consul \
      --ui-dir=/tmp/consul-webui \
      -bind=\$(
        ip addr show eth1 \
        | grep -o -e '[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+' \
        | head -n1
      ) \
    >> /var/log/consul.log
  \" | at now
"

# マスターのプライベートIPを取得
MASTER_PRIVATE_IP=$(
  docker-machine ssh swarm-node0 "
    ip addr show eth1 \
    | grep -o -e '[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+' \
    | head -n1
  "
)

# ノード作成
docker-machine create \
  --driver digitalocean \
  --digitalocean-access-token ${DIGITALOCEAN_TOKEN} \
  --digitalocean-image "ubuntu-15-10-x64" \
  --digitalocean-region "sgp1" \
  --digitalocean-size "512mb" \
  --digitalocean-private-networking \
  --swarm \
  --swarm-discovery \
    "consul://localhost:8500" \
  --engine-opt \
    "cluster-store=consul://localhost:8500" \
  --engine-opt "cluster-advertise=eth1:2376" \
  swarm-node1

# ノードにConsulを設置
docker-machine ssh swarm-node1 "
  apt-get install -y at zip &&\
  cd /tmp &&\
  curl -LO https://releases.hashicorp.com/consul/0.6.1/consul_0.6.1_linux_amd64.zip &&\
  unzip consul_0.6.1_linux_amd64.zip &&\
  mv consul /usr/local/bin &&\
  echo \"
    consul agent \
      -join=$MASTER_PRIVATE_IP \
      -node=consul01 \
      -data-dir=/tmp/consul \
      -bind=\$(
        ip addr show eth1 \
        | grep -o -e '[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+' \
        | head -n1
      ) \
    >> /var/log/consul.log
  \" | at now
"

注記いくつか

シェル中の${DIGITALOCEAN_TOKEN}はDigitalOceanの管理画面から取得したアクセストークンに置き換える。
Consul起動にat nowコマンドを使っているのは、nohupや&を使っても、Consulがフォアグラウンドで走ってしまい、バッチ処理が途中で止まってしまうため。docker-machine sshの仕様の問題？
Consul実行時にbindに指定しているのは、自身のプライベートIP。
途中で、マスターのプライベートIPを取得しているのは、各ノードに設置したConsulクライアントをサーバーにJOINさせるため。

動作確認

Swarmクラスタ確認

$ eval $(docker-machine env --swarm swarm-node0)
$ docker info

Containers: 3
Images: 2
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 2
 swarm-node0: x.x.x.x:2376
  └ Status: Healthy
  └ Containers: 2
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 513.4 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.2.0-16-generic, operatingsystem=Ubuntu 15.10, provider=digitalocean, storagedriver=aufs
 swarm-node1: y.y.y.y:2376
  └ Status: Healthy
  └ Containers: 1
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 513.4 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.2.0-16-generic, operatingsystem=Ubuntu 15.10, provider=digitalocean, storagedriver=aufs
CPUs: 2
Total Memory: 1.003 GiB
Name: swarm-node0

ノードが２つあることが確認できる。

オーバーレイ・ネットワークの確認

docker-compose.yml

container1:
  image: busybox
  container_name: container1
  environment:
    - constraint:node==/node0/
  command: tail -f /dev/null

container2:
  image: busybox
  container_name: container2
  environment:
    - constraint:node==/node1/
  command: tail -f /dev/null

ネットワークモードでコンテナを立ち上げる

$ docker-compose --x-networking up -d
$ docker ps --format "{{.Names}}"

swarm-node0/container1
swarm-node1/container2

それぞれのノードにコンテナが作られた。

疎通確認

$ docker exec -it container1 ping container2 -c4

PING container2 (10.0.0.3): 56 data bytes
64 bytes from 10.0.0.3: seq=0 ttl=64 time=1.470 ms
64 bytes from 10.0.0.3: seq=1 ttl=64 time=0.691 ms
64 bytes from 10.0.0.3: seq=2 ttl=64 time=0.620 ms
64 bytes from 10.0.0.3: seq=3 ttl=64 time=0.699 ms

--- container2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.620/0.870/1.470 ms

$ docker exec -it container2 ping container1 -c4

PING container1 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: seq=0 ttl=64 time=1.379 ms
64 bytes from 10.0.0.2: seq=1 ttl=64 time=0.854 ms
64 bytes from 10.0.0.2: seq=2 ttl=64 time=0.847 ms
64 bytes from 10.0.0.2: seq=3 ttl=64 time=0.861 ms

--- container1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.847/0.985/1.379 ms

オーバーレイ・ネットワークの疎通も問題なさそう。

Dockerイメージのビルド中にExitedしたコンテナに入る方法

Tue, 29 Sep 2015 08:00:00 +0900

長めのansible-playbookをRUNしてる途中でエラーが出た時に役立ったので、まとめておく。

どういう時に使う？

例えば、docker build途中によくわからない理由でエラー落ちした時、直前状態のコンテナに入ってデバッグしたい事がある。

ビルドに失敗した後、docker ps -aすると、 Exitedしたビルド作業用のコンテナが消されずに残っているので、このコンテナの中にシェルで入れれば、エラーの詳細を調べられる。

コンテナだけでなく、直近のイメージも残っているが、 Dockerコマンド単位でコミットされるため、数珠つなぎのRUNとか、ansibleやchefなどのプロビジョニングツールを併用した時に、大幅にロールバックしていることがある。

ビルド途中にエラーで落ちるDockerfileの例

FROM busybox

RUN touch /step1
RUN touch /step2 && errcmd && touch /step3
RUN touch /step4

errcmdという架空のコマンドで、わざとエラーを起こしてみる。

docker build の途中で落ちる

$ docker build . -t tset

Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM busybox
latest: Pulling from library/busybox
cfa753dfea5e: Pull complete
d7057cb02084: Pull complete
library/busybox:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:16a2a52884c2a9481ed267c2d46483eac7693b813a63132368ab098a71303f8a
Status: Downloaded newer image for busybox:latest
 ---> d7057cb02084
Step 1 : RUN touch /step1
 ---> Running in f1ca76c9072d
 ---> ef649ff08895
Removing intermediate container f1ca76c9072d
Step 2 : RUN touch /step2 && errcmd && touch /step3
 ---> Running in d117aa39bacd
/bin/sh: errcmd: not found
The command '/bin/sh -c touch /step2 && errcmd && touch /step3' returned a non-zero code: 127

途中にある---> Running in d117aa39bacdの次で止まっている。

$ docker ps -q --filter status=exited

d117aa39bacd

d117aa39bacdコンテナが消されずに残っている。
これが直近の作業コンテナでtouch /step2までのコマンドを実行されているはず。

Exitedなコンテナには入れない？

生きているコンテナであれば、docker exec+シェルでコンテナの中に入れるが、 Exitedしていると、以下の様なエラーが出る。

$ docker exec -it d117aa39bacd sh

Error response from daemon: Container d117aa39bacd is not running

解決手順

１．Exitedコンテナを一旦コミットして、イメージ化する

死んでいるコンテナをコミットするという機会があまりなかったので、ちょっと戸惑ったが、以下のコマンドでイメージ化できる。

$ docker commit -t exited d117aa39bacd

２．インタラクティブ+TTYモードで実行する

そのままdocker runしても速攻で死ぬので、-it bashをつけて実行。

$ docker run --rm -it exited sh

# ls / | grep step
step1
step2

ちょっとまどろっこいが、一応エラーコマンド直前の状態のコンテナに入れた。同じRUNコマンドの中でエラーが起きても、touch /step2までは実行されているようだ。

webpack-dev-serverで継続的なクライアントサイドテスト

Fri, 11 Sep 2015 08:30:23 +0900

webpackのTestingを眺めてたら、ブラウザ上でアプリを動作させながらMochaのSpecを走らせて、クライアントサイドのテストをする、みたいなことが手軽に出来そうだったので、やってみた。

webpack-dev-serverを利用すれば、ソースやテストを修正直後に自動リロードされるので、継続的テストみたいな手法もとりやすい。

動作サンプル

ひと通り動くサンプルを作ったので、以下のGitHubに上げておきます。 nodeやnpmがインストールされていれば、動作すると思われます。

“Greetingボタンを押したら、その下に挨拶が追加される”
みたいな動作のサンプルアプリとそのSpecをjQueryでシンプルに組んであります。

GitHub: sample-webpack-test
https://github.com/namikingsoft/sample-webpack-test

試しにブラウザで動かしてみる

GitHub上の動作サンプルをcloneして、 webpack-dev-serverを起動したら、お使いのブラウザから以下のURLにアクセスすることで動作を確認できる。

http://localhost:8080/webpack-dev-server/

コマンド例

git clone https://github.com/namikingsoft/sample-webpack-test
cd sample-webpack-test
npm install && npm start
open http://localhost:8080/webpack-dev-server/

動作画面の例

フロントエンドアプリとMochaのSpecを同時に動かしている図。 Seleniumみたいにギュンギュン動いて楽しい。 Mochaのテスト中にに割り込んでワザとテストを失敗させたりできる。

Specは走らなくていいから、アプリの動作確認だけしたいときは以下のURL¹で可能。 http://localhost:8081/webpack-dev-server/app

ざっくり解説

ファイル構成

sample-webpack-test
|-- build
|   |-- app.js # webpackが吐き出したアプリ本体のバンドルJS
|   |-- index.html # アプリとSpecを動作させるHTML
|   `-- spec.js # webpackが吐き出したSpecのバンドルJS
|-- spec # このディレクトリ以下に置いた*Spec.jsが実行される
|   `-- mainSpec.js
|-- src
|   `-- main.js # アプリ本体のソース
`-- webpack.config.js # webpackの設定ファイル

buildディレクトリ内のapp.jsとspec.jsは、 webpack-dev-server内の動作であれば、メモリ内のものが呼び出されるようなので、特に設置する必要はなさそう。

複数のSpecファイルに対応する

npmのglobモジュールを利用して、複数のSpecファイルをエントリーポイントに含めることができる。また、requireでglobを書きたい場合は、glob-loaderを使えば、同じようなことができる。

// webpack.config.jsのmodule.exports内

entry: {
  app: "./src/main.js",
  spec: glob.sync("./spec/**/*Spec.js"),
}

修正後に自動的にテストが走るようにする

webpack-dev-serverには、ファイル修正を検知して再読み込みをしてくれる、 hotモードという機能が付いているので、webpack.config.jsでそれをを有効にする。

// webpack.config.jsのmodule.exports内

devServer: {
  // Document Root
  contentBase: "./build",
  // 動作ポート指定
  port: 8080,
  // hotモード有効化
  hot: true,
  // これがないと、ブラウザで
  inline: true,
},
plugins: [
  // hotモードに必要なプラグイン
  new webpack.HotModuleReplacementPlugin(),
],

Specファイルをブラウザで動作するように変換する

webpackのTestingのページにもあるが、 mocha-loaderを噛ますことで、ブラウザでMochaが利用可能になるJSが吐き出せるようになる。

SpecファイルをES6で書きたければ、 babel-loaderを挟むと、一般ブラウザ用のJSに変換できる。 CoffeeScript+Chaiとかで書いても気持ちよさそう。

// webpack.config.jsのmodule.exports内

module: {
  loaders: [
    // App用
    {
      test: /\.js$/,
      loaders: ['babel'],
      exclude: /(node_modules|bower_components)/,
    },
    // Spec用
    {
      test: /Spec\.js$/,
      loaders: ['mocha', 'babel'],
      exclude: /(node_modules|bower_components)/,
    },
  ],
},

AppとSpecを同時に走らせるHTMLを用意

アプリの動作画面にSpec結果のレイアウトを入れ込む。
app.jsで必要なUIを書き出すなどの初期処理を行ってから、spec.jsを走らせている。

<!-- build/index.html -->

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="UTF-8">
    <title>App</title>
    <style>
      /* Spec実行結果を表示するレイアウトCSS */
      .layout-spec {
        position: fixed;
        overflow: scroll;
        top: 0; bottom: 0; right: 0;
        width: 45%;
        background-color: #eee;
      }
      .layout-spec pre {
        background-color: #fff;
      }
    </style>
  </head>
  <body>
    <!-- App実行 -->
    <script src="app.js"></script>
    <div class="layout-spec">
      <!-- Spec実行 -->
      <script src="spec.js"></script>
    </div>
  </body>
</html>

あとがき

ChromeとかFirefoxなどの複数のブラウザ上で手軽にフロント動作仕様を自動チェックしたい、みたいなときの方法論の一つとして紹介してみた。

ただ、CLI動作とかCIと連携する場合は、 Kermaのようなテストランナーを使ったほうが良いかも。 webpackはKermaとも簡単に連動できるようなので、その辺も後々まとめておきたい。

URLのappの部分はバンドルJS出力先のパスを指定すれば、webpack-dev-serverが出力用HTMLを自動生成してくれるみたい。(.jsは省略してます) ^[return]

オープンソースのかんばん式管理ツールを３つほど試してみた

Fri, 04 Sep 2015 08:30:23 +0900

コンプライアンス¹を重視する現場で、アジャイルなプロジェクト管理ツールが現場で必要になったときに、外部WebサービスなTrelloやPivotal Trackerを導入しづらいことがある。

そこで、OSSのかんばん式管理ツールをいくつか探して、
色々試して感じたことをまとめておきます。

今回試した ‘かんばん式’ プロジェクト管理ツール

以下に挙げる以外にも、OSSのかんばん式管理ツールは数多く存在するが、機能面・とっつきやすさ・導入の容易さなどに基いて、３つだけピックアップさせていただいた。

TAIGA
https://taiga.io/
Wekan (旧LibreBoard)
http://newui.libreboard.com
Restyaboard
http://restya.com/board/

個別のサーバーに実行環境を構築したい場合

各々デモ用のURLが用意されているが、OSSなので個別のサーバー環境やDockerで試したい場合は、当ブログに構築手順の記事があるので、参照されたい。

TAIGA - 本格的なアジャイル開発管理

本格的なアジャイル開発を支援するプロジェクト管理ツール。他のかんばん管理ツールに比べて、デザイン洗礼されていて、使っていて気持ちいい。

ここが良かった

アジャイル開発管理に特化したテンプレート

全体を見渡せるかんばんボードだけではなく、期間区切りのスプリントを作成して、バックログからストーリーカードを割り振り、各タスクの進捗状況を確認できるタスクボード機能。

プロジェクト全体の遅延動向をより正確に把握するために、ストーリーカード毎に設定するポイント(難度重み付け)²と、ストーリーカードの進捗に基いて描写されるバーンダウンチャート。

感覚的には以前使っていたRedmineのアジャイル拡張のAlminiumに似ている。
(アジャイルの管理ツールって概ねこんな感じなのかな)

ユーザーごとに権限グループ設定をすることができる

スプリントを追加できるのはオーナーのみとか、エンジニア/デザイナーはタスクのみを登録できる。とか、グループによって、事細かに権限を設定することができる。

デフォルトの権限グループとしては、UX,DESIGN,FRONT,BACK,PRODUCT OWNERなどがあるが、こちらも設定で変更できるっぽい。

微妙なところ

軽めに使うには複雑すぎるか

Redmine拡張のAlminiumを使った時も思ったことだが、メンバーがアジャイル開発手法に慣れていない場合、バックログ > スプリント > タスクボードの階層構造に少し戸惑うかもしれない。

一応、設定からアジャイル開発系のモジュールを無効にできたりするが、かんばんボードの列名を別の設定画面で行う必要があったりと、少し面倒くさい。シンプルなTODO表として使うなら、Trello,Wekanとかの方がとっつきやすいかもしれない。

Wekan - お手軽かんばん式プロジェクト管理

ちょっと前は、Libreboardと呼ばれていて、日本語の紹介サイトも豊富に存在した。その頃はボード画面から設定画面から、何から何までTrelloにそっくりだったが、 Wekanに名を変えてから、少しUIにオリジナリティが増したように感じる。

ここが良かった

シンプル・イズ・ベスト

Trelloの基本機能から、更に必要最低限のものに絞ってるので、非常にとっつきやすい。システム開発に限らず、シンプルなTODO管理にも使えそう。ひょっとすると、ITアレルギー持ちの老若男女にも使っていただけるかもしれない。

こういうツールの真髄は、今どんな課題があるか。どういう状況か。誰が着手してるか。を素早く把握することにあるので、コミュニケーションツールとして割り切るならば、十分だとは思う。

日本語UIに対応

上のログイン画面のスクリーンショットのとおり、デフォルトで日本語に対応している。ログイン後の画面も右上メニューのChange Languegeから日本語にできる。英語アレルギー持ちの老若男女にも使っていただけるだろう。

微妙なところ

アジャイル開発管理に使うにはシンプルすぎるか

本格的にアジャイル開発に使うには、複数ボードにまたいだりと、運用テクニックが必要になりそう。あと、TrelloやRestyaboardにあるようなチェックリスト機能がないので、各ストーリーカードの進行状況(タスク状況)をボード上から確認するのは難しい。

Restyaboard - 多機能かんばん式プロジェクト管理

基本的にはTrelloクローンなのだが、シンプル化のWekanと違い、多機能化を目指している。

ここが良かった

他ツールにない前衛的な機能やTrello有料機能が使えたりする

例えば、ボードのオーナー以外がストーリーカードを追加することができないが、ボード一覧による進捗状況確認、カレンダー表示、デスクトップ通知³、ファビコンに新着通知数表示など、他ツールにない前衛的な機能/UIが豊富。

チェックリスト、Due Date、ボードの背景に写真が使える、などを見ると、機能面ではWekanより、こちらのほうがTrelloを意識しているかも。また、Trelloからデータをインポートする機能が付いているので、もし無償版では満足できなくなったら、試してみるのもいいかもしれない。

微妙なところ

ユーザーインタフェースに少し難あり

定期的に再読み込みのロードバーが表示されたり、デスクトップ通知が絶え間なく表示されたり、ストーリーカードの詳細ポップアップがグィングイン動いたり、若干UI効果がうるさいかも。

GitHubを見るに、機能面含めて現在開発中のアルファ版という位置づけと思われるので、今後のバージョンアップに期待したいところ。

あとがき

１年ほど前にOSSのかんばんツールを探してた時は、 RedmineのAlminiumぐらいしか選択肢がなかった気がしたが、ものすごいスピードで新サービスが生まれるWeb系の恐ろしさを感じる。

OSS作者様に感謝すると共に、自分もなにか残してえなあ。と色々弄ってて思った。

いまいちピンとこない用語だが、ここでは情報漏洩を気にする企業という意味。内部サーバーだからバッチグーという事ではなく、いかにお固い上席を説得しやすいか。 ^[return]
フィボナッチ数列っぽいものから重みを選択できる。数列は設定から変更可能。 ^[return]
Trelloにもデスクトップ通知機能は付いているみたい。[参考] ^[return]

docker-composeのインストールとバージョン差異エラー回避方法

Wed, 02 Sep 2015 08:30:23 +0900

docker-composeはDockerコンテナの構成管理ツール。
昔はfigという名前のツールだったが、Dockerと統合して名前を変更したとのこと。

データボリューム, DB, バックエンド、フロントエンドなど、サービスの稼働に複数コンテナが必要な場合のビルドや立ち上げが非常に楽になる。

インストール自体はシンプルだが、 Dockerのバージョンによっては実行時にエラーが出てしまうようなので、エラー回避方法もまとめておく。

Overview of Docker Compose
https://docs.docker.com/compose/

インストール手順

公式ドキュメントに対応OSごとのインストール方法がまとめてあった。

Docker Compose: Supported installation
https://docs.docker.com/installation/

OS共通の方法で一番簡単なのが、pipでインストールする方法。

pip install -U docker-compose

pipがない場合は、easy_installでインストールできる。

easy_install pip

バージョン差異エラー回避方法

docker-compose upなどの実行時に、以下の様なエラーが表示されることがある。

client and server don't have same version (client : 1.19, server: 1.18)

原因

このエラーは、インストールされているDockerサーバーのバージョンと、 docker-composeクライアント(API)のバージョンに互換性がない時に表示されるらしい。

回避方法

COMPOSE_API_VERSION環境変数にサーバーのバージョンを設定すれば、 docker-composeの方で、サーバーのバージョンに合わせて通信してくれるとのこと。 autoを設定すれば、自動で調整してくれるみたい。便利。

以下のコマンドを入力するか、/etc/profileとか~/.bash_profileあたりに追記しておく。

export COMPOSE_API_VERSION=auto

/etc/environmentに追記する場合は以下のようにする。

COMPOSE_API_VERSION=auto

docker-composeの利用例

当ブログの以下の記事で、具体的な使用例を紹介しているので、参照されたい。

TAIGA on Dockerで本格アジャイル開発管理

Tue, 01 Sep 2015 10:30:23 +0900

TAIGAは、やたらデザインがきれいなアジャイルプロジェクト管理ツール。
Trelloクローンという感じはなく、Redmine拡張のAlminiumに似ている。

ストーリーカードの重み付けやタスクボード、バーンダウンチャートなども備えており、しっかりとアジャイル開発をやりたい場合はおすすめ。

Taiga.Io | Agile, Open Source, Free Project Management System
https://taiga.io/

Dockerを利用した導入手順

以下のdocker-compose.ymlとイメージを参考/利用させていただきました。

GitHub: htdvisser/taiga-docker
https://github.com/htdvisser/taiga-docker

00. 事前準備

Dockerとdocker-compose¹をインストールしておく。

01. docker-compose.yml 設置

以下の内容のdocker-compose.ymlを設置する。
hostname, EMAIL_*辺りは各々の環境に合わせて書き換える。

data:
  image: tianon/true
  volumes:
    - /var/lib/postgresql/data
    - /usr/local/taiga/media
    - /usr/local/taiga/static
    - /usr/local/taiga/logs

db:
  image: postgres
  environment:
    POSTGRES_USER: taiga
    POSTGRES_PASSWORD: password
  volumes_from:
    - data
  restart: always

taigaback:
  image: htdvisser/taiga-back:stable
  hostname: example.com
  environment:
    SECRET_KEY: examplesecretkey
    EMAIL_USE_TLS: True
    EMAIL_HOST: smtp.gmail.com
    EMAIL_PORT: 587
    EMAIL_HOST_USER: example@gmail.com
    EMAIL_HOST_PASSWORD: password
  links:
    - db:postgres
  volumes_from:
    - data
  restart: always

taigafront:
  image: htdvisser/taiga-front-dist:stable
  hostname: example.com
  links:
    - taigaback
  volumes_from:
    - data
  ports:
    - 0.0.0.0:80:80
  restart: always

02. Docker起動

先ほどのdocker-compose.ymlがあるディレクトリ内で、以下のコマンドを入力。

docker-compose up -d

03. 足りないDBレコードを挿入

Dockerコンテナ起動時に、初期DBデータの挿入が行われるが、おそらくTAIGAのバージョンアップで、必要なDBデータが増えたっぽい。

動作確認時にプロジェクトが作成できない²、などの不具合を起こしていたので、取り急ぎ、こちらのコマンドで入れておく。

docker exec -it (taigabackコンテナID) \
  python /usr/local/taiga/taiga-back/manage.py \
    loaddata initial_project_templates

docker exec -it (taigabackコンテナID) \
  python /usr/local/taiga/taiga-back/manage.py \
    loaddata initial_project_templates initial_user

docker exec -it (taigabackコンテナID) \
  python /usr/local/taiga/taiga-back/manage.py \
    loaddata initial_project_templates initial_role

04. 動作確認

通常画面

画面内の「create your free account here」からユーザー登録を行う。

http://(SERVER_IP)/

管理画面

DBレコード操作などを行う画面？
通常運用であれば、使わなくてもよい画面と思われる。

http://(SERVER_IP)/admin/
Username: admin
Password: 123123

導入でつまづいた点

新規ユーザー登録ボタン押下後に、次画面に遷移しない。

SMTP設定が正しくない。
Docker起動直後に登録した。(初期DBデータ登録が終わっていない？)

プロジェクトの作成途中で次画面に遷移しなくなる。

追加DBデータを挿入していない。

Namiking.net

パーサーコンビネーターを使って自然言語風のテキストからパラメーターを抽出する

実装したいこと

パラメーター抽出例

実装してみる

00. ソースコード全体

01. 使っている npm モジュール

Parsimmon - パーサーコンビネーターライブラリ

Ramda - 関数型プログラミング支援ライブラリ

02. 字句の定義

03. パーサーの構築

04. パーサーを使う

まとめ

各要素に名前を付けられる ＆ 組み合わせることができる

Parsimmon ドキュメントが Parsec より簡潔でわかりやすい

静的型チェッカーflowでReact+Reduxのサンプルアプリを組んでみた

サンプルアプリについて

ソース周りのファイル構成

ポイントいくつか

StateやActionの型定義をする

FluxスタンダードなAction型の定義

Counter関連の型を定義する

定義した型をActionやReducerで使い回す

Action関数の定義で使い回す

Reducer関数の定義で使い回す

コンポーネントのProps型はプロパティ変数で定義

コンポーネントのプロパティ変数でPropsの型定義ができる

コンポーネント内で使うActionはconnectしない

dispatch関数を直接propsに回す

action関数をconnectを通さないことで、元の型定義のまま使える

まとめ

静的型チェッカーflowのクラスでPrivateなフィールドを定義するメモ

なんでPrivateフィールドが必要？

flowのmunge_underscoresオプションを使う方法

.flowconfig 追記

実装例

継承元のクラスを直接インスタンス化すると使えちゃう

ES6のWeakMapを使う方法

実装例

コンソールデバッグがしづらい

[おまけ] Privateなメソッドも定義できる？

備考・注意点

まとめ

静的型チェッカーflowを使ってみて、微妙に気になったこと４つ

気になったこと４つ

ESLintとの併用でめんどうな事が多かった

Babelを通しても、ES6文法で使えないものがある

ジェネリクスなクラス/関数の使い方次第でエラー

クラスのフィールド定義などでセミコロンが強制

まとめ

サーバーサイドReactをwebpackを使って最小構成で試す (ES6 ＆ TypeScript)

この記事の方針

実装するサンプルアプリの内容

事前に必要なソフトウェア

[Memo] 利用したnpmパッケージのバージョン

ECMAScript6 版 (チュートリアル)

まずはクライアント側で動かしてみる

npm init

必要なnpmパッケージをインストール

webpack.config.js

.babelrc

public/test.html

src/client.js

src/components/Counter.js

webpack実行

動作確認

サーバーサイドからコンポーネントを描写する

必要なnpmパッケージをインストール

src/server.js

サーバー起動

動作確認

サーバーサイドとクライアントの処理をつなげる

src/server.js の修正

再度、動作確認

TypeScript 版 (要約)

要約

型定義ファイルマネージャにはdtsmを使った。

サーバーサイドのコンパイルはtscを直接使った。

クライアントのコンパイルにはwebpackのts-loaderを使った。

あとがき

各要素に名前を付けられる＆組み合わせることができる

Sparkで機械学習：回帰モデルで値を予測する