ゼロからGKEにDjango+Reactをデプロイする(9)掃除とまとめ

(8)HTTPS化とロールアウトの続きです。

これで最後です。

まとめ

今回はServiceをfrontendとbackendに分けることでコンテナの中身のアプリケーションはDjangoだろうがGolangだろうが、なんでもOKというような形を実現することができました。管理者機能やテーブルのマイグレーションなどはDjangoにやらせて、API機能はGolangなどに任せることもできるんじゃないかとか思います。Kubernetesってすごいですね。。

残念ながら肝心のアプリケーションに関する実装はまったく進みませんでした。
これからやります。

お掃除

プロジェクトを削除すれば全て消えます。
プロジェクトは残してクラスタだけ削除する場合、予約した静的IPアドレスは削除されません。
下記コマンドで削除してください。

# 静的IPアドレスの削除
gcloud compute addresses delete [STATIC_IP_NAME] --global

はまったところ

KubernetesのキャッチアップとGKEにデプロイしたときにどういう挙動をしているのかを把握していくのに時間がかかってしまいました。GAEの手軽さが恋しいです。

• ヘルスチェックの存在

  ヘルスチェックの存在を知らずローカルで docker-compose up すれば動作するのにGKEにデプロイすると起動せず困りました。
  当初はPodにリバースプロキシを設置しておらず、ヘルスチェック用にviewを追加していました。汎用性も考慮してPod内にリバースプロキシを追加して、ヘルスチェックに対応させました。

• frontendのエンドポイントはどこ？

  Pod内のコンテナ間はDjangoとcloud_sql_proxyのように localhost:PORT で通信できるので,frontendからbackendも同じように web-back:80 のように名前解決して通信できるはずだと思い込んでいました。frontendはクライアントのブラウザで実行されるのに localhost で解決できるはずないですね。。Kubernetesの名前空間やネットワーク周りは未だにはっきりと理解できていません。。

• Kubernetesのリソースの種類

  DeploymentとServiceとIngressが何を意味しているのか、最初はまったくわかりませんでした。
  特にServiceでもタイプによっては外部公開できるのでIngressとServiceの何が違うのか理解するのに時間がかかりました。
  公式のGKEにDjangoをデプロイするチュートリアルではLoadBalancerタイプのServiceの使って公開していて、これをIngress化するように進めていきました。

まだできないこと

• CI/CDの構築もするべきだった

  実際には コード修正⇒イメージ作成⇒Push⇒更新 のサイクルを何度も行いました。
  このサイクルが本当に面倒なのでCI/CDは最初にやるべきでした。
  そのうち記事を書きたいと考えています。

• マネージドなSSLから複数TLS証明書の利用

  正直この辺の仕組みを浅くしか理解できておらず、チュートリアルに沿って「とりあえず対応した」という形なのです。
  複数ドメインをIngressで捌く、みたいな形には適用できていません。セキュリティ面へのキャッチアップがまだまだ薄いです。。

• IngressコントローラーをNginx化する

  HTTPS化できたタイミングで力尽きました。Nginxにすることで細かな設定ができるようなので対応したくて調べたりしましたが、GCEで間に合ってしまいました。

課金について

残念ながらKubernetesはお金がかかります。ノードの数だけVMインスタンスが起動してしまいます。
4日ほどで4000円近くかかってしまったので、この記事を作成したのちプロジェクトは削除してしまいました。
ここまでやっておいて申し訳ないですが、お金かけずにポートフォリオ作るなら無料枠のVMインスタンスで運用した方が良さそうですね。。

以上です。
お粗末様でした。

⇒目次