サーバー環境とローカル開発環境を全くドンピシャ同じにするって、なかなか難しいんです。
もちろん、サーバー側でもDockerを導入して同じコンテナで動作させれば問題はないんでしょうが、
サーバーにはできるだけ無駄なモジュールを入れたくないのと、Dockerをサーバーで運用する時に過去に不思議な挙動を何回か経験したことがあったので、
シンプル構成でのサーバー環境にしているモノも多いと思います。
そして、直近の開発で色々と環境違いによるトラブルがあったので、自己への戒めもこめて備忘録しておきます。
OSライブラリ依存
PHPのバージョンが違う場合に、大規模な計算式による誤差が発生する場合があります。
厳密に言うと、浮動小数点の計算の丸め込み誤差による違いのようですが、
OSにインストールされているlib系モジュールに依存している場合に、そのモジュールバージョンの違いによって誤差が発生するケースがあるんですね。
どうしても開発環境と、本番のサーバー環境の出力数値が合わないので、ChatGPTで色々と調べて発覚した内容です。
プログラムだけをいくら探しても誤差原因が見つからないわけだ・・・
SQLのカラム予約後
ローカル環境では、DockerでインストールされたMYSQLを使っていたのですが、
本番環境では、AWSのRDSは、比較的新しいバージョンを使っていて、本番アップしたモジュールをビルドする時にエラーが発覚しました。
ちなみに、このビルドというのは、独自に構築した処理で、
データベースのテーブルを整えるバッチをビルド処理として登録していて、
何かしらのアップデートがある度に、実行して差分を無くすという内容になっています。
これで、新しく作られたテーブルなどを自動でCREATEしたりUPDATEしたりできるようにしているんですが、
何故かCREATEされないテーブルがあり、ローカル環境では問題なくCREATEされていたので、調べてみたところ、
MYSQLの予約後がバージョンによって違うということがわかりました。
今回該当したのが、以下の２つ
option
あまり使わない命令ですが、以下のようにクエリヒントで使うやり方があったんですね。
使ったことなかったわ！コレ。
SELECT ... OPTION
でも、ローカルのDocker版MYSQLでは、問題なくCREATEできていたんだよね。
lead
これは、MySQL 8.0以降でウィンドウ関数として LEAD() が追加され、そのタイミングで予約語になったようです。
これもローカルMYSQLでは、CREATEできていたので、安心していたんですが、予約後が追加されてトラブったという事で理解しました。
usage
権限管理で使われるので、コレも予約後でした。
GRANT USAGE ON ...
こんな感じ
その他の予約後抜粋
以下の単語に気をつけてテーブル設定をするといいでしょう。
SELECT, INSERT, UPDATE, DELETE, FROM, WHERE, JOIN, ORDER, GROUP, BY, LIMIT, AS, AND, OR, NOT, IN, IS, NULL, TRUE, FALSE, TABLE, DATABASE, INDEX, KEY, PRIMARY, FOREIGN, CREATE, DROP, ALTER, IF, EXISTS
内部パスやWAN経路による差異
よくあるトラブルとして、URLなどでコントロールする仕組みを入れている場合、
開発環境での localhost と本番環境の exsample.com では、意味合いが変わることが多々あります。
SSLの有無だったり、
WAN経由でのパケットの扱いだったり、
ページ読み込み速度も大きな違いがある場合もあれば、読み込みタイミングによるバグを見つけるケースもありました。
ローカル環境で、一度
読み込み速度を遅延させる開発用コンソールの設定を事前にして開発チェックをするのも必要なんだと言うことですね。
あとがき
実は今、自分が会社を起業して、いまだかつてないほどの激忙しモード状態なのです・・・
案件が4つほど似たような締切で混雑している上、
どれも無碍にできないクライアントさんで、自分のことをとても信頼してくれているので、どれも遅延させるわけにはいきません。
今回のようなトラブルで足止めをくらっている場合じゃないんですよね。
とりあえず、こうしたトラブルは学習のタネということで、今後の効率化に繋げたいと思います。
改めて「無知はコスト」を体験した経験でしたね。
0 件のコメント:
コメントを投稿