Engineer's Way

主にソフトウェア関連について色々書くブログです。

CloudFormationでElasticSearchService 5.x系を構築する時の注意点

 

CloudFormationでElasticSearchServiceを構築しようとしたところ、
Createに異様に時間がかかる上、

Creating Elasticsearch Domain did not stabilize.

というエラーが出て構築に失敗してしまうという状況に出くわしました。 (ロールバックにも異様に時間がかかるという、、)

調べてみたところ、バージョン5.x系のElasticSearchを作る場合、 AdvancedOptionsの指定が必須らしいとのこと。

https://forums.aws.amazon.com/thread.jspa?messageID=768527

YAMLだとこうなります。

      ElasticsearchVersion: "5.3"
      AdvancedOptions:
        rest.action.multi.allow_explicit_index: true
        indices.fielddata.cache.size: ""

公式ドキュメントだと「Required: No」となっているので結構な罠ですね、、。

AWS::Elasticsearch::Domain - AWS CloudFormation

Angular4(2+)でカスタムValidationを作る

 

Angular4(2+)で独自のValidationを作ってフォームに適用したい時のやり方を調べましたので、備忘録として残しておきます。

1. Validationディレクティブを作成する。

まず、ディレクティブとして、カスタムValidationを実装したクラスを作ります。 以下は単純な例で、フォームへの入力値が「abc」だったらNG、それ以外はOKとしてます。

import { Directive } from '@angular/core';
import { AbstractControl, FormControl, ValidationErrors } from '@angular/forms';

@Directive({
    selector: '[validateCustom][ngModel],[validatorCustom][formControl]'
})

export class CustomValidator {
    check(control: AbstractControl): ValidationErrors|null {
        return control.value === 'abc' ? {‘custom': true} : null;
    }
}

入力をNGとしたい時に「{‘項目名’: true}」をreturnします。

参考:angular.coreのソース
https://github.com/angular/angular/blob/71f5b73296708014b740fb5dd0145c0599de7a19/packages/forms/src/validators.ts

2. 作ったカスタムValidationを使う。

使いたいコンポーネントの中で以下のように書くことで使用できます。

import ‘CustomValidator’ from ‘../directives/custom-validator';

:
onNgInit() {
  const cv = new CustomValidator();
  this.control = new FormControl('', cv.check);
}

AWS SESでスパム認定されない独自のメールアドレスドメインを登録する

 

独自ドメインでメールを送信する時、受信側にスパムメールフィッシングメールと認定されないように注意しなければなりません。そのために、SPFDKIMといった認証技術を使って、ドメインを認証する必要があります。

SPF/DKIMの普及が迷惑メール対策に効果、Googleが調査結果を公表 -INTERNET Watch Watch

今回はAWS SESを使って、独自ドメインSPFDKIMの認証をしてみます。

1. ドメインの取得

まずはドメインが必要です。
Route53などで取得しましょう。

2. メールドメインの登録&DKIMの設定

  1. AWSコンソールでSESを選択 東京リージョンには残念ながら存在しないので、オレゴンリージョンあたりを選択します。
  2. 「Verify a New Domain」をクリックする。 f:id:matsnow:20170604170356p:plain:w400
  3. ドメイン名を入れ、「Generate DKIM Settings」にチェックを入れ、「Vefiry This Domain」をクリックする。 f:id:matsnow:20170604170418p:plain:w500
  4. Use Route53をクリックする。 f:id:matsnow:20170604170433p:plain:w500
  5. 画面が切り替わった後、そのまま「Create Record Set」をクリックする。 f:id:matsnow:20170604170439p:plain:w500
  6. pending vefiricationの状態になるので、verifyになるまで数10分待つ。 f:id:matsnow:20170604170511p:plain

3. SPFの設定

  1. 「Domains」の中から、追加したドメインをクリックする。
  2. 一番下の「MAIL FROM Domain」を開き、「Set MAIL FROM Domain」のボタンをクリックする。
  3. ダイアログ中の「MAIL FROM Domain」に任意のサブドメインを入力して「Set MAIL FROM Domain」をクリックする。 f:id:matsnow:20170604170533p:plain:w400
  4. 「Publish Records Using Route53」をクリック f:id:matsnow:20170604170606p:plain:w400
  5. Warningの画面になるので、MXとSPFの両方にチェックを入れてボタンをクリック f:id:matsnow:20170604170613p:plain
  6. verifyになるまで待つ。 f:id:matsnow:20170604171628p:plain

4. 設定できていることの確認

Gmailで確認してみます。

  1. 「Domains」から登録したドメインを選び、「Send a Test Email」でテストメールを送信する。 f:id:matsnow:20170604171320p:plain:w500
  2. 受信したメールの詳細を表示する。 f:id:matsnow:20170604170633p:plain
  3. dkim=pass」と「spf=pass」の所に、設定したドメインが記載されていればOK。 f:id:matsnow:20170604170641p:plain

以上でドメインの認証が完了です。

AWS LambdaをNode.jsで簡単に作れるサーバレスアーキテクチャのフレームワークClaudia.jsを実戦で使ってみた

 

f:id:matsnow:20170525010920p:plain:w200

はじめに

今のプロジェクトでAWS Lambdaによるサーバレスアーキテクチャのシステムを開発していますが、フレームワークとしてClaudia.jsというものを選択してみました。

Claudia.jsとは

AWS Lambdaのようなサーバレスアーキテクチャ用のフレームワークとしてはServerless Frameworkが有名ですが、
それ以外にClaudia.jsというフレームワークがあります。 claudiajs.com

以下のような点がServerlessとの大きな違いです。

  • Claudia.jsはAWS Lambda、かつNode.js (JavaScript、TypeScript)に特化している。 特化している分、非常に少ない手間でデプロイまでできる。
  • api-builderやbot-builderなどの追加パッケージを使うことで、簡単にAPIBotを作れる。

なお、サーバレスアーキテクチャということもあり、フレームワークといっても、
フルスタックやMVCなどではなく、むしろビルド・デプロイツールといった色合いが強いです。

Claudia.jsの導入

Claudiaの導入は以下のブログが分かりやすいです。 qiita.com

dev.classmethod.jp

あとは公式のサンプル集を見れば、たいていのものは作れると思います。(手抜き) github.com

実際に使ってみる

Claudia.jsはLambdaやAPIをNode.jsを書いていく上では非常に便利ですが、 実戦投入するに当たって、いくつか考慮する点があります。

1. package.jsonは関数ごとに用意する

公式のサンプルなどでは、ディレクトリは1階層だけで、そこにpackage.jsonが置いていますが、実開発ではディレクトリは複数階層になることが多いと思います。
例えば、以下のようなディレクトリ構成にする場合、api/hello、function/foo、function/hogeの各ディレクトリにpackage.jsonが必要です。

sample  
├── api  
│   └── hello  
│       └── index.ts  
└── function  
    ├── foo  
    │   └── index.ts   
    └── hoge  
        └── index.ts  

その時のpackage.jsonの内容は、例えば「function/foo/package.json」であれば、以下のようになります。
nameがLambda関数の名前、descriptionは説明文、mainはエントリポイントのJSファイルです。

{
  "name": "foo",
  "description": "Lambda関数のサンプル",
  "main": "index.js"
}

なお、node_modulesのディレクトリは下位階層には不要です。 通常のプロジェクトと同じくトップにあればOKです。

2. ロールはあらかじめ作成しておく

Claudia.jsのコマンドでは、とりあえず以下を指定すればLambda関数を作成できます。 sh $ claudia create --region ap-northeast-1 --handler index.handler ただし、この場合、Claudia.jsによってIAMロールが毎回新しく作られてしまいます。 そのため、あらかじめLambda用のIAMロールを作成し、「–role sample-role」のように指定するようにした方が良いです。

3. claudia create –handlerの指定は相対パス

単純なことですが、–handlerで指定するハンドラ関数はディレクトリ構成が影響します。 例えば、src/ の下にindex.jsを入れており、「export handler」としている場合、「–handler src/index.handler」と指定する必要があります。

4. api-builderの中でpromiseを扱うときはpromiseをreturnする

ハマりどころの1つとして、API作成時にPromiseを使う場合、それをreturnしないと、 CloudWatchLogsなどにも何も出力されないまま、APIが終了します。

api.post('/user', function (request) {
    return dynamoDb.put({
        TableName: request.env.tableName,
        Item: {  userid: request.body.userId }
    }).promise();
}); 

公式ドキュメントの「4. Return a Promise out of the API handler」に記載されていますが、 かなりハマりやすい点なので注意が必要です。 https://claudiajs.com/tutorials/external-services.html

まとめ

最初に慣れるまでは若干手間取るかもしれませんが、一度使い方を覚えれば非常に楽に開発が進められる、良いフレームワークだと思います。
とりあえず、今のプロジェクトでは、このままClaudia.jsを使い続けるつもりです。

Linuxでのファイルの正しい配置について

 

続きを読む

Exrm(Elixir Release Manager)を使ったリリースでエラーが出た時の対処法

 

続きを読む

BrowserifyからWebpack(バージョン2.2.1)に移行してみた

 

続きを読む

gulpで「CALL_AND_RETRY_LAST Allocation failed」というエラーが出た時の対処

 

続きを読む

Docker for mac v1.13でdocker pullできない問題

  

続きを読む