はじめに（注意）
この記事ではGAEのフレキシブル環境を利用してDjangoアプリケーションをインターネット上に公開するまでの内容を書いていますが、そもそもGAEのフレキシブル環境は2017/7/10（月）時点では「ベータ版」となっています。チュートリアルページにも「本番環境でのご利用はお勧めしません。」と記載されていますので、それを踏まえた上でこの記事を読んでいただければと思います。
参考：
App Engine フレキシブル環境での Django の実行
本文
最近、個人的にDjangoでとあるWebアプリケーションを開発しているのですが、それを公開するにあたってAzure Web AppやGoogle App Engineなど、いくつかのPaaSサービスを試してみています。この記事ではその中でも Google App Engine（以下GAE）を使った場合のデプロイまでの記録を、主にハマった点に注目して書いていきたいと思います。
GAEでDjango（Python3）となると、ググってもだいぶ情報が少なかった印象なので、同じようにハマっている人の役に立てればと思う次第です。
ハマった原因
振り返ると、僕がいろいろとハマった原因は以下の2点です。
- 「スタンダード環境」ではPython3を実行できない
- 作業の全体像が把握しづらく、「今何やってるんだっけ？」状態になりやすい
（僕はDjangoもGAEも初めてのため、もしかしたら慣れてる人にとっては「そんなのあたりまえじゃん」な内容もあるかもしれません。）
では、以下に詳細を書いていきます。
「スタンダード環境」ではPython3を実行できない
そもそも、GAEには「スタンダード環境」と「フレキシブル環境」があり、それぞれ仕組みや制限事項、用途が違います。僕はこれを知らなかったためにだいぶハマってしまいました。
「GAEでDjangoアプリケーションをデプロイするぜ！」と思ったら、まずは「Django Google App Engine」でググってみるかと思います。（たぶん）
すると、以下のページが上の方にヒットします。
App Engine スタンダード環境での Django の実行
おお、公式のチュートリアルがヒットしました。これは手順通りに進めていけばうまくいきそうですね！
と思ったそこのあなた（僕です）、ちょっと待ってください。このページのタイトルは「App Engine スタンダード環境での Django の実行」です。
そして次にこちらのDjango スタートガイドページを見てみると（先ほどのページの１つ上の階層のページですね）、スタンダード環境が使用できないケースの欄に、
Python 3 が必要
App Engine の標準 Python 環境で使用できないシステム ライブラリが必要
との記載されています。
つまり、Python3でアプリケーションを書いたり、「App Engineの標準Python環境で使用できないシステムライブラリ」を利用して開発したい場合、このスタンダード環境は利用できない、ということになります。
つまり、先ほどの「スタンダード環境」向けのページの通りに作業を進めてもそのあたりの制限でハマってしまう、というワケです。僕はこれに気が付かず、スタンダード環境でなんとかPython3を実行したりライブラリをインストールさせようとして四苦八苦してしまいました。
なお、スタンダード環境とフレキシブル環境の違いについての詳細な説明は以下のページにまとまっています。
App Engine スタンダード環境ユーザーのための App Engine フレキシブル環境
要するに、プラットフォームとしての動作方法が全く違うため、うまく使い分けてね、ということで、単純にPython3が使いたければフレキシブル環境、というわけでもないようです。このあたりはちゃんと理解した上でシステム設計をする必要がありそうです。
今回はひとまずPython3で書いてしまったシステムをGAEへデプロイしてみたい、ということで、以下のページを参考に作業を進めます。
App Engine フレキシブル環境での Django の実行
※ 最初にも書きましたが、フレキシブル環境はベータ版のため、このまま本番環境として利用するのはお勧めされません。僕も最終的にどう本番環境を構築するかはこれから考えます（この記事では結論は出ません）
作業の全体像が把握しづらく、「今何やってるんだっけ？」状態になりやすい
さて、参考にするチュートリアルページが見つかったら、あとはこれを頼りに作業を進めていく形になります。
なのですが、この手順がなかなか長く、実際に1からあれこれやっていると「あれ、今何のために何をやってるんだっけ？」状態にだんだんと陥ってきます。
そんな時に自分の現在地を確認するための目安として、作業開始からデプロイまでにどんな手順があるのかを把握しておくことは精神衛生上とても有効だと思いますので、ここにまとめます。
項目としては、以下の通りです。
- Google Cloud Platformを使うためにアカウントを設定する
- Google Cloud Platformのプロジェクトを作成する
- Google Cloud SDKをインストールする
- データベース（Cloud SQL）を準備する
- サンプルプロジェクトをクローンし、試しにデプロイしてみる
- 自分のアプリケーションをデプロイする
それぞれについて、もう少し詳しく説明します。
なお、具体的な作業手順についてはドキュメントに記載の通りですので、割愛します。ここではあくまで全体像を把握することが目的です。
Google Cloud Platformを使うためにアカウントを設定する
今更ですが、GAEはGoogle Cloud Platform（以下GCP） という、Googleが提供するクラウドサービス群のひとつです。AWSにEC2やLambda、S3といった様々なサービスがあるのと同様、GCPもGAEやCloud Storage（あとで出てきます）、Big Queryなど、様々なサービスがあります。GAEはその中のひとつ、というワケですね。
そのため、まずはGCPを使い始めるためにアカウントの設定（Gmailアカウントをそのまま使えます）をします。課金の設定もここでしておいてください。
Google Cloud Platformのプロジェクトを作成する
GCPでは、様々なサービスを「プロジェクト」という単位で一つのシステムにまとめます。まずはプロジェクトを作成しましょう。
チュートリアルに従って、GCPのコンソールページを開いてプロジェクトを作成します。
ここで作成したプロジェクトのIDは後で何かと使いますので、どこかにテキストとして控えておくと作業がしやすくなります。
Google Cloud SDKをインストールする
GAEを含め、GCPの各サービスをコマンドラインから操作するためにはGoogle Cloud SDKのインストールが必要です。
コマンド自体のインストール、アカウントの設定、動作確認等、これだけでも何かとやることがありますので、こちらも手順（別ページ）を見ながら一つずつ進めていきます。
データベース（Cloud SQL）を準備する
DjangoにしてもRailsにしても、開発環境で利用していたSQLiteをそのまま本番環境で使い続けるわけにはいきません。アプリケーションをデプロイするタイミングで何かしらのRDBを準備し、そこに接続するよう設定を書き直す必要があります。
GAEでは、同じGCPのサービスの一つであるCloud SQLを利用する方法がチュートリアルとして説明されています。
GCPのコンソールでCloud SQLを有効にし、インスタンスを作成し、rootユーザーを作成したりアクセス制御をしてログインできる環境を整えたりと、いろいろとやることがありますので、ここでも迷子にならないようにご注意ください。
なお、Cloud SQLのインスタンスには第1世代と第2世代があるようなのですが、フレキシブル環境で利用する場合は必ず第2世代を利用するようです。
各種設定が完了したら、次の工程でクローンしてきたサンプルプロジェクトのsettings.py ファイルに設定内容を記載し、アプリケーションがDBに接続できるようにします。
サンプルプロジェクトをクローンし、試しにデプロイしてみる
いきなり自分のアプリケーションをデプロイしようとすると、ライブラリのバージョンの関係やGAEに必要な設定ファイルの内容、そもそものGAEへのデプロイ準備の不備など、エラーが出たときの原因の切り分けが難しくなってしまいます。
まずは、手順に記載の通りサンプルのプロジェクトをクローンしてDBの接続設定だけを変え、一度GAEのフレキシブル環境へデプロイしてみます。
用意された Hello World ページが問題なく表示されることを確認したら、次の段階に進みます。
自分のアプリケーションをデプロイする
ここまでできたら、あとは先ほどデプロイしてみたサンプルプロジェクトへ少しずつ自分のアプリケーションを移植＆デプロイ＆動作確認を繰り替えし、問題なく自分のアプリケーションがインターネット上で動作することを確認します。
だいたい、DjangoやPython自体のバージョンの違い、ライブラリの違い、DBの違いなどでローカルとは違ったエラーが出たりしますので、原因の切り分けを楽にするためにも少しずつ進めるのがオススメです。
ライブラリが見つからない類のエラーの場合は、 pip freeze > requirements.txt で requirements.txt に自分が使っているライブラリの記載を追記し、GAEへデプロイした時にインストールしてもらうのを忘れないようにしましょう。
これで、ようやくアプリケーションの開発 → 本番公開の流れが見えてきました。
自分の書いたアプリケーションがローカル以外で動作するところを見るのは何度経験しても良いものです。
この後は、同じ手順で機能追加とデプロイを繰り返す感じになるかと思います。
今回はテンプレートプロジェクトをベースにしてデプロイしましたが、app.yamlや settings.py に記述されているGAE環境用の設定内容を理解し、自分のアプリケーションに合った内容に修正できるようになることも必要かと思います。
まとめ
今回はGAEに内容を絞って書きましたが、この試行錯誤の前にAzure Web Appでも同じように試行錯誤し、結果うまくデプロイできなかった、という体験をしました。
PaaSサービスは一度アプリケーションをデプロイできてしまえばあとはそこから修正を重ねるだけで楽なのですが、そこに至るまでにいろいろとそのPaaS独特な仕組みや制限事項、設定方法を理解しなければならず、「Hello World!」が少し大変な印象を受けました。
加えて、今回利用した「GAEのフレキシブル環境でDjango（Python3）」は、そもそもやっている人が少ないためか問題発生時にググってもなかなかピッタリな情報を見つけることができなかったことも、迷子になる大きな要因の一つでした。
実際に作業する中で発生した個々のエラーや解決方法などもこの記事で書ければと思ったのですが、ちゃんと内容をメモしていなかったり、解決してみると自分の単純な作業ミスだったりしたため、割愛します。何か具体的に困っていることがある方がいらっしゃいましたらコメントいただければと思います。（僕に解決できるかはわかりませんが、、、）