目次 はじめに 事前準備 SES制限緩和申請 SES作成 EC2ロールにSESポリシーをアタッチ バウンス、苦情対策 DMARC設定 DNS登録 ログ出力設定 参考情報 1.はじめに 皆さんこんにちは、奥平です。 今回はSES環境を構築したいと思います。 SES環境構築を書いた理由につきましては、2022年になってSESのWEB画面（UI）が大きく変更があり、英語だらけになってしまい、構築しづらいと思ったのでナレッジ残しとして記事にしました。 ※今回はSES構築を中心としますので、IAMロール作成やSNS作成、その他リソース作成につきましては省略致します。 ※本当はCLI等で構築出来るようになった方が良いのですが、それはまたの機会に致します。 2.事前準備 テスト用DNSサービスをRoute53に登録しておいてください。 今回は下記テスト用ドメインを用意しました。 SESテスト用ドメイン：
お知らせ 2022年初頭に本記事を元にしたAWS書籍が技術評論社より全国出版決定いたしました。 関係者各位のご協力に深く感謝いたします。 タイトル：AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ 本書籍出版までの制作プロセス、チーム執筆の方法論などをまとめました チームで技術書を出版して学べた共同執筆メソッド はじめに インフラ初学者がAWSを用いた設計・構築レベルに到達するため、学習の全体像をロードマップ図にまとめました。 背景 パブリッククラウド全盛期においてAWSは全エンジニアにとって「常識」となりました。 しかしながら、情報過多によってAWS学習に必要な情報がネット上のノイズに埋もれてしまい、初学者の直感による判断が誤った学習に行き着くこともあります。 このロードマップはAWS学習の全体像を俯瞰でき、パブリッククラウドを用いた設計・構築レベルに到達するまで導く体系的なス
Docker Desktopのインストールが簡単にできるようになったという記事を拝見したため、Overleaf Community Editionを設定してみたメモを作りました。 GitHub - overleaf/overleaf: A web-based collaborative LaTeX editor Docker Desktopをインストールします 以下から最新版をダウンロードしてインストーラーを実行しました。 インストール後にWindowsからのサインアウトが必要でした。 Docker Desktop for Mac and Windows | Docker つまづいたときは以下の記事を参考にすると良いと思います。 Windows 10 HomeへのDocker Desktop (ver 3.0.0) インストールが何事もなく簡単にできるようになっていた (2020.12時点
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? AWS re:Invent 2020の会期中に発表された新サービス/アップデートのまとめです。 今年も、後から出来るだけ素早く簡単に振り返ることができるようにまとめました！ 凡例 (無印) 新サービス (Update) 既存サービスのアップデート (APN) パートナー制度に関連したリリース/アップデート 12/1 (火) 今年の開幕は**「Amazon EC2 Mac instances」**でした。 Amazon EC2 Mac instances macOS用のAmazon Elastic Compute Cloud （EC2）
2020/8/23 追記 2.3.5.0 の Edge release で削除されてしまった模様です。 今後の統合方法を検討するということで、続報を期待します。。 Docker for Mac の Edge channel で、 Mutagen ベースのキャッシュが使えるようになっています。(手元のバージョンは 2.3.1.0) 従来、 EC-CUBE をはじめとする Symfony をベースとしたアプリケーションや、Composer や npm などのパッケージ管理システムのファイルをマウントすると、強烈に遅くなる問題がありました。 今回利用できるようになった Mutagen ベースのキャッシュを利用するには、 Preferences -> Resources -> FILE SHAREING でマウントするディレクトリを指定 キャッシュを ON にするだけ。 です。 あとは通常通り、ア
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 記事の概要 GitHub Flowでの開発、つまり単純なプルリク運用での開発を、営業も巻き込んで実践したいと思い、そのような環境を作りました。その際、いくつか足りない機能を補うウェブアプリを作って公開したので、それに関する様々な話を書きます。 （実際にこのウェブアプリを使えるかどうかというよりは、似たようなフローで開発を改善できるといいなというような目的の話です。） ウェブアプリのリポジトリ このウェブアプリの使い方と機能については、一応README.mdに書いていますが、この記事では少し背景的な話も含めて順番に書きます。 issue対
AWS バックアップってなんですか？ AWS Backup は、AWS Storage Gateway を使用して、オンプレミスだけでなくクラウド内で AWS のサービス全体のデータのバックアップの集中管理と自動化を簡単に実行できる、完全マネージド型のバックアップサービスです。 EC2 のバックアップ集中管理と自動化に対応しました。 以下の AWS Blog 1月14日号で発表がありました。 https://aws.amazon.com/jp/blogs/aws/aws-backup-ec2-instances-efs-single-file-restore-and-cross-region-backup/ AWS Backup に以下3つの機能が追加されました。 you can now back up entire Amazon Elastic Compute Cloud (EC2) i
このストーリーの登場人物は以下の2人です。 依頼人 = アプリケーションエンジニア or マネジメント層（適宜文脈によって読み替えてください） 匠 = インフラエンジニア Before まずは依頼人が抱えるお悩みについて話を聞いてみることにします。 インフラ構成 依頼人のサーバ構成は、 Sidekiq では標準的な構成を採用していました（図1, 2）。 Web ノードでタスクを Redis 登録し、 Worker ノードで Redis からタスクを取り出し実行します。 Web ノードは API として外部に公開されているほか、 Sidekiq の GUI として利用しています。 各ノードは AutoScalingGroup を構成していますが、台数固定で稼働しています。 図1. サービス構成: 図2. AWS構成図: 以下の文章では、便宜的に以下の用語を用います: マスターノード: タスク
version: 0.2 phases: pre_build: commands: - echo Logging in to Amazon ECR... - echo $AWS_DEFAULT_REGION - $(aws ecr get-login --no-include-email --region $AWS_DEFAULT_REGION) build: commands: - echo Build started on `date` - echo Building the Docker image... - docker build --no-cache -t $IMAGE_REPO_NAME:$IMAGE_TAG . - docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGI
最近、GraphQL APIをインターネット上に晒す上で何を考慮したらいいのだろうか、的なことを考える機会が多く、空いた時間でチマチマと素振りしています。 今日はGraphQLのクライアント - サーバー間に挟むリバプロ的な機能について書いてみようと思います。 やりたいこと 1. 想定しないクエリの排除 例えばECやメディアサイトのような、未ログインでも情報の閲覧が可能なサービスのWeb API層をGrahpQLで実装したとします。ECにしろメディアにしろ、詳細ページでの回遊率を上げるため、詳細同士を関連付けるようなスキーマ設計となるのは自然なことでしょう。 GrahpQLのスキーマ定義で書くと、下記のようなイメージです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く