ServerlessConf Tokyo 2016が最高だった
イベント参加後の感想書くの久しぶりな気がするｗ
9/30（金）〜10/1（土）に開催されたServerlessConf Tokyo 2016に１日目のワークショップは普通に一般参加者として、２日目はスピーカーとして参加してきました。
ワークショップ
思った以上に実践的でそこそこ長丁場だったのもあって、けっこう疲れました。 ゾンビが大量発生した世界で生き残った人々が連絡を取り合うためのチャットシステムを作るみたいな感じだったのだけど、そのストーリー性のあるテーマのおかげでTwitterで参加者がわいわいしながらやっててとても楽しかったです。
その様子はこちらでご覧いただけます↓
内容はAPI Gatewayはやっぱりマネジメントコンソールから手動でポチポチするのツラいな・・・とか、Amazon ESやっぱ微妙だな・・・とか思ったりもしたけど全体的にはとても満足度が高かった。
カンファレンス本編
会場の写真を撮り忘れたのが痛いけど、とてもおしゃれで一体感のある良い会場でした。また、飲食の提供がとても充実していて、これどう考えても参加費以上にかかってるよね・・・という感じですごい充実していました。朝・昼・夕食が出て、特に夕食が話してばっかりであまりゆっくり食べられなかったけど、とても美味しかったです。懇親会のお酒も十分な量提供されていて良かったです。
自分のセッション
www.slideshare.net
一応、海外発のカンファレンスで海外ゲストも多いということでスライドだけ英語にして日本語で解説するスタイルにしてみました。元々、自分のツールを宣伝する気はほとんどなくて、そういう話をしても一部の刺さる人以外には面白くないのは自明だったので、フレームワークやツールの話をする人が自分だけということも踏まえて、なるべく網羅的に解説するとともに何をどう使うべきで、これからどうして行きたいか、を考えてもらえるような構成を意識しました。あとで懇親会とかで感想をくれた人達の反応から、わりと伝わったようで良かった。え、最初のネタ？何の話ですかね？？
追記：日本語による解説も書きました（勤務時間中なので会社ブログ）
ベンダーセッション
AWS,Azure,IBMのベンダーセッションについては内容的にはAWSとAzureは既に知っていることがほとんどで、AWSはEcho, Alexaのデモがあったのが良かった。Azureも知識レベルではそこそこ知ってるので特に得るものはなかったけど面白かったです。IBMはOpenWiskが思った以上にガチでServerlessに取り組んでるというのがまず意外で、一応これから動向くらいはチェックしていこうと思いました。あと、この場にGoogleが居ないのが本当に残念でした。Firebaseは素晴らしい（Firebaseについては同じくランチセッションで登壇したSection-9メンバーでフリーランスのきはるさんからの紹介が分かりやすかったです）し、Cloud Functionsも順調に正式公開に向けて開発されているようだし（MLを見る限り）、Serverlessの文脈に含むべきか微妙なAppEngineも、気にせずその凄さを語ってほしかった。
事例セッション
事例セッションはグノシーの松本さん、日経の猪飼さんのセッションが実体験に基づくノウハウ詰まった良セッションでした。あと、GS2の丹羽さんが情熱と共に高い技術力を持ってガチでServerlessに取り組んでいるのが、セッションもそうだしその後に個別にお話できた時からも感じられてとても応援したくなりました。
海外ゲストセッション
ServerlessConfの大本であるA Cloud GuruとCloud Academyの方々によるセッションで、どちらも英語ながら分かりやすい、的を得たセッションで良かったです。特にCloud AcademyのAlexさんのセッションがServerlessにする所・しない所やその他も含めて納得感のある構成や解説で最高でした。EngineYardの人のセッションも組織論的な話で気になってたけど、何をしてたか忘れたけどまともに聞けなかったのが残念。
www.slideshare.net
LT
お酒とこのあとのパネルのことに夢中であまりちゃんと聞けなかったけど、デジタルキューブ堀家さんの発表で紹介されたShifterはWordPressの運用を知っている立場からすると本当に最高です。世のWordPressユーザはみんな知っておいてほしい。
パネルディスカッション
伊藤直也さんをモデレータにお迎えして、スピーカーのグノシーの松本さん、日経の猪飼さんと共にパネルディスカッションに立たせてもらいました。ちゃんとした場でのパネルは初めてで、途中「伊藤直也先生とできない生徒（俺）」みたいな感じになって申し訳なさと悔しさがあったけど、それも含めてServerlessもそうだしそれ以外にも自分のこれからを考える上で得るものが大きかったです。改めて皆さんにお礼を言いたかったけど、気づいたら帰られてしまっていたので、この場を借りてお礼を言いたいと思います。ありがとうございました。
懇親会(Social)
懇親会では今までネット上（主にTwitterとGitHub）では絡ませてもらっていたけど、対面でお話したことがない方々とたくさん話すことができて本当に良かった。地方に住んでるとこういう時じゃないと会う機会がなくて、今回はServerlessが広いコンテキストで色んな人が集まるということでさらにそれを促進してたと思う。皆さん、これからもよろしくお願いします。
総括して
最高だった。会場wifi無いのにTwitter上で色んな議論や話題が出てて、自分も含めてみんなが色々考える良い刺激になっていたのが凄い良かったと思います。パネルでは「現実的な線」で落ち着いた感じはあったけど、自分としてはやはりもう少し先を目指してみたいので、これからも「やっていく気持ち」になりました。ということで、ちょうどまた東京出張のタイミングと合ったので来月のMeetupにも参戦します。あと、札幌でもやるぞ！！
最後に、主催の吉田さん、運営の皆さん、スポンサーの皆さん、ありがとうございました。
リモートマルチワーカーになりました
前置き
この記事は、同業で私のことを知っている方向けのご報告、及び私自身の節目に対する記録の意味で書かれたものです。
自分の新しい状況を適切に言葉で表現するのが難しい
とりあえず、今日から新しいスタートを切ったというのは間違いないんですが、転職しましたっていうのも違うし、かといってフリーランスになりましたっていうのもちょっと違う感じで、タイトル決めるのに小一時間悩みました。
色々調べていたら、マルチワーク（多業）という言葉があるらしく、微妙にニュアンスが違う感じもするのですが、わりとマッチしてる気がするのと、基本的にリモートワークになるので、合体させてみました。
http://www.mlit.go.jp/kisha/kisha06/02/020614_2/01.pdf
で、このなんとも怪しいタイトル*1のできあがりですｗ
状況など
とりあえず、状況を書き出してみます。
- 前の会社は退職しましたが、フリーランスとして一部業務を請け負っています
- 新しい会社はフルタイムではなく稼働日数を減らして契約社員という形でジョインしています
- 基本的にリモートワークになります
- 今は研修で東京にいて、数ヶ月の間は行ったり来たりします（ので、遊んでください）
ざっくり言うと、所属が変わってリモートワークになって「副業」だったフリーランスが「兼業」になったって感じですかね？
以前から副業として活動していたフリーランスとしての仕事に注力し、独立しようかと考え始めていた時に、とある会社の方々と元々は普通に業務委託で一緒に仕事をできればと思って相談させてもらっていたのですが、稼働を減らしてフリーランスの活動と両立する形での働き方を提案してもらい、提案されたポジションというか仕事内容が魅力的で、会社としても以前から良いイメージを持っていたので乗らせてもらうことにしました。待遇も基本的に正社員と同じでありがたいことです。（もちろん給与は稼働日数が少ない分は考慮されています）どの会社かはそのうち別の形でお知らせしたいと思うので、一応一旦ここでは書かないでおきます。 フリーとして外側から関わるとなかなかできないような仕事なども出てくるので、そういった意味でも中に入って関わる会社があっても良いのかなと思ったというのもあります。
一つ言っておきたいこと
前の会社を辞めたのは副業でフリーランスをやっていたからでは決してありません。
たまたま副業でやっていたからその道を志向しただけであり、それが無ければ単純に転職していただけの話です。それももう少し早い時期にしていたはずです。
じゃあなんで辞めたのかって話はここではしませんが、これだけは言っておきたい。
「副業は人材流出のリスクがある」は真逆（の場合もある）
これは前の会社が良い悪いではなく、普通に仕事をしていれば、つまらない仕事が回ってくることや上手くいかないことはあるものです。時にそれが耐え切れなくなってしまいそうになった時に１つの会社だけで仕事をしているとどうでしょう？
逃げ場がありません。苦痛のある仕事を続け無くてはならない。「逃れたければ転職するしかない」ということになります。
副業があれば「こっちの仕事はさっさと終わらせて別の仕事をしよう」と思えますし、気分転換になります。現実逃避に思われるかもしれませんが、会社側からしても低いモチベーションでダラダラ仕事されるよりよっぽど良いはずです。もちろん、それで本業に手を抜くようなことがあれば論外ですが、それはそもそも副業する時の大前提なのでまた別の話です。また、そうやって過ごしているうちにまたモチベーションが回復したならそれは両者にとってメリットにしかなりません。
そういうわけで、私は経験者として「副業は人材流出のリスクがある」は否定します。
これからについて
とりあえずは当面は家族との時間も大事にしたいので、新しい生活に慣れることを重視していきたいと思います。フリーの方のお仕事については、まだ活動のキャパはそれなりに残っているはずですが、既に契約済みのお仕事を除き、大変ありがたいことにいくつかいただいているお話についてこちらからアクションすることは少し様子を見ながらとさせていただきたいと思っています。 もちろん、アクションいただければちゃんと返しますので、優先で対応させたいなら今がチャンスかもしれませんｗ
というわけで
散文的になりましたがご報告でした。
|дﾟ)ﾁﾗｯ
SwaggerのAPI定義をRuby DSLで書いてAPI Gatewayにデプロイできる「rapis」というgemを作った
背景
API Gatewayはとにかく設定が面倒である。Serverlessの概念はシステムをシンプルに保てるとても素晴らしいものだが、それを実現するための設定が複雑になって、運用に支障が出たりするのは厳しい。*1
「柔軟なリソース定義を担保しようと思ったらまあ仕方ないよね」みたいな気持ちもあるが、やっぱり面倒なものは面倒だ。
便利だけど、1リソースでモックのレスポンス返すだけのAPI定義で50行超か・・・ / “AWS CloudFormation が Amazon API Gateway をサポートしたので使ってみた ｜ Developers.IO” https://t.co/vgKAk7BVHY
— Masashi Terui (@marcy_terui) 2016年5月10日
Terraformですらこの記述量なのか。。。 / “TerraformでAPI Gatewway - @ijin” https://t.co/KPf9jV4wzl
— Masashi Terui (@marcy_terui) 2016年5月2日
Swaggerですら面倒くさい。1APIにつき3行くらいで記述したい。
— Masashi Terui (@marcy_terui) 2016年5月2日
俺達（俺）は書いたコードをサクッと上げてサクッとAPI公開したいだけなんだ！！１
書いたコードをサクッとLambdaで実行出来るようにするツールはすでにある。
問題はAPI Gatewayの方。現状でAPI定義をする上で一番マシだと思えるのがSwaggerのインポートによる方法だが、それでも、x-amazon-apigateway-integrationみたいなAPI Gatewayの独自要素*2に色々突っ込む必要があったりして、まだまだ十分とはいえないし、冗長な表現も多い。
先人の知恵を借りてみる
同じように、非常に生のJSONで扱うのがツラい某CloudFormationというものがあるが、これをRuby DSL*3でかけるようにすることで劇的（当社比）に見通しが良くなり、冗長な表現を避けることができるようになるツールとして、kumogataがある。ただ変換を行うだけではなく、実際にデプロイを行ったりするための運用に便利な機能も付いていて、最近もv2になってChange Sets（プレビュー的な機能）に対応したりプラグイン機構を導入したりして進化してる。本当にいつもお世話になってます。
じゃあ、Swagger定義も同じようにRuby DSL化すれば楽になるのでは？
というのが今回の趣旨。併せて、運用に便利なdiffを取る機能や定義のデプロイ等も含めてツール化してみた。
使い方
とりあえずインストールはgemなのでこれです。
gem install rapis
詳しくはREADMEを読んでいただければと思いますが、ざっくり主なコマンドの解説だけ。
API Gatewayの仕様上の注意事項としては、Swagger定義のインポートはAPIのベースとなる設定に対して行うが、実際にAPIとして公開されるステージにデプロイ（反映）する作業は別のステップとなっており、エクスポートについてはベースの定義を出力することはできず、デプロイ済みのステージから抜くことしかできないということ（デプロイはまあ良いとしても、大本の設定は抜けるようにしてほしい。。。）*4
- API作成
rapis create -n <API名>
- APIとそれらが持つステージを一覧表示
rapis list
- 既存API定義をエクスポート
rapis export -r <APIのID> -s <Stage名>
rapis diff -r <APIのID> -s <Stage名>
rapis apply -r <APIのID>
rapis deploy -r <APIのID> -s <Stage名>
記述について
今のところ、機械的にRuby DSLに置き換えるとシンタックスエラーになるような部分以外は特に特別な記述に置き換えるようなことはしていないが、これから使っていく中で汎用的に使えるような省略表現やメソッドなんかを入れていくことで、もっと楽にかけるようにしていきたい。目指せ1APIあたり3行！
ちなみ現状(2016-06-02)ではにこれが
{ "swagger": "2.0", "info": { "version": "2016-05-27T17:07:04Z", "title": "PetStore" }, "host": "p0dvujrb13.execute-api.ap-northeast-1.amazonaws.com", "basePath": "/test", "schemes": [ "https" ], "paths": { "/": { "get": { "consumes": [ "application/json" ], "produces": [ "text/html" ], "responses": { "200": { "description": "200 response", "headers": { "Content-Type": { "type": "string" } } } }, "x-amazon-apigateway-integration": { "responses": { "default": { "statusCode": "200", "responseParameters": { "method.response.header.Content-Type": "'text/html'" }, "responseTemplates": { "text/html": "<html></html>" } } }, "requestTemplates": { "application/json": "{\"statusCode\": 200}" }, "passthroughBehavior": "when_no_match", "type": "mock" } } } }, "definitions": { "Empty": { "type": "object" } } }
こんな感じになる
rest_api do swagger "2.0" info do version "2016-05-27T17:07:04Z" title "PetStore" end host "p0dvujrb13.execute-api.ap-northeast-1.amazonaws.com" basePath "/test" schemes ["https"] paths do path "/" do get do consumes ["application/json"] produces ["text/html"] responses do code 200 do description "200 response" headers( {"Content-Type"=>{"type"=>"string"}}) end end amazon_apigateway_integration do responses do default do statusCode 200 responseParameters( {"method.response.header.Content-Type"=>"'text/html'"}) responseTemplates( {"text/html"=> "<html></html>"}) end end requestTemplates( {"application/json"=>"{\"statusCode\": 200}"}) passthroughBehavior "when_no_match" type "mock" end end end end definitions do Empty do type "object" end end end
実装について
基本的にはAWS APIをゴニョゴニョしているという形なんですが、一番面倒そうなAPI Gateway上ではJSONとして扱われるSwagger定義をRuby DSLと相互変換するのは、kumogataを含め、AWS等の設定をコード化するCodenize.toolsの作者であるid:winebarrelさんが公開しているdslhというgemを使ってます。
ということで、偉大な先人へ感謝をしつつ締めたいと思います。よろしくお願いします。
*1:普段、こんなことを言ったりしてるけど、これはServerless自体を否定してるんじゃなくて「サーバのお守りをしたくないだけならPaaSで良いんじゃないの？Serverlessはそこがコアじゃないよね？」って意味である
*2:参考→ Swagger に対する API Gateway 拡張 - Amazon API Gateway
*3:他のフォーマットもサポートしてる
*4:そもそもAPI Gatewayのデプロイの概念がよく分からんという方はコチラを→Amazon API Gateway での API のデプロイ - Amazon API Gateway
LamveryにSwaggerベースのちょっとリッチな機能付きAPI Gateway integrationを追加しました
経緯
API Gatewayの"x-amazon-apigateway-integration"っていう独自要素に色々突っ込んでるSwagger記述サンプルを見て複雑な気持ちになってる
— Masashi Terui (@marcy_terui) April 11, 2016
書いたコードをサクッと上げてサクッとWebから叩ける用にしたいだけなのに何故こんなにJSONを書かないといけないのか
— Masashi Terui (@marcy_terui) April 11, 2016
ということでサクッとAPIが定義できるようにしました。
ここで説明しないインストール方法や使い方の詳しい情報はGitHubのREADMEやQiitaの記事でご確認ください。
使い方（コマンド）
lamvery api [-d] [-n] [-r] [-s <stage-name>] [-w]
-dは恒例のDry run!!-nが後述の自動オプション付加の無効化-rで削除-sはAPI Gatewayで言うステージ（dev,prod環境使い分けるとかに使う）-wで新規作成時に設定ファイルにAPIを識別する番号を保存（更新する時に指定しなくて良いようにする）
設定
こんな感じで設定を書きます。
api_id: myipugal74 stage: dev cors: origin: '*' methods: - GET - OPTION headers: - Content-Type - X-Amz-Date - Authorization - X-Api-Key configuration: swagger: '2.0' info: title: Sample API schemes: - https paths: /: get: produces: - application/json parameters: - name: sample in: query required: false type: string responses: '200': description: 200 response schema: $ref: '#/definitions/Sample' definitions: Sample: type: object
ちなみにこれとほぼ同じ雛形は以下のコマンドで生成できます。
lamvery init
で、本来ならこれをAPI GatewayでLambda backendによって動かすためには x-amazon-apigateway-integration っていう要素に色々突っ込まないといけないわけですが、その辺は同じくLamveryでデプロイしたFunctionに向くように自動でよしなにやってくれるという感じです。
差分表示
こんな感じでDiffっぽくSwagger定義の差分が見れます。Dry runにすれば事前に確認だけすることが可能。
最後に
これぐらいサクッと書いてサクッとAPI公開できると「ああ、サーバレスっていいなあ」って思えそうな感じ。
ただ、認証の定義とかは未対応だし、自動オプション付加のやり方とかもうちょっとスマートに出来ないか悩み中で、もしアイデアあればいただけると嬉しいです。
-n（x-amazon-apigateway-integrationの自動付加をしないオプション）をつければ単純に差分表示＆Dry run対応のSwagger importerとしても使えるので、良かったら使ってみてご意見ください。
明日、ぺちかん北海道なのに俺、何やってんだ。。。
各社のサービスから見えるServerlessの本質とは何か
前置き
ポエム系です。以下は私の見解ですが、異論は大いに認めます。
あと、エイプリルフールは全く関係ありません。ごめんなさい。
まず、本日2016.04.01、MicrosoftがAzure Functionsというサービスを発表しました。
これで、AWS Lambda・GCPのCloud Functions・Azure Functionsという、三大（？）クラウドの所謂Serverlessと呼ばれるジャンルのサービスが出揃ったわけです。
AWS Lambda (サーバーレスでコードを実行・自動管理) | AWS
Google Cloud Functions Documentation | Cloud Functions | Google Cloud Platform
ドキュメントを読んで分かったAzure Functionsの実体
とりあえず、気になるサービスが出てきたらドキュメントを読んでみるようにしているのですが、そこでAzure Functionsがどんなものなのかなんとなく窺い知ることができました。
ランタイムとしてはC#, Node.js, Python, F#, PHP, batch, bash, Java等をサポートするようです。
「おお、多いなスゲー」とか思ったんですが、読み進めてみるとAzureのPaaS系サービスであるApp Serviceの一機能であるWebJobsと関連しているような記述が出てきます。
バックグラウンドジョブを行うWebJobsにスケジュール実行だけではないStorageやQueueからのイベント実行を追加したようなものがAzure Functionsの今のところの実体のようです。
ちなみにCloud Functionsは今のところ基盤としてContainer Engineを使用しており、コンテナクラスタからオンデマンドで実行環境（コンテナ）を割り当てていくような実装のようです。今はGKEインスタンスがユーザから見えちゃってるんですが、これは無くなってユーザは意識せずに使えるようになる予定のこと。
Lambdaは中身が全然見えないのですが、上記のCloud Functions完成形って感じの雰囲気ですよね。
さて、ここで考えてみたいのは以下です。
PaaSとServerlessって何が違うの？
よく言われる、ユーザが管理しなくて良いマネージドサービスを使って運用フリーなシステムを作るっていうのがありますが、
それって（狭義の）PaaSでも一緒じゃね？*1
っていう話なんですね。
ここで注目したいのが、Azureが今までPaaSとして提供してきたものにEvent Drivenな要素を足してServerlessなサービスと銘打って出してきたということです。
つまり、"PaaS(狭義) + Event Driven = Serverless"であるという一つの定義が見いだせるわけです。
あとは、課金体系ですね。PaaSは基本的にアイドル状態でも課金が発生しますが、Serverless系のサービスは真に動いている分しか課金が発生しません。
Serverlessの本質とは
これは私の見解なので異論は大いに認めます（2回目）
まず、最近話題のServerless(Architecture)と呼ばれているものについて、ずっと違和感を感じていました。
「API Gateway + LambdaでAPIシステム作るのがCoolだ」みたいな話ですね。
こんなことを言うとたぶん誰かに怒られる気がするのですが、
いや、普通にPaaS使った方が良いんじゃない？
っていう。全部がそうだとは言いませんが、けっこうそういうケースが多いんじゃないかなと。
扱いやすさを求めるならHerokuでRailsとか、性能を求めるならApp EngineでGolangとかで良いと思うんですよね。
最近なら、AWSにこだわりたいならAWS上でのライフサイクルを自動化してPaaSのように使わせてくれるMobingiという手もあります。
https://mobingi.co.jp/mobingi.co.jp
ただ単に「インフラ運用したくない！！１」ってだけなら、そっちの方が管理も楽だし制約も少ないので良いと思うんです。
（管理が大変だからこういうツールを作りたくなるわけで）
じゃあ、何が本質でどんな場面でServerless系のサービスが良いのかっていうと、そこで出てくるのがやっぱりEvent Drivenじゃないかと。
その中でAPI Gatewayがどんな存在になるかというと、Lambdaに対してWeb hookだったりとか、ユーザの行動イベントをHTTPリクエストとして別システムから伝えるためのインターフェースだと思うわけです。
AWSはその辺り別サービスにして徹底的に疎結合になってるのがさすがって感じですね。だからこそ色んな使い方ができているというのはあると思います。（他はHTTPが単にトリガーの一つの扱いのはず）
クラウドのサービスとサービスの間をイベント連携する、あるいは他システムやユーザの行動を絡めたりもして、システムをイベント駆動で作り上げていく、それがServerlessの本質というか最大のメリットなのではないかと。
そういう風に考えると、多様なイベントに対応し、これからもどんどん増やしていくであろうAWS Lambdaがやっぱり一日の長があるといった印象です。
つまり何がいいたいかっていうと
っていうか、Lambdaのマイクロサービスとかサーバレスの話はもういいから、イベントドリブンコンピューティングの話しようぜ
— Masashi Terui (@marcy_terui) March 23, 2016
あと、もう一つ
App Engineを昔のCPU時間課金に戻して、Event Driven要素足せばそれだけで最強のServerless実行環境になるので、Google先生におかれましては是非ご検討のほどよろしくお願いします
— Masashi Terui (@marcy_terui) April 1, 2016
*1:広義のPaaSはIaaSの上に乗るマネージドサービス全般、狭義のPaaSはHeroku,App Engine等のアプリケーション実行環境を指すと思ってます
Lamveryが速攻でLambdaのVPCサポートに対応したぞ！
本題
念願の（？）LambdaのVPCサポートが来ましたね！
これはもうすぐにでも使いたいやつなので、速攻で対応しました。
v0.12.0～対応済みとなっております。
他にも随時機能が増えたりしてるので、以下の記事やREADMEをご確認ください。
設定ファイルはこんな感じ
vpc_config以下が該当部分です。
今後、SecurityGroupとかIDじゃなくて名前で解決できるようにしたい。
profile: private region: us-east-1 versioning: true default_alias: test configuration: name: lamvery-test runtime: python2.7 role: {{ env['AWS_LAMBDA_ROLE'] }} handler: lambda_function.lambda_handler description: This is sample lambda function. timeout: 10 memory_size: 128 vpc_config: subnets: - subnet-cadf2993 security_groups: - sg-4d095028
補足
VPC内でのLambdaの起動（や削除等も含めた諸々）にはENIに関する権限が必要になります。
以下の様なIAM Role Policyの設定が必要です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeNetworkInterfaces",
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:AttachNetworkInterface",
"ec2:DetachNetworkInterface"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:<region>:<account-number>:key/<key-id>"
]
}
]
}
最速だろコレは！
Lambda(Python)のスケジュール実行をコード(YAML)化してコマンド一発で設定！LamveryのCloudWatch Events対応とその他アップデートまとめ。
以前、QiitaやCloud RoadshowのLTで、AWS Lambda for Pythonのデプロイを便利にする拙作のツール(OSS)をご紹介しました。
その後もちょっとずつ改善を重ね、以下の様な機能追加・変更を行いました。
- 差分表示を整えた
- Lambdaの設定だけ変更するコマンドを追加 *1
- デプロイパッケージ(zip)の容量削減
- アーカイブ*2にライブラリを含まないオプションの追加
- リージョン毎にLambdaの容量に制限があるので合計容量も差分表示するようにした（下記参照）
下2つは @ijin さんにインスパイアされた機能です。ありがとうございます。
そして今回、一つ目玉的な機能として、CloudWatch Events対応をリリースしました。
これは、主な用途としては兼ねてよりAmazonらしからぬコンソールの画面先行でAPI待ちだった Scheduled Eventsに対応するものです。
つまり、Lambda functionのスケジュール実行がコマンド一つで設定できるようになります。
定義もテンプレートエンジン付きのYAMLで簡潔かつ柔軟に記述できます。
最近、こんなのが話題になりましたが、
Python限定でFunction毎の管理という面で少し方向性は異なりますが、こっちの方が手軽だし便利で高機能なので、是非使ってみてください。 *3
使い方・設定の解説などはREADMEに書いていますが、後日Qiitaあたりに日本語でまとめようと思います。
今回のアップデート以外の部分については以下にまとめてます。
ざっくり使い方
Functionを実装してデプロイした上で、以下のような設定ファイルを記述（lamvery init で雛形生成可）します。
profile: private region: us-east-1 configuration: name: lamvery-test runtime: python2.7 role: {{ env['AWS_LAMBDA_ROLE'] }} handler: lambda_function.lambda_handler description: This is sample lambda function. timeout: 10 memory_size: 128 events: - rule: foo description: bar schedule: 'rate(5 minutes)' targets: - id: test-target-id input: this: - is: a - sample: input
コマンドを叩きます。
lamvery events
これだけ！
もちろん、Dry runをサポートしているので -d を付けて事前に更新内容だけ確認することもできます。
また、これを作る過程と使っていてLambda(Python)及び、CloudWatch Eventsについてかなりの知見や想定が溜まっているので、それもどこかで放出したいと思います。 *4
以上です。
是非使ってみてフィードバックをいただければ嬉しいです。
*1:それまではdeploy時と一緒にやる選択肢のみ
*2:アップロードするためのZIPアーカイブ
*3:正直、アレで1400 Starとか、やっぱり「何ができるか」よりも「誰が作ったか」が大事なんだな感あって、ちょっと悔しい
*4:JAWS Days 2016のタイムテーブルでLambda枠がまだ埋まってない(2015-01-23現在)んだけど、入れてくれたりしないかなー|дﾟ)ﾁﾗｯ
