並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 32 件 / 32件

新着順 人気順

codedeployの検索結果1 - 32 件 / 32件

  • AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠

    これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス:ALB or ECS Service 共有 or 1環境毎 アクセスログ:ALB or WEBサーバー ECS / EKS デプロイ:Blue/Gr

      AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
    • 改めてECSのデプロイ方法を整理する - NRIネットコムBlog

      こんにちは。梅原です。 今日はECSのデプロイタイプについて改めて整理します。 ECSのデプロイ方法は3つあります。 ローリングアップデート Blue/Greenデプロイ 外部デプロイ の3つです。 この記事ではローリングアップデートとB/Gデプロイについて流れをおさらいします。 ECSの前段にALBを置いた構成を例にします。 ローリングアップデート ローリングアップデートの流れを見る B/Gデプロイ B/Gデプロイの流れを見る ローリングアップデートとB/Gデプロイの比較 最後に ローリングアップデート ローリングアップデートとは、稼働中のECSタスクをそのまま新しいタスクに置き換える方法です。一番オーソドックスなデプロイ方法なのではないでしょうか。 ECSのみでデプロイすることができ、設定箇所も主に後述する2つだけなので手軽にできます。ですがデプロイ中は新旧のタスクが混ざる状態となるた

        改めてECSのデプロイ方法を整理する - NRIネットコムBlog
      • ぼくのかんがえたさいきょうのDevOps実現構成

        はじめに 昨年、AWS のインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を紹介した記事、「【AWS】ぼくのかんがえたさいきょうの運用・監視構成」が投稿したその日の Qiita のトレンド 1 位になり、はてなブックマークのテクノロジー分野でトップを飾りました。(たくさんの方に見ていただき感謝してます!) 本記事では「ぼくのかんがえたさいきょうの運用・監視構成」の続編として「ぼくのかんがえたさいきょうの DevOps 実現構成」を紹介させていただきます。あくまでも「ぼくのかんがえた」なので私個人の意見として受け入れていただけると助かります。 前回の記事でもお伝えいたしましたが、各個人・企業によって環境は違うと思いますし、使いやすいサービスは人それぞれだと思うので、これが正解という訳ではありません。一個人の意見として参考にしてただければ幸いです。 また、こちらの記事

          ぼくのかんがえたさいきょうのDevOps実現構成
        • 大規模サービスのインフラを全面的にリプレイスした話 - Qiita

          はじめに こんにちは。雑食系エンジニアの勝又です。 今回は、私が2年ほど参画させていただいた大規模サービスのインフラやDevOps周りを全面的にリプレイスしたお話について簡単にご紹介させていただきます。(内容に関しては事前に参画先企業様に確認していただいております) サービス概要 詳細な内容は伏せますが、メインとなるテーブルのレコード数が数十億件、スパイク時には数万〜数十万のユーザーが一斉にアクセスする大規模サービスです。 技術的負債 長く運用されてきたサービスのあるあるですが、新機能の追加が最優先されてきたことにより、こちらのサービスにも下記のような技術的負債が大量に積み上がっていました。 RubyやRailsやMySQLのバージョンがかなり古い インフラの構成がコードではなくドキュメントで管理されている アプリケーションの構成管理がおこなわれていない CI/CDパイプラインが構築されて

            大規模サービスのインフラを全面的にリプレイスした話 - Qiita
          • [ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media

            この記事について みなさん、ECS利用していますか!? AWSでコンテナを使うのなら、ECSですよね!?(kubernetesわからない勢) ECSはタスクという単位で、アプリケーションを実行させます。 そして、タスクの中にコンテナが1つ以上稼働します。 タスクはタスク定義から作成されます。タスク定義はタスクの金型的な存在です。 また、タスク定義はJSONファイル(以後taskdef.json)として運用することが一般的です。 このtaskdef.jsonを実運用する際に迷うポイントがあります。 それは以下のどちらの方法にするかです。 – 方法① : 各環境ごとにtaskdef.jsonを用意する – 方法② : 各環境でtaskdef.jsonを共用する ①,②について、それぞれの詳細/メリット・デメリットについて洗い出しをして、どちらを採用すべきかについての見解を述べていきます。 あく

              [ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media
            • 【2024年】AWS全サービスまとめ | DevelopersIO

              こんにちは。サービス開発室の武田です。このエントリは、2018年から毎年公開しているAWS全サービスまとめの2024年版です。 こんにちは。サービス開発室の武田です。 このエントリは、2018年から毎年公開している AWS全サービスまとめの2024年版 です。昨年までのものは次のリンクからたどってください。 AWSにはたくさんのサービスがありますが、「結局このサービスってなんなの?」という疑問を自分なりに理解するためにまとめました。 今回もマネジメントコンソールを開き、「サービス」の一覧をもとに一覧化しました。そのため、プレビュー版など一覧に載っていないサービスは含まれていません。また2023年にまとめたもののアップデート版ということで、新しくカテゴリに追加されたサービスには[New]、文章を更新したものには[Update]を付けました。ちなみにサービス数は 247個 です。 まとめるにあ

                【2024年】AWS全サービスまとめ | DevelopersIO
              • インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ

                こんにちは。カミナシでソフトウェアエンジニアをしているaomanです。 私のエンジニアとしての経歴はカミナシが2社目で、前職も含めフロントエンドからバックエンドまで一通り開発はしていました。ですが、AWSなどインフラに関しては、アプリケーション開発時必要になったところを少し触ったりするくらいで、ガッツリと本格的に学んだことがありませんでした。 そんな私ですが、今回ECS Clusterの切り替え作業を先輩エンジニア監修の元一緒に行う機会をいただきました。どのようなことをしたのか、簡単にではありますがご紹介させて頂こうと思います! ざっくり概要 カミナシのサービスでは、APIサーバーの運用にAmazon ECS(on Fargate)を利用しています。また、APIサーバーコンテナの他にいくつかのコンテナが起動しています。以下がざっくりとした図になります。1つのTask定義があり、4つのコンテ

                  インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ
                • なぜSUZURIはHerokuから「EKS」へ移設する決定をしたのか - Pepabo Tech Portal

                  こんにちは。技術部プラットフォームグループのshibatchです。プラットフォームエンジニアとして、主にSUZURIとminneをより良くするおしごとをしています。 さて私が主として携わっているSUZURIですが、2014年のサービス開始以来、一貫してHerokuを利用してきました。このたび、10年間使っていたプラットフォームを卒業し、新たにAmazon EKS(Elastic Kubernetes Service)へ移す方針に決めた経緯についてお話しします。EKSに移すという決定にするまでに多角的に検討し、時に悩みながら決定した過程について明らかにしていきます。 なお、現在プラットフォーム移設の真っ最中であり、移設の詳細な内容はこの記事に含めません。移設作業はほぼ完了に向かっており、また別途お話しする予定です。 この記事は以下の3部構成になっています。 Herokuから移行しようと思った

                    なぜSUZURIはHerokuから「EKS」へ移設する決定をしたのか - Pepabo Tech Portal
                  • クラウドロックインされないアーキテクチャ「Cloud Agnostic Architecture」のすすめ | フューチャー技術ブログ

                    この記事はQiitaのアドベントカレンダー記事のリバイバル公開です。 ※ 当時の記事から、一部表現を見直し加筆しています。 はじめに先日ガートナーのレポートで「多くの企業において、特定のクラウドベンダにシステムを集中させるリスクの重要度が上昇している」との発表がありました。 https://www.gartner.com/en/newsroom/press-releases/2023-10-30-gartner-says-cloud-concentration-now-a-significant-emerging-risk-for-many-organizations 日本においてクラウドの活用はますます進んでいる一方で、特定の Cloud Service Provider(CSP)にロックインされるリスクについては、常に議論の余地があると考えています。 本記事では、特定のクラウドに強く依

                      クラウドロックインされないアーキテクチャ「Cloud Agnostic Architecture」のすすめ | フューチャー技術ブログ
                    • 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
                      • 改めてCI/CDパイプラインを使ったECS自動デプロイの流れを整理する - NRIネットコムBlog

                        本記事は 【コンテナウィーク】 1日目の記事です。 💻 告知記事 ▶▶ 本記事 ▶▶ 2日目 📱 こんにちは。梅原です。 皆さんはCI/CDパイプラインやってますか。昨今はパイプラインファーストという考え方もあり、ソースコードの変更反映をトリガーにテストやビルド、デプロイまで自動でやることは多いのではないでしょうか。 今回はAWSでCI/CDパイプラインを実現するためのサービスであるCodeシリーズ(CodeCommit、CodeBuild、CodeDeploy、CodePipeline)を使ってECSへ自動デプロイする流れを見ていきます。 AWSでCI/CDパイプラインを実現するために そもそもCI/CDパイプラインは、継続的インテグレーション/継続的デリバリーの略で、これまで手動でしていたテストやビルド、デプロイ作業を自動化・高速化するために使われるものです。 CI/CDパイプライ

                          改めてCI/CDパイプラインを使ったECS自動デプロイの流れを整理する - NRIネットコムBlog
                        • カメラ映像録画サーバのデプロイを改善した話 - Safie Engineers' Blog!

                          こんにちは。サーバサイドエンジニアの村田 (@naofumimurata) です。 本記事では、セーフィーのシステムでカメラ映像の録画機能を担うアプリケーションのデプロイを改善した話を共有したいと思います。 セーフィーの録画・配信システム カメラサーバのデプロイの課題 デプロイの流れ 実行環境 問題 時間がかかる 作業負荷が高い メンテナンス性が悪い 結果どういう状態になったか 改善に向けた取り組み GitHub Actions + AWS CodeDeployの構成に 監視の強化 成果 デプロイ時間の短縮 作業負荷の軽減 デプロイ頻度の向上 まとめ セーフィーの録画・配信システム セーフィーはクラウド防犯カメラ・録画サービスを提供しています。 バックエンドのシステムとしては、まずカメラから映像を常時受け取りストレージに保存するアプリケーション(本記事では以降「カメラサーバ」と呼びます)が

                            カメラ映像録画サーバのデプロイを改善した話 - Safie Engineers' Blog!
                          • クラウド時代におけるポテンヒットの防ぎ方 - NRIネットコムBlog

                            本記事は 【Advent Calendar 2023】 5日目の記事です。 🎄 4日目 ▶▶ 本記事 ▶▶ 6日目 🎅 今回はクラウド活用をしていく上でアプリケーションチームとインフラチームとの間でどのようなコミュニケーションを取っていくべきかをまとめてみようと思います。 また、インフラエンジニアとして僕が普段アプリケーションチームの方と接する時に意識していることも併せて整理してみました。 アプリとインフラどっちがやるんだ問題 ポテンヒットとは エンジニアの境界はより曖昧に 重要なマインドセット ポテンヒットは起きるという事実をまず知ること アレルギー反応を起こさない 密なコミュニケーションを取る 1.全体像を共有する 2.前提知識に違いがあることを理解する 3.課題を共有する さいごに アプリとインフラどっちがやるんだ問題 いきなりですが、このような構成のAWSシステムがあるとします

                              クラウド時代におけるポテンヒットの防ぎ方 - NRIネットコムBlog
                            • 海外のCDKの知見を学ぼう! Advanced AWS CDK: Lessons learned from 4 years of use COM302 参加レポート #AWSreInvent2023 | DevelopersIO

                              海外のCDKの知見を学ぼう! Advanced AWS CDK: Lessons learned from 4 years of use COM302 参加レポート #AWSreInvent2023 re:Invent2023で参加した「Advanced AWS CDK: Lessons learned from 4 years of use」のレポートです。感想多めです。 はじめに re:Invent現地参加組の佐藤智樹です。今回は、AWS DevTools HeroであるMatthew Bonigさんの登壇、「Advanced AWS CDK: Lessons learned from 4 years of use」に参加した際のレポート記事です。彼は4年間CDKの利用歴があり、その中で得た知見をもとにCDK Bookも共著で執筆されています。そんな4年間の中での学びが共有されたセッシ

                                海外のCDKの知見を学ぼう! Advanced AWS CDK: Lessons learned from 4 years of use COM302 参加レポート #AWSreInvent2023 | DevelopersIO
                              • DevOps on AWS大全 - Qiita

                                はじめに この記事ではDevOpsを切り口に私がまとめている記事を目次形式でまとめます。 この記事を読んでほしい人 AWSにおけるDevOpsを網羅的に整理したい人 私が書いている記事の前後性や一覧がわかりづらく困っている人 AWS Certified DevOps Engineer Professionalを目指している人 DevOps on AWS大全目次 SDLCのオートメーション AWSにおけるCI/CDのテクノロジースタック https://qiita.com/tech4anyone/items/f9d24d77cdf2b55d91ec AWSにおけるパイプラインのベストプラクティスパターン整理 https://qiita.com/tech4anyone/items/d0f86ef24ab710498d59 AWS CodeCommitの超詳細解説 https://qiita.c

                                  DevOps on AWS大全 - Qiita
                                • AWS CDK Pipelines と AWS CodeDeploy を使用したブルー/グリーンデプロイ | Amazon Web Services

                                  Amazon Web Services ブログ AWS CDK Pipelines と AWS CodeDeploy を使用したブルー/グリーンデプロイ お客様から Amazon Elastic Container Service (Amazon ECS) に AWS CodeDeploy を使用して ブルー/グリーン デプロイを実装するための支援がしばしば求められます。 お客様のユースケースは通常、クロスリージョンおよびクロスアカウント間でのデプロイシナリオが含まれます。 これらの要件だけでも十分に難しいのですが、さらに CodeDeploy を使用する際には特定の設計上の決定が必要となります。 具体的には CodeDeploy の設定方法、CodeDeploy リソース (アプリケーションやデプロイグループなど) の作成時期と方法、アカウントとリージョンの任意の組み合わせにデプロイでき

                                    AWS CDK Pipelines と AWS CodeDeploy を使用したブルー/グリーンデプロイ | Amazon Web Services
                                  • Amazon ECSにおけるカナリアリリースの実現

                                    カナリアリリースに関連のある部分を図に起こしたものが以下です。 ECSクラスターの中にあるサービスに対してターゲットグループを設定し、ALBからのリクエストをタスクに割り振っています。 デプロイはGitHub ActionsのWorkflow Dispatchを使用し、ボタン押下で実行できます。このプロセスはDockerイメージをビルド、Amazon Elastic Container Registry(以下、Amazon ECRと表記)にイメージをプッシュし、Amazon ECSのタスク定義を更新すると自動的にタスクのローリングアップデートが走る仕組みを使用しています。 余談ですが、クーポンサービスでは以前Spring Boot 2.6を採用していました。 Spring Bootの3系へのアップグレードについては記事「出前館クーポンサービスでのサーバーアプリケーションのSpring Bo

                                      Amazon ECSにおけるカナリアリリースの実現
                                    • Steampipeを利用してAWSリソースのリレーションを可視化してみた | DevelopersIO

                                      データアナリティクス事業本部のueharaです。 今回は、Steampipeを利用してAWSリソースを可視化してみたいと思います。 Steampipeとは Steampipeは、AWSやGCPなど対応するクラウドサービスに対してSQLを使用してリソース情報を抽出できるOSSです。 v0.18.0にてRelationship graphsに対応したので、今回はそちらの機能を試してみたいと思います。 事前準備 Steampipeのインストール SteampipeはHomebrewでインストールすることができます。 $ brew install turbot/tap/steampipe インストール後、steampipeコマンドが利用できるか確認してみましょう。 $ steampipe -v Steampipe v0.20.9 AWSプラグインのインストール SteampipeのAWSプラグイン

                                        Steampipeを利用してAWSリソースのリレーションを可視化してみた | DevelopersIO
                                      • 【AWS】CodePipeline+ECSでBlue/Greenデプロイしてみた

                                        概要 会社で aws を触ることになり、基本から学んでいこうと思ったため備忘録として記事を書き始めました。 今回は 有名な Blue/Green デプロイ に関する概要説明の後 CodePipeline と ECS を使用して 自分の PC 内の Next アプリケーションを Blue/Green デプロイして Web 上に公開してみます 🌀 もし理解が違うよというところ等ありましたら優しく教えて頂けると幸いです 🙇‍♀️ Blue/Green デプロイ とは Blue/Green デプロイとは、アプリケーションのデプロイをダウンタイム無しに行うことができるデプロイ手法のことです。 下の図をご覧ください。 旧アプリケーションから新アプリケーションにアプリケーションの移行を行いたかったとします。 もし Blue/Green デプロイを行わなかった場合旧アプリケーションを新アプリケーション

                                          【AWS】CodePipeline+ECSでBlue/Greenデプロイしてみた
                                        • AWS上での DevOps の基本的な哲学、プラクティス、ツールの理解を学べる【DevOps Engineering on AWS】を受講してみた | DevelopersIO

                                          AWS上での DevOps の基本的な哲学、プラクティス、ツールの理解を学べる【DevOps Engineering on AWS】を受講してみた 皆さんこんにちは、AWS事業本部オペレーション部の清水です。 AWS Certified DevOps Engineer - Professional 認定を取得するべく、「DevOps Engineering on AWS」を受講してきました。以下に、学習した内容や参考ブログをご紹介したいと思います。 本コースの受講をお考え中の方へ、お役に立てば幸いです。 AWS認定トレーニングとは? 以下のブログに、弊社AWS認定トレーニング講師の平野のほうで執筆した各トレーニングの詳細が記載されています。 私が今回受講したのは、以下の図の赤枠に入るコースになります。 このトレーニングは、先にAWSの開発の基本を学習できるDeveloping on AWS

                                            AWS上での DevOps の基本的な哲学、プラクティス、ツールの理解を学べる【DevOps Engineering on AWS】を受講してみた | DevelopersIO
                                          • AWS環境におけるPCI DSS v4.0 に対応したセキュリティ対策を考える | DevelopersIO

                                            はじめに こんにちは。AWS事業本部コンサルティング部に所属している和田響です。 この記事では、AWS環境にてクレジットカード業界のセキュリティ基準であるPCI DSS v4.0に準拠するための対応を、AWSの提供するコンプライアンスガイドをもとに考えていきます。 PCI DSS対応の勘所や、AWSサービス理解の一助になれば幸いです。 ソース 本記事は2023年10月9日にAWSから公開されている、Payment Card Industry Data Security Standard (PCI DSS) v4.0 on AWSをもとに、PCI DSSの各要件に必要なAWSでの対応を簡単にまとめていきます。 前提 PCI DSSの各要件について考える前に、 AWS環境でのPCI DSS準拠を考えるために重要な前提を整理します。 共有責任モデル AWSはセキュリティの責任範囲をAWSとお客様

                                              AWS環境におけるPCI DSS v4.0 に対応したセキュリティ対策を考える | DevelopersIO
                                            • クラスメソッドに入社してもうすぐ2年なのでエンジニアとしてどのように働き学んできたかを振り返る | DevelopersIO

                                              はじめに データアナリティクス事業本部ビッグデータチームのkasamaです。 私は2022年の5月に入社したのでもうすぐクラスメソッド入社して2年になります。この2年でどのようなことをやってきたのかを振り返りつつ、 どのような考えで学習、情報収集しているのかなどを記事にすることで、少しでもお役に立てればと思います。 前提 普段私が活用しているサービス等を紹介させていただきますが、あくまで私個人の意見であることをあらかじめ記載させていただきます。 2年前の自分の情報も載せておくことで、2年間でどのようなことを学んできたのか比較したいと思います。 エンジニア経験:4年 プログラミング言語: Python(FastAPI): 2.5年, Java: 1年, JavaScript: 1年, HTML: 1年, CSS: 1年, C: 3ヶ月, SQL: 2年 データ分析基盤構築: 経験無し クラウ

                                                クラスメソッドに入社してもうすぐ2年なのでエンジニアとしてどのように働き学んできたかを振り返る | DevelopersIO
                                              • AWS Fargateを活用してコスト削減するには #AWSreInvent | DevelopersIO

                                                このセッションでは、Fargateを利用しているWebサービスでのコスト削減に関するセッションでした。Fargateに行き着くまでの技術選定の遍歴や、組織編成についても触れられていました。 こんにちは。ゲームソリューション部の出村です。 AWS re:Invent 2023のセッションである「Boosting efficiency: How to realize 70% cost reduction with AWS Fargate」のレポートをお届けします。 セッション概要 ''' In this session, discover how a leading enterprise SaaS company, using AWS Fargate and AWS Graviton, transformed their data-intensive grid service. Learn h

                                                  AWS Fargateを活用してコスト削減するには #AWSreInvent | DevelopersIO
                                                • IoT系のプロダクト開発の裏側って? 知られざる開発・運用ノウハウを2社のエンジニア6名が徹底解説! | gihyo.jp

                                                  IoT系のプロダクト開発の裏側って? 知られざる開発⁠⁠・運用ノウハウを2社のエンジニア6名が徹底解説! 電化製品や産業用機器など、あらゆるコンピューターやデバイスがインターネットを介して通信し、相互にやりとりする。そんな、IoT(Internet of Things)の技術を用いたサービス・ビジネスが注目を集めています。 2023年12月22日に開催されたイベント「IoT系のプロダクト開発の裏側って?知られざる開発・運用ノウハウを2社のエンジニア6名が徹底解説!」では、IoT技術を事業に活用するENECHANGE株式会社と株式会社スマートショッピングのエンジニア合計6名が登壇。プロジェクトから得られた知見を紹介しました。今回はそのレポートをお届けします。 今回登壇した発表者の集合写真 高度なモノの管理を実現⁠:SmartMatのエンジニアリング紹介 はじめに登壇したのは、スマートショッピ

                                                    IoT系のプロダクト開発の裏側って? 知られざる開発・運用ノウハウを2社のエンジニア6名が徹底解説! | gihyo.jp
                                                  • 2023年10月くらいのAWS最新情報ブログとかをキャッチアップする – AWSトレンドチェック勉強会用資料 | DevelopersIO

                                                    こんにちは、臼田です。 みなさん、AWSの最新情報はキャッチアップできていますか?(挨拶 社内で行っているAWSトレンドチェック勉強会の資料をブログにしました。 AWSトレンドチェック勉強会とは、「日々たくさん出るAWSの最新情報とかをブログでキャッチアップして、みんなでトレンディになろう」をテーマに実施している社内勉強会です。 このブログサイトであるDevelopersIOには日々ありとあらゆるブログが投稿されますが、その中でもAWSのアップデートを中心に私の独断と偏見で面白いと思ったもの(あと自分のブログの宣伝)をピックアップして、だいたい月1で簡単に紹介しています。 10月は73本もピックアップしています。そろそろre:Inventが近くなってきたのでウォームアップしていきましょう! ちなみにAWSの最新情報をキャッチアップするだけなら週刊AWSがおすすめですが、Developers

                                                      2023年10月くらいのAWS最新情報ブログとかをキャッチアップする – AWSトレンドチェック勉強会用資料 | DevelopersIO
                                                    • 認証情報を保護してセキュリティ確保!ECS on FargateからAuroraへの安全な接続をSecrets Managerで実現 - APC 技術ブログ

                                                      目次 目次 はじめに こんな方へおすすめの記事です 前提 参考 試してみた Secrets Managerの設定 Secrets Manager用のIAMロール作成 ポリシーの作成 IAMロールへのポリシー紐付け Secrets ManagerへのVPCエンドポイントの追加 バックエンドアプリケーションへの認証情報の設定 データベースへのアクセス確認 お知らせ はじめに こんにちは、クラウド事業部の清水(駿)です。 ECS on FargateからAuroraへの安全な接続するためのSecrets Managerへの認証情報の格納ついて調査・検証を行いました。 アプリケーションからデータベースに接続するには認証情報が必要です。しかし、ソースコードに認証情報を直接平文でベタ書きすることはセキュリティ上好ましくありません。 対処するためのテクニックとして、コンテナ内の環境変数として定義し、ソー

                                                        認証情報を保護してセキュリティ確保!ECS on FargateからAuroraへの安全な接続をSecrets Managerで実現 - APC 技術ブログ
                                                      • クラウドロックインされないアーキテクチャ「Cloud Agnostic Architecture」のすすめ - Qiita

                                                        この記事はフューチャー Advent Calendar 2023の20日目の記事です。 はじめに 先日ガートナーのレポートで「特定のクラウドベンダにシステムを集中させるリスクの重要度が多くの企業で上昇している」との発表がありました。 日本においてクラウドの活用はますます進んでいますが、特定の Cloud Service Provider(CSP)にロックインされるリスクについては、まだまだ議論の余地があると考えています。 本記事では、特定のクラウドに依存しないアーキテクチャについて「Cloud Agnostic Architecture」という言葉を用いて整理していきます。 Cloud Agnostic Architecture とは Cloud Agnostic1 Architectureとは「特定のクラウドに依存しないアーキテクチャ」を意味します。これはクラウドプラットフォーム自体を利

                                                          クラウドロックインされないアーキテクチャ「Cloud Agnostic Architecture」のすすめ - Qiita
                                                        • GitHubActions+ECSでBlueGreenDeploymentを実装するお話

                                                          はじめに こんにちは。プラットフォームGのOperationToolManagerチームでPlatformEngineeringとかツール周りの開発・運用の役割の島村です。 同じくプラットフォームGのOperationToolManagerチームで内製ツールの開発を行っている山田です。 KINTOテクノロジーズではAmazon ECS+Fargateをアプリケーション実行基盤として使用しています。また、CICDについてはGitHubActionsを使用しています。 AWSのECSにおけるBlueGreenDeploymentの仕組みは、DeploymentControllerとして「CODE_DEPLOY」が主として使用されており、「EXTERNAL(サードパーティーでの制御)」を使用している実例は少ないと思います。 CI/CD Conference 2023 by CloudNative

                                                            GitHubActions+ECSでBlueGreenDeploymentを実装するお話
                                                          • OSSにコントリビュートしてみたい人を応援する記事

                                                            先日、人生で初めて OSS にコントリビュート(貢献)してきました。 自分の実力ではとてもできないだろうと思って手を出そうともしなかったのですが、真面目にコツコツ取り組んでみるとついにはその目標を達成することができました。 かかった期間も一週間以内(ぶっ通しではないので実際の時間はもっと短い)でした。 もちろん優しい issue を対象にしたというのもありますが、一週間なら挑戦してみようかな という前向きな気持ちになれる期間ですよね。OSS にコントリビュートするのに壁を感じる方は多いと思うので、この記事ではそういった壁を取り払うべく、自分が OSS にコントリビュートするまでの道のりを書いていこうと思います。 この記事では、以下の内容を扱います。 OSS コントリビュートへの意欲・背景 OSS にコントリビュートするためにやったこと OSS コントリビュートしてみてどうだったか OSS

                                                              OSSにコントリビュートしてみたい人を応援する記事
                                                            • 【AWS】CodePipeline+ECSでコンテナアプリケーションのCI/CDしてみた

                                                              概要 会社で aws を触ることになり、基本から学んでいこうと思ったため備忘録として記事を書き始めました。 今回は CodePipeline と ECS に関する概要説明の後 これら を使用して自分の PC 内の Next アプリケーションを コンテナで Web 上に公開するまでの過程を CI/CD 化してみます 🌀 もし理解が違うよというところ等ありましたら優しく教えて頂けると幸いです 🙇‍♀️ CodePipeline とは 公式ドキュメント引用。 CodePipeline とは、最近流行りの CI/CD を実現するためのサービスです。 CI/CD とは書いたコードをテストして本番環境にデプロイする過程を自動化することを指します。 CodePipeline での CI/CD の一例を挙げると、旧来 自分の PC でコードを書く そのコードを手動でテスト 本番環境へデプロイする とい

                                                                【AWS】CodePipeline+ECSでコンテナアプリケーションのCI/CDしてみた
                                                              • 新卒1年目がECSにCanary Releaseを導入し信頼性を高めた話〜PipeCD〜 - Qiita

                                                                はじめに こんにちは、サイバーエージェントのAI事業本部でバックエンドエンジニアをしている23卒の高橋です。 CD環境をGitHubActionsからPipeCDに完全移行したので、その知見や感想について共有したいと思います。 背景 現在のデプロイフローはGitHubActionsを採用しており、以下のような非常にシンプルな手順になっております。 1. workflow dispatchで手動実行 2. GitHubActionsがImageをビルドし、ECRにPushします Imageタグを指定して、以下のworkflowを手動実行 SSMの値を書き換え,terrafrom apply これらの手順を追うことでビルドからデプロイまでの作業が完了します。 課題点 このデプロイ方法には以下のような課題点がありました ビックバンリリースのリスク ロールバック問題 誤操作のリスク 多様なデプロイ

                                                                  新卒1年目がECSにCanary Releaseを導入し信頼性を高めた話〜PipeCD〜 - Qiita
                                                                • [アップデート]AWS CodePipelineでソースリビジョンを上書きして実行できる機能がリリースされました | DevelopersIO

                                                                  こんにちは、オペレーション部の坂本です。 2023年11月23日にAWS CodePipelineでソースリビジョンを上書きして実行できる機能がリリースされました。 今までは手動でパイプラインを実行する際は、最新リビジョンが自動的に選択されいましたが、過去のリビジョンを選択して、手動できるようになりました。 リリースした後に不具合を見つけた時に素早く過去のバージョンに戻したいという時に気持ち楽になるかもしれませんね。 ※本機能はV2のみの機能です。 AWS CodePipeline supports starting a pipeline execution with source revision overrides コンソール画面 CodeCommit画面を見ると、リビジョンを指定できるようになっています。 やってみた バージョニングされた S3 バケット と CodeDeploy を

                                                                    [アップデート]AWS CodePipelineでソースリビジョンを上書きして実行できる機能がリリースされました | DevelopersIO
                                                                  1