CI/CD Conference 2021
数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021
CI/CD Conference 2021
AWSにおけるALB&NLBのBlue/Greenデプロイメント設計 - How elegant the tech world is...!
はじめに どうも、iselegant です。 前回、執筆した商業誌について本ブログで紹介させていただいたところ、大変多くの反響がありました。 コメントをくれた方、書籍に関心を持っていただいた方、本当にありがとうございます🙇 AWSコンテナ設計・構築[本格]入門 | 株式会社野村総合研究所, 新井雅也, 馬勝淳史, NRIネットコム株式会社, 佐々木拓郎 |本 | 通販 | Amazon 本日から少しの間、分量調整と締め切りの都合上、商業誌では執筆しきれなかった AWS 設計に関するサイドトピックについて、本ブログ上でご紹介したいと思います。 今日はALB (Application Load Balancer) と NLB (Network Load Balancer) の Blue/Green デプロイメントに関する設計がテーマです。 AWS で Web アプリケーションの可用性とパフォ
あなたの組織に最適なコンテナデプロイ方法とは？〜ECSにおけるデプロイ最新機能てんこ盛り〜
AWSにおけるコンテナワークロード運用のデファクトスタンダードの地位を確立したECS。 デプロイ方法も進化を続け、CodeDeployとALBで連携したB/Gデプロイやカナリアリリースにも対応し、そのデプロイにおける柔軟性はEKSに勝るとも劣りません。 そんなECSですが、手段が豊富になったこともあり現状「そもそもうちの組織としてどんなデプロイ方法が最適なのか？」を選択するのが難しくなっています。 このセッションでは、ECSのデプロイ機能を紹介しつつ、マルチアカウントでの運用、リリース承認プロセス、IaCとの連携方法、GitHub Actionsも含めた最新動向を全てお伝えいたします。
事業成長を加速させたエンジニアリングのウラ側 https://medpeer.connpass.com/event/211745/
「ECSデプロイの話だけで45分喋った男がいた…」 というわけで、先日、Developers.IO 2020 CONNECTにおいて、以下のタイトルで喋りました。 「あなたの組織に最適なコンテナデプロイ方法とは？〜ECSにおけるデプロイ最新機能てんこ盛り〜」 オンラインセッションは何度か登壇経験あったのですが、今回は45分。正直めっちゃくちゃ疲れました。いやぁ、登壇ってもしかしたら、リアルよりもオンラインのほうがつかれるかもしれません。 そんな登壇だったわけですが、内容あれこれ詰め込んでECSのデプロイだけに内容を絞ったのですが、その甲斐あってかいろんな方に参考にしていただける内容になったのではと考えています。 ぜひ、この記事を、皆さんの現場のECSデプロイをパワーアップする参考にしていただければと思います。 ホンマにECSデプロイだけで45分喋ったの…!? ( ﾟдﾟ) ｶﾞﾀｯ /
GitHub Actions + CircleCI + AWS CodeDeployによるCI/CD環境にインフラを移行した話 - SMARTCAMP Engineer Blog
スマートキャンプ、エンジニアの入山です。 前回のブログで、弊社プロダクトのインフラをEC2基盤からECS/Fargate基盤へ移行した話を紹介しました。 tech.smartcamp.co.jp 上記プロジェクトは大規模なインフラの刷新だったこともあり、CI/CDについても従来の仕組みからECS/Fargateの構成に合わせて変更しています。 CI/CDは、安定したプロダクト開発には必須且つ長期に渡って継続的に利用するものなので、いかにストレス少なく効率的に出来るかが重要だと考えています。 また、CI/CDは一度構築してしまうと放置されがちですが、日々の開発チーム全体の生産性にも大きな影響を与えるため、こういった数少ない再構築のタイミングではコストを掛ける価値があるのではないでしょうか。 今回は、弊社のインフラ移行時に実施したCI/CDの改善について紹介したいと思います。 従来のCI/CD
【開発者必見】Codeシリーズに最適化された通知サービスNotificationsがリリースされました！ | DevelopersIO
DevOpsやCI/CDに必須なサービスとしてすっかりおなじみになったCodeシリーズですが、今般、そのCodeシリーズに特化した通知サービスがリリースされました。 Introducing notifications for AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, and AWS CodePipeline Codeシリーズはアプリケーション開発〜運用のライフサイクル全般に関わるものが多く、それらを使っている中でリポジトリに対するプルリクエストの連絡、ビルド結果やパイプラインの実行結果、デプロイ結果などを通知するシチュエーションは非常に多くあります。従来、通知にはCloudWatch Eventsの利用が必須でしたが、今回Notificationsサービスとしてリリースされることで、Codeシリーズの中だけでの設定が可能となっています。
SlackでChatOps！CodeDeployのBlue/Greenデプロイを操作する方法 - SMARTCAMP Engineer Blog
スマートキャンプ、エンジニアの入山です。 昨年末から弊社BOXILでは、EC2からECS/Fargateへのインフラ移行作業を実施しています。 EC2運用からコンテナベースのECS運用への移行は、インフラの思想として異なる部分も多く、一筋縄ではいかないということを日々痛感しています。特に運用面に関する仕組みやノウハウは大きく異なっているため、今までと同等の運用を異なる方法で実現する必要があり、頭を悩ませることが多いです。 例えば、今まではEC2にSSHしてコマンドを投入していたが、ECS/Fargate上で同じことをどうやってやるのか…など。SSHしなくても良い運用にすることも必要ですが、今まで当たり前に出来ていたことが万が一の時にどうやっても出来なくなるのはやはり辛い問題ではないでしょうか。 また、とりあえず移行はできたけど、今までよりも運用に時間や手間が掛かるようになった…といったこと
AWS Chatbot を利用して AWS 開発者用ツールの通知を Slack で受け取る方法 | Amazon Web Services
Amazon Web Services ブログ AWS Chatbot を利用して AWS 開発者用ツールの通知を Slack で受け取る方法 本投稿は Sr. Product Manager の Anushri Anwekar による AWS DevOps Blog への投稿を翻訳したものです。 開発者は多くの場合、Slack 上でコードについての議論を行います。AWS Chatbot を使用すると、リポジトリ、ビルドプロジェクト、デプロイアプリケーション、パイプラインといった開発者用ツールの通知を設定し、重要なイベントを自動的に Slack へ通知することができます。デプロイに失敗した時、ビルドが成功した時、プルリクエストが作成された時などに、開発者はもっとも気付きやすい形で通知を受け取ることができます。 2020年1月時点で通知がサポートされている AWS のサービスは以下の通りです
AWS CodeDeploy が Amazon ECS の線形デプロイと Canary デプロイをサポートするようになりました | Amazon Web Services
Amazon Web Services ブログ AWS CodeDeploy が Amazon ECS の線形デプロイと Canary デプロイをサポートするようになりました AWS CodeDeploy は、Elastic Container Service (Amazon ECS) のブルー/グリーンデプロイサポートを拡張し、AWS Fargate または Amazon Compute Cloud (Amazon EC2) でホストされるアプリケーションの Canary および線形デプロイを含めます。 ブルー/グリーンデプロイは、アプリケーションバージョンの変更による中断を最小限に抑えるために、AWS CodeDeploy が提供する安全なデプロイ戦略です。これは、グリーンと呼ばれる新しいアプリケーション環境と、ブルーと呼ばれるライブトラフィックを処理している現在のアプリケーション
はじめに CodeDeployはALBを使って、複数台あるEC2を順次 振り分け停止 デプロイ実施 振り分け再開 する、といったデプロイ方法を取ることが可能です。 これを試してみたところ、想像していたよりもデプロイに時間がかかってしまいました。 また、ターゲットグループの設定を見直すことで処理時間を短縮できるので、その点も含めて記事化しています。 1. 構成 ALB EC2インスタンス * 2 ALBのターゲットグループでは、以下の通り2台のEC2インスタンスを登録しています。 この2台がCodeDeployのデプロイ対象です。 2. CodeDeployのデプロイグループの設定 ALBを使ったデプロイでのCodeDeployの設定です。 2.1. デプロイタイプ デプロイタイプはインプレースとしました。既存のEC2インスタンスに新しいアプリケーションをデプロイします。 なお、Blue/G
CodeDeployを使用したECS-FargateのBlue/Green Deploymentをしてみた。 | DevelopersIO
CodeDeployを使用したECS-FargateのBlue/Green Deploymentをしてみた。 はじめに Blue/Green Deploymentとは？ Blue/Green Deploymentでは、2つの環境を作成します。1つの環境(Blue)は現在のアプリケーションバージョンを実行し、もう1つの(Green)は新しいアプリケーションバージョンを実行します。Green環境でのテストが完了すると、アプリケーショントラフィックはGreen環境に転送されて、Blue環境は非推奨になります。 この記事では、CodeDeployを使用したFargateのblue/green deploymentをしてみました。 やってみた Application Load Balancer の作成 Target Groupsの作成 EC2 コンソールで、Load Balancingで Targe
Amazon ECS の Blue/Green デプロイメントの動作は何が起こっているか解説したい - Qiita
はじめに Amazon ECS は、コンテナを動かしうまく管理するためのコンテナオーケストレーションサービスです。新たなバージョンのコンテナをデプロイするときに、いろいろなデプロイの方法が取れますが、ECS 側で用意されているデプロイ戦略が3種類あります Rolling Update : Service の中で稼働しているタスクを少しずつ順繰りアップデートする方式 Blue/Green Deployment : 新たな環境である Green 環境を用意して、LB レイヤーで切り替える方式 External Deployment : 外部のサードパーティの何かでデプロイをコントロールする方式 こちらの Document に記載があります。 : https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-types.htm
AWS CDKを(途中まで)使用してAmazon ECSの Blue/Greenデプロイ環境を構築する | SEEDS Creators' Blog | 株式会社シーズ
AWC CDKに関してはチュートリアルのリンクなどを本文中に貼っていますのでそちらをご覧ください。 Amazon ECRに関してはこちらを。 Blue/Greenデプロイについてはリンクはつけていないですが検索すると情報はいろいろでてきます。 Amazon ECS (Fargate) の作成aws-ecs-patterns moduleを使うチュートリアル にあるのですが、AWS CDKに aws-ecs-patterns module というものがあります。 ゼロからコンソールで作成する場合Amazon ECSの作成のほかにロードバランサーの作成をして、、などちょっと手間がかかりますが、aws-ecs-patternsを使用すると簡単に動くところまで作成してくれます。 以下は基本的にチュートリアルのコードですが少し変更しています。 imageの指定をECRから取得するように変更 1imp
Perform ECS blue/green deployments through CodeDeploy using AWS CloudFormation - AWS CloudFormation
Perform ECS blue/green deployments through CodeDeploy using AWS CloudFormation You can use CloudFormation to perform ECS blue/green deployments through AWS CodeDeploy. Blue/green deployments are a safe deployment strategy provided by CodeDeploy for minimizing interruptions caused by changing application versions. This is accomplished by creating your new application environment, referred to as gre
こんにちは、AWS事業本部コンサルティング部の枡川です。 当エントリは弊社コンサルティング部による『AWS再入門ブログリレー2022』の16日目のエントリです。 このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2022年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。 では、さっそくいってみましょう。16日目のテーマは『AWS CodeDeploy』です。 AWS CodeDeployとは アプリケーションを構成するフ
AWS CodePipeline（CodeCommit → Codedeploy → EC2へデプロイ）を設定してみた - サーバーワークスエンジニアブログ
こんにちは！技術4課のイーゴリです。 この記事では、試しにAWS CodePipelineを使って、CodeCommit → Codedeploy → EC2へデプロイのプロセスを作ってみましたので、ご紹介したいと思います。 構成の説明 前提条件 IAMユーザー用のGit 認証情報の生成手順 CodeCommitリポジトリを作成する CodeCommitリポジトリにサンプルコードを追加する CodeDeployエージェントのインストール 事前準備（IAMロール作成） エージェントのインストール Codedeployでアプリケーションを作成 CodeDeployのIAMロール作成 アプリケーションの作成 デプロイグループの作成 CodePipelineでパイプラインを作成する 構成の説明 CodeCommitにコードをアップロードすると、CloudWatch Eventsがこれを検知して、C
CodePipelineの一連の流れを確認するためにテストをしているのですが、 CodeDeployにおいて、BlockTrafficとAllowTrafficが共に5分程かかっていました。 リリースのたびに10-15分も時間がかかることになってしまいます。 画像の差し替えなど、かなり頻繁にコンテンツリリースが発生するので、このままでは使い物になりません。 そのため、なんとか速度改善ができないか足掻いてみました。 環境 ALBBlockTraffic インプレースデプロイ方式 AutoScaling リリースコンテンツの総量は1MB程度 [対応その1] ヘルスチェックのパラメータを変更してみる AWSフォーラムに記載があったのですが、デプロイのライフサイクル中のBlockTrafficとAllowTrafficはELBのヘルスチェックの設定に関係しているとのこと。 そのため、ヘルスチェック
【CI/CD for Amazon ECS】ECSへの自動デプロイで利用するファイルをまとめてみた - サーバーワークスエンジニアブログ
こんにちは。AWS CLIが好きな福島です。 はじめに 概要図 ファイル一覧 フォルダ構成 各ファイルの詳細 CodeBuildで利用 1. buildspec.yml: ビルド処理の定義書 buildspec.ymlの例 version pre_build(ビルドの前処理) build(ビルド) post_build(ビルドの後処理) artifacts 2. Dockerfile: dockerビルド時に利用する定義書 Dockerfileの例 FROM COPY Dockerfileの詳細 CodeDeployで利用 3. appspec.yml: デプロイ処理の定義書 version TaskDefinition ContainerName ContainerPort 詳細 4. taskdef.json: タスク定義を作成する定義書 5. imageDetail.json: Am
[AWS Black Belt Online Seminar] AWS CodeDeploy 資料及び QA 公開 | Amazon Web Services
Amazon Web Services ブログ [AWS Black Belt Online Seminar] AWS CodeDeploy 資料及び QA 公開 先日 (2021/01/26) 開催しました AWS Black Belt Online Seminar「AWS CodeDeploy」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20210126 AWS Black Belt Online Seminar AWS CodeDeploy AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. cloudfront がELBの先にあった場合、blue/Green のデプロイした場合に、キャッシュはどのようになるのでしょうか？ A. CloudFront のキャッシュ保持期間が経過するまでキャッシュは更新されません
【備忘録】CodeBuildで`aws ecr get-login`コマンド実行時にエラーが発生する - Qiita
問題点 CodeBuildでaws ecr get-loginコマンド実行時にエラーが発生する ビルド結果 buildspec.yml(抜粋) version: 0.2 phases: pre_build: commands: - # 省略 - $(aws ecr get-login --no-include-email --region ${AWS_DEFAULT_REGION}) - # 省略 [Container] 2018/08/23 06:59:56 Running command $(aws ecr get-login --no-include-email --region ${AWS_DEFAULT_REGION}) An error occurred (AccessDeniedException) when calling the GetAuthorizationToken
AWSで実践! 基盤構築・デプロイ自動化(10) AWS CodeBuildを用いた継続的インテグレーション自動化(その1)
前回までで、下図のようにマイクロサービスアプリケーションや、それを呼び出すWebアプリケーションの単体／結合／E2E(EndToEnd)テストのコードを実装しました。 続く今回は、GitHubにプッシュしたこのアプリケーションのソースコードやテストコードに対し、AWS CodeBuildを使ってビルド／テストを行った後、カバレッジなどのソースコードメトリクスをスキャンした結果をSonarQuberServerへ連携する環境(最初の図「構築する環境の全体像」の3～6の部分)の構築を進めていきます。 AWS CodeBuildの概要 AWS CodeBuildはクラウドでアプリケーションのビルドを行う従量課金型サービスです。ビルドの元になるソースコードはS3に保存したものに加え、AWS CodeCommit、GitHub、BitBucketなどの各Gitベースのバージョン管理システムをサポート
CloudFormationを使って、インフラ構築を自動化/コード化してみます。この本ではハンズオン形式で Rails を ECS/Fargate にデプロイすること、CI/CD環境を作ること、ログの監視ができるようにすることを目指します。
GitHub + AWS CodePipeline|Build|Deployで自動ビルド・デプロイ環境の構築 - lycheejam's tech log
概要 ASP.NET CoreアプリをAWS LightsailでホスティングされているCentOS 7のサーバで公開するにあたり自動ビルド・自動デプロイ環境を構築しました。 所謂、CI環境と言うものですが自動テストは組み込んでいないためタイトルを「自動ビルド・デプロイ環境の構築」としています。 今回のインフラ基盤として使用したAWS LightsailはCodePipelineと統合されていないため、自動ビルド・デプロイ環境にAWS Codeシリーズを使用する旨味はあまりありません。 しかし、過去にAWS CodeBuildを使用してVue.jsの自動ビルド・デプロイ環境を整えた自身の経験があったためAWSを選択しました。 また、今回の構成では下記のような特徴があります。 AWS EC2などではなくオンプレミスなサーバ AWS CodeDeployと統合されていない環境 CodeDepl
ECSで開発用と本番用のCodePipelineを作る
version: 0.0 Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: <TASK_DEFINITION> LoadBalancerInfo: ContainerName: "app-container" ContainerPort: 3000 ビルド時に必要な環境変数があればssmのパラメータストアから渡す。ssmからも渡せる。 AWS_ACCOUNT_IDとAWS_DEFAULT_REGIONとIMAGE_NAMEに関してはcode buildの環境変数で定義している。 buildspec.yaml version: 0.2 env: parameter-store: DOCKER_USER: dockerhub-user DOCKER_TOKEN: dockerhub-t
ECS ServiceへのBlue Greenデプロイをする場合にデプロイメントコントローラとしてECSではなく, CodeDeployを利用することが多いかと思います. 以前CodePipelineを利用したBlue Greenデプロイは試して実装しましたが, 今回はDocker ImageをECR にpushするところから, CodeDeployでdeploymentを作成するところまで全て手動で実行してみたいと思います. 今回は内部動作の理解とCIツールで何をすべきかの確認を目標として行っています. 最終的にはCIツールからCodeDeploy経由でデプロイできれば一番良いとは思っています. 概要 実装する内容は図の通りです. この図の内容に沿ってどのような流れでデプロイをするかについて説明していきます. ECRリポジトリにDocker Imageをpushします. Docker I
CodeBuildでGitHubのOrganizationアカウントと接続する | Simple is Beautiful.
CodeBuildで個人のアカウントとの接続ではなく所属しているOrganizationと接続したかったので調べてみました。 GitHubアカウントと接続 GitHubアカウントのリポジトリを選択してOAuthで接続します。 GitHubの連携設定 右上のアカウントの設定を選んだあと左側のメニューからApplicationを選択します。次にAWS CodeBuildを選択して詳細を開き 下の方にあるOrganization accessのところにある対象のOrganizationの横にあるGrantを押します。 これでOrganizationアカウントとの連携の設定は完了なので、CodeBuildの設定画面に戻ってGitHubリポジトリの横のリロードマークを押してリロードするとGrantを押したOrganaizationのプライベートリポジトリも表示されているはずです。 参照 https:
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Deploy Rails apps in 2021
あなたの組織に最適なECSデプロイ手法の考察 | DevelopersIO
CodeDeploy + ALBでEC2に1台ずつデプロイする - Qiita
AWS再入門ブログリレー2022 AWS CodeDeploy 編 | DevelopersIO
AWS CodeDeployの速度改善(ALB) - Qiita
Rails × CloudFormation ハンズオン
CodeDeployを利用したECSのデプロイをCLIから試す | DevelopersIO