bookmarkGo言語で Elasticsearch Index の再構築を行う

Elasticsearch で Index の再構築を行う場合、ダウンタイムを低減するために Alias 機能を利用するのが常道のようです。 Index Aliases and Zero Downtime | Elasticsearch: The Definitive Guide [2.x] | Elastic Elasticsearch インデックス・エイリアス — Hello! Elasticsearch. — Medium 今回 Elasticsearch を Go言語で利用するにあたり、elastic を利用します。elastic は Elasticsearch の クライアントライブラリです。 olivere/elastic: Elasticsearch client for Go. Go言語向け Elasticsearch クライアント Elastic の紹介とコントリビューション | カメリオ開発者ブログ なお、Elasticsearch は REST API が整備されているので、ライブラリ や SDK がなくとも利用は平易です。JSON の処理を手間に感じるようであれば、ライブラリの利用を検討するとよいと思います。 アイデア概要 Alias を利用するにあたり、Index の命名を以下のようにします。 Index名 = Alias名 - タイムスタンプ (などのなにか) 具体的な状態を以下に示します。 { "test1-1467527980": { "aliases": { "test1": {} } }, "test2-1467527980": { "aliases": { "test2": {} } } } 今回は簡略化のために UnixTime のタイムスタンプを採用していますが、衝突可能性が気になる場合は UUID v1 などで生成するのが宜しいと思います。 コード例 全ての Index を再構築するコード例は以下のとおりです。Elasticsearch のバージョンは 2.3.3、対応する elastic のバージョンは v3 です。 package main import ( "fmt" "strings" "time" "github.com/pkg/errors" "gopkg.in/olivere/elastic.v3" ) // ReBuildElasticsearchIndex は以下の処理を行います // 1.

today 2016-07-03 Sun
bookmarkAWS Lambda で本番/検証環境を切り替える

AWS Lambda で本番/検証環境を切り替える場合、いくつかの手段があります。今回はContext オブジェクトから得られる関数名を利用するアプローチを紹介します。なおコード例は Python です。 前提: AWS Lambda に環境変数はない AWS Lambda に 環境変数はありません。機能追加が待ち望まれる今日この頃ですが、外部サービスのトークンなど、セキュリティ上の観点からソースコードに埋め込みたくない情報を利用する場合は、AWS KMS を利用するのが宜しいと思います。 本番/検証環境の切替方法 ところで、ソースコード中で $ENV などの環境変数の値に応じて、設定ファイルの読み込み先やログ出力のレベルを変更するなど、プログラムの動作を変更したい場合があります。 上述のとおり、AWS Lambda では環境変数は利用できないので、どこかから情報を取得する必要があります。 1つの方法として、Build/Deploy のプロセスの中で値を変更する策が考えられます。環境毎に設定ファイルを用意しておき、ファイル名を変更してもよいかも知れません。しかし、CI サービスを利用しない/できない場合や、その他要因でこの方法がとれない場合、以下の方法を検討してみてください。 context.function_name の利用 The Context Object (Python) - AWS Lambda AWS Lambda の Entry Point (標準では lambda_handler()) へ渡される2つのオブジェクトのうち、context からは AWS Lambda の環境に関するさまざまな情報を取得できます。内容は上述の公式ドキュメントが詳しいです。 本番/検証環境それぞれで別の Function として Deploy している場合、動作の切替判定に context.function_name が利用できます。 def lambda_handler(event, context): if context.function_name == "your-awesome-function": log_level = "ERROR" elif context.function_name == "dev-your-awesome-function": log_level =

today 2016-07-02 Sat
bookmarkPython で パッケージを vendoring しつつ AWS Lambda へデプロイ

Glide で Go 言語のパッケージ管理と vendoring - Librabuch で書いた vendoring のプロセスは現状そこそこうまく回っています。 最近 AWS Lambda のコードを Python で書く機会が多いのですが、ここでも vendoring することにしました。 課題 AWS Lambda で Python の サードパーティ・パッケージを利用する場合、デプロイファイル群の中にパッケージを含める必要があります。よくサンプルでは、プロジェクト直下に pip install requests -t . などとしたのちにプロジェクトのディレクトリごと zip で固める方法が提示されます。 元々、関係無いファイルが含まれるディレクトリごとデプロイするのはあまり上品ではないなぁと思っていたので、対象物だけ明示的に指定するようにしていたのですが、依存パッケージに変化があった際にデプロイスクリプトを追従させるのも手間でした。 解決案 上述のとおり、Lambda へのアップロードにはパッケージを含める必要があるので、vendoring を行ったうえで、vendoring ディレクトリをデプロイファイル群に含めるようにします。 vendoring は以下のコマンドで実行できます。 mkdir ./vendor pip install -U -r requirements.txt -t ./vendor # もちろん個別指定でも OK # pip install -U requests -t ./vendor vendor ディレクトリを認識させるために、lambda_function.py にコードを追加します。 import os import sys # 以下の行を追加 sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)),

today 2016-04-29 Fri
bookmarkAWS Cognito User Pools は人類待望の IDaaS かも

引き続き主語大きめでお届けしております。 人類に IDaaS は早すぎた話 で IDaaS について触れました。昨日、Amazon Web Service から関連するリリースが出ました。 New – Your User Pools for Amazon Cognito | AWS Blog これまでの Cognito これまでも Amazon Cognito は、モバイルアプリや JavaScript アプリケーションから、AWS のサービスにアクセスするための認可・認証の機能を提供していました。しかし、ユーザーのパスワードや属性情報を Cognito が保持できるわけではありませんでした。また、Webサービスにおける一般的な認可のための機能やフロー – パスワードの複雑性の管理や Emailアドレス確認のプロセス – は提供されていなかったため、いわゆる IDaaS とは同カテゴリながら少し異なる位置づけでした。 これからの Cognito User Pools の登場によって、Cognito を本格的な IDaaS として利用開始できることが期待されます。 他の IDaaS に対する優位性は、User Pools が AWS の中に存在するという点に尽きます。サービスの継続性や堅牢性については相当のレベルで担保されることになると考えて差し支えないでしょう。一方、SDK 以上のツールは今後も提供されないと考えられるため、Auth0 の Lock のようなエレガントな認証インターフェースを実現したければ自前で実装するしかありません。この点については他の IDaaS に優位性がありそうです。 IDaaS についての補足 IDaaS というワードで調べると、サービスの種類はそこまで多くありません。しかし色々調査した結果、 BaaS や mBaaS のプラットフォームの中にユーザー認証機能があり、IDaaS の役割の一部または全部を兼ねているケースのほうが多いことがわかりました。例えば、Firebase や

today 2016-04-21 Thu
bookmarkAmazon CloudFront Origin Path と Invalidations の関係

Amazon CloudFront の Origin を Amazon S3 に設定し、かつ、Origin Path が root (S3 Bucket 直下) ではない場合、Invalidations の Path との関係が気になっていたのでその検証結果の備忘録です。 結論としては、Origin Path のディレクトリは含めずにその直下から Invalidation の Path を指定するのが正しいようです。 まとめると以下です。 https://librabuch.jp/index.html に対して Invalidations を行う場合で S3 Bucket に www ディレクトリを作成し、CloudFront の Origin Path を www/ に設定している場合 Invalidations の Path は /www/index.html ではなく /index.html と指定する。 なお、/ と /index.html は当然異なるので、https://librabuch.jp に対して Invalidations を実行したい場合は path を / に指定する必要があります。

today 2016-04-09 Sat
bookmarkGlide で Go 言語のパッケージ管理と vendoring

Go 言語の vendoring ツールとして Glide を使い始めました。 Masterminds/glide: Package Management for Golang vendoring とは vendoring とは、アプリケーションが依存する 3rd-Party パッケージ/ライブラリのソースコードそのものを自身のレポジトリに含めて管理する試みのこと、を指す用語の模様です(たぶん)。 Node.js における package.json に依存関係が書かれている状態だけでは vendoring ではないです。node_modules ディレクトリ自体をレポジトリの管理対象に含めることで vendoring ができている状態、と言えるようになります。 Node.js (というか npm) に限らず、node_modules 的な役割のディレクトリは .gitignore で無視するのがよくあるプロジェクトの管理方法です。vendoring 自体の厳密な定義の話や、vendoring することの是非については言及の対象外として、Go 言語で vendoring を行う話に進めます。 2点だけ補足をすると、Go 言語は外部パッケージを go get で Github などのレポジトリから直接ソースコードを取得してくる方式になっており、元来 vendoring とは相性がよいものでした。加え、npm の left-pad 問題もあり、多少プロジェクトのレポジトリが肥大化したとしても依存しているコードは自身の責任で保全できていたほうがいいだろうと考えたのが、vendoring を始めた動機です。 Go 1.6 のパッケージ管理について Go 1.6 からの標準機能として、コンパイラが $GOPATH 以外に ./vendor ディレクトリ配下を探索するようになりました。この点の歴史的経緯については既に情報が多いので割愛します。これから Go を始める方はそうなったことだけ把握していれば問題無いと思います。 参考 : Go言語のDependency/Vendoringの問題と今後.gbあるいはGo1.5 | SOTA この標準機能に、いまでは主要な Go

today 2016-04-09 Sat
bookmarkWordPress から Hugo (S3 + CloudFront) に移行

静的サイト回帰へのムーブメントに乗っかるために WordPress から Hugo に移行しました。以下参考文献。 Hugo - Introduction to Hugo WordPress から Hugo に乗り換えました - rakuishi.com WordPressからHugoへ移行して、ビルドとデプロイを自動化した話 | creative tweet. WordPress の Plugin に依存していた記述が壊れたりいくつかの情報が失われたりしていますが気が向いたら直す予定。 Hugo とは Hugo は、Jekyll などと同じいわゆる静的サイトの構築ツールの1つです。Go 言語でできています。 環境 環境は以下のとおりです。 Amazon S3 Amazon CloudFront Amazon CloudFront で SNI 用 独自ドメインSSL証明書が無料で利用できます。 New – AWS Certificate Manager – Deploy SSL/TLS-Based Apps on AWS | AWS Blog S3 RoutingRules に関する注意点 CroudFront + S3 の RoutingRules を有効にする際、Origin Domain Name を Static Website

today 2016-03-26 Sat