はじめに 2021年10月にAWSクラウドプラクティショナーを受験し、無事に合格しました。 私自身クラウドに関する勉強を始めたばかりですので、同じようにこれから勉強を始めようとされている方の参考になれば幸いです。 クラウドプラクティショナーとは そもそもこの資格が一体何なのか、AWSの公式サイトでは以下のように説明されています。 この認定は、AWS クラウドに関する基本的な知識とスキルをお持ちの方を対象としており、AWS クラウドについての総合的な理解ができていることを証明する基礎レベルの認定資格です。出題範囲には、AWS の主なサービスや料金、サポートに関する内容を含みます。技術者だけでなく、マネージメントやマーケティング等、AWS に関わるすべての方に理解いただきたい内容です。 AWSの11個ある試験の中で入門編の資格です。各種サービスの概要など基礎的な内容の試験のため、業務未経験者や非エンジニアの方などにも広く受験されています。今からクラウドの勉強を始める方にちょうど良いレベルだと思います。 勉強教材 書籍 AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー(緑本) 模擬試験 この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問） 学習内容 １週間で合格することを目標とし、短期に集中して学習しました。平日は約2時間、休日は約4時間勉強しました。 まずは参考書を読み基礎知識を習得しました(約4日間)。ここは時間をかけず、大体の理解で良いと思います。どんなサービスがあってそれぞれどんな役割を持つのか、要点のみを押さえて読み進めました。 参考書を軽く一周した後はUdemyの模擬試験をひたすら解きました(約3日間)。ここでどれだけ問題を解くがが合格に向けてのポイントだと思います。模擬試験で間違った問題は参考書で正解をしっかり確認し、理解を深めました。私は基本レベル①,②と応用レベル①,②をそれぞれで8割以上とれるまで繰り返し解きました。 試験結果 合格ライン700点で、試験結果は720点とギリギリで合格することができました。 １週間の勉強期間でギリギリだったので、１ヶ月程度しっかり集中して勉強すれば、もっと余裕をもって合格できると思います。 体感的には実際の試験は模擬試験の基礎レベルよりも難しく、応用レベルより簡単という印象でした。模擬試験とほぼ同じような問題も多数出題されていました。 まとめ クラウドプラクティショナーはAWS認定資格の入門編です。これから勉強を始める方にちょうど良いレベルだと思います。 基本的に模擬試験中心で勉強することが合格への近道です。正答率が8割以上になるよう繰り返し解くことをおすすめします。

0. はじめに 題目の通り、2021年6月19日にソリューションアーキテクト-アソシエイトに1発合格しました。 4ヶ月前なのですが、記録を残しておこうと思ったため執筆することにしました。 というのも実は本日2021年10月9日、SOA-C02に合格しました。ということでこれから全ての合格体験記とともにこれから受験する方に情報を共有できたらと思ったのですよね。(SOAについては後日別記事にて...) スコアは777点！なんと縁起がいい！ 1. 受験動機、自分の経歴 私は今年で2年目のSEです。ほぼ無経験で入社し1年目からリモートワークだったためなかなか仕事を覚えるのも難しく苦労しています。 自分が参加しているプロジェクトのワークロードでAWSを使用していたため、興味を持ちました。1年目の当時はそもそもAWSとは何ぞやというところからでした。 2年目となり、SAAの受験対象者である実務経験1年が経ったのでそろそろ挑戦してみようと思い受験に踏み切りました。ちなみに自分の同期や近い先輩にはAWSの資格ホルダーはいなかったため、完全に独学です。同じような境遇の方に本記事が役立てば幸いです。 2. 学習期間 学習を始めたのは2021年の3月から。準備期間は約3ヶ月ですね。 1日あたり2時間ほど、平均して週4くらいの学習時間でした。なのでトータル100時間前後だと思います。 他の記事では1ヶ月の人もいれば1年の人もいますが、短期間でまとまった学習時間が取れるのであれば1ヶ月でも十分SAA突破は可能だと思います。 3. 学習方法 この記事を読んでいる方は必ずと言って良いほど見かけることでしょう。そう、Udemyです。SAAはこれだけやれば十分受かります。 3-0 公式トレーニングを受講する まずはこのeラーニングを行いましょう。 ここで突然ですが、実はこれ自分はやってません。しかし、やはり公式から得られる試験に関する情報なので最も確かな情報です。勉強のとっかかりやモチベーション向上の為には非常に有益な情報となるはずです。 SOA受験の際には私もSOA版のトレーニングを受講し大いに役立った為、本記事にも記載します。 3-1 試験突破講座 さあ、3-0でまず試験の概要を把握してから学習を開始しましょう。 教材として上記Udemyのコースを用いました。一通り全て行いました。 試験範囲の話などはこの講座でも知ることができます。 個人的にこの講座がお勧めできる理由として以下3点が挙げられます。 充実したハンズオン 最新アップデートに対応 セクション毎の練習問題 まずはハンズオンが充実している点です。試験問題を解くだけだと、原理だけわかっていてもイマイチ実際の操作感が掴めないので本当に問題を理解するのは難しいと思います。自分は業務でAWSを使用していましたがもちろん触ったことがないサービスがたくさんあるので、講座において実務経験不足を補ってくれるハンズオンはとても有難かったです。しかも、SOA受験に際してこの講座でハンズオンを復習することもありました。 次に、最新アップデートに対応している点です。AWSはリアルタイムに新機能がどんどん増えていく為、紙媒体の試験対策本にある説明が今は通じないものになっているということも少なくありません。この講座はAWSのアップデートに応じて講座の内容も更新してくれます。 最後に、各セクション毎に練習問題もついている為、復習もしやすい作りになっています。間違えた問題はどの講座で振り替えられるかも教えてくれます。 上記の理由から、この講座を受講するだけでかなり充実した学習時間を確保できると思います。 自分は動画を逐一とりながらノートを取るようにしました。(昔から書かないと覚えられないタチなんです...) コースの最後には模試が3回分あります。これらも全問解けるまで復習しました。 3-2 問題集 流石に自分は講義だけでは不安だったので、Udemyの模擬試験問題集を解きました。 6回分あり、繰り返し解くことができます。自分は2周しました。 難易度は実際の試験に対して高めだと思います。 参考までに自分の6回分のそれぞれ1回目のスコアはと言いますと... 90%, 58%, 53%, 53%, 60%, 60% はい、よく受かりましたよね。6回目だけは試験当日に早起きして本番の感覚で解いたのですが、結果を見たときには絶望しかけました。これでも本番で77%取れました。(実際はスケーリングスコアなのでこれが正答率というわけではないですが) 1~5回目までは本番前に復習を繰り返し、100%近くのスコアになるまで何度も解き直しました。 3-3 追加の学習 講座で習っていないことや問題集の解説でも理解できなかったAWSサービスに関しては、公式ドキュメントやサービス別資料を読みこみました。どちらも現在でも大変活用させていただいております。 Udemyの模試合わせて9回分でまだ不安な方はググればネットに問題集が転がっているので探して解くのもいいと思いますが、それよりも模試の問題を完璧に理解するまで学習することをオススメします。 4 試験当日 受験はピアソンVUEの自宅受験にて行いました。受験当時は一度落ちても無料で再試験できるということだったので(2021年10月9日現在はこの特典は終了していようです)、とりあえず気軽に受けてみました。 直前に受けた模試の点数は低かったものの、事前に難易度が実際より高いことは知っていたので、試験前は模試の復習を行いこれまでの自分を信じて試験に臨みました。 自宅での受験がどんな感じかというと、詳細は調べれば出てくると思うので割愛しますが、とりあえず要点だけまとめるとこんな感じでした。 試験監督が名前からすると中国(?)の方だったが日本語のやりとりは問題なし 試験監督とのやりとりは全てチャットで行える（マイクで喋ってもチャットで反応が来る） 部屋の周りをカメラで映す必要がある為部屋は見られても恥ずかしくないようにしておく 自宅といえどいい環境で受験した方が集中力も増すので当日の朝は部屋の掃除を行いました。 30分前には試験ツールを立ち上げて着席するようにしました。 試験中はWebカメラがONなので見られている始めは感じが少し気になりましたが試験が始まればそんなことは気になりませんでした。 5 試験を終えて 試験の準備にあたり事前に他の方の合格体験記を読みましたが、かなり色々な種類の教材を使用して試験に臨む方が多い印象でした。自分は問題の量を解くより問題を一つ一つ理解し、周辺の知識も取り込んでいきそのサービスへの理解を深めていくことの方が重要だと思った為、問題集はUdemy1本で試験に臨みました。もちろん問題の量はもっと欲しいという気持ちはありましたが、復習の大事さも捨てられません。このあたりは個人の判断になるかなと思います。とりあえず実際合格できましたし、自分の選択は間違っていなかったと思います。 反省点としては、問題集の6回目の模試はわざわざ当日にやらず復習の時間をもっと確保する為早くにやるべきでした。 試験を終えて、何より、学習を通してぼんやりとしか把握できていなかった普段の業務でのAWSの利用についても理解が深まり、AWSを使うのがより好きになれたことがとても大きかったです。あとは貰えるデジタルバッジがかっこいい...! 目標はAWSの資格コンプリートです。まだまだ遠い道のりで始まったばかりですが、有言実行目指して頑張ります！

はじめに AWS認定ソリューションアーキテクトアソシエイト試験に一発で合格することができました。 学習に使った教材や記事などをまとめてみました。 ほとんどUdemyの講座ですが。 試験概要はこちらの公式サイトからどうぞ。 受験を考えている方は試験ガイドを読んでおくと良いと思います。 こちらの前にクラウドプラクティショナー試験を取得してから受験しています。その学習方法はこちら。 合格までにしたこと & 学習時間 学習期間 2021年8月1日 ~ 2021年10月8日 学習時間 1日 1~3時間 学習内容 Udemy試験突破講座 2周（2倍速） Udemy模擬試験問題集 4周 Udemy短期突破講座 3周（2倍速） その他 学習のポイント 分からない内容や問題はとりあえず言葉や答えだけ覚えてとにかく先へ進む 毎日学習する 間違えた問題はその日すぐに復習する Udemyのいいところは、スマホアプリで講座をダウンロードできるところにあります。 ダウンロードしておけば、スマホで通勤中などにも学習できてよいです。 いろんな教材に手をつけずに、とにかくUdemyの教材をひたすらやり続けることが結果的に良かったかなと思っています。 クラウドプラクティナーに比べたらAWSサービスの範囲は狭いですが、深く学習する必要がありました。 覚える問題に加え、考える問題も増えた印象です。 Udemy試験突破講座 こちらの講座を購入しました。 実際に手を動かしながら、楽しく学ぶことができます。 講座を購入すると、講座で使用しているスライドをすべてPDFでダウンロードすることができるため、空き時間の学習にも困りません。 これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） Udemy模擬試験問題集 こちらの模試を購入しました。 直前の1ヶ月は毎日模試の問題を解き続けました。 最初は点数50%くらいしか取れませんでしたが、最終的には6回とも正答率80-90%くらいになっていました。（答えを覚えてしまっている感は否めませんでしたが…） 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） Udemy短期突破講座 試験2週間前に購入しました。 ハンズオンなしで、完全に試験対策に特化した講座です。 模擬試験問題集よりも全体的に難易度が高かったため、これを実施することで自信がつきました。本番で出題された問題を考えると点数も上乗せされたと感じます。 総復習という意味でも知識を定着させるために役立ちました。 AWS認定ソリューションアーキテクト アソシエイト試験：短期突破講座（300問の演習問題） その他 その他学習に使用した教材です。 AWS認定試験【ソリューションアーキテクトアソシエイト試験対策】 YouTube無料で100問以上の問題と、その解説が視聴できるためスキマ時間にちょうどよいです。 CloudTech 有料AWS学習オンラインスクールですが、無料会員登録するだけで200問の問題を無料で解くことができます。 おわりに 自分は学習にNotionというツールを使用してまとめていました。 お気に入りのツールを使用して学習すると、モチベーション維持にいいんですよね。 資格を取ったから仕事ができるようになるというわけではないとは思いますが、「知識の証明」だけでなく「意欲の証明」にもなるし、職場の士気も上がることを考えると学習が苦でないなら取っておいて損はないと自分は思いました。 受験を考えている方の参考になれば幸いです。

はじめに DVA 取得と、デプロイについての知識とそれを含めた開発スキルのレベルアップのために色々とやっているのでそれの途中経過をアウトプット。 前提として以下の記事の話があります。 React と DRF の SPA で JWT を Cookieで管理してみた話 もくもく会アウトプット:Django で JWT を Cookie で処理するやつを理解したい やったこと フロント側(React)を CodePipeline・CodeBuild・Route53・CroudFront・S3 の構成でデプロイ サーバー側(DRF)を EC2 インスタンス 1 台を使ってデプロイ 上記を Https でやり取りするようにして連携 ひとまず今回は Code シリーズを使った S3 静的 Web ホスティングでの React デプロイと同時にクロスオリジンでの SPA デプロイの体験を行うというのがテーマなので最小限の構成です。 サーバー側も Code シリーズや ElasticBeanStalk などを使ってやろうとしたのですが、フロントと比べると数倍は難しかったのでまずは 1 番基本的なデプロイを試してみて何をする必要があるのかを把握することに重きを置きました。 以下今回のサービス構成図です。 前述の通り、サーバー側は DB も証明書も EC2 インスタンス内においてあります。 当然あまりよろしくはないので、今後リファクタリングを進めたり実際に一定期間デプロイすることを考えるとプライベートサブネットを作って踏み台 Web サーバーを作り、インスタンスはプライベートサブネットに移して、AutoScaling グループにしてさらにそれを ALB で管理することになると思いますし、それに従って証明書は ALB で管理し、DB は RDS 等を用いることになると思います。 ただそうなると個人でやるには割とコストかかるなぁ……と感じますね、やはりインフラは重い…… 要点 ネットをうまく探せば大まかなところは見つかるので、見つけられなかったところとか分かりづらいところを載せておきます。 自動化ツールを使う場合、.env は基本的にはリソースに含まれないはずなので AWS System Manager の Parameter Store や CodeBuild の環境変数設定画面を用いて環境変数を設定する 上記で設定した環境変数を buildspec.yml などを使って、ビルドする際に.env として書き出す SPA、つまるところクロスオリジンにする場合、ローカルと違ってフロントからサーバーへの Request も Https で行わないと blocked mixed-content エラーになる よって独自ドメインはフロントとサーバーの 2 つで必要となり、サーバー側の独自ドメインは ElasticIP とで名前解決の紐付けを行う サーバーが Django の場合、SameSite 周りの設定が settigs.py 経由だとうまく行かない場合がある 同様に、if settings.DEBUGが本番環境だと動作しないことがある よって、開発環境でif settings.DEBUGで SameSite の設定を変えていた Middleware をsamesite='None'及びsecure=Trueで固定するように変更する 上記の点さえ把握してれば、あとはネットの海を漁れば以降のことは見なくてもできると思います。 今回は React、Django(DRF)でやってますが多分どの言語でもやることはだいたい同じだと思うので参考になれば幸いです。 フロント側 【AWS】S3+CloudFront+Route53+ACM で SSL 化(https)した静的 Web サイトを公開する React で作った Web アプリを GitHub で管理して S3 に自動デプロイする [CodeBuild]buildspec.yml での環境変数指定方法あれこれまとめ React+Django+AWS でペットの成長をサポートするアプリを開発したので Tips をまとめた 上記サイトを参考にさせていただいてなんとかなりました。 特に下 2 つのサイトのおかげで.env をビルドの自動化のときにどう作ればいいのかというところを解決できたので本当に助かりました。 以下手順をセクションごとに。 準備 リポジトリの用意(今回は Github) ASM で環境変数の定義 buildspec.yml の作成 独自ドメインの取得(今回は freenom) なお ASM の ParameterStore は KMS を使って暗号化することもできる。 buildspec.yml は CodeBuild で使う、Build の手順書みたいなもの。 version: 0.2 env: # 　ASMで作成した環境変数の指定 parameter-store: buildspec.yml内での呼び出し方:ASM設定した環境変数のKey名(ex.REACT_APP_API_URL:https://localhost:8000の場合はREACT_APP_API_URL) key: "REACT_APP_API_URL" phases: install: runtime-versions: nodejs: 14 pre_build: commands: - if [ -e /tmp/node_modules.tar ]; then tar xf /tmp/node_modules.tar; fi - npm install build: commands: #コマンドの実行結果としてBuild Sequence……を出力する - echo "Build Sequence……" # .envを作成して、そこにREACT_APP_API_URL:https://localhost:8000を定義して出力する - echo "REACT_APP_API_URL=$key" >> .env - npm run build post_build: commands: - tar cf /tmp/node_modules.tar node_modules artifacts: files: - '**/*' base-directory: build cache: paths: - /tmp/node_modules.tar phase 部分が実際のビルド時の動作についての指示。 ビルド前、ビルド中、ビルド後とそれぞれコマンドを設定できる。 作った buildspec.yml はプロジェクトルートにおいてリポジトリへ push しておく。 S3 バケットの作成 静的 Web ホスティングができるような設定で作成しておく。 不慣れであるなら、この段階ではバケットポリシーはパブリック読み取りアクセスを許可しておき、ブロックパブリックアクセスもオフにしておくと後でデプロイがうまく行っているか確認ができる。 CodePipeline と CodeBuild、CodeDeploy の設定 CodePipeline からパイプラインを作成するとそのまま一連の設定ができる。 CodeCommit にあたる部分はソースプロパイダで CodeCommit 他用意したリポジトリを設定する。(今回は Github) すると連携してくれと言われるので画面の通り進めていってリポジトリとビルドに使うブランチを指定する。 CodeBuild プロジェクトを作成するからビルドプロジェクトを作成する、CodeBuild で既に作ってあるならばそれを指定。 また環境変数はここでも設定できる。 するとこんな感じでビルドに使うマシンの設定になるので OS を選んで任意の設定をする。 特に指定等なければ最新のイメージ、最新のバージョンを選択しておく。 CodeDeploy 任意のデプロイ先を選択、今回は S3 を選択して、作ったバケットを選択する。 これでデプロイが始まる。 デプロイできたかの確認はこの段階であれば静的 Web ホスティングの設定画面にあるバケットウェブサイトエンドポイントの URL を叩いてみるとわかる。 サイトが表示されれば OK。 CloudFront コンテンツ配信ではこれを使うと便利なので S3 とは基本的にセットで使っていくことが多い。 CDN としての役割の他に証明書を持たせて SSL での通信も行えるようにすることもできる。 この段階ではディストリビューションを作るだけ。 OAI を使ったアクセスにすることでバケットへの直接アクセスを避け、必ず CloudFront を経由したアクセスになる。 今回は S3 は静的 Web ホスティング用途で使っているだけで、インターネットからバケットにアクセスしてデータをどうのこうのとはしないので、なので AWS が作ってくれた OAI に基づいたバケットポリシーで問題ない。 Route53 と Certificate Manager ここで SSL 通信を行うための設定を行う。 用意した独自ドメインを使って、ホストゾーンを作る。 できたホストゾーンの NS レコードの値をすべてドメインの取得先の DNS 設定(freenom だと NameServer)で登録する。 Certificate Manager では取得したドメインに対して SSL 証明書を作成する。 手順は以下の通り。 パブリック証明書のリクエストを行い、先程取得したドメイン名または*.ドメイン名の形式で登録する。 証明書をリクエストできたら、証明書の画面に行き CNAME レコードを作成。作成手順は以下の 2 種 A. DNS 設定ファイルをエクスポートして Route53 から任意のホストゾーンでその設定ファイルの値に基づいて作成 B. 証明書の画面からドメイン欄をクリックすると Route53 でのレコードを作成というボタンが出るのでそこから作成 CNAME レコードが作成されてしばらくすると証明書が検証実行中のステータスから発行済になるのでそうなったら完了。 CloudFront に戻り、以下の設定を行う。 代替ドメイン名の欄には取得したドメインを登録する。 SSL 証明書を作る際に*.ドメイン名と設定しておくと、画像の様にサブドメインも設定できる。 ここで気をつけておかないといけないことは必ずデフォルトルートオブジェクトオプションに index.html を指定しておくこと、でないと 403 エラーになる。 しかし、実は SPA でwindow.loactionを使ったページ遷移をしている場合これを設定しても 403 になる。 なのでその場合は CloudFront で公開した SPA でページ遷移を行う時に、４０３エラーが返ってくる時の対処法 以上を参考に設定をしておく。 ここまで終わったら Route53 で A レコードを代替ドメイン名欄で指定した値を CloudFront のディストリビューションのエイリアスと紐つけて作成すればフロント側は完了。 サーバー側 EC2 インスタンス起動 冒頭に書いた通り、今回は API サーバー 1 台だけなので普通にインスタンスを起動します。 OS は Ubuntu の方がスムーズに行くかと思います。(特に postgres 周りのインストールは LinuxOS だと躓くポイントがいくつかある) インスタンスを起動したら 任意のクライアントでキーペアを使って SSL 接続でインスタンスに接続(AWS コンソール上でもできるはず) sudo apt-get updateでアップデート、Linux とかだとここはsudo suしてからyum update -yとかだと思います。 必要なものをインストール 今回インストールしたのは以下の通り。 sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx python3-venv DB の設定 インストールが終わったら DB の設定を行います。 今回は Postgres なので以下の通り。 # postgres起動 sudo -u postgres psql # DB名は任意 CREATE DATABASE ~; # USER名、PASSWORDは任意 CREATE USER ~ WITH PASSWORD '~' # 初期設定 ALTER ROLE ~ SET client_encoding TO 'utf8'; ALTER ROLE ~ SET default_transaction_isolation TO 'read committed'; ALTER ROLE ~ SET timezone TO 'UTC+9'; # 作ったUSERに作成したDBの権限をすべて付与。 GRANT ALL PRIVILEGES ON DATABASE ~db TO jira; # uuidが使えるようにしておく CREATE EXTENSION "uuid-ossp"; 仮想環境の作成 Python は 3 以降から venv で仮想環境を構築することが推奨されているのでそれで行う。 # 仮想環境作成 python3 -m venv 仮想環境名 # 仮想環境をアクティブ source 仮想環境名/bin/activate # ちなみに無効化は以下 deactive Django のセットアップ sudo -H pip3 install --upgrade pipで pip のインストール 仮想環境に入ってgit cloneでリポジトリをクローンする nano .envで環境変数を作成 pip install -r requirements.txtで依存関係すべてインストール 予め、pip freeze > requirements.txtを Django のプロジェクトルート(通常であれば manage.py があるルート)で実行して書き出したものを push したリポジトリを用意しておくと楽。 .env 部分は SECRET_KEY= ~ DEBUG=False DATABASE_URL=postgres://ユーザー名:パスワード@localhost:/DB名 ALLOWED_HOSTS=EC2インスタンスのElasticIP,サーバー側に用意した独自ドメイン と定義して作成。 また settings.py 部分はdjango-environを使って env = environ.Env() env.read_env(os.path.join(BASE_DIR, '.env')) SECRET_KEY = env('SECRET_KEY') DEBUG = env('DEBUG') ALLOWED_HOSTS = env.list('ALLOWED_HOSTS') # django-cors-headers3.4.0の場合 CORS_ORIGIN_WHITELIST = [ "http://localhost:3000", "http://localhost:3000", "https://127.0.0.1:3000", "https://127.0.0.1:3000", "http://localhost:8000", "http://127.0.0.1:8000", "https://サーバー側の独自ドメイン" ] # django-cors-headers3.5.0の場合 # CORS_ALLOWED_ORIGINS = [ # "http://localhost:3000" # ] CSRF_TRUSTED_ORIGINS = ['localhost:3000', '127.0.0.1', 'サーバー側の独自ドメイン'] SESSION_COOKIE_SAMESITE = 'None' SESSION_COOKIE_SECURE = True といったようにしておく、あとから Route53 の設定をしたあとにやってもよし。 また Middleware も開発時には以下のように DEBUG を見て samesite 周りの変更を行っていたところを class SameSiteMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): response = self.get_response(request) from config import settings for key in response.cookies.keys(): response.cookies[key]['samesite'] = 'Lax' if settings.DEBUG else 'None' response.cookies[key]['secure'] = not settings.DEBUG return response このように常にsamesite='none'かつsecure=Trueにするようにしておく。 class SameSiteMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): response = self.get_response(request) from config import settings for key in response.cookies.keys(): response.cookies[key]['samesite'] = 'None' response.cookies[key]['secure'] = True return response if settings.DEBUGがうまく動作しない問題は [Django]settings に DEBUG=True を定義してても、テスト実行すると DEBUG=False になってしまう罠 上記のような記事でも報告されてたりする、Django はこうイマイチそこでトラブル起きる？ってところで詰まることが多い気がする。 そもそも settings.py で指定してるのでそれで動いて欲しいものなのだけども…… 閑話休題、.env ファイルの作成以外の変更は予めリポジトリを作成するときに一緒にやってしまっても構わないと思う。 nano エディタで変更するのはつかれるので。 あとは python3 manage.py migrate python3 manage.py collectstatic python3 manage.py createsuperuser とやっていく。 DB 周りの設定をやっていない migrate でエラーが出るので先に済ましたということになる。 ネットワークの設定 Route53 フロント同じ要領でサーバー側の独自ドメインの設定を行う。 ALB を使うと証明書もここで解決できるはずだが、今回はパス。 Gunicorn sudo nano /etc/systemd/system/gunicorn.service ファイルは以下の通り。 [Unit] Description=gunicorn daemon After=network.target [Service] User=ubuntu Group=www-data WorkingDirectory=/home/ubuntu/jira_api ExecStart=/home/ubuntu/仮想環境名/bin/gunicorn --access-logfile - --workers 3 --bind unix:/home/ubuntu/プロジェクトフォルダ名(以下A)/config(wsgiが入っているフォルダ名).sock config.wsgi:application [Install] WantedBy=multi-user.target ここで気をつけないと行けない部分はプロジェクトフォルダ名と wsgi が入っているフォルダ名の部分。 リポジトリから Clone した場合、リポジトリ名がプロジェクトフォルダ名にあたることになるはずである。 いずれにせよ、プロジェクトのルートディレクトリになるフォルダ名を指定すること。 wsgi が入っているフォルダ名はdjango-admin startproject mysiteで作成したフォルダ、つまり特に弄ってなければ settings.py が入っているフォルダになる。 そのフォルダに wsgi も一緒に入っているのでそのフォルダ名を指定すること。 このあたりは個々人で違ってくると思う部分なのに間違えると通信できなくなるので注意、この辺の関係が解説によってまばらだったりしたのでかなり沼りました。 nginx の設定 sudo nano /etc/nginx/sites-available/jira_api 一先ずは以下の通りにする。 server { listen 80; server_name サーバー側の独自ドメイン名; location = /favicon.ico {access_log off; log_not_found off;} location /static/ { root /home/ubuntu/Djangoのstaticフォルダがあるルート; } location / { include proxy_params; proxy_pass http://unix:/home/ubuntu/プロジェクトフォルダ名/wsgiがあるフォルダ名.sock; } } ポート番号を見ればわかるが Http 通信を行うための基本的なテンプレートのようなものらしい。 設定したらsudo ln -s /etc/nginx/sites-available/jira_api /etc/nginx/sites-enabled/でエイリアスを作っておく。 あとはsudo ufw allow 'Nginx Full'。 SSL 通信を可能にする ここまでしたら一応 Gunicorn と nginx を再起動する。 sudo systemctl restart gunicorn sudo systemctl enable gunicorn sudo systemctl restart nginx きちんとデプロイできて、ここまでの設定がうまくいっていれば、ElasticIP/admin で URL で叩けば Django の管理ページが出るはずである。 しかし、このままだと SSL(Https)通信ができないのでそのための設定を行う。 今回は EC2 内部で発行管理するので Certbot で試してみる。 Certbot 参考: EC2 上の Django アプリを独自ドメイン、SSL 対応する 参考記事中の DNS の設定は Route53 で A レコードを同じ要領で作成すればよし。 Certbot の指示通り導入を行って、sudo certbot --nginx行い、さらに指示に従ってうまく作成できればsudo nano /etc/nginx/sites-available/jira_apiで作成したファイルが server { server_name サーバー側の独自ドメイン名; location = /favicon.ico {access_log off; log_not_found off;} location /static/ { root /home/ubuntu/Djangoのstaticフォルダがあるルート; } location / { include proxy_params; proxy_pass http://unix:/home/ubuntu/プロジェクトフォルダ名/wsgiがあるフォルダ名.sock; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/challengejiradjango.tk/fullchain.pem; # manage> ssl_certificate_key /etc/letsencrypt/live/challengejiradjango.tk/privkey.pem; # mana> include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } server { if ($host = サーバー側の独自ドメイン名) { return 301 https://$host$request_uri; } # managed by Certbot listen 80; server_name サーバー側の独自ドメイン名; return 404; # managed by Certbot } 以上のような形に変更され、SSL 通信が可能となっているはずである。 あとはセキュリティグループで Http、SSL、HTTPS を許可しているか確認をし、再度 nginx→gunicorn の順でリセットを行えば全行程が終了、お疲れ様でした。 ちなみに、Nginx でエラーが出ている場合はsudo tail -f /var/log/nginx/error.logでログを確認してみる。 最後に リファクタリングの余地はかなりあるが、これでクロスオリジン前提での React(というか JS フレームワーク)と Django(DRF)のデプロイをするためには最低限何をすればいいのかということが把握できた。 主にリファクタリングの余地はサーバー側にたくさんあるはずで、いま思いつく限りでも デプロイの自動化 EC2 ではなく、ALB を使った SSL 証明書の管理と SSL 通信 サブネットを分けて踏み台サーバーを作る AutoScaling を導入し、マルチ AZ にする DB は RDS にする などがある。 ただ今回やったサーバー側の処理はおそらく API GateWay と Lambda で置き換えることができて、しかもその方が都合が良さそうだなとは感じた。 Django 側で複雑なデータ処理を行う……という工程があればまた別なのかもしれないけども、その場合でも FastAPI の方が適していそうな気がするし、プログラミングの世界は本当に終わりがないんだなということをしみじみと感じました。 もし今回の記事で間違っているところや補足の解説、ベストプラクティスやリファクタリング案などあればぜひ教えて頂けると嬉しいです。 とりあえずは、DVA 取得に向けて頑張ろうと思います。

背景 Nuxt.jsをAmplify CLIでデプロイして外部オリジンのAPIをPOSTしようとしていた。 amplify cliでのデプロイにはManaged Hosting(amplifyhosting)を採用していた。 また、CORS対策のために、以下のようにproxy設定をしていて、ローカルでは問題なく動いていた。 nuxt.config.js const backendBaseUrl = process.env.BACKEND_BASE_URL || 'http://localhost:3003' export default { ... axios: { baseURL: backendBaseUrl, proxy: true, prefix: '/api', credentials: true, }, proxy: { '/api/': { target: backendBaseUrl, pathRewrite: { '^/api/': '' }, changeOrigin: true, } }, ... } 現象 proxy経由で外部APIに対してPOSTを叩くと、status code 405(MethodNotAllowed)のエラーが発生した どうやらcloudfrontがPOSTを拒否しているみたい 解決策 自分の場合は、特定のパスに対して、書き換えてリダイレクトすることでPOSTが成功した [ { "source": "/api/<*>", "target": "(Your API URL)/<*>", "status": "200", "condition": null } ] こちらの設定はAmplify consoleの「書き換えて、リダイレクト」から設定することができる 「編集」を押す 「テキストエディタを開く」を押す ここでsourceとtargetを設定してあげる 保存してからPOSTを叩き直すと成功した 参考

【AWS CloudFormation (Infrastructure as Code)】 今回のSprintでCloudFormationをきっちり理解する！ CloudFormationとは。 EC2やELBのなどのAWSリソースの環境構構築をテンプレートを元に自動化できるサービス テンプレートを自由に作成できるため、自分好みのシステム構成を自動的に構築可能 テンプレートに作成するAWSリソースの定義をYAMLで記述（JSONも可） CloudFormationの利用料は無料 (プロビジョニングされたAWSリソース分の料金は当然ながら発生する) CloudFormationの基本機能 作成 テンプレートに定義された構成でスタックを自動作成 並列でリソースを作成 依存関係がある場合は自動的に解決してくれる 変更 スタックに前回のテンプレートとの差分を適用（幕等性） リソース変更時は無停止変更、再起動、再作成のいずれかが発生 Change Setを作ることで差分の内容を事前に確認可能 削除 依存関係を解決しつつリソースを全て削除 データストアはスナップショット取得と保持が可能 （手動でおこなった変更は管理外） CloudFormationを使った構成管理の流れ YAMLでテンプレートを記述 ローカル環境のファイルをAWSマネジメントコンソールやS3バケット経由でアプロード AWSマネジメントコンソールやAWS CLI、スタックセットを利用してスタック（AWSリソースの集合体）を作成 リソースの作成と管理 CloudFormation　テンプレート AWS CloudFormationの心臓部 スタックの設計図 AWSリソースの依存関係は自動判別してくれる テンプレートの要素 AWSTemplateFormat.yml # AWS CloudFormationテンプレートバージョン AWSTemplateFormatVersion: "version date" # テンプレートの説明文 Description: String # テンプレートに関する追加情報 Metadata: template metadata # 実行時(スタック作成、更新)にユーザ入力を求めるパラメータ(キーペア名やDBのユーザ名など) Parameters: set of parameters # キーと値のマッピング（条件パラメータ値の指定に使用） Mappings: set of mappings # 条件名と条件判断内容（Resourcesセクションなどでリソース作成時に利用） Conditions: set of conditions # サーバーレスアプリケーションや定型コンテンツ（挿入等のための、マクロを指定） Transform: set of transforms # 必須!! # 起動するリソースのタイプやプロパティを指定（スタックを構成するリソースとプロパティ） Resources: set of resources # スタック構築後に表示·取得した値や他スタックとの連携のための出力を指定（CloudFormationから出力） Outputs: set of outputs スタック スタック単位でリソースの管理が可能 削除を実行すると、スタックに紐づくリソースが削除される 使用するリソースおよびリソースの構築順は、テンプレートの依存関係から自動的に決定 Change　Setでスタックの変更内容を事前確認しデプロイ可能 変更要求した箇所とその変更いより影響を受ける箇所を事前確認 変更によってリソースが中断されたり再作成されたりすることに注意 StackSets：一回の操作で複数のアカウントやリージョンヘスタックを作成、更新、削除できる ライフサイクル別のスタック - フロントエンドリソース：　 - インスタンス、Auto Scalingグループ - ステートフルなリソース：　 - DB、クラスター、キュー - バックエンドサービス：　 - API エンドポイント、Lambda関数 - 監視リソース：　 - アラーム、ダッシュボード - ネットワーク：　 - VPC、NATゲートウェイ、VPN、サブネット - セキュリティ：　 - IAMユーザー、グループ、ポリシー スタックをレイヤーとライフサイクルで分割 スタックを環境ごと（dev, stg, prdなど）に再利用 規模が大きくなると単一のテンプレートでの管理は手間と時間がかかる 変更時の影響範囲も大きくなるため、スタックを分割しよう 設計観点 依存関係 VPC→SG+IAM→アプリケーションが基本となる ライフサイクル 更新頻度と寿命 通常VPCやIAMなど依存される側のリソースは更新頻度が少なく寿命が長い アプリケーションは高頻度に更新があり、短命であることが多い ステートレス・ステートフル ステートレスなリソースとステートフルなリソースを分割 所有権 更新に責任を持てっいるチーム毎に分割 これらをもとにして、実装　→　Cross Stack Reference インフラ全体のスタック分割 【上：依存する側、短命かつ高頻度　　　下：依存される側、長寿かつ低頻度】 - アプリケーションレイヤー - アプリケーションリソース - システムが直接利用するリソースを配置 - アプリケーションだけではなく、共有サービス（Directoryなど）も依存関係上で含まれる - リソースの例 - EC2, RDS, ELB, SQSキュー, Active Directory, CI/CDサーバ - セキュリティレイヤー - ネットワークリソースのうちSGはネットワークの存在を前提とするのでこのレイヤー - IAMは事実上依存性のないリソースだが、分類上このレイヤー - リソースの例 - SG, IAMロール, IAMグループ, IAMポリシー - ネットワークレイヤー - ネットワークリソースは最も依存性が低いリソース - インフラ環境の「地面」に相当する - 外部のリソースの存在を前提としない。 - リソースの例 - VPC, サブネット, エンドポイント, ルートテーブル,Route53,IGW, NATGW, VGW アプリケーションレイヤ内部のスタック分割（インフラ全体の中のうち） 【上：依存する側、短命かつ高頻度　　　下：依存される側、長寿かつ低頻度】 - アプリケーション（アプリケーションリソース） - アプリケーションコードを直接実行するものを配置 - またはリクエストをルーティングするものを配置 - ステートレス - リソースの例 - EC2, ECS, ELB, AutoScaling, API Gateway - データ - DBやキャッシュ、キューなどのアプリケーションのリソースのうちステートフルのリソースを配置 - リソースの例 - S3, RDS, Redshift, ElastiCache, SQS, EC2(データを保持するもの) - シェアードサービス - アプリケーションから共通で利用されるサービスを配置 - Active Directoryのような認証サーバ - プロキシサーバー - メールリレーサーバー - CI/CDサーバー - リソースの例 - Directory Service, EC2(共通サービス), Codeシリーズ, SES, Route53 今後 新たに追記予定。 実務の中で学んだことを書き足していけたらなと。 参考 【AWS Black Belt Online Seminar】AWS CloudFormation ありがとうございましたm(_ _)m

LocalStackを用いて、DynamoDBにデータ登録を行うAPIをAPI Gateway + Lambdaで作成する方法についてメモする。 LocalStack 準備 こちらの手順でDocker LocalStack環境を準備しておく。 Dynamo DB 準備 テーブル(sample-table)作成 aws dynamodb create-table --table-name sample-table --attribute-definitions AttributeName=Data,AttributeType=S --key-schema AttributeName=Data,KeyType=HASH --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1 --endpoint-url=http://localhost:4569 --profile localstack { "TableDescription": { "AttributeDefinitions": [ { "AttributeName": "Data", "AttributeType": "S" } ], "TableName": "sample-table", "KeySchema": [ { "AttributeName": "Data", "KeyType": "HASH" } ], "TableStatus": "ACTIVE", "CreationDateTime": "2021-10-09T14:55:59.763000+09:00", "ProvisionedThroughput": { "LastIncreaseDateTime": "1970-01-01T09:00:00+09:00", "LastDecreaseDateTime": "1970-01-01T09:00:00+09:00", "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 1, "WriteCapacityUnits": 1 }, "TableSizeBytes": 0, "ItemCount": 0, "TableArn": "arn:aws:dynamodb:ddblocal:000000000000:table/sample-table" } } 動作確認(データ登録) aws dynamodb put-item --table-name sample-table --item={\"Data\":{\"S\":\"fuga\"}} --endpoint-url=http://localhost:4569 --profile localstack 登録データ確認 aws dynamodb scan --table-name sample-table --endpoint-url=http://localhost:4569 --profile localstack { "Items": [ { "Data": { "S": "fuga" } } ], "Count": 1, "ScannedCount": 1, "ConsumedCapacity": null } API Gateway 準備 REST API を作成する リソースID(id)を控える aws apigateway create-rest-api --name 'LambdaDynamoDBTestAPI' --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "id": "0157166521", "name": "'LambdaDynamoDBTestAPI'", "createdDate": "2021-10-09T06:01:05.462000+00:00" } ルートリソースID(以下id)取得 aws apigateway get-resources --rest-api-id 0157166521 --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "items": [ { "id": "4739445932", "path": "/", "resourceMethods": { "GET": {} } } ] } 子リソース追加 パス名：lambda_dynamodb_test リソースID(以下id)を控える。 aws apigateway create-resource --rest-api-id 0157166521 --parent-id 4739445932 --path-part lambda_dynamodb_test --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "id": "A-Z13318A-Z712", "parentId": "4739445932", "pathPart": "lambda_dynamodb_test", "path": "/lambda_dynamodb_test", "resourceMethods": { "GET": {} } } HTTP POSTメソッド追加 aws apigateway put-method --rest-api-id 0157166521 --resource-id A-Z13318A-Z712 --http-method POST --authorization-type "NONE" --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "httpMethod": "POST", "authorizationType": "NONE" } Lambda 準備 lambda_dynamodb_put_test.py DynamoDBテーブルsample-tableにデータを登録する。 import boto3 from boto3.session import Session from datetime import datetime session = Session(aws_access_key_id='dummy', aws_secret_access_key='dummy', region_name='ap-northeast-1' ) dynamodb = session.resource( service_name='dynamodb', endpoint_url='http://localhost:4569' ) def lambda_handler(event, context): table = dynamodb.Table('sample-table') data = 'sample_' + datetime.now().strftime('%Y-%m-%d-%H-%M-%S') response = table.put_item( Item={ 'Data': data } ) return response 上記ファイルをlambda_dynamodb_put_test.zipにzip化する。 アップロード aws lambda create-function --function-name="lambda-dynamodb-put" --runtime=python3.8 --role="arn:aws:iam::123456789012:role/service-role/lambda-sample-role" --handler=lambda_dynamodb_put_test.lambda_handler --zip-file fileb://lambda_dynamodb_put_test.zip --endpoint-url=http://localhost:4574 --profile=localstack 起動 aws lambda invoke --cli-binary-format raw-in-base64-out --function-name lambda-dynamodb-put result.log --endpoint-url=http://localhost:4574 --profile=localstack {"StatusCode": 200} 動作確認 aws dynamodb scan --table-name sample-table --endpoint-url=http://localhost:4569 --profile localstack { "Items": [ { "Data": { "S": "fuga" } }, { "Data": { "S": "sample_2021-10-09-06-38-16" } } ], "Count": 2, "ScannedCount": 2, "ConsumedCapacity": null } ※データが追加されている。 API Gateway - Lambda 設定 Lambda ARN確認 aws lambda list-functions --endpoint-url=http://localhost:4574 --profile=localstack{ "Functions": [ { "FunctionName": "lambda-dynamodb-put", "FunctionArn": "arn:aws:lambda:us-east-1:000000000000:function:lambda-dynamodb-put", "Runtime": "python3.8", "Handler": "lambda_dynamodb_put_test.lambda_handler", "Timeout": 60, "Version": "$LATEST" } ]} API Gateway - Lambda設定 aws apigateway put-integration --rest-api-id 0157166521 --resource-id A-Z13318A-Z712 --http-method POST --type AWS_PROXY --integration-http-method POST --uri arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:000000000000:function:lambda-dynamodb-put/invocations --passthrough-behavior WHEN_NO_MATCH --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "type": "AWS_PROXY", "httpMethod": "POST", "uri": "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:000000000000:function:lambda-dynamodb-put/invocations", "integrationResponses": { "200": { "statusCode": 200, "responseTemplates": { "application/json": null } } }} 設定デプロイ aws apigateway create-deployment --rest-api-id 0157166521 --stage-name test --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack{ "id": "1850348379", "description": "", "createdDate": "2021-10-09T06:43:04.032000+00:00"} 動作確認 APIリクエスト POST /restapis/0157166521/test/_user_request_/lambda_dynamodb_test HTTP/1.1 Host: localhost:4567 Content-Type: application/json Content-Length: 2 {} APIレスポンス {"ResponseMetadata": {"RetryAttempts": 0, "HTTPStatusCode": 200, "RequestId": "9f2c5ca3-6187-4d92-811d-5cd62c5f5289", "HTTPHeaders": {"x-amzn-requestid": "9f2c5ca3-6187-4d92-811d-5cd62c5f5289", "content-length": "2", "access-control-allow-methods": "HEAD,GET,PUT,POST,DELETE,OPTIONS,PATCH", "server": "BaseHTTP/0.3 Python/2.7.13, Jetty(8.1.12.v20130726)", "x-amz-crc32": "2745614147", "date": "Sat, 09 Oct 2021 06:44:22 GMT", "access-control-allow-origin": "*", "access-control-allow-headers": "authorization,content-type,content-md5,x-amz-content-sha256,x-amz-date,x-amz-security-token,x-amz-user-agent", "content-type": "application/x-amz-json-1.0"}}} DynamoDB登録データ確認 aws dynamodb scan --table-name sample-table --endpoint-url=http://localhost:4569 --profile localstack { "Items": [ { "Data": { "S": "fuga" } }, { "Data": { "S": "sample_2021-10-09-06-38-16" } }, { "Data": { "S": "sample_2021-10-09-06-44-22" } } ], "Count": 3, "ScannedCount": 3, "ConsumedCapacity": null } ※データが追加されている。 参考情報 LocalStack入門(第５回)　ブラウザからのAPI Gateway,Lambda関数アクセス方法 ステップ 3: Python で項目を作成、読み込み、更新、削除する

はじめに AWS上にCapistranoを使用してRailsアプリをデプロイしましたが、ブラウザー上に「We're sorry, but something went wrong.」と表在されてしまうエラーに遭遇して、エラーの解決に苦戦しましたため、同様の悩みをお持ちの方のお役に立てばと思い、記載いたします。 開発環境 Mac Ruby 2.7.2 Rails 6.1.3.1 PostgreSQL 13.2 本番環境 puma nginx AWS（EC2、RDS、VPC、S3） 前提 RailsアプリをHerokuとS3を使用した環境で上手くデプロイできましたため、AWS（EC2、RDS、VPC）環境にRailsアプリをデプロイした際に発生したエラーとなります。 エラーの事象 ローカル環境のターミナルで「bundle exec cap production deploy」コマンドを実行し、表示されたIPアドレスをブラウザーに入力後、以下の画面が表示されました。本来であれば、アプリケーションのトップページが表示されるはずですが、エラー画面が表示されてしまいました。 ローカル環境のターミナルでデプロイエラーは出ていなかったため、サーバー環境のターミナルで「/var/www/アプリケーション名/shared/log/nginx.error.log」を確認したところ、以下のメッセージが表示されました。 /var/www/アプリケーション名/shared/log/nginx.error.log 2021/10/04 08:00:08 [crit] 25745#25745: *539 connect() to unix:/var/www/stop_sweets/shared/tmp/sockets/puma.sock failed (2: No such file or directory) while connecting to upstream, client: xx.xx.xx.xxx, server: localhost, request: "GET /blog/wp-includes/wlwmanifest.xml HTTP/1.1", upstream: "http://unix:/var/www/stop_sweets/shared/tmp/sockets/puma.sock:/blog/wp-includes/wlwmanifest.xml", host: "xx.xx.xx.xxx" 2021/10/04 08:00:09 [crit] 25745#25745: *539 connect() to unix:/var/www/stop_sweets/shared/tmp/sockets/puma.sock failed (2: No such file or directory) while connecting to upstream, client: xx.xx.xx.xxx, server: localhost, request: "GET /web/wp-includes/wlwmanifest.xml HTTP/1.1", upstream: "http://unix:/var/www/stop_sweets/shared/tmp/sockets/puma.sock:/web/wp-includes/wlwmanifest.xml", host: "xx.xx.xx.xxx" 「sockets/puma.sock failed (2: No such file or directory)」というメッセージでググってみたところ、pumaが起動した際にpuma.sockというファイルが作成されるとのことですので、pumaが上手く起動していないことによるエラーなのではと思い、pumaが上手く動かない原因を調べてみました。 以下のpuma起動用スクリプトからpumaを起動しているコマンドを確認しました。 /etc/systemd/system/puma_アプリ名_production.service [Unit] Description=Puma HTTP Server for stop_sweets (production) After=network.target [Service] Type=simple User=stop_sweets_user WorkingDirectory=/var/www/stop_sweets/current ExecStart=/home/stop_sweets_user/.rbenv/bin/rbenv exec bundle exec puma -C /var/www/stop_sweets/shared/puma.rb ExecReload=/bin/kill -TSTP $MAINPID StandardOutput=append:/var/www/stop_sweets/shared/log/puma_access.log StandardError=append:/var/www/stop_sweets/shared/log/puma_error.log Restart=always RestartSec=1 SyslogIdentifier=puma [Install] WantedBy=multi-user.target 上記のpuma起動用スクリプトから確認した起動コマンド「bundle exec puma -C /var/www/アプリ名/shared/puma.rb」をサーバー環境ターミナルのディレクトリ「/var/www/アプリ名/current」で実行したところ、以下のログが表示されました。 Puma starting in single mode... * Puma version: 5.2.2 (ruby 2.7.2-p137) ("Fettisdagsbulle") * Min threads: 0 * Max threads: 16 * Environment: production * PID: 13673 ! Unable to load application: ArgumentError: Missing required arguments: aws_access_key_id, aws_secret_access_key bundler: failed to load command: puma (/var/www/stop_sweets/shared/bundle/ruby/2.7.0/bin/puma) Traceback (most recent call last): 57: from /home/stop_sweets_user/.rbenv/versions/2.7.2/bin/bundle:23:in `<main>' 56: from /home/stop_sweets_user/.rbenv/versions/2.7.2/bin/bundle:23:in `load' エラーメッセージ「ArgumentError: Missing required arguments: aws_access_key_id, aws_secret_access_key」でググってみたところ、Railsアプリ内で画像投稿用のgem「CarrierWave」を使用して、投稿した画像をS3に保存するようにしておりましたが、S3を使用するためのアクセスキーとシークレットキーを設定していなかったことによるエラーであることが分かりました。そのため、railsアプリ内のコードを以下のように修正しました。 config/initializers/carrier_wave.rb if Rails.env.production? CarrierWave.configure do |config| config.fog_credentials = { provider: 'AWS', aws_access_key_id: Rails.application.credentials.dig(:aws, :access_key_id), aws_secret_access_key: Rails.application.credentials.dig(:aws, :secret_access_key), region: Rails.application.credentials.dig(:aws, :region) } config.fog_directory = Rails.application.credentials.dig(:aws, :bucket) end end config/credentials.yml.enc aws: access_key_id: 【IAMユーザーのアクセスキーID】 secret_access_key: 【IAMユーザーのシークレットアクセスキー】 region: ap-northeast-1 bucket: 【S3のバケット名】 上記の修正後、githubのmainブランチに反映し、ローカル環境のターミナルで「bundle exec cap production deploy」コマンドを実行致しました。ブラウザーからアプリへアクセスしたところ、無事にトップページが表示されるようになりました。 まとめ デプロイログやサーバログに真因に関するメッセージが出ていなかったため、 解決に手こずりましたが、エラーメッセージから地道に調査していくことが大切だと思いました。 nginxやpumaなどのサーバに関する知識も必要だと思いました。サーバに関する知識がないと原因がアプリ側なのか、インフラ側なのかの原因の切り分けが難しいと思いました。 参考資料 Capistrano自動デプロイ中の「ArgumentError: Missing required arguments: aws_access_key_id, aws_secret_access_key」エラー NginxとRails（Puma）をソケット通信で連携させる方法！

概要 AWS Directory Serviceのチュートリアルをやっていたら思いがけず詰まったのでメモ。ちなみに根本原因は調査中。 内容 チュートリアルのテストラボ4で、ドメインユーザーでログインしようとするとエラーとなり、ログインできない。 キャプチャは忘れたが、エラー内容は「ドメインが利用できない。端末をネットワークに接続してリトライしろ。」という内容。 チュートリアルの構成は以下の通り。 問題が発生していたのは、MGMT Instanceに対し、Directory Serviceのドメイン管理者ユーザーでRDPログインするとき。 ちなみにMGMT InstanceはWindows Server2019。ローカルアカウントでのログインは問題なし。 原因（分かった範囲で） DHCPでDNSサーバーの値が正常に払い出されていなかったため。 本来この形になっているはずが、 cmd.exe DNS Servers . . . . . . . . . . . : 10.0.0.234 10.0.1.78 実際はこうなっていた。 cmd.exe DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 暫定対処 DNSサーバーの値を手動で設定して、ひとまず解決。 根本原因はDHCPの動作不良と思われるが、こちらは調査中。 DHCPオプションセットはVPCにアタッチされているし、設定も間違ってなさそうなのでよくわからん。 MGMT Instanceを作成したタイミングで、DHCPオプションセットがVPCにアタッチされてていなかったっぽいが、それが原因だったりするかもしれない。ちなみにDHCPオプションセットをVPCにアタッチ後、MGMT Instanceを再起動しても効果はなかった。 解明まで とりあえずipconfigを叩いてみた。 cmd.exe C:\Users\admin>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : EC2AMAZ-NE4HBON Primary Dns Suffix . . . . . . . : corp.example.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : ap-northeast-1.ec2-utilities.amazonaws.com ap-northeast-1.compute.internal corp.example.com Ethernet adapter Ethernet 2: Connection-specific DNS Suffix . : corp.example.com Description . . . . . . . . . . . : Amazon Elastic Network Adapter Physical Address. . . . . . . . . : 06-40-84-38-F4-0B DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::9560:dbae:d823:8fb0%7(Preferred) IPv4 Address. . . . . . . . . . . : 10.0.0.50(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Saturday, October 9, 2021 5:39:50 AM Lease Expires . . . . . . . . . . : Saturday, October 9, 2021 6:39:50 AM Default Gateway . . . . . . . . . : 10.0.0.1 DHCP Server . . . . . . . . . . . : 10.0.0.1 DHCPv6 IAID . . . . . . . . . . . : 118097003 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-28-F2-D2-A7-06-40-84-38-F4-0B DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS over Tcpip. . . . . . . . : Enabled DNSサーバーの値がなんかおかしい。 cmd.exe DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 ドメインに対してのpingも通らない（DNSサーバーが応答してない）。 cmd.exe C:\Users\admin>ping corp Ping request could not find host corp. Please check the name and try again. マネジメントコンソールでDirectory Serviceの内容を確認してみると、 とあるので、ここはこうなっているのが正常なはず。 cmd.exe DNS Servers . . . . . . . . . . . : 10.0.0.234 10.0.1.78 ということで、DNSサーバーの値をコンパネから手動で設定してみた。 再度ドメインユーザーでログインしてみると、今度は正常にログインできた。 DHCP周りでなんかわかったら追記します。もしくは有識者の方、ご意見もらえると嬉しいですー。

LocalStackを用いて、S3バケットにオブジェクト登録を行うAPIをAPI Gateway + Lambdaで作成する方法についてメモする。 LocalStack及びS3 準備 こちらの手順でLocalStackとオブジェクト登録先のバケット(sample-bucket)を準備しておく。 API Gateway 準備 REST API を作成する リソースID(id)を控える aws apigateway create-rest-api --name 'LambdaS3TestAPI' --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "id": "A-Z2699261A-Z3", "name": "'LambdaS3TestAPI'", "createdDate": "2021-10-09T04:56:42.976000+00:00" } ルートリソースID取得 aws apigateway get-resources --rest-api-id A-Z2699261A-Z3 --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "items": [ { "id": "8955626A-Z80", "path": "/", "resourceMethods": { "GET": {} } } ] } 子リソース追加 パス名：lambda_s3_test aws apigateway create-resource --rest-api-id A-Z2699261A-Z3 --parent-id 8955626A-Z80 --path-part lambda_s3_test --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "id": "5A-Z12A-Z75998", "parentId": "8955626A-Z80", "pathPart": "lambda_s3_test", "path": "/lambda_s3_test", "resourceMethods": { "GET": {} } } HTTPメソッド追加 aws apigateway put-method --rest-api-id A-Z2699261A-Z3 --resource-id 5A-Z12A-Z75998 --http-method POST --authorization-type "NONE" --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "httpMethod": "POST", "authorizationType": "NONE" } Lambda 準備 lambda_s3_test.py S3バケットsample-bucketにJSONファイルをオブジェクトとして配置する。 import boto3 from boto3.session import Session from datetime import datetime session = Session(aws_access_key_id='dummy', aws_secret_access_key='dummy', region_name='ap-northeast-1' ) s3 = session.resource( service_name='s3', endpoint_url='http://localhost:4572' ) def lambda_handler(event, context): bucket_name = 'sample-bucket' key = 'sample_' + datetime.now().strftime('%Y-%m-%d-%H-%M-%S') + '.json' body = '{"sample_key":"sample_value"}' s3.Bucket(bucket_name).put_object(Key=key, Body=body) return 's3 put JSON_FILE' 上記ファイルをlambda_s3_test.zipにzip化する。 アップロード aws lambda create-function --function-name="sample-function" --runtime=python3.8 --role="arn:aws:iam::123456789012:role/service-role/lambda-sample-role" --handler=lambda_s3_test.lambda_handler --zip-file fileb://lambda_s3_test.zip --endpoint-url=http://localhost:4574 --profile=localstack 起動 aws lambda invoke --cli-binary-format raw-in-base64-out --function-name sample-function result.log --endpoint-url=http://localhost:4574 --profile=localstack { "StatusCode": 200 } 確認 aws s3 ls s3://sample-bucket --endpoint-url=http://localhost:4572 --profile=localstack 2021-10-09 11:25:03 29 sample_2021-10-09-02-25-03.json ※ファイルが配置されている。 API Gateway - Lambda設定 Lambda ARN確認 aws lambda list-functions --endpoint-url=http://localhost:4574 --profile=localstack { "Functions": [ { "FunctionName": "sample-function", "FunctionArn": "arn:aws:lambda:us-east-1:000000000000:function:sample-function", "Runtime": "python3.8", "Handler": "lambda_s3_test.lambda_handler", "Timeout": 60, "Version": "$LATEST" } ] } API Gateway - Lambda設定 aws apigateway put-integration --rest-api-id A-Z2699261A-Z3 --resource-id 5A-Z12A-Z75998 --http-method POST --type AWS_PROXY --integration-http-method POST --uri arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:000000000000:function:sample-function/invocations --passthrough-behavior WHEN_NO_MATCH --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "type": "AWS_PROXY", "httpMethod": "POST", "uri": "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:000000000000:function:sample-function/invocations", "integrationResponses": { "200": { "statusCode": 200, "responseTemplates": { "application/json": null } } } } 設定デプロイ aws apigateway create-deployment --rest-api-id A-Z2699261A-Z3 --stage-name test --endpoint-url=http://localhost:4567 --region us-east-1 --profile localstack { "id": "6271136713", "description": "", "createdDate": "2021-10-09T05:08:40.688000+00:00" } 動作確認 APIリクエスト パス:/restapis/${REST_API_ID}/test/_user_request_/${登録したAPIパス名} POST /restapis/A-Z2699261A-Z3/test/_user_request_/lambda_s3_test HTTP/1.1 Host: localhost:4567 Content-Type: application/json Content-Length: 2 {} APIレスポンス "s3 put JSON_FILE" S3オブジェクト確認 aws s3 ls s3://sample-bucket --endpoint-url=http://localhost:4572 --profile=localstack 2021-10-09 11:25:03 29 sample_2021-10-09-02-25-03.json 2021-10-09 13:43:27 29 sample_2021-10-09-04-43-27.json 2021-10-09 14:14:53 29 sample_2021-10-09-05-14-53.json ※オブジェクトが追加されている。 参考情報 LocalStack入門(第５回)　ブラウザからのAPI Gateway,Lambda関数アクセス方法

Google Authenticatorが初期化された・・・ それまで問題なく使えていたのですが、ある日突然初期化されちゃいました。 引き継ぎもしていたのでどうしようもなかったのですが、自力でMFAを解除出来るとのことなのでやることにしました。 別の認証要素を使用したサインインで試みる メールと電話番号で解除してみる まずはコンソール画面からルートユーザーからEメールアドレスとパスワードを入力して次へを押します MFAコードの入力画面に遷移するので、送信の下にある「MFAのトラブルシューティング」を押します。 すると別の認証要素を利用したサインインに遷移します。 登録したEメールが表示されるので「確認Eメールの送信」を押すとこのような画面になります。 メールを確認すると届いているので、本文内にある「[Verify your email address」を押すと、電話番号の確認画面が出てきます。 上手く行けば発信してくれるのですが、ここで何故か詰まったので、サポートに問い合わせをします。 サポートへの問い合わせ 必要項目の入力 画面に表示されている「AWSサポートにお問い合わせください。」を押すとこんな画面が表示されます。 左の「I'm still having problems and would like to contact AWS Support.」を押します。 問い合わせに必要な項目を入力します。Support languageを日本語にしてSummitを押すと完了です。 電話での対応 数分するとサポートから電話がかかってきます。電話での確認は 1. 登録しているアドレスを「アルファベットで」回答する 2. 登録アドレス宛にワンタイムパスワードが送付されるので、その場で答える でした。これでMFAが無効化されるので、コンソールのログイン画面でIDとパスワードを入力します。 無事ログインできました コンソール画面からIAMのダッシュボードを確認するとMFAが無効化されているのがわかりますので、再設定をします。これで再度MFAが有効化できるようになりました。 日本語サポートが平日の9:00-18:00までなので、そこは注意したほうがいいですね。 参考 MFA デバイスが故障または紛失した場合のセルフサービスによるリセットの方法

概要 入力された $\mathbb{Q}$ 上の多項式のガロア群を ${\rm mod}\ p$ で因数分解し、ガロア群に含まれる共役類の割合を計算することで予測します。有限個の $p$ しか動かせないので、決定まではできず予測の域を超えません。 URL はこちらです。Amplify でデプロイしています。 以下の「use credit」ボタンを押すと、ゲストユーザーでアプリが使用可能になります。 AWS 構成 Fargate で計算をし、結果を DynamoDB に送ります。そのレコードをユーザーに返します。 問題点 Fargate でタスクを起動するのに時間がかかることです。リクエストを送ってから予測結果を表示するまでに 1 分 30 秒ほどかかります。

LocalStackとは？ AWSのサービスを擬似的に利用できるフレームワーク 対応AWSサービスは、公式ページを参照のこと AWS CLIインストール・設定 インストール 筆者環境はWindowsのため、こちらからインストーラーをダウンロードし、実行する。 インストール結果確認 aws --version aws-cli/2.2.44 Python/3.8.8 Windows/10 exe/AMD64 prompt/off 設定 クレデンシャル設定 aws configure --profile localstack AWS Access Key ID [None]: dummy AWS Secret Access Key [None]: dummy Default region name [None]: ap-northeast-1 Default output format [None]: json 設定値確認 cat ~/.aws/credentials [localstack] aws_access_key_id = dummy aws_secret_access_key = dummy cat ~/.aws/config [profile localstack] region = ap-northeast-1 output = json Docker 環境構築 Gitからプロジェクトクローン git clone https://github.com/atlassian/localstack.git Cloning into 'localstack'... remote: Enumerating objects: 2199, done. remote: Counting objects: 100% (6/6), done. remote: Compressing objects: 100% (4/4), done. Receiving objects: 100% (2199/2199), 618.62 KiB | 2.07 MiB/s, done. Resolving deltas: 100% (1435/1435), done. Docker起動 cd localstack docker-compose up 動作確認 ダッシュボードアクセス(http://localhost:8080) S3 バケット作成 aws s3 mb s3://sample-bucket --endpoint-url=http://localhost:4572 --profile=localstack make_bucket: sample-bucket バケット確認 aws s3 ls --endpoint-url=http://localhost:4572 --profile=localstack 2006-02-04 01:45:09 sample-bucket ※作成時刻がおかしい...？ 参考情報 LocalStack s3 — AWS CLI 1.20.58 Command Reference

こんにちは。パエリア王子です。 最近写真や動画を取る機会があって、友人にも共有したかったのですが、容量が多くてLINEでは送れないということがありました。 Google DriveなどのSaaSを使えば簡単に実現可能だと思いますが、せっかくならAWSを利用して共有する方法を考えようと思い、実施しました。 筆者は普段、AWSの監視、運用しかやっておらず、開発経験はあまりありません。 あまりS3に触る機会もないので、内容はレベルが低いですが、ご容赦ください。 また、筆者はSAPを取得しており、AWSの各種サービスの概要等は知っていますが、触ったことのあるサービスはEC2やRDSくらいなので、持っている知識をできるだけ使ってみようという趣旨のもとサービスを検討、利用しています。 どうやってファイル共有を実現するか まずはじめに、どのサービスを使ってファイル共有を実現するかですが、保存先はS3で決まりでしょう。 次にダウンロード（共有）方法ですが、そのままオブジェクトをパブリック公開するのはセキュリティ上、問題があると考えました。 会社の書類を公開するわけではないので、そんなに気にすることではないかもしれませんが、友人との写真や動画を垂れ流しにすることにも少し抵抗があります。 （SNSで公開するのとどう違うんだと言われればそこまでなんですが、、、） ①AWS Cognito ? まず考えてみたのがAWS Cognitoでの連携。 (頭の中) セキュリティを考えたら、やっぱりユーザーの認証とかすればかなり安全なんじゃないか 　→AWSで認証のサービスと言えばAWS Cognitoでしょ 　　→LINEとかSNSで連携して実装できればなんかちょっとすごいものができそう よし、これで進めてみよう！ ・・・・・・・めちゃめちゃ大変だ。 調べてみると可能ではあるのですが、かなり時間がかかりそうでした。 一部参考にさせていただいた記事を載せさせていただきます。 https://qiita.com/Futo_Horio/items/97586a3c16d939a8ab5f ②署名付きURL? SAAの試験で何度も見た　S3 署名付きURL。 「S3 セキュリティ」と検索すると結構これが引っかかります。 AWSの試験でもよく出るし、何かしらAWSがベストプラクティスとして紹介しているサービスですね。 存在は知っていたけど、結局URLを知っていれば見ることはできるし、時間制限も友人とファイル共有するのならめんどくさいなーと思っていました。 しかし、①の方法より簡単だし、調べてみるとURLの中身は https://awsexamplebucket.s3.amazonaws.com/test.txt?AWSAccessKeyId=EXAMPLEACCESSKEYXXXX&Signature=XXXXEXHCcBe%EXAMPLEKnz3r8O0AgEXAMPLEXXXX&Expires=155553XXXX のようにハッシュ値のようなものが入った長いURLになるので、悪意があっても簡単には特定できなそうだと感じました。（小並感） とはいえ、URLが知られてしまえば誰でも見れてしまうので、使うときは時間制限を設けてで少しでもリスクを減らしましょう。 ということで、こちらの方法で進めていきます。 では、実際に署名付きURLを作成していきましょう。 方法はいくつかあるようですが、簡単な方法を２つ紹介します。 ①マネージメントコンソールから作成 署名付きURLで公開したいファイルを選択する 「開ける」ボタンをクリックする ファイルの中身が表示されるので、そのURLをコピーして共有したい人に送る。 この方法では300秒(5分)の期限の署名付きURLが発行されるようです。 署名付きURLの正式な作成方法ではなさそうですが、制限時間が５分間で問題なければこの方法が一番簡単ではないでしょうか。 ②CLIで作成 CLI環境が整っていない人は少し手間がかかるかもしれませんが、CLIが使えるなら簡単です。 一応、CLIインストールの公式のドキュメントを貼っておきます。 https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-mac.html 下記コマンドを実行するだけです。 aws s3 presign s3://バケット名/オブジェクト名（S3 URL） --expires-in 60 --expires-in　のあとには秒単位で有効期限を入力します。 コマンドを実行したらURLが作成、表示されるのでそれをコピーして共有したい人に送りましょう。 しかし、私はここでエラーが起きました。 aws s3 presign s3://バケット名/AWS Certified Solutions Architect.pdf --expires-in 60 Unknown options: Certified,Solutions,Architect.pdf むむ。ちゃんとS3　URLをコピーしたのに、、、 このときは「AWS Certified Solutions Architect.pdf」というオブジェクト名のURLを作成しようとしていました。 このオブジェクト名に「スペース」が入ってしまっていることによって、その部分がコマンドの引数として扱われてしまっていることが原因のようでした。 aws s3 presign 's3://バケット名/AWS Certified Solutions Architect.pdf' --expires-in 60 これで、コマンドの実行はうまくいきました。しかし、URLを見に行くと、、、 This XML file does not appear to have any style information associated with it. The document tree is shown below. <Error> <Code>PermanentRedirect</Code> <Message>The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.</Message> <Endpoint>バケット名.s3-ap-northeast-1.amazonaws.com</Endpoint> ・ ・ ・ 指定されたエンドポイントを使用してアドレス指定してください、、、？？？ これはCLIの設定の問題でした。 コマンド実行時CLIを実行する環境の「.aws/config」にあるリージョンの設定が「region = us-east-2」となっていることが原因でした。 ここを対象オブジェクトに合わせたリージョン（今回は「ap-northeast-1」）に修正し、コマンドを再実行することでエラーは解消されました。 リージョン指定の部分はなにか違う方法でも解決できそうですが、今回はここまでとします。 まとめ ・ファイル共有は S3 の 署名付きURLを使ってみよう ・CLI コマンド実行時に　S3 URL　は ' ' でくくっておこう。 ・CLI コマンド実行時はエンドポイントに合わせたリージョンを指定しよう。 今回私が出会ったエラーは、頻度は多くないエラーな気がしますが、少しでも同じような方のお力になれれば幸いです。 また、料金も気になる人もいると思いますので、公式のリンクを貼っておきます。 https://aws.amazon.com/jp/s3/pricing/ それでは、また次回。

勉強前イメージ EC2のイメージを作ってくれるやつ？ でもイメージって手で作れるんじゃね？？？ 調査 EC2 Image builder とは AMIのアップデートを自動的に自動化出来るサービスになります。 今まで取得したAMIを定期的にアップデートして再作成などしないといけません。 また、アカウントを跨いだAMIの共有なども面倒でした。 EC2 Image builder を使うとインスタンスを起動してアップデートすることなく、 自動的にアップデートでき、EC2 Image builder自体は無料で利用することができます(EBSなどの費用はかかります。) EC2 Image builder の用語 ビルドコンポーネント ソフトウェアのパッケージのダウンロード・インストールなど定義するドキュメントでyaml形式で書かれます。 レシピ ソースのイメージとソースイメージに適用して出力イメージに必要な構成を作るコンポーネントを定義するドキュメント イメージパイプライン 安全なOSイメージを構成するための自動化構成でレシピからAMIを取得するパイプライン(ビルド・検証・テスト)を定義してるものです。 流れ 作成の流れとして、以下になります。 コンポーネントを作成 コンポーネントを元にレシピの作成 レシピを元にイメージパイプライン作成 イメージパイプラインからAMIの取得 作ってみる イメージパイプラインを作成 ホーム > EC2 Image builder へ進み、イメージパイプラインを作成を行います。 パイプラインの詳細を指定 パイプライン名を指定します。 また、どういう頻度や方法でビルドするのかを決めます。 レシピを選択 レシピを作成します。 既存のレシピはなかったので新しく作りました。 今回はAMIを作成、またレシピの名前とバージョンの指定を行います。 ここではOSやイメージ、OSのバージョンをどうするのかの指定をします。 コンポーネントを指定します。 今回はpythonとmariadb、phpを入れてみました。 テストコンポーネントも指定します。 rebootするように指定しました。 インフラストラクチャ設定 インフラは今回デフォルトにしますが、 普通に業務で使う際は色々決まりがあると思うので、 「新しいインフラストラクチャ設定を作成する」 から キーペアなどを設定してください ディストリビューションの設定を定義 こちらも今回デフォルトにしますが、 アカウント横断でAMIを使う際などは 「新しいディストリビューション設定を作成する」 から アカウントなどの設定をしてください 最終確認 設定に間違いがないか確認を行い、パイプラインを作成します。 パイプラインの作成完了 パイプラインが作成できました。 パイプラインを実行 できたパイプラインを実行してみます。 パイプラインにチェックを行い、アクションから「パイプラインの実行」を行います。 test-pipelineの中を見てみると、作成中になっています。 EC2インスタンス作成 新しいEC2インスタンスができました！ 勉強後イメージ そんなに難しくなく作れた気がする・・・まぁ詳細設定しようとすると難しいんだろうな。。。。 AMIを自動で更新してくれるの嬉しいね 参考 EC2のイメージ作成を劇的に効率化するEC2 Image Builderが発表されました！ #reinvent 【re:Invent 2019】新機能 EC2 Image Builder を使ってみた

Pulumiはプログラマーにとって慣れ親しんだ言語でインフラを構成できるモダンなIAASツールです。 小規模なプロジェクトで１人で何役もやっている人にとって、生産性が高いかもしれません。 イケてると思ったポイントや、ググってもサクッと分からなかった様な話を記事にしていきます。 前提条件 Pulumi及びAWSの設定が完了している ARNを参照するコード 直でうまく動いたケース例 const sqsPolicyCustomAttachment = new aws.iam.RolePolicyAttachment( `RolePolicySample`, { role: lambdaRole.name, policyArn: sqsPolicy.arn, // <-----------直接ARNを指定している } ); この場合、poliyArnプロパティに対して直接arnを指定しています。 このとき、policyArn の型は pulumi.Input<string> で、sqsPolicy.arnの型は pulumi.Output<string>です。 うまく動かなかったケース例 const queue = new aws.sqs.Queue(`QueueExample`, { fifoQueue: true, redrivePolicy: JSON.stringify({ deadLetterTargetArn: deadLetterQueue.arn, maxReceiveCount: 10, }) }); これだと、deadLetterQueue.arn をうまく解決してくれません。 このとき、deadLetterTargetArnは pulumi.Input<string> 型ではありません。 以下が修正 const queue = new aws.sqs.Queue(`QueueExample`, { fifoQueue: true, redrivePolicy: deadLetterQueue.arn.apply((arn) => JSON.stringify({ deadLetterTargetArn: arn, maxReceiveCount: 4, }) ), }); apply関数を適用することで、値が解決され、このケースでもうまく動くようになります。 pulumi.Output<T> 型 に関しては、インフラのプロビジョンが完了するまでその値が決定しない為、Promiseと似た非同期処理の形を取るようです。Apply関数を利用することで値が解決され、実際の値を取得可能です。 ドキュメントを見た限りでは、リソースのプロパティで pulumi.Input<T> の型に対しては、pulumi.Output<T> を直接指定しても、Pulumiが内部的に解決してくれるようです。 参考 https://www.pulumi.com/docs/intro/concepts/inputs-outputs/