コンテナというかDockerの勉強をしようと思って例のごとく2～3年してないままです。 ちょこちょこDockerの概念とかコマンドは勉強しているものの、 dockerfileを書いたり、開発っぽいことをしたりはできていないです。 今回は、このあとDockerというかコンテナを勉強するにあたって、 何をしようかというのがわかった気がする動画と記事（ワークショップ）があったので紹介しておきます。 動画：難しい事抜きでまずはアプリケーションをコンテナ化してみよう ! #AWSDevLiveShow - YouTube 記事（ワークショップ）：コンテナ化のためのリアーキテクチャ（Re-Architecture for Containers） 続きを読む これまでこのブログやQiitaなどの記事で使っている画像はGoogle Driveに保存し、公開用のリンクをマークダウンに埋め込めるものに変換して

はじめに 前回記事「お名前.comで購入したドメインを使ってALBでECSにホストベースルーティングする」を拡張してデプロイパイプラインまで作ります。 全体図 前提 -　お名前.comでドメイン(example.com)を購入済み -　Route53でexample.comのホストゾーンを作成し、そのNSレコードをお名前.comで設定 -　ECRのプライベートリポジトリを作成後、アプリのイメージをpush済 -　(今回追加)GithubのトークンなどをSecretManagerに保存済 実装 ディレクトリ構成 前回の内容に下記を追加 buildspec.ts codepipeline.ts . ├── bin │ └── app.ts ├── cdk.json ├── jest.config.js ├── lib │ ├── app-stack.ts │ ├── getENV.ts │ └

やりたいこと ソース管理はGitHubを利用する。 GitHub flow 最終的にはAWS上のEC2に対してDeployを行う。 master push時には承認なしにDevelop環境にDeployしたい。 tag push時にはStaging〜Production環境にDeployしたいが、各環境Deploy時に承認が必要。 前提 諸々の事情で、AWS側でGitHubをSourceArtifactsとして動作することができない。 承認は、これも諸事情で、AWS側で実施したい。 本来はProduction環境はAWS上別アカウントにした方がベターなのでは？とは思うが、小さいシステムなのと、まだ最終的なプロダクトではないということで、同一アカウントのまま。別アカウントの場合は、クロスアカウントの考慮が必要。 結論 BuildはGitHub Actionsで実施する。 Build後、Zip

はじめに 2022 年 11 月にサポートされた CloudFront の Continuous deployment (継続的デプロイ) を検証する機会がありましたので紹介します。 また、この機能を利用してステージングディストリビューションへアクセスする際、Requestly という Chrome 拡張が便利だったのでこちらについても併せて紹介します。 CloudFront continuous deployment とは まず Continuous deployment がどのようなものかをざっくり確認します。概ね以下のような機能でした。 本番ディストリビューションをコピーしてステージングディストビューションを作成する ステージングディストリビューションは本番ディストリビューションの設定をベースにオリジンやビヘイビアを変更できる 本番ディストリビューションとステージングディストリビュー

Laravelかどうかに関係なく、ECS Fargate上のアプリのログをCloudWatchに表示させるには、ログを標準出力させればOK。Laravelの場合、config/logging.phpの「channel」部分を以下のように調整してあげるだけでよい。 'channels' => [ 'stack' => [ 'driver' => 'stack', 'channels' => ['single', 'stderr', 'stdout'], 'ignore_exceptions' => false, ], 'single' => [ 'driver' => 'single', 'path' => storage_path('logs/laravel.log'), 'level' => 'debug', ], 'daily' => [ 'driver' => 'daily', 'p

背景 Laravel には S3 を操作できる便利なライブラリ Flysystem が備わっていますが，これを使用するには AWS IAM ポリシー の設定が必要です。その設定方法を解説する記事は Qiita にも数多く見られますが，ほぼ揃って「AmazonS3FullAccess をアタッチする」と解説してます。 しかし AmazonS3FullAccess の権限内容を見てみると，実に多くの権限が設定されており，その数はなんと 84 個 。Laravel で行う S3 操作 はファイル取得/保存/削除くらいなので，ここまで大きな権限が必要とは考えられません。必要以上の権限を与えることは IAM のベストプラクティスに反します。 IAM のベストプラクティス: 最小権限を付与する IAM ポリシーを作成する場合、最小限のアクセス権を付与するという標準的なセキュリティアドバイスに従うか、タ

こんにちは、CX事業本部の若槻です。 AWS上に構築したシステムを外部サービスと連携する時はAWSでIAMユーザーのアクセスキーを発行することが多いですが、このIAMアクセスキーの作成は手動で行うと手数が多くなかなか手間が掛かり、また数が増えすぎると管理も大変になります。 そこで「IAMアクセスキーについても他のリソースと同様にAWS CDKで管理できないか？」と考えたのですが、その際にCDKスタックの再デプロイ時にアクセスキーの値が変更されてしまわないか？という懸念があり、今回実際に確認してみました。 確認してみた スタック初回デプロイ 発行したアクセスキーのIDとシークレットをAWS System ManagerのパラメータストアにString形式で格納しています。 lib/sample-app-stack.ts import * as cdk from "@aws-cdk/core"

はじめに GitHub Actions で Docker イメージをビルドして ECR にプッシュして ECS にデプロイするまでの手順をまとめます。 ディレクト構成 今回は以下のようなディレクトリ構成で進めます。 aspnetapp 以下には ASP.NET Core のプロジェクトがあります。 . ├── .github │ └── workflows │ └── deploy.yml ├── deploy │ └── ecs-task-def.json ├── aspnetapp │ └── aspnetapp.csproj など └── Dockerfile .github/workflows 以下に yml ファイルを配置します。 これにより、GitHub Actions を定義することができます。 deploy ディレクトリには、ECS タスク定義の JSON ファイルを配置し

こんにちは、CX事業本部 IoT事業部の若槻です。 GitHub ActionsではOpenID Connect（OIDC）がサポートされたため、AWSなどと安全にキーのやり取りが可能となっています。 Secure deployments with OpenID Connect & GitHub Actions now generally available | The GitHub Blog GitHub ActionsをAWSとOIDC連携する場合は、「ID Provider」と「IAM Role」をAWS上に作成する必要があるのですが、これらリソースをAWS CDKで作ってコードで管理するようにしてみました。 やってみた 以前作ったID Providerの確認、削除 以前にコンソールから手動で作成した同じくGitHubとのOIDC連携用のID Providerを取得します。 $ OP

【初心者向け】【入門】GitHub Actionsの書き方についてデバッグ設定、runs-onやcheckoutなどの仕組みや構造も含めて徹底解説LinuxGitHubGitHubActions 概要 GitHub Actionsの 仕組みや構造 基本的な書き方(ワークフロー、ジョブ、イベントなど) よく出てくるruns-on、actions/checkoutで何してるのか 環境変数とsecrets サービスコンテナ 環境のsetup 権限 について解説していきたいと思います そもそもGitHub Actionsとは 公式に GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and

はじめに NTTテクノクロス株式会社の渡邉洋平です。 今回はAWS CDKを使用して、「SPF、DKIM、DMARC設定を行ったAmazon SESを作成する方法」について解説します。 CDKでドメイン回りを設定するのは鬼門なのか、検索してもすぐに見つからない情報だったので、手を動かして実際に試してみました。 参考：SPF、DKIM、DMARC 送信元のなりすましを検出するための認証として「送信ドメイン認証」という技術が一般的にあります。 SPF、DKIM、DMARCの詳細は下記のような記事でも把握できるので割愛します。これら3つの対応をすべて実施することで、送信元の信頼性を高めることができます。 1. hostzoneの参照 ※前提として、送信元メールアドレスを事前に同じアカウントのRoute53のホストゾーンに設定してあるものとします。 まずはじめに、指定済みのホストゾーンをCDKのコ

こんにちは。ゲーソル新屋です。 今までAWS　CDKのデプロイメントポリシーの最小権限について考えたことはなく、なんかCDKがいい感じにやってくれてるんだろうくらいに思っていたのですが（実際そうですが） AWS CDK Security And Safety Dev Guideを読んでみて、AWS CDKデプロイメントで登場するロールとポリシーとその最小権限について、いくらか理解できた部分があるので、それを共有します。 ※本記事はCDKv2であることを前提にしています。 TL;DR CDKはCloudFormationがAWSリソースの変更をデプロイする アクター（開発者または自動システム）はデプロイをしない CloudFormationはアクターから CloudFormationExecutionRole というロールをPassRoleされ AdministratorAccess でデプ

やること メールを送信するために以下のステップを踏んでいきます。 もしご自身にとって不要なステップがあったら飛ばしてください。 IAMユーザーの作成 SESの設定 独自ドメインの取得 SESの設定 サンドボックス外への移動 Laravelの設定 IAMユーザーの作成 LaravelからSESにメールの送信リクエストをするには、認証のためにIAMユーザーが必要です。 （最終的に.envにIAMユーザーのアクセスキーやシークレットアクセスキーを記入します） そのため、まずはIAMユーザーを作成しましょう。 今回は以下のようなポリシーを作成し、このポリシーを直接IAMユーザーにアタッチしました（直接IAMユーザーにポリシーアタッチするのは良くないのですが、テストなので許してください笑） { "Version": "2012-10-17", "Statement": [ { "Sid": "Vis

morishitaです。 AWSのリソースを作るときにはコンソールをポチポチやるよりは Cloud Formation を使ったほうが楽に感じるようになってきました。 そんなところに aws-cdk が GA になりました。Typescript で Cloud Formation スタックが書けるということで気になっていました。 ちょっとググると DyanamoDB とか Lambda を使ってサーバレスアプリケーションを作りました的な記事が出て来るのですが、今回はちょっと地味にIAMユーザを作ってみました。 背景 当社ではほとんどのプロダクトで Docker Compose による開発環境を用意しています。 更に、いくつかのプロダクトでは本番DBのデータ1を含むDockerイメージを毎日ビルドしてECRにプッシュしています。それを Pull すれば、ほぼ最新の本番DB同様のデータをローカ

AWS CDKの公式機能でクロスリージョン参照が可能になりました（exprementalな機能です）。ACMとCloudFrontをクロスリージョン参照して構築してみたので、ソースを共有します。 AWS CDKでクロスリージョン参照できなくて、悔しい思いをしたことはありませんか？ 私はよくあります。 そんなときはcdk-remote-stackパッケージを利用すると解決できており、以前ブログも書きました。 AWS CDK（cdk-remote-stack）でACMとCloudFrontのクロスリージョン参照を実装する | DevelopersIO ところが、いつの間にかAWS CDK公式でクロスリージョン参照できるようになっていました！（2023/10/05時点では、まだexperimentalな機能です） aws-cdk-lib module · AWS CDK 以前のブログ同様、次の図