AWSにおけるコンテナワークロード運用のデファクトスタンダードの地位を確立したECS。 デプロイ方法も進化を続け、CodeDeployとALBで連携したB/Gデプロイやカナリアリリースにも対応し、そのデプロイにおける柔軟性はEKSに勝るとも劣りません。 そんなECSですが、手段が豊富になったこともあり現…
AWSにおけるコンテナワークロード運用のデファクトスタンダードの地位を確立したECS。 デプロイ方法も進化を続け、CodeDeployとALBで連携したB/Gデプロイやカナリアリリースにも対応し、そのデプロイにおける柔軟性はEKSに勝るとも劣りません。 そんなECSですが、手段が豊富になったこともあり現…
Amazon Web Services ブログ コンテナの世界での AWS Fargate の役割 2017 年、AWS は、AWS Fargate と呼ばれる大規模なコンテナを実行するサーバーレスサービスを導入しました。今日、お客様は毎週何百万ものコンテナをローンチしています。お客様が Fargate を好むのは、多くのインフラストラクチャにまつわる未分類の重労働から解放してくれるからだと繰り返し伝え聞いています。たとえば、お客様は EC2 フリートまたはコンテナランタイムのサイズ変更、スケーリング、パッチ適用、更新について責任を負う必要がなくなりました。 過去 2 年間で気付いたのは、Fargate は非常に斬新なアイデアであることから、お客様の中には大規模な AWS コンテナポートフォリオの特定のレイヤーに入れるのが難しいと感じていらっしゃる方もおられるということです。当社は、お客様
この記事はpushをトリガーとしたGitHub Actionsのワークフローを前提として書いています。 概要GitHub Actions、簡単便利で良いですね! ぼくも遅まきながら使いはじめ、先日、Git pushをトリガーにデプロイしてSlackで通知、とよくあるワークフローを追加して運用しはじめました。 Slackへの通知も Marketplace に数ある既存Actionを選んで利用すれば、すぐに実現できました。すごい! ぼくはこんな感じにしたかったとはいえ、贅沢を言えば、ぼくは レガシーなCustom integrationsのIncoming Webhooksでなく、きちんと新しいIncoming Webhooksでやりたいref: https://api.slack.com/legacy/custom-integrations#incoming-webhooksAction独自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く