[csmuk]

No but updating static routes via puppet/ansible and reloading is a piece of piss.

If your site is volatile enough that the routing needs to change that often then there is something wrong either with your information architecture or your development process.

[floops]

Or maybe you're trying to deal with a huge legacy content migration of several hundred different government agencies and want to deploy several times a day without waiting for 10 minutes for nginx to load 1MB of config each time?

[csmuk]

2 front end nginx boxes s01-s02:

1. take s01 out of pool.

2. migrate config on s01 to new config.

3. put s01 back in pool.

4. take s02 out of pool

5. migrate config on s02 to new config.

6. put s02 back in pool.

Ansible can handle this quite happily. Scales up to any number of boxes. For an (n-1)/n capacity reduction during deployment.

I've got a 450k apache config somewhere that takes <1 second to reload so I don't think that's a major issue.

Also if you have THAT much config, something is wrong with your information architecture (see my other points).

[dylz]

Or the fact that having multi-megabyte configuration files in the first place is in itself somewhat of a horror...

[danpalmer]

The back-end to GOV.UK is designed to be very configurable by non-technical users, and many of their routes are dynamic. While Puppet could be used, the process of automating those edits, then rolling them out to all the servers, but in batches so that no downtime is experienced with restarts, configuring load balancers to be aware of this, etc, etc, the whole process has lots of points that could fail.

It really sounds like a dynamic front-end that is aware of the routes would be a much better idea, far less that can go wrong.

[csmuk]

Allowing non-technical users access to routes is a disaster waiting to happen. The whole thing should have a QA process around it. I'm genuinely surprised it's being run like this.

The biggest point of failure is always humans and you're basically handing them a gun there.