Google Cloud PlatformとAmazon Web Servicesには、Webアプリを動かすためのインフラが豊富に揃っています。とはいえ、新しいサービスに手を出すのは気が引けるもの。まずはコマンドラインから最小構成のインスタンスを立ち上げて様子を見たい、というのが本音ではないでしょうか。
本記事では、筆者が用意した「Quickstart」を使って、Google CloudとAWSの9サービスをすばやく体験する方法を紹介します。ここでいうQuickstartとは、対象サービスを「Hello World!」が表示される段階まで一気に進めてくれる軽量スクリプトのこと。同時に、その裏側で何が起きているのかを把握する助けにもなります。
このQuickstartがあれば、「何が何だかさっぱり」という最初の壁をすんなり越えて、「とりあえず動いた!」という安心ポイントまでたどり着けます。あとは、興味のある機能を少しずつ追加していけばOKです。

Quickstartの設計方針
すべてのQuickstartは、共通の方針に沿って作られています。「自動化されている」「最小構成である」「単体で完結している」の3つです。
自動化
最初の探索にはGUIが向いていますが、「Hello, World!」段階ではスクリプトに軍配が上がります。設定を調整したり機能を足したりしながら、同じサービスを何度でもデプロイできるからです。
最小構成
「Hello, World!」スクリプトはとことん最小構成です。HTTPレスポンスを返すのに必要な最小限のコードだけを書きます。
GCPでは、特定の技術を最短で動かすためのチュートリアルを「Quickstart」と呼びます。筆者のリポジトリでは実行可能なスクリプトに絞り込むことでさらに簡素化しており、こうした記事よりも一段とシンプルな内容になっています。
AWSのQuick Startは、特定の技術を動かすためのCloudFormationテンプレートです。これも便利ですが、筆者があえてシェルスクリプトを用意したのは、低レベルのコマンドを理解しやすくするため。後々フルスタックのシステムを組むときに、この理解が効いてきます。
いわば「Quickstartよりさらに素早いQuickstart」といったところです。
完結性
スクリプトは、IAMロールやクラスターなど、必要なものをすべてまとめてデプロイします。前提となるのはコマンドラインツールと、クラウドアカウントへの認証だけ。これさえ揃えば、必要なものをすべて立ち上げることを目指します。途中でつまずいても、各コンポーネントを安定状態に戻す手順を考えることなく、ゼロからやり直せます。
理想としては、スクリプトは再実行可能で、既存のデプロイに新しいコードを上書きできるのがベストです。本リポジトリでも一部はそうなっていますが、再実行対応にするとコード量が膨らみすぎるものは見送りました。その場合は、再デプロイ前に古いインスタンスを削除するか、新しいバージョンを別名で起動してください(コストにはご注意を!古いインスタンスは早めに削除しましょう)。
前提条件
前提条件は各ディレクトリのREADMEに記載しています。主な内容は次のとおりです。
gcloud(gcloud initで認証済みのもの)- 認証情報を設定済みのAWS CLIツール
- AWS CLI用のLightsailプラグイン
- Elastic Beanstalkの
ebツール - ECS用の
ecs-cliツール(こちらはスクリプトが自動でインストールします) - コマンド出力の処理用に、スクリプトによっては
envsubst(gettextパッケージで導入)とjqが必要です
対応インフラ一覧
以下のサービス向けにスクリプトを用意しました。
- AWS Elastic Beanstalk
- AWS Lambda
- Amazon Elastic Container Service
- Amazon Lightsail
- Google App Engine Standard Environment
- Google App Engine Flexible Environment
- GCP Cloud Functions
- GCP Cloud Run
- Google Kubernetes Engine
スクリプト
gitリポジトリには、各インフラ技術ごとのdeploy.shスクリプトがサブディレクトリに収められています。思い切って一気に試したい方は、ルートディレクトリのrun_all.shからまとめて実行することも可能です。
役に立った、もっと種類を増やしてほしい、と感じた方は、ぜひご自身のスクリプトをプルリクエストで送るか、対応してほしいサービスをissueに挙げてください。
次に追加するならElastic Kubernetes Serviceが有力候補で、その後はEC2やGoogle Compute Engine、さらに他のクラウドプロバイダーへと広げていきたいところです。
シンプルさの違い
シンプルさと柔軟性は、インフラ技術によって大きく異なります。
App Engine Standard EnvironmentとCloud Functionsの場合、スクリプトはdeployコマンド1つだけ。あとは既知のURLにアクセスするだけで完了です。一方、もう少し手間がかかるものもあります。たとえばCloud RunとECSはコンテナのビルドとプッシュが必要で、LambdaはさらにIAMロールも用意しなければなりません。
もっとも、こうした違いはさほど大きな問題ではありません。「Hello, World!」が動き出してしまえば、あとはスクリプトが複雑な部分を引き受けてくれます。
参考情報
「Hello, World!」までの手順については、各READMEからリンクしているQuickstartやGetting Startedの記事をご覧ください。