サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
はじめに お久しぶりです。iselegantです。 今回は超久しぶりにAmazon ECSに関するブログを書いてみます。 ネタは先日発表された、Amazon ECSBlue/Green Deploymentです。aws.amazon.com これまで、Amazon ECSでBlue/Green Deploymentを実装しようとした場合、CodeDeployによる連携が一般的でした。 それが今回のリリースにより、CodeDeploy不要となり、Amazon ECSの機能として閉じる形でシンプルに実装・管理できるようになったわけです。 さて、このアップデートにより、既存のCodeDeployの方式と比較して、どのような違いがあるのか気になる方もいるのではないでしょうか？ 今回は、CodeDeploy方式とECSネイティブ方式のBlue/Green Deploymentの違いに関して、少し
こんにちは。SRE部の巣立（@ksudate）です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプラインGitHub Environmentsによるリリー
Rather than continuously releasing what's landed to your default branch, release-please maintains Release PRs: These Release PRs are kept up-to-date as additional work is merged. When you're ready to tag a release,simply merge the release PR. Both squash-merge and merge commits work with Release PRs. When the Release PR is merged, release-please takes the following steps: Updates your changelog f
Tier: Free, Premium, UltimateOffering:GitLab.com,GitLab Self-Managed,GitLab Dedicated This document lists the configuration options for theGitLab .gitlab-ci.yml file. This file is where you define the CI/CD jobs that make up your pipeline. If you are already familiar with basic CI/CD concepts, trycreating your own .gitlab-ci.yml file by following a tutorial that demonstrates asimple or compl
突然ですが、git-pr-releaseのなんちゃってコラボレーターである私が僭越ながら、その王道の使い方を皆様に伝授していきます。何番煎じかの記事ではありますが、現代の、特にGitHub Actions出現以降の使い方をまとめたいというのが動機です。 https://github.com/x-motemen/git-pr-release https://rubygems.org/gems/git-pr-release git-pr-releaseはGitHubを業務開発で利用している場合に便利なツールで、デフォルトブランチにマージされたpull requestをリリース項目として一覧し、それをpull request化してくれるものです。これにより以下のことが実現できます。 リリース項目が一覧されることによるリリース内容の明確化 マージボタンによる明快なワンクリックデプロイの実現 pul
『ブログのインフラ構成を改善する』 にて残った以下の課題。 しかしこれによりWAFの ウェブACL x 1とルール x 1 の使用料が月6ドルが掛かってしまうので、そのうち(1)のLambda@Edgeでアクセス制限す流方法に変更しようと思う。 ということでWAFからLambda@EdgeによるBASIC認証へ移行する。 目的 今回の目的は以下4つ。 WAFをやめてBASIC認証で保護するTerraformでLambdaを管理するが関数コードは管理しないLambdaのビルド＆デプロイはTerraform外から行う ClojureScript + shadow-cljsでLambdaを作る WAFをやめてBASIC認証で保護する 『ブログのインフラ構成を改善する』 では「TerraformからWAFv2を使ってみたい」ということでブログ開発環境のアクセス制限に使用してみた。 とりあえず使
Lambda アプリケーションのモニタリング - AWS LambdaLambda コンソールの [アプリケーション] セクションには [モニタリング] タブが含まれており、アプリケーション内のリソースの集計メトリクスが表示されたAmazon CloudWatch ダッシュボードを確認できます。Lambda アプリケーションをモニタリングするにはLambda コンソールの [Applications (アプリケーション)] ページを開きます。 [モニタリング] を選択します。 グラフ内のメトリクスの詳細を表示するには、ドロップダウンメニューから [メトリクスで表示] を選択します。 グラフが新しいタブで開き、関連するメトリクスがグラフの下に一覧表示されます。このグラフの表示はカスタマイズできます。表示されるメトリクスやリソースを変更し、統計や期間などの要因を変更することで、現在の状況を詳しく理解できます。 デフォルトでは、Lambda コンソールにベーシ
Azure Pipelinesには、アプリケーションをデプロイするためのリリースパイプラインを、GUIで作る機能がありました。 この機能は大変便利なのですが、既に「Classic」と表現されていて、徐々に消えていく運命にあります。 今からやるなら、ビルド/リリースパイプラインの定義をYAMLで作り、ソースリポジトリと一緒に管理していくのがよい、とされています。 Azure PipelinesにもYAMLを使ったビルドパイプラインを作る機能があるのですが、悲しいかな仮想マシンに対してアプリケーションをデプロイすることが、標準的な方法では準備されていませんでした。 しかし、2019年末のSprint 162で、Azure Pipelinesから仮想マシンにデプロイするための機能が入りましたので、その中身を軽く確認してみようと思います。 Classicなリリースパイプラインで使っていた「Depl
開発チームごとに独自の要件があり、それによって、クラウド サービスで効率的なデプロイ パイプラインの実装が困難になる可能性があります。 この記事では、Azure App Service へのデプロイにおける 3 つの主要なコンポーネントである、デプロイ ソース、ビルド パイプライン、およびデプロイ メカニズムについて説明します。 この記事では、特定の言語スタックのベスト プラクティスとヒントについても紹介します。 デプロイ コンポーネント このセクションでは、App Service にデプロイするための 3 つの主要な構成要素について説明します。 デプロイ ソース デプロイ ソースは、アプリケーション コードの場所です。 運用アプリの場合、デプロイ ソースは通常、GitHub、Bitbucket、Azure Repos などのバージョン管理ソフトウェアによってホストされるリポジトリです。
//Stop re-writing pipelines! WhyGitHub Actions drive the future of CI/CD The Pipeline-as-Code pattern is implemented by most CI/CD platforms today. So what could be the next evolutionary step? Based onGitHub Actions, the article outlines why open-source Pipeline-as-CodeBuildingBlocks will take your pipelines to the next level.GitHub Actions –blog seriesPart 1:GitHub Actions CI pipeline: Git
クラウドを活用した本番システムのデプロイ手法の1つに「Blue-Green Deployment」がある。Blue-Green Deploymentの目的とそのメリットを、マーチン・ファウラー氏の解説から紹介する。 1つ前の記事で紹介した、チャド・ファウラー氏によるImmutable Infrastructureの記事「Immutable Infrastructure（イミュータブルインフラストラクチャ）と捨ててしまえるコンポーネント」では、デプロイをより安心して行うために、サーバの内容を変更する際には既存のサーバに手を加えるのではなく、新規に作り直して切り替える、という方法を提案しています。これがサーバの不変性、すなわちImmutable Infrastructureにつながるわけです。 これから紹介するマーチン・ファウラー氏の記事「BlueGreenDeployment」は、Immut
こんにちは、インフラ部の id:sue445 です。Terraformなにもわからないけどディレクトリ構成の実例を晒して人類に貢献したい - エムスリーテックブログ やTerraformのディレクトリ構成の模索 - Adwaysエンジニアブログ を読んで影響されたのでピクシブのTerraform運用事例を紹介しようと思います。Terraformの採用理由GitLabでのリポジトリ構成Terraformのファイル構成 moduleがうまく使えたと思っている事例GitLab CIでTerraformをいい感じにCIする テンプレートの使い方 ピクシブで実際に使っているテンプレートファイル このテンプレートでできること masterブランチ以外 masterブランチ このテンプレートファイルのポイント 最後にTerraformの採用理由Terraformと同じようなプロビジョニン
はじめに 前回のブログでは、マルチアカウントにおけるIAMユーザーの設計戦略についてご紹介しました。 今回は少しテーマを変え、以前筆者がJAWS DAYS 2020で登壇させていただいたCI/CDの内容を基に、データ保護の観点からの設計~実装を取り上げたいと思います。 ※少々お硬い内容を含みますが、AWS CI/CDセキュリティを考える上で一つのポイントになるはずなので、ご興味をお持ちの方は是非お付き合いください。m(_ _)m 前回ご紹介したCI/CD内容のおさらい JAWSDAYS2020にて「金融サービス向けに理想のCI/CDを追い求めたお話」というタイトルで、筆者が担当するサービスのCI/CD設計をご紹介いたしました。 ここで、「理想」という点についてもう一度振り返ると、それは「CI/CD導入により期待すること」と、「業務特性として守らなければならないこと」の両立でした。 高アジリ
終了 2018/04/27（金） 18:30〜 あつまれ！ CI/CDツール大集合！ - cndjp第5回 Cloud Native Developers JP 第5回勉強会です。 hhiroshell 他 東京都渋谷区道玄坂1丁目12番1号
GoogleとNetflix、カナリアリリース分析ツール「Kayenta」オープンソースで公開。新たにデプロイしたリリースに問題がないかを自動分析GoogleとNetflixは、共同開発したカナリアリリース分析ツールの「Kayenta」をオープンソースで公開した。新規リリースを本番環境に対して小規模にデプロイし、問題がないかを検証する作業を自動化。より迅速で確実な継続的デリバリを実現する。GoogleやNetflixのようにWebサービスを提供している企業では、そのWebサービスに次々と改良が加えられ、1日に何度も新しいリリースがデプロイされています。 しかし新しいリリースのデプロイはいきなり大規模に行われるわけではありません。リリースされるコードに対しては継続的デリバリのパイプラインの中で一通りの自動テストが行われ、ある程度の品質が保証されているはずです。しかし、それでも新しいリリー
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://media.amazonwebservices.com/jp/summit2015/docs/Dev-04d-Tokyo-Summit-2015.pdf
