© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. AWS 公式 Webinar https://amzn.to/JPWebinar 過去資料 https://amzn.to/JPArchive ソリューション アーキテクト 川﨑 一青 2019/9/25 AWS Fargate サービスカットシリーズ [AWS Black Belt Online Seminar] © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 自己紹介 川崎 一青 (かわさき いっ
関連記事 マイクロサービスを支えるインフラアーキテクチャ (AWS Dev Day 2019登壇資料) ECSデプロイツールを公開しました ECSにおけるログの取り扱いを別ページに移動させました 設計 基本方針 基盤を設計する上で次のキーワードを意識した。 Immutable infrastructure 一度構築したサーバは設定の変更を行わない Infrastructure as Code インフラの構成をコードで管理 (Terraformを採用) Serverless architecture 無駄にサーバを増やさない アプリケーションレイヤに関して言えば、Twelve Factor Appが参考になる。コンテナ技術とも親和性が高い。 ECSとBeanstalk Multi-container Dockerの違い 以前に記事を書いたので、詳しくは下記参照。 Dockerコンテナデプロイ
Containers Amazon ECS availability best practices We spend a lot of time thinking about availability at AWS. It is critically important that our service remains available even during inevitable partial failures in order to allow our customers to gain insight and take remedial action. To achieve this, we rely on the availability afforded us by Regional independence and Availability Zones isolation.
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
2020/04/14に加筆しました。 はじめに 2019年序盤から、値下げ、機能追加連発でとても利用しやすくなったAWS Fargateについて 弊社でも取扱が急速に増えてきましたので、代表的なパターンとして紹介させて頂きます。 ※こちらの記事ではコンテナ内部の設計/Fargate詳細については深く触れておりません。 なぜ/いつFargateを利用するか Fargate登場前までは、AWS上でコンテナを利用するためには、コンテナを動かす場所としてEC2が必要でした。 つまり、コンテナだけを動かしたいのに、EC2インスタンスを管理する必要がありました。 この状況がFargateの登場により、大きく変化しUpdateを重ねた結果多くの方が本番環境での利用に非常に前向きでいらっしゃいます。 Fargateを利用する = コンテナ運用を理解して設計するという事になりますので、ノウハウは必要となって
AWS (ECS + RDS)+ CircleciによるCI/CDの理解(初学者がインプットすべき情報)~用語と概念理解編~AWSCircleCIDockerECReks 導入のきっかけ ・いわゆるWeb系の現場ではコンテナのデプロイ+ CI/CDパイプライン構築が当たり前に組まれている 主なメリットとしてはフックとなる箇所(masterブランチにpushしたときなど)を指定してテスト~デプロイ~DBマイグレーションなどを自動でやってくれるというところ。それにより テスト~デプロイまでが一定の品質で自動でできる 開発者は商品価値を生み出す部分(機能の差別化など)に全力を注ぐことができる。 Web系のエンジニアとしてDevOpsの知見と後に出て来るような構成での構築スキルは武器になる最早必須であると考えた。 参考文献 【AWS Black Belt Online Seminar】Amazon
© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 【AWS Black Belt Online Seminar】 Amazon Container Services Ryosuke Iwanaga, Solutions Architect Amazon Web Services Japan K.K. 2018.02.20 © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 自己紹介 Ryosuke Iwanaga (岩永 亮介) • Twitter/GitHub @riywo Amazon Web Services Japan K. K. Solutions Architect • Containe
アマゾン ウェブ サービスの公式イベントのアーカイブおよびオンデマンドコンテンツの動画や資料がご利用いただけます。
CON414 Security best practices for AWS Fargate はじめに この記事はre:invent 2019 CON414 Security best practices for AWS Fargate のセッションレポートです。 セッションで使用されたコードはこちらで公開されています。 このセッションではシンプルなWebアプリを題材にFargateのセキュリティベストプラクティスについてデモを交えて解説が行われました。 記事と合わせてコードを参照して内容を確認するのをお勧めします。 セッション概要 In this session, we highlight several of the recommendations for container security on AWS Fargate. You learn about using a privat
AWS Startup ブログ スタートアップのためのコンテナ入門 – AWS Fargate 編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 前回「スタートアップのためのコンテナ入門 – 導入編」という記事を公開致しましたが、今回はスタートアップ企業に特におすすめな AWS Fargate についてご紹介します。 前回もお話しましたが、「そろそろコンテナやった方がいいか?」「なんとなく使い始めたけれどこれでいいのか?」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といった漠然とした課題感をお持ちの方は「スタートアップのためのコンテナ入門 – 導入編」から目を通して頂ければと思います。 ※ 本記事は Amazon ECS を前提に書かれております。(執筆時点では Amazon EKS に未対応であったためです。)Amazo
AWS Compute Blog Building, deploying, and operating containerized applications with AWS Fargate This post was contributed by Jason Umiker, AWS Solutions Architect. Whether it’s helping facilitate a journey to microservices or deploying existing tools more easily and repeatably, many customers are moving toward containerized infrastructure and workflows. AWS provides many of the services and mechan
【ACM】 サーバー証明書の有効期限切れ/自動更新失敗 ACMは、CloudFrontとELBと連携してサーバー証明書を提供するサービスです。 ACMで発行する証明書は1年毎に更新する必要がありますが、基本的には自動更新されます。 ただし、場合によっては自動更新が失敗するケースがあります。 検証の仕組みは、以下のドキュメントを確認してください。 自動ドメイン検証の仕組み 自動検証に失敗した場合、EメールおよびPersonal Health Dashboardで通知されます。 自動検証に失敗した場合 また、外部で発行された証明書を利用している場合は、手動で更新する必要があります。 再インポートの手順は、以下のドキュメントを参照してください。 証明書の再インポート EV証明書が必要なケースでも無ければ、ACMで証明書を取得してオペレーションが発生しないようにしておきたいですね。 【Route
意外と分からずに、「とりあえず」とか「なんとなく」で使っちゃうパターンが多い系案件な気がして書いてみます。 こんな事ありませんか? DIとDIコンテナの違いを説明出来ない DIとサービスロケータの違いを説明出来ない DIを使ってるつもりが、サービスロケータになっている DI、サービスロケータが、ただの「パターン」の1つであることを理解してない DI(Dependency Injection)を正しく理解する そもそも、Dependeny Injectionを日本語にするとどういう意味になるでしょうか。 多くの人が「依存性の注入」とか応えるのではないでしょうか? 私もそうでした。きっと何かで読んだのでしょう。 (wikipediaに「依存性の注入」と書いてありますね) 補足 なぜ依存性を注入してあげると良いのか、そのメリット等は後述しますが、 DIというのはただのパターンの1つです。 たまに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く