Назад | Перейти на главную страницу

Динамически добавляемые плагины Wordpress в Kubernetes

Если я запускаю Wordpress в среде Kubernetes, где код является частью образа Docker, и кто-то пытается добавить плагин через админку Wordpress, я не ожидаю, что это будет работать очень хорошо, поскольку плагин будет только установлен на контейнере, который попадает, когда они добавляют плагин, верно?

Является ли мой подход к встраиванию кода в изображение ошибкой? Еще один подход, который я рассмотрел, - это том, содержащий код, который хорошо справился бы с этим вариантом использования. Могу ли я где-нибудь прочитать обсуждение таких вещей?

Предполагая, что вы обязательный чтобы пользователи WordPress могли устанавливать / обновлять плагины, запись Wordpress в образ Docker не будет работать: либо вы разрешите обновление приложения только распространяя новый образ докера, или нет. То, что вы хотите сделать, позволяет получать обновления приложений из двух источников.

Если у вас нет такого требования, просто добавьте:

define(‘DISALLOW_FILE_MODS’,true);

в wp-config.php, и все готово. Убедитесь, что при обновлении образа Docker новой версией Wordpress схема базы данных обновляется соответствующим образом, и все версии Wordpress, выполняемые в настоящее время, могут использовать эту схему базы данных.

Если вы не можете отключить установку / обновление плагинов, вам необходимо решить 2 проблемы:

1) Вам необходимо, чтобы все контейнеры имели доступ к одной и той же установке WordPress.

Файлы на диске в контейнере недолговечны, что означает, что при сбое контейнера kubelet перезапустит его, но файлы будут потеряны - каждый раз, когда вы получаете чистый лист.

Типичное решение этой проблемы - создать том только для хранения вашей установки WordPress и смонтировать его на всех контейнерах в модуле, например:

volumes:
  - name: wp-webroot
    emptyDir: {}

- name: wp-container
    image: wp
    volumeMounts:
    - name: wp-webroot
      mountPath: /var/www/html

- name: wp-container2
    image: wp
    volumeMounts:
    - name: wp-webroot
      mountPath: /var/www/html

Больше информации:

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

2) Вам необходимо сделать хранилище общего тома надежным / избыточным. Kubernetes предлагает множество вариантов, которые различаются в зависимости от того, где вы запускаете свою установку Kubernetes. Если вы находитесь в общедоступном облаке, используйте все, что это облако делает доступным (например, EFS на AWS), если вы работаете в локальной среде, вы можете изучить glusterfs или использовать это в существующей SAN.

Больше информации на: https://kubernetes.io/docs/concepts/storage/volumes/

Что касается вашего запроса на библиографию по теме, вы найдете множество документов, в которых говорится, что ваше приложение должно быть частью изображения, например точка № 7 в:

https://developers.redhat.com/blog/2016/02/24/10-things-to-avoid-in-docker-containers/

но опять же, это предполагает, что приложение может быть обновлено / изменено только администратором, а не конечными пользователями. Вы должны адаптировать предложения, которые вы найдете в Интернете, к вашим конкретным требованиям.