デプロイにはFabricが超便利

デプロイって大げさな名前だなぁって思うわけですよ。業務報告受けていても、「今日一日はデプロイでした」って、そんなバカなと。アプリケーションって、基本的にはファイルのコピーなわけで、ファイルのコピーがそんなにたくさんの「工程」を経ているのなら、それたぶんまちがってる。

そんな分けで、Webアプリのリリースに関してまとめますね。

想定する構成

いわゆるWebアプリ。ApacheなどのWebサーバ数台と、DBサーバとう二階層。アプリケーションサーバみたいなものもあるけど、ここではWebサーバと呼ぶことにする。

データとプログラムは事情が違う

DBのテーブル構造が変わったりするのは、データ構造いじりながらアプリ稼働ってのは難しい。だけどWebのプログラムは基本は一瞬で変えれる。

Webの再起動

PHPをApacheのモジュールで動かしているようなケースは、PHPファイルを更新するとそのままWebのプログラムが変わる。スクリプト言語とその稼働のさせ方によっては、プログラムを更新させたあとに、Webを再起動させなくちゃいけないケースもある。これがちょっと面倒。もちろんスクリプトを更新してたあとに再起動させるWebアプリケーションは、それはそれで「プログラムがメモリに常駐している」ということだからメリットもある。

NFS or Webサーバローカル

複数のWebサーバは同じ動きをして欲しいから、同じプログラムが動いていて欲しい。そういう場合にはNFSサーバを置いて、複数のWebサーバからはNFSサーバをマウントするという構成をとることもある。デプロイという観点からは超便利。欠点としては、NFSサーバが調子悪いと、システム全体がダウンする。折角Webサーバを複数に展開しているのに障害に弱いポイントができてしまっている。だからWebサーバのローカルに置けばいいのだけれど、今度はファイルの同期が面倒になる。

同期の方法あれこれ

rsync

rsyncは、その名の通りリモートサーバ感でフォルダの同期を取るコマンド

リポジトリから同期

svnのupdateや、gitのpullを使って同期を取る
個々のサーバでコマンドを発行しなくちゃいけない
なんやかんやでコマンド発行は必要
ファイルの同期という観点だけなら、rsyncでいいのだけど、どうせその後にはサーバ再起動したりしなくちゃいけないのだから、リポジトリからの同期がシンプルで便利。

ということでFabricが便利

Fabricというのは、Pythonで書かれたスクリプト。凝ったことはしていなくて、コマンドを受け付ける側に特別なアプリをインストールしなくていいので、導入が楽ちん。
使い方は、本家をみてもらうとして、必要な箇所だけピックアップ。

ロールという概念で、接続先のマシンのエイリアスを配列でもち

run でそのマシン上でのコマンドを発行

def AppStart(app_name=None):
    if app_name is None:
        app_name = APP_NAME
    run("service "+app_name+" start",pty=False)

sudo で、別ユーザでのコマンド発行

def SvnUp():
    sudo('cd '+APP_WORK_DIR+'; svn up', user='webservice')

こんな感じ。