WordPressのサイトヘルスでREST APIとループバックのエラーが発生した話

WordPessのサイトヘルス画面で『致命的なエラー』が2件発生していたので確認したら、以下のエラーが発生していました。

エラー: cURL error 7: Failed to connect to <DOMEIN> port 443: Connection refused (http_request_failed)

私の環境は、組織のDNS → 下部組織のDNS → Nginxリバースプロキシ → WordPress(Dockerコンテナ)という構成だったため、どこで443エラーが発生しているのかわからず、1週間以上原因究明をしていました。

結論として、Dockerコンテナ内の /etc/hosts に『ドメイン名→リバースプロキシIPアドレス』を追記したら解決しました。

原因として、おそらく以下のことが発生していました。

  1. WordPress内から(自分サイトの)ドメイン名でcURLをした際に、一度WANを出て戻ってくる。
  2. 外のネットワークから来たパケットだけど、ネットワークインタフェースは内側ネットのものだから、ルーターがGUIの管理者画面に飛ばしてしまう。
  3. ルーターの管理者画面は基本的に80ポートを受け付けて443ポートは拒否する。
  4. この拒否が、上記のエラー内容

という感じでした。運悪く私の組織で使用しているルーターでは、GUI管理者画面のポートを変更することができなかったため、ポートフォワードの解決は難しかったです。そのため、WordPressサービスが動くホストの /etc/hosts でサービスドメインをリバースプロキシに飛ばすことで、そもそも外に出ない構成に変更しました。

(これが正解かわかりません)

/etc/hosts
#wordpress
192.168.xxx.xxx    www.<domein>.com
↑これはリバースプロキシのプライベートIP

こんな感じ

これでなんとかループバック処理は解決しました。

Nginxを挟んでいるWebサービスで画像アップロードに詰んだ話

WordPressで画像をアップロードしようとしたら、次のようなエラーが発生した。

サーバーが画像を処理できません。このエラーは、サーバーが忙しいか、タスクを完了するために十分なリソースがない場合に発生します。

1週間以上の格闘の末、やっと解決しました。

Webで調べても上位レイヤーの話しかしてなくてイライラしてました(WordPressをログインし直しましょうとか、小さい画像にしましょうとか)

 

私の場合、原因はWordPressの前に設置しているNginxのリバースプロキシが問題でした。

リバースプロキシのconfに以下を追記します。

server {
    ##省略
    client_max_body_size 1024M;
}

これでnginxを再起動。

そもそもnginx側でパケットサイズ?ファイルサイズの制限をしているのを知りませんでした。。

もちろんこの後でWordPress(PHP)側のファイルアップロードサイズ等の設定をphp.iniで変更する必要があります。
こっちは有名な話なので、対策してる人は多いと思いますが、nginxは見落としていました。。知識不足ですね。

WordPressテーマの作成にあたって

WordPressのテーマ作成を行うにあたって、最低限必要な要素を作りました。

GitHubリンク

WordPress上ではPHPで記述する必要があります。その中でWordPress専用の関数が提供されています。
その関数のリファレンスについては、オンラインドキュメントである WordPress Codex に紹介があります。

Laravel sailでよく使うコマンド備忘録

サービス立ち上げ(テスト)
./vendor/bin/sail up -d

サービスダウン
./vendor/bin/sail down

マイグレートの実行
./vendor/bin/sail php artisan migrate

モデルとマイグレーションを同時実行
./vendor/bin/sail php artisan make:model SampleModel -m

マイグレーションやり直し (初めてでも使えるから基本コレ)
./vendor/bin/sail php artisan migrate:fresh

マイグレーションの確認
./vendor/bin/sail php artisan migrate:status

コントローラーの作成
./vendor/bin/sail php artisan make:controller SampleController

シーダーの作成
./vendor/bin/sail php artisan make:seeder SampleTableSeeder

シーダーの実行
./vendor/bin/sail php artisan db:seed –class=SampleTableSeeder

ヤマト運輸ハッカソンにて総合優勝をいただきました。

2021年11月に開催されたヤマト運輸ハッカソンにて総合優勝、メンター特別賞、オーディエンス賞を受賞しました。

イベント概要

ヤマト運輸ハッカソン 社会課題を解決せよ。 〜ヤマト運輸とSDGsに挑戦!〜

開催日:2021.11.27 – 11.28 (SAT-SUN)

優勝記事

【イベント実施レポート】理系大学生・大学院生向け「ヤマト運輸ハッカソン」を開催- 理系学生が29名参加、SDGsの課題解決に挑戦する8つのサービスを開発 –

ヤマト運輸/理系大学生・大学院生向けハッカソン開催 -LNEWS-

macOSのtopコマンド備忘録

今回紹介するコマンドの名前

top (プロセスに関する情報をソートして表示するコマンド)

パラメータの説明

オプション 説明
-a -c と同じ
-d -c と同じ
-e -cと同じ
-c <mode> a … Accumulative(累積)モード。 topを起動してからのCPU使用率とCPU時間を累積的に計算する。
d … Delta (デルタ) モード。 前回のサンプルからのCPU使用率を相対的に計算する。このモードでは、デフォルトでメモリオブジェクトマップレポートが無効になる。 メモリオブジェクトマップの報告は、-r オプションまたは対話式の r コマンドで再び有効にすることができる。
e … Absolute (絶対) モード。絶対カウンタを使用してイベントをカウントする。
n … Non-event (非イベント) モード(デフォルト)。 前回のサンプル以降のCPU使用率を計算する。
-F フレームワークとして知られる共有ライブラリの統計を計算しない。
-f フレームワークとして知られている共有ライブラリの統計を計算する(デフォルト)。
-h コマンドラインの使用情報を表示して終了する。
-i <interval> フレームワーク(-f)の情報を間隔サンプルごとに更新する。
-l ロギングモードを使用し、標準出力がターミナルであっても、サンプルを表示する。 0 は無限大として扱われる。 再表示するのではなく、出力は定期的に生の状態で印刷される。 最初に表示されるサンプルでは、各プロセスの無効な%CPUが表示されることに注意すること。
-ncols <columns> ロギングモード使用時のカラム表示。 デフォルトはinfinite。 数値が0以上でないとエラーになる。
-o <key> | -O <secondaryKey> keys: pid (default), command, cpu, cpu_me, cpu_others, csw,
time, threads, ports, mregion, mem, rprvt, purg, vsize, vprvt,
kprvt, kshrd, pgrp, ppid, state, uid, wq, faults, cow, user,
msgsent, msgrecv, sysbsd, sysmach, pageins, boosts, instrs, cycles
-R 各プロセスのメモリ・オブジェクト・マップをトラバースして報告しない。(デフォルト)
-r 各プロセスのメモリ・オブジェクト・マップをトラバースしてレポートする。
-S スワップとパージ可能なメモリのグローバル統計を表示します。
-s <delay> アップデートの遅延時間をdelay-sec秒に設定する。 デフォルトでは アップデートの遅延は1秒。
-n <nprocs> nprocsプロセスまでしか表示しない。
-stats <key(s)> カンマで区切られた統計情報のみを表示する。 有効なキーについては、-o フラグを参照。
-pid <processid> トップにプロセスIDのみを表示する。 このオプションは複数回指定できる。
-user <username> ユーザーが所有するプロセスのみを表示
-U <username> -userと同じ
-u -o cpu -O time と同じ