はじめに はてなサマーインターン2018の大規模システム開発コースの成果報告をします。 今年は、メンターのid:cohalzさん、id:wtatsuruさんの下、実際に使われているサービスをAmazon ECS(Elastic Container Service)にデプロイする基盤を構築しました。 コンテナでサービスを本番運用するために、AutoScaleの検証や、デプロイ時間の計測、改善策の検証を行いました。また、開発、デプロイフローを楽にするために、AWS CodeBuild、CodePipelineを使ってCI/CDの構築も行いました。これにより、PullRequestごとにCIが走り、masterにマージされたら自動でECSにデプロイすることができるようになります。高速なデプロイ切り替えを行うために、Blue-Green Deploymentの検討も行いました。 他にも、Micro
AWS×コンテナで基本的なDevSecOpsアーキテクチャをデザインしたお話 - How elegant the tech world is...!
はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは？ DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
あなたの組織に最適なコンテナデプロイ方法とは？〜ECSにおけるデプロイ最新機能てんこ盛り〜
AWSにおけるコンテナワークロード運用のデファクトスタンダードの地位を確立したECS。 デプロイ方法も進化を続け、CodeDeployとALBで連携したB/Gデプロイやカナリアリリースにも対応し、そのデプロイにおける柔軟性はEKSに勝るとも劣りません。 そんなECSですが、手段が豊富になったこともあり現状「そもそもうちの組織としてどんなデプロイ方法が最適なのか？」を選択するのが難しくなっています。 このセッションでは、ECSのデプロイ機能を紹介しつつ、マルチアカウントでの運用、リリース承認プロセス、IaCとの連携方法、GitHub Actionsも含めた最新動向を全てお伝えいたします。
AWS News Blog
New — File Release for Amazon FSx for Lustre Amazon FSx for Lustre provides fully managed shared storage with the scalability and high performance of the open-source Lustre file systems to support your Linux-based workloads. FSx for Lustre is for workloads where storage speed and throughput matter. This is because FSx for Lustre helps you avoid storage bottlenecks, increase utilization of compute
「ECSデプロイの話だけで45分喋った男がいた…」 というわけで、先日、Developers.IO 2020 CONNECTにおいて、以下のタイトルで喋りました。 「あなたの組織に最適なコンテナデプロイ方法とは？〜ECSにおけるデプロイ最新機能てんこ盛り〜」 オンラインセッションは何度か登壇経験あったのですが、今回は45分。正直めっちゃくちゃ疲れました。いやぁ、登壇ってもしかしたら、リアルよりもオンラインのほうがつかれるかもしれません。 そんな登壇だったわけですが、内容あれこれ詰め込んでECSのデプロイだけに内容を絞ったのですが、その甲斐あってかいろんな方に参考にしていただける内容になったのではと考えています。 ぜひ、この記事を、皆さんの現場のECSデプロイをパワーアップする参考にしていただければと思います。 ホンマにECSデプロイだけで45分喋ったの…!? ( ﾟдﾟ) ｶﾞﾀｯ /
「JX通信社Advent Calendar 2019」7 日目の記事です。 こんにちは。2019年9月からJX通信社のエンジニアとなった鈴木（泰）です。趣味は映画観賞です。 はじめに JX通信社では AWS の Lambda Layer、Lambda 関数を使った Serverless なアプリケーションの開発に従事しています。 私が初めて Lambda 関数に触れたのは2019年の9月です。 3ヶ月のあいだ業務で扱ってきたこともあり、現在では Lambda 関数をサクサク作れるようになりました。 また、複数の Lambda 関数を連携させて1つのアプリケーションを組んでみたり、共通する処理を Layer として切り出したりと、少しずつ複雑なこともできるようになりました。 最近の問題は、増えてきた Lambda 関数の管理です。 特に、Lambda 関数のデプロイにかかる手間の大きさが問題
人工衛星の運用を支えるクラウドネイティブ民主化への取り組み / Efforts toward cloud-native democratization for satellite operations
Kustomize + CodePipeline + CodeBuildでEKSに継続的デプロイしてみた | DevelopersIO
こんにちは、かたいなかです。 Kubernetesを仕事で触っていて、CodePipeline/CodeBuildとKustomizeを組み合わせての継続的デプロイを検証する機会があったので備忘録として記事にまとめてみます。 Kustomizeとは KustomizeはkubernetesのYAMLファイルをパッケージングするツールです。ベースの構成をもとにSTG/PRDなどの環境ごとに変えたい設定などを上書きすることができます。Kustomizeで生成されたYAMLを、kubectl applyする形で使用します。将来的にkubectlへの統合が前提に開発されているそうです。 今回はこのKustomizeをCodePipeline/CodeBuildと組み合わせて使用し、継続的デプロイできるようにしていきます。 パイプラインの構築 今回は以下の図のようなパイプラインを組んでいきます。 前
【開発者必見】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シリーズの中だけでの設定が可能となっています。
はじめに おはようございます、もきゅりんです。 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」を入力しておくこと。
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/CodeBuild/ECR/ECS/Fargateのコンテナデプロイ基盤を構築してみました - LCL Engineers' Blog
モバイルアプリエンジニアの山下（@yamshta）です。 今回は、AWSの以下のサービスを用いてコンテナデプロイ基盤の構築を試してみました。 CodePipeline CodeBuild ECR ECS Fargate AWSのドキュメントは丁寧で情報も豊富ですが、サービス毎に手順が書かれているため一連の流れをまとめました。CLIでの操作のみで手順を進めています。 なぜアプリエンジニアがデプロイ基盤を構築するのか 疑問に思った方もいらっしゃると思うので手短に書かせていただきます。 LCLのエンジニアチームはスペシャリスト集団というよりはゼネラリスト集団に近く、特定の技術に縛られない文化とそれを推奨する環境になっています。そのため、メインに扱う技術力も伸ばしながらも別の技術を習得することができます。 今回の経緯ですが、私個人としてはインフラには興味がありませんでした。しかし、Dockerは環
CircleCI 2.0アップグレードをあきらめてCodePipelineでGitHub→S3静的ホスティングのCD環境を作った話 | DevelopersIO
ベルリンのしがひです。クラスメソッドヨーロッパのウェブサイトはS3のスタティックホスティングとCloudFrontを使ったサーバーレス・超低コストな構成になっているのですが、サイトの編集管理ワークフローとして、GitHubとCircleCIを使っていました。 CircleCIはパフォーマンスが大幅に強化されたバージョン2.0が現行で、1.0は2018年8月31日でディスコンされるというアナウンスが昨年のはじめにありました。1.0 --> 2.0のアップグレードは何かボタンを押せばできるというたぐいのものではなく、yamlの書き換えとソース配置の再検討が必要になる大仕事で、見なかったことにしていたら9月になっていました。 早くアップグレードしなさいという圧を感じます。しかしこう言われると、動いているものを変えろというわりには成果が少なく、もっとなんかできるんじゃないか、と、このメッセージを書
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 Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeDeploy
2015年10月28日に放送したAWS CodeCommit & AWS CodePipeline & AWS CodeDeployの回の資料です。今後の予定は以下をご覧ください。 http://aws.amazon.com/jp/about-aws/events/#webinar Read less
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
GitHub/CodeBuild/CodePipelineを利用してCloudFormationのCI/CDパイプラインを構築する | DevelopersIO
GitHub/CodeBuild/CodePipelineを利用してCloudFormationのCI/CDパイプラインを構築する はじめに こんにちは、中山です。 最近CloudFormation(以下CFn)を書く機会が多いです。いろいろと個人的に思うところもあるのですが、やはりAWS公式サービスなので他サービスとの連携が手厚くサポートされている印象があり、好きなサービスの1つです。例えばLambda-backed Custom Resourceを利用することでイベントドリブンに処理を実装できたりします。 今私が関わっている案件的にチームとして動く機会が少なかったので、CFnテンプレートはローカルで管理することが多かったです。しかし、個人で開発している分にはこれでもよいのですが、チームとして管理する場合には問題が出てきます。テンプレートのテスト、スタックの作成/更新フローなどが統一され
CodePipeline で ECS にデプロイできるようになり、Docker 環境の継続的デリバリも簡単になりました | DevelopersIO
ども、藤本です。 現地時間 2017/12/12、CodePipeline のデプロイにて、ECS を選択できるようになり、ECS Service にデプロイできるようになりました。 AWS CodePipeline Adds Support for Amazon ECS and AWS Fargate 早速、試してみました。 概要 AWS CodePipeline は AWS や AWS 以外の SaaS を繋ぎ合わせて継続的デリバリを実現、モニタリングするサービスです。今まで CodePipeline が連携可能なデプロイサービスには CodeDeploy、Beanstalk、CloudFormation、OpsWorks の 4つがありました。ここに ECS が加わりました。ECS へのデプロイには、今までの EC2 上のコンテナにも可能ですし、先日の re:Invent 2017
こんにちは、かたいなかです。 以前、ECSがCodeDeployによるBlue/Greenデプロイに対応したことをお伝えしました。 今回は、CodePipelineからECS+CodeDeployへのデプロイを行うことで、CodeBuildでDockerイメージをビルドし、ビルドしたイメージをもとにタスク定義の新しいリビジョンを登録、ECSのサービスを更新するといった一連の流れを自動で行えるようにする方法をご紹介します。 構築するパイプラインの概要 今回は、以下のようなパイプラインを構成します。 GitHubの特定のブランチを変更を契機に処理を開始します。CodeBuildでイメージをビルドし、ECRにプッシュします。そして、最後にCodeDeploy + ECSを使用してデプロイを行うという流れです。 手順 では、実際にやっていきましょう。 設定としては以下の流れで進めます。 CodeD
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
【速報】フルマネージドのビルドサービスCodeBuild爆誕 #reinvent | DevelopersIO
はじめに こんにちは、中山です。 re:Invent 2016に参加中です。現地時間12/1(木)の8:30から実施されているWerner Vogels氏によるキーノートの中で発表された新サービス、CodeBuildについてレポートします。 CodeBuildとは何か 以下の資料が参考になります。 ドキュメント FAQ Jeffさんによる紹介ブログ 概要は以下のとおりです。 一言でいうと「フルマネージドのビルドサービス」 フルマネージドなのでJenkinsのように自分でビルドサーバを管理する必要がない 並行処理などを利用してスケール可能 サードパーティ製ツールを使って機能を拡張可能 CodePipeline/CodeCommit/CodeDeployといったCode3兄弟と連携可能 CodePipelineのJenkinsプラグインを利用すれば、CodeBuildをJenkinsのスレーブ
CodeDeploy の Blue/Green デプロイを利用して、CodePipeline でいい感じに自動化されたデリバリを実装する | DevelopersIO
CodeDeploy の Blue/Green デプロイを利用して、CodePipeline でいい感じに自動化されたデリバリを実装する こんにちは、藤本です。 ちょっと前から、AWS の Code◯◯ をベースにデリバリの自動化を勉強しています。 今回は今までブログエントリしてきたデリバリ方法に、先日リリースされた CodeDeploy の Blue/Green デプロイを組み合わせた実装を試すとともに、リリースプロセスを今一度整理してみました。 今までのエントリは下記をご参照ください。 CodePipeline で CodeCommit/CodeBuild/CodeDeploy を繋げてデリバリプロセスを自動化してみた #reinvent CodePipeline で承認プロセスを設けて本番環境へリリースする #reinvent CodeDeploy の Blue/Green デプロイ
GitHub - awslabs/ecs-refarch-continuous-deployment: ECS Reference Architecture for creating a flexible and scalable deployment pipeline to Amazon ECS using AWS CodePipeline
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
CodePipeline で承認プロセスを設けて本番環境へリリースする #reinvent | DevelopersIO
おはようございます、藤本です。 先日、AWS re:Invent 2016 でリリースされた CodeBuild を CodeCommit、CodeDeploy、CodeCommit と組み合わせて、デリバリプロセスの自動化を試してみました。 CodePipeline で CodeCommit/CodeBuild/CodeDeploy を繋げてデリバリプロセスを自動化してみた #reinvent こちらは master ブランチにプッシュしたら、テスト、ビルドを通して、インスタンスにアプリケーションをデプロイします。リポジトリへプッシュするだけでデプロイまで全て自動化されていて、デプロイが簡単ですね。ただし、テストが全て自動で網羅されていることが前提となっています。 ユニットテスト、単一アプリケーション内のインテグレーションテストであれば、ある程度できるかもしれませんが、ペネトレーションテ
[小ネタ] CodeBuild の最新ビルド結果を GitHub リポジトリに表示する（CodeBuild のバッジアイコン） | DevelopersIO
ども、藤本です。 今回紹介するのはタイトルから少し分かりづらいかもしれませんが、よく GitHub リポジトリの README.md に貼られているバッジの CodeBuild 版です。↓の画像のようなやつ。↓のバッジは左から Travis CI、Codecov、Read the Docs のバッジです。 このバッジ機能のリリース自体は 2017/11/22にリリースにされています。 概要 CodeBuild は CodeCommit、S3、GitHub、BitBucket にあるソースコードをコンパイルしたり、スタイルチェックしたり、ユニットテストしたりできるビルドサービスです。CodeBuild のビルド結果はマネジメントコンソール（WEB GUI）やSDK、CLIなど様々な方法で確認することができます。ただビルドのステータスを見るには AWS にログインできる必要があります。READ
![[小ネタ] CodeBuild の最新ビルド結果を GitHub リポジトリに表示する（CodeBuild のバッジアイコン） | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/973d1f1133f801c1bef12a58dfd68c9574de9c5f/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2017%2F01%2Feyecatch-codebuild.png)
CodePipelineからAWS Lambdaを呼び出してCloudFrontのキャッシュを削除(Invalidation)してみた | DevelopersIO
CodePipelineからAWS Lambdaを呼び出してCloudFrontのキャッシュを削除(Invalidation)してみた CodePipelineからAWS Lambdaを呼び出してCloudFrontのキャッシュ削除(Invalidation)を行うLambda Functionを作ってみました。AWS Lambdaを呼び出すときどういう感じで作ればいいか？というのが本エントリの主旨です。 こんにちは、佐伯です。 CodePipelineからAWS Lambdaを呼び出してCloudFrontのキャッシュ削除(Invalidation)、キャッシュ削除のステータス確認、SNSへ通知までを行うLambda Functionを作ってみました。 CodePipelineからAWS Lambdaを呼び出すときどういう感じで作ればいいか？というのが本エントリの主旨です。 やってみた
Amazon ECR をソースとしてコンテナイメージの継続的デリバリパイプラインを構築する | Amazon Web Services ブログ
Amazon Web Services ブログ Amazon ECR をソースとしてコンテナイメージの継続的デリバリパイプラインを構築する 2018 年 11 月 27 日（米国時間）、Amazon Elastic Container Registry (Amazon ECR) を AWS CodePipline のソースプロバイダとして利用可能になりました。これにより Amazon ECR に新しいイメージをアップロードすることにより、AWS CodePipelineを起動することができるようになります。AWS Developer Tools による CI/CD 実現が一段と容易になりました。 Amazon ECR をソースとして使うには、AWS CodePipline コンソールでAWS CodeDeploy による Blue/Green デプロイメントを実装している必要があります。C
AWS CodePipeline Code三兄弟のなかで最後にご紹介するのはAWS CodePipelineです。似た名称のAWSのサービスにAWS DataPipelineがありますがそれとは全く異なるサービスになっています。 AWS CodePipelineはアプリケーションの継続的デリバリーと継続的インテグレーションを実現するためのツールです。継続的デリバリーはソフトウェアのリリースプロセスを自動化することでリリースの負荷を減らし、素早くリリースを実施していく仕組みのことです。 Amazon.co.jp： 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 AWS CodeDeployはアプリケーションのデプロイプロセスを自動化するためのツールとしてご紹介しましたが、AWS CodePipelineはビルド、テスト、デプロイなどのアプリのリ
CodePipeline, CodeBuildを使ってAmazon ECSへの継続的デプロイメントを試してみた | DevelopersIO
モバイルアプリサービス部の五十嵐です。 Amazon Web Services ブログのエントリー「AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント」 で紹介されているリファレンスアーキテクチャを実際に手組で構築してみたりサンプルで動きを確認してみましたので、ブログの補足的な位置づけとして、より詳細な動きを解説してみます。 前提知識 ECS/ECR、CodeBuild、CodePipeline、CloudFormation などのサービスの基礎知識が必要となります。 アーキテクチャ 紹介されているリファレンスアーキテクチャを以下に示します。 引用: Amazon Web Services ブログ 開発者がGitRepositoryにソースコードをPushします
エンジニアリングブログのCI環境をCodePipeline・CodeBuildに移行しました。 — みんなのウェディングエンジニアリングブログ
はじめまして、みんなのウェディング 横山です。 ご覧いただいてる通り、みんなのウェディングではエンジニアリングブログを運営しています。今回、エンジニアリングブログのCI環境をCodePipeline＆CodeBuildへ移行したので概要をお伝えします。 エンジニアリングブログは何を使って構築されているのか。 middleman という静的サイト構築用のフレームワークを利用しています。 middlemanでは記事の追加・修正後、HTMLファイルを再生成するためにビルド作業を行う必要があります。 みんなのウェディングのエンジニアリングブログでは、記事の追加・修正はマスターブランチへ変更をマージすることで行っています。こうすることで、マスターへのマージをトリガーにビルド作業および生成されたHTMLファイルのデプロイを自動で行うことができます。 ビルド&デプロイ自動化の仕組み これまでは、Circ
AWS 開発者用ツールのまとめ – CodeCommit、CodePipeline、CodeDeploy に追加した最近の機能強化 | Amazon Web Services
Amazon Web Services ブログ AWS 開発者用ツールのまとめ – CodeCommit、CodePipeline、CodeDeploy に追加した最近の機能強化 AWS 開発者用ツールは現代の DevOps を実施する上で役立ちます。概要については次をご覧ください (詳しくは「ソースコード管理やデプロイに使用できる新しい AWS ツール」を参照)。 AWS CodeCommit は完全マネージド型のソースコード管理サービスです。既存の Git ツールやワークフローを引き続き使用しながら、安全でスケーラビリティに優れたプライベート Git リポジトリをホストするために同サービスを使用できます (詳細は「Introduction to AWS CodeCommit」のビデオをご覧ください)。 AWS CodeDeploy は Amazon Elastic Compute Cl
渡辺です。 開発者に待望のアップデートです。 CodeCommitが東京リージョンで利用できるようになりました。 早速リポジトリを作成してみます。 リージョンがap-northeast-1（東京）になっていますね。 CodePipelineからCodeCommitのリポジトリを参照してみましょう。 バッチリです。 これで開発系サービスのCodeDeploy, CodeBuild, CodePipeline, CodeCommitが東京リージョンで利用できることになります。 これまでは東京リージョンでCodeDeployを利用する時にS3を利用せざるを得ませんでしたが、今後はCodeCommitを利用することでスムーズな連携が可能になるでしょう。 残るはCodeStarのみです。 CodeStarは各開発系サービスを連携するサービスですから、遠くない時期には対応されるのではないでしょうか？
![[アップデート] AWS CodeCommit が東京リージョン対応 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/13935a4e593b03d16999ca4cb4f253480dea8a3f/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F07%2Fcodecommit.png)
AWS CodeBuildとGitHubをWebhook連携した場合において、よく使うと思われるトリガー設定をいくつか試しました。公式以外の情報が少ないように感じたため、本記事で共有します。 本記事で紹介する設定方法については、主に下記のブログを参考にさせて頂きました。 AWS CodeBuildでGitHub Webhookイベントをフィルタリングする - あとらすの備忘録 設定箇所 CodeBuildプロジェクト作成済 CodeBuildとGitHub連携済 という前提で進めていきます。 CodeBuildプロジェクトを開いて、「編集」から「ソース」を選択します。 「プライマリソースのウェブフックイベント」の「ウェブフックイベントフィルタグループ 1」を確認します。 こちらの 「イベントタイプ」 「これらの条件でビルドを開始する」の「HEAD_REF - オプショナル」 の値がキーにな
AsciiDocの文書をCodePipeline/CodeBuildでHTMLに変換してみた | DevelopersIO
こんにちは、かたいなかです。 今回はGitHubにpushしたAsciiDocの文書をCodePipeline/CodeBuildでをHTMLに自動で変換する方法をご紹介します。 AsciiDocとは AsciiDocはドキュメントや記事、スライドショーなどを記述するためのテキストドキュメントのフォーマットです。AsciiDocのファイルはHTMLやPDF、EPUBなど様々な形式へ変換することができます。 Markdownよりも表現力が高いのも特徴で快適にドキュメントを作成することができます。 また、AsciiDocではPlantUMLなどを文書内に埋め込むことができ、UMLを多用した視覚的にわかりやすいドキュメントを容易に作成できます。 なぜHTMLに変換するのか GitHub上ではそのままでもAsciiDocの形式のファイルをある程度きちんと表示してくれます。しかし、PlantUMLで
いろいろとツッコミどころはあるばってん、Backlog Git と AWS CodePipeline の連携について考察してみたくさ - ようへいの日々精進XP
CodePipeline よ Github や CodeCommit と連携出来るのはわかった ということで ざっくり構成 Backlog Git の Webhook は… Lambda ファンクションは… API Gateway と Lambda ファンクションのセットアップは… CodePipeline と S3 バケットの連携は… Codebuild では Ruby のテストを走らせてみる まとめ 課題 Serverless Framework CodePipeline よ Github や CodeCommit と連携出来るのはわかった では、Backlog Git と連携はどげんすればよかとかね。 その答えにヒントを与えてくれたのは以下の記事。 Integrating Git with AWS CodePipeline | AWS DevOps Blog なるほど…とにかく、何ら
AWSエンジニアだから、今風のナウい感じでAnsibleもサーバーレスで使いたいよねっ？！ - サーバーワークスエンジニアブログ
全国のAnsible愛好家の皆様こんにちは、技術4課 岩本です。 さて、ラノベ風のタイトルで始まりました今回ですが、 Windowsユーザー/Macユーザーが混在してたりすると、セットアップ手順が各端末であったり、 もしくはプロビジョニング用サーバーを用意したりと、それなりに手間がかかるので、 Ansibleの実行もサーバーレスでできないかしら？と思ったのが事の始まりです。 結論 git push するだけで、Ansibleの実行ができるようになりました！ 手元の端末にAnsibleのインストールは不要で、テキストエディタとGitクライアントだけで、Ansibleの実行ができます。 Gitに対応したVisualStudioCodeとかAtomなら、それ以外不要。 しくみ CodeCommit上にあるGitリポジトリに、AnsiblePlaybookとCodeBuildで利用するbuilds
AWS Code シリーズを使って git push と連動して静的コンテンツを自動リリースする環境の作り方 - log4ketancho
この記事は、 OpsJAWS Advent Calendar 2017 - Qiita の1日目分として書かせていただきます。（既に12/9ですが、空いていたので埋めさせていただきました！） S3の静的ホスティング機能が便利でたまりません。フロントはS3、バックエンドは API GW + Lambda + DynamoDB で、安い・はやい・うまい三拍子揃ったWebサービスを提供していきたいです。 ただし、この「安い」とか「はやい」ですが、一番ネックになるのは人手がかかる部分だと思っています。コア機能を開発するのに時間をかけるのはいいとして、それ以外の部分の無駄を極力減らしていくことが重要だと思います。AWSには運用を支援するサービスがたくさんありますので、少しずつ使い方をまとめていきたいと思います。まずは入門編ということで、下記の流れを自動化します。 S3上で静的コンテンツをWebホステ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンテナデプロイ基盤の検証 - Hatena Developer Blog
あなたの組織に最適なECSデプロイ手法の考察 | DevelopersIO
CodePipelineを用いたLambdaのデプロイについての所感 - JX通信社エンジニアブログ
金融サービス向けに理想のCI/CDを追い求めたお話
CodePipeline を使った Gitブランチ運用をまとめてみた | DevelopersIO
BacklogのGitにCI/CDを導入する方法（AWS CodePipeline & TypeScript編）
CodePipelineからECSにBlue/Greenデプロイする | DevelopersIO
AWS CodePipelineことはじめ – 概要紹介 | DevelopersIO
CodePipelineとGitHubを連携する方法を追求したら Github Actionsでやるべきという結論に至った話
[アップデート] AWS CodeCommit が東京リージョン対応 | DevelopersIO
AWS CodeBuildとGitHub連携した場合のビルドのトリガー設定 | DevelopersIO