Packer and Azure:- A DevOps Case Study
Introduction
Azure,AWS,Google provides various kind of Linux and Windows images in market place. Every organizations are having its own standard so it is very much necessary to customize the images based on the client specific requirements , it is also necessary to provide security or harden the images based on CIS standard. So it is very tedious & complex job to manage images in single and multi-cloud environments by maintaining a common standard.The following case study performed on Azure cloud.
Packer
Packer is a well known DevOps tool developed by Hasicorp, which is known is the best and standard candidate to perform this image baking task It’s an ideal tool to use for purposes multiple platforms (AWS, Azure, GCP) from one build template file. At a high level, Packer works by allowing us to define which platform we’d like to create our machine or image for with a builder.
A Packer template contains 4 parts
1. Variable: A variable is name which holds a value. In packer there are two type of variable.
a. User defined Variable:- A variable which defined and assigned (value) by user. The scope of the variable limited to the template.
b. Environment Variable:- A variable which is being assigned and initialized from the DevOps agent or OS environment.
2. Builder: The build section of packer template is responsible for creating images of the respective cloud like for Azure,Amazon,Google
a. amazon-instance
b. azure-arm
c. googlecompute
3. Communicator:- The communicator section is responsible to login to the system and perform operations (executing scripts) to the temporary VMs.Incase Linux Server a combination of shared key generated and incase of Windows, winrm CLI tool need to mention, packer used the communicator for login into the temporary VM and execute the instructions mentioned in provisioner section.
4. Provisioners:- The provisioners are responsible for executing the script/shell-command after the build is complete. There are three type of provisioners
1. Local :- Executing the script which are placed in same directory.
2. Remote:- Executing a script which are placed in Git.
3. Inline:- Executing the OS shell inline command.
Azure Shared Image Gallery:-
Azure share Image gallery is new azure service which provides the facility to host the OS golden Image and share the image in various regions, this way it eliminates the explicit images copy task with various region and it reduces the efforts of maintaining a parity of maintaining the golden image as OS golden Image is the main building block of VM or compute unit of cloud service.
Image Definition:- To host an image in azure shared image gallery an image definition need to create with customize published name. This best practice is to increase the image definition version with each release of image.
The following diagram contains the end to end architectural workflow of packer implementation with Azure Cloud Service.
Image definition Creation:-
The below command will create an image definition (ubuntu-18.04-LTS) ,publisher (Cloudops) , offer (Ubuntu) ,sku (18.04), OS type Linux and imageTags. These mentioned parameters can be customize based on the origination standard
$az sig image-definition create — resource-group PrdRsgAsig — gallery-name prdasig — gallery-image-definition ubuntu-18.04-LTS — publisher Cloudops — offer Ubuntu — sku 18.04 — os-type linux — tags @{“Application Name”=”Azure Shared Image Gallery”; “Application ID”=”APP001"; “Business Unit Name”=”cloudo”; Environment=”Test”; “Live”=”No”}
Packer Image Creation template:-
Following are the packer image creation template snapshot.
Packer Image Template Section 1:-
Description of the packer image Template section 1:
The section 1 of the template contains the following part
Variable:-
This part of the image is responsible for azure service principal details which is having the permission to work as contributor of a subscription. Packer will create a temporary VM in the subscriptions so it must have contributor access , this permission access will be privileged by Azure service principal mentioned in variable section. The variable type mentioned here is user variable, it can be mentioned a environmental variable which need to be initialized in the packer hosted OS environment or inside DevOps Agent.
Builder:- The builder part contains the builder type like azure-arm for azure cloud in this case . along with the Azure marketplace image definition parameters(publisher,offer,sku).
The build will contains the Packer Resource group name along with VNET & subnet details , as it is described earlier packer will create a temporary VM in this place.If the VNET and Subnet are not mentioned packer will create a VM with a public IP which is not recommended as a best parties
Apart from that the builder section also a Azure shared image Resource Group Name, image gallery name and replication region name , here the image will be placed and replicated through shared image gallery service , Ms azure will take care of this replication.
Packer Image Template Section 2:-
Description of the packer image Template section 2:
Provisioners:- This part is responsible for executing the various scripts (example:- hardening, partitioning,base pkg installation ) and commands(system cleaning) .
Once the Image template created properly it can be verified by using the following command , the output of the command will give the details like below
$packer inspect “imgCreation.json”
Output:-
Optional variables and their defaults:
client_id = xxx → This SP need to have contributor access in subscription level
client_secret = xxx
subscription_id = xxx
tenant_id = xxxx
Builders: azure-arm
Provisioners:
shell
shell
If there is no error then image build can be executed with the below command
$packer build “imgCreation.json”
This will create an image and place it in shared image gallery.
Conclusion:-
Packer provides the flexibility with easy readable parameters of json and various cloud integration builder integration , most important aspect in provisioner section it can call any language scripts (bash,Poweshell,Ansible,python etc), so the provisioner remain constant but it can be applied to various cloud as the OS ( Linux,windows) remain common irrespective of cloud.
Generating Images with latest patch every month also reduce the patching effort and remediate the vulnerabilities. Application team can perform the rolling update of the base OS with new releases of the application stack.This will also help to achieve immutable infrastructure in terms of VM related compute unit.