Practical Technology

Here are some config snippets from the haproxy setup I mentioned in the last post.  Note that if this looks weird, it probably is - our environment is a bit of a mess, but due to constrained test resources, no cleanup is possible. Some organizational helpers I used: IP addresses 'make sense' - for example WEB02-IP2 is 192.168.1.62, -IP3 is .63, etc Keep the naming convention for backends consistent Keep things simple Comments only for the first frontend, first backend, unless actual specific notes required Keep spacing consistent, tabs, etc Frontend Example frontend domain1_com-http bind 192.168.0.50:80 # Subdomains: I put relevant subdomains here (just to keep track) acl is_GKWEB-http hdr(host) -i -f /etc/haproxy/GKWEB-http-urls # Subdomains: subdomain1 subdomain2 acl is_ITF01-http hdr(host) -i -f /etc/haproxy/ITF01-http-urls # Subdomains: subdomain1 subdomain2 acl is_WEB34-IP2-http hdr(host) -i -f /etc/haproxy/WEB34-IP2-http-urls # Subdomains:

This project was something I'd been wanting to do for quite some time, but never had the opportunity.  Well, opportunity kicked the door in, so who would I be to not offer tea & crumpets? I've not had much exposure to load balancers so far aside from 'hey, they are neat' and understanding the basic concepts behind them.  Never had the chance to set one up from scratch, never done actual configuration, etc.  So why not have my first shot be with a pretty complex environment that had been badly maintained for the last 5 years? (they're dropping the contract at any moment, don't bother fixing it up - really) We were moving said environment as a cost-savings exercise and had decided to forego load balancers (it was leaving behind some Stingray LBs) as another cost-saving exercise (we priced out Netscaler VMs at ~$2k each, Riverbed started at $5k).  Should be simple enough to just static-NAT straight to the servers and remove any redundancy (it was a dev envi

Sooo, we dropped Chef from our lineup.  There were a number of good reasons to do so, such as: To properly get the most out of Chef in a Windows environment, you really need DSC (desired state configuration).  We are not using DSC at this time (on the to-do list). We were starting to twist it into doing deployment tasks - this is not appropriate (such as 'stop the AppPool, deploy, start the AppPool'). We found a way to do the same thing via (easy?) Powershell scripts, and modules!  Yes, we have really started having fun.  Not only that, but all of this is in TFS and part of our deployment chain. Another big step is moving all of our pipelines into templates, and introducing a development process around new template features/fixes.  This means that keeping track of pipelines is really easy for us, and much easier for the devs to deal with from a requirements standpoint. Further - we've gotten everyone to agree to a naming convention so our template model works