サーバーエンジニアの下川です。 IDEをローカルCloud9から、AWS Cloud9に移行しました。
はじめに
IDE、何を使っていますか？
私はvimや、少し前はVSCodeも利用しましたが、２年前程からメインで使用しているのはCloud9です。 Cloud9でもサービスの方ではなく、自前でサーバーにインストールして使用しています。
Cloud9がAWSに買収されたのは2016年7月。 そして、2017年12月にはAWS Cloud9がリリースされました。
2018年4月現在では、まだ東京リージョンにはリリースされていませんが、EU (アイルランド)、アジアパシフィック (シンガポール)、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)でリリースされています。
今回はローカルCloud9ユーザー、および、Lambda開発者がIDEをAWS Cloud9に移行する9つの理由を紹介します。
１つ目〜設定が簡単
今回はアジアパシフィック (シンガポール)でAWS Cloud9を使ってみます。 新規ではなく、現在私が使用している東京リージョンでAWS Cloud9を利用します。 (リージョンは違いますが、問題なく動作しました。)
まず、AWS Cloud9のコンソールから、「Create Environment」をクリックします。
名前を付けます。
EC2インスタンスを新規で立ち上げるか、既存のEC2インスタンスに設定するか？を選べます。 今回は元々稼働していたEC2インスタンスに入れます。
Copy key to clipboardで公開鍵をコピーして、別コンソールで対象インスタンスにログインし ~/.ssh/authorized_keys にペーストします。
これで「Next step」をクリックしたところ、 Cauld not execute Node.js というエラーが発生しました。
SSH接続は成功したけど、nodeが動かないようです。
自動でnodeを入れようとしたり、NODE_PATHから探ったり等はしないようです。
ここで、「Advanced settings」をクリック。Nodeのバイナリパスを指定できます。
nodeはnmvで入れていたので、とりあえず持ってるnodeのversionを確認。
$ nvm ls
v0.10.40
iojs-v3.3.1
-> v4.3.2
v6.11.3
default -> v4.3.2
node -> stable (-> v6.11.3) (default)
stable -> 6.11 (-> v6.11.3) (default)
iojs -> iojs-v3.3 (-> iojs-v3.3.1) (default)
LambdaがサポートしているNodeのバージョンがv4.3.2なので、これで動くかな？とv4.3.2のnodeで動くかやってみます。 念のためパスを確認。
$ node > global.module.paths [ '/usr/bin/repl/node_modules', '/usr/bin/node_modules', '/usr/node_modules', '/node_modules', '/home/shimoty/.node_modules', '/home/shimoty/.node_libraries', '/home/shimoty/.nvm/versions/node/v4.3.2/lib/node' ]
リトライしたところ、前に進みました！(ちなみにこれらの設定は全て後から変更可能です。)
確認画面の次に進むと・・・
これは起動の予感。Cloud9のロゴに胸が踊ります。
起動！ 簡単すぎて拍子抜けです。
２つ目〜接続が簡単
コンソールから「OpenIDE」をクリックすると、すぐCloud9が起動します。
ポートの設定で苦しんだり、ポートフォワードって何？とかそんなこと１ミリも考える必要がありません。 これは、ネイティブエンジニアの皆さんがちょろっとサーバーいじりたい時等にもとても良いのではないでしょうか。
３つ目〜死なない
ローカルCloud9ユーザの方なら経験あると思いますが、Cloud9はたまに謎の死に方をします。
設定後、わざとプロセス殺したらどうなるかな？とやってみたのですが、期待通り即復帰してきます。 自分で永続化の設定とかしないでいいんですよ！ (Cloud9ユーザーなら共感してくれるはず。)
４つ目〜簡単にLambdaの開発環境が整う
初回インストール後、自動Lambdaのコンポーネントのインストール画面がでてきます。
至れり尽くせりすぎて申し訳なくなるレベル。 両方入れてみます。
途中でsudoのパスワード入力が求められるところで入力を求められるので何回か入力してOKを繰り返せばインストール完了です。
５つ目〜LambdaFunctionの新規作成がIDE上でできる
さて、AWS Cloud9の個人的目玉機能、Lambdaに進みます。 どうやって作るのかな、と思ったら、welcome画面にCreate Lambda Functionの文字が。
でもここは、既存のLambda関数を動作させたい！ でもRemote Functionsが0・・・？更新してもリストが更新されない・・・。
ふと、更新ボタンの上に目をやると、、、、
そうだ！既存のLambdaFunctionは東京リージョン！AWS Cloud9はシンガポールリージョン！
AWSさん！東京リージョンもよろしくお願いします！！！
ということで既存LambdaFunctionを動作させるのは諦めて新規作成します。
(2018/4/5追記)
すみません、AWSの中の人からご指摘いただきまして、Lambdaのリモートのリージョンは切り替えられました！
Prefernces画面にAWS Settingsというメニューがあります。 そちらからリージョンを選択すると既存のLambdaFunctionがRemote Functionsに反映されました！
ご指摘ありがとうございました！
(2018/4/5追記ここまで)
IDE上でLambda functionの新規作成ができます。
まず、Function名を入力。
blueprintを選択。
トリガを選択。APIGatewayもlocalでテストできるんですね。 今回はnoneとします。
IAMロールを選択。 コンソールと同じで、ここからIAMロールの作成もできますが、今回は既存のロールを選択します。
確認画面でFinishをクリックし、無事完成です。 完成。 ふとRemote Functionsを見ると1になってます。
この時点でRemoteも更新されるようですね。 コンソール側でも確認できました。
６つ目〜LambdaFunctionの実行がIDE上でできる
では早速「Run Local」で実行。
ここでエラーが発生です。
Could not find AWS SAM Local at path: '~/.c9/bin/sam'.
sam-localが必要とのことです。
sam-localを手動でinstallします。
npm install -g aws-sam-local
~/.c9/bin/samにシンボリックリンクを作成します。
ln -sfn $(which sam) ~/.c9/bin/sam
そして、リラン！
node.js
exports.handler = (event, context, callback) => {
console.log('Hello Cloud9');
context.succeed("Hello Lambda");
};
動きました！responseもログも表示されてます。
７つ目〜LambdaFunctionのステップ実行ができる
あとは念願のステップ実行。 ブレークポイントを設定。
Runの隣の領域にあるDebugモードスイッチをONにしてRun。
止まりました！ Local Variablesのvalueでiが0な事も確認できます。
そして説明するまでもなく、ステップ実行も簡単です。
ローカル実行は便利ですが、やはり node で直接動かした方が起動が早いです。ある程度nodeで直接動かしてから、ローカル実行、デバッグ実行を試して行くのが良さそうです。
８つ目〜コスト節約設定が簡単
今回は既存インスタンスからの作成でしたが、新規インスタンス作成を行うと、「Cost-saving setting」という選択肢が出てきます。
もう説明は不要でしょう。 こんな設定まであるとは驚きました。
もちろん24時間365日開発をする方のために「Never」という設定もありますのでご安心を。
９つ目〜API Gatewayまで含めたテストができる
API Gatewayの設定、実行もIDE上でもちろんできます。
CloudFormationの設定ファイルが自動で作成されますので、設定管理もできます。 また、環境を複製したり、自動化したりも手軽にできますね。
積極採用中!!
子育て家族アプリFamm、カップル専用アプリPairyを運営するTimers inc. では、現在エンジニアを積極採用中！ 急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください！ 採用HP : http://timers-inc.com/engineerings
