Feature request: support isolated Redis/Valkey databases and ACL users per site

オープン
  • 何か問題がありますか？
#782 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
php, python, redis
領域
backend, cli, databases

調査の方向性

Start with the existing wo site create, wo site info, and --wpredis paths, then inspect how WordPress object-cache settings are generated. Define how database assignment, site-specific ACL users, persistence, and reuse warnings fit together; done means isolated sites receive the selected settings and the assigned database is shown in site information.

索引モデルが issue の本文から書いたものです。

説明

WordOps currently supports Redis object cache, but when running multiple sites on the same server it would be useful to have stronger isolation between sites.

Disclaimers

  • Disclaimer 1: I use Valkey on my server.
  • Disclaimer 2: I have already used a similar isolation approach for PHP-FPM, with separate pools/users per site, and the same idea would be useful for Redis/Valkey cache isolation.
  • Disclaimer 3: I've used AI to generate this proposal, as I'm not a native English speaker. I'm happy to share more details or clarify any points if needed.

Proposal

Add support for configuring Redis/Valkey with:

  • A separate logical database per site.
  • A separate Redis/Valkey ACL user per site.
  • Explicit database selection via --redis-isolated=<number>.
  • Automatic database assignment via --redis-isolated=new.
  • Site-specific credentials in the generated WordPress/object-cache configuration.
  • Persistent ACL configuration so users survive Redis/Valkey restarts.

CLI behavior

Instead of a boolean flag, the isolated Redis/Valkey database could be selected explicitly:

wo site create example.com --wpredis --redis-isolated=1
wo site create shop.example.com --wpredis --redis-isolated=2
wo site create blog.example.com --wpredis --redis-isolated=new
wo site create existing.example.com --wpredis --redis-isolated

Where:

  • --redis-isolated=<number> uses the specified Redis/Valkey logical database.
  • --redis-isolated=new automatically picks the next available database number.
  • --redis-isolated without a value uses the current Redis/Valkey database setting from wp-config.php when present.
  • If --redis-isolated is used without a value and no database setting is present in wp-config.php, WordOps should assume --redis-isolated=new.
  • WordOps stores the selected database number in the site configuration.
  • WordOps shows the assigned database in wo site info.

If a database number is already assigned to another WordOps site, WordOps should warn or fail unless the user explicitly confirms reuse.

Main problem: database number management

One practical issue is choosing the correct Redis/Valkey database number for each domain.

When multiple WordPress sites share the same Redis/Valkey instance, the administrator has to manually track which database number belongs to which domain. This is error-prone, especially when sites are added, removed, or migrated.

WordOps could make this explicit by maintaining a mapping such as:

example.com      -> database 1 -> user wo_example_com
shop.example.com -> database 2 -> user wo_shop_example_com
blog.example.com -> database 3 -> user wo_blog_example_com

ACL persistence

For Valkey/Redis ACL users, WordOps should ensure the generated users are persisted to disk so they survive service restarts.

For example, Valkey/Redis should be configured with an ACL file:

aclfile /etc/valkey/users.acl
aclfile /etc/redis/users.acl

After creating or updating users, WordOps should save the ACL configuration, for example with:

ACL SAVE

Without this, dynamically created ACL users may be lost after a restart, breaking the object cache configuration for sites.

Why this would help

Using separate databases and users would provide better isolation when hosting multiple WordPress sites on one server:

  • One compromised site has less access to cache data from other sites.
  • Cache flushes can be limited to one site.
  • Redis/Valkey credentials can be scoped per site.
  • The domain-to-database mapping becomes explicit and less error-prone.
  • Site migrations and troubleshooting become easier.
  • ACL users survive Redis/Valkey restarts.

Example WordPress configuration

WordOps could configure the matching Redis/Valkey settings for each site:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 1 );
define( 'WP_REDIS_PREFIX', 'example_com:7af0c2:' );
define( 'WP_REDIS_PASSWORD', array( 'example_com_7af0c2', '<<generated>>' ) );
define( 'WP_REDIS_CLIENT', 'phpredis' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );

This is mainly useful for servers hosting multiple WordPress sites, where better separation between sites is desirable.

主要言語
Python
スター
1.6k
フォーク
222
平均マージ
1日 3時間
マージ済み PR（30日）
1

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

WordOps/WordOps のほかの issue

WordOps/WordOps の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。