Dynamically added Wordpress plugins on Kubernetes

If I'm running Wordpress in a Kubernetes environment, whereby the code is part of a Docker image and someone tries to add a plugin through the Wordpress admin, I don't expect that will work very well, as the plugin will only be installed on the container that's hit when they add the plugin, right?

Is my approach of building the code into an image a misstep? Another approach I'd considered was a volume that holds the code, which would handle this use case well. Is there a discussion of such things I could read somewhere?

Assuming that you are required to allow wordpress users to install/upgrade plugins, burning wordpress in a Docker image is not gonna work: either you allow the app to be updated only by distributing a new docker image or you don't. What you want to do allows for app updates to come from two sources.

If you don't have such requirement, just add:

define(‘DISALLOW_FILE_MODS’,true);

to wp-config.php and you are good to go. Make sure that when you upgrade your Docker image with a new version of Wordpress, the database schema is upgraded accordingly and all versions of Wordpress currently in execution can use that db schema.

If you can't disable plugin installation/updates, you need to solve 2 problems:

1) You need to have all containers access the same wordpress installation.

On-disk files in a container are ephemeral, which means when a container crashes, kubelet will restart it, but the files will be lost - everytime you get a clean slate.

A typical solution to this problem is to create a volume just to store your wordpress installation and mount it on all containers in the Pod, like this:

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

More info:

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

2) You need to make the storage of the shared volume reliable/redundant. Kubernetes offers many options that vary depending on where you are running your Kubernetes installation. If you are in a public cloud use whatever that cloud makes available (e.g. EFS on AWS), if you are on-premise you might want to look into glusterfs or if you have an existing SAN use that.

More info on: https://kubernetes.io/docs/concepts/storage/volumes/

Regarding your request for some bibliography on the topic, you will find many documents telling you that your application should be part of the image, e.g. point #7 in:

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

but again, that assumes that the application can only be upgraded/modified by the admin, not the end users. You must contextualize the suggestions that you find on the web to your specific requirements.