Heroku は人気のある Platform-as-a-Service (PaaS) で、開発者はハードウェアとソフトウェアの面で必要なインフラを利用して、アプリケーションを実行およびデプロイすることができます。
これは、エンドユーザーにアプリケーションを公開するために必要なハードウェアやソフトウェアに投資する必要がないことを意味し、この自由により、デプロイではなく、ビジネスロジックに集中することができます。
この投稿では、シンプルなDjangoアプリケーションをHerokuパイプラインにデプロイする方法の概要を説明します。この記事は、既存の Python 開発者を対象としており、Django アプリケーションのセットアップと実行に関する基本的な理解を想定しています。
前提条件
この投稿では、以下のものが必要です。
- 無料版Herokuのアカウント
- Python 3+ と Virtualenv がインストールされていること。
- GitのインストールとGitHubのアカウント。
デモアプリケーション
Djangoアプリのブートストラップ
Django アプリケーションをデプロイする前に、Heroku の要件に従って準備する必要があります。まず仮想環境を作成し、それを有効にして必要なパッケージをインストールし、最後にシンプルな Django アプリケーションをブートストラップすることから始めます。
$ virtualenv --python=python3 env --no-site-packages
$ source env/bin/activate
$ pip install django gunicorn
$ django-admin startproject plaindjango
すべてがうまくいけば、次のようなランディングページがローカルサーバ上で動作するはずです。
この時点で、プロジェクトのフォルダ構造は以下のようになっています。
$ cd plaindjango && tree .
.
├── manage.py
└── plaindjango
├── __init__.py
├── asgi.py
├── settings.py
├── urls.py
└── wsgi.py
1 directory, 6 files
Heroku にデプロイする前に、いくつか変更する必要があります。まず、 plaindjango/settings.py にある ALLOWED_HOSTS 設定を変更する必要があります。
ALLOWED_HOSTS = ['*']
この設定は、 Django アプリケーションがサービスを提供できるホストやドメインを定義します。これは HTTP ヘッダホスト攻撃に対するセキュリティ対策ですが、私たちのプロジェクトは単純なデモプロジェクトなので、リストに '*' を追加することで、全てのホストを許可することにします。
次に必要なのは、 STATIC_ROOT 設定で静的ファイル用のフォルダを指定することです。
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
Herokuがアプリケーションをデプロイするときに、 django-admin collectstatic コマンドを実行し、すべての静的ファイルをバンドルして、指定したフォルダに保存します。このフォルダは、プロジェクトのルートディレクトリになります。
デプロイメント用アプリの準備
Django アプリケーションの準備ができたので、Heroku は以下のファイルをプロジェクトルートにインクルードして、デプロイの準備ができるようにすることを要求しています。
-
runtime.txt
このファイルの目的は、プロジェクトの実行に使用される Python のバージョンを指定することです。私たちの場合、このファイルには以下の内容が含まれます。
python-3.7.6
-
Procfile
プログラム起動時に実行されるコマンドを指定するファイルです。
セットアップ中に、 UNIX 用の純粋な Python WSGI (Web Server Gateway Interface) サーバである Gunicorn (‘Green Unicorn’) をインストー ルしました。
Django は独自の WSGI サーバを同梱していますが、このプロファイルは Heroku に対して、アプリケーションを提供するために Gunicorn を使用するように指示します。このファイルの内容は以下の通りです。
web: gunicorn plaindjango.wsgi:application --log-file -
この行は Heroku に、私たちのアプリケーションは gunicorn を使って起動される web プロセスまたはアプリケーションであることを伝えています。Gunicorn は私たちのプロジェクトの WSGI ファイルを使用して、アプリケーションサーバーを起動します。
-
requirements.txt
最後に、Django アプリケーションの要件を定義する requirements.txt ファイルが必要です。次のコマンドを実行することで、仮想環境上にこのファイルを作成することができます。
$ pip freeze > requirements.txt
追加ファイルを含む Django アプリケーションの最終的なフォルダ構造は、次のようになります。
$ tree .
.
├── Procfile
├── manage.py
├── plaindjango
│ ├── __init__.py
│ ├── wsgi.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── requirements.txt
└── runtime.txt
1 directory, 9 files
これらのファイルを配置することで、私たちのアプリケーションは Heroku に対応する準備が整いました。
GitHub経由でHerokuにデプロイする
Heroku は独自の Git プラットフォームを提供しており、それを使ってデプロイすることもできますが、GitHub ほど機能は豊富ではありません。Heroku でも、GitHub からコードを引っ張ってきてデプロイすることができます。
GitHub リポジトリを作成してコードをプッシュすれば、デプロイの準備が整います。
参考までに、Heroku へのデプロイが可能な GitHub 上の Django アプリケーションのサンプルを以下に示します。
GitHub での準備ができたら Heroku に移動して、Heroku のダッシュボードの右上にある “New” ボタンで新しいパイプラインを作成します。
パイプラインの名前と、接続する GitHub リポジトリを指定します。
パイプラインは、同じコードベースを共有するHerokuアプリケーションのグループを表します。パイプラインでは、継続的デリバリーワークフローの異なるステージを定義することができます。
つまり、Heroku を使って GitHub から本番環境、ステージング環境、開発環境に同時にコードをデプロイすることができるのです。
GitHub をアプリケーションのソースとして使う場合、Heroku のパイプラインを設定することで、異なるブランチのコードを異なる環境にデプロイすることができます。
例えば、”master” ブランチのコードは本番環境に、”staging” ブランチはステージング環境に、”dev” ブランチは開発環境にデプロイされることになります。
これにより、複数のステージにまたがるプロジェクトを可視化し、デリバリーを強化することができます。
Heroku pipelinesには「Review Apps」という機能があり、Pull Requestsをスタンドアロンアプリケーションとしてデプロイすることができます。この機能を使えば、ローカルに変更を取り込んでテストすることなく、Pull Requestsの作業を検証することができます。
Herokuパイプライン
GitHubで最近作成したアプリケーションのパイプラインを表示しています。
パイプラインにはデフォルトで2つのステージがあり、レビューアプリを有効にするセクションがあります。現在、すべてのコードは “master” ブランチにあるので、production ステージで “Add app” をクリックしてブランチをデプロイしてみましょう。
Herokuでは、既存のアプリケーションをパイプラインに追加したり、新しいパイプラインを作成したりすることができます。これは新しいパイプラインなので、本番環境となる plaindjango-production という名前の新しいアプリケーションを作成します。
この結果、以下のようになります。
本番用アプリケーションは作成されましたが、コードはまだ実行されていません。次のステップは、コードを本番環境にデプロイするブランチを選択することです。
Deploy” をクリックすると、Heroku は “master” ブランチからコードを取得し、デプロイします。デプロイの進行状況はログで確認することができ、アプリケーションがデプロイされると、実行中のアプリケーションへのリンクが表示されます。
ログの一番最後に、実行中のアプリケーションへのリンクがあります。このリンクにアクセスすると、 Django のランディングページが表示されます。
これで、本番用の Django アプリケーションを GitHub 経由で Heroku にデプロイすることができました。ステージング環境用のアプリを作るには、マスター環境と同じステップを踏みます。
まず、ターミナルから GitHub 上に “staging” ブランチを作成します。
$ git checkout -b staging && git push origin staging
最後に、プロジェクトにアプリケーションを追加し、”staging” ブランチから “master” ブランチへのプルリクエストを作成します。
プルリクエストはGitHubのここで見ることができ、これがHerokuのパイプライン上の結果です。
プルリクエストのために新しいアプリケーションが作成され、それを開くと、プルリクエストによってプロジェクトにもたらされた変更を確認することができます。
プルリクエストは正常にデプロイされ、変更をマスターにマージする前に確認することができます。自動デプロイを有効にすると、プルリクエストを master ブランチにマージした時点で Heroku がデプロイし、変更は自動的に公開されます。
結論
Django アプリケーションを GitHub から Heroku にパイプラインでデプロイしてみました。これは Heroku に Django アプリケーションをデプロイする唯一の方法ではありませんが、共同プロジェクトには最も適しています。
コンテナ化されたアプリケーションは、Docker イメージをビルドして Dockerhub か Heroku 独自のコンテナレジストリに公開することで Heroku にデプロイできます。Docker化されたアプリケーションのHerokuへのデプロイについての詳細は、公式ドキュメントを参照してください。Herokuはまた、CLIツールと組み合わせてアプリケーションをデプロイするために使用できるGitプラットフォームも提供しています。
gitとGitHubの機能を統合し、コンテナ型アプリケーションのデプロイを可能にしたHerokuは、開発ニーズに対応する有能なプラットフォームと言えます。また、このプラットフォームは、マーケットプレイスを通じてアドオンを提供している。
これらのアドオンは、私たちのアプリケーションを強化するために使用できるサービスやインフラの一部分です。このようなアドオンにより、PostgreSQL、MySQL、Redisを含むデータベースやデータストアにアプリケーションを統合することができます。
Heroku 上の Django アプリケーションで実現できることはもっとたくさんあります。この投稿は、日々のワークフローに合った方法でプラットフォームに Django アプリケーションをデプロイする方法を簡単に紹介することを意図しています。
Heroku に対応した Django プロジェクトは GitHub で見ることができますし、デプロイされたオープンなプルリクエストも見ることができます。