{"id":34,"date":"2019-05-21T04:48:00","date_gmt":"2019-05-21T04:48:00","guid":{"rendered":"https:\/\/opstree.com\/blog\/\/2019\/05\/21\/intro-to-packer\/"},"modified":"2025-11-27T16:58:45","modified_gmt":"2025-11-27T11:28:45","slug":"intro-to-packer","status":"publish","type":"post","link":"https:\/\/opstree.com\/blog\/2019\/05\/21\/intro-to-packer\/","title":{"rendered":"Intro to Packer"},"content":{"rendered":"
\n

Packer is an opensource tool developed by HashiCorp to create machine images for multiple cloud platforms like AWS, GCP, Azure or even VMWare. As the name suggests it packs all your software, packages, configurations while baking your machine images. Perhaps Packer is the only tool right now in the market which solely focuses on creating machine images and giving us the ability to automate the machine image creation process.<\/span><\/p>\n

In this blog post, we will learn What Packer does and how it does things. Sounds Interesting!!!! <\/span><\/p>\n

\u00a0<\/span><\/div>\n
\n
What is Packer and Machine Images<\/span><\/div>\n<\/div>\n
\n
<\/span><\/div>\n<\/div>\n
\u00a0<\/span><\/div>\n
“Packer can be used to creating identical machine images for multiple platforms from a single source configuration. Packer is lightweight, runs on every major operating system, and is highly performant, creating machine images for multiple platforms in parallel.”\u00a0<\/span>
\nhttps:\/\/www.packer.io\/intro\/<\/a>\u00a0<\/span><\/div>\n
It does installs and configures the software by using different SCM tools such as Ansible, Chef or Puppet, shell scripts within your Packer-made images. You can either include your scripts in json template itself or you can source it from a file. <\/span><\/div>\n
\u00a0<\/span><\/div>\n
“A machine image is a single static unit that contains a pre-configured operating system and installed software which is used to quickly create new running machines. Machine image formats change for each platform. Some examples include AMIs<\/a> for EC2, VMDK\/VMX files for VMware, OVF exports for VirtualBox, etc”<\/span>
\nhttps:\/\/www.packer.io\/intro\/<\/a>\u00a0<\/span><\/div>\n
\u00a0<\/span><\/div>\n
\n
Why the Heck We Should Consider to Learn Packer!!!!!!!!<\/span><\/div>\n<\/div>\n
\u00a0<\/span><\/div>\n
Consider a couple of scenarios mentioned below:-<\/span><\/div>\n
\u00a0<\/span><\/div>\n
Scenario1<\/span><\/div>\n
\u00a0<\/span><\/div>\n
If you want to have an immutable infrastructure in place. The key guideline behind an immutable infrastructure is that you never modify a running server. If a change is required, you instead completely replace the server with a new instance that contains the update or change.<\/span><\/div>\n
<\/span><\/div>\n
The new server instance is created with an origin image that is built upon or a restored image from a previously defined server state. Version control and tag your images for easy rollback and distribution. Image contains all the application code, runtime dependencies, and configuration\u2013in essence, the state needed for the software to run as expected. You will want to minimize the time required to bake all your required stuff into your image which can be achieved if you have proper tag maintained over your previous release images which can be used as an origin-golden image to bake the new image. The entire process of baking and using images become outstandingly easy by using Packer.<\/span><\/div>\n
\u00a0<\/span><\/div>\n
Scenario2<\/span><\/div>\n
\u00a0<\/span><\/div>\n
If you have autoscaling in place, there must be a requirement to scale up a new serviceable VMs as soon as possible but there are some concerns which spoil your expectations of serviceable VMs in the least time:<\/span><\/div>\n