I am taking a hard look at Docker as my primary local WordPress development environment. I’ve been here before (in terms of checking it out) and generally love the environment. But I have a few details to work through. I will be posting a few questions here and here’s the first one.
I am using the official WordPress image, which by default has a docker-compose file defining two volumes (one for the DB and one for HTML). Anecdotal testing suggests that the performance on my local (Windows) machine, which is a pretty beefy laptop, is much slower using the volumes. This is in comparison to a test I did where I removed the volumes and just had everything in the containers. The difference in performance is very clear, especially on longer processes (restoring a backup, loading a pagebuilder, etc).
One option I am considering is just keeping everything in the containers (no volumes defined) and using a regular backup (UpDraftPlus) to take care of backups (to the cloud). That will cover the persistence I need, while also seemingly offering a much quicker instance. That said, I really like the host-related benefits of using volumes, so want to think this through.
I’d be interested in how others have approached this. Do you see a really significant difference in instance performance when using volumes for WordPress data?
Volumes aren’t a problem in Windows - Docker uses a Linux file system. But mounting a Windows folder into a container can be really slow. It’s best to use a volume for the core WordPress files with a bind mount to wp-content for local development.
Thank you for the response, @craigbuckler. I am actually using the html folder (parent of wp-content) on the local machine, as well as the db folder. That is the default for wordpress:latest in docker hub and seems to work well in terms of persistence (I know you know this, given that you have your course - just documenting my understanding).
I have pretty much all I need (in terms of persistence, editing local files, etc) from the docker-compose file wordpress:latest. It is only the very slow performance that is of concern to me.
Is the suggestion that the docker-compose file (two containers and two local folders used - db and html) not a great way to achieve this on Windows?
Thank you again, @craigbuckler. I really appreciate the suggestions.
I think I need to drill down a little more on the difference between regular Linux volumes and mounts, since it is not clear to me how the WordPress database would be persisted in the suggestion above (or WordPress configuration file changes such as in wp-config).
This is likely just a misunderstanding on my part and I will drill down (as an aside, I have a separate question, elsewhere here, about managing persistence by creating images with Docker commit but that’s a separate topic altogether )
By the way, your course looks very interesting. In the interests of full disclosure, I don’t think it’s for me at this time since I think I’m really quite close to having this as I want to (just a “lightbulb” away :)). I have been using Docker as my primary environment for a while, including using VS Code to edit local Windows files, as per the wordpress:latest docker-compose setup.
But I wish I had found your course a few months ago, as I was working through all this. For anyone else starting out with setting up this sort of environment it looks very interesting and I wish you well with it.
PS: I was looking at the WSL2 option a couple of days ago but, frustratingly, my dev machine hasn’t yet been offered Windows 10 2004 and researching that (how to accelerate availability of that) was another little project I haven’t yet reached.
A volume is persistent Docker-controlled Linux storage mounted into a container. MySQL requires one for DB data and WordPress can use one to persist the core installation files.
A bind mount mounts a host (Windows) folder into the container. Mounting wp-content only means you can edit theme and plugin files in Windows, but the container can still use them. Access to those files is slower, but it’d hardly be noticeable because the majority of WordPress code is running from Linux storage.
If you wanted to change the WP config file, you wouldn’t see it in Windows but could connect to the container shell and edit it in the Linux volume. Changes would persist in the Linux volume.
WSL2 is worth the effort if it’s supported on your PC. Roll-out has been fairly slow.
Thank you, @craigbuckler. After much hassle and troubleshooting (long story there) was finally able to get to Windows 10 2004, which eventually allowed me to install WSL2. The improvement is amazing, particularly in terms of performance. So, that’s my path now.
I have most of this all worked out now, but have a problem setting up debugging from within VS.Code (as described here). But I am making slow but sure progress.
I ended up going through the Windows Insider program, which moved things along. That said, I spent several hours troubleshooting an issue with compatibility checks (failing on an unsigned driver, even after I deleted the driver)…until I realized that the combability checks use a file as a cache for their check. That seems like a weird choice but when I eventually manually deleted this file the compatibility check finally passed and I was able to get 2004 installed.
Sorry to hear that. @ghidley. By the way, although this likely won’t fix the issue, one more note.
I had spent quite some time researching an unsigned binary reported in one of the compatibility check log files. I actually thought that was a blocker and looked at that for a lengthy period of time. I had assumed that the cache file to which I referred was effectively blocking a re-evaluation, especially since deleting that file fixed the issue for me and I was able to upgrade immediately after.
However, I just noticed that - even though I upgraded OK - that unsigned binary is still being reported, so that could have been a red herring after all.
Thanks for this thread @markwill890 and @craigbuckler. I was looking for something to improve my local WordPress installation performance and found this. Running the files from Linux filesystem when using WSL seems the best choice.
)