I'd like the notion of 'environment' to go away. In that the code shouldn't be making determinations about where its running - the config-management gubbins works out where the DB is or what clients the load-balancer should have, so all the app has to do is ask how it connects to the DB.
That answer would change depending on who (or from where) is asking.
For instance ,you fire up a new instance of a web-server for, er, www.fred.com. The minimal things it needs to know to be able to do some work (helo i am a new webserver can i do some work today? i have the greatest enthusiasm for this project, etc.) is where its traffic comes from and where its database is. (assuming a DB-driven site. It could equally well be the location of some large amount of static data.)
The first thing it ought to do is grovel in the config-db for something like /conf/www.fred.com/database-server, ../database-name and ../database-auth - which should return a JSON packet with enough info for the thing to establish a connection.
At that point, a well-written server could try some example queries or other useful self-testery before...
The next/last thing that should happen is that it registers itself as an available www.fred.com server by (say) writing its IP address into the /conf/www.fred.com/webservers area.
A moderately wonky load-balancer config would subscribe to that key and reconfigure itself to add the new server to the pool, a less wonky one would wait 'til the next Puppet run noticed the config change ditto.
So I guess it just wants some fiddling about with resources and ordering. Probably.
Right, but if there is to be a www.fred.com for testing the flanges feature and a different www.fred.com for testing the intercept trajectories, the two webservers presumably need to identify themselves as 'flanges' or 'intercepts' as well as 'fred.com' when they go to the config DB.
Hm. Point. There is the case where v1.0.4-intercepts requires an extra column in the DB.
At the moment, the code would just catch fire.
In a less worse world, the self-test code should do something like 'if exists(intercepts-column) then intercepts-enable = 1 else intercepts-enable = 0.
... Which is just feature-flagging.
Hm. So I guess there's a /conf/www.fred.com/webservers/features path.
What do you do when you want to run up one of these configs multiple times on multiple sets of hardware - say, a live and a staging and a load-testing ?
Currently I envisage a different config DB per subdomain, which is how we've managed some other systems that act differently depending on where you ask from. Such that config.stage.fred.com is a different server to config.dev.fred.com is different to config.test.fred.com
That answer would change depending on who (or from where) is asking.
For instance ,you fire up a new instance of a web-server for, er, www.fred.com. The minimal things it needs to know to be able to do some work (helo i am a new webserver can i do some work today? i have the greatest enthusiasm for this project, etc.) is where its traffic comes from and where its database is. (assuming a DB-driven site. It could equally well be the location of some large amount of static data.)
The first thing it ought to do is grovel in the config-db for something like /conf/www.fred.com/database-server, ../database-name and ../database-auth - which should return a JSON packet with enough info for the thing to establish a connection.
At that point, a well-written server could try some example queries or other useful self-testery before...
The next/last thing that should happen is that it registers itself as an available www.fred.com server by (say) writing its IP address into the /conf/www.fred.com/webservers area.
A moderately wonky load-balancer config would subscribe to that key and reconfigure itself to add the new server to the pool, a less wonky one would wait 'til the next Puppet run noticed the config change ditto.
So I guess it just wants some fiddling about with resources and ordering. Probably.
Reply
Reply
At the moment, the code would just catch fire.
In a less worse world, the self-test code should do something like 'if exists(intercepts-column) then intercepts-enable = 1 else intercepts-enable = 0.
... Which is just feature-flagging.
Hm. So I guess there's a /conf/www.fred.com/webservers/features path.
Reply
Reply
Reply
Leave a comment