satoru
Forum Replies Created
-
Posts
-
念のため、以下の項目についてもお教えください。
– docker version の実行結果
– docker-compose version の実行結果
– WP プラグインをインストールしようとした方法xcrun: error が発生するのは、MacOS X 独自の問題です。
google で検索すると、xcode-select –install を実行すると解決するようです。
https://ysko909.github.io/posts/xcrun-error-after-macos-update/primestrategy/kusanagi-nginx:latest というイメージは、現在作成していません。そのため、このようなエラーが発生します。以下の手順で、各イメージの最新バージョンを取得して、provision できます。
1. ~/.kusanagi/update_version.sh を実行し、最新のイメージを取得してください。イメージの最新バージョンは、~/.kusanagi/lib/image_versions に書き込まれます。ここで、最新のイメージの取得に失敗すると、primestrategy/kusanagi-nginx:latast と表示されます。
2. kusanagi-docker remove media.test.com でディレクトリ削除してください
3. 再度 kusanagi-docker provision を実行してみてください。もし、手順1で バージョンがlatestとなるときは、一度以下のコマンドを実施し、最新イメージを取得できるか確認してください。
git pull primestrategy/kusanagi-nginx:1.23.2-r0
その理解であっています。
基本的に、.kusanagi.http を直接編集する必要はなく、kusaangi-docker ssl コマンドを使用してください。念のため、ターミナルで以下のコマンドを実行し、確認してください。
`
curl -k -H ‘host: wp1.local’ https://localhost/
`matsubarah さん
なぜかapache httpdを使用するとhttps接続がうまくいかないようです。今調査中です。
問題なければ、Webサーバとして nginx をご使用ください。または、https接続用のリバースプロキシを設置し、http 80番ポートを利用する方法があります。
そちらの使用も検討ください。kusanagi-docker 1.3.5 のバグで、wordpress:wp-cli をきちんと取得できていませんでした。
いま、1.3.6 を作成したので、もう一度 install.sh を実行し、アップデートしてください。$HOME/.kusanagi/update_versionは、kusanagi-docker provision実行時に使用するイメージを更新するだけです。kusanagi-docker コマンドは、最初のdocker-compose の構成と、WordPressなどの初期セットアップを行います。docker-compose.yml は、自分で修正していただいて構いません。また、docker-compose.yml のイメージを自動アップデートはしません。イメージのバージョンを変えるには、docker-compose.yml 内のイメージ名を手動で書き換えてください。
update_version.shの結果は、$HOME/.kusanagi/lib/.kusanagi/lib/image_versionsに出力されます。各コンポーネントと言ってますが、各Dockerイメージのことでしょうか？
PHPは、PHP7.4、8.0、8.1 の最新バージョンを使用してください。PHP8.1が一番処理速度が早いですが、一部のプラグインやテーマはPHP8.1に対応していないため、PHP8.0の最新バージョン(今現在primestrategy/kusanagi-php:8.0.18-r1)の使用をお勧めします。
nginxは、nginx1.21(primestrategy/kusanagi-nginx:1.21.6-r5)が一番処理速度が早いと思います。RoDで使用する各Dockerイメージは、脆弱性の対処のため週単位でアップデートします。随時更新することをお勧めします。
ftpを使った更新についてですが、最新版のkusanagi-docker で構築した環境では再現しませんでした。別名のWordPress環境を構築し、docker-compose.yml を比較すると参考になるかもしれません。
なぜエラーになってるのかわかりません。wordpressディレクトリに移動し、以下のコマンドを実施してください。正常ならば以下のパーミション、ユーザ、グループになっているはずです。
$ docker-compose exec httpd ls -l /home/kusanagi/wordpress total 20 drwxr-x--- 5 kusanagi www 4096 Apr 6 00:54 DocumentRoot drwxr-xr-x 2 kusanagi kusanagi 4096 Aug 8 2019 settings drwxr-xr-x 2 kusanagi kusanagi 4096 Apr 6 00:54 tools drwxr-xr-x 4 kusanagi kusanagi 4096 Aug 8 2019 wp-config-sample -r--r----- 1 kusanagi www 3561 Apr 6 00:54 wp-config.phpあとは以下コマンドで、使用しているDockerイメージを更新してみてください。
~/.kusanagi/update_version.shこちらで試したところ、Docker version 20.10.14と、docker-compose 1.29.1 および 2.4.1 の組合せでは再現しませんでした。
rm: remove 'wp.sh'? y
というメッセージは、コンテナ内で同じユーザのファイルを削除しているだけなので、本来は出ないはずです。
念のため、docker のバージョンをお教えください。また、以下のように実行するとデバッグメッセージが出力されるので、こちらもお教えいただけると幸いです。
bash -x kusanagi-docker provision --fqdn wp.localhost wordpressPHPの高速化に関しては、PHP8.1 + WordPress 5.9 移行を使用することで解決済みです。
Certbotの使用に関しては、どうしても証明書更新処理をcronなどで実行することになります。docker-compose内ではcronのような運用できないため、どうしてもホスト側での処理が必要になります。
本番環境で docker-compose で必要かという部分が不透明だった(開発時点では、docker-compose の存続状況が危ぶまれていた)ため、その処理の実装を行っていませんでした。要望があるならば、作成してみようと思います。これらの現象は、すべて KUSANGI RoDの内部SSLポートが8443で有ることに由来します。
dockerでは、セキュリティの観点からroot権限でのプロセス実行は避けるべきとされています。KUSANAGI RoDもその基準に則り内部プロセスをユーザ権限で動作させています。80ポートや443ポートは、root権限でのみLISTENできるポートのため、RoDでは8080/8443 を使用し、外部にフォワードするときだけ80/443 に変更しています。
このため、phpから443 ポートをLISTENしても応答がありません。
1. REST APIですが、RoD外部からのREST API接続には問題ありません。php自体からのREST APIに問題が発生する可能性があります。しかし、ブロックエディタの挙動を確認すると、特に問題なく編集・投稿できています。
2. ループバックリクエストは問題があり、予約イベントの実行に失敗することを確認しました。これについては、現時点での機能制限とさせてください。将来的には解決予定です。解決時期は未定です。
