Object cache disabled on container start

The plugin is “enabled” by copying the /wp-content/plugins/redis-cache/includes/object-cache.php file into you /wp-content/ directory. In my case I modified the “entryscript” used in my image to copy the file and change ownership on container creation. Not sure if it’s the best practice, but it worked in my case so the plugin is always enabled on container spin up. Depending on how you have your container built, you could also edit the ‘Dockerfile’ to just copy a local object-cache.php file into the image build as well but you’ll have to remember to update that local file if the plugin gets updated.

# Enable Redis Object Cache Drop-in
cp ./wp-content/plugins/redis-cache/includes/object-cache.php ./wp-content/
chown www-data:www-data ./wp-content/object-cache.php

• This reply was modified 6 years, 7 months ago by castle9mm.

Thanks for that! That’ll help me cut further digging short!
I have a script that pulls down publicly available plugins and installs them into the image. I will just add a RUN cp command in the Dockerfile right after the redis plugin installation is complete to copy the file into the wp-content directory. That way i have always the current version in place.

Thanks a lot!

@castle9mm another point i’m not so clear about (being new to redis) is it necessary to provide persistent storage to the redis instance? I run redis in a separate container but have no persistent volumes linked to it, so each time the container restarts, redis starts as if it was fresh out of the box. Is there an advantage in it to have it’s local db persist across container restarts? Doesn’t matter actually where redis sits, same is true for a redis instance running on the WordPress instance.

Thanks,
olaf

@olaflexemo Sorry if I don’t understand. Are you asking if you need to have persistent storage with redis or are you telling me I should be using a persistent store?

I’m not sure about best practices and I don’t have the best redis knowledge, but having persistent storage in Redis for WordPress isn’t mission critical in my case since I’m only using it to store the opcode cache. If the cache is wiped on container creation it’s not a huge loss for me. The sites will still function normally (albeit slower) and the cache will be built back up in a short amount of time.

Redis is a memory store so it can ‘dump’ it’s memory to a time based snapshot so you have some data on a restart. https://redis.io/topics/persistence You could mount a host volume and have redis save it’s snapshot after a certain time or transaction to that volume and have it reload on spin up.

If you’re wanting to add scalability with multiple redis containers, you can look into setting up a redis cluster. If I understand correctly they’ll sync over network so no need for a persistent shared data store in that case either. This is still on my to-do list but I haven’t need to outgrow the single container just yet.

I hope that explains a little bit.

• This reply was modified 6 years, 7 months ago by castle9mm.

@castle9mm Sorry for being unclear… I was not suggestion for you to use persistent storage but was wondering if it’s of any value at all if it’s just being used as opcache.
It can be used as php session store but I believe that WordPress is not using the PHP session store mechanisms but I could be wrong there. In that case I believe persistence might make sense.
I don’t have any persistent storage setup either and use just a single container for it too. But I want to be able to server multiple WordPress instances. They are all running the same site, so I hope it will actually work fine for them to share the same redis instance.

@olaflexemo Yes i have multiple site using the same single redis container. You just define a different ‘WP_CACHE_KEY_SALT’ for each site in their wp-config.php That way they won’t be conflicts. I just use a “siteName1-somerandomstring” for my key salts.

And yes, I have some sites that have multiple containers. As long as the salt is the same in each container, they’ll be able to share the same keys across the different containers.

• This reply was modified 6 years, 7 months ago by castle9mm.

@castle9mm I’m trying to share the redis content between these (horizontally scaled) instances too. So they all use the same KEY_SALT value and they all are instantiated from the very same container image. I’m still working on it though and have other challenges to overcome before I get into testing if a shared redis setup like that will work. But it’s great to hear that this works – thanks! ?? How do you scale the containers, docker swarm or kubernetes or something else?