HashiCorp Packer & Azure Shared Image Gallery

Packer is a another great tool from Harshicorp that can automate the cumbersome image generation process without much hustle. Besides, it paves the way to much more effective automated content delivery (CD) process. You can check this story to understand the overall features of Packer, check this article.

Azure Shared Image Gallery is a perfect place to store VM images given the fact that it can automatically share images across multiple regions / subscriptions while maintaining the versions under the hood. Check this out for detailed explanation of image gallery and its capabilities.

Let me share you one particular example for better understand the Packer and what values it gives to the devops teams.

Generally every operation team maintains a base OS image for VM deployment. Whether it is a Red Hat Enterprise Linux, Ubuntu, Windows or any other flavors, this is the base OS image that can be used for any application after installing required dependencies and application binaries. This base OS image doesn’t change frequently until it is replaced with newer OS version. These are the high level steps carry out by operation teams to manually deploy the application in development or production environment.

• Create a new VM from the base OS image
• Install required components such as java, python, mysql, etc
• Create required data disks, partitions and folder layout
• Install application
• Install security patches
• Test and release for production

This can be a long process in larger organizations where multiple teams have to perform these tasks sequentially leads to several days of effort to get the things done. When it comes to release newer versions of application, ops team will bring down the production apps and reinstall the new app version on the same OS or VM. This could leads to inconsistencies between QA/Dev and Prod environment due to the fact that individual servers are continuously modified for new app releases and break fixes by team members. This isn’t bother much in on-premise environment because these VMs will be up and running for very long time once deployed it.

This manual process is not sustainable in public cloud environment where VMs are charged per every minute and there should be a way to deploy apps quickly and discard them based on demand. You can shutdown the VMs in off peak hours, but there will be still a charge for disks, nic cards. This is where automation tools like Packer comes into picture. Let me describe same scenario with the use of Azure shared image gallery and Packer.

• Base OS image will be stored in Azure shared image gallery(azig)
• Ops team will write a packer build config to generate a new app image with required tools (java, mysqls,etc) and application version
• Packer will be executed (manual or part of CD pipeline) and generates the end image in azig with all the required component to run the apps
• This app VM image can be deployed to Dev/QA environment first and qualify before release to the production

These are one time configuration tasks to be done for a given application. Once you have the packer configuration completed, you can deploy any number of production VM in couple of minutes. This will make sure all the VMs of a given application will maintains in same configuration with consistency across the system. Yes this leads to many versions of OS images but Azure image gallery can be configured to create image store for each app and maintains its images within that container. In other words, shared image gallery avoids the complications of handling multiple OS images. This image generation process can be a part of CD pipeline where you can create new image automatically with new application release.

Here is a example of creating modified VM image with all the application configuration installed. In this example, ansible playbook performs all the post build setup including apps installation and configuration.

In nutshell, above packer config file will perform these tasks in its each configuration section

• Variables — assign variables and their values or you can choose to provide values as a parameter while running the packer build command. This allows you to use the same configuration file for different environments such as production, DR or dev/qa.
• Builders — Azure arm builder will use the base image in shared image gallery and create the new image in the image gallery itself. Actually it creates a managed image first and upload it to the shared image gallery. Furthermore, additional details provided to create the build VM required for image creation process.
• Provisioners — Run Ansible playbook to configure the VM with all the required config and apps.
• Post processors — Delete the manged image created during the process which we are not interested in anymore.

Here are useful tips to fix any issues while setting up the packer configuration.

• Make sure “pyasn1.codec.der” python module is installed in your base OS image. Azure linux agent “waagent” requires this module for image creation.
• If your packer controller host act as the Ansible controller as well, set these values to disable proxy settings. By default, packer will try to create ssh server for ansible connections.
  “use_proxy”: “false”, “user”: “root”
• Add this parameter to the packer build command to troubleshoot any packer errors. It will halt the process if runs into any errors so that you can ssh to the new VM and check the logs for possible errors. Specially inspect the /var/log/waagent.log file for any errors. packer buikd -debug -on- error=ask file.json
• Ensure correct python path is configured in Azure agent service “/usr/sbin/waagent” of base OS

This concludes the story and thank you very much for reading.