ecspresso v2とTerraform null_resourceで一発構築 - KAYAC engineers' blog
SREチームの藤原です。 この記事はTech KAYAC Advent Calendar 2022 5日目の記事です。 この記事では筆者が開発しているAmazon ECSデプロイツール ecspresso (v2)と、Terraformのnull_resourceを組み合わせて、 TerraformによるECS関連リソース作成とecspressoによるECSサービスのデプロイを一発で実行する手法について説明します。 ecspresso とは github.com ecspressoは筆者(fujiwara)が開発している、Amazon ECS用のデプロイツール(OSS)です。ECSにタスク定義とサービスをデプロイするツールはAWSが作っているものを含めて世の中に多々ありますが、ecspressoは次のような特徴を持っています。 Go 言語で書かれた OSS (MIT LICENSE) です
ecspresso v1 をリリースします(v0.99.x をリリースしているのでお試しください) - 酒日記 はてな支店
おかげさまで各所でご利用頂いている(模様の) Amazon ECS デプロイツール ecspresso ですが、リリースしてからもうすぐ3年になりますし、ここで一部非互換の修正を入れた v1 を出そうとしています。 非互換な点は少ないのでほとんどの方にはそのまま使って頂けると思いますが、下記を確認した上で v0.99.x を試して頂いて、もし何か問題があればフィードバックを頂けると幸いです。 (2020-10-30 追記) v1.0.0 をリリース済です。 github.com (2020-09-25 23:00 追記) Homebrew で 0.99.x がインストールできるようになりました。 tap ecspresso@0.99 by mashiike · Pull Request #9 · kayac/homebrew-tap · GitHub $ brew install kaya
Next.jsアプリケーションを動かす環境をaws-cdkを使って構築する(with CloudFront/S3/Fargate) - $shibayu36->blog;
Next.jsをproduction環境で使うために外観を掴んでおきたいと思い、Next.jsアプリケーションを動かすAWS環境をaws-cdkを使って構築するサンプルを作ってみた。だいぶ荒削りだけど、参考になる例にはなったと思う。 https://github.com/shibayu36/nextjs-on-ecs 利用した技術 AWS CloudFront S3 ECR ECS aws-cdk Docker Next.js + TypeScript 今回作ったアーキテクチャ 全てのリクエストをCloudFrontに通すフルCDNアーキテクチャ フルCDNアーキテクチャ実験 / Minami Aoyama Night #1 - Speaker Deck フルCDNアーキテクチャでサービス設計した話 - Speaker Deck next buildで生成した静的ファイルはS3から配信
ecspresso で設定ファイル生成と CodeDeploy による Blue/Green デプロイに対応した - 酒日記 はてな支店
ecspresso は筆者が開発している Amazon ECS 用のデプロイツールです。 github.com 最近 AWS DevDay Tokyo 2019 の「第1回 AWS Fargate かんたんデプロイ選手権」でも紹介していただいて、気をよくして最近あれこれ機能追加をしていたのでそのご紹介です。 speakerdeck.com 分かりやすい導入記事をクラスメソッドさんの blog で書いていただきましたのでこちらもどうぞ。 dev.classmethod.jp 設定ファイル生成機能 ecspresso init で、既存の ECS サービスの情報を引っこ抜いて定義ファイルを生成し、そのまま ecspresso deploy できるようになりました。(v0.11) README の Quick Start にもあるように、region, cluster, service, con
Introducing the ‘aws-rails-provisioner’ gem developer preview | Amazon Web Services
AWS Developer Tools Blog Introducing the ‘aws-rails-provisioner’ gem developer preview AWS is happy to announce that the aws-rails-provisioner gem for Ruby is now in developer preview and available for you to try! What is aws-rails-provisioner? The new aws-rails-provisioner gem is a tool that helps you define and deploy your containerized Ruby on Rails applications on AWS. It currently only suppor
LambdaのCDをCodePipelineとCloudFormationで構築してみる | DevelopersIO
おはようございます、もきゅりんです。 タイトル通りですが、CodePipelineを利用したLambdaのCD(Continuous Deployment)をCloudFormation(以下CFn)で構築してみたのでまとめました。 Lambdaを手元でわちゃわちゃやった後に、デプロイしたいときはリポジトリにプッシュすればよろしおす、便利よね、ということでCFnにしてみました。 色々なやり方があるとは思いますが、元ネタはこちらです。 AWS CodePipeline を使用して Lambda アプリケーションの継続的な配信パイプラインを構築する この例では、CodeCommitのGitリポジトリを利用します。 前提条件 CodeCommitが利用できる状態であること AWS CLIインストール＆設定済み CodeCommitリポジトリの作成については、『CodeCommit ユーザーガイド
CloudFormationとAWS CLIで作るCodeDeploy（Blue/Green）環境 | DevelopersIO
上記、パラメーターに指定する値を環境変数にセットします。 PROJECT_NAME=test-yotsugi EC2_KEY_PAIR=test-yotsugi-key SNS_SUBSCRIPTION=xxxxxx@xxxxxxxx.jp セットした内容を確認します。 cat << ETX EC2_KEY_PAIR : ${EC2_KEY_PAIR} PROJECT_NAME : ${PROJECT_NAME} SNS_SUBSCRIPTION : ${SNS_SUBSCRIPTION} ETX スタックを作成します。必要な値は、環境変数にセットされているので、以下のコマンドのまま実行できます。 aws cloudformation create-stack \ --stack-name ${STACK_NAME} \ --template-body file://${TEMPLATE_
Debugging what you deploy in Go 1.12 - The Go Programming Language
David Chase 21 March 2019 Introduction Go 1.11 and Go 1.12 make significant progress toward allowing developers to debug the same optimized binaries that they deploy to production. As the Go compiler has become increasingly aggressive in producing faster binaries, we’ve lost ground in debuggability. In Go 1.10, users needed to disable optimizations entirely in order to have a good debugging experi
最速でGoのAPIサーバを公開する方法 - Qiita
はじめに Web系の開発やってるとサクッとWebAPIサーバ建てたい・・・！けどめんどくさいことは抜きにしたい！というときありますよね？ コールバック先を指定したいけどいい感じの公開サーバがないときとか・・・ どっかのサーバからリクエスト流してもらって中身確認したい時とか・・・ シンプルに開発中のサーバを一回公開したいとか・・・ この投稿ではサクッとコマンド１発でWebAPIサーバが起動する、丸投げ系テンプレートを紹介します。 動作環境 MacBookPro2016 Mojave go version go1.10.3 darwin/amd64 Python 3.6.5 事前に AWSのアカウントを作成する。 EBコマンドを事前にインストールする。 リポジトリ テンプレート置き場 https://github.com/muff1225/goserver-saisoku プロジェクトの構成
Nuxt.jsで作った静的サイトのビルド/テスト/デプロイを自動化して、毎朝10時に更新する。
AWSとCircleCIの力を借りて、Nuxt.jsで作った静的サイトの運用をできるかぎり自動化した話です。 3ヶ月ほど前からCIのサービスを使うようになり、入門記事はたくさんあって助かったのですが、具体的にどんな感じで使っているかの情報が少なかったので記事にしました。 もしかしたら、CIの使い方が間違っているかもしれないので、そのときは優しくコメントをいただけたら嬉しいです。 できあがった流れ 毎朝10時にLambdaを起こしてデータの更新を行い、静的ファイルを再生成してからデプロイする流れになっています。 対象のサイト ざっくりAWSという、AWSの料金を日本円でざっくり計算できるサイトです。 Nuxt.jsで作成したものを、静的サイトとして生成して、AWSのS3にホスティングしています。 計算に必要なAWSの価格や為替は、毎朝10時に取得したものをS3にJSONで保存し、そのJSON
AWS Fargateのデプロイパイプライン(Gitlab > S3 > CodePipeline)を構築してみた - エムスリーテックブログ
こんにちは、エムスリーエンジニアの園田です。 この記事はAWS FargateでElixirのコンテンツ配信システムを動かしてみた (実装編) - エムスリーテックブログの続きです。 エムスリーでは医療・ヘルスケアサイト向けのコンテンツ配信システムであるChuoiというサービスを運用しています。先日のポストで、ElasticBeanstalkからFargateに運用を切り替えたことについて書きました。 www.m3tech.blog 今回は前回に引き続きその実装編で、CodePipeline を利用したデプロイパイプラインの構築について書きます。 まずは構成のおさらいです。 デプロイ周りは以下のような構成です。 社内 Gitlab からの CI/CD パイプライン構築 先日の記事で述べたとおり、弊社ではソース管理にオンプレの Gitlab を使っており、 CodeBuild や CodeP
[ChatOps]Opsidianとdroneを使って、SlackからAWSへデプロイしてみた - Qiita
はじめに 先日【drone.ioを使ってCI環境を構築したので、色々整理してみた___<基本編>】を書きました。タイトルは揃っていませんが、今回はそれの続編で、Slackからデプロイコマンドを打って、droneがおとなしく指示通りにやってくれる方法について書きます、。 SlackでのChatOps (AWS寄りになってしまいますが)Slackを使って、ChatOpsをする時に、下記API Gatewayを使うパータンがよくあるのではないかと思います。もちろん、SlackからHubotを呼ぶのもあります。 ちなみに、Slack → API Gateway → Lambdaにご興味がある方は、下記、昨年私が書いた記事を見て頂ければと思います。 【Slack de AWS CLI】SlackのChannelからAWS CLIを実行できるようにしてみました! 元々、自分もAPI Gatewayを使
![[ChatOps]Opsidianとdroneを使って、SlackからAWSへデプロイしてみた - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/6a124639ab2e0266d49c393fb9c42cb957f7b90e/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCQ2hhdE9wcyU1RE9wc2lkaWFuJUUzJTgxJUE4ZHJvbmUlRTMlODIlOTIlRTQlQkQlQkYlRTMlODElQTMlRTMlODElQTYlRTMlODAlODFTbGFjayVFMyU4MSU4QiVFMyU4MiU4OUFXUyVFMyU4MSVCOCVFMyU4MyU4NyVFMyU4MyU5NyVFMyU4MyVBRCVFMyU4MiVBNCVFMyU4MSU5NyVFMyU4MSVBNiVFMyU4MSVCRiVFMyU4MSU5RiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YjI1NmE2NWQ5MDIzZDVhNTFhYWY1NzliNzI5OGI4NDc%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwam9iYmluJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz01NDg2N2VkMzc0NzY5YzFlN2U0NzM4Yjg0MGM4N2M2OQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Df120ab236c7d32faf009c871d3964e93)
golangで書いたツールをCircleCI上でビルドしてその成果物をGitHub Releasesにリリースする - その手の平は尻もつかめるさ
表題の通り．いくらかポイントがあったのでメモとして記す． 基本的にこの記事の内容を真似した． medium.com あらかじめ，CircleCIの側の設定でGITHUB_TOKENという環境変数を登録しておく．なおGitHubのPersonal access tokenにはrepoのpermissionを付与しておく． とは言えこれでは動かない．理由はghr (ghrについてはこちら: 高速に自作パッケージをGithubにリリースするghrというツールをつくった | SOTA) がcontextに依存しているからで，contextはgo 1.7以降でないと利用できない．しかしながらCircleCIのgolang環境は1.6系が使える内の最新なので *1 このままではghrをgo getすることが出来ない． というわけでCircleCI上でgo 1.7を使うようにしましょう，ということでそう
一からマイクロサービスの開発フローを作った話 - Qiita
※ 2016年の記事なので、すでに古い情報が多いです。 今の会社で、全社の外部サービスで利用できるAPIを作ってね、という話があったので、環境構築からコーディング、運用まで一人で行っている。 基本はAWSのサービスを利用し、ログの保存だけGCPのBig Queryを利用した。 ※ 2017/10/13 追記 このときの経験を踏まえて、コンテナでの環境構築を行ったので記録した。 → 一からAPIサーバの開発フローを作った話〜コンテナ編 関連記事 マイクロサービスで調査しやすいログをつくる マイクロサービスのテスト作成方針 マイクロサービス作成時におこなった負荷対策 deployフローに関しての振り返り ウェブサービス構築時に導入する、開発が3倍速くなる仕組み 簡単な要件 ゲームなど自社で利用するユーザアカウント情報を1つにする 現在のアカウントで引き続きサービスは利用できる アカウント以外に
【翻訳】プロダクション環境でのベストプラクティス - Qiita
Qiitaは2ヶ月ぶりです。 GopherCon2014でSoundCloudの方がプロダクションでGoをどう使うかというところで発表されていたようです。その内容がブログで公開されていたので、僕の勉強も兼ねて翻訳することにしました。 英語は得意でないのですが、ザクッと訳してみました。きっと間違い有るので、どうかご指摘ください。 元ネタ：http://peter.bourgon.org/go-in-production/ スライド：https://github.com/gophercon/2014-talks/blob/master/best-practices-for-production-environments.pdf SoundCloudでは、たくさんのクライアントに対してAPIの形でプロダクトを提供するようにしています。ですから、ウェブサイトやモバイルクライアント、モバイルアプリの
大人のスタートアップは大人のリリースができる。そう、ChatOpsならね。 | メルカリエンジニアリング
このブログをご覧のみなさま初めまして。@siroken3です。メルカリではインフラチームに所属しており、リリースの仕組み構築を担当しています。 メルカリのリリースについて メルカリではカスタマーサポートから受け取る改善要望、プロダクトとしてまだやれてないことなど多くのタスクがあり現在も継続して開発とリリースが行われています。 Issue管理はRedmine、ソースコードのリポジトリはGitHub privateを使用しています。Pull Request(以下PR)でのコードレビューを実施、masterブランチへマージされたものをリリースするのが基本的なフローです。 一方、1年前まではリリース頻度は週1回のリリース日を決めて実施していましたが、この1年で大きく変わりました。現在では日本版とUS版を合わせて10回〜30回/日の頻度でリリースしています。この記事では大きく変わったメルカリのリリー
capistrano3のデプロイを把握する - Qiita
結局Node.jsアプリケーションのデプロイはどうすればいいの？ で 色々node.jsアプリのデプロイを考えたのですが、 やっぱりcapistranoが結構使いやすい気がしてきました。 デプロイ対象でリポジトリから直接ソースコードを落とせるならば デプロイ専用のリポジトリを作成して、それをCIで実行するようにすればいいわけです。 capistrano3では、基本的なデプロイタスクがあり、 それに独自のタスクを追加することで、様々な状況に対応しています。 どのようなタスクが実行されているかを把握できれば、柔軟にデプロイ設定が出来ます。 capistrano3をまず使ってみる --dry-run で動くこと確認 $ gem install capistrano $ cap install mkdir -p config/deploy create config/deploy.rb creat
結局Node.jsアプリケーションのデプロイはどうすればいいの？ - Qiita
node.js アプリケーションのデプロイをする時の選択肢が あまりにもありすぎて、結局どうすればいいのよ？ってなったので、 いったん基礎からまとめてみます。 デプロイとは何か？ アプリケーションのデプロイは大きく2つのフェーズに分かれます。 ファイルを所定の場所に置く 置かれたファイルの再ローディング 文章にするならば『ファイルを各サーバーの所定の場所におき、それらのファイルを再度ロードをする。』になると思います。 Webアプリケーションの場合 ファイルを所定の場所に置く前にテストを走らせたり 置いた後に静的ファイルを生成したりと、この２つの前後にはもっと色々なフェーズがありますが、 デプロイのタスクは、大きく分けてこの２つになります。 ファイルを所定の場所に置く サーバーにファイルを置く作業は、以下のような方法があります。 FTP tar などで圧縮scpで転送して解凍 rsync g
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Capistrano3でGithubにあるコードをデプロイ - Qiita