Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on. →
ふだんの開発では,稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている.どんな事を考えてやっているか記しておきます. フィーチャートグルを使う すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で,フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり,フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で,実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに,ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の
関連記事 マイクロサービスを支えるインフラアーキテクチャ (AWS Dev Day 2019登壇資料) ECSデプロイツールを公開しました ECSにおけるログの取り扱いを別ページに移動させました 設計 基本方針 基盤を設計する上で次のキーワードを意識した。 Immutable infrastructure 一度構築したサーバは設定の変更を行わない Infrastructure as Code インフラの構成をコードで管理 (Terraformを採用) Serverless architecture 無駄にサーバを増やさない アプリケーションレイヤに関して言えば、Twelve Factor Appが参考になる。コンテナ技術とも親和性が高い。 ECSとBeanstalk Multi-container Dockerの違い 以前に記事を書いたので、詳しくは下記参照。 Dockerコンテナデプロイ
鉄道では個人の注意力だけでなくシステムにより安全を確保している。 写真は「タブレット閉塞式」のタブレットを交換する様子。1つの区間にはタブレットを持った列車しか進入できないため、衝突事故を防ぐことができる。(作者 Spbear [CC BY-SA 3.0 ], ウィキメディア・コモンズより) こんにちは、エムスリーでソフトウェアエンジニアとして働いている小本です。 私は基盤開発チームという、エムスリーの複数のサービスにまたがって使われるシステムを開発・運用するチームに所属しています。 基盤開発チームが担当するシステムの1つに、会員向けメルマガの配信システム「メールコンシェルジュ」があります1。 エムスリーはメールコンシェルジュで1日数十万通のメルマガを配信しており、機械学習でメルマガを最適化する施策2などもメールコンシェルジュの存在が前提になっています。 このようにエムスリーにとって重要な
By Andy Glover and Katharina Probst Over the past four years, Netflix has gone from less than 50 Million subscribers to 125 Million subscribers. While this kind of growth has caused us no shortage of scaling challenges, we actually managed to improve the overall availability of our service in that time frame. Along the way, we have learned a lot and now have a much better understanding of what it
OSS紹介 Advent Calendar 2017 - Qiita 18日目の記事です。(一週間遅れ) Amazon ECS へのデプロイツール ecspresso と、そこで使っている環境変数を展開しつつ複数の YAML/JSON/TOML を読み込む config loader である go-config の紹介をします。 ecspresso github.com 「エスプレッソ」と読みます。Go で書かれた Amazon ECS 用のデプロイツールです。以下の3つのファイルを用いて ECS へのサービス、タスク定義作成、入れ換えを行います。 YAML の設定ファイル タスク定義のための JSON (aws ecs describe-task-definition 出力と互換) サービス定義のための JSON (オプション。aws ecs describe-services 出力の
SREの@deeeetです。 新しい機能を素早くリリースしフィードバックを得てすぐにPivotの決定を行う、もしくはリスクを抑え小さな改善を継続的に行うContinuous Deliveryはソフトウェア開発において非常に重要です。 メルカリではこのContinuous DeliveryのためのPlatformにSpinnakerを採用し始めました。現在は主にkubernetes(k8s)へのコンテナアプリケーションのDeployに利用しており、既にいくつかの本番アプリケーションがSpinnakerによりDeployされています。 本記事ではなぜSpinnakerを採用したか、Spinnakerとは何か、実際にメルカリでどのようにSpinnakerを使っているか、について簡単な紹介をします。 kubernetes上でのDeploy問題 k8sへのコンテナイメージのDeployは非常に簡単で
エンジニアアルバイトの妹尾です。 今回はタイトルの通り、Circle CI + AWS + Dockerの組み合わせで簡単にサービスのデプロイを自動化した話をします。 弊社サービスWorkinGoodではGItHub flowを採用しており、masterへマージした後に自動的にElastic Beanstalkへ新しいバージョンを作るところまで行っています。依存サービスとの関係もありデプロイするタイミングはこちらが手動でAWSのGUI上から行っています。 また、弊社では開発環境構築にDockerを使っていますが、本番環境へのデプロイにも使用しています。 このブログ初投稿となります、MatchinGoodでエンジニアアルバイトをしている妹尾です。 弊社では人材紹介会社様と人材派遣会社様向けのシステムの開発をしており、今年初めごろに派遣会社スタッフ様向けの新サービスである WorkinGood
今年、稼働中のサービスであるはてなブログのデプロイ方法を新しい方式へ無事故で移行し、従来と比べて約6倍速くデプロイできるようになりました。 この記事では、安全にデプロイ方式を変えたプロセスを順を追って紹介します。 はてなブログと継続的デリバリー デプロイが遅い 複雑なデプロイ設定 デプロイのテストを書く ボトルネックの発見、そして pull 型から push 型のデプロイへ 新デプロイへの移行 結果 まとめ はてなブログと継続的デリバリー はてなブログは1日あたり平均して1.02回デプロイを行っています。これは土日を除いた週5日の営業日に対する平均です。ざっくりとした算出で、祝日は考慮していません。5月と9月の祝日を含めるともう少し多くなるかもしれません。 また、原則として休日の前日にはデプロイしないことになっています。もしもデプロイした変更にバグがあった場合、休日が明けてから対応するか、
TL;DR AWS Application Load Balancer(以下ALB) + Amazon ECS でDockerのホットデプロイ環境を構築した ALBのTarget GroupとECSのServiceを紐付けることで、ALB配下のコンテナの入れ替えが自動で行われるようになる ALBは先日リリースされたばかりで、私もまだ色々と検証している段階なので、内容や認識等に誤りがあるかもしれないのでご容赦下さい。(詳しい人教えてください!!) その他弊社の前提情報 GitHub + CircleCIが連携済み Docker RepoにはAmazon EC2 Container Registry(以下ECR)を利用 DeployはGitHubのデプロイブランチへのマージを契機にCircleCI経由で、Docker Pushとecs-deployでDockerデプロイを実施 準備 ALBとE
Large-scaled Deploy Over 100 Servers in 3 MinutesAI-enhanced description Large-scaled Deploy Over 100 Servers in 3 Minutes Deployment strategy for next generation involves creating OS images using Packer and cloud-init that allow deploying over 100 servers within 3 minutes through automation. The strategy uses Puppet for configuration management and builds minimal and application-specific images t
“SRE”がテーマで2016/03/12に開催されたRetty Tech Cafe #5 で「メルカリにおける、継続的なアプリケーション改善を支える技術」という発表をしてきました。 私の発表資料はspeckerdeckにて公開しました。 デプロイや監視まわりでメルカリのSREがやっていることをまとめてみました。参考になれば幸いです。 元GoogleのSREであるRettyのCTO、樽石さんの発表では、SREが目標とする指標について簡潔にまとめられていて、とても参考になりました。自動化やクラウドが提供するサービスが中心となりやすいインフラとはちょっと違う切り口で、アプリケーションのパフォーマンスやサービスの信頼性を確保する方法、その考え方について短い時間でしたが情報交換できました。ありがとうございましたー。 SREの活動についてもっと喋れる場があるといいなー。
SA岩永です。クラウド時代になり、Blue/Greenデプロイと呼ばれる方式を取るシステムが増えてきました。ただ、日本語で書かれているBlue/Greenデプロイの情報は多少古いものが多いため、特にクラウドで真価を発揮するBlue/Greenデプロイについて2015年の最後に一度まとめてみたいと思います。 以下は私の個人的な考えに基づくものであり、他にも様々な考え方があります。AWSのデプロイに関する発表でも沢山の考え方が提案されていますし、デプロイをサポートするサービスを多種多様に提供しています。1つの考え方として参考にして頂ければ幸いです。 なおこの記事は、2015年のAWS re:Inventのセッション『(DVO401) Deep Dive into Blue/Green Deployments on AWS』を参考にしています。興味のある方はSlideshareやYoutubeを
Fabric は、Python 製のデプロイ・システム管理ツールです。 最近、構築や運用を自動化するための様々なツールが出てきています。 構成管理ツールの Puppet や Chef が有名ですが、使うまでに覚えることが多いのが欠点です。 しかし、Fabric は非常にシンプルなツールで、今からすぐに使うことができます。 Fabric はデプロイ・システム管理ツールで、類似のツールとして Ruby 製の Capistrano があります。 Fabric の最大の特長は、シェルスクリプトを書き慣れた人がいきなり利用できるところです。 シェルスクリプトとしてまとめていたコマンドをそのまま run() メソッドや sudo() メソッドで囲むだけで、使うことができます。 シェルスクリプトを使っていていると、いくつもの問題に遭遇します。 名前空間の管理 変数の扱い 複雑なデータ構造がない(せいぜい
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで,10以上のプロジェクト,コードベースを抱える場合にどのようにデプロイの自動化を進めたか,工夫したこと,考慮したことなどをまとめておく. デプロイツールには,Python製のfabricを採用しているが,他のツールでも同様のことはできそう.なお,fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない(最後の参考の項を見てください). fabricの選択 シェルスクリプトとCapistranoを考慮した. まず,シェルスクリプトは人によって書き方が違うため,統一が難しくメンテナンスコストも高い.また共通化も難しい. 次に,Capistranoは,裏でやってくれることが多く,学習コストも高い.プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため,Capistranoの前提から外れる
その上で、新しく作り上げた deploy フローについて、雑な絵になりますが概略図を以下に示します。 主要な登場人物は Itamae Auto Scaling CodeDeploy GitHub / Circle CI となります。それぞれ追って説明をしていきます。 https://github.com/itamae-kitchen/itamae Itamae は @ryot_a_rai さんが作られた LightWeight な Chef like な OSS です。Chef で実現できた事のうち、 recipes の部分のみを切り出したようなシンプルなツールになっています。 (こちらの発表資料より引用) 弊社内で蓄積された Chef 関連のリソースを再利用・再整理するために粒度がちょうど良かったこともあり、Itamae を用いて provisioning の定義を書き直すことにしました
技術部の鈴木 (id:eagletmt) です。 クックパッドでは一部の Web アプリケーションサーバで Docker が使われており、今回はそのデプロイ方法について紹介します。 Docker で Web アプリケーションをデプロイするときには、まだまだベストプラクティスがある状況ではありません。 たとえば、どのように無停止でデプロイするか、どのようにコンテナと通信するかといった問題があります。 最初に Apache Mesos と Marathon などのツールを検証しましたが、クックパッドの環境において使いやすそうなものはなく、最終的に自前でデプロイのしくみを作ることにしました。 しかし Docker 周辺のツールは様々な新しいものが出てきている最中です。 今はまだベストなものが無いけれども、近いうちによりよいものが出てくるかもしれません。 そのため、できるだけ単純なしくみにしておく
最近、仕事やら趣味やらで AWS / OpenStack / GCE その他のいわゆるIaaSなプラットフォームを調査したり、いじったり、そのAPIをいじったりする機会が多かった。 この辺の運用を考えていて試したこと、ぶつかったことなどをまとめたい。 実際やったこととしては、特定のプラットフォームに依存している訳ではないが、たいていの人はAWSのアレね、みたいなイメージを持った方が読み進めやすいんじゃないかと思う。 ゴールデンイメージを雑に走らせること この手のIaaSの基本であるが、サーバーはインスタンスと呼ばれ、イメージを指定して起動する。ec2 aws run-instanceとかnova bootとかその類いである。 イメージからの起動のためには雑には大きく2要素があって、一つはイメージ自体の構築、もう一つは起動直後のそれぞれのインスタンスの特性に合わせた初期化処理のフェーズである
Zero downtime PHP deployment Deployments you've only dreamed about. Zero downtime. Zero fuss. Deploy your PHP and Laravel applications with confidence Envoyer has been carefully crafted by the creators of Laravel to work perfectly with your applications. You can deploy at any time of day or night with confidence that your users will never experience downtime.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く