Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
twiwt.org - このウェブサイトは販売用です！ - twiwt リソースおよび情報
このウェブサイトは販売用です！ twiwt.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、twiwt.orgが全てとなります。あなたがお探しの内容が見つかることを願っています！
wercker + Capistrano で自動デプロイ - milk1000cc
GitHub / Bitbucket のプライベートリポジトリも無料で CI し放題の wercker というサービスがあります。(2013/11/30 現在) サイトもきれいで素敵です。ビルド成功後、Capistrano でデプロイが自動実行される方法を書いておきます。 まず、アプリの設定で SSH 公開鍵を作成します。 生成された公開鍵は、デプロイ先サーバの ~/.ssh/authorized_keys や Bitbucket のデプロイ鍵などに追加しておきます。 次に、アプリの設定から Deploy targets の設定をします。Custom deploy を選択して、 master ブランチのビルドに成功したら、自動デプロイするようにします。 入力したら、Deploy pipeline の Add new variable をクリック。 SSH Key pair を選択し、先ほど
Dockerを使ってWebアプリケーションをデプロイする - Qiita
Dockerを使うと、隔離された環境でアプリケーションを動かすことができます。 今回は実際の開発中のアプリケーションの代わりに、Sentryをデプロイしてみます。 はじめに Docker Docker, Incが公開している、Linuxコンテナを使って隔離された環境を構築できるソフトウェア 仮想環境構築に docker を使う - apatheia.info Rebuild: 14: DevOps with Docker, chef and serverspec (naoya, mizzy) Sentry Pythonで書かれたエラーログギングツール。サービスとして利用することもできるが、自分で構築することもできる。Djangoベース 今回は実際のアプリケーションを想定してgithubから最新版のソースコードをチェックアウトします。 https://getsentry.com/ 環境 備考
#isucon 2013で優勝しました - すぎゃーんメモ
第三回 ISUCONの本選に、参加しました。予選から引き続き、@kazeburoさん、@tagomorisさんとの「LINE選抜チーム」。 #isucon 2013予選に参加した - すぎゃーんメモ 第三回 #isucon 本選リアルタイムフォトレポート【更新終了】 : ISUCON公式Blog 結果はなんと、優勝！！ おや、優勝2回目だ。→第1回のとき タイムライン 予選のとき同様に、自分の手元にある記録と記憶を辿ってどんな雰囲気だったか書き残してみます。間違っていたらゴメンナサイ。 使用言語はPerlです。 〜10:00 出社…じゃなくて会場入り。ちゃんと前日に早寝したので寝坊せずに済みました。 〜11:00 開会待ち。早くきすぎた、でも他の参加者さんたちも早くからしっかり集まってる。 ルール説明。ストーリー仕立てで緊張感が走る。画像系サービスか〜。 11:00〜 開始。用意されたのは
おそらくはそれさえも平凡な日々: サーバーマシンのコア数に応じてworker数を調整する方法
PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ 便乗ポスト。最近は、上記内の「シェルスクリプトでラップする方法」で運用していることが多いです。その場合のone more tips. appサーバーごとにマシンスペックが違う場合がたまにあって、その場合マシンごとに worker数を調整したいけど、deployの都合上サーバー起動スクリプトは同じやつを使いた いってことがあります。 そこでおすすめなのが、CPUコア数に応じてworker数を計算する方法です。 シェルスクリプトの場合、 % cat app.sh #/bin/sh NCPU=`getconf _NPROCESSORS_ONLN` WORKERS=$(expr $NCPU \* 5) exec plackup -E production -s Starlet --max-workers=$WORKERS と
サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係 - プログラマでありたい
最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。 Chefの役割 まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態＆設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、本番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。 さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入る
「初めてのChefの教室」を開催しました。(動画&資料) - Engine Yard Blog JP
去る2/22(金)に恵比寿の弊社オフィスにて初の勉強会となる「初めてのChefの教室」を開催しました。インフラエンジニアだけでなく、アプリケーションエンジニアからも注目が集まっているChefの勉強会という事で様々な方にお集まり頂き、濃い情報交換が繰り広げられました。 この記事では内容のまとめてスライドや動画などの各種資料を集約します。さらに公開された記事などの資料も順次追加していきます。 Chef未経験者向けのセッション [eytokyo] 初めてのChefの教室 from suzuki on Vimeo. まずは最初のセッションとしてRubyもChefも未経験な人(≒PHPer)向けのChefのセッションをyandoが担当しました。セッションではChefの動作原理やアーキテクチャの全体像を示した上で、最低限レシピを書いて実行する為に必要な手順だけをデモを交えて紹介しました。また実際に公
Kansai.pmに行ってCinnamonというデプロイツールについて発表しました - $shibayu36->blog;
http://www.zusaar.com/event/476003 に参加して来て、前作ったデプロイツールであるCinnamonについて発表して来ました。 発表したこと 以前capistranoの奥深さに毎回ハマっているのを怒りを覚えて、もっとシンプルなデプロイツールであるCinnamonをantipopさんと一緒に作ったのでその発表をしてきました。それなりに好印象っぽかったので、発表してよかったです。 スライド Cinnamon - simple deploy tool from Yuki Shibazaki デモで使ったサンプルコード https://github.com/shibayu36/cinnamon-deploy-sample 簡単に紹介すると CinnamonはMinimumというのと、Role x Taskというのを思想として持っている Minimum : デプロイの方
GitHub - kentaro/cinnamon: a simple deploy tool
use strict; use warnings; # Exports some commands use Cinnamon::DSL; my $application = 'My::App'; # It's required if you want to login to remote host set user => 'johndoe'; # User defined params to use later set application => $application; set repository => "git://git.example.com/projects/$application"; # Lazily evaluated if passed as a code set lazy_value => sub { #... }; # Roles role developmen
Chef-solo の代わりに fabric を使う - methaneのブログ
Fabric は ssh 経由でリモートをゴニョゴニョするツールなので、デプロイツールとして見られがちですが、 cuisine など冪等な操作をサポートするライブラリを組み合わせれば手軽な構成管理ツールになります。 chef-solo に比べてターゲットとなるマシンへのインストールが不要なので vagrant と EC2 の Amazon AMI で同じように home ディレクトリを構築するようなスクリプトを書くことも可能です。 また fabtools を使えば、簡単に vagrant を対象にすることができます。 インストール: $ pip install fabric fabtool cuisine fabfile.py を作ります (サンプル): 使い方: $ fab vagrant package_upgrade setup_devtools # 開発マシンにいつもインストールし
Webアプリのディレクトリ事情 - ゆーすけべー日記
現在進行中で開発・運用しているWebアプリのファイルとディレクトリが若干ゴチャゴチャしてたんで、整理したらだいーぶスッキリした。こんな感じ！ MacBook@yusuke % tree -L 1 -F . ├── Makefile.PL ├── cli/ ├── config/ ├── deploy/ ├── etc/ ├── lib/ ├── log/ ├── psgi/ ├── public/ ├── sandbox/ ├── script/ ├── t/ └── templates/ ちなみにこのプロジェクトは以下が前提です。 Perl製、WebのフレームワークはMojoliciousを使っている 一つじゃなくていくつかのアプリのエンドポイントがある つまり一つのModel、複数の「Contoroller郡」で構成されている 一個一個見て行こう！ Makefile.PL Perlプロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ops for Everyone
http://papix.hateblo.jp/entry/2013/02/23/235900