意識を低く保ったまま、定型作業を自動化する話です。 ※どうも言葉足らずで誤解させてしまっているようなので補足を書きました。ご覧ください http://qiita.com/greenspa/items/fff535d2ae5da36e36fe
![デプロイツールFabric](https://cdn-ak-scissors.b.st-hatena.com/image/square/5ce336d6b550a2b2f384bd042c55a156169bc3ee/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Ffabric-130426022257-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Fabricというアプリケーションのデプロイ作業や管理作業を自動化するためのツール(Pythonモジュール含む)があります。 アプリケーションのデプロイ作業や管理作業の自動化の為のツールと聞くと、訳の分からんDSL覚えなきゃいけないのかだるいなぁとか、謎のアーキテクチャに合わせなきゃいけないのかめんどくせとか思ってしまうタイプだったんですが、FabricはPythonで書けます。仕組みも(概念的にはでありますが)単純です。 ローカルからリモートへSSHで接続して行える作業だったら基本的に何でも自動化出来ます。 で、リモートのサーバーを複数定義しておくと、自動化した作業を1つずつ全部に適用してくれます。 ロードバランサーの下にWebサーバーが複数あって、それらに自動的にアプリケーションを配置・再配置するために使うってのがよくあるパターンだと思います。 今回は、複数のサーバーに同じ初期設定を行
信頼性の高いシステムを構築課題として、以下があります。 デプロイ方法の確立 テスト技法の確立 今回はデプロイに関連して、Capistrano を使ったリモートサーバでのタスク実行について調査してみました。 現状のデプロイ法テストサーバから本番サーバへ Rsync。 Rsync については以下に記述あり。 rsyncを使った熟練者レベルのバックアップ Rsync は以下のようなスクリプトを書いて実行できる。 #!/bin/sh rsync -av $1 /path/to/yourapp/ \ haida@deploy_to_server:/path/to/deploy_to/ \ --exclude='tmp/cache/*' \ --exclude='tmp/pids/*' \ --exclude='tmp/sessions/*' \ --exclude='tmp/sockets/*' \
Twitterは、同社の何千台ものサーバに対してバイナリをデプロイする場合に、ピア・ツー・ピアシステムのBitTorrentを利用したツール「Murder」を用いていると、7月1日の記事「Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)~Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」」で紹介しました。 FacebookでもBitTorrentによる大規模なデプロイが高速に行われていることは、7月16日の記事「Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側」で紹介しました。 どうやら大規模システムにおけるデプロイではBitTorrentの利用が進んでいるようです。 7月15日付けのTwitter Engineering Blogに、Twitterのエンジニア、Larry Gadea氏による「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く