CloudShellをIaC実行基盤として考えてみる #omoshiro_cloudshell

re:Invent 2020で、待望のAWS CloudShellが発表されました。みなさん、使ってますか？

AWS CloudShell – AWS リソースへのコマンドラインアクセス | Amazon Web Services ブログ

「クラウドでシェルが動くんやで！」というわけで、色んな人達がその使いみちの探求に明け暮れているわけですが、そんな中、自分は、IaC（Infrastructure as Code）の実行基盤として、CloudShellがどこまで使えるのか、ちょっと考えてみたので、その内容をお届けします。

（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     これはもう祭りやな！！
　　　 |_|＿|
　　　 し'´Ｊ

あんた、年がら年中祭りやん。

そんなこんなで爆誕した「AWS CloudShell おもしろ選手権」

というわけで、おもむろにポジティブな Toriさん主催で開催された「AWS CloudShell おもしろ選手権」にLT参加してきたので、その様子をお届けします。

AWS CloudShell おもしろ選手権 - connpass

はっきり言って自分の発表にはいわゆるひとつのおもしろ要素は皆無で、そのへんのネタ枠はきっとその筋の人がすげぇのやるだろうなという感じで様子見にしました！

発表資料「CloudShellをIaC実行基盤として考える」

お品書きはこちら。

• IaC実行基盤ってなんやねん？
• IaC実行基盤の代表例とPros and Cons
• CloudShellはIaC実行基盤として使えるか？

IaC実行基盤ってなんやねん？

IaCとはざっくりいうと、インフラをコードで定義すること。代表的なIaCプラットフォームとして、以下がある。

• CloudFormation
• Terraform
• AWS Cloud Development Kit（AWS CDK）
• Pulumi

これらのコードは、アプリケーションコードと同じく、リポジトリに格納されバージョン管理されます。じゃ、IaC実行基盤とは、このインフラコードを実行する場所だとご認識ください。端的に言うと、下記のコマンドが実行される場所です。

• CloudFormation
  • create-stack
• Terraform
  • terraform plan
• AWS Cloud Development Kit（AWS CDK）
  • cdk deploy
• Pulumi
  • pulumi up

IaC実行基盤の代表例とPros and Cons

それでは、上記IaC実行基盤として、実際にAWS上でよく使われる場所と、それぞれのPros and Consを超主観で纏めた表がこちら。

理想形としては、リポジトリからCI/CD的なサムシングで自動的にインフラに適用するのが、リポジトリを唯一の正解として信頼できるソースとして管理できるのでよいのですが、実際にやるには運用フロー含めた見直しが必要なため、ハードルは高いです。各IaCプラットフォームとIaC実行基盤との相性もありますしね。

これらPros and Consがあるなかで、CloudShellを採用したときの感触を確かめてみます。

CloudShellはIaC実行基盤として使えるか？

以下の観点で考えてみましょう。

1. 実行権限
2. 料金
3. 実行ログ
4. IaC実行のための前準備

1. 実行権限

CloudShellはマネジメントコンソールアクセス時の実行権限をそのまま使うため、ユーザー管理をIAMに統一できます。これは、クライアントPCやEC2にSSHでアクセスしているときに比べて、管理上明らかにアドバンテージがありますね。

IAMロールを利用してマネジメントコンソールにアクセスしているときの、CloudShellでのaws sts get-caller-identityです。いつもの内容ですね。

[cloudshell-user@ip-10-0-43-201 ~]$ aws sts get-caller-identity
{
    "UserId": "AROAXXXXXXXXXXXXYYYYYYYY:cm-hamada.koji",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/cm-hamada.koji/cm-hamada.koji"
}

AWS SSOでアクセスしたときでも、問題なく割り当てられたポリシーを利用して、AWSリソースにアクセスできました。

2. 料金

There is no additional charge for AWS CloudShell. You only pay for other AWS resources you use with CloudShell to create and run your applications. Additionally, there are no minimum fees and no required upfront commitments. Data transfer is billed at standard AWS data transfer rates.
引用：AWS CloudShell Pricing | Browser-Based Shell | Amazon Web Services

完全に無料と明言されておりますな。やるぅ。EC2など確保するコンピューティングリソースのための料金が不要なのは素敵。

3. 実行ログ

ヒストリーは普通のLinuxマシンと同様に利用できます。下記に格納されています。

[cloudshell-user@ip-10-0-43-201 ~]$ cat $HISTFILE
ls
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
sudo yum install -y yum-utils
sudo yum -y install terraform
docker
sudo yum install -y docker
sudo systemctl start docker
curl -I https://download.docker.com/linux/static/stable/x86_64/docker-17.03.0-ce.tgz
curl -O https://download.docker.com/linux/static/stable/x86_64/docker-17.03.0-ce.tgz
ls

ただ、実際の標準出力の内容全てをマネージドで取得する機能は現在ありません。まぁCloudShellは中身はFargateな匂いがしているので、awslogsドライバからのCloudWatch Logsへのログ転送などもそのうち対応されるんじゃないでしょうか。

それ以外の、APIコールなどは、他のAWSのサービスと同じく、CloudTrailに格納されています。詳細はこちら。

Logging and monitoring in AWS CloudShell - AWS CloudShell

4. IaC実行のための前準備

とりあえず、自分が普段良く使っている、CloudFormationとTerraformの場合で纏めてみました。

CloudFormationの場合

IaCのコードの取得（from リポジトリ）は、大きく2つのやり方があるかと思います。

CodeCommitを使う場合は、AWSリソースなので、CloudShellにログインしたときのIAMの権限でそのままgit cloneすればOK.

GitHubなど、AWS以外のリポジトリを使う場合、CloudShellから都度認証させるのも面倒くさいですよね。自分は、GitHubプッシュ時に自動でS3コピーしておいて、CloudShellからaws s3 cpするのが早いかなと。

一点注意として、homeディレクトリは容量が1Gなのと、IaCコードはテンポラリなので、実際のIaCのコードを格納するのは、/tmp配下などの利用を推奨します。

CloudFormationの実行に関しては、CloudShellには、あらかじめaws cli v2やbashなどがインストールされているため、bashで動くシェルさえ用意しておけば、即実行可能です。一点、新サービス発表時などaws cliのバージョンが更新されたさい、CloudShellにどの程度のタイムラグでアップデートされるかわからないため、このあたり気になるようであれば、毎回aws cliもバージョンアップしたほうが良いでしょう。

Terraformの場合

IaCのコードの取得方法については、CloudFormationと同じ。

Terraformの実行ですが、公式のInstall Terraformが問題なく動いたので、このあたりをブートストラップ的なシェルにいれておくのが良さそうです。

tfstateに関してはローカルに格納するわけにもいかないので、対象AWSアカウントのS3バケットに格納するのが良いでしょう。

IaC実行環境のためにコンテナは利用できないのか？

いろいろ環境用意するのが面倒くさいので、CodeBuildのように専用のコンテナを用意しておきたい気持ちもありますが、現状、CloudShellでdockerはうまく動作しませんでした。そもそも、CloudShell自体がコンテナで動作しているためだと思われます。このあたり、突っ込みだすと沼に嵌りそうなので、一旦自分は静観しております。

結論：CloudShellはIaC実行基盤として使えるのか？

一部制限はありますが、割り切って使うには全然問題なさそうでした。

• 実行ログをきちんと残す仕組みを構築
• 実行権限や履歴をCloudTrailで管理する
• まずはステージングでやってみようね♡

参考サイト

日本語紹介ブログ

外観をつかむにはコレですな！

公式ページ

まずは、ここで概略を掴むのが早かったです。みんな大好きFAQもあるよ。

ユーザーガイド

細かい仕様は一通りこちらに書かれてます。気になるSecurity関連の記載も細かくあるので、使い込む際は目を通しておくことをオススメします。

実行基盤として

実際に、CloudShell上でSLSを試してみたブログ。実行基盤として使うときのストレージの制約など詳細に書かれているので、一読をオススメします。

なにはなくとも触ってみまっしょい！

AzureにもGCPにもはるか昔（詳細はしらないです、ごめんな）から実装されていたCloudShellが、ようやくAWSにもやってきました。まだ出来たてほやほやのサービスだけどできることは無限大なので、みなさんもどんどん運用環境で使いながら、その使い方のノウハウを貯めつつ、AWSに機能改善フィードバックしていけば良いんじゃないでしょうか。

それでは、今日はこのへんで。濱田（@hamako9999）でした。