moxt

Just another Blog site

DjangoアプリをCapistrano使ってデプロイする

      2015/11/30

Railsアプリでデプロイする、といえばCapistranoが定番感ある。
ではDjangoの場合はどうなんだ。
と、思ってググってみるも有用な情報を見いだせなかった。。

なので、Capistranoを使ってデプロイタスクを雑に書いてみる。

デプロイタスクで何をすべきか

こんな感じだろうか。

  • ブランチからソースコードをpullする
  • 追加ライブラリをインストール
  • DBのマイグレーション
  • 画像,js,cssといったアセットファイルたちを加工したり・特定の場所に移動したり
  • アプリケーションサーバー(ここではgunicorn)を再起動

業務プロジェクトでデプロイするなら『Slackに通知』とかもあるだろう。

Fabricは?

Fabricでもいいんだけど、FabricってRailsでいうところのSinatraなイメージがあって、上記のタスクを実現しようとすると結構手を動かさないとダメかも&単純な構成のアプリなのでFabricほどの小回りはいらない、というで理由で不採用。

Capistranoをプロジェクトに導入

cap installでOK
Capfileやらdeploy.rbやら必要なファイルたちが生成される。

deploy.rbを編集

デプロイタスクの共通部分ですね。
こんな感じ。

set :linked_dirs, fetch(:linked_dirs, []).push('static')python manage.py collectstaticでアセットファイルを集約して転送する先をstaticというディレクトリをリリースバージョン間で共有したかったので指定してる。
指定しないと各バージョンごとにアセットファイルを保有するので無駄にストレージを消費しちゃうよ。

after XXX, XXXな部分が独自に追加したタスク。
こちらは後述する。

production.rbを編集

ステージングは不要だったのでプロダクションだけ弄った。
超シンプルですね。

Django関連のタスク(django.cap)

bundle,migrate,assetsのやってることは超シンプル。
Djangoやってる人なら必ず使うだろうコマンドを実行してるだけ。

Gunicorn関連のタスク(gunicorn.cap)

Gunicornの起動・停止・再起動のタスクをつらつら書いてる。
Gunicornそのものがわりとメジャーな存在だと思うので送ってるシグナルに見覚えあるはず。

デプロイしてみる

cap production deployでOK
ログがつらつら流れてくるので、しばらく放置してると完了するはず。

 - Python

336px




336px




  • このエントリーをはてなブックマークに追加
  • follow us in feedly

  関連記事