開発作業
APIの入れ替え
何個かのAPIについて、ローカルでの動作確認が終わったので、サーバー側にも反映させて動作確認を行うことに。
まずは、修正したソースコード一式をGit HubのリモートリポジトリにPushします。
次に、サーバー側ですが、APIの構成自体を変更しているため
一旦、現状動いているAPIを削除します。
「pm2 list」で実行されているAPIを確認。
とりあえず、「pm2 delete all」一旦すべて削除することに。
現状格納しているファイルも削除します。
次にGit Hubに上げたファイルをクローンします。
git clone <Git HubのリポジトリURL>すると、ユーザー名とパスワードを聞かれてきました。
GoogleアカウントでGitHubアカウントを作ったため、パスワードが未設定です。
仕方なく、GitHubでパスワードを設定し、再度試してみることに。
すると今度は、以下の様なエラーが
remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentication failed for 'https://github.com/･･･拙い英語力でも分かる。Git操作ではパスワードの認証がサポートされていないとのこと。
パスワード聞いてきたのに！！
ということで、困ったときのGeminiさん。
Gemini曰くGitHubが2021年よりパスワードによる認証を廃止したとのこと。
現在、GitHubで認証を行うためには
・パーソナルアクセストークン（PAT）を使う
・SSH鍵を設定する
という方法があるようです。
PATはパスワードの代わりになるトークンで、それを使って認証を行う方式です。
パスワードを入力する際にPATを入力すると認証されます。
簡単そうですが、今回は、推奨されたSSH鍵を使って認証を行ってみます。
SSH鍵の認証は、サーバー側でSSH鍵を生成して、GitHub側にその鍵を設定する方式です。
一度設定してしまえば、GitでPush等を行う際にパスワードを聞かれずに済んで開発効率があがるそうです。
（安全性は低いかもだけど、まぁ、サーバー内に入られたら安全もなにもないですからね。）
SSH鍵の設定方法としては
１．サーバーで鍵ペアを作成
サーバー内で以下のコマンドを実行して鍵ペアを作成する。
ssh-keygen -t ed25519 -C "メールアドレス"作成された鍵ペアをcatで確認
cat ~/.ssh/id_ed25519.pub2．GitHubに鍵ペアを設定
GitHubにてサーバーで作成した鍵ペアを設定します。
GitHubを開いて右上のアイコンの「Settings」を選択
左側に表示されたメニューから「SSH and GPG keys」を選択
SSH Keys欄の「New SSH Key」ボタンを選択
表示された入力エリアのKeyに作成したペア鍵を張り付けて「Add SSH Key」ボタンを押す。
以上で、SSH鍵の設定は終わり。
あとは、サーバー上のリソースを展開したいディレクトリで以下のコマンドを実行すればクローンが作成されます。
git clone git@･･･コマンド実行時に「The authenticity of host ‘github.com (20.27.177.113)’ can’t be established.」的なメッセージが表示される場合がありますが
初めてそのサーバーからGitHubに接続する際に表示されるメッセージらしいです。
「この接続先を信頼していいですか？」
と聞かれている状態なので「yes」で続行します。
サーバーにリソースが展開された後は、アプリが実行できるよう以下を行います。
1.「.env」ファイルの反映
「.env」ファイルにはDBやトークン用のパスワード等が記載されているGit上では管理しています。
「.env」ファイルを作成してパスワード等の設定を手動で行います。
2.「node_modules」の作成
ローカル環境で使用していたパッケージがインストールされている「node_modules」もGitでは管理していないため、以下のコマンドで作成します。
npm installこれで、package.jsonに記載されたパッケージ情報を元に「node_modules」が作成されパッケージが一式インストールされます。
SQLの更新
ローカル環境で作ったDBのテーブルを本番環境に反映させます。
最初に作ったCreate文が使えるなら、そのCreate文を使えばすみますが
試行錯誤しながらカラムを追加したり消したり変更した場合
それまでの変更SQLを全部順番通り実施するのは手間ですし、間違いの元です。
実運用をしておらず、データも少ないテーブルであれば
テーブルをDropして、最終的なCreate文を実行するのが簡単で確実。
ということで、ローカル環境で変更したテーブルのCreate文を確認することに。
ローカル環境のDBはXAMPPのMySQLを使用しており
テーブル情報等はphpMyAdminで確認することができます。
･･･どこでCreate文確認ができるんだろう？
業務でいつも使っていたデータベースのGUIツールだと、
構造とかでCreate文を見ることができたので、phpMyAdminでも見えるのかと思ってましたが
画面上には表示されないようです。
phpMyAdminでCreate文を取得したい場合は、上メニューのエクスポートボタンから
テーブル情報をエクスポートする必要があるようです。
一緒にデータもダンプしてくれるので、データ量が多い場合は行数を絞ってエクスポートしましょう。
そうすると、SQLファイルがダウンロードされるので、それを開いてみればCreate文やIndexのSQLを確認できます。
ここまでやって、普通にSQLで「SHOW CREATE TABLE」をした方が速くて簡単かもと気づきました。
phpAdmin上でSQLを実行するした場合、デフォルトだと文字が見切れているので「拡張オプション」から「全文」を選択します。
まぁ、エクスポートしとけばファイルとして保存しておけるメリットもありますし、
SHOW CREATE TABLEを思い出せず、とりあえずGUI操作だけでCreate文を出せるので、
用途や好みですかね。
APIの起動
APIの管理を行うためにPM2にてAPIを起動。
pm2 start src/index.js --name game-api通常のアプリの起動方法である「node 実行ファイル名」では、プロンプトを閉じた時点でアプリは終了しますが、PM2でAPIを起動、管理することで、バックグランドでアプリが動き続けます。
そのほか、「pm2 logs」でログが見れたり
「pm2 list」でAPIの一覧を見れたりできます。便利。
リバースプロキシ設定
APIを外部から安全に使用できるように、リバースプロキシを設定します。
APIで使用しているポート（今回は3001番）をそのまま外部に開放することでも、通信自体は可能です。しかし、そうするとApache側で設定しているHTTPS（ポート:443）の暗号化の仕組みを利用できず、API側で個別にSSL設定を行う必要が出てくるため、手間もセキュリティ上のリスクも増えてしまいます。
そこでリバースプロキシを設定し、443番ポートで安全に受け取ったHTTPS通信を、サーバー内部で動くAPIへと転送する形をとります。
設定は、サーバー内の /etc/apache2/sites-available にある設定ファイル（.conf）に行います。
今回の場合は、対象の <VirtualHost *:443> 内に以下の記述を追加します。
ProxyPass /game-api/ http://localhost:3001/api/
ProxyPassReverse /game-api/ http://localhost:3001/api/これにより、外部から /game-api/ 宛てに来たリクエストが、内部の http://localhost:3001/api/ に自動で転送されるようになります（ProxyPassReverse は、APIからのレスポンスに含まれるURLも自動で外部用に書き換えてくれる設定です）。
この構成にしておけば、将来的にAPIのポート番号を3001から変更した場合でも、このリバースプロキシの設定を書き換えるだけで済みます。外部の利用者はURLを変更することなく、そのままAPIを使い続けることができる点も大きなメリットとなります。
実際に外部に公開されたAPIとして、以下のURLにアクセスすると
「API of kurushoo-rankings is running」と表示さます。
https://www.lab-apps-forest.com/game-api/kurushoo/v1/rankings-health
コメント