Djangoを触り始めた頃。
「APIくらいなら共有レンタルサーバーでも動くやろ」
そう思って、さくらの共有サーバーにDjangoをデプロイしようとした。
構成としてはシンプル。
Apache ↓gunicorn ↓Django今思えば、この時点ではまだ平和だった。
まだ。
gunicornが存在しない
まずは仮想環境を作って、
pip install gunicornよし。
じゃあ起動。
gunicorn mysite.wsgiすると。
gunicorn: Command not foundは？
さっき入れたやん。
最初は
- インストール失敗した？
- pipがおかしい？
- PATH壊れてる？
この辺を疑った。
結論から言うと、単純に仮想環境に入れていなかったり、PATHが通っていなかったりした。
こういう「入れたはずなのに存在しない現象」、Python界隈では定期的に遭遇する。
Apacheに門前払いされる
gunicornを起動できたので、次はApacheから転送する。
ネットの記事を見ながら.htaccessを書いた。
すると。
.htaccess: DocumentRoot not allowed hereさらに。
.htaccess: <Proxy not allowed hereさらにさらに。
.htaccess: ProxyPass not allowed hereApache、怒りすぎである。
最初は設定ミスだと思った。
スペルミスか？
改行コードか？
いや違う。
原因は単純だった。
共有サーバーではVirtualHost系の設定は使えない。
つまりネット上の記事に書いてある
DocumentRootProxyPass<Proxy>この辺がほぼ使えない。
この時初めて理解した。
共有サーバーは普通のApacheサーバーではない。
Internal Server Errorしか返ってこない
設定を書き換えてアクセスすると、
Internal Server Errorだけが返ってくる。
情報ゼロ。
まずはgunicornが生きているか確認したい。
Linuxなら普通こうする。
lsof -i:8000しかし。
lsof: Command not found.なら。
netstat -anPermission denied共有サーバー、そこも制限するんか。
この辺から嫌な予感がし始めた。
結局、
ps aux | grep gunicornと
curl http://127.0.0.1:8000だけを頼りにデバッグすることになった。
staticファイルが消える
なんとか管理画面は表示できた。
勝った。
そう思った。
しかし画面は真っ白だった。
CSSがない。
Django管理画面がプレーンHTMLになっている。
お約束のstatic問題である。
しかも共有サーバーなので、
Alias /static/ ...を書いたら、
Alias not allowed hereと返される。
ここでもApacheに怒られた。
結局、
python manage.py collectstaticで公開ディレクトリ配下に静的ファイルを集める構成にした。
無限ループするRewriteRule
次に遭遇したのがこれ。
Request exceeded the limit of 10 internal redirectsApacheが
お前、さっきから同じ場所に飛ばし続けてるやん
と怒っている。
RewriteRuleの転送先が、自分自身を指していた。
.htaccessは一見シンプルに見えるが、条件を一つ間違えると簡単にループする。
デバッグが難しい分、かなり厄介だった。
やっと起動したと思ったらMySQLに怒られる
苦労してDjangoを起動させた。
ここで終わると思っていた。
甘かった。
django.db.utils.NotSupportedError:MySQL 8 or later is required(found 5.7.40)ここで初めて知る。
さくら共有サーバーのMySQLは5.7。
そしてDjango4系はMySQL8必須。
つまり。
動かない。
「じゃあMySQL8を自前ビルドするか」
そう考え始めたあたりから、話はさらに大きくなっていく。
その時はまだ、Boostやlibunwindと戦うことになるとは思っていなかった。
次回。
さくらレンタルサーバーにMySQL8を入れようとして、依存関係モグラ叩き編が始まった話