Вопрос или проблема
Я пытаюсь настроить развертывание Kubernetes для двух веб-сайтов WordPress в разных подах, каждый будет иметь своё собственное развертывание и сервис и т. д., под одним и тем же ingress. Я настроил ingress следующим образом:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: letsencrypt
nginx.ingress.kubernetes.io/rewrite-target: /$1
nginx.ingress.kubernetes.io/use-regex: "true"
labels:
app: app-1
built-by: kustomize
name: app-1
namespace: namespace-1
spec:
ingressClassName: nginx
rules:
- host: test.sub.website.com
http:
paths:
- backend:
service:
name: wordpress-service-1
port:
number: 80
path: /(.*)
pathType: Prefix
- host: test.sub.website.com
http:
paths:
- backend:
service:
name: wordpress-service-2
port:
number: 80
path: /path/wordpress2(?:/|$)(.*)
pathType: Prefix
tls:
- hosts:
- test.sub.website.com
secretName: app-cert
status:
loadBalancer:
ingress:
- hostname: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.elb.ap-northeast-1.amazonaws.com
Это мой файл Apache:
<Directory /var/www/html>
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
<IfModule mod_negotiation.c>
Options -MultiViews
</IfModule>
Options FollowSymLinks
AllowOverride ALL
</Directory>
И вот так я настроил wp_home и wp_siteurl в моем втором WordPress сервисе wp-config.php:
define( 'WP_HOME', 'https://test.sub.website.com/path/wordpress2/' );
define( 'WP_SITEURL', 'https://test.sub.website.com/path/wordpress2/' );
Я с трудом смог сделать так, чтобы каждый путь “/” или “/path/wordpress2” вел к своему соответствующему сервису, проблема в том, что на втором пути “/path/wordpress2”, когда я пытаюсь получить доступ к странице администратора “test.sub.website.com/path/wordpress2/wp-admin”, она перенаправляет меня на страницу администратора “/”, “test.sub.website.com/wp-admin/”. Я пробовал многое, но это не сработало, не только “wp-login”, но также “wp-admin”, и, я думаю, также при выходе из системы. Есть ли способ исправить это из Kubernetes, используя аннотацию server-snippet? Или, возможно, отредактировать конфигурационные файлы WordPress или Apache?
Есть ли способ изменить перенаправление WordPress, чтобы убрать это поведение?
Редактировать (ВАЖНО): обновил свою конфигурацию. Редактировать 2: похоже, это поведение WordPress, если я получаю доступ к папке, она будет переписываться на корневой путь, если это файл, она не будет, я протестировал это с несколькими существующими папками и новыми созданными, например, у меня есть папка test1, которая действительно содержит index.html внутри, “https://test.sub.website.com/wordpress2/test1” ====> https://test.sub.websie.com/test1″. Как я должен избежать этого поведения?
У меня похожая проблема, но не только с WordPress.
Я заметил, что если вы добавляете путь, скажем, wordpress1, чтобы перенаправить его в ваш под, то WordPress нуждается в доступе к папкам внутри установки и добавляет, например, wp_admin (здесь вы впервые сталкиваетесь с проблемой, когда пытаетесь настроить WordPress), новый URL-адрес не содержит ваш путь wordpress1, и поэтому он не работает.
Это происходит также с Nextcloud.
Сейчас я не могу решить проблему и застрял с использованием NodePort и открытием портов на моем домашнем маршрутизаторе.
Ответ или решение
Разветвлённое развертывание приложений на Kubernetes с многими компонентами и изменениями урлов часто сталкивается с проблемами перенаправлений и путей. Рассмотрим вашу ситуацию: вы развернули два сайта на WordPress в качестве отдельных подов, которые находятся под единым Ingress, с помощью которого вы роутируете трафик по различным путям.
Теория
Проблемы, описанные вами, часто возникают из-за неправильной конфигурации путей и перенаправлений в Ingress. WordPress известен своей строгой зависимостью от настроек URL, особенно если речь идет о конфигурации в wp-config.php, где указаны WP_HOME
и WP_SITEURL
. Это критически важно для корректной работы административной панели и процессов входа/выхода, поскольку WordPress внутренне использует указанные значения для генерации путей и последующих переадресаций.
В данном контексте, ключевая проблема заключается в сбоях перенаправления, когда wp-admin
на втором сайте ведет на административную панель первого сайта. Это, скорее всего, связано с тем, как WordPress обрабатывает и формирует абсолютные URL. Если Ingress переписывает URL неправильно или Apache в вашем конфиге генерирует некорректные ссылки, это может привести к подобным коллизиям.
Пример
Основной конфиг Ingress, который вы разместили, использует правила переписывания с использованием аннотаций:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1
nginx.ingress.kubernetes.io/use-regex: "true"
Это говорит о том, что вы переписываете путь непосредственно в NGINX. Однако, ваш WordPress URL (по wp-config.php
) указывает на /path/wordpress2/
. Когда ваше приложение делает запросы на /wp-admin
, этот путь может интерпретироваться как относящийся к корню, если не учтены все нюансы конфигурации перенаправлений.
Применение
-
Корректировка переписывания URL в Ingress:
Вам необходимо убедиться, что Ingress правильно обрабатывает абсолютные и относительные маршруты. Попробуйте изменить аннотацию
nginx.ingress.kubernetes.io/rewrite-target
:nginx.ingress.kubernetes.io/rewrite-target: /
Попробуйте исключить использование регулярных выражений, если это возможно, для упрощения правил рерайтинга.
-
Редактирование .htaccess и Apache:
У вас уже есть базовый конфиг Apache, однако стоит проверить, нет ли дублированных или противоречащих правил в .htaccess самой подсистемы WordPress.
-
Конфигурация wp-config.php:
Убедитесь, что
WP_HOME
иWP_SITEURL
полностью учитывают корректные пути:define('WP_HOME', 'https://test.sub.website.com/path/wordpress2/'); define('WP_SITEURL', 'https://test.sub.website.com/path/wordpress2/');
Убедитесь также, что в базе данных WordPress ссылки на siteurl и home также корректно отражены в таблице
wp-options
. -
Проверка баз данных и плагинов:
Возможно, что некоторые плагины требуют изменений в конфигурации, чтобы корректно работать в подсетях на одном домене.
-
Изучение логов:
Активируйте логирование запросов на Ingress и Apache. Это даст вам представление о том, какие именно запросы приходят, и какие перенаправления происходят некорректно.
-
Использование server-snippet:
Если простые изменения не помогают, можно попробовать использовать
nginx.ingress.kubernetes.io/server-snippet
для добавления специфичных правил, однако это стоит делать с осторожностью, чтобы избегать потенциальных конфликтов с модулем WordPress.
annotations:
nginx.ingress.kubernetes.io/server-snippet: |
location /path/wordpress2/ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
Решение этой проблемы требует целостного подхода к конфигурированию и тестированию, чтобы убедиться, что все компоненты правильно взаимодействуют друг с другом. Надеюсь, эти шаги позволят вам наладить корректную работу ваших сайтов на WordPress в Kubernetes.