Team!
We’re about to enter a topic of conversation that, much like everything else in the information technology industry, has hundreds of different ways to be implemented and hundreds of other opinions on the strategy of it. Yeah, you know what I’m talking about. We’re touching on the topic of templates. I recently had a fairly in-depth conversation about this and I decided that I would share my personal opinion and the strategy that I try to adopt where possible.
Why use templates?
If you’ve been around the industry for some time, the answer to this is probably already clear to you. But if you haven’t this one’s for you. No matter the hypervisor, in the virtualization world you have the concept of templates and they are, by nature, the exact definition of the word; a pre-determined, pre-configured (whatever that configuration may be) virtual machine object that you can use as a base line to deploy other virtual machines over and over again. This drastically reduces the time it takes for servers/services to go into service and become usable. Imagine if you had to build a 2, 3, 4, even 8-node web farm all from an ISO installer each time. Ugh! Sorry, that gave me the chills.
Template Strategy
As mentioned, there’s many different approaches to this so I’m going to discuss the one that I favor. I’ve walked into companies who had have tens upon tens of templates – one for Windows Server 2019 Datacenter, one for Windows 2019 Datacenter with SQL 2019, one for Windows Server 2012 just in case, one for this, one for that, and the list went on and on. There are some instances that you cannot avoid having additional templates. For example – in the event that you have use cases for Windows Server Standard and Datacenter. That’s two templates – no way around it. Server Core versus GUI-based (although it is possible to add/remove components to swap between Windows Core and GUI), vendor requirements, might warrant additional templates. As a technology department, determine your supported OSes. If you have apps running on 30 different Linux distributions then that should raise a flag to spark a conversation around standardizing. My rule of thumb – deployable OSes are N and N-1, where N is the current release.
My approach to templates is a minimalistic one. I create templates only for what is supported for deployment. Furthermore, from a OS-level configuration I make very, very basic modifications to the installation which include moving the page file, patching, and installing VMware Tools. This is where I usually find myself in a debate. “Why don’t you just bake all of the modifications into the template?” can be really answered with word, but I will give you three…
Flexibility
If I bake all of the configuration items into a template I cannot be as flexible as I want or might need to be. With the vanilla base line approach, I can turn this template literally into anything – an IIS server, SQL server, print, file, you name it. I have a blank canvas and can layer on security, application configurations, and standards as I build up. The alternative method would probably entail me peeling back certain configurations for certain scenarios.
Manageability
The more templates you have, the less manageable they really are and the more room for error and inconsistencies you introduce. Imagine creating X amount of templates for different reasons and you forgot to add something to the templates. Guess who’s re-touching all those templates? And think about keeping them all up to date with patches. The more templates you have, the more time you have to spend managing them bottom line.
Security
If one of your templates has an OS-level vulnerability, then chances are all template of the same OS do too…and now we get to remediate ALL of them. As I mentioned earlier under ‘Manageability’, the more templates the more room for error and inconsistencies. This can have a correlation to security risks. While we’re on the subject of security, your templates are your single sources of truth for your server build and should be treated and guarded as such. A breach of these could introduce a whirlwind of problems for your department and and company. With that said, don’t keep them online and accessible via the network. Power them off, store them AS a template, restrict management access to the objects, and put alerts on them whenever they are converted from templates to virtual machines.
Many Ways to “Skin a Cat”
I’ve already explained to you that I choose a minimal amount of templates with minimal configuration of said templates. So how do I build these templates up to become the end product that they need to be? Automation of any (and probably every) type. I’ve helped companies by using Ansible, Terraform, vRealize Automation, and even just basic PowerShell scripts to standardize and secure their deployments. In the future, I’ll put together a follow-up post to show how we do things over here in the Dirmann Technology Consultants lab environment. We’ve shown the value of it to a lot of companies and replicated it (with some custom tweaks here and there) on multiple occasions. If you’re interested, please feel free to hit me up on LinkedIn or Twitter and let’s talk more about your template strategy and how to improve it.
Thanks for reading. If you enjoyed the post make sure you check us out at dirmann.tech and follow us on LinkedIn, Twitter, Instagram, and Facebook!
Paul Dirmann (vExpert PRO*, vExpert***, VCIX-DCV, VCAP-DCV Design, VCAP-DCV Deploy, VCP-DCV, VCA-DBT, C|EH, MCSA, MCTS, MCP, CIOS, Network+, A+) is the owner and current Lead Consultant at Dirmann Technology Consultants. A technology evangelist, Dirmann has held both leadership positions, as well as technical ones architecting and engineering solutions for multiple multi-million dollar enterprises. While knowledgeable in the majority of the facets involved in the information technology realm, Dirmann honed his expertise in VMware’s line of solutions with a primary focus in hyper-converged infrastructure (HCI) and software-defined data centers (SDDC), server infrastructure, and automation. Read more about Paul Dirmann here, or visit his LinkedIn profile.
