タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
「JX通信社Advent Calendar 2019」7 日目の記事です。 こんにちは。2019年9月からJX通信社のエンジニアとなった鈴木（泰）です。趣味は映画観賞です。 はじめに JX通信社では AWS の Lambda Layer、Lambda 関数を使った Serverless なアプリケーションの開発に従事しています。 私が初めて Lambda 関数に触れたのは2019年の9月です。 3ヶ月のあいだ業務で扱ってきたこともあり、現在では Lambda 関数をサクサク作れるようになりました。 また、複数の Lambda 関数を連携させて1つのアプリケーションを組んでみたり、共通する処理を Layer として切り出したりと、少しずつ複雑なこともできるようになりました。 最近の問題は、増えてきた Lambda 関数の管理です。 特に、Lambda 関数のデプロイにかかる手間の大きさが問題
はじめに おはようございます、もきゅりんです。 CodePipeline は使いたいのだけど、どんなデプロイフローにするか迷ってるといったことを聞くことがあります。 本稿では、CI/CDツールを CircleCI でも GitHub Actions でもなく、CodePipeline を前提として、そして代表的と思われる Git フローでどのように考えるかをまとめてみました。 諸事情と背景があって、基本的には AWSのサービス限定で CI/CDを利用したいというケースはよくあると思います。そういった状況に限定して、かつ、よくある環境セット、一般的なステージを利用した CodePipelineの CI/CDを想定しています。 とりあえず検討してみる材料にでもなれたら幸いです。 なお、どのタイプの Gitブランチフローが一番使いやすいとかそういう話はしません (できません)。 想定とする方 C
はじめにソースコードの管理にBacklogのGitリポジトリ、CI/CDにAWS CodePipelineを用いたかったのですが、CodePipelineの送信元にBacklogは指定出来ません。なの...
ECRへのPushでECSをデプロイするだけのシンプルなCodePipelineを試す | DevelopersIO
はじめに 瀬田@大阪オフィスです。1年に一つ、何か新しいことに手を出すことを目標にしているんですが、理解の浅いCode兄弟に入門してみることにしました。だってCodePipeline楽しそうなんだもの。 今回の構成 シンプルにECRへのPushでCodePipelineを発火させ、ECSにデプロイするだけの構成を作ります。 CodeCommitもCodeDeployも使用せず、S3から設定ファイルを取得します。 前提 ECRのリポジトリと、ECSは構成されているものとします。 手順 CodePipelineでSorceを作る(ECR+S3) ソースステージの編集からECRのソースを作成します。 ソースステージの編集から「アクションの追加」を押してS３のソースを作成します。 ポイントは、「S3 object key」に「imagedefinitions.json.zip」を入力しておくこと。
CloudFormation 一撃で EC2 の Blue/Green Deployment の CodePipeline を構築する | DevelopersIO
準備 CodeCommitに以下をプッシュします。 なお、CodePipelineによる自動デプロイではファイル上書きデプロイを設定できないので、必要に応じて appspec.ymlで元のファイルを削除するように対応します。 ソースコード(index.html, hello.conf) appspec.yml (本稿では beforeInstall.sh を利用) ちなみに、index.html や hello.conf の素材は こちら を使っています。 参考 ## appspec.yml version: 0.0 os: linux files: - source: ./hello.conf destination: /etc/nginx/conf.d/ - source: ./index.html destination: /usr/share/nginx/html/ hooks:
Github + CodeBuild + CodePipelineを利用したFargateのデプロイフローをTerraformで構築する | 株式会社ビヨンド
インフラエンジニアの寺岡です。 今回はFargateに対するアプリケーションのデプロイのお話です。 Code兄弟と言われていたりしますが AWSでは各種サービスに対してデプロイを行う際に便利なサービスがいくつかあります。 今回はその中のCodeBuildとCodePipelineを利用して Fargateに対してデプロイするパイプラインをTerraformで作成したのでコードを共有します。 Terraformのバージョンは「v0.12.24」です。 参考になされる場合はご注意ください。 今回構築したもの 以下の様になっています。 VPCはPublicとDMZとPrivateの3層構造にし PublicサブネットにはALBとNatGatewayを DMZサブネットにFargateのタスクを起動させてALBのターゲットグループに紐づけています。 デプロイのパイプラインの要のCodeBuildと
CodePipeline で簡単 Terraform CI/CD パイプラインの実装 | DevelopersIO
今回は、CodeCommit への push をトリガーに CodeBuild で terraform apply する CodePipeline を作成してみたいと思います。ざっくり環境は以下のとおりです。 環境 Terraform Backend S3 DynamoDB CodeCommit CodeBuild CodePipeline Terraform Backend の作成 今回は CI/CD パイプラインを使って Terraform を管理しますので、tfstate ファイルは共有可能な場所に保存する必要があります。また、このパイプラインは複数人が利用することが想定されるため、git push のタイミングによっては、同時に terraform apply が動作し tfstate に競合が発生してしまう可能性があります。 これらの課題は Terraform の Backend
AWS CDK(Cloud Development Kit )で、CodePipeline、CodeCommit、CodeBuildを使用した開発環境を作ってみました | DevelopersIO
AWS CDK(Cloud Development Kit )で、CodePipeline、CodeCommit、CodeBuildを使用した開発環境を作ってみました 1 はじめに CX事業本部の平内（SIN）です。 今回は、AWS CDKで、CodePipeline、CodeCommit、CodeBuildを使用した開発環境を作ってみました。デプロイされるのは、Lambdaファンクションのみです。 CodeCommitのリポジトリで、developブランチをコミットすると、dev環境のLambdaが更新され、masterブランチでprd環境が更新されるようになってます。 2 リポジトリ作成 最初に、CodeCommitでリポジトリを作成します。 スタックの中で作成することも可能ですが、その場合、スタックの削除でリポジトリも消えてしまうので、ちょっと運用上まずいかと思います。 $ aws
AWS AppConfigとAWS CodePipelineの統合による機能リリースの自動化 | Amazon Web Services
Amazon Web Services ブログ AWS AppConfigとAWS CodePipelineの統合による機能リリースの自動化 昨年、AWS AppConfigをリリースしました。これはアプリケーション設定の作成、管理及び迅速なデプロイを行う、AWS Systems Managerの新機能です。AppConfigを使用すると、デプロイメントを行う前にアプリケーション設定を検証でき、制御及び監視可能な方法で設定をデプロイできます。 AWS AppConfigを使用すると、アプリケーションコードのデプロイメントとは独立して、設定の変更をデプロイ可能です。つまり、アプリケーション設定を更新しても、アプリケーションの再起動やサービスの停止を行う必要がありません。AWS AppConfigを使用すれば、アプリケーションは更新した設定をすぐに使用できます。具体的には、AWS AppCon
CFnでGitHub + Fargate + CodePipelineを構築してみる | DevelopersIO
おはようございます、もきゅりんです。 CFnを使用してGitHub CodePipelineを作成してみたので、まとめておきます。 テンプレートの再利用等で役立てば幸いです。 先日、CodeCommitで構築したFargate+RDS(MySQL5.7)+FlaskをCFnで構築してみるを使った、GitHubでのケースになります。 実際に確認したい場合は、先にこの環境を構築する必要があります。 なお、やってから気付きましたが、こんなのも2年以上前にありました。 AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント そして、上記内容を弊社ブログ記事が丁寧に補足説明しています。 CodePipeline, CodeBuildを使ってAmazon ECSへの継続的デプロ
こんにちは、エンジニアの藤田です。 私事ですが、2018年の11月に入社してから半年以上が過ぎました！ 自分の入社エントリーを読み返してみると 入社から半年以上たった今も自分が思うスペースマーケットへの魅力は変わっていないような気がします。 しかしながら、入社早々いろいろなことを任せていただいたこともあり、スキル面はだいぶ変化がありました！ 今回は私がスペースマーケットに入社一ヶ月で、いきなり任された AWS CodePipeline を使った CI/CD の自動化について書こうと思います。 入社したてでシステムの構成もまだ把握していない段階でも、 AWS CodePipeline の力を借りて、比較的簡単に CI/CD を構築できました。 AWS CodePipeline とは AWS の公式ドキュメントから引用すると AWS CodePipeline は完全マネージド型の継続的デリバリ
LambdaのCDをCodePipelineとCloudFormationで構築してみる | DevelopersIO
おはようございます、もきゅりんです。 タイトル通りですが、CodePipelineを利用したLambdaのCD(Continuous Deployment)をCloudFormation(以下CFn)で構築してみたのでまとめました。 Lambdaを手元でわちゃわちゃやった後に、デプロイしたいときはリポジトリにプッシュすればよろしおす、便利よね、ということでCFnにしてみました。 色々なやり方があるとは思いますが、元ネタはこちらです。 AWS CodePipeline を使用して Lambda アプリケーションの継続的な配信パイプラインを構築する この例では、CodeCommitのGitリポジトリを利用します。 前提条件 CodeCommitが利用できる状態であること AWS CLIインストール＆設定済み CodeCommitリポジトリの作成については、『CodeCommit ユーザーガイド
CodePipeline で承認プロセスを設けた Terraform workspace の CI/CD パイプライン実装 | DevelopersIO
先日、CodeCommit への push をトリガーに terraform apply をサクッと実行するシンプルなパイプラインの記事を投稿しました。 今回はもうちょっと発展させて以下のような要件を取り込んでみたいと思います。 terraform workspace 環境でも使えるようにしたい 本番環境は terraform apply の前に承認者による承認プロセスを入れたい イメージは以下のとおりです。 開発環境向け 1-1. develop ブランチへ push 1-2. dev workspace に terraform apply を実行 本番環境向け 2-1. develop ブランチから master ブランチへ merge 2-2. prod workspace で terraform plan を実行 2-3. 承認者に後続処理の承認要求をメール通知 2-4. 本番用パ
CodePipelineでアクション間の変数の受け渡しができるようになりました | DevelopersIO
ECRをソース元にした場合はImageTagやImageURIなどが生成されるようになっています。 他のソース元の情報や詳細については下記ドキュメントを参考にしてください。 Variables 嬉しいこと 変数の自動生成により変数のベタ書きを減らすことができます。例えばECRのタグ名を環境変数で付与して使っていたCodeBuildだと、ECRをソース元にしていれば自動でタグ名引っ張ってきてくれるため設定箇所が減ります。 またスクリプトで生成した値をオリジナルの変数に格納して次のアクションに渡す等、幅広い使い道が考えられます。 さいごに 最近CodePipelineのアップデートが多いです。細かく柔軟にできることが増えてきています。かゆいところに手が届かずサードパーティのCI/CDツールを導入しているケースも多いかとは思いますが、いよいよCodePipelineだけでいいんじゃないか、という
[アップデート]CodePipeline 途中で実行を停止できるようになりました | DevelopersIO
はじめに CodePipelineのアップデートがありました。 AWS CodePipeline Enables Stopping Pipeline Executions CodePipelineを途中でストップさせることができます。 今まではCodePipeline実行した後に絶対これ失敗するやつだとなっても失敗をただただ見守ることしかできませんでした。時間もBuild実行するコストも無駄でした。 確認してみた 「実行を停止ボタン」が追加されています。 これをクリックすると新しいウィンドウが出てきます。 停止して待機 停止して終了 のどちらかが選べます。 前者は今実行中のアクションを待ってから停止、後者はまさに強制終了にあたるものです。 コメントも追加できるので何ゆえに停止したかを後から確認することができます。 さいごに より柔軟に使えるオプションが一つ増えました。特に検証段階などでは多
CodePipeline を利用した ECS Service の自動リリースをやってみた | DevelopersIO
ECS を利用したアプリケーションを構築する上でデプロイ戦略の選択は重要な要素になります. 開発段階では ECS が制御するローリングアップデートを利用して手動デプロイすることはあっても, 本番環境では自動デプロイが好ましいでしょう. 今回はCodePipelineを主軸に自動デプロイできる環境を構築します. デプロイ戦略の概要について 今回はパイプライン内でDocker Imageをビルド, pushを行った後に, ECS ServiceをBlue/Greenデプロイします. またDocker Imageに付与するタグとしてgitのコミットハッシュを利用することでコードとイメージを一意に紐づけることも同様に行います. パイプラインの構築は主にTerraformを利用しますが, 一部AWS CLIを利用します. 今回は検証が目的のため, 本番環境を意識したコード分割などは行っていません.
[アップデート]CodePipelineからStep Functionsの呼び出しが可能になりました | DevelopersIO
CodePipelineのアクションプロバイダーでStep Functionsの指定が可能になりました。 CodePipeline が新しいアクションタイプでの Step Functions の呼び出しをサポート こちらのアップデートにより、リリースプロセスの一部として、条件分岐、エラー処理などを含む複雑なワークフローを呼び出すことが可能になりした。以下のようにパイプライン内でStep Functionsの呼び出しができる感じです。 今回は以下チュートリアルをベースに、動作を確認してみたいと思います。 Tutorial: Use an AWS Step Functions Invoke Action in a Pipeline 前提 CodePipelineが作成済みであることを前提としています。前提環境となるCFnテンプレートを作成しましたので、ここではこちらを利用しています。 Gist
GitHub モノレポを AWS CodePipeline と統合して、プロジェクト固有の CI/CD パイプラインを実行する | Amazon Web Services
Amazon Web Services ブログ GitHub モノレポを AWS CodePipeline と統合して、プロジェクト固有の CI/CD パイプラインを実行する (この記事は、Integrate GitHub monorepo with AWS CodePipeline to run project-specific CI/CD pipelines を翻訳したものです。) AWS CodePipeline は、ソフトウェアのリリースに必要なステップをモデル化、可視化、自動化できる継続的デリバリーサービスです。AWS CodePipeline を使用して、コードを構築し、稼働前の環境にデプロイし、アプリケーションをテストし、実稼働環境にリリースするまでの完全なリリースプロセスをモデル化できます。AWS CodePipeline は、コードが変更されるたびに定義されるワークフロー
CodePipelineからCodeBuildの環境変数が設定できるようになりました！ | DevelopersIO
はじめに こんにちは！AWS事業本部の島川です。 CodePipelineからCodeBuildの環境変数が設定ができるようになりました。 AWS CodePipeline Enables Setting Environment Variables on AWS CodeBuild Build Jobs You can now set environment variables for CodeBuild build jobs in your pipeline. これまでは複数環境下の場合、環境ごとにCodeBuildプロジェクトを用意⇒環境変数を設定するということが必要でした。 CodePipelineもその分の数が必要でした。 それが今回のアップデートにより、1つのCodeBuildプロジェクトのみで複数環境に対応できるようになりました。 CodePipelineの追加だけで済むように
AWS CodePipeline Enables Setting Environment Variables on AWS CodeBuild Build Jobs
You can now set environment variables for CodeBuild build jobs in your pipeline. Previously, build jobs in your pipeline could only use environment variables defined in the build project configuration or buildspec file. When building for different environments and stages, you can now set environment variables directly through CodePipeline. You can now reuse the same build project for multiple acti
Amazon SNS + AWS Chatbotを使ってコーディングなしでCodePipelineのデプロイステータスをSlackへ通知する
Amazon SNS + AWS Chatbotを使ってコーディングなしでCodePipelineのデプロイステータスをSlackへ通知する これまでCodePipelineのデプロイステータスの通知をするとなるとCloudWatch EventsやLambdaを使う必要がありましたが、AWS Chatbotが登場してから驚くほど簡単になりました。 Slack連携についてノンコーディングで設定できたのでその手順を書きたいと思います。 CodePipeline Notification Ruleの設定 CodepiplineのDeveloper Tools画面を開き、 「Pipepeline」→ 「Pipelines」→「Settings」をクリックします。 次に「Create notification rule」をクリックします。 そしてNotification rule作成に必要な情報を
前回、本番環境向けの CI/CD パイプラインとして承認プロセスを設けたパターンをご紹介しました。 環境によってはこれで十分かもしれませんが、より厳格に運用されている環境においては「2 名以上の承認が必要」といった要件もあるのではないでしょうか。今回は CodePipeline で 2 名以上の承認を必要とするパイプラインの実装方法をご紹介したいと思います。 イメージ こちらの実装を行うにあたり、以下のサイトを参考にさせていただきました。 Enforcing the 'Two-Person Rule' with AWS CodePipeline (UPDATED) やってみる 今回の構成においてポイントとなるのは以下 2 点の実装です。 承認者 A (承認グループ A) が承認プロセス B の承認を行えないこと（その逆も然り） 承認者が同一でないこと それでは実装していきましょう。 承認プ
Multi-Region Terraform Deployments with AWS CodePipeline using Terraform Built CI/CD | Amazon Web Services
AWS DevOps Blog Multi-Region Terraform Deployments with AWS CodePipeline using Terraform Built CI/CD As of February 2022, the AWS Cloud spans 84 Availability Zones within 26 geographic Regions, with announced plans for more Availability Zones and Regions. Customers can leverage this global infrastructure to expand their presence to their primary target of users, satisfying data residency requireme
AWS Loft好きなKyoです。CLIも好きです。 CI/CDに入門するためにS3への静的サイトのデプロイパイプラインを作ってみました。なお、今回は自動デプロイのみなので、CI/CDではなくCDですね。 参考にしたのは、以下の公式チュートリアルです。 Tutorial: Create a Pipeline That Uses Amazon S3 as a Deployment Provider 環境 macOS Mojave 10.14.6 aws-cli/1.16.232 Python/3.7.3 Darwin/18.7.0 botocore/1.12.222 構築してみた 大きく3種類の作業が必要となります。1,2についてはCLIから作業を行いました。 CodeCommitのレポジトリの作成 S3バケットの作成および静的サイトホスティングの設定 CodePipelineのパイプライン
Secure and analyse your Terraform code using AWS CodeCommit, AWS CodePipeline, AWS CodeBuild and tfsec | Amazon Web Services
AWS DevOps Blog Secure and analyse your Terraform code using AWS CodeCommit, AWS CodePipeline, AWS CodeBuild and tfsec Introduction More and more customers are using Infrastructure-as-Code (IaC) to design and implement their infrastructure on AWS. This is why it is essential to have pipelines with Continuous Integration/Continuous Deployment (CI/CD) for infrastructure deployment. HashiCorp Terrafo
EC2インスタンスのデプロイを CodePipeline + CodeDeploy + CodeBuildで改善した話 - Sansan Tech Blog
はじめまして、技術本部 サービス開発部の上島です。 私はSansanのプロダクトの裏側でデータ統合の役割を担う「名寄せシステム」の開発に携わっています。 今回は、その名寄せシステムのEC2で稼働しているRailsアプリのデプロイの仕組みを、CodePipeline+CodeDeploy+CodeBuildを使った仕組みに移行して、デプロイ環境を改善した取り組みについて、紹介したいと思います。 名寄せシステムとは 関連のある名刺データを統合することで、顧客情報を一元管理できるようにしたり、世の中の様々なビジネスデータを収集し、名刺に紐づけることで、名刺の価値を高めるシステムです。 Ruby(Rails)で開発しており、AWSの利用サービスは EC2、RDS(Aurora MySQL)、S3、ElastiCache(Redis)などがあり、一般的な構成のアプリケーションです。 独自のデプロイシ
【AWS CDK】GitHub の Release をトリガーに CodePipeline を起動する（GitHub ソースアクション Version 2 版） | DevelopersIO
【AWS CDK】GitHub の Release をトリガーに CodePipeline を起動する（GitHub ソースアクション Version 2 版） はじめに テントの中から失礼します、IoT 事業部のてんとタカハシです！ 先日、GitHub の Release をトリガーにして、CodePipeline を起動する構成を CDK で構築する方法について記載しました。 ただ、上記で記載した構成では、GitHub のソースアクション「Version 1」を使用しています。GitHub のソースアクション「Version 1」は、既に非推奨となっているため、特別な理由が無い限りは「Version 2」を使用する方が好ましいです。 今回は、GitHub のソースアクション「Version 2」を使用して、同様な構成を CDK で構築します。 環境 % sw_vers ProductN
サードパーティの Git リポジトリから AWS CodePipeline のビルドステータスを追跡する | Amazon Web Services
Amazon Web Services ブログ サードパーティの Git リポジトリから AWS CodePipeline のビルドステータスを追跡する (この記事は、Tracking the AWS CodePipeline build status from the third-party Git repository を翻訳したものです。) AWS CodePipeline では、パイプラインのソースとしてサードパーティの Git リポジトリを使用できますが、ビルドステータスをサードパーティ Git リポジトリダッシュボードで確認できない場合があります。開発者がリポジトリで作業する場合、同じダッシュボードでビルド/パイプラインのステータスを確認できることが望ましいです。このブログでは、パイプライン/ビルドステータスをサードパーティのリポジトリに反映するソリューションの構築手順を説明し
別のAWSアカウントにあるCodeCommit RepositoryをソースとするCodePipelineをCloudFormationで構築してみた | DevelopersIO
別のAWSアカウントにあるCodeCommit RepositoryをソースとするCodePipelineをCloudFormationで構築してみた 中山です 今日はタイトルの通り、別のAWSアカウントにあるCodeCommit RepositoryをソースとするCodePipelineをCloudFormationで構築してみたので、その内容をまとめてみました。 背景 まず、構築してみた経緯を少し述べます。 マルチアカウント戦略 AWSを利用する際、どのようにAWSアカウントを利用するか事前に戦略を定めて運用を開始することが多いのではないかと思います。 個人的な印象では、環境毎(Production/Staging/Develop,etc)にAWSアカウントを作成して運用するケースが多いです。 実際、AWSからもLanding ZoneというソリューションやControl Towerと
[Terraform] CodeCommitで管理するモノレポの変更に応じてCodePipelineの実行を振り分ける - Qiita
はじめに 本記事では、CodeCommitで管理する単一リポジトリ（モノレポ）において、 変更されたディレクトリに応じて、実行するCodePipelineを振り分けるCIパイプラインをTerraformで構築する方法について記載しています。 Terraform で構築する全体構成図 構成の概要 Systems Managerの Parameter Storeには、リポジトリ内のディレクトリ名と実行する CodePipeline名がJSON形式で格納されています。 開発者がCodeCommit のリポジトリにコードをプッシュすると EventBridgeがリポジトリの変更イベントを検知してLambda関数をトリガー実行します。 Lambda関数は、Systems Managerのパラメータを読み取って、変更があったディレクトリに応じたCodePipeline を実行します。 変更があったディ
![[Terraform] CodeCommitで管理するモノレポの変更に応じてCodePipelineの実行を振り分ける - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f0a2467e855aede439f2a92b2cf361396edbd34/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCVGVycmFmb3JtJTVEJTIwQ29kZUNvbW1pdCVFMyU4MSVBNyVFNyVBRSVBMSVFNyU5MCU4NiVFMyU4MSU5OSVFMyU4MiU4QiVFMyU4MyVBMiVFMyU4MyU4RSVFMyU4MyVBQyVFMyU4MyU5RCVFMyU4MSVBRSVFNSVBNCU4OSVFNiU5QiVCNCVFMyU4MSVBQiVFNSVCRiU5QyVFMyU4MSU5OCVFMyU4MSVBNkNvZGVQaXBlbGluZSVFMyU4MSVBRSVFNSVBRSU5RiVFOCVBMSU4QyVFMyU4MiU5MiVFNiU4QyVBRiVFMyU4MiU4QSVFNSU4OCU4NiVFMyU4MSU5MSVFMyU4MiU4QiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MzQzOGNkZDY4NDFhOGFkZTIwMDM0ZGZjYTA3NDEwNzc%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwb2t1Ym90NTUmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zMiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTI5ZWU2N2RmYjZhZTcyOTM5Mzg1NTAxZGRiODQzZDE4%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D363ff9f7e9a619e0438020078659d5b6)
CodeDeploy,CodePipelineで、S3に置いたソースコードをEC2インスタンスにデプロイするパイプラインを作ってみた | DevelopersIO
CodeDeploy,CodePipelineで、S3に置いたソースコードをEC2インスタンスにデプロイするパイプラインを作ってみた Codeシリーズ触ってみよう！ということでAWS公式チュートリアル「シンプルなパイプラインを作成する (Amazon S3 バケットの場合)」をやってみたレポートです。 こんにちは、大阪オフィスのかずえです。 Codeシリーズ触ってみよう！ということで以下AWS公式チュートリアルをやってみたレポートです。 チュートリアル: シンプルなパイプラインを作成する (Amazon S3 バケットの場合) やること ZIPで固めたソースコードをS3にアップすると、複数のEC2インスタンスに自動デプロイされる仕組みを作ります。 さらに、実際の現場ではいきなり本番環境にデプロイするなんてことはあまりないですよね。ということでデプロイ対象をもう一つ作成し、ステージング環境へ
[AWS CDK] CodePipelineのソース元を色々指定してみました（CodeCommitとか、Githubとか、S3 Bucketとか、BacklogのGitとか) | DevelopersIO
[AWS CDK] CodePipelineのソース元を色々指定してみました（CodeCommitとか、Githubとか、S3 Bucketとか、BacklogのGitとか) 1 はじめに CX事業本部の平内（SIN）です。 CodePipelineでは、各種のソースが利用可能です。 今回は、AWS CDK(AWS Cloud Development Kit)で、CodePipelineのソース元を色々変えて記述要領を確認してみました。 2 サンプル 最初に、本記事の基準となるサンプルコードです。 更新されたコードでLambdaを更新します。 #!/usr/bin/env node import cdk = require('@aws-cdk/core'); import * as codepipeline from '@aws-cdk/aws-codepipeline'; import
![[AWS CDK] CodePipelineのソース元を色々指定してみました（CodeCommitとか、Githubとか、S3 Bucketとか、BacklogのGitとか) | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/b3e2a7c179f476b77a4d8776332d9d9f737e6d55/height=288;version=1;width=512/https%3A%2F%2Fd1tlzifd8jdoy4.cloudfront.net%2Fwp-content%2Fuploads%2F2019%2F08%2Faws-cloud-development-kit.png)
はじめに 今年の10月に株式会社LITALICOに入社しました@i-kです。SREチームに所属しています。 この記事は『LITALICO Advent Calendar 2020』2日目の記事です。 前職でCI/CDパイプラインを設計・構築した際にCodePipelineを使おうとして苦労した話を書いていこうと思います。 CodePipelineとは フルマネージドのCI/CDサービスです。 リポジトリサービスのCodeCommitやビルドサービスのCodeBuild、デプロイサービスのCodeDeployやAWS以外のCIツール等と連携してデプロイフローを構築することができます。ソースにはGitHubやCodeCommit以外にECRやS3、Bitbucketを指定できます。 AWSのサービスなので当たり前なのですが他のAWSサービスと親和性が高いです。 手動承認ステージが作れたり、Cl
serverless frameworkをCodePipelineでデプロイするCloudFormationを作成する | DevelopersIO
目標 CodeCommitにホストされたserverless frameworkのコードをCodePipelineでデプロイするためのCloudFormationを作成します。 serverless frameworkのデプロイコマンドにはstageオプションがあり、ステージ（環境）ごとにデプロイされるようになっています。それにあわせてCodePipelineもステージ別に作成するように実装してみます。今回はdevとprdという2環境むけに作成します。 環境 今回は下記の環境で確認しています。 serverless framework: 1.67.0 Codepipeline runtime: Node.js 12.x serverless framework側 ソースコードの変更 CloudFormationテンプレート作成の前にまずserverless framework側（CodeC
CodePipeline + Fargate + FastAPIで本番・開発・ローカル毎に環境変数が変わるCI/CDを構築してみた - Qiita
CodePipeline + Fargate + FastAPIで本番・開発・ローカル毎に環境変数が変わるCI/CDを構築してみたDockerECSCodePipelineECRCICD はじめに 初めまして。現在、新卒1年目でグーホームチームに所属しているプロトソリューションの川崎です。 今回は業務でAPIサーバーのCI/CDを構築する業務があり、その中で得た知見を書いていこうと思います。 環境 【筆者ローカル環境】 ・Windows ・WSL(コントリビューション：Ubuntu-20.04) ・Docker 20.10.23 【使用した主なAWSサービス】 ・CodeCommit ・CodeBuild ・CodePipeline ・Elastic Container Registry ・Elastic Container Service(ECS on Fargate) この記事で分かる
概要 会社で aws を触ることになり、基本から学んでいこうと思ったため備忘録として記事を書き始めました。 今回は 有名な Blue/Green デプロイ に関する概要説明の後 CodePipeline と ECS を使用して 自分の PC 内の Next アプリケーションを Blue/Green デプロイして Web 上に公開してみます 🌀 もし理解が違うよというところ等ありましたら優しく教えて頂けると幸いです 🙇♀️ Blue/Green デプロイ とは Blue/Green デプロイとは、アプリケーションのデプロイをダウンタイム無しに行うことができるデプロイ手法のことです。 下の図をご覧ください。 旧アプリケーションから新アプリケーションにアプリケーションの移行を行いたかったとします。 もし Blue/Green デプロイを行わなかった場合旧アプリケーションを新アプリケーション
Scanning images with Trivy in an AWS CodePipeline | Amazon Web Services
Containers Scanning images with Trivy in an AWS CodePipeline This post was contributed by AWS Container Hero, Liz Rice, VP Open Source Engineering at Aqua Security. If you’re working with containers, it’s important to scan your images for known vulnerabilities, so that you don’t deploy code that an attacker can easily exploit. A good way of ensuring that all your deployed images get this check is
静的WebサイトをCodePipelineとCodeCommitをつかって自動デプロイしてみた | DevelopersIO
はじめに こんにちは、久住です。 静的WebコンテンツをS3で公開する際、「誤った資材を公開しない」、「バージョン管理を適切にしたい」、「承認プロセスをはさみたい」等、考慮事項が増えてくると思います。 今回はCodeCommitとCodePipelineを使った承認プロセスをはさんだ自動デプロイを試してみました。 構成 静的Webコンテンツ構成は一般的なCloudfront -> S3の構成にしています。 CloudfrontとS3間の通信はHTTPSとしたかったのでS3の静的Webサイトホスティングは無効にしています。 本構成は下記の流れをイメージしています。 エンジニアがローカルリポジトリで作業し、CodeCommitにpush（もしくはbranchからマージ） CodePipelineが検知してSNSで管理者に通知、承認レビュー 承認OKとなったらS3にデプロイ Cloudfront
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
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CodePipelineを用いたLambdaのデプロイについての所感 - JX通信社エンジニアブログ
CodePipeline を使った Gitブランチ運用をまとめてみた | DevelopersIO
BacklogのGitにCI/CDを導入する方法（AWS CodePipeline & TypeScript編）
AWS CodePipeline で CI/CD の仕組みを構築したお話 | スペースマーケットブログ
CodePipelineとGitHubを連携する方法を追求したら Github Actionsでやるべきという結論に至った話
CodePipeline で複数名の承認を必要とするパイプラインの実装方法 | DevelopersIO
CodePipelineとCodeCommitとS3でCD入門してみた | DevelopersIO
CodePipelineでCI/CDパイプラインを組もうとして苦労した話 - Qiita
【AWS】CodePipeline＋ECSでBlue/Greenデプロイしてみた
www.youtube.com
anond.hatelabo.jp
treeswarmth.blog.jp
qiita.com/tearoom6
riisansaro.booth.pm
www.kinutaniyutaka.com