今回のテーマは「Djangoアプリケーションのデプロイの概要」です。いよいよ第４章が始まりました。この章ではdjangoアプリケーションのデプロイの基礎を見ていきます。一般的にウェブアプリケーションのデプロイ方法は手法が沢山あり唯一無二の正解があるわけではありません。インフラや規模によっても選択するツールや手法が異なりますので本章ではできるだけ原理的な話を中心にしようと思います。原理が理解できていれば便利なデプロイツールや自動化ツールを使うのは難しくないはずです。
Webアプリケーションのデプロイ
この「Django学習帳」はDjangoで初めてWebアプリケーションを作成する方も対象としているためWebアプリケーションのデプロイについても簡単に触れておきます。一般的にWEBアプリケーションは開発者がローカル環境で開発しただけではユーザーは使えないため、公開するためのサーバーに設置する必要があります。簡単に言うとデプロイ作業とはローカルで開発していたWebアプリケーションをサーバに反映させ公開できるようにする設置作業のことです。
静的なHTMLとCSS、javascriptのみで構成されたWEBページであればデプロイ作業はファイルを適当な構成で配置するだけの簡単な作業です。（SCSSやjavascript等のフロントエンド関連のビルドもデプロイ作業に含まれますが、本質的な話ではないので一旦横に置きます。）しかし、サーバーサイドプログラムが動作する一般的なウェブアプリケーションではユーザーからのリクエストをプログラムに伝え動作させるためのミドルウェアの設定や、ソースコードの変更を反映させる方法、データベースのマイグレーションなどを行う必要があります。
現在では様々な自動化ツールが開発され手軽にデプロイできるようになっています。またDocker等のWEBアプリが動作する仮想環境をそのまま本番環境にアップロードするだけという手法も生まれており多様化しています。しかし、基本的な部分は変わりませんので一度オンプレミスやVPSで環境構築からデプロイまでを一通り経験しておくと良い経験になると思います。
Djangoアプリケーションのデプロイ
おそらくDjangoでアプリケーションを作成してきた方はDjangoに付随している開発用サーバを起動してローカル環境で開発をしてきたと思います。（Docker環境という方も居るかと思いますが・・・）この開発用サーバはあくまで開発用なので公開には使用できません。間違っても本番サーバーで./manage runserverで開発サーバを起動して外部へ公開してはいけません。
DjangoはWSGIをサポートするフレームワークです。ですのでDjangoに限らず、WSGIアプリケーションをデプロイした経験があればさほど難しくは感じない筈です。（動作環境やデプロイ方法の共通化がWSGIの大きな目的でもあります。）今回はDjangoアプリケーションを動作させる方法の１つとしてNginx + uWSGIで動作させる方法を中心に見ていきたいたいと思います。
WSGIについて
ご存知の方も多いかと思いますがWSGIについて見ていきましょう。WSGIはWeb Server Gateway Interfaceの頭文字を取って名付けられています。PythonにおいてWebアプリケーションとWebサーバーを結びつけるための標準化された規格と考えれば良いと思います。Python製のWEBフレームワークはDjangoに限らずWSGIをサポートしているものが多く、共通の手法でWebサーバーで動作することが出来ます。
WSGIはWSGIサーバ(WSGIアプリケーションコンテナ)で上で動作します。この実装としてはuWSGI, guniconなどの他にApache用のモジュールであるmod_wsgiやmod_pythonなどがあります。Apache上で動作させる際にはmod_wsgiを使用する方法がメジャーだと思います。今回はNginxで動作させるため、uWSGIを用いて動作させようと思います。
uWSGIについて
uWSGIは前項で説明したWSGIサーバの１つです。pythonのライブラリ管理ツールpipでインストール可能です。（ただしC言語で書かれているためGCC等のC言語コンパイラが必須です)
Nginx + uWSGIでDjangoアプリを動かす環境の概要
それでは実際にNginx + uWSGIでDjangoアプリケーションを動作させる概念図を見ながら概要を見ていきましょう。冒頭に書いたようにあくまで構成例であり、唯一の正解ではないことに注意してください。ユーザーがWEBサーバーにアクセスしてからNginxを経由してuWSGIに接続され、Djangoアプリケーションを呼び出すところがイメージできれば良いと思います。当然ですが、WEBサーバにApacheを使用した場合は異なる図となります。
fig. 4-1
NginxとuWSGIの通信
uWSGIがDjangoを動作させるサーバとなり、Nginxはリバースプロキシとしてユーザーからのリクエスト受けることになります。
NginxとuWSGIの通信はポートを指定する場合とunixドメインソケットを使用する場合があります。同サーバー上でNginxとuWSGIを動かす場合にはunixドメインソケットの方が良いかと思います。
尚、Djangoアプリのソースコードを更新した場合はuWSGIを再起動する必要があるのでシステムのinit（多くの場合はSystemd)と管理できるようにしておくと自動化が非常に楽になります。
venv仮想環境でアプリごとに独立した環境を構築
Djangoアプリケーションはvenv仮想環境下で動かすことを想定しました。同一サーバーに複数のDjangoアプリが存在した場合にvenv仮想環境下で動作させておくとアプリケーションごとにライブラリの独立性を保つことができます。これによりDjango2.0のアプリとDjango2.1のアプリが同一サーバーに共存するなどということも可能となります。
ソースコードの更新
WEBアプリケーションが公開された後のデプロイ作業はソースコードの更新作業とDBマイグレーションが主な作業となると思います。ソースコードの更新方法は様々な手法が考えられますが、多くの場合はGitサーバからpullすることで更新することが主流ではないでしょうか？近年Githubを始めGitのホスティングサービスは充実しているので活用しているプロジェクトも多いと思います。プロジェクトによってはSFTPによるアップロードなども考えられます。ただしGitはあくまでソースのバージョン管理ツールなのでデプロイに必須ではありません。
ただし近年Gitのhookを契機にビルドツールやデプロイツールが走るようになっているプロジェクトは多く、GitやSVN等のバージョン管理ツールとデプロイ作業は密接な関わりを持っていることは確かです。
マイグレーション
ソースコードの更新に合せてデータベースのマイグレーションを行いますが、マイグレーションはDjangoのマイグレーションツールを使っても良いですし、Flyway等の独自のマイグレーションツールを活用しても問題ありません。本ページではDjangoのマイグレーションツールを利用することを前提として説明していきたいと思います。
最後に
近年はより簡単にWEBアプリケーションをデプロイできるホスティングサービスが増え、自らオンプレミス環境で一から環境構築する機会はあまりないかも知れません。しかし自らサーバーを立て、Webアプリケーションを公開した経験は無駄にならないと思っています。是非一度挑戦してみてください。
Sponsored Link