Building OCI Custom images with Packer
April, 2019
Building and deploying applications in a cloud can be time-saving and easy, but getting all the value offered requires finding the best tools to solve your particular problem. Nearly two years ago, I found tools from Hashicorp’s Packer and Terraform, which were easy to pick up and have high levels of utility. The idea of “infrastructure-as-code” and “declaratively built” images appealed to me in both cool factor and simplicity.
Terraform is another article and workshop (there is a hands-on workshop that can walk you through building packer images available here), but in short: Terraform can build the network and stand up/keep up images and services in the cloud. Packer is the tool to help you build those images.
Packer lets you define images as code, simple JSON.
From that simple JSON, you can build custom images in various environments (clouds, Virtualbox, VMWare, KVM) which will include the same configuration defined in the JSON. This might be adding packages, users and data. It might be configuring a desktop or adding a service for something like the mail subsystem, mySQL database or wordpress hosting.
Baking vs Frying
While we’re not making dinner, building images is analogous to cooking a dish. Hardware, ingredients, and techniques are all flexible to accommodate a variety of approaches. When building images for the cloud, most of the time, it makes sense to automate/orchestrate the build of the image. That build process generally looks something like :
ISO Image (base OL, Ubuntu, CentOS or RedHat iso) to start an Instance → custom scripting (Ansible, Chef, cloud-init) → Running Custom Instance
The above flow is the model which looks most like Frying. Start with a Pan (base image) add your ingredients, customize with scripting (which might include: Chef, Ansible, or scripted yum installs/updates) and your product is dinner. For each similar image, it will download the same components, run the same scripts and create a new custom instance — taking all the time it took to cook the first. This is acceptable if the pieces are small (simply package installs and some config files), but in cases where your end-state is complex, large (in footprint) or the software install requirements grow to several Gigabytes, this starts to cost much more in terms of both TIME and BANDWIDTH.
One customer used the Linux rsync utility to copy just over 20GBs in support of their application servers. Starting 5 such servers simultaneously would use over 100GBs of network traffic from their rsync server to the new spawned instances.
The anti-pattern to this would be to build ONE custom image from which to start, load everything needed (copy the 20GB via rsync for example) and then start 5 copies (instances) of that custom image. The difference is subtle, but can be important in terms of set-up time and overall velocity of deployment.
The idea here is to “bake” and image upfront to use as needed. It might not be a black and white contrast between the two as you might want to “bake” and image with the largest, longest running components installed, but then do minor customization after booting the pre-baked image. Using common sense and using the best approach is up to the reader.
Packer is a great tool for Baking. It can help you in your kitchen (on-prem datacenter or laptop) as well as the cloud kitchens of Oracle, AWS and Google.
Packer
Packer can be run on your laptop, server or any cloud infrastructure server you may have access to. It installs https://www.packer.io/intro/getting-started/install.html quickly and takes very little in terms of resources. Building your first image can be done in about 15 mins (see Build OCI images using Packer) for a trial account and instructions on get some basic images built.
Hashicorp’s Packer automates the building of machine images with a template approach containing several parts, it requires a builder and a provisioner.
By changing the “builder”, you choose where you want to place the resulting asset (image/VM)
You define your “Builder” :
- Where you want it to build and deploy (Virtualbox,AWS,OCI,etc.)
- What image you’d like to build on (RedHat, CentOS, anything you can reach)
- Your cloud specifics (availability, data center, credential info)
Next, you define a “Provisioner” which is the essence of the custom environment, it can include:
- file — a file you’d like to include
- shell — scripts to be run interactively on the server being built
- shell-local — script to be run interactively on the server which packer is being run
- Other orchestration provisioners — ansible, chef, powershell (windows), puppet, salt.
While container-native develop is gaining popularity, there is still and need in the foreseeable future for what amount to VMs. Either in the cloud or the datacenter, making these VM images easier to build and maintain using automation is a key to having them fit comfortably into our standard DevOps practices. Learning Packer adds yet another tool to the toolbox.
Start your free trial and guided tutorial today!
- Request a Cloud Trial
- Access the lab guides at http://go.oracle.com/packer-oci
- If you need technical assistance or would like an engineer from our Cloud Solutions Hub to guide you through the workshop you can request a Cloud Coach from http://go.oracle.com/cloudcoach.
