前置き
・書いてる人はWEBエンジニア1年の素人です。
・Docker初めてさわる
・GCP初めてさわる
・Django初めてさわる
今作っているもの
CloudRun上で動作するウェブアプリケーション
- Django 3.0.3
- Python 3.8.0
- gunicorn 20.0.4
- Docker 19
- Docker-compose (ローカルでしか使わない、cloudrunで動かないので（動かせるかも？まだよくわかってない））
- Cloud SQL (mysql)
- SQLAlchemy
- alembic
これから似たような構成を作ろうとしている方へ
- なるべく公式のtutorialを参考にする
- なるべく最近の記事を参考にする（かなり最近の方が良いです）
- GCPの公式リファレンスはとても有用（Djangoのsampleプロジェクトまでありました…）
環境構築中の所感
- Docker何それから始まったのでとても苦労した
- Docker上で環境を構築してからcloud runの流れでやろうとすると苦労するかも
- 最初からcloud runの公式チュートリアルで進めた方が無難かも
- とはいえDockerでイメージを作ったりコンテナの中に入ったりDockerを体で理解するためには遠回りも意味があった
- Dockerまわりの参考記事は基礎知識が端折られてたりする
- Docker run はホストマシンとポートをバインドしないとコンテナとやり取りできない
最後のが個人的にはかなりつらい思いをした。
当たり前といえば当たり前だけどかなり時間を食った、というか起動オプションが何が必須で何が必須かわかりにくい…。
コンテナが正しく動かない理由がDockerfileが悪いのか、起動方法が悪いのか、コンテナはログを出せるけど詳細なログまで追う方法が仮想ではないコンソールの環境とは異なるため何が原因か探りにくかった。とにかく確実に動くもの、成功したコマンド、そういうものを積み重ねるか本質的な理解をしないとかなり躓く印象があった。
DockerFileの設定とか起動コマンドとかそのあたりがある程度固まってきた後は割とすんなり。
cloud SQLにSequelで接続する方法としては、GCPから提供されているプロキシを起動した状態でSequelのホストは127.0.0.1:PORTの標準の接続方法でいけた。
これらの設定はプロジェクトが終わった後にきっちりまとめたい。
：3/16追記
・webpackの設定とかいろいろやったけど、結論nuxt使った方が圧倒的に楽...
・ただいきなりnuxtから入ると何がなんやらだったので、フレームワークがやっていることを自分で組み立てて構築することの意義は感じた。やった方がいいとおもう。
:3/19追記
cloud-runはすごい
例えば、開発中に色々レイアウトをいじってたりする。
クラウドrunはデプロイしたバージョンを管理していて、いつでもお手軽に切り替えられる。
つまり、「昨日イケてないわ〜と思ったあのレイアウトもう１回見たいな〜」とかそういう時に、gitのcommit logからハッシュを探して開発環境を元に戻して・・・とかそういうことをしなくていい。
デプロイしたビルドに名前をつけておけば、開発用のcloud-runの環境があるならいつでも確認できる。
もしバグがあったなら、調査もすぐできるし、他の人にデバッグをお願いする時もURLを渡すだけ。
いちいち環境がどうだったとかまとめてもらう必要はない。
なぜならデプロイされたバージョンで全て再現されているから。
しゅごい、本当にしゅごい・・・（ああ嗚呼あaaaa~〜〜〜〜）