Update, add, remove plugins, themes or wordpress behind load balancer

It has been a while since this was answered, but I have some thoughts that I thought I would add - having had to take care of this same situation several times over the last few years. It involved several extremely high traffic and high visibility sites that were load balanced with three to four nodes each.

The first thing I did was I wrote a linux script that essentially runs as a cron job twice a day. It checks for available core and plugin updates using the wp-cli tool. It runs on each server that is a node of the LB. It worked (at the time) in conjunction with a plugin that could limit what plugins were updated automatically.

The most recent thing I did was having a staging server that we accessed for content/code changes. The changes on that environment were then synced to whatever live nodes were active at the time. This was done in AWS EC2 instances using RDS for DB. It allowed for relatively seamless updating. We had to do a bit of customization around the DB push in order to preserve production data which had not been synced to our staging environment.

Most of these answers seem to be based on the assumption that you are only running/updating your website on a remote server; and as such, some of the solutions seem very complicated. I have two sites that both run behind load balancers - one with 2 servers, and one with 4; both of which are scalable to as many servers as required. Both of these sites are maintained & updated with a couple of clicks using a local build, Git and Jenkins.

I have a functional copy of the sites on localhost running under XAMPP. The databases aren't identical, but the file structure is. I also have a private BitBucket account and a .gitignore to ignore things like my local wp-config and the /uploads/ folder (which I don't want or need to sync with the server).

Whenever there's a plugin update, I update it through Wordpress on my localhost as normal. Once it's done, I open up my Git client and push the changes to BitBucket.

On the server, I have a Jenkins service that is set to build from my BitBucket source to the live site. I click Build, wait a couple of minutes, and it's all done. Jenkins builds to all servers, and there's rsync available to make sure everything is simpatico.

So my entire update process is Update local -> Git push -> Jenkins build

This is reliant on you having a localhost or other controllable build that you can push with Git, but once it's set up and running, updating your load-balanced Wordpress site becomes incredibly easy.

I have been in this same situation for many years -- 3 servers behind a load balancer. Different disk subsystems. Shared database. I actually found this question by searching for some way to simplify management. What I have been doing (and what has been working fine) for many years is the following:

1. Make sure that I have automatic backups of everything (database and files) ... just in case. I have never needed them, but that is always a prerequisite.
2. Login to the WP admin console and note what server you are connecting to, if possible
3. Update wordpress and plugins using the normal UI methods
4. Login to the server in question (and if you could not tell which it was using some feature of your infrastructure, look at the time stamps of the plugin files that you just updated).
5. Copy the wordpress directory tree to the other server(s)
6. Backup the old WP directories there and replace with the new directories.

This has never failed. However, it is not 100% recommended as WP running on the severs that are not yet upgraded could have issues during the upgrade due to software or database inconsistencies. Usually the process is very quick anyway.

The best solution is to do the above, but by taking the servers you are not updating out of service first and updating them before re-enabling them on your load balancer. I suppose it is up to you where you fit on the "quick and easy" vs "risk" curve for your blog.

This needs to be done in few steps

1. replicate the DB (in case you do not already have one).
2. remove one server from the LB, change its config to point to the "new" DB.
3. connect to the admin area only to that server (define in your localhosts file the IP or any other way and do the upgrade.).
4. In the LB turn the other server off and the upgraded one on.
5. update the plugin on the other server (basically it is enough to update the code)
6. connect the other server to the "new" DB
7. change the LB configuration to enable the other server.

As this is not an extremely quick procedure you should either minimize the number of plugins you use as pure plugins, or try to upgrade as many as possible at the same time.

(I wrote plugin, but it applies to themes and core as well)

This is a fantastic question - I've personally never run into this before, but here's what I'd try, assuming:

• you have an image of a server that you've been using to spin up new instances
• you're using a CDN and cloud storage for images and uploads (rather than having a local uploads folder)

With those two assumptions, it means you can spin up and spin down instances of the server without worrying about data loss - the files and config between each server are identical.

• Spin up a new instance of your server, but don't add it to the load balancer
• point your hosts file to the IP of the instance
• update the plugin on the instance, make sure everything is working as you expect
• create an image of the updated server
• spin up one more instance based on the updated image
• point the LB at the new instances

This is a bit of a painful process, and I think next would also look into automated deployment tools, such as Capistrano, or maybe a service like Deploy.