クックパッドにおけるScalable Deploymentsのスライドが興味深い - GeekFactory
クックパッドにおけるアプリのデプロイの資料が非常に興味深いので紹介します．これは @sora_hさんがRubyKaigi 2014で発表 された資料で，100台以上のサーバに短時間でアプリをデプロイする仕組みをどうやって作り上げたのかが説明されています． 以前，スライドの内容を箇条書きにまとめていたのでシェアします．最近では，Jenkins User Coferenceの発表（How We Use Jenkins? // Speaker Deck）でほんの少し引用されていたりします． 内容のまとめ スライドは90枚あります．ざっくりまとめた内容を以下に示します． 概況 140サーバに1日10回のデプロイを実施している（ピーク時） コードベースが大きい モデルだけで約 69K LOC プロダクトコードとテストコードを合わせると約 319K LOC デプロイのルール CIのビルドが成功したリビ
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
Consul + Capistrano でオーケストレーションさせてみた - log.fstn
はじめに Serfに続いてHashiCorpからConsulが発表されて、2ヶ月少々経ちました。 公式では Serf: service discovery and orchestration Consul: service discovery and configuration と言っていますが(http://www.serfdom.io/intro/vs-consul.html)、Consulも使い方によってはオーケストレーションできるかなと思って、試してみました。 ちなみに Serf や Consul の最近の動向については @zembutsu さんの記事がわかりやすいです ご注文は監視自動化ですか？ SerfとConsulの記事まとめ そもそもオーケストレーションとは webサーバをproxyから追加したり抜いたり webサーバにデプロイしたり 障害が発生したサーバを撤去したり db
開発メモ#1 : Cinnamon によるデプロイ - naoyaのはてなダイアリー
このごろ作っているものが幾つかあるのだけど備忘録代わりにこの辺はこうしているということを書いて行こうかなと思います。 まずは Perl によるアプリケーションのデプロイについて。id:antipop と id:shiba_yu36 が開発した "Cinnamon" というミニマムなデプロイツールを利用しています。 Cinnamon - A minimalistic deploy tool https://github.com/kentaro/cinnamon シンプルで使いやすいデプロイツールです。 Capistrano? デプロイツールの定番といえば Capistrano で、最初は Capistrano を使っていました。けど、作っているものはほぼ Perl で書かれているのにデプロイツールだけ Capistrano で Ruby というのが、例えばモジュールの管理に Carton と
ssig33.com - Docker をプロダクトのデプロイに使う
コミケの列に並んでたあたりのころから Docker 本格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。 Docker の利点と欠点で 開発環境の配布が容易にできる プロダクトのデプロイにつかうにはなにかとキツい みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。 Docker をデプロイに使う際の問題点としては以下があります Dockerfile に 42 個しか命令かけないみたいなやつ なんだかんだでコンテナのビルドに時間がかかる コンテナの管理とかどうするのか リバースプロキシの設定とかどうするのか 一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ
今年流行りそうな「インフラエンジニア」向けトレンドのまとめ その1 (Blue-Green DeploymentとImmutable Infrastructure編)
あけましておめでとうございます。バズワード評論家 横田でございます。(恐らく)皆様1月6日から出社ですね。お仕事がんばりましょう。 というわけで今年のインフラ業界のバズワードトレンドをまとめてみました。年始の仕事前にどうぞ 《Blue-Green DeploymentとImmutable Infrastructure》今年のインフラ業界の一番のトレンドは「Blue-Green Deployment」と「Immutable Infrastructure」となる気がしています。今までは、サーバの設定を変更する時は、運用中のサーバを変更していましたが、「Blue-Green Deployment」と「Immutable Infrastructure」の考え方は、運用中のサーバの変更するのではなく、新しくサーバ群を用意し、本番環境をそちらに切り替えるという手法を取っております。 手法自体は「Blu
Ruby on Railsのチームから学ぶ仕事術
Ruby on Rails自体についての解説は、「WebプログラマはRailsに乗るべきか？」や、「Rubyでアジャイルプロトタイピング」にもありますので、そちらもぜひご覧ください。本記事は2006年に執筆されたものです。RubyやRuby on Rails全般の最新情報は＠IT Coding Edgeフォーラムをご参照ください。 素早く開発が行えるRuby on Railsに驚くとともに、Railsのプロジェクトの素早さの根源はどこにあるのか不思議に思った人も多いことでしょう。 Ruby on Railsの開発には、37singals社のDavid Heinemeier Hansson氏を中心とする11名で構成されたチームがかかわっています。 Core team behind Ruby on Rails Ruby on RailsによるWebアプリケーション構築風景を撮影したいくつかのス
入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering
はじめに この記事はGREE Advent Calendar 2013年の21日目です。お楽しみください！ こんにちは、アゴひげがダンディーだと評判の九岡です。GREEでは、JavaやScalaを布教するための土台を固めるため、デプロイや監視の仕組みづくりなどを横断的にやっています。今回はその過程で得られた知識を「Capistrano 3の入門記事」という形で共有させていただきます。 この記事ではCapistrano 3の基礎をご紹介します。Capistrano 3はRubyをベースにしたサーバ操作およびデプロイの自動化ツールです。Capistrano 3を利用することで、デプロイなどの複雑なサーバ操作を自動化することができます。ここの記事では、特にデプロイに焦点をあてながら、Capistranoでサーバ操作を自動化する考え方と実現方法をご説明していきます。 Capistrano 3の習得
まとめてたくさん処理したい！ を解決する「Capistrano」
まとめてたくさん処理したい！ を解決する「Capistrano」：特集 DevOps時代の必須知識 インフラ運用の自動化を実現し、DevOpsを支援するツールはいくつかあります。ここではその中から「Capistrano」というツールについて、サンプルを用意しつつ紹介します。 はじめに インフラ運用の自動化を実現するツールには「Chef」や「Puppet」などいろいろあります。今回の記事ではそういったツールのうち、Capistranoというツールを簡単なサンプルを用意しつつ紹介します。 Capistranoとは Capistranoとは簡単にいうと、オープンソースで提供されている、複数のサーバ上で同時にスクリプトを実行するためのソフトウェアツールです。主に、同じ役割のサーバが複数台存在するような環境での自動化であったり、アプリケーションのデプロイ自動化に利用されています。 特にRuby On
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
chef-solo + capistrano で複数ホストを管理する - 酒日記 はてな支店
chef-server は仕組みが大げさでインストールも大変だし、10〜20台ぐらいなら chef-solo と capistrano を組み合わせればいいよね？（同案多数） Capistranoとchef-soloを組み合わせて使う | ひげろぐ capistrano + chef-soloで構成管理する - delirious thoughts 実はこれまでもずっと、適当に書き殴った shell script で rsync && chef-solo 実行というのをやっていたのですが、複数の json をいい感じにマージして適用したかったので、capistrano で書き直してみました。 fujiwara/chef-solo-with-capistrano · GitHub 方針 cookbook などのファイルの同期は rsync で 共通で使用する json とホストごとにそれを上
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
