「JAWS-UG CLI専門支部 #171R S3基礎通知 (Lambdaの自動実行)」受講時の Cloud9 事前準備不足について調べた #jawsug_cli

jawsug-cli.connpass.com

過去、JAWS-UG CLI専門支部のハンズオンは、最後までオンタイムで完走することができていました。
今回は量が多いこともあり、途中でうまく行かないとついていけなくなり、最後までオンタイムで進めきることができませんでした。
なぜ失敗したかを探りたいと思います。

過去のハンズオン作業環境

今まで受けてきた CLI 専門支部のハンズオンは、macOS のターミナルで処理をしていました。
aws コマンドは公式資料を参考に Docker 上で起動して利用しております。

aliase aws='docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

多少苦労する点はありましたが、だいたい時間内に完走はできておりました。
CLI 専門支部のハンズオンで推奨されている Cloud9 環境との違いをまとめます。

aws cli version の違い

「CLI のバージョンは新しいほうがいいだろう」ということで、ローカル環境では v2 を利用しております。

$ aws --version
aws-cli/2.0.43 Python/3.7.3 Linux/5.4.39-linuxkit docker/x86_64.amzn.2

一方、CLI 専門支部は v1 での動作保証をしている状況です。
バージョンは違いますが、ここが問題になることは過去ありませんでした。

BSD と GNU の違い

macOS 標準のターミナルのコマンドは、基本 BSD の sed や awk です。
一方、CLI 専門支部のコマンドは Amazon Linux2 になるため GNU のコマンドです。
それぞれのコマンドオプションなど違う場合があり、BSD 版に読み替えて書き直す必要がありました。
ハンズオンでは、遅れないように急いで書き換えて、なんとかついていくようにしてました。

今回のハンズオン作業環境

Cloud9 との出会い

CLI 専門支部では、Cloud9 を利用した環境を前提としております。
別のハンズオンで Cloud9 を利用したことがあり、一度 Cloud9 を使ってみるととても便利でした。

「Cloud9 使えば、今までみたいな苦労はなくなり余裕でついていける！」と考えて、今回のハンズオンからは Cloud9 の利用に切り替えました。

事前確認

私は aws コマンドが正しく動くかの確認をいつも aws s3 ls で行っております。
S3 バケットを見ればどの AWS 契約につないでいるかわかるため、事故を起こさないために必ず最初にこのコマンドを叩きます。
ハンズオン環境で利用しているバケットが見えたので、接続先は問題ないと確認できました。

また、ハンズオンで利用しているユーザーは Admin 権限で作っております。
Admin であれば Role 設定をいちいちしなくても困らないだろうと考えました。

問題が発生した

IAM 権限がない

Cloud9 上で作業を進めていると以下のエラーが発生しました。

$ aws iam create-group \
>   --group-name ${IAM_GROUP_NAME}
An error occurred (InvalidClientTokenId) when calling the CreateGroup operation: The security token included in the request is invalid

「あれ？ IAM の作成権限が足りてない？」ということで、ローカルからコマンドを叩いて乗り切りました。

S3 バケットへアップロードができない

今回作業に使うユーザーは、ローカルからコマンドを叩いて API キーを取得しました。
この情報を Cloud9 上に配置しました。
新たに作成したユーザー権限で動作するから、これ以降は問題出ないだろうと思いました。

しかしながら、S3 へのアップロードでエラーが発生してしまいました。

$ ${FILE_SCRIPT}   ${ARGUMENT_1} ${ARGUMENT_2}
upload failed: local-handson-cli-s3/handson-cli-s3-notification.txt to s3://handson-cli-s3-notification-686609377265/sample/0.tmp An error occurred (InvalidAccessKeyId) when calling the PutObject operation: The AWS Access Key Id you provided does not exist in our records.

今回作成したユーザーには権限が足りているはずですが、S3 へのアップロードができません。

API キーの書き換えができない

では、ローカルでも利用している Admin 権限のキーを .aws に配置すれば何でもできるだろうと思い配置してみました。
しかしながら、ワーニングが発生したので強制的に書き換えることはやめました。

f:id:omron:20201114171527p:plain

何が原因だったか？

Cloud9 環境の作り方が問題だったんだろうと考えました。
再度 Cloud9 を作り直して権限を増やそうとしましたが、デフォルトで設定されているロールから変更することはできません。

f:id:omron:20201114171842p:plain

CLI 専門支部のハンズオンの Cloud9 と何が違うのか調べることにしました。

AWS CLI利用環境(Cloud9)の構築・利用・破棄(簡易版)

prototype-handson-cli.s3-website-ap-northeast-1.amazonaws.com

「『GUI は中学生まで』の波多野さんの資料なのに GUI のキャプチャーが大量にある！」
ということにびっくりしながら、これにならい Cloud9 環境を構築していきました。

「Cloud9 を起動している EC2 のロール権限が無い！」

1.2. EC2インスタンスへのIAMロールのアタッチ (handson-cloud9-env)

順に進めていき、この項目に来たときに気が付きました...
Cloud9 を起動している EC2 から cli を叩くときは、EC2 自身の IAM ロールにも影響を受けます。
EC2 に IAM ロールが足りていなかったため、Cloud9 環境から叩けるコマンドに制限があったようでした。

まとめ

Cloud9 も EC2 で動いているのでアタッチされているロールに依存する
- 権限がある API キーを利用しても制限を受けてしまう
ハンズオン環は手順に沿えば全く問題はない
- 違う環境でやるのは自己責任
  - 勉強になるので違う環境も基本は楽しい
  - しかし、ハンズオンの量が多いときには辛い

理由がわかれば単純なことでした。
Cloud9 自体はとても便利なので今後も活用したいと思います。