Making Templates on a Scale HC3 Cluster
-
Templating, or making a base image of an OS, is an important means of standardization and speeding up the deployment of virtual machines on nearly any virtualization platform (especially cloud platforms.) Doing this on a Scale HC3 cluster is no different and is very easy.
Before we have any templates we need to make a gold reference VM from which to work. This is a one time manual virtual machine creation process (which can be automated through any usual means: e.g. Kickstart for Red Hat Linux.) We do this like any normal VM installation, by uploading an installation ISO to our Scale media library, creating a new VM and performing an installation.
At this point, once the VM is installed, we could make a template, but generally we are going to want to modify the base image before templating. For example, likely running updates to ensure that our template is fully patched before we use it as a base for other systems reducing the number of patches to download and apply to the resulting VMs. Often we will want to add a root key or local administration account and apply permissions to the base image to make access and administration of the VMs easier and possibly automated for in house scripts or agentless like Ansible. Including standard tools like glances, htop, sysstat, fail2ban or Chef. Enabling a firewall.
Once our template is ready, we simply power it down and then use the clone button to make new VMs from our template. The template itself would remain powered down.
To make templates easier to use on the Scale HC3, I recommend making a tag for them called "templates" and keeping any and all templates in a separate group away from other VMs so that they are easily identifiable. And, of course, designate them by name such as by ending their name with "-template."
-
It would be standard practice to, from time to time, power on a template in order to perform updates and patches so that the base template was as secure and stable as possible and to save additional time in the preparation of resulting VMs.
-
Another typical thing to have added to a base template is applications. In the example above I showed a generic operating system template, like you might make for Ubuntu, CentOS or Windows 2012 R2. But it would also be common to template a fully configured application, such as a Redis node, or NGinx server that could be rapidly cloned and powered on to handle additional workloads either in an application cluster or simply making another server similar to other, existing workloads.
-
This is one grip I have with XenServer. "Templates" are either the templates that come with XenServer which are more presets for the options for the install, or they are the templates that you can create from a VM you've set up. You can append something to the name to show it's different, but you still have to wade through a list of 20 or so templates to find the one you want.
-
@johnhooks said:
This is one grip I have with XenServer. "Templates" are either the templates that come with XenServer which are more presets for the options for the install, or they are the templates that you can create from a VM you've set up. You can append something to the name to show it's different, but you still have to wade through a list of 20 or so templates to find the one you want.
You can tag in the Scale. I tag with "template" as the main group and then it is in a separate group from everything else rather than in with the other VMs.
-
@scottalanmiller said:
@johnhooks said:
This is one grip I have with XenServer. "Templates" are either the templates that come with XenServer which are more presets for the options for the install, or they are the templates that you can create from a VM you've set up. You can append something to the name to show it's different, but you still have to wade through a list of 20 or so templates to find the one you want.
You can tag in the Scale. I tag with "template" as the main group and then it is in a separate group from everything else rather than in with the other VMs.
Ah after looking you can do that with XO.
-
Another important aspect of a template is that you can have someone with access to the "master" root password set it once and then never need it again and no need to share it. You provide access through keys, root keys or sudo or whatever, and have this built in so that a password is never needed. This increases security and efficiency immensely. This fixes some of the complexities of the break-glass system.
-
Another thing that we have done with our templates at the NTG Lab, we have added our ELK FileBeat client into the template so that any machine created with the template will automatically send log files to our ELK server upon creation. This speeds up new system creation, increases standardization, reduces the chance for error and just makes everything that much easier.
Of course it does not have to be ELK, you could include logging capacity for Splunk or Loggly or similar service just as easily.
-
And adding Topbeat too, to send performance information to the ELK system as well.
