✏️ 👤

新サービス AWS Serverless Application Repository をさらっとウォークスルー

Serverless Advent Calendar 2017 の 22 日目です.

AWS の新サービス、Serverless Application Repository のプレビュー申請が通ったのでスクリーン・ショットを交えてさらっと紹介していきます.

昨日の ykarakita さんの記事に同じくわたしも AppSync のことを書きたかったんですが、リリース当日のプレビュー申請にも関わらずこちらいまだにゼロ回答をいただいております. AppSync〜〜〜〜〜!!!

さて、先週書いた AWS SAM の記事でも軽く触れたとおり、Serverless Application Repository は re:Invent 2017 で発表された新サービスです. 2017.12 現在、us-east-1 (N. Virginia) と us-east-2 (Ohio) リージョンでプレビュー中というステータスです.

サーバーレス・アプリケーション開発者、利用者それぞれのためのプラットフォームのようなサービスで、開発者は AWS マネジメント・コンソールを通して自身のアプリケーションを公開 & 配布でき、利用者も AWS マネジメント・コンソールから公開されているアプリケーションを自身の AWS アカウント配下に簡単にインストールすることができるようになるようです. インストールされたアプリケーションに対して最新コード・ベースから更新を配信することも(更新をデプロイするかは利用者次第な雰囲気)できるようなので胸踊りますね.

本記事では実際に Serverless Application Repository を使って

  • 公開されているサーバーレス・アプリケーションをインストール
  • 自作サーバーレス・アプリケーションを公開
  • 自作サーバーレス・アプリケーションのインストールと更新

という流れをウォークスルーしてみようかと思います.

本日紹介する画面の中には Serverless Application Repository のプレビュー申請が通っていないと開くこともできないものが含まれています. まだプレビュー申請を行なっていない方はこちらからサクッと申し込めます. 申請には AWS アカウントの ID (数字12桁くらいだった気がします)が必要なので事前に調べておきましょう.

目次

Serverless Application Repository 関連ページ・ドキュメント

画面はこんな感じ

公開されているアプリケーションは AWS Lambda の Create function 画面から確認することができます. 選択肢の一番右側に Serverless Application Repository が増えています.

Select apps from Serverless Application Repository

この画面の下の方には以下のようなカードがアプリケーションごとに並んでおり、その単位でデプロイすることができるようです.

App card on Serverless Application Repository

  • アプリケーション名
  • 開発者
  • デプロイされた回数
  • タグ(ラベル)

あたりの情報が乗っています. タグをクリックして絞り込みたくなりましたがクリックしてもなんの反応もなかったので残念です.

ざっとみた感じ現時点では AWS 内部で完結するものが多い印象ですが、3rd パーティー・ベンダーのサービスとの連携をするためのものもたくさん公開されていました. Splunk, Datadog などの運用系サービスのベンダーのものとか.

「何か良さげなアプリケーションは公開されてないかな」的な軽いノリの探し方ではお目当のものは見つけられそうにない作りに AWS の質実剛健さを感じます.

公開されているアプリケーションのインストール

さっそく公開されているアプリケーションをインストールしようと思います.

ここでは上でスクリーン・ショットを載せた cfn-flip-service というやつをインストールしてみます. デプロイすると CloudFormation テンプレートを JSON/YAML 間で変換して返してくれる API を利用できるようになるみたいです.

カードのアプリケーション名のところをクリックすると以下のような画面に遷移します. とりあえず各タブを開いて見ていきます.

Configuration - ここで入力した名前が CFn のスタック名になるのかなそうなのかな. パラメーターが必要なアプリケーションの場合もここに入力欄が出てくるみたいです.

Configuration - ここで入力した名前が CFn のスタック名になるのかなそうなのかな. パラメーターが必要なアプリケーションの場合もここに入力欄が出てくるみたいです.

Details - あー詳細ですね

Details - あー詳細ですね

Permissions - cfn-flip-service はパーミッションが空だったのでこれは他のアプリケーションのものです. 一覧になってるの便利ですね.

Permissions - cfn-flip-service はパーミッションが空だったのでこれは他のアプリケーションのものです. 一覧になってるの便利ですね.

Template - 実際にデプロイされる AWS SAM テンプレートも表示してくれます. こんなサクッと見えちゃうと雑な名前を書きにくいですね.

Template - 実際にデプロイされる AWS SAM テンプレートも表示してくれます. こんなサクッと見えちゃうと雑な名前を書きにくいですね.

Readme - 読んでね

Readme - 読んでね

License - ライセンスも合わせて表示してくれます. いいですね.

License - ライセンスも合わせて表示してくれます. いいですね.

ここでは特に何も変更せずに画面右下の Deploy ボタンを押下してみました.

デプロイ中...

デプロイ中...

しばらく待つと、以下の通りデプロイが完了します.

デプロイ完了！

デプロイ完了！

で、ここからどうすればこのアプリケーションを利用できるんですか？となりますが、Serverless Application Repository 側はここでは何もしてくれないようです.

このアプリケーションの場合は API をデプロイするとのことだったので、「CloudFormation の Outputs のところを見たらきっと API Gateway のエンドポイントが出力されているはず・・・！」という予想のもと CloudFormation の画面を開いてみたらちゃんと出力されていました.

次に API の呼び出し方を調べました.「さっきスクリーン・ショットを撮った時に README になんか書いてあった気がする・・・！」という思い出を頼りに再度 AWS Lambda の Create function 画面に戻って cfn-flip-service を探しだし、README にたどり着きました. なるほど、cfn-flip-service はいろいろ HTTP ヘッダをつけてボディに CFn テンプレートを載っけてさっきの API Gateway に POST すればいいんですねーなるほどなるほど…

個人的にはこのあたり質実剛健すぎて CloudFormation とか AWS SAM 使ったことないユーザーにとってはハードルがすごく高い気がしました. 公開する側も今まで以上にユーザーが使いやすいようにドキュメントなどを用意する工夫が必要だと感じさせられます.

なので、アプリケーション利用者の視点でこのサービスを見ると、AWS SAM で記述されたサーバーレス・アプリケーションを自分自身でデプロイする際に必要な aws cloudformation package と aws cloudformation deploy の 2 コマンドの実行を省略してくれるものと考えるのが少なくとも現時点では分かりやすそうです.

自作アプリケーションの登録

自作アプリケーションを公開するための画面はまだサービス一覧にもメニューがなかったので URL 直叩きで開く必要がありそうです. 開発者ドキュメントによると https://console.aws.amazon.com/serverlessrepo/home とのこと. とりあえずドキュメントは読まずに進めてみました.

上記の URL にアクセスすると(プレビュー申請が承認されていれば)以下のような画面が開きます.

何か公開できそう

何か公開できそう

Publish application をクリックして先に進みます. 今回は昨年公開時に一部界隈で話題騒然(当社比)となった toricls/cobolambda を登録してみることにします.

全部埋めてみた状態 - Labels がカンマ区切りではなく半角スペース区切りでハマりました

全部埋めてみた状態 - Labels がカンマ区切りではなく半角スペース区切りでハマりました

GitHub リポジトリが指定できると聞いていたので、リポジトリから勝手に読み取って色々埋めてくれるのかな？と思いきや、そんなことはありませんでした. 基本全部自分で埋める形です.

ですが考えてみれば確かにリポジトリで公開している README はデプロイのための事前準備などから書く必要がありますが、Serverless Application Repository で公開するものはデプロイに必要なパラメーターの意味だったりデプロイした後にどうやって利用すれば良いかの説明だったりがメインになると思うので、そのままリポジトリのものを利用されるよりもこちらの方がスジが良い感じがします.

ちょっと驚きだったのは SAM テンプレートもローカルからアップロードする(スクリーン・ショットでいう下のほう)方式ということです. これはつまりリポジトリで公開しているテンプレートとは違うものをここにアップロードできるということなので、もし別バージョンの SAM テンプレートをリポジトリと Serverless Application Repository で運用するとなると管理の仕方に工夫が必要そうです.
(僕が使い方をちゃんと理解できていなかっただけなのでこの表現は不十分です. 詳細は後述.)

スクリーン・ショット一番下に表示されているメッセージのとおり、最初は「プライベート」なアプリケーションとして登録されるようです. パブリックに利用してもらうためにはあとで設定変更する感じになります.

おもむろに Publish application をクリックすると以下のようなエラーメッセージが表示されました. (改行とか入れてます)

com.amazonaws.serverlessappsrepo.template.InvalidTemplateException: Invalid Serverless Application Specification document.
  Number of errors found: 
    1. Errors: Resource with id [CobolFunction] is invalid. 
      'CodeUri' is not a valid S3 Uri of the form "s3://bucket/key" with optional versionId query parameter.

登録しようとした AWS SAM テンプレートの該当部分 CodeUri は以下のように記述されています.

# - 省略 -
  CobolFunction:
    Type: AWS::Serverless::Function
    Properties:
      # テンプレートと同じディレクトリに index.js がある、という指定
      CodeUri: .
      Handler: index.handler
# - 省略 -

なるほど. 僕のいろんな勘違いが分かりました.

上記のエラーメッセージが表示されるまで、自分の中では Serverless Application Repository でのアプリケーション公開を勝手に以下のようなイメージで捉えていました. (結果としては間違ってます)

  • Serverless Application Repository で GitHub リポジトリを指定すると AWS 側で Git クローンとかしてくれて色々お作法に沿ったスクリプトを書いておけばうまいことデプロイまでやってくれる
  • なので例えば Node.js で書かれたコードの場合は node_modules とかその辺も AWS 側がうまいことダウンロードしてきてくれて、いい感じに Zip にまとめてどーんってやってくれる

これらは完全に誤りで、実際には次に書くようなサービスです.

なるほどこういう使い方なのね

アプリケーションを公開するためには、開発者は以下のような手順を事前に済ませておく必要があります.

  • 依存ライブラリなどをパッケージングし、公開された自分の S3 バケットにアップロードしておく
  • Serverless Application Repository に登録する AWS SAM テンプレートが、その中で Lambda のコードや API Gateway の Swagger 定義として上記のアーカイブを参照する形になっている

つまり、依存ライブラリのインストールや aws cloudformation package コマンドによるアーカイブ作成と S3 へのアップロードなどを済ませてから、その成果物を Serverless Application Repository にそのまま登録してくださいね、ということになります.

また、アプリケーションの登録画面に GitHub リポジトリの URL を入力する欄はありますが、AWS 側は特にリポジトリの中身を読み取るようなことはしていないようです.

まとめると AWS 側は以下のような使い方を一例として想定している気がします.

  • 開発者がコードベースに最新コードをプッシュする
  • 開発者が用意した CI/CD の中でビルド処理や aws cloudformation package コマンドを実行し、アーカイブを公開用 S3 にアップロードする
  • 同時に、アップロードしたアーカイブのパスを参照する形に書き換えられた AWS SAM テンプレートも出力される
  • (おそらく近い将来 Serverless Application Repository をサポートするであろう AWS CLI で)成果物を新しいバージョン番号とともに Serverless Application Repository に登録する(まずはプライベートな公開範囲で)
  • 登録した最新バージョンを開発者自身の AWS アカウントにデプロイする (ここも CLI でできそう)
  • テストする
  • 問題なければ公開範囲をパブリックにして、利用者側に公開する

なるほどなるほど. よく考えられてますね. というかちゃんと開発者ドキュメントに事前にやらなきゃいけないことは書いてあるんですよね. ドキュメントは読まないとダメですね.

というわけで cobolambda を AWS 側の前提を満たす形でアーカイブや AWS SAM テンプレートを用意して登録しなおすと以下のような感じの画面に遷移します.

登録された

登録された

事前に書いてあったとおり、Visibility はプライベートな状態になっていますね. こんなものを世の中に公開しても何の役にも立たないのでプライベートなまま進めます.

AWS Lambda の Create function 画面に戻って検索してみると以下の通り先ほど登録したアプリケーションが表示されています.

一覧に出てきた

一覧に出てきた

カードをクリックしてあげると最初に試した cfn-flip-service と同じような画面が出てきますので、そのまま Deploy してみます.

この後はさっきと同じですね.

cobolambdaデプロイ中...

cobolambdaデプロイ中...

デプロイ完了

デプロイ完了

ちなみに Serverless Application Repository でデプロイされた Lambda 関数の画面を開くとこんなメッセージが表示されるようです.

誤って Lambda のコンソールから関数を消すなどの作業を行ってしまうと CloudFormation 側が保持している状態との差分が発生してしまうため、気をつけたいですね.

実際に削除する際は、まずは上記メッセージに表示されている CloudFormation console のリンクを開きます(もちろん普通にいつもの CFn の画面からも開けます). 以下のような画面が表示されるので、プルダウンメニューを開いて Delete Stack しましょう. Lambda 関数だけでなく Serverless Application Repository からデプロイしたアプリケーションによって作成されたリソースを丸ごと削除することができます.

お行儀よく削除

お行儀よく削除

余談ですがこの記事を書いている間に cobolambda のデプロイメントの数が急に増えたんですが、公開範囲はプライベートなはずなのでバグか何かでしょうか. もし何かの誤りでパブリックになってたらすごく恥ずかしいので気になります. なんにせよ GA が楽しみですね.

ちなみに今回はやってないですが AWS SAM じゃない普通の CFn テンプレートだとどうなるかとかもそのうち試してみたいと思いました.

まとめ

AWS SAM 使ってるお友達を絶賛募集中です.

AppSync〜〜〜〜〜!!!