概要 1年くらい前に試したAWS ECRにdockerイメージをpushする手順のまとめ。備忘録。 1. ECRリポジトリの作成 aws ecr create-repository --repository-name ${REPOSITORY_NAME} --region ${AWS_REGION} 2.ログイン --password-stdinには上記で作成したリポジトリのURLを指定する。Login Succeededが帰ってくれば成功。 aws ecr get-login-password | docker login --username AWS --password-stdin https://<aws_account_id>.dkr.ecr.<region>.amazonaws.com ビルドする Dockerfileが存在するディレクトリで実行する。 {レジストリID}.dkr.ecr.{リージョン}.amazonaws.com/{リポジトリ名}:{タグ名}はECRのレジストリのURLと同じ。 docker build {レジストリID}.dkr.ecr.{リージョン}.amazonaws.com/{リポジトリ名}:{タグ名} ECRにpushする docker push {レジストリID}.dkr.ecr.{リージョン}.amazonaws.com/{リポジトリ名}:{タグ名} 結果 ちゃんと登録できました。 参考文献

はじめに AWSに出てくる基本単語を備忘録を兼ねてまとめます。 ざっくりイメージで記載している箇所も多々あるので、その点はご容赦ください。 当方初学者故、誤りがあればコメントでご教授いただけると幸いです。 VPC　（Virtual Private Cloud） AWS上に仮想ネットワークを作成できるサービスのこと。 AWSの敷地にないに自分の領土を広げるイメージ。 VPC内にアプリに必要なサーバーやサブネットなどを配置する。 サブネット VPCを細かく区切ったネットワーク、そのグループのこと。 VPC内で役割が異なるパーツを外部接続、内部接続など、接続先ごとにサブネットというグループに分類する。 サブネットは複数のAZに接続する。 インターネットゲートウェイ VPCから外部に出るときに通る出入り口のこと。VPCにアタッチして設定する。 ルートテーブル サブネットごとに作成できる、通信に関するルールブック。 セキュリティグループ サブネットごとに作成できる、セキュリティに関するルールブック。 ホワイトリスト方式でルールを記載する。（記載されたルール以外は全て拒否する） ・インバウンドルール：来る通信のルール ・アウトバウンドルール：送る通信のルール RDS(Relational Database Service) DBを提供するサービス。 AWSでDBを利用するには２種類の方法がある ・EC2インスタンス（サーバー）にDBをインストールする ・RDSを利用する EC2インスタンス（Elastic Compute Cloud） EC2とはクラウド上に存在する仮想サーバーのこと。 EC2インスタンスとは、EC2によって実際に建てられたサーバーのこと。 AMI(Amazon Machine Image) インスタンスの起動情報が入ったOSのイメージ. 作成するサーバーのコンピューターのテンプレートのこと。 AMIを選択してクイックスタートすることでパッケージ化されたOSの起動に必要な情報を簡単にインストールできる。 ElasticIP 動的なクラウドコンピューティングのために設計された静的な IPv4 アドレス。 Elastic IP アドレスはユーザーの AWS アカウントに割り当てられ、解放するまでユーザーのアドレスとして使える。

概要 2021年12月1日以降、Athenaの特定のSQLクエリ構文のクエリ結果が変更になるようです。 今回は、その該当するクエリ構文がどのようなものかをまとめました。 該当するクエリ構文 1: CHAR 型カラムと文字列リテラルの比較の評価が容易になります。文字列リテラルにはパディングは必要ありません。 データ型 CHAR (5) の col5 という名前の列があり、列 col5 の値 'abcd ' (末尾のスペースに注意) の行が含まれている。 現在の仕様: クエリで結果を一致させるには、まったく同じ文字列リテラルを使用する必要があった。 SELECT 1 FROM t WHERE col5 = 'abcd '; (末尾にスペースが必要) 新しい仕様: 条件と一致するためにクエリの末尾にスペースを入れる必要がなくなった。 SELECT 1 FROM t WHERE col5 = 'abcd'; ちなみに、上記のクエリは両方とも一致し、現在の動作は引き続き有効な模様。 2: MAP 型の存在しないキーにアクセスすると、結果として NULL が返されるのではなく、エラーが発生する。 現在の仕様: MAP データから存在しないキー「abc」の値にアクセスする際に、キー 'abc' は MAP に存在しないため、Athena は NULL を返す。 新しい仕様: Athenaが「マップに存在しないキー:abc」を示すエラーを返す。 下記のようなクエリを発行し、NULL を返すことを望む場合は、TRY 関数を利用する。 SELECT MAP(array['foo', 'bar'], array[1, 2])['abc']; SELECT TRY(MAP(array['foo', 'bar'], array[1, 2])['abc']); 3: 「.field [n]」形式の匿名行フィールドへのアクセスはサポートされなくなった。 現在の仕様: 匿名行のフィールドにアクセスすると、Athena は次のクエリの最初のフィールド ('a') を返す。 SELECT ROW('a', 'b').field0; 新しい仕様: Athena は「列 'ROW ('a', 'b') .field0' を解決できません」というエラーを報告する。 ただ、匿名でない行にアクセスする方法には影響しない。 次のクエリは変わらず動作し、'a' を返します。 SELECT CAST(row('a', 'b') AS ROW(col0 char, col1 char)).col0;

勉強前イメージ 1分間隔で見れるとか正直それくらいしか覚えてないし違いがわからん 調査 cloudwatchの詳細モニタリングとは EC2のモニタリングタイプで、 基本モニタリング と 詳細モニタリング があります。 基本モニタリング 費用 : 無料 データの取得間隔 : 5分 詳細モニタリング 費用 : 有償 データの取得間隔 : 1分(10個までは無料利用枠) 詳細モニタリング有効化の方法 詳細モニタリングはEC2インスタンス1台ごとに有効化を行います EC2へ移動 EC2へ移動します 有効化 アクション > モニタリングとトラブルシューティング > 詳細モニタリングを有効化 へ進みます。 設定を変更 有効化にチェックを入れて有効化します 確認 内容を確認すると、詳細と記載があります。 無効化の方法 分かりづらいのですが、詳細モニタリングを無効化するには 有効化 を外すだけで出来ます。 勉強後イメージ 実際ちょっと調べてみたけど1分くらいしかなかった気がする。 あと、有償なのねこれ 参考 AWS初心者向けWebinar これで完璧、AWSの運用監視 （ショロカレ 14 日目）EC2 の詳細モニタリングが適用されていることを確認するメモ

　前提 バックエンドをAWSを利用してiOS開発をしています。 新たなアプリにプッシュ通知を実装する必要があり、元々amplifyを使用していたためAmazon pinpointを利用することになりました。 初めてのプッシュ通知、初めてのpinpointで山あり谷ありでしたが、なんとか実装に成功。 その山の中でも特にわけわからなかったのがpinpointがオレゴンにpushされるという事象です。 amplifyはap-northeast-1(東京リージョン)に設置しているので、amplify CLIを利用して作成したapi、authなどは東京リージョンに設置されます。 しかし、analyticsだけは何故かus-west-2(オレゴン)に設置されてしまいました。 これを解決しようと思ったのですが、なかなか記事が引っ掛からなかったので、ここに備忘録として残しておきます。 原因 amplify add analytics をした後に作成されるcloudformation-templete.jsonが原因。 このファイルの中でどのリージョンにpushさせるか決めています。 なので、このファイルの中身をいじってからpushするだけ。 解決方法 自分が作成したプロジェクトまで移動し、 cd amplify/backend/analytics/プロジェクト名（もしくはここにあるファイル名） に移動します。 lsコマンドを実行すると pinpoint-cloudformation-templete.json というファイルがあると思います。（ここにない人はごめんなさい、わかりません） このファイルをcatコマンドで見てみると、マッピングリスト的なものがあると思います。 その中に、それぞれのリージョンに対するpinpointRegionがあると思いますが、それがpinpointが設置されてしまうリージョンです。 私は東京リージョンなのでap-northeastを確認してみると以下のようになっていました。 "ap-northeast-1": { "pinpointRegion": "us-west-2" }, これが原因で、us-west-2に設置されてしまう、というわけです。 なので、例えばus-east-1におきたい場合、 "ap-northeast-1": { "pinpointRegion": "us-east-1" }, に変更してから、amplify pushをしてあげればOKです。 pinpointは比較的新しいサービスのため、まだ対応していないリージョンがあります。自分が使用したいリージョンで使えるかは各自調べてみてください。 まとめ amplifyはじめAWSの知識がまだまだ足りないなと思う今日この頃です。 pinpointを利用してチャットアプリの通知機能も実装できたので、そちらの記事も近々記事を上げたいと思います。 今度はfirebaseを使って通知機能も実装してみたいですね。 それでは。

S3＋CloudFrontの構成で静的Webサイトを構築した場合、サブフォルダまたはサブディレクトリからデフォルトのルートオブジェクトを返さないという問題に対し、Lambda@Edge（L@E）で解決するという記事をよく見かけますが、CloudFrontFunctions(CF2)でも実現することができました。 CF2はL@Eより手前で、シンプルな処理をより高速に、素早く、安価に実行できるサービスです。 今回のように URLにファイル名や拡張子を含まないリクエストにindex.htmlを追加するだけ といった単純なユースケースではより最適な方法かと思います。 やってみた コードを拾ってくる コードサンプルがAWS公式のCloudfrontデベロッパーガイドに載っているので以下のページからコピーします index.html を追加してファイル名を含まない URL をリクエストする CF2に追加 CloudFront>関数にアクセスし、適当な名前をつけて保存します 関数を発行する 発行>関数を発行 をポチります（コレをやらないとCloudFrontと紐付けができない CloudFrontにCF2を関連付ける CloudFrontの該当するディストリビューション > Behavior > 編集 からViewerRequestに関連付けを行います 以上 ググったら出てこなかったので,投稿してみました。

ポートフォリオのデプロイに使用したAWSのサービスとその周辺のインフラ知識についてまとめました。 サービス一覧、 VPC RDS EC2 Route53 IAM S3 ACM ALB VPC VPCとは？ Virtual Private Cloudの略で、AWS上に仮想ネットワークを作成できるサービス。 AWSの広いネットワークの土地の中で自分だけの空間を作成できる。 リージョン AWSの各サービスが提供されている地域のこと。 AWSのサービスを使う場合まずリージョンを設定し、リージョン毎にサーバーを作っていく。 アベイラビリティゾーン 独立したデータセンターのこと。 どのリージョンにも複数存在している。理由は災害が起きて１つのアベイラビリティゾーンが止まっても他のアベイラビリティゾーンを使えるから。 サブネット ネットワークを分割して作った小さなネットワークのこと。 サブネット内で1つをインターネットからアクセス可能なWebサーバー、もう1つをアクセスできないDBサーバーのように複数分けて作ることができる。 複数のアベイラビリティゾーンの中にそれぞれサブネットを作ることで冗長性を高める。 IPアドレス ネットワーク構築の際には、まずIPアドレスの範囲を決める必要がある。 IPアドレスとは、インターネットの住所で重複なしの32ビットの整数で8ビット4つの組に分け10進数で表現されている。 IPアドレスの種類は、インターネットに接続する際に使用するパブリックIPアドレスと、インターネットの接続には使用しないプライベートIPアドレスがある。 IPアドレスはネットワーク部とホスト部に区分けすることで範囲を表記してる。 CIDR表記 IPアドレスの後ろに「/」を書きその後ろにネットワーク部が先頭から何ビット目なのかを表記する。 例：　192.168.128.0/24 (ネットワーク部が24ビット目) EC2 EC2とは？ Elastic Compute Cloudの略でAWSクラウド上の仮想サーバー。 インスタンスとはEC2から立てられたサーバーのこと。 EC2インスタンスの作成に必要なもの AMI インスタンス起動に必要なOSのイメージ、サーバーのテンプレート。 インスタンスタイプ サーバーのスペックを定義したもの。 例 : m5.xlarge、スペックにより値段が変わる。 ストレージ サーバーにつけるデータの保存場所 EBSとインスタンスストアの2種類ある SSH 通信内容が暗号化された遠隔ログインサービスでEC2にログインする際に使用する。 SSHでログインすることでサーバーと自分のPCを安全に繋いでくれる 公開鍵認証 サーバーの作成者だけがログインできるようにEC2ではSSHログイン時に公開鍵認証を行なっている。 公開鍵と秘密鍵を用いてログイン認証を行う仕組み。 サーバーの作成者（秘密鍵を持っているユーザー）だけがログインできる。 イメージは南京錠で閉めるのは誰でもできるけど開けるには鍵が必要。 ファイアウォール ネットワークを不正アクセスから守るために必要な通信だけ通してそれ以外は通さない機能 AWSではセキュリティグループがファイアウォールの役割を担っている。 Elastic IPアドレス EC2インスタンスのIPアドレスは、起動、停止すると別のIPアドレスが割り当てられてしまう。 Elastic IPアドレスを使用することでIPアドレスの固定ができる。 インスタンスを削除するまでずっとそのIPアドレスを使用できる。 RDS RDSとは？ フルマネージドなリレーショナルデータベースのサービス。 AWSが構築や運用の管理をしてくれているのでRDSを使うことでコア機能の開発に注力できる。 MySQLやPostgreSQLなどのデータベースが利用可能。 RDSの特徴として、高い可用性、パフォーマンスの向上、運用負荷の軽減などがある。 Route53 ドメイン インターネット上に存在するコンピューターやネットワークを識別するための名前。 IPアドレスでは覚えにくいので、example.comのような形式で表すインターネット上の住所。 DNS ネームサーバーとフルリゾルバから構成されているドメインの管理システムで、ドメイン名をIPアドレスに変換する。 ネームサーバー ドメイン名とそれに紐ずくIPアドレスが登録しているサーバー。電話帳のようなもの。 フルリゾルバ 紐付くIPアドレスをネームサーバ-に問い合わせて、色々なネームサーバーに聞いて調べて教えてくれるサーバー。 Route53とは？ AWSのDNSサービス。ネームサーバーの役割を果たす。 フルマネージドサービスで運用が楽。 ドメインの登録、サーバーの稼働状況をチェックするヘルスチェク、IPアドレスとドメインの紐付けのルーティングを決めるルーティングポリシーなどの機能がある。 IAM IAMとは？ AWSのサービスを利用するユーザー権限を管理するサービス。 各AWSリソースに対して別々のアクセス権限をユーザー毎に付与できるので、セキュリティを高めることができる。 ポリシー アクセス許可の定義。 「どのAWSサービスの」「どのリソースに」「どんな権限を」「許可するかしないかを」定義できる。 ユーザー 個々のアカウントのことで、一人一人に一つ一つのユーザーを作る。 グループ IAMユーザーの集合体で、複数のユーザーにアクセス権限を付与。 毎回ユーザー一人一人にポリシーを定義するのは手間だからグループを作りグループにポリシーを割り当てるので、まとめてポリシーを割り当てることができる。 ロール 一時的にアクセスを許可したアカウントを発行できる。 S3 S3とは？ 安価で耐久性の高いAWSのクラウドストレージサービス。 S3を使うことでデータ容量を気にすることなく保存することができる。 画像などの静的コンテンツの配信、ログの出力先、静的なWebサイトをS3から公開するなどに利用される。 CloudFront PCとS3の間の仲介に入り高速にコンテンツを配信するサービス。 CloudFrontはPCからS3にリクエストがあった場合、コンテンツを取得してキャシングを行いキャッシュから配信するので、高速化されS3の負荷が減る。 ACM ACMとは？ AWS Certificate Managerの略で、AWS上のSSL証明書発行サービス。 簡単かつ安価にSSLの対応、そしてSSL証明書の更新ができる。 SSL証明書 インターネット上でやりとりされるデータの「盗聴」「なりすまし」を防止するための暗号化プロトコル。 SSLを使うことで送受信される情報を第三者に読み取られないように暗号化することができるので、 セキュリティの向上とアクセス権限をもたない人が、サーバーや情報システムの内部に侵入しないようにできる。 ALB ALBとは？ Application Load Balancerの略。複数のEC2インスタンスにアクセスを振り分けることで負荷分散でき高い可用性を実現できる。 ACMを利用したSSL/TLS証明書の管理などセキュリティ面が充実している。 参考

この記事を書いている私について インフラ系PMO歴半年でAWSクラウドプラクティショナーを取ったばかりの私が AWS CloudTechという動画学習サービスに参加し、AWSエンジニアを目指すための備忘録です 構築→記事作成→指摘反映の中で間違いがあったら業務でも発生するので、これからも気を引き締めて行きたいと思います。 本記事の目標 前回の「HTTPS通信でアクセス可能にする」に引き続き、 今回はCloudFrontを使いキャッシュサーバーを設置します。 前回の記事ではHTTPS通信でブログサイトにアクセスして閲覧できる状態でした。 本記事ではCloudFrontを配置してHTTPS通信でブログサイトにアクセスして閲覧できるようにしていきます。 CloudFrontとは データを効率良く配信できるキャッシュサーバーをフルマネージドで利用できるAWSのサービスです。 EC2のデータをCloudFrontにコピーしているようなイメージです。 ユーザーはEC2にデータを取りに行くのではなく、間にあるCloudFrontに取りにいきます。 これによって、ユーザーにとってはWebページの表示が速くなり、サーバーにとっては、データを渡す処理が減るため、負荷が軽減されるメリットがあります。 今回の構成図 ※構成図の作成にcloudcraftを利用しています。 構築の流れ 以下の流れで構築を進めます。 ・前回の環境を再構築 ・S3バケットを作り直す ・Route53のレコードを修正 ・ロードバランサーの証明書を作成 ・Cloudfront用の証明書を作成 ・Cloudfrontの作成 ・Cloudfrontにでドメインを紐づけ ・動作確認 ・前回の環境を再構築 前回の記事の構成がされている場合は割愛してください。 構成されていない場合は下記の環境を再構築しましょう。 ・EC2インスタンスが2台立ち上がっていることを確認する。 ・RDSを削除した場合はスナップショットから復元する。 ・ALBを削除した場合は作成する。 ・S3を削除した場合は作成する。 ・HTTPS通信でブログを閲覧できることを確認する。 ・S3バケットを作り直す 前回の記事で作成したS3バケットを削除し、 「alb.aws-demo-xxx.ga」という名前の（ドメイン名と一致した）S3バケットを作成します。 ・Route53のレコードを変更 Route53で作成したレコード"blog.aws-demo-xxx.ga"を"alb.aws-demo-xxx.ga"に変更します。 ・ロードバランサーの証明書を作成 ロードバランサーのリスナーからどのサブドメインからでも使用できる証明書を作成します。 証明書のドメイン名は下記のようにアスタリスクをつけます。 「*.aws-demo-xxx.ga」 ＊前回の記事で作成した証明書は不要ですので削除しておきましょう。 この時点でalb.aws-demo-xxx.gaにてブログを閲覧できることが確認できます。 ・Cloudfront用の証明書を作成 [ここで注意があります] CloudFrontの証明書はバージニアリージョンでしか作成ができないため、 ELBの証明書は東京リージョンでCloudFrontはバージニアリージョンで作成します。 ACMのドメイン名は先ほどと同様に「*.aws-demo-xxx.ga」とします。 ・Cloudfrontの作成 alb.aws-demo-xxx.gaをOriginドメインネームとして作成を行います。 この時、プロトコルポリシーは「HTTPSのみ」となります。 キャッシュポリシーからキャッシュ時間を短く設定することも可能です。 SSL証明書に「*.aws-demo-xxx.ga」を選択します。 代替ドメイン名(CNAMEs)には「blog.aws-demo-xxx.ga」を記載します。 設定完了後、5分ほどでデプロイ完了となります。 　＊ディストリビューションドメイン名という聞きなれない値が表示されますが、 　　これはCloudFrontに直接アクセスするドメインとなります。 ・Cloudfrontにてドメインを紐づけ Route 53からCloudfrontまでのルーティングを定義 　レコード名「blog.aws-demo-xxx.ga」 今までの設定で２種類のドメインは下記のように紐づいた状態になります。 「blog.aws-demo-xxx.ga」 　→Croudfrontに紐づいている状態 「alb.aws-demo-xxx.ga」 　→ロードバランサーに紐づいている状態 動作確認 ２種類のドメインにアクセスし、動作に違いがあるか確認します。 「blog.aws-demo-xxx.ga」 「alb.aws-demo-xxx.ga」 ここでサイトトップページを変更した場合、albの方は直ぐ反映されることが分かります。 　 変更方法は過去記事を参照ください。 今回の動作確認で下記の事が分かりました。 ・「blog.aws-demo-xxx.ga」はCloudFrontと紐づいておりCloudFrontでキャッシュされたページが表示されている。 ・「alb.aws-demo-xxx.ga」は直接ロードバランサーのドメインを紐づいている。 今回の講座は以上となります。 サービス停止 お約束ですが、学習後は下記のサービスを停止しておきましょう。 ■EC2(オンデマンド)→時間単位または秒単位で計算されるため停止中にすること。 ■RDS(オンデマンド)→RDS の使用料は秒ごとに課金されるため、スナップショットを取って削除すること。 ■ALB→実行時間に対して時間単位、または1時間未満で使用料を課金されるため、削除すること。 ■S3→保存したオブジェクトのサイズ、保存した期間の長さによって課金されるため、削除すること。 ■ACM→費用が発生することは無いですが、不要ですので削除すること。 ハンズオン6に発生する費用一覧 ・EC2 x 2 ・RDS x 1 ・ALB x 1 ・Route 53 x 1 ・S3 x 1 ・CloudFront x 1 1時間に14円ほど費用が発生します。 最後に CloudFrontを設置する方法を学びました。 キャッシュサーバーを設置することでサイトの負荷がどのように軽減するのかとても気になりました。 効果があることが分かれば納得して使えますので、近いうちに実際に検証してみたいですね。 AWS CloudTechの課題としてこれらが残っていますので、 やったことを今後のQiita記事にして発信していきたいと思います。 これから始められる方の参考になれば嬉しいです。 今後の学習予定↓↓↓ ・CloudFormationの作成、更新 ・Lamda関数 ・Docker ・ECS 内容に不備がございましたら、ご指摘いただけますと幸いです。 今後の励みになりますので、良ければ「LGTM」をお願いします。 閲覧ありがとうございました。 この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」のハンズオンを基に作成しました。 https://aws-cloud-tech.com/

DMMデータインフラ部に所属しているyuuaです terraformで作成しlambdaをデプロイする際にterraformにlambda関数を含めるとchangeがでたり、扱いづらく 悩むときがあるのでその際の手順的な備忘録です 今回のlambdaはlambda containerではありません 初回の手順 1.terraformで基本的なlambdaの事前の情報を作成する(配置先など) 2.lambda関数をzip化しs3バケットに配置する 継続的なデプロイの手順 基本的にgithub actionsなどのCI/CDを使います 1.github actionsでlambda function / lambda layerをバケットに配置 2.github actionsでupdate functionの実行 下準備 lambdaを配置するようのs3 keyなどをterraformで作成します s3.tf // bucket作成 resource "aws_s3_bucket" "lambda_bucket" { bucket = "lambda-bucket" } // lambda関数配置するようのkeyを作成 resource "aws_s3_bucket_object" "lambda_function" { key = "functions/nodejs/" bucket = aws_s3_bucket.lambda_bucket.id } // layerを使う場合はlayer用も resource "aws_s3_bucket_object" "lambda_layer" { key = "layers/nodejs/hoge/" bucket = aws_s3_bucket.lambda_bucket.id } これで一旦 terraform apply を実施する lambda functionを配置 default のnode.js lambda aiu.js exports.handler = async (event) => { // TODO implement const response = { statusCode: 200, body: JSON.stringify('Hello from Lambda!'), }; return response; }; 上記を zip 化し先ほど作成したs3のkeyに配置します。 配置自体はcliでもconsoleでもciでも配置できれば何でも良いです lambdaのリソース定義 関数をs3に配置したらterraformでlambda関数を定義します lambda.tf data "aws_iam_policy_document" "role" { statement { actions = ["sts:AssumeRole"] effect = "Allow" principals { identifiers = ["lambda.amazonaws.com"] type = "Service" } } } resource "aws_iam_role" "role" { name = "${var.function_name}-lambda" assume_role_policy = data.aws_iam_policy_document.role.json } // logginなど必要であれば、適宜roleにattachなどしてください // 関数定義 resource "aws_lambda_function" "function" { function_name = var.function_name handler = var.handler role = aws_iam_role.role.arn runtime = var.runtime s3_bucket = bucketを指定 s3_key = 配置したkeyを指定 layers = [layerを使うのであれば指定] } terraform applyを実施する 上記でlambda関数の作成自体は完了です publishなどのoptionは適宜 継続的なデプロイをするために 基本的に一度作ったら終わりということはあまりないと思うので継続的なdeployをするために定義を作成します ここではgithub actionsを定義して、Pull Requestから各branchにPR close/mergeされたタイミングでdeployできるようにします 外部からdeployする際は iam で 必要な権限を付与したuserを作成し、そのユーザのsecretを使います。 ざっと必要になりそうな権限 s3:PutObject s3:GetObject s3:DeleteObject s3:ListBucket lambda:GetFunction lambda:UpdateFunctionCode lambda:UpdateFunctionConfiguration // layerがいるなら lambda:GetLayerVersion lambda:PublishLayerVersion lambda:ListLayerVersions lambda:AddLayerVersionPermission github actions定義 lambda function 下記はセルフホストランナーでの定義ですが通常通りgihtub hosting/セルフホスティングどちらでも問題ないです function.deploy.yml name: deploy-function on: pull_request: branches: - ブランチ名 types: [closed] jobs: update-functions: name: lambda deploy runs-on: [self-hosted, linux] if: github.event.pull_request.merged == true // mergeされたら処理継続 steps: - name: Checkout uses: actions/checkout@v2 - name: code build uses: actions/setup-node@v2 with: node-version: "14" cache: "npm" - run: npm install // 必要であれば - run: npx webpack // buildなどあれば // aws credentialを設定 - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v1 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: リージョン // zipファイルを作成 - name: compression working-directory: ./dist run: zip function.zip main.js - name: lambda update function codes working-directory: ./dist run: | aws lambda update-function-code --function-name function名 --zip-file fileb://function.zip // 必要であればpublish コードをzip化し aws cli の update-function-codeを実行しています これでPR Close/merge時にdeployが実行されます lambda layer layerはnodeの場合 nodejs/node_modules をzip化する必要があります ここではlambda functionとは別にlayer用のディレクトリを定義しそこにpackage.jsonをおいています layer.deploy.yml name: lambda-layer-deploy on: pull_request: branches: - develop types: [closed] paths: - "layerのpath/**" jobs: update-functions: name: lambda layer deploy runs-on: [self-hosted, linux] if: github.event.pull_request.merged == true steps: - name: Checkout uses: actions/checkout@v2 - name: code build uses: actions/setup-node@v2 with: node-version: "14" cache: "npm" - name: lambda layer working-directory: ./layer run: | mkdir nodejs cp package*.json nodejs/ npm install --prefix ./nodejs --production zip -r package.zip nodejs/node_modules - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v1 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: リージョン - name: lambda layer deploy working-directory: ./layer run: aws lambda publish-layer-version --layer-name layer名 --zip-file fileb://package.zip --compatible-runtimes nodejs14.x // 現在のlatestを取得 - name: lambda layer latest version id: step1 run: | layer=$(aws lambda list-layer-versions --layer-name layer名 --query 'LayerVersions[0].LayerVersionArn') echo "::set-output name=layer_ver::$layer" - name: lambda update configure run: | aws lambda update-function-configuration --function-name function名 --layers ${{ steps.step1.outputs.layer_ver }} //複数layerがある場合は ${{ hogehoge }} ${{ foobar }} このような形で続けてかけます まとめ terraformでlambdaのリソースを作成しつつ継続的なdeployはCI/CDで行う環境を備忘録的な形でまとめました。 IaCとlambda関数のcodeが分離され、意識することもすくないのでlambda containerを使わない場合は 今のところ一番使いやすいかなと思っています。 データインフラ部では、AWSでのビッグデータ基盤関連の運用を行っており、 様々リソースを活用したプロダクト開発を行っています。 中途採用などもおこなっておりますので、興味のある方は、一度弊社HPなどから カジュアル面談など、是非ご応募ください。

CodeBuildを使ってLambdaに対して自動デプロイしていたのだが、Layer部分で急にエラーが出るようになったので調べてみた。 TL;DR CodeBuild だけでなく、コンソールからの AWS CLI でも起きる update-function-configuration を利用しなければ影響はない Lambda関数の説明に「aws:states:opt-out」を追加すれば、取り敢えずは今まで通り動く 2021/12/1 以降は上記説明を付けても無理そうなので、検討必要 Error Log An error occurred (ResourceConflictException) when calling the UpdateFunctionConfiguration operation: The operation cannot be performed at this time. An update is in progress for resource: [ARN] ResourceConflictException さて、エラーログに例外が明記されていますので調べました。 しかし、上記で検索すると以下の解決策が出てきますが、これでは解決できません。 リソースが既に存在しているか、別のオペレーションが進行中です。 ということで、もう少し調べてみました。 update-function-configuration Layerの設定を行うコマンドなのだが、これを利用するときだけエラーが発生した。 使っているレイヤーに問題があるのかどうか考えたり、レイヤーの上書きが問題の可能性も考えたが、Layerを消すコマンド（「update-function-configuration」コマンドで空リストを指定するだけ）を使ってもエラーが起きたことから、「update-function-configuration」コマンド自体に問題があると想定して、コメントアウトするとエラーが出なくなったことから確信へと変わった。 the state of AWS Lambda functions あまり気にしていなかった（知らなかった）だけなのだが、どうやら Lambda には状態というものが存在するようです。 調査中なので割愛しますが、アップデートする際に「LastUpdateStatus」という状態があり、これが「InProgress」になっているとアップデート（上書き）出来ないようになっており、このタイミングで「update-function-configuration」をかけて失敗したものと思っています。 実際にエラーログにも「InProgress」と書かれていました。 何で急にこうなったのかはちゃんと調べます。。 解決策 取り敢えずは、Lambda 関数の説明文に「aws:states:opt-out」と書けば、従来通りに動いてくれました。 「opt-out」なのでデフォルトでは「ON」になっているんですね。。 最後に 常に情報をアップデートすることと、常に勉強しなくては、、と思いました。 Ref update-function-configuration Coming soon: Expansion of AWS Lambda states to all functions Tracking the state of AWS Lambda functions

こちらの記事を参考にAWSのデプロイを進めていると、最後の最後であるプリコンパイルで詰まる rake assets:precompile RAILS_ENV=production を実行すると長文のエラー よくみてみると error /var/www/rails/myapp/node_modules/node-sass: Command failed. node-sass周りに問題がある？ こちらの記事を参考に解決。 node -v v16.1.0 nodeのバージョンが非推奨だったようで記事の方法を試すと解決。

この記事を書いている私について インフラ系PMO歴半年でAWSクラウドプラクティショナーを取ったばかりの私が AWS CloudTechという動画学習サービスに参加し、AWSエンジニアを目指すための備忘録です 構築→記事作成→指摘反映の中で間違いがあったら業務でも発生するので、これからも気を引き締めて行きたいと思います。 本記事の目標 前回の「独自ドメインの設定/障害時にSORRYページへ通信を流す」に引き続き、 今回はAWS Certificate ManagerをセキュアなHTTPSで通信できるように設定を変更していきます。 前回の記事ではブログサービスにアクセスするのにHTTPで通信をしており、 このままではセキュリティに問題があります。 本記事ではAWS Certificate Managerで証明書を発行してELBにアタッチすることでHTTPS通信を可能にし、 ELBのセキュリティグループでHTTPS通信を許可する設定の追加なども行なっていきます。 今回の構成図 ※構成図の作成にcloudcraftを利用しています。 構築の流れ 以下の流れで構築を進めます。 ・前回の環境を再構築 ・ロードバランサーでHTTPS通信を受けるよう設定 ・ELBのセキュリティグループでHTTPS通信を許可 ・WordPressの対応 ・HTTPS通信が出来るか確認 ・HTTP通信の許可設定を削除 ・前回の環境を再構築 ・EC2インスタンスが2台立ち上がっていることを確認する。 ・RDSを削除した場合はスナップショットから復元する。 ・ALBを削除した場合は作成する。 ・S3を削除した場合は作成する。 ・前回取得したドメインでブログが閲覧できること確認する。 ＊余談ですが、前回までの復習になるので再構築はとても勉強になります。 　素早くミスなく構築したいので、近いうちにqwiklabsを使って反復練習をしてみたいと思います。 　年内にはqwiklabsを使った社内勉強会を開きたいですね。 ・ロードバランサーでHTTPS通信を受けるよう設定 リスナーを追加 　※リスナーとは通信を受付けるポートの許可設定のことになります。 転送先に作成したターゲットグループを選択し、ACM証明書を発行します。 完了すると、Route53のCNAMEに検証用のレコードが追加されます。 ・ALBのセキュリティグループでHTTPS通信を許可 インバウンドルールで、全てのIP（0.0.0.0/0)からのHTTPS通信を許可します。 　※私の体感ですが、証明書が発行されるまで数分時間がかかります ・WordPressの対応 この時、HTTPS通信を許可することでWordPressの仕様により、ブログの表示が崩れます。 その為、2台のEC2インスタンスに下記の設定ファイル(wp-config.php)にコードを追加することで対応します。 if($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') { $_SERVER['HTTPS'] = 'on'; $_ENV['HTTPS'] = 'on'; } この段階でまだ表示が崩れている場合はEC２インスタンスにログインして下記のコマンドを実行します。 UPDATE wp_options SET option_value = 'https://[独自ドメイン名]' WHERE option_name IN ('siteurl', 'home'); ※独自ドメイン名]はご自身で取得したドメインになります。 上記のコマンドによりRDSのDBに保存されているURLを更新することで正常にブログを表示することが出来ます。 ・HTTPS通信が出来るか確認 ブログのURLに鍵マークがついていることで確認します。 ・HTTP通信の許可設定を削除 HTTP通信を許可した状態だとセキュリティ上の問題があるためELBのセキュリティグループ・リスナーにて、HTTP通信の許可設定を削除します。 これにて課題は終了です。 サービス停止 次のハンズオンでも今回の設定を使いますので、サービス停止は行わず一気に次のハンズオンもやってしまうことをお勧めします。 一旦学習を止められる場合は下記のサービスを停止しておきましょう。 ■EC2(オンデマンド)→時間単位または秒単位で計算されるため停止中にすること。 ■RDS(オンデマンド)→RDS の使用料は秒ごとに課金されるため、スナップショットを取って削除すること。 ■ALB→実行時間に対して時間単位、または1時間未満で使用料を課金されるため、削除すること。 ■S3→保存したオブジェクトのサイズ、保存した期間の長さによって課金されるため、削除すること。 ハンズオン5に発生する費用一覧 ・EC2 x 2 ・RDS x 1 ・ALB x 1 ・Route 53 x 1 ・S3 x 1 1時間に13円ほど費用が発生します。 最後に AWS Certificate Managerで証明書を発行してHTTPS通信を行う方法を学びました。 当たり前のようにHTTPSを使って色んなサイトを見ていますが、自分で発行すると 普段見ているサイトがHTTPSになっているか気になってきますね→私だけ？(笑) AWS CloudTechの課題としてこれらが残っていますので、 やったことを今後のQiita記事にして発信していきたいと思います。 これから始められる方の参考になれば嬉しいです。 今後の学習予定↓↓↓ ・キャッシュサーバーの配置 ・CloudFormationの作成、更新 ・Lamda関数 ・Docker 内容に不備がございましたら、ご指摘いただけますと幸いです。 今後の励みになりますので、良ければ「LGTM」をお願いします。 閲覧ありがとうございました。 この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」のハンズオンを基に作成しました。

概要 タイトルの通り、Layerを用いて一部ライブラリを共通化しているAWS Lambda functionを、serverlessでローカル実行しようとした時につまずいたので備忘録として残しておく。 経緯 最近、趣味でAWS Lambda上で動かすpythonプログラムを作成していて、デプロイが楽になるとのことなのでserverlessを導入していた。 その際、functionを複数作成しており、一部ライブラリはLayerを用いて共通化していた。 作成したプログラムの構成は以下。 プロジェクトルートディレクトリ ├─function1 │ └─src │ └─handler.py ├─function2 │ └─src │ └─handler.py ├─layer │ ├─layer1 │ │ └─layer1のpythonライブラリ・ソース群 │ └─layer2 │ └─layer2のpythonライブラリ・ソース群 └─serverless.yml また、serverless.ymlの記述内容は以下。 （本記事に関係ない細かな設定については省略している） serverless.yml layers: layer1: path: layer/layer1 name: ${self:service}-layer1 compatibleRuntimes: - python3.7 allowedAccounts: - "*" layer2: path: layer/layer2 name: ${self:service}-layer2 compatibleRuntimes: - python3.7 allowedAccounts: - "*" functions: function1: handler: function1/src/handler.lambda_handler layers: - { Ref: Layer1LambdaLayer } - { Ref: Layer2LambdaLayer } function2: handler: function2/src/handler.lambda_handler layers: - { Ref: Layer1LambdaLayer } - { Ref: Layer2LambdaLayer } この設定でsls deployコマンドを実行すると、AWSへのデプロイは正常終了し、Lambda上でのpythonプログラムの起動もできるのだが、 何故かsls invoke local --function {function名}コマンドによるローカル実行は下記エラーが発生してうまくいっていなかった。 ModuleNotFoundError: No module named '{layerに配置したライブラリ名}' どうやら、ローカル実行するとlayerに配置したライブラリが参照できていないらしい。 AWSにデプロイするとちゃんと動くのに。解せぬ。 解決策 とにかくserverlessでローカル実行するとlayerをうまく参照できていないことがわかったので、コマンド実行時にオプションなどで設定を追加できないか公式ドキュメントを調べてみた。 …うーん、それっぽいオプションは見当たらない。 というかデータ入力の方法についての記述が大半でLayerについての説明なんかは皆無なんだなこれが。 とりあえずオプションを一通り試してみるかー、と半ばやけくそになりかけた時、気になる記述を見つけた。 --docker Enable docker support for NodeJS/Python/Ruby/Java. Enabled by default for other runtimes. 訳）--dockerオプションは、NodeJS / Python / Ruby / JavaのDockerサポートを有効にします。他のランタイムではデフォルトで有効になっています。 へー。pythonだとDockerはデフォルトで無効化されてるんだー。へー。 …ひょっとしてこれじゃね？ serverlessではなくAWS CLIを使ってLambda functionをローカルで実行するときは、ローカルのDocker上にLambdaの実行環境が作成されそこでfunctionが実行されることは知っていたのでそこから連想できた。 とにもかくにも、--dockerオプションを追加してコマンドをたたいてみる。 >sls invoke local --function function1 --docker Serverless: Running "serverless" installed locally (in service node_modules) （略） {"statusCode":200,"body":"{\"message\": \"finished . !\"}"} 動いた！！！ どうやらlayerが参照できなかったのは、docker上で動かしてなかったからだった模様。 作成したfunctionを正しく動かすためにはほぼ本番に近いdocker上の環境で動かす必要があるのに、その設定はデフォルトで無効になっているという…。 いやまあ毎回docker上で動かしていると実行が遅くなったりするし、Lambda functionはLayer使わないものが大半だったりするとデフォルト無効の意義も理解はできるんだが…。 ちょいと公式ドキュメントが分かりづらすぎやしませんかね？ 結論 Layerでライブラリを共通化したLambda functionがserverlessでローカル実行できない、といった事象に遭遇した方はコマンドに--dockerオプションを付け加えてみてはいかがだろうか。

TL;DR Resourceキーの値をLambdaのARNから、arn:aws:states::: Lambda:invoke に変更する Parametersキーを追加して、呼び出したいクロスアカウント 先のLambdaのARNを指定する クロスアカウント先のLambdaには、呼び出し元のAWSアカウントからの呼び出しを許可する必要がある 事前準備 AWSアカウントを2つ用意する(アカウントA, アカウントB) アカウントBに対して、以下のようなLambdaを用意する exports.handler = async (event, context) => { const response = { body: JSON.stringify({ foo: 'Hello, world', bar: 'Goodbye, world', }) }; return response; }; 手順 ステートマシンの定義 まずは、アカウントAで使用するStepFunctionsで使用するステートマシンの定義をしていきます。 今回は、呼び出しだけを確認したいだけなので、シンプルなものにしました。 ここで、大きなポイントとしては、Resource の部分で、LambdaのARNではなく、lambda:invokeを指定しているところです そして、Parameters の中の FunctionName で、呼び出し先のLambdaのARNを指定する必要があります。 こちらの2点を注意していただければ、クロスアカウントでのLambdaの呼び出しが可能になります。 { "Comment": "This state machine is for invoke cross account lambda.", "StartAt": "Exec", "States": { "Exec": { "Comment": "実行", "Type": "Task", "InputPath": "$", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": { "FunctionName": "arn:aws:lambda:ap-northeast-1:xxxxxxxx:function:cdkSampleFunction" }, "ResultPath": "$", "End": true } } } では、上記のステートマシンの定義ファイルを使って、アカウントAでステートマシンを作成します 作成すると、以下のようなフローになると思います Step Functionsで使用するRoleのポリシーは、以下のようになります { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": [ "arn:aws:lambda:ap-northeast-1:[AccountB]:function:[Function]" ] } ] } アカウントBのLambdaから、StepFunctionsの呼び出しを許可する 先ほどの手順で、StepFunctionsでのステートマシンが作成でき、Lambdaを呼び出す準備ができました。 ただし、このまま実行すると、クロスアカウント先(アカウントB)のLambdaを呼び出すことができないため、アクセス権限を付与していきます。 アクセス権限を付与するLambda関数のページを開き、[設定] タブで、[アクセス権限] を選択します。 [リソースベースのポリシー] ペインで、[アクセス権限を追加] を選択します。 [ポリシーステートメント] ペインで、AWS service を選択します。[サービス] ドロップダウンリストが表示されます。 [サービス] ドロップダウンリストで、[Other] を選択すると、テキストフィールドが表示されます。 [プリンシパル] に、StepFunctionsのステートマシンを作成したアカウント(アカウントA)の AWS アカウント ID を入力します。 [ソース ARN] に StepFunctionsのステートマシンのの ARN を入力します。 [アクション] ドロップダウンリストから [lambda:InvokeFunction] を選択します。 [ステートメント ID] に、ポリシー内で作成するステートメントを区別する一意のステートメント ID を入力します。 [保存] を選択します。 呼び出してみる 上記の手順を実施することで、呼び出し元のステートマシンと呼び出し先のLambdaの準備ができました では、早速、呼び出し元のアカウントAのステートマシンから、「実行の開始」を実行します そうすると、以下のようなグラフから、成功していることがわかるかと思います。 まとめ いかがだったでしょうか。 AWS StepFunctionsを使ったクロスアカウントでのLambdaを試してみましたが、意外と簡単に呼び出せることが、わかっていただけたかと思います。 呼び出したLambdaの実行結果をキャッチすることもできるので、クロスアカウントでの実行がより楽になっていくと思います。 参考URL

まずは参考URLを先に貼り付けておきます。これらを参考にすればうまいことssl化が出来ます！ はっきり申し上げます。僕ssl化するだけなのに６時間以上悪戦苦闘しました。 と言うのも、AWSのロードバランサー、ターゲットグループの設定が既存の記事とやることは一緒でも、異なる仕様に変わってしまっているからでした。 なので複数の記事を参考にしてまとめたものをアウトプットしていきます！ 前提条件 すでに（http://ドメイン名）でデプロイ済み ssl化の手順の確認 ACMの設定 TGの設定 ELBの設定 セキュリティグループの設定 Route53の設定 リダイレクト処理 ACMの設定 AWSではELB（後で設定します）を利用しているとACM（AWS Certificate Manager）を使用する事ができ、ACMで無料でSSL証明書を利用する事が可能です。 AWSの検索欄でACMを検索し開く 証明書のプロビジョニングを選択 ドメイン名記述 DNSの検証を選択 内容確認をして確定とリクエスト とりあえずこれで発行済みとなればOK！ これでssl証明書が発行されました。 TGの設定 ターゲットグループページに遷移 create target groupを選択 instancesを選択 以下のように設定 nextを選択 対象アプリにチェックを入れてinclude...をクリック 最後にcreate target group ELBの設定 ec2のところからロードバランサーを選択 ロードバランサーの製作を選択してさらに「http,https」の項目を選択 必要項目を記述していきます。 Basic configuration Network mappingは「ap-northeast-1a」「ap-northeast-1c」を選択 Security groupsは対象アプリのものを選択（ec2のインスタンスから確認できます） Listeners and routingは先ほど作った「アプリ名-TG」を選択 Create load balancerを選択してELBの作成が完了 作成したELBを選択して、さらにリスナーを選択し、リスナーの追加をする プロトコルポート：「HTTPS」「443」 デフォルトアクション：「アクションの追加」ボタンを選択 「転送先」を選択し、「アプリ名-TG」を選択 セキュリティポリシー：「ELBSecurityPolicy-2016-08」 デフォルトの SSL 証明書：「ACMから（推奨）」「ドメイン名」 保存ボタンを選択 セキュリティグループの設定 ec2の対象インスタンスからセキュリテイグループを選択 インバウンドルールからEdit inbound rulesを選択 以下のように選択 追加する Route53の設定 対象アプリのホストゾーンからAレコードを選択しレコードを編集 エイリアス先をONにして、東京時間、「アプリ名-ELBを選択」に修正する レコードセットの保存をする リダイレクト処理 ロードバランサーに移動 アプリ名-ELBを選択 [リスナー]タブを開く HTTP の[ルールの表示/編集]を選択 以下のように*を記述　（引用：https://dev.classmethod.jp/articles/alb-redirects/） 以下のように記述　（引用：https://dev.classmethod.jp/articles/alb-redirects/） 最後に 以上で完成になります。「https://ドメイン名」で検索してみてください。「http://ドメイン名」でも検索するとリダイレクト処理で「https://ドメイン名」に飛ぶはずですので確認してください。 これするのにまる1日かかったわ。。。