What tools do people use to manage and install their wordpress sites ? I’ve got a large (by some definition of large) wp multi user installation, that is currently difficult to update and maintain - because of various plugin compatibilities etc … This makes it difficult to upgrade and track security etc… which is a cause of nagging stress etc…
Currently no staging site, though computing resource for that is available now. There are backups though of db and files.
I think I’d like
A way to quickly deploy a copy of the live site and plugins etc to staging.
A way of reproducibly managing changes to staging
A way of pushing the changes from staging back to live so that after acceptance testing it can be consistently and reliably deployed.
Is this a reasonable workflow ? If not, what is ?
What tools are available to do this ?
There is a small team associated with the site, but firstly everyone is quite time poor, and secondly there are a range of skills associated with the team. So something that is very technical but slick may not be a good solution.
I’m pretty sure we can get the team all up to speed with git/ssh though.
At Autonomic, we have been experimenting with Bedrock. We have only used this is on a very small scale of one or two installs but when combined with ansible, it’s pretty easy to manage.
Features
Better folder structure
Dependency management with Composer
Easy WordPress configuration with environment specific files
Environment variables with Dotenv
Autoloader for mu-plugins (use regular plugins as mu-plugins)
Enhanced security (separated web root and secure passwords with wp-password-bcrypt)
Use Trellis for additional features:
Easy development environments with Vagrant
Easy server provisioning with Ansible (Ubuntu 16.04, PHP 7.1, MariaDB)
One-command deploys
There is an Ansible role here that does this for The News Co-op server, but I’m afraid points 2. and 3. are just done manually for this setup.
I’d suggest the approach that Outlandish use with the Bedrock structure, I’m sure @harry or soemone from Outlandish could explain this better than I could.
The goal of this setup is exactly what you say - approaching reproducable builds/deployments.
Getting everything installed by composer is the key thing there (with composer.lock to pin the dependencies), and the bedrock layout makes it easier to manage in version control, etc. Still have to manage uploads and database somehow though.
Also, wordpress site configuration is not covered by those tools, I have looked at https://github.com/danielbachhuber/dictator for that purpose, and we have added that into some projects.
… having said that, it’s not obviously a better approach for all cases and requires some fairly significant mindset changes (e.g. no adding plugins in the admin UI).
The cotech site above has a docker compose setup, but you could also manage bedrock setups with ansible or just plain old scripts.
Plugins/themes are not installed by the mu tenants. They can choose between just a small number of curated ones. Admin staff time and lack of staging means the curation is difficult to do.
Obviously this is not a rocket science problem.
I don’t actually know much about WordPress,
Altering workflows to not use the wp interface to manage plugins etc sounds eminently sensible to me. ( Having a web application that’s got writable access to it’s own codebase sounds like a recipe for disaster ) but it’s also important that there is a low entry bar to any solution because otherwise it’s difficult to get workers in to support the site.
Each site we have is on a different server/virtual server. That makes sense for us as we sell custom themes not hosting, so our assumption is that our users need quite different things that are not already offered in a standard multi tenant environment (such as WordPress.com).
Sorry that’s not get helpful. We would be very interested in aligning a single CoTech approach to WordPress that takes the best of how we each host and develop our systems.
Expanding on this a bit, have you experimented much with containerisation of Wordpress? It seems like you could get most of the benefits of separate virtual servers but with lower overheads.
It’d be much easier however to set up a Dokku instance with a couple of wordpress instances and see if it nets you any benefits over the virtualisation approach, although it won’t scale to multiple servers or give you high availablity or anything. Flynn might work for actually scaling this kind of solution out but I’ve only used Dokku.
We have setup chroots for SSH access for managing WordPress sites, I posted here about this here, this is fine for most the small sites we host and with around 30 sites per 12GB RAM virtual server it means there are the resources to cope with most traffic spikes and to prevent sites impacting on others we have mpm-itk set to limit the maximum number of Apache processes per site and this mod also allows Apache to run as the user which solves security and privacy issues with shared hosting and Apache running as one user (www-data or nobody).
At some point in the future a Docker approach might be an option and although managing all the WordPress code in git makes sense for clients with a decent budget I don’t think it does for most of our clients as they manage the themes, plugins and updates themselves. (Also they need Apache rather than Niginx so that the .htaccess files work, but perhaps a reverse Ngnix proxy in front of Apache would be good to add to the mix someday.)
although managing all the WordPress code in git makes sense for clients with a decent budget I don’t think it does for most of our clients as they manage the themes, plugins and updates themselves.
Yeah, I can certainly see how the chroot solution makes sense in this context. I think as far as Docker goes at least you should be able to use volumes if you want to be able to persist plugin installations and such, although I don’t know how well that works with Wordpress in practice. Maybe something to try at some kind of Wordpress hack weekend.
We have explored deployments of WordPress with a Bedrock layout with dictator, deployed to Kubenetes (well, OpenShift) using S3 for uploads storage, controlled via a GitLab CI pipeline.
You have to be careful with the stateful stuff in Kubenetes as depending on the type of storage, it may only be mountable on one node, and so prevent horizontal scaling with shared storage (see the access modes section at Persistent Volumes | Kubernetes). The s3 upload approach solves that by handling uploads at the WordPress level (as opposed to filesystem level) via a plugin.
I would recommend staying away from using Docker to deploy Wordpress. It’s possible but we had so many annoying esoteric problems. It’s just not designed for it.
