Fabric は指定したコマンドを各ホストで実行する実行モデルです。この場合は特にホストの指定がなかったので、全部ローカルで、一回実行することになります。 これは結構つまんないので、本当の例を見ましょう。これは最近、仕事で作ったコマンドです。 nginx サーバーでメンテ画面を出すようなコマンドです。 各ロードバランサーで実行します。 from fabric.api import run, cd, abort, require, sudo, env from fabric.decorators import runs_once, roles from fabric.contrib.console import confirm ... @roles('loadbalancers') def start_maintenance(): """ メンテナンス画面に切り替える """ _produc
これまでサービスで使うCPANモジュールの管理と言えばrpm/debパッケージが主流だと思いますが、最近ではperlbrewで使いたいバージョンのperlをインストールすることもあり、rpm/debでは対応できなくなってきています。 perlbrewのperlに対してプロジェクトが依存しているCPANモジュールを入れる際、 $ perlbrew switch perl-5.12.3 $ cd /path/to/MyProj $ perl Makefile.PL $ cpanm --installdeps . などと cpanm —installdeps が使えます。 しかし、これではサーバを新規セットアップするたびに、最新のモジュールが入ることになりサーバ間でモジュールのバージョンの差異が生まれる可能性があります。 そこで対応策として考えられるのが開発サーバで—installdepsを実行
Welcome to Chef! Chef is a systems integration framework, built to bring the benefits of configuration management to your entire infrastructure. With Chef, you can: Manage your servers by writing code, not by running commands. (via Cookbooks) Integrate tightly with your applications, databases, LDAP directories, and more. (via Libraries) Easily configure applications that require knowledge about y
目がかい～～～の。こんにちは nakamura です。暖かくなってきたので、ぼちぼち自転車通勤始めようと思ってます。 デプロイって面倒な作業ですよね。本番環境へのデプロイは特に神経を使う上に FTP クライアント等を使っての手動アップだといつか絶対に漏れが出そう。サーバが複数台あったりするともう最悪！今日はその辺りのストレスを軽減する方法として rsync コマンドをご紹介します。 オプション色々 rsync はオプションがむちゃんこあります。代表的なものをいくつがご紹介しますが、もっと知りたい方はコマンドラインで man rsync と実行すれば公式のマニュアルが読めますよ。 -a オプション --archive オプションの略で更には -rlptgoD オプションをひとつにまとめたものです。細かい点はマニュアルを参照してもらえれば分かりますが、一言で言うと『ローカルとリモートを全く同じ
Please note This documentation is for the stable (0.9) version of Fabric. To view documentation for the in-development (1.0) version, please click here. About¶ Fabric is a Python library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks. It provides a basic suite of operations for executing local or remote shell commands (normally or v
初歩的な管理ミスで3300もの有名サイトがソースコードを盗まれる この記事。まず訳がちょっと違うかな？という箇所があるのでそこを補っておくと。 しかしコードが実動サーバに乗る段階ではそれはローカルな作業用コピーではなく、エキスポートされた完成品だから、この問題が起こる。 こう訳されてる箇所があるけど、 When code is rolled to a live server from a repository, it is supposed to be done as an export rather than as a local working copy, and hence this problem. 実働サーバにコードを載せる場合は、ローカルな作業用コピーとして取得するのではなくエクスポートするべきだ。（だが今回はローカルな作業用コピーを本番に置いているので）問題になっている。 み
DSASのファイル転送システムを、オープンソースで公開します。 その名は、makuosan（まくおさん：通称「まくお」）っていいます。 名前は冗談っぽいですが、内容はわりと真面目です(^^; MAKUOSANプロジェクトサイト Webサイトの運用に欠かせない作業のひとつに、「デプロイ」という作業があります。 これは、新しいプログラムやデータなどをWebサーバに設置して利用できるようにす ることを指していますが、サイトの規模が大きくなってWebサーバの台数が増えると、 それに比例してファイル転送にかかる時間も長くなっていきます。 一般的な話として、サイトの規模が大きくなるほど運用コストは増大しますが、 その要因のひとつとして「デプロイ時のファイル転送に時間がかかる」という 点がありました。そこで、できるだけ運用コストを抑える（作業者の負担を減 らす）ために、独自のファイル転送システムをこしら
とある Subversion をリポジトリとするプロジェクトで、デプロイツールとして Capistrano を使用しようと思ったのですが、私と同僚の開発環境が異なる事を理由に、前から目を付けていた Webistrano を試してみました。 動作環境 apache 2.2.9 mysql 5.0.67 ruby 1.8.6 rails 2.1.0 passenger 2.0.3 capistrano 2.5.0 webistrano Revision 189 webistrano 本体は http://labs.peritor.com/svn/webistrano/trunk/ からチェックアウトしたものを使用しています。 基本的な使い方 下記を眺めると、何となく理解できます。 Screencasts – Peritor Webistrano – Trac Catalyst で作ったアプリを
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
デプロイツール Archer #0 Posted by Gosuke Miyashita Sun, 11 Feb 2007 18:35:29 GMT id:tokuhirom さん作のデプロイツール Archer を最近使い始めたのですが、これがすげーいいっす。 で、この週末は更に便利に使えるように、Archer 用のプラグイン書いたりしてました。 Archer::Plugin::SVN::Log Archer::Plugin::SVN::Diff Archer::Plugin::SVN::Update Archer::Plugin::Rsync Archer::Plugin::Shell global: work_dir: /home/miya/work dest_dir: /home/miya/assurer tasks: init: - module: SVN::Diff - mod
※ この資料について 2006年4月の勉強会資料をCapistranoのバージョンアップ（現時点では1.3.1になってました）による仕様変更などに合わせてちょっと修正したものです。 質疑応答の部分は当時のままなので最初の質問が初々しいです。 Capistranoって何なのさ デプロイツール デプロイ=配備 参考 : Capistrano: Automating Application Deployment 一言で言うと複数のサーバ上で同時に並行してコマンドを実行できるツール。 複数のサーバで動いているサービスのデプロイを楽に行うことができる。 Rails起源なのでRailsに特化した部分もあるが、ほかのアプリケーションでも使える。 昔はSwitchTowerと呼ばれていた。はてなでも使われてる。 何がいいのか 複数サーバへの作業が効率化、自動化できる 定義済みの標準タスクに沿った運用をする
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
