＜環境の復習＞
サーバサイドの開発をAWS Cloud9で行います。
なるべく無料範囲で、ということで、EC2を使用せず、GCP上のGCEに接続します。
ですので、サーバ側開発環境はGCEに立っています。
クライアント側開発は、クロスプラットフォーム開発を行うためにMonacaを使用しています。
ですので、開発中は、MonacaからGCEに接続して、JSONを取得しよう、と考えています。
本番環境は、さくらレンタルサーバにサーバアプリを構築し、Monacaでビルドしたモバイルアプリから接続します。
ここまで、GCE上でWordPressを動作させており、Monacaでデザインの概要を作成しました。
次は、MonacaからJSON取得をしようとしています。
Let’s Encrypt
さて、MonacaからGCEに接続してJSONを取得しようとしたところ、
The page at ‘https://ide.monaca.mobi/’ was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint ‘http://xxx/’. This request has been blocked; the content must be served over HTTPS.
というエラーになりました。
これは、ここまでの調査の中で予期されたエラーなので、では、SSL証明書を導入しましょう、ということになります。
こちら
https://nozomi-hiragi.com/gcd_wp_ssl_support/
を参考に、Let’s Encryptを入れようと思いました。
SSL証明書も無料の時代、すごいなと思います。
ところが。やはり、ところが。
ConfigurationError: Requested name xxx.xxx.xxx.xxx is an IP address. The Let’s Encrypt certificate authority will not issue certificates for a bare IP address.
というエラー。
xxx.xxx.xxx.xxx はGCEで外部公開用に発行してくれているIPアドレス。GCE環境は単なる開発環境と考えているので、ドメイン名など取得していません。IPアドレスでは証明書発行できないんですね。
ということで、このチャレンジはあきらめます。
さくらレンタルサーバの共有SSL
ではどうするかというと、さくらレンタルサーバにテスト環境も立てます。
AWS Cloud9＋GCEでサーバ側開発を行い、コミットしたらさくらのテスト環境に連動し、クライアント側の開発・テストは、テスト環境のサーバに接続して行います。テスト完了後、アプリビルド、サーバアプリを本番環境にリリース、というのが理想の流れです。
さくらのレンタルは無料の共有SSLというサービスを提供してくれていますので、できるのではないかと思います。
https://www.sakura.ne.jp/function/common-ssl/
今日は終わり。
独自ドメインの場合は、自前でSSL証明書を取得する必要があります。
