CloudFormationのスタックを間違えて上書きデプロイしちゃったので、対策としてスタックの命名を自動化した | DevelopersIO
先日、既存のCloudFormationスタックを間違えて上書きデプロイしてしまいました。気づいたときには後の祭りです（再デプロイで復旧しました）。 そこで今回は、発生したことの整理と対策を考えてみました。 前提 リポジトリとCloudFormation（AWS SAM）のスタックは次のような関係です。 AWS SAMのテンプレートファイルを使用していた 1つのリポジトリに対して、1つのCloudFormationスタックを作る 発生したこと 単純なミスでした。でも怖い……。 新しいリポジトリRepository-Xを作成した 既存リポジトリRepository-Aのデプロイコマンドをコピーした このとき、デプロイコマンドのスタック名がRepository-A-Stackとなっていた（★修正漏れ） これに気づかず、新規作成したRepository-XリポジトリをRepository-A-S
Cookie使用の同意を求めるポップアップを表示する (Cookie Consent by Osano)
Web Cookie使用の同意を求めるポップアップを表示する (Cookie Consent by Osano)※当サイトにはプロモーションが含まれています。 1. 一般データ保護規則 (GDPR) 2018年5月25日から EU 一般データ保護規則（GDPR） が適用され、EU向けに提供しているウェブサイトでクッキーを使用している場合、「クッキーの使用について利用者に同意を得る必要がある」ということになりました。 2. Cookie Consent by Osanoクッキー使用の同意を求めるポップアップを表示するには、いろいろなやり方があると思いますが、Osano という組織が提供している Cookie Consent というツールを使うと比較的簡単に実現可能です。 Cookie Consent (Open Source 版) の利用方法この Cookie Consent には「Osan
トップページ -
増分テスト： クイックスタートガイド（計算付き） キャンペーンが成功したとき、あなたはどのように分かりますか？先月よりも収益が増えたとき？ たぶん。 しかし、あるキャンペーンやチャネルが売上にどれだけ影響したかを知るにはどうしたらよいでしょうか？ マ…
AWS FargateでFireLensを使って同じログを3箇所に送ってみた | DevelopersIO
Fluent BitとFluentd Firelensで起動するログルーティングのコンテナは同じタスク内にサイドカーとして起動します。 軽量なコンテナの方が嬉しいのでFluent Bitを採用しました。 参考： Fluent Bit による集中コンテナロギング | Amazon Web Services ブログ 設定ファイル込みのイメージ作成 同じログ内容を合計3箇所の出力先へ送るシンプルなFluent Bitの設定を作るところからはじめます。Fluent Bitの設定次第で特定のログであればCloudWatch Logsへ、それ以外はS3バケットへ送信も可能です。Fluent Bitのドキュメントまで読みきれなかったので細かい設定は断念。 Fluent Bitの設定ファイル作成 各プラグインの設定はFluent Bitドキュメントを参考に出力先を設定しました。 S3へ直接する保存する場合
CLI ツールの出力を JSON にする jc コマンドの使い方のメモ。 - 全力で怠けたい
jc コマンドの使い方 jc コマンドとは インストール方法 使い方 -p オプション: JSON の出力をフォーマットする -m オプション: JSON をモノクロ出力する -r オプション: JSON を raw 出力 -a オプション: jc コマンドの使い方を出力する 互換性 その他 Twitter で見かけた jc コマンドが便利そうなので少し使ってみたメモ。 jc コマンドのバージョン。 $ jc -a | jq -r .version 1.13.4 jc コマンドの使い方 jc コマンドとは jc JSONifies the output of many CLI tools and file-types for easier parsing in scripts. jc コマンドはいろいろな CLI ツールとかファイルタイプの出力を JSON 化するので jc コマンドの出力
CloudFormationのスタック間でリソースを参照する | DevelopersIO
ども、大瀧です。 昨日Cloudformationの大規模アップデートが有り、YAMLサポートや新しい関数などと共に異なるスタックのリソース参照機能が追加されました。 今回は異なるスタックのリソース参照機能について試してみた様子をレポートします。 これまでのスタック間参照 これまでCloudFormationには、独立したCloudFormationスタック(単一のCloudFormationテンプレートから作成されたリソース一式)同士でリソースを参照する方法はなく、リソース名やリソースIDをパラメータに入力するか、テンプレートにハードコードしていました *1。 シェルスクリプトで複数のCloudFormationスタック作成を自動化するときは、aws cloudformation describe-stack-resourcesのレスポンスをパースして次のスタック作成のパラメータに代入な
CQRS パターン - Azure Architecture Center
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 CQRS はコマンド クエリ責務分離を表し、データ ストアの読み取りと更新の操作を分離するパターンです。 アプリケーション内に CQRS を実装すると、そのパフォーマンス、スケーラビリティ、セキュリティが最大化される場合があります。 CQRS への移行によって生まれる柔軟性により、システムは時間の経過と共にさらに進化し、更新コマンドでドメイン レベルのマージ競合が発生することを防ぐことができます。 コンテキストと問題 従来のアーキテクチャでは、データベースの更新とクエリに同じデータ モデルが使用されます。 このシンプルな方法は、基本的な CRUD 操作に適しています。 ただし、複雑なアプリケーションの場合、こ
簡易 CQRS で「画面に ~~ も表示したいんだけど」に強い API を実装 - Qiita
はじめに x と y と z を JOIN して COUNT した値を画面に表示したいなど、画面が要請する値を DB からごにょごにょと集計して API で返したくなることがあります。1 そんなとき、DB のモデルをドメインモデルにマッピングし、ドメインモデルを API のインターフェースにマッピングして返すような実装をしていると、以下のような問題にぶつかります。 集計後の値を取得したいだけなのに、大量のオブジェクトをアプリケーションのメモリ上にロードすることになる ちょっと取得する値を追加・変更するだけでもドメインモデルに影響が出てしまう 使っている O / R マッパ によっては N + 1 問題が発生しやすい ドメインモデルを集約単位で扱っていると、アプリケーション上で JOIN の処理を実装することになる この記事では、簡易的な CQRS で上記の問題を解決してみます。 CQRS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://ift.tt/3s1BDTR
GitHub - CodeverDotDev/codever: Bookmarks, Snippets and Notes Manager for Developers & Co (website)
YAML Beautifier Online
Formatting Dates and Times
https://www.youtube.com/hashtag/rsgt2021