ご機嫌よう、ガラパゴスのおとめです。
今年のre:Inventでもたくさんのサービスが紹介されましたね。気になったサービスはいくつもあるのですが、今回はCloud9をさわってみようと思います。
この記事はガラパゴスアドベントカレンダーの6日目の記事です。ガラパゴスアドベントカレンダーは、ガラパゴスの姫君によって発案されました。ガラパゴスのおとめもガラパゴスの姫君に進化したいです。
Cloud9てなあに?
クラウド統合開発環境で、共同編集などもできるようですが、AWSの名前を冠しているだけあって、Lambda + API GatewayのセットアップやCodeStarと統合したデプロイなどにも対応しているようですね。
東京リージョンにはまだ来ていませんので、適当なリージョンを選んで使ってみましょう。
するとこのようにCloud9の実行環境を作成する画面になりました。ふむふむ。同じリージョンにある既存のインスタンスか、新しいのを作るようです。今回は新しいインスタンスを作ってみました。
また、Cloud9を実行する環境は、使っていないときに自動で止まるようです(デフォルトでは最後に書いてから30分が選択されています。止めないことを選ぶこともできます。自動停止していても使うときにはインスタンスは自動で起動します)。
環境ができるとIDEが開きま……せんか? もしも「サードパーティCookieが」みたいなエラーになったら、ブラウザの設定を変更しましょう。Safariたんの場合は「プライバシー>サイト越えトラッキングを防ぐ」のチェックを外します。
Lambdaを作ってみる
IDEを初めて開くと、このような画面になると思います。
おやbashコンソールがありますね? どうやらCloud9に必要な環境があらかじめセットアップされた普通のAmazon Linuxのようです。
そして何やらメニューが並んでいますが、では早速新しいLambda関数をぽちっとしてみましょう。
名前と説明を入れて……
テンプレートを選びます。まるでコンソールからLambda関数を作るのと同じですね。Go言語のサポートもアナウンスされましたがまだ選べないので、Python3にしてみます。
作成時にトリガーとしてAPI Gatewayを選択することはできるようです。でも他のトリガーはここでは選べないですね。CloudFormationを自分でどうにかする……のは面倒なので、他のトリガーにも期待したいですね。
セキュリティと……(今回はお試しなのでなしにしました)
パフォーマンスを選んだら……
何やら開発環境っぽくなりました。ふむ、選んだテンプレートのコードが書かれていますね。
実行ボタンを押したらそのままテスト実行になりました。イベントのパラメタをそのまま書いて実行できます。Lambdaのテスト、意外と面倒だったので、これは便利〜。
ところで先ほどAPI Gatewayをトリガーにしましたので、レスポンスを変更して、API Gatewayをテストしてみましょう。実装したら、ターゲットからAPI Gateway (local)を選んで実行するだけです。楽チンですね!
また、ブレークポイントを置くこともできるようなのですが……この記事を書いている時点では、Pythonの場合はブレークポイントは効かないようです。
何ができたのか見てみる
template.yaml
にお定まりのCloudFormationの設定が書かれています。また、.application.json
に実際のLambda関数とAPI GatewayのIDが書き込まれていました。
CloudFormationのテンプレートができていますので、これをイジったら他の設定などもできそうな気がしますね? 他のトリガーを指定したり、Lambda関数をVPCの中に入れてみたり?
ライブラリを含めてみる
Cloud9で作成したインスタンスでは、Python2.7とPython3.6がセットアップされていて、そのままpython
コマンドを打つとデフォルトでは2.7の方が使われます。これはpip
も同様です。
ところで新しいLambda関数を作るとディレクトリが作られて、bashコンソールからも普通に見えますね? じゃあ、ここにライブラリをインストールしたら使えるのかしらん?
今回はランタイムにPython3を選んでいますので試してみましょう。
関数の親ディレクトリに移動して、カレントディレクトリにパッケージをインストールしてみます。
$ pip-3.6 install simplejson -t .
importを書き換えて実行ボタンを押してみると、このようにimportもできているようです。
ではデプロイしてみましょう! デプロイボタンを押して、最後にデプロイされたAPI Gatewayをつついてみましょう。API Gateway (remote)を選んで実行ボタンを押してみます。
するとこのように、レスポンスが帰ってきました。ついでにcurl
もできました。デプロイ時に自分でパッケージをzipしたりとかする必要はないようです。
Runtimeを変えてみる
今度はRuntimeを変えてみましょう。まずNode.jsで新しいLambda関数を作ってみます(今回もAPI Gatewayをトリガにしました)。サクッと作ってデプロイしてテストしてみます。
動作しました。ところで、この関数は以前作ったもので、AWSからサポート期限の案内があったと想像してみます。うぅん。Node.jsはサポート期間が短くて、定期的にランタイムを変更したりするのが、ちょっと面倒ですので、この際ですからPythonに変えてしまいたいですね。
というわけで、前のステップで作成したコードをコピーして、template.yaml
を変更してみます。
変更前
...(前略) Resources: node2py: Type: 'AWS::Serverless::Function' Properties: Handler: node2py/index.handler Runtime: nodejs6.10 ...(後略)
Node.jsの関数ができています。
変更後
...(前略) Resources: node2py: Type: 'AWS::Serverless::Function' Properties: Handler: node2py/lambda_function.lambda_handler Runtime: python3.6 ...(後略)
なんのことはなく、HandlerとRuntimeを変更しただけです。ではデプロイして実行してみます。
実行できました。Lambda側のコンソールを確認すると、ちゃんとRuntimeが変わっています。
注意点?
Lambdaコンソールの側から関数を変更したら、その後Cloud9側からデプロイしても反映されなくなったり、Lambda関数を削除したら2度とデプロイできなくなったりしました。一応Lambdaコンソールを開いたときに「この関数はCloudFormationで管理されています」みたいなやんわりとしたメッセージは出てくるのですが、それ以外に何事もなく普通に編集も削除もできてしまうので、注意が必要かもしれません。
また、メニューなどをつつきまわしてみましたが、Cloud9からリモートを削除するみたいなことはできないみたい……?
さいごに
いくつか注意点などはありそうですが、ローカルでAPI Gatewayまで含めたテストができるのは便利ですね。
ところで! 明日はなんと〜ガラパゴスのアプリエンジニアがTensorflowしてしまうそうです! 読んでいただけると嬉しいです♪
さて、今日はAWS Cloud9を軽く眺めてみました。ガラパゴスでは、re:Inventで発表されたサービスを早速触ってみたいエンジニアを大大大募集しています。皆様の応募お待ちしています。
では、ご機嫌よう。
この記事は業務の一環として業務時間中に書きました。