satoru
Forum Replies Created
-
Posts
-
なぜエラーになってるのかわかりません。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. ループバックリクエストは問題があり、予約イベントの実行に失敗することを確認しました。これについては、現時点での機能制限とさせてください。将来的には解決予定です。解決時期は未定です。
修正を完了しました。
kusanagi-docker コマンドを更新すると、wp-config.phpにWP_DEBUGが複数含まれる不具合は解消します。
kusanagi-ftpdのバージョンを更新し、正しく起動するように修正しました。docker-compose.yml を直接修正し、kusanagi-ftpd のバージョンを 1.0.4-r0 に変更してください。
ftp: container_name: wordpress_ftp image: primestrategy/kusanagi-ftpd:1.0.4-r0 restart: always宮崎と申します。
ご指摘ありがとうございます。- –admin-passwd</br>ご指摘の通り、–admin-pass が正しいです。ドキュメントおよびヘルプを直します。
- –admin-email</br>ここかのタイミングで間違えて消してしまったようです。追加します。
- –-admin_user</br>ご指摘の通り、–admin-userが正しいです。変更を行います。
- —–END DH PARAMETERS—–‘ may not contains whitespace.</br>Macの改行コードの問題の用です。この現象はdocker-compose down/up しなければ発生しないはずです。こちらも修正します
ご指摘の内容は近いうちに修正したいと思います。何かあれば今後ともご指摘ください。
ありがとうございました。nginx の設定ファイルで rootの設定を変更する、もしくは apacheの設定ファイルで DocumentRootの設定を変更することで、別コンテンツとWordPressの公開を切り替えることは可能です。
ただし、この場合別コンテンツ部分とWordPress部分を同時に表示することはできません。別コンテンツとWordPressを同時に表示するには、以下の方法で可能です。
http://www.example.jp というホストで公開するものとします1 kusanagi provision –lamp –fqdn http://www.example.jp contents でLAMPプロファイルを作成、別コンテンツを/home/kusanagi/contents/DocumentRoot へ配置
2 kusanagi provision –WordPress –fqdn test.example.jp http://www.example.jp で公開後のWordPressプロファイルを作成し、WordPress構築これで、www.example.jp にコンテンツ公開し、WordPress部分は test.example.jpという名前のホスト名でアクセス可能になります。
公開ディレクトリ切り替えは、kusanagi setting –fqdn pre.example.jp contents を実施して別コンテンツのホスト名を変更後、kusanagi setting –fqdn http://www.example.jp http://www.example.jp でWordPressのホスト名を本番用(www.example.jp)に変更することで実現できます。
切替前：
http://www.example.jp /home/kusanagi/content/DocumentRoot
test.example.jp /home/kusanagi/www.example.jp/DocumentRoot切替後：
http://www.example.jp /home/kusanagi/www.example.jp/DocumentRoot
pre.example.jp /home/kusanagi/content/DocumentRootKUSANAGIで使用できるページキャッシュには、NGINXの機能を使用するfcacheと、KUSANAGI Pluginで実現するbcache があります。
bcache は、WordPressで生成されるページが対象となるため、WordPressのwp-load.phpを読み込んでいないPHPページはキャッシュされません。bcacheをクリアする場合はKUSANAGIプラグイン画面からキャッシュクリアするか、kusanagi bcache clear を実行してください。
一方fcache では、WordPressのwp-load.phpを読み込んでいなくてもキャッシュされます。
fcache を任意のタイミングでクリアする場合は、kusanagi fcache clear を実行してください。yum update時に、_http.confと_ssl.confをRPMのファイルで上書きするのは
kusanagi-nginx の仕様です。
というのも、このファイルを変更することをあまり想定していなかったためです。たしかに、アップデート時にこのファイルを上書きするのは問題がありそうですので、
次回更新時にはconfigファイル扱いとし、旧ファイルが _http.conf.rpmsave のように
リネームされるようにしたいと思います。自分のConoHaの環境でも激遅になっていたので、調べてみました。
どうやら、ConoHaの1GBメモリのマシンではKUSANAGI標準設定だとswapが頻発していました。
以前はそんなことなかったのですが。手っ取り早く使用メモリ量を減らすために、以下のようにMySQLの設定(/etc/my.cnf.d/server.cnf)を変更し、MySQLを再起動して下さい。
（変更前） query_cache_size = 128M innodb_buffer_pool_size = 384M （変更後） query_cache_size = 64M innodb_buffer_pool_size = 128Mまた、4GBメモリのマシンでも変わらないということは、別要因の可能性があります。
以下の情報があると特定がし易いです。kusanagi status の内容
plugin のリスト(できれば)HHVMを使用している場合、プラグインによっては遅くなります。
その場合は該当プラグインを停止するか、PHP7を使用することを検討して下さい。provision 時に配置される kusanagi-core ディレクトリの元は、
/usr/lib/kusanagi/resource/DocumentRoot/wp-content/mu-plugins
以下のファイルを元にコピーされますので、これを cp コマンド等を用いて復元することが可能です。
mu-plugins ディレクトリに移動して以下のコマンドを実行してください。
cp -r /usr/lib/kusanagi/resource/DocumentRoot/wp-content/mu-plugins/kusanagi-core ./
