satoru

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 57 total)
  • Author
    Posts
  • satoru
    Moderator

      今回の指摘から、kusanagi-wp-plugin の 1.3.5 がリリースされました。
      このプラグインを含む、kusanagi RoD の 1.6.7をリリース致しました。
      このプラグインをコピーして、お試しください。

      satoru
      Moderator

        ご報告、ありがとうございます。

        advanced-cache.php は、bcache をON/OFF した場合に修正されるもので、頻繁に再生成されるものではありません。また、こちらでも確認していますが、上記の現象は起きませんでした。

        > ・LOCK_EXを入れることは適切なのか
        > ・または別の問題なのか
        > ・LOCK_EXを入れることはページ表示速度に影響はないかなど(1つのファイルをロックするので表示速度に影響がある可能性有)

        上記に関しては、その修正で問題が発生しないのであれば、そのままご運用ください。
        また、bcache on の場合では、キャッシュしたデータを MariaDB に保存します。phpコンテナへのファイルへの頻繁な書き込みはないため、httpアクセスでの性能問題は無いはずです。

        以上、よろしくお願いします。

        satoru
        Moderator

          fcache の不具合の報告ありがとうございます。次バージョンで修正させていただきます。

          satoru
          Moderator

            docker動作環境知りたいため、以下のコマンドの結果を教えてください。

            docker version
            docker-compose --version
            docker image list | grep primestrategy

            すいませんが、よろしくお願いします。

            satoru
            Moderator

              KUSANAGI Runs on Docker(RoD) に含まれるWordPress用プラグインが古い事がわかりました。
              RoD の 1.6.5 を先日リリースし、プラグインを最新のものに変更しました。
              プラグイン自体の更新コマンドはございません。更新するには、以下のファイルをDocker環境の wp-content へコピーしていただければと思います。

              $HOME/.kusanagi/lib/mu-plugins/

              上記ファイル更新後、現象が再発するようであれば、ご連絡お願いします。

              in reply to: KUSANAGI RoD: オプションが機能しない #1364
              satoru
              Moderator

                ご報告ありがとうございます。

                KUSANAGI RoD でのProvisionは、以下のようにオプションを指定します。

                
                kusanagi-docker provision [options] --fqdn domainname target
                

                お知らせいただいた実行コマンドでは、targetに相当しているtest以降に --wplangなどのオプションを指定しているため、オプションの指定が無効になっています。オプションの位置を変更して再度実行してください。

                以上、よろしくお願いします。

                • This reply was modified 1 year, 1 month ago by satoru.
                satoru
                Moderator

                  ご報告ありがとうございます。

                  ご指摘の通り、always の設定は間違いです。
                  なお、config は、wordpress構成時以外にも、dump/restore などでも使用する、Job的なコンテナですが、毎回起動する必要はありません。

                  この件は、次回のRoDの更新で修正させていただきます。
                  それまでは、手動でdocker-compose.yml を修正して対応してください。

                  以上、よろしくお願いします。

                  satoru
                  Moderator

                    kusanagi-docker config pull/push コマンドでは、既存のボリュームへファイルへを上書きするだけで、削除を実施しません。

                    docker-compose run config sh を実行し、/home/kusanaigi の該当ファイルを削除することで対処してください。
                    お手数ですが、よろしくお願いします。

                    • This reply was modified 1 year, 4 months ago by satoru.
                    • This reply was modified 1 year, 4 months ago by satoru.
                    satoru
                    Moderator

                      RoD では、SSL証明書の登録が可能です。

                      kusanagi-docker ssl --cert 証明書ファイル --key 鍵ファイル

                      ただし、RoDでは Let's Encryptを使用した証明書の更新には対応していません。ご注意ください。

                      satoru
                      Moderator

                        追加情報です。
                        docker-compose で ecs を使用する方法は、つい最近(2023/11)にEOLになったようです。

                        satoru
                        Moderator

                          > wp_などで始まるテーブルが存在する既存の外部のデータベースにはプロビジョンでは接続できないという理解であっておりますか?

                          あっています。kusanagi-docker provision --wp コマンドは、あくまでも WordPress の環境を設定するものです。また、docker-compose では Scale In/Out の機能は実装していません。
                          単純にALB配下にdocker host を追加したい場合は、上位の認識通りで、ディレクトリコピー、docker-compose up -dkusanagi-docker config push を実行します。

                          Scale In/Out を使用する場合 docker swarm を使用する方法があります。

                          https://docs.docker.jp/swarm/toc.html

                          KUSANAGI RoD 作成当時は、docker swarmは廃止の方向だったため採用していません。しかし、現在もdocker swarmは廃止されることなく提供されているため、こちらを使用する方法もあります。

                          また、AWSをお使いの場合、ECS/Fargate を用いてdocker-compose の内容をもとに、環境構築と運用をできるようです。ただし、こちらではこの方法は未検証です。

                          https://aws.amazon.com/jp/blogs/news/automated-software-delivery-using-docker-compose-and-amazon-ecs/

                          satoru
                          Moderator

                            > Nginx のバージョンが 1.25 のときにアクセス不可となることを確認いたしました。
                            > kusanagi-docker provision --fqdn hogehoge.com --wp --nginx1.25 wordpress
                            >
                            > そのため、Nginxのバージョンの違いによる影響がどこにあるのか気になっております。

                            上記の件ですが、こちらで再現しません。疎通方法は、curl -v http://IPアドレス/ で200 OKを返していることを確認しています。
                            すいませんが、どのような方法で疎通確認を行っているか、ご教授ください。

                            > dbhostの情報を追加した状態で途中でスクリプトがエラーになる原因についてご確認いただけると助かります。

                            こちら、指定したデータベースに WordPressで使用するテーブル( wp_ で始まるテーブルすべて)が存在する場合に、WordPressのプロビジョンが失敗するために発生します。データベース内のテーブルを削除してから kusanagi-docker provison を実行してください。

                            satoru
                            Moderator

                              > 追加の質問となるのですが、バージョン 1.5.1 ではfqdnで指定したアドレスにアクセスができていた以下のコマンドが 1.6.1 で実行するとアクセスができなくなる(502 Bad Gateway)事象が発生しております

                              上記現象は、docker-compose を再起動すると直る場合があります。docker-compose の再起動は、wordpress ディレクトリ上で docker-compose down && docker-compose up -d を実行します。一度再起動してみてください。

                              > また、PHP や Nginx のバージョンを指定するフォーマットをご教授いただけますでしょうか

                              上記はバグの可能性があります。調査に少々時間をいただきます。
                              暫定処置としては、docker-compoose.yml の image 部分を修正し、docker-compose を再起動してください。
                              なお、php7.4およびphp8.0 はセキュリティサポートが終了したバージョンになります。新たな環境を作成する場合は、php8.1 以上をお使いください。

                              satoru
                              Moderator

                                > 追加の質問となるのですが、バージョン 1.5.1 ではfqdnで指定したアドレスにアクセスができていた以下のコマンドが 1.6.1 で実行するとアクセスができなくなる(502 Bad Gateway)事象が発生しております

                                上記現象は、docker-compose を再起動すると直る場合があります。docker-compose の再起動は、wordpress ディレクトリ上で docker-compose down && docker-compose up -d を実行します。一度再起動してみてください。

                                > また、PHP や Nginx のバージョンを指定するフォーマットをご教授いただけますでしょうか

                                上記はバグの可能性があります。調査に少々時間をいただきます。
                                暫定処置としては、docker-compoose.yml の image 部分を修正し、docker-compose を再起動してください。
                                なお、php7.4およびphp8.0 はセキュリティサポートが終了したバージョンになります。新たな環境を作成する場合は、php8.1 以上をお使いください。

                                satoru
                                Moderator

                                  報告ありがとうございます。
                                  > wordpress_config_runで繰り返しErrorとなってしまう

                                  これは、以下のエラーの通り、wordpressディレクトリがすでに存在するため発生します。
                                  > mkdir: cannot create directory ‘wordpress’: File exists

                                  一度、kusanagi-docker remove wordpress を実行し、一度削除してから再度実行してください。

                                  > Macbook は前回と同じ状況です。
                                  ここでエラーが出る場合は、bash のバージョンが古いことが原因です。
                                  MacOS Xの場合、OSにインストールているbashのバージョンが古いため、homebrewなどで最新のbashをインストールする必要があります。

                                  上記の件、お試しいただければと思います。

                                Viewing 15 posts - 1 through 15 (of 57 total)