はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 ALBのリスナールールの変更とLambdaの追加でベーシック認証を行います。 ベーシック認証の処理の流れとしては以下となります。 ALBでAuthorizationヘッダーを検証する 認証OKであれば、正規のターゲットグループに転送する 認証NGであれば、Lambdaをターゲットとするターゲットグループに転送する Lambdaではベーシック認証を要求するレスポンスを返す(なお、ALBからのヘルスチェックに対しては200を返すようにします) 1. Lambda関数の作成 まず、ALBが存在するリージョンで、Lambda関数を作成します。 一から作成を選択 関数名を入力(今回はBasicAuthとします) ランタイムはNode.js 12.xを選択 実行ロールは基本的な Lambda アクセス権限で新しいロールを作成を選択 VPCは特に何も選択しない 関数の作成ボタンを押下 index.

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに CodeDeployはALBを使って、複数台あるEC2を順次 振り分け停止 デプロイ実施 振り分け再開 する、といったデプロイ方法を取ることが可能です。 これを試してみたところ、想像していたよりもデプロイに時間がかかってしまいました。 また、ターゲットグループの設定を見直すことで処理時間を短縮できるので、その点も含めて記事化しています。 1. 構成 ALB EC2インスタンス * 2 ALBのターゲットグループでは、以下の通り2台のEC2インスタンスを登録しています。 この2台がCodeDeployのデプロイ対象です。 2. CodeDeployのデプロイグループの設定 ALBを使ったデプロイでのCodeDeployの設定です。 2.1. デプロイタイプ デプロイタイプはインプレースとしました。既存のEC2インスタンスに新しいアプリケーションをデプロイします。 なお、Blue/G

「俺はactions/cacheをやめるぞ！〇〇〇〇ーッ!!」 はじめに S3にキャッシュするアクションを作成しました。 GitHub Actions公式のキャッシュ機能であるactions/cacheは、 Pull Requestでコケた時にRe-run jobsするとactions/cacheアクションが正常に動作しない actions/cacheアクションは時折キャッシュの取得に失敗することがある などの問題を抱えているようです。 詳しくは、こちらのブログ記事を参照ください。 GitHub Actionsの知見ご紹介 - Masteries 加えて、キャッシュの容量はリポジトリごとに5GBとのことなのですが、明らかに容量オーバーしていないはずなのに、キャッシュミスが発生していることがあるような気がします。 そこで、今回S3に独自にキャッシュさせるアクションを作成しました。 今のところ

はじめに あなたは何かWebアプリケーションを作っているとします。 このWebアプリではItemというモデルを取り扱っていて、複数のItemを一覧で見る画面や、個々のItemの詳細を見る画面があります。 /itemsにアクセスしたらItemの一覧画面が表示されて、items/1やitems/2にアクセスしたら、それぞれのidのItem詳細画面が表示されます。 各モデルに所有者がいたとして さて、このItemですが、それぞれに所有者が存在するとします。 idが1であるItemの所有者はAさん、idが2であるItemの所有者はBさん・・・といった具合です。 AさんもBさんもこのWebアプリにユーザーとしてログインできるのですが、全てのItemを見ることはできなくて自分の所有するItemだけを見ることができる、という要件があなたが作るWebアプリに求められているとします。 その為に何をする必要が

はじめに GitHub Actions公式のキャッシュ機能であるactions/cacheは、 Pull Requestでコケた時にRe-run jobsするとactions/cacheアクションが正常に動作しない actions/cacheアクションは時折キャッシュの取得に失敗することがある などの問題を抱えているようです。 詳しくは、こちらのブログ記事を参照ください。 GitHub Actionsの知見ご紹介 - Masteries 加えて、キャッシュの容量はリポジトリごとに5GBとのことなのですが、明らかに容量オーバーしていないのに、いつのまにかキャッシュが追い出されていることがあるような気がします（検証はして無いので、私の思い込みかもしれません)。 そこで、actions/cacheを使わず、S3に独自にキャッシュさせることにしました。 今のところ、快適に動いているので、今回その内

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

AWS Lambdaのアプリケーション作成とは AWS Lambdaのアプリケーション作成機能を利用してLambda関数を作成すると、Lambda関数自体の他に Lambda関数のソースコード等を管理するGitリポジトリとしてCodeCommit CodeCommitのmasterブランチの更新を契機にLambda関数へのデプロイを行うCodePipeline 等々、CI/CDパイプライン実現のためのAWSリソースが同時に作成されます。 Lambda関数自体は手軽に作ったものの、次のステップとしてCI/CD環境を構築するのは腰が重く、ソースの更新はマネジメントコンソール上で実施している・・・といったケースを改善するアプローチとして、このようなCI/CD環境をセットで構築する機能がリリースされたそうです。 Lambdaのマネジメントコンソール画面では、これらAWSリソースをアプリケーションと

本記事の対象者 AWS初心者の方 AWS初心者向けのチュートリアル、ハンズオンなどでマネジメントコンソール画面を用いてシンプルな構成を構築した経験のある方 上記をマネジメントコンソールではなく、ファイルを使って構築することに関心のある方 本記事で行うこと AWSのサービスのひとつであるCloudFormation用のテンプレートファイルを作成し、パブリックサーバー、プライベートサーバーを持つシンプルな構成を構築していきます。 テンプレートファイルとは CloudFormationは、テンプレートファイルというものを読み込ませることでAWSのリソースを一括して構築してくれます。 テンプレートファイルの形式はJSONかYAMLを選択できますが、今回はYAMLで記述することにします。 エディタ 私は普段JetBrainsのIDEを使用しているのですが、CloudFormationのプラグインが存

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up