諸事情でParseServerを構築する必要にせまられた際のメモ。ParseServerが結構モダン化しており、モダン化に伴いこちらの知識もアップデートする必要があった。ParseServerの構築は2017年ごろにBitnami が提供するParseServerを使ったのが最後で、一から構築サーバーを一から構築することになった。
作業を列挙すると、
- データベースの修復
- セキュア接続の確保
- Blobデータ格納先の修復
- CloudCodeの復元
- プッシュ通知の復元
- 外部との接続
となる。
今回は、4-5について。
CloudCodeの復元
AWSでのParseServerの復元作業でAWSが絡むものは3までで、残ったCloudCodeおよびプッシュ通知復元はParseServerとbitnami のドキュメントベースで完了する。
CloudCode について簡潔に説明するとFirebase Cloud Functionsで記述可能なCloud Firestoreのイベントトリガー のようなものでNodeJS相当でオブジェクトの各種イベント(生成、削除)をトリガーとして処理を記述可能。mBaaSを2010年代に先取りしたParseServerが先鞭をつけその後Firebase Cloud Functionsが現実的な形で落とし込んだというのが正しい。
ParseServer上でのCloudCodeはフォルダに格納したNodeJSのコードでmain.jsにコード記述もしくはインポート対象のNodeJSファイルを指定する。CloudCodeの配置はbitnami のドキュメントを参考に/opt/bitnami 配下にcloudフォルダを作成する。
cd /opt/bitnami
sudo mkdir cloud
管理者権限でcloudフォルダを作成するとSFTPなどでアップロード時にpermissionエラーとなってしまうのでアクセス属性を一時的に変更する。
sudo chmod 777 cloud
SFTPでクラウドコードアップロード後、セキュリティ属性を管理者のみに変更する。
sudo chmod 755 cloud
CloudCodeは配置しただけでは動作しない。/opt/bitnami/parse/config.js にCloudCode設定を記述する。
{
...
"cloud": "/opt/bitnami/cloud/main.js",
...
}
その後、ParseServerを再起動して問題がないか確認する。cloud/main.js の読み込みに失敗するとParseServerの起動に失敗するのでCloudCodeの復元に成功したかの確認は容易なはず。
sudo /opt/bitnami/ctlscript.sh restart
Push通知の復元
プッシュ通知についてはParseServerでAndroid、iOSのプッシュ通知にそれぞれ対応している。iOSのプッシュ通知はトークン認証によるプッシュ通知は未対応のため従来からのp12ファイル(証明書ファイル)を使った認証のみ用意されている。
iOSのプッシュ通知送信時にトークン認証が使えるようになったので調べてみた
p12ファイルについては、Appleの開発者ポータルの、Identifiersから対象アプリの名前を選び、詳細のPush通知で確認可能。復元作業が必要となっている状況であるならば証明書の期限が切れているのは当然ありうるので証明書の期限切れを確認しておく。
キーチェインアクセスからp12ファイルを出力する
トークン認証ではない認証ファイルベースだと1) 開発マシンからCertificateSigningRequestファイルをアップロード、2) アップロード後にAppleの開発者ポータルからcerファイルをダウンロード、3) cerファイルをクリックしてキーチェーンアクセスに認証情報を登録。認証情報をp12形式で書き出す。
ここで話題は脱線し、過去の私がp12形式で出力の際に行った失敗を記しておくと、キーチェインアクセスの出力時に秘密鍵まで選択してp12ファイルを出力してしまい延々とプッシュ通知でができないとトラブルになったことがある。p12ファイルのを出力できるのが私だけ&他にiOSアプリに詳しいものがいないため誰も解決することができるアプリリリース遅延の一因となりひいては担当プロジェクトの仕事失うまで至ったので注意が必要な話でクラシックなアプリほど認証ファイルベースでプッシュ通知を行なっているのでメンテナンス業務などを受け持った場合に、あなたがiOSアプリ担当出会った場合はキーチェインアクセスの操作を誤って仕事を失わないことを願う。
話を戻しp12ファイルの復元に戻る。
p12ファイルの設置とサーバー初期化
p12ファイルを開発機で出力成功した後、PaeseServerにp12ファイルを配置およびサーバーを再起動する。p12ファイルの配置場所は/opt/bitnami 配下にcloudフォルダを作成しp12ファイルを配置する。CloudCodeと手順は同じだが手順を明記する。
cd /opt/bitnami
sudo mkdir cert
管理者権限でcertフォルダを作成するとSFTPなどでアップロード時にpermissionエラーとなってしまうのでアクセス属性を一時的に変更する。
sudo chmod 777 cert
SFTPでp12アップロード後、セキュリティ属性を管理者のみに変更する。
sudo chmod 755 cloud
/opt/bitnami/parse/config.js にプッシュ通知設定を記述する。
{
...
"push": {
"ios": {
"pfx": "/opt/bitnami/cert/product.p12",
"passphrase": "",
"bundleId": "[必須:バンドルID]",
"production": true
}
}
...
}
config.jsの保存(SFTPベースならアップロード)を忘れずに。
その後、ParseServerを再起動して問題がないか確認する。cloud/main.js の読み込みに失敗するとParseServerの起動に失敗するのでCloudCodeの復元に成功したかの確認は容易なはず。
sudo /opt/bitnami/ctlscript.sh restart
CloudCodeおよびp12の復元でエラーが出ている場合は、
''' none /opt/bitnami/parse/logs '''
上記で問題が起きた日付がファイル名に付与されているログおよびparse.logを確認し配置場所の整合性や原因を探してみるとParseServerの情報に行き着くことができるはず。特にbitnami の問い合わせとbitnami技術者の回答が適切なことが多いので参考にすると良い。