並び順

ブックマーク数

期間指定

  • から
  • まで

361 - 400 件 / 1508件

新着順 人気順

ecrの検索結果361 - 400 件 / 1508件

  • ElastiCacheでメモリ一斉開放はどのくらいCPU使用率が上がるのか検証してみた | DevelopersIO

    こんにちは(U・ω・U) ElastiCacheおじさんを目指して日々鍛錬を続ける深澤です。 立派なElastiCacheおじさんに成長することを決意したラスベガスでの出来事でした。 — 深澤俊 (@shun_quartet) December 4, 2019 まだ見習いです。 さて皆さんElastiCacheでメモリがモリモリになったご経験はありますでしょうか。運用をご経験された方には分かるかもしれませんがキャッシュでメモリ使用量がモリモリ成長していくのはとっても恐怖ですよね!!さて今回はそんなモリモリになったメモリを一斉に開放した時、ノードへの負荷がどうなるのか実際に検証してみました。 環境 ElastiCache for Redisに対してやってきます。ノードタイプですが、今回はcache.r4.largeを選択しました!搭載メモリは12.3GBですね。 ノードにデータを投入するには

      ElastiCacheでメモリ一斉開放はどのくらいCPU使用率が上がるのか検証してみた | DevelopersIO
    • Content Security Policy のレポートを収集するためにやったこと - Classi開発者ブログ

      はじめに こんにちは、開発本部所属エンジニアの id:kiryuanzu です。 現在、Classi ではサービスのセキュリティリスクをできる限りなくすために Content Security Policy を導入して脆弱性を検知する仕組みの導入を進めています。 本記事ではこの仕組みを導入する上でどのような手順が必要であり、どのような箇所で苦戦するポイントがあったかについて紹介していきます。 筆者は今まで CSP対応に携わったことがなかったのですが、導入段階の時点で想定していたよりも様々な知識が必要なことがわかり、記事にしたいと思いました。 もし数ヶ月前の自分と同じように初めてCSP対応に関わる人の一助となれば幸いです。 Content Security Policy (通称: CSP) って何? Content Security Policy とは、HTTPヘッダの種類の1つであり、クロ

        Content Security Policy のレポートを収集するためにやったこと - Classi開発者ブログ
      • EKS(Kubernetes)上にDigdag・Embulk・Redashで分析環境を構築する - Koichi Ishida blog

        目次 ワーカーノードの作成 DigdagとEmbulkのDockerビルド KubernetesにDigdag/Embulkをデプロイ Redashの導入 まとめ Kubernetes上に分析環境を構築する機会があったのでどのように構築したかを紹介します。同じような構成でKubernetes上で構築するのは3回目になったので構築方法も洗練されてきました。構成は以下のようになっています。 MySQL(RDS): サービスのデータベース。ここのテーブルからBigQueryにEmbulkでデータをエクスポートします。 PostgreSQL(RDS): Digdagのデータベース。今回新たにつくりました。 Digdag: データベースのエクスポートなどを実行するタスクスケジューラ。失敗したときにリトライもできます。 Embulk: プラグインを使ってデータベースをMySQLからBigQueryにエ

          EKS(Kubernetes)上にDigdag・Embulk・Redashで分析環境を構築する - Koichi Ishida blog
        • 【転職会議】ArgoCDで実現するストレスフリーな新GitOps基盤 - LIVESENSE ENGINEER BLOG

          こんにちは、かたいなかです。 最近、転職会議のCI/CD基盤をFluxベースのものからArgoCDベースのものに式年遷宮しました。今回の記事では、新しいArgoCDでのCI/CD基盤について、作り直しに至った経緯や改善点をご紹介します。 ArgoCD移行に至った経緯 転職会議では、以前の記事でも紹介したFluxというGitOpsのツールを使用してGitOpsを実現していました。 made.livesense.co.jp しかし、その後FluxからFlux2への移行が公式から推奨されるようになった後も、Flux2やArgoCD Image Updaterへの移行ができない状態が長く続いていました。 また、現行のフローでも以下のような大きな問題点を抱えていました。 ロールバックできない問題 チャットボットが老朽化 Weave Cloudがサービス終了 以下でそれぞれ説明します。 ロールバックで

            【転職会議】ArgoCDで実現するストレスフリーな新GitOps基盤 - LIVESENSE ENGINEER BLOG
          • コンテナ好き4名がコンテナの魅力を喋り倒すJAWS-UGコンテナ支部に行ってきた #jawsug_ct | DevelopersIO

            「懐かしのツイートと振り返るAWSコンテナサービスアップデート」 最近、twitter芸人の様相を呈しているポジティブなTori(@toricls)さんの、AWSコンテナ関連サービスのアップデート。 最初から最後まで一貫して、Toriさんのツイートをもとにアップデートを語っていくという斬新なスタイルで、2018年8月以降のアップデートについて語ってくれました。 自分、AWSのコンテナ関連サービスについては、ほぼほぼ全て目を通してブログを書いているつもりなんですが、改めてこうやって網羅的に棚卸しをしてもらったおかげで知ってるつもりで完全に抜けていたものが結構あったので、再復習できてよかったです。 ハマコーなりに重要だとおもうアップデート トリさんセッション中、自分の琴線にふれたアップデートと、Developers.IOのリンクを貼っていきます。気になる方は、今一度復習してみると良いかもね!D

              コンテナ好き4名がコンテナの魅力を喋り倒すJAWS-UGコンテナ支部に行ってきた #jawsug_ct | DevelopersIO
            • [初心者向け] GitHub ActionsからECS FargateにCI/CDしてみた | DevelopersIO

              こんにちは!コンサル部のinomaso(@inomasosan)です。 本記事はGitHub Actions Advent Calendar 2021の20日目の記事です。 投稿が遅くなってしまい申し訳ございません! GitHub ActionsからECSへ簡単にCI/CDできると聞いたので試してみました。 いくつか参考ブログはあったのですが、ワークフローのテンプレートが古くなっていたりしたので改めてブログにまとめてみました。 前提 以下の環境を構築している必要があります。 DockerイメージレジストリにECRを使用 ECSでコンテナを起動中 GitHub Actionsワークフローについて 今回はGitHub ActionsのDeploy to Amazon ECSというテンプレートからワークフローを作成します。 テンプレートの大まかな内容は以下の通りです。 ECRにログイン Dock

                [初心者向け] GitHub ActionsからECS FargateにCI/CDしてみた | DevelopersIO
              • freeeサインのAWSリージョンを移行した話 - freee Developers Hub

                この記事はfreee 基盤チーム Advent Calendar 2023 の24日目の記事です。 はじめに はじめまして! kanno と申します。freee SREで、freeeサインのプロダクトSREを担当しておりAWSインフラの改善や運用を主に行っています。初回の投稿で拙い文章になりますが、直近で実施したfreeeサインのAWSリージョンを移行した話を書こうと思います。 背景 元々、freeeサイン(旧ninja-sign)はHeroku上にアプリケーションをデプロイしていましたが、2022年の年末頃にAWSに移行しています。その際、元々のHerokuがus上で稼働していたことが影響して、AWSのバージニアリージョンに移行された状態でした。私がfreeeのサインチームにjoinしたのがこの時で、AWSリージョン移行を担当することになりました。 AWSリージョン移行のモチベーション

                  freeeサインのAWSリージョンを移行した話 - freee Developers Hub
                • Docker HubのイメージプルがDownloadRateLimitで失敗する問題を、認証を利用して対処した話 - ANDPAD Tech Blog

                  明けましておめでとうございます、ANDPAD SREチームの@DanKadoiです。 AWSサポートの一歩進んだ使い方 ~問い合わせの極意編~ の節はありがとうございました。 今回はDocker Hubのイメージプルについて書こうと思います。 困っていたこと 弊社ではいくつかの用途でDocker Hubからイメージプルしていましたが、主に以下のユースケースでDownlowdRateLimitによる失敗が頻発しました。 ECRのPrivateリポジトリでホスティングしたい自前のDockerイメージを、CodeBuildプロジェクトでビルドしているケース [1/2] FROM docker.io/library/mysql:5.6 resolve docker.io/library/mysql:5.6 resolve docker.io/library/mysql:5.6 3.0s done

                    Docker HubのイメージプルがDownloadRateLimitで失敗する問題を、認証を利用して対処した話 - ANDPAD Tech Blog
                  • Amazon ECRとInspectorのイメージスキャン機能の違い - Qiita

                    脆弱性の検知対象 基本スキャンはオープンソースの Clair プロジェクトの CVE データベースを使用したスキャンを提供します。脆弱性の検知対象は OS パッケージのみです。 拡張スキャンは OS パッケージに加え、プログラミング言語パッケージの脆弱性を検知することが可能です。対応するプログラミング言語は以下のとおりです。 C# Golang Java JavaScript PHP Python Ruby Rust 脆弱性の検知タイミング 基本スキャンはイメージが Push された際にスキャンを起動する (Scan on push) か、手動でスキャンを開始することができます。そのため脆弱性を検知できるタイミングもそのどちらかになります。手動スキャンの実行は各イメージごとに24時間に1回に制限されます。 拡張スキャンではリポジトリに対し連続スキャンを利用することができます。連続スキャンは

                      Amazon ECRとInspectorのイメージスキャン機能の違い - Qiita
                    • Amazon SageMakerを利用したエンタープライズのためのMLOps基盤ロードマップ | Amazon Web Services

                      Amazon Web Services ブログ Amazon SageMakerを利用したエンタープライズのためのMLOps基盤ロードマップ この記事はMLOps foundation roadmap for enterprises with Amazon SageMakerを翻訳したものです。 企業が組織全体で機械学習 (ML)の採用を進めるにつれて 、MLモデルの構築、学習、デプロイのための手動ワークフローがイノベーションのボトルネックになる傾向にあります。これを克服するために、企業はデータサイエンティスト、データエンジニア、MLエンジニア、IT、ビジネス関係者などの複数のペルソナがどのように協業すべきか、懸念事項、責任、スキルをどのように分離するか、AWSのサービスをどのようにして最適に使用するかなどについて明らかにし、明確な運用モデルを構築する必要があります。 このようなMLと運用

                        Amazon SageMakerを利用したエンタープライズのためのMLOps基盤ロードマップ | Amazon Web Services
                      • Amazon Inspectorから脆弱性情報を取得してGitHub Issuesにチケット発行するのを自動化する - LIVESENSE ENGINEER BLOG

                        まえがき こんにちは、インフラグループの yjszk です。 インフラグループでは、Amazon Inspectorで検出された脆弱性への対応を定期的に行っています。 ただ、脆弱性情報を収集して適切な対応を行うプロセスは手作業です。作業が面倒であり、トイルとなっていました。 そこで、PythonとGitHub Actionsを使ってGitHub IssuesにAmazon Inspectorで検出した脆弱性情報を登録し、必要な対応内容がひと目でわかるようにしました。 この自動化により、より迅速な脆弱性対応が可能になりました。具体的には以下のようなIssueを自動作成しています。 Amazon Inspectorについて 概要は以下です。 EC2インスタンスにAmazon Inspector エージェントをインストールして、ネットワーク到達性や、プラットフォームの脆弱性を診断し、潜在的なセキ

                          Amazon Inspectorから脆弱性情報を取得してGitHub Issuesにチケット発行するのを自動化する - LIVESENSE ENGINEER BLOG
                        • Next.js 13 の SSR Streaming を AWS Lambda Response Streaming で実装する方法 | Amazon Web Services

                          Amazon Web Services ブログ Next.js 13 の SSR Streaming を AWS Lambda Response Streaming で実装する方法 AWS Lambda のレスポンスペイロードストリーミングを使用することで、サーバーサイドでレスポンスデータが利用可能になった時点で呼び出し元にデータを段階的に送信することができます。これにより、Web アプリケーションやモバイルアプリケーションのパフォーマンスを改善し、ユーザ体験を向上させることができます。AWS Lambda のレスポンスストリーミングに関して詳しくは Introducing AWS Lambda response streaming の記事を参照ください。 本記事では、レスポンスストリーミングの実践的な活用例として、Next.js 13 において提供されている SSR Streaming

                            Next.js 13 の SSR Streaming を AWS Lambda Response Streaming で実装する方法 | Amazon Web Services
                          • EKS Kubernetes 構成と構想 | 外道父の匠

                            やるといった以上、記事は書くわけなんですが、何度この下書きをゴミ箱に突っ込もうとしたかわかりませんKubernetesですよろしくお願いします。 ナニがアレかというと、構成図に全部盛り込めるはずもないくらいには色々要素があるわ、構築手順を書いていこうにも予備知識が必要な箇所がそこかしこに出現するわで、わかりやすく書けそうもないのです。なので、まずは丁寧にやりたいことから整理していくことにします。 全体図 ECSシリーズ まず、前回のECSシリーズの復習としてこちら。 これは複雑そうに見えて、わりとオススメできる簡潔さでした。 ECSをEKSに入れ替える ECSで説明した、ECS以外の部分は大体そのまま流用するので、薄くしたところはあまり触れず、Kubernetesクラスタの内側に重点を置いていきます。必要があれば、ECSの方の記事に都度リンク貼ったりして重複は回避していく感じで。 EKS

                              EKS Kubernetes 構成と構想 | 外道父の匠
                            • AWS X-Rayによる分散アプリケーション分析をFargateで試してみた #Fargate | DevelopersIO

                              こんにちは、コカコーラ大好きカジです。 AWS X-RayをFargate上でどのように動かすか不明だったため、調べてみたところ、以下の資料が見つかったので、東京リージョンで構築して試してみました。 構築時のコマンドの実行結果も貼っています。 GitHub - aws-samples/aws-xray-fargate: Code examples showing how to run AWS X-Ray as a sidecar container on Fargate for deep application insights. AWS X-Rayによる分散アプリケーション分析(分散トレーシング)とは マイクロサービスが増え、パフォーマンス状況やデバッグが煩雑になっており、サービス間の相互作用やそれぞれの待機時間を把握するのは面倒な問題です。 そんな問題を解決するのが、AWS X-Ray

                                AWS X-Rayによる分散アプリケーション分析をFargateで試してみた #Fargate | DevelopersIO
                              • 「AWS Controllers for Kubernetes」(ACK)、AWSが公開。KubernetesからAWSのサービスを定義可能

                                AWSは、AWSのサービスやリソースをKubernetesのkubectlで定義できる「AWS Controllers for Kubernetes」(ACK)を、オープンソースとしてデベロッパープレビューで公開したことを明らかにしました。 AWS Controllers for Kubernetesを用いることで、Kubernetesのクラスタから直接AWSのサービスとリソースを定義し、使用できるようになります。 現時点で、Amazon S3、Amazon SNS、Amazon SQS、DynamoDB、Amazon ECR、AWS API Gatewayなどのサービスに対応しています。今後ほかのサービスにも対応が広がる見通しです。 これまでKubernetesからAWSのサービスやリソースを呼び出すためのソフトウェアとして「AWS Service Operator」がありました。今回リ

                                  「AWS Controllers for Kubernetes」(ACK)、AWSが公開。KubernetesからAWSのサービスを定義可能
                                • [アップデート]AWS Fargate プラットフォームバージョン1.4でできるようになったこと | DevelopersIO

                                  はじめに こんにちは、コンサル部の島川です。 2020/4/8 Fargateの新しいプラットフォームバージョン 1.4がリリースされました。てんこ盛りですが、今すぐ適用させたいそんな機能ばかりです! アップデート情報は基本的にここにまとまっていますが、こちらでも再度要点をまとめて更に適用する手順についてもご紹介いたします。 追加された新機能について FargateはECSとEKSで利用することができますが、今回のアップデートは主にECSにおけるアップデートになります。共通する部分もありますが、基本的にECSでの利用という点に注意してください。 FargateでElastic File System(EFS)が使えるようになりました ECS on EC2では既に使える機能でしたが、ECS on Fargateでも使えるようになりました!限られたディスク容量という課題をクリアすることができま

                                    [アップデート]AWS Fargate プラットフォームバージョン1.4でできるようになったこと | DevelopersIO
                                  • 【Autify x ZOZO x dip共同開催】AWSコスト削減事例祭り(イベント参加レポート) - Qiita

                                    Autify x ZOZO x dipさんが共同開催の「AWSコスト削減事例祭り」というイベントの参加レポートとなります。 アーカイブ 塵も積もれば山となるコスト削減の話(Autify 松浦さん) Autifyさんはソフトウェアのテストをノーコードで作成することができる製品を提供。 元々Webサービスに対するテストを作成できる製品があり、その後にモバイルアプリをテストできるサービスをリリース。 以下のような構成がAWS上で動いている。 まずは、ワーカーとテストデバイスをFargateに移行してコストを最適化。 この最適化のおかげでお客様が増えれば売り上げも増えるような仕組みとなった。 モバイルアプリに対するテストをするサービスをリリースしたことで、急にコスト増加。 原因は以下 開発用インスタンスの一時的な軌道 ユーザが少なくコスト効率が悪い Web障害からの学びで大きめのインスタンスを使っ

                                      【Autify x ZOZO x dip共同開催】AWSコスト削減事例祭り(イベント参加レポート) - Qiita
                                    • docker/build-push-action v3.3.0で導入されたprovenanceオプションにまつわる問題 - chroju.dev

                                      docker/build-push-actionのv3.3.0 で、 provenance というオプションが入り、デフォルトで有効化された。このオプションについては、 This may introduce issues with registry and runtime support (e.g. GCR and Lambda). という注意書きがされており、一部環境で問題が起きる可能性がある。GitHub Actionsでバージョンをマイナー、パッチバージョンまで指定せずに使っていた場合、自動的にこのバージョンが適用されるため、実際に問題になったという声もTwitterで散見され、自分も一部で引っかかった。 @GitHub Actions runner bumped @Docker buildx today, which has default provenance on. It's

                                        docker/build-push-action v3.3.0で導入されたprovenanceオプションにまつわる問題 - chroju.dev
                                      • [アップデート]ゼロキャパシティからのバッチ処理に最適!AWS Batch で AWS Fargate が利用可能になりました! #reinvent | DevelopersIO

                                        本日のアップデートで AWS Batch で AWS Fargate の利用が可能になりました! Serverless Batch Scheduling with AWS Batch and AWS Fargate AWS Batch for AWS Fargate AWS Batch はジョブをキューイングすると、定義された内容に従い自動的にコンピューティングリソースを起動し、計算処理を実行するバッチコンピューティングのサービスです。バックグラウンドでは Amazon ECS が動いているのですが、ユーザーは ECS を意識することがないようにラッピングされています。 従来はいわゆる ECS on EC2 がサポートされていましたので、ラッピングされてるとはいえ EC2 ホストの存在は少なからずとも意識する必要がありました。加えてゼロキャパシティからスケールする際は、キューイングしてから

                                          [アップデート]ゼロキャパシティからのバッチ処理に最適!AWS Batch で AWS Fargate が利用可能になりました! #reinvent | DevelopersIO
                                        • ECSサービスの設計ポイントをざっくりまとめてみる - NRIネットコムBlog

                                          本記事は 初夏のAWSアワードエンジニア祭り 1日目の記事です。 🍦 告知記事 ▶▶ 本記事 ▶▶ 2日目 💻 尾澤です。 この度、2023 Japan AWS All Certifications Engineers に選ばれました。 更新が不安です。 というわけで今回はAWSアワードとかはあまり関係ないですが、 私が日頃業務で対峙するECSさんについてお話ししようかと思います。 ECSとは もう今となってはコンテナといえばこれというサービスですね。(?) 改めての説明ですが、 Amazon ECS(Elastic Container Service)は、AWSが提供するコンテナオーケストレーションサービスです。 Webサービスなどを構成する場合、コンテナ単体で動かすにはさまざまな運用課題があるため、 基本的にはオーケストレーションツール(ex: Kubernetes, e)を使いま

                                            ECSサービスの設計ポイントをざっくりまとめてみる - NRIネットコムBlog
                                          • シェルからのSQL実行をAmazon ECSを使ってサーバーレスに実現してみる - 虎の穴開発室ブログ

                                            こんにちは。虎の穴ラボの鷺山です。 この記事は「虎の穴ラボ 夏のアドベントカレンダー」の3日目の記事です。 2日目は植竹さんによる「GCPの監視機能 Monitoring の推しポイント紹介」が投稿されました。 4日目はH.Y.さんによる「Amazon WorkSpacesで色々試してみる。」が投稿されます。こちらもぜひご覧ください。 はじめに データベースを運用していると、「挿入・変更・削除などのちょっとしたデータ操作を、シェルスクリプトの中にSQLを書いて実行」したりすることはあると思います。 今回はそのような処理をAmazon ECSのタスク実行を使ってサーバーレスに実現する方法をご紹介したいと思います。 コンテナの起動にAWS Lambdaも使用します。 環境 データベース: MySQL 5.7 (Aurora 2.10.2) この記事の付録にPostgreSQLでの方法もご紹介し

                                              シェルからのSQL実行をAmazon ECSを使ってサーバーレスに実現してみる - 虎の穴開発室ブログ
                                            • Automating Dependabot with GitHub Actions - GitHub Docs

                                              About Dependabot and GitHub Actions Dependabot creates pull requests to keep your dependencies up to date, and you can use GitHub Actions to perform automated tasks when these pull requests are created. For example, fetch additional artifacts, add labels, run tests, or otherwise modifying the pull request. Responding to events Dependabot is able to trigger GitHub Actions workflows on its pull requ

                                                Automating Dependabot with GitHub Actions - GitHub Docs
                                              • AWS Fargateにデプロイしたアプリに対して負荷テストを行う | DevelopersIO

                                                Introduction 先日Fargateで起動したWebアプリに対して負荷テストを実行していたので、 環境の構築方法についての備忘録です。 本稿ではNodeのWebアプリをFargateで起動し、AWSでの分散負荷テストソリューションを つかって構築した環境から負荷テストを実行するまでを記述します。 Environment 以下の環境で試しました。 aws cliは実行可能な前提です。 OS : MacOS 11.3.1 Node: 16.2 Docker : 20.10.12 Build Services 負荷テスト環境を構築 ここにある負荷分散テストソリューションを使えば、 かんたんに環境が構築可能です。 cloudformationテンプレートが公開されているので、これを使ってデプロイするだけで 負荷テストを実行する環境が全部できてしまいます。 さらに、使用方法や具体的な構築方法

                                                  AWS Fargateにデプロイしたアプリに対して負荷テストを行う | DevelopersIO
                                                • Announcing Amazon ECS deployment circuit breaker | Amazon Web Services

                                                  Containers Announcing Amazon ECS deployment circuit breaker Today, we announced the Amazon ECS deployment circuit breaker for EC2 and Fargate compute types. With this feature, Amazon ECS customers can now automatically roll back unhealthy service deployments without the need for manual intervention. This empowers customers to quickly discover failed deployments, while not having to worry about res

                                                    Announcing Amazon ECS deployment circuit breaker | Amazon Web Services
                                                  • Amazon Inspector と AWS Systems Manager を用いた脆弱性管理と修復の自動化 – Part 2 | Amazon Web Services

                                                    Amazon Web Services ブログ Amazon Inspector と AWS Systems Manager を用いた脆弱性管理と修復の自動化 – Part 2 このブログは Automate vulnerability management and remediation in AWS using Amazon Inspector and AWS Systems Manager – Part 2 を翻訳したものです。 このブログは、Amazon Inspector と AWS Systems Manager を使った脆弱性管理と修復の自動化シリーズの Part 2 です。このシリーズでは、AWS Systems Manager Automation Runbook を使用して、Amazon Inspector の検出結果をオンデマンドで修復する方法を紹介します。本シリーズ

                                                      Amazon Inspector と AWS Systems Manager を用いた脆弱性管理と修復の自動化 – Part 2 | Amazon Web Services
                                                    • RubyKaigi 2022の会場ネットワークリポジトリを読み解く | うなすけとあれこれ

                                                      私がこれを書く動機 私はKaigi on Railsのオーガナイザーのひとりです。Kaigi on Rails 2023は物理会場にて開催されることが公開されました。そうなるともちろん、会場でのインターネットについてはどうなる、どうする、という問題が出てきます。それに備えて、先輩イベントであるRubyKaigiを参考にしようというわけで、自分の理解のために書くことにしました。 おことわり 私はRubyKaigi 2022のネットワークをお手伝いしましたが、ケーブルの巻き直し、APの設営、撤収時の諸々を手伝ったのみです。よってこれから言及する内容については、一般参加者に毛が生えた程度の事前知識しかありません。 またこれから読み解くコードにおいて、コメントする内容の正確性は一切ないものと思って読んでください。 RubyKaigiのネットワークについて RubyKaigiのネットワークにおけるL

                                                        RubyKaigi 2022の会場ネットワークリポジトリを読み解く | うなすけとあれこれ
                                                      • Amazon ECS deployment circuit breaker のご紹介 | Amazon Web Services

                                                        Amazon Web Services ブログ Amazon ECS deployment circuit breaker のご紹介 ※日本語字幕の表示には、設定 → 字幕 → 自動翻訳 → 日本語をご選択ください EC2 および Fargate コンピュートタイプ用の Amazon ECS deployment circuit breaker をパブリックプレビューで発表しました。この機能により、Amazon ECS をご利用のお客様は、手動での作業を行うことなく、不健全なサービスデプロイを自動的にロールバックできるようになります。これにより、お客様は失敗したデプロイを迅速に発見できるようになり、失敗したタスクのためにリソースが消費されたり、デプロイが無期限に遅延したりすることを心配する必要がなくなります。 以前は、Amazon ECS でデプロイメントタイプにローリングアップデートを使

                                                          Amazon ECS deployment circuit breaker のご紹介 | Amazon Web Services
                                                        • Earthlyでコンテナ時代のビルド環境を味わう - Runner in the High

                                                          【これはUnipos Advent Calendar 2021の2日目の記事です】 つい最近、EarthlyというDockerコンテナベースのビルドツールで、自分の開発しているGoのアプリケーションのMakefile/Dockerfile/docker-compose.yamlを置き換えたのでそれを記事にしてみる。 Earthlyとは github.com めちゃくちゃ雑に言うとDockerイメージをベースにしたビルドツール。 できることとしてはGoogleが作っているBazelに近い*1が、書き味はMakefile+Dockerfileに近く*2、独特の文法が少ない雰囲気。当然、言語やフレームワークに依存しない。まるでローカル環境でビルドをしているかのようにシームレスにコンテナ環境でビルドを実行できる。 Earthlyは書き味こそDockerfileと似ているが、Dockerイメージを作

                                                            Earthlyでコンテナ時代のビルド環境を味わう - Runner in the High
                                                          • GitHub Actions on AWS with CDK - NTT Communications Engineers' Blog

                                                            はじめに こんにちは、イノベーションセンターの福田です。 今回、開発環境改善の取り組みとして GitHub Actions の self-hosted runners を AWS 上に構築しました。 この構築で得られた知見について共有します。 概要 GitHub Actions は GitHub で CI/CD を手軽に実現する機能です。 GitHub が提供している環境を利用して、 CI/CD のジョブを実行できます1。 一方で、ハードウェア等をカスタマイズできないため、例えば容量が大きくより速度の早いストレージを利用したい場合や、より多くのメモリを利用したい場合に対応ができません。 そこで、GitHub Actions には self-hosted runners という機能があり、自身の環境で GitHub Actions の CI/CD ジョブを走らせる環境を用意できます。 今回は

                                                              GitHub Actions on AWS with CDK - NTT Communications Engineers' Blog
                                                            • この1年の Amazon EKS アップデートを振り返る

                                                              この1年の Amazon EKS アップデートを振り返る Amazon EKS Advent Calendar 2019 の1日目です. アメリカ時間だとまだ12/1なので許して… 他の AWS サービス同様、Amazon EKS もこの1年間で多くのアップデートを発表してきました. 本記事では、ざっくりとこの1年間の主なアップデートを振り返りつつ、いよいよ本日から開催される re:Invent に備えていこうではありませんかという、そんな目論見がございます. 日付順にアップデートを追って書いていたんですが、なんだか読みにくかったのでカテゴリごとに分けて書いていきます. 目次です. Security & Reliability Regions & Versions Nodes Storage & Networking Tooling Machine Learning その他 まとめ Sec

                                                              • Trivy の Misconfiguration Scanning で Terraform の設定ミスを検出しよう - kakakakakku blog

                                                                Trivy の「Misconfiguration Scanning」は Terraform をサポートしていて(AWS CloudFormation もサポートしている👏),Terraform コードのセキュリティ課題や設定ミスを検出できる❗️Trivy を活用した Terraform のスキャンを試した作業ログをまとめる📝 aquasecurity.github.io tfsec から Trivy へ 🔜 tfsec は現在も使えるけど,今後は Trivy に移行する流れとなっている💡 GitHub Discussions に今年2月頃 tfsec is joining the Trivy family というアナウンスが投稿されている❗️ github.com さらに GitHub の tfsec リポジトリ(master ブランチ)に今年5月頃 Migrating from

                                                                  Trivy の Misconfiguration Scanning で Terraform の設定ミスを検出しよう - kakakakakku blog
                                                                • AWS Organizations を利用したマルチアカウント環境での Amazon ECR リポジトリの共有 | Amazon Web Services

                                                                  Amazon Web Services ブログ AWS Organizations を利用したマルチアカウント環境での Amazon ECR リポジトリの共有 この記事は Sharing Amazon ECR repositories with multiple accounts using AWS Organizations を翻訳したものです。 お客様は AWS 上でセキュリティの向上と職務の分離を行うためマルチアカウントの導入を進めています。Amazon Elastic Container Registry (ECR) のような一部の AWS サービスは、管理のオーバーヘッドを減らし可視性を高めるために、単一のインスタンスをアカウント間で共有できるスケーラビリティをサポートしています。AWS アカウントは、アカウント番号やその他のアカウント固有のメタデータが頻繁に生成される弾力性のあ

                                                                    AWS Organizations を利用したマルチアカウント環境での Amazon ECR リポジトリの共有 | Amazon Web Services
                                                                  • ANDPADのマイクロサービス基盤チームの取り組み - ANDPAD Tech Blog

                                                                    はじめに 用語の定義 取り組みの背景 マイクロサービス化の目的 モノリスのつらさ ふたたびマイクロサービス化の目的 マイクロサービスとは 採用技術について 技術スタック サービス構成 現状の課題 技術面 最後に はじめに こんにちは、マイクロサービス基盤チーム所属のzigeninです。 この記事では、マイクロサービス化の取り組みについて紹介します。 技術的な取り組みやチームに興味を持っていただければと思います。 用語の定義 はじめに本文で使用する単語を定義させていただきます。 コアドメイン:アンドパッドの事業に直結するドメイン 施工管理が該当します 施工管理は建設現場のマネジメントです。 ソフトウェア開発に例えるとプロジェクトマネジメントに近く、ツールとしてはJIRAやGitHub Projectをイメージしていただけると当たらずといえども遠からずです。 汎用ドメイン:コアドメインを支援す

                                                                      ANDPADのマイクロサービス基盤チームの取り組み - ANDPAD Tech Blog
                                                                    • Terraform 1.8 provider functions for AWS, Google Cloud, and Kubernetes

                                                                      Today, we are announcing the general availability of provider-defined functions in the AWS, Google Cloud, and Kubernetes providers in conjunction with the HashiCorp Terraform 1.8 launch. This release represents yet another step forward in our unique approach to ecosystem extensibility. Provider-defined functions will allow anyone in the Terraform community to build custom functions within provider

                                                                        Terraform 1.8 provider functions for AWS, Google Cloud, and Kubernetes
                                                                      • CVE-2021-44228 Log4jの脆弱性のAWS環境への影響 - Qiita

                                                                        ざっとSecurity Bulletinの2件を読みながらのメモ。12月18日21:00時点。誤りや情報が古いなどありましたらご指摘いただけるとありがたいです。 AWS(Amazon Web Services)のCVE-2021-44228関連情報 Apache Log4j2 セキュリティ速報 (CVE-2021-44228) Apache Log4j2 のセキュリティ速報 (CVE-2021-44228) の更新情報 日本語情報が遅れることがあります。原文は、上記各ページ右上(モバイルブラウザではページ最下部)で言語「English」を選ぶと確認できます。 影響があるもの Amazon Kinesis は修正済みのKinesis Agentが利用可能になっている。 Amazon Kinesis Data Analytics は修正済み。利用者は、アプリケーションを日本時間2021年12月

                                                                          CVE-2021-44228 Log4jの脆弱性のAWS環境への影響 - Qiita
                                                                        • NuxtJS製のWebサービスをECSに移行したはなし - KAYAC engineers' blog

                                                                          SREチームの長田です。 Advent Calendar Migration Track 22日目の記事です。 今回は弊社で運用しているLobiというサービスの、Webブラウザ版(Web版)をECSに移行したはなしです。 web.lobi.co なぜ移行したのか おなじみ、Amazon Linux1 EoL対応です。 すべてのアプリケーションをEC2から移行するプロジェクトの一環です。 移行前 LobiのWeb版はNuxtJSを使って実装されています *1。 各APIにリクエストし、サーバーサイドレンダリング(SSR)した結果を、Webブラウザに返しています。 NuxtJSアプリは他のアプリケーションも同居するEC2インスタンスで実行していました。 移行前の構成 (実際にはクライアントで動的にコンテンツを更新するためのAPIリクエストも発生しますが、今回の話題には関わってこないので省略して

                                                                            NuxtJS製のWebサービスをECSに移行したはなし - KAYAC engineers' blog
                                                                          • GitHub Actionsを使ってコンテナ版AWS Lambdaにデプロイしてみた | DevelopersIO

                                                                            GitHub Actionsを使い、コンテナイメージをAmazon ECRにプッシュし、AWS Lambdaにデプロイする方法を紹介します。 GitHubからAWSへの認証では、OpenID Connect(OIDC)を利用します。 本ブログでは、GitHub Actionsを使い、main ブランチへの push をトリガーにコンテナイメージをビルドしてコンテナレジストリのAmazon ECRにプッシュし、AWS Lambdaにコンテナイメージをデプロイする方法を紹介します。 実質的にやっていることは、GitHub の ECS 向けドキュメントをベースに、以下の変更を加えています。 GitHub から AWS への認証に、IAMアクセスキーの代わりに OpenID Connect(OIDC)を利用 デプロイ先をAmazon ECSからAWS Lambdaへ変更 大前提として、デプロイのゴ

                                                                              GitHub Actionsを使ってコンテナ版AWS Lambdaにデプロイしてみた | DevelopersIO
                                                                            • クラウド移行における設計という共通認識 - LIVESENSE ENGINEER BLOG

                                                                              これは SRE Advent Calendar 2023 DAY 22 の記事です。 はじめに 自分しかわからないPR なぜ読まれなかったのか 実際のPR 設計という共通認識の重要性 経緯を残すと++ ちいさくてかわいいPR わかりやすいPRのTips 直したPR 終わりに はじめに リブセンスでインフラグループに所属している鈴木です。競馬に行きすぎて、行ったことない地方競馬場が水沢と高知だけ1になりました。今後は釜山か済州2を考えています。 ところで、クラウド移行を複数経験したことで感じたことを共有しようと思います。なお本記事は第2回ゆるSRE勉強会の登壇資料をもとに作っています。 自分しかわからないPR オンプレのVMで動いていた社内認証基盤をECS Fargateに移行する案件がありました。構成は下記となります。 nginxのリバースプロクシ oauth2-proxyという様々なID

                                                                                クラウド移行における設計という共通認識 - LIVESENSE ENGINEER BLOG
                                                                              • [アップデート]Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました #AWSreinvent | DevelopersIO

                                                                                [アップデート]Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました #AWSreinvent ついにECS on Fargateでコンテナランタイムのセキュリティ対策ができるようになりました!Fargate利用者は全員必見のアップデートです! こんにちは。AWS事業本部トクヤマシュンです。 本日より、Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました!! 当機能はECS on Fargate、ECS on EC2のどちらにも対応しています!! (2023/11/29追記:ECS on EC2は現在プレビュー機能のようです。) 立ち位置としては、これまでAmazon GuardDuty EKS Runtime MonitoringとしてEKSのみに提供されてきた機能が、 Runti

                                                                                  [アップデート]Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました #AWSreinvent | DevelopersIO
                                                                                • Solrのクラウド移行 -AWS ECS Fargateの事例- - LIVESENSE ENGINEER BLOG

                                                                                  はじめに 技術部インフラグループの春日です。 2024年現在、弊社が運営している マッハバイト は一部を除いてオンプレからクラウドへの移行が完了しました。 本記事では移行対象の1つであった Apache Solr に関する総括をします。 今回のプロジェクトでは移行自体を最優先とするため、スコープを以下に定めていました。 Apache Solrから他の検索エンジンへは乗り換えない アプリケーション側の改修は向き先の変更だけに留める Apache Solr自体のバージョンUP対応はしない 運用負荷を軽減できる形の構成変更を加える 移行スピードと移行後の運用コストとの天秤 新たに運用しないといけなくなるコンポーネントはなるべく増やさない モニタリングや監視の精度はなるべく落とさない 上記を踏まえ、以降の節ではApache Solrのサービス内利用箇所の紹介から始め、 インフラ構成・デプロイ・モニ

                                                                                    Solrのクラウド移行 -AWS ECS Fargateの事例- - LIVESENSE ENGINEER BLOG