Sure! Here is the blog post based on the information provided, without a title or any additions such as “this article”:
Welcome to Part 4 of the Packer Series! In this part, we will look at putting together all the blocks and files we need to deploy a template. As we have touched upon in earlier parts, we have multiple blocks and files available to us that can be used to make up a complete configuration. We will walk through a complete Source and Build Block here using user-defined variables to complete the build.
In the previous parts of this series, we have discussed the different types of blocks and files that can be used in a Packer template. In this part, we will focus on the Source Block and how it can be used to deploy a Windows 2019 Core template. All values are passed in via variables in this example. You can see this by the ‘var.’ entry against every configuration line. All variables in this example are user-defined variables in a pkrvar.hcl file.
We have configuration for CPU, Memory, and disk sizes for instance, then we also have the WinRM username, password, and timeout values used for connecting to the operating system after it’s been installed, for use with provisioners. You can deploy your template as just a “normal” VM Template in the VM and Templates Inventory by using this line:
Or you can deploy to Content Libraries by either removing the “convert_to_template” option or setting it to false, and replacing it with this:
If you already use Content Libraries, then you are likely going to want to continue to do so. Or, if you have multiple vCenters, you may want to make use of subscribed libraries so you only have to deploy the template once. To go further, you can automatically destroy the original VM after its been uploaded to the Content Library by adding:
And to take it even further, you can add the following to convert the template to an OVF:
A key line to point out in this Windows example configuration is the ‘floppy_files’ option. This option is used to mount a floppy disk with any configuration files or media that you need to reference during the operating system installation. This includes your unattended.xml file, any scripts, and any media or drivers such as VMware Paravirtual drivers for the SCSI controller. Check out Part 2 for more info.
If we were looking at a Linux build, we would see the WinRM options replaced by SSH, like so:
A full list of the different configuration options available can be found here. Now we have defined our source, we want to deploy it using a build block. What’s happening in this block is that we are referencing the source block that contains our configuration based on the name of the source block that we defined earlier, in this case, ‘source.vsphere-iso.win-2019-std-core’. In this example, we also have two provisioners being used once the operating system has been installed. Firstly, the Windows Update Provisioner which installs the latest Windows updates based on any filters you include. In this example, it’s configured to exclude any updates with ‘Preview’ in the title and also to limit it to install up to 25 updates. Secondly, we are making use of the Manifest post-processor. This produces an output that includes information such as build time each time it is run.
All of the above makes up a complete build file that can be deployed with any media or variables you have referenced. The full set of files for this example can be found here.
To give you an example of a non-Windows provisioner, here is a Shell Provisioner for a Linux template:
This executes all scripts that are referenced in the script.files variable. Now using environment variables, nothing really changes. Your build file will look the same; the only differences will be you won’t provide a value for your declared variable and head over to http://packer.io to discover more. In the final part of this series, I am going to try a different content type, video’s! In these, we will run through two end-to-end template deployments using default values for variables, user-defined variables, and environment variables to show how you could use this as part of a workflow. If you have gotten this far, thanks for sticking with me, and I hope you have enjoyed it and found it useful! Cheers!
Copyright © The Small Human Cloud 2024