What is the Packer

Introduce yourself briefly

Packer is a lightweight command-line tool that runs on almost all major operating systems.

Given a configuration file, Packer can create cloud host images for a variety of systems architectures. Packer can also create multiple images concurrently, which greatly saves the time cost during image creation.

Why Packer

Why is that?

There are, of course, many benefits to using prefabricated images, most simply to maximize service consistency across machines (which is empirically important). However, in practice, mirroring has not been fully popularized in many cases due to the tedious and complex task of creating/managing it.

Existing tools for automated image creation are either difficult to use or inconvenient, or have a steep learning curve. These characteristics cause operations teams to put too much effort into the use of mirrors, which can hinder productivity and agility. This is why mirroring, despite its many advantages, has not been widely adopted.

Packer can create images in pipeline + concurrent mode based on a single configuration file. Compared with traditional manual operations, its “Infrastructure as Code” working mode also greatly reduces the probability of errors.

In Packer’s official opinion, at least:

Packer brings pre-baked images into the modern age, unlocking untapped potential and opening new opportunities.

Infrastructure as Code works

Before the idea was proposed, the manual + script approach was common, manual error prone, and the script itself required a lot of manpower to maintain. At the same time, some mainstream cloud vendors are also actively looking for more possibilities. In April 2019, after we released the Terraform-provider-JDCloud plug-in, some teams are using the Jdcloud plug-in of Terraform. Some will leave issues on Github, and some will express their hope to add more functions through messages. The performance of the users has proved the reliability and agility of the “Infrastructure as Code” working mode.

When it came to Packer, these characteristics were still preserved. Compared to the traditional approach, IaC is considered to be: “Modern and Automated”, also a simple JSON configuration file, IaC encourages developers to start using images, while using Packer to automate and streamline image management, thereby reducing the burden of image management itself.

This section describes daily application scenarios

  • Continuous delivery – Packer&Chef&Puppet: Packer is a possible choice to be put directly into the assembly line and become a part of the assembly line due to its lightweight characteristics: The pipeline is triggered when the Chef/Puppet configuration changes, and the next Packer is responsible for generating images for the new configuration, which can be tested immediately and deployed to production once the test passes.
  • Hybrid cloud usage: One Packer configuration can generate images for multiple cloud service providers. Assuming you use VMWare as a development environment and AWS as a production environment, Packer can generate two images concurrently for both cloud service providers, minimizing the differences between the two images.

In more detail, Packer also contains these advantages

  • For the processing of temporary products: Packer can create some temporary resources for you, for example, in the case of no specified subnet, Packer can help you create a temporary subnet for the cloud host. And it terminates the task when an error occurs, while cleaning up the intermediates automatically. In the traditional way, you need to create a temporary subnet and manually clear the subnet if an error occurs.

  • Traceability and location of problems: All changes on Packer are based on code, and the code can be traced, which is convenient to quickly locate problems and roll back. In the traditional way, it is not easy to catch the problem completely, considering that manual operation may involve multiple people.

  • In terms of convenience and efficiency: since the operation on Packer is based on code, the operation will be very fast when the change is made. The efficiency of manual operation depends on personal hand speed.

  • In terms of repeatability of operation: Packer can quickly re-operate at any time according to the configuration file; In the case of full manual, it is not easy to reproduce all operations completely at once. The repeatability of the Packer code also means that you can recreate an identical environment as quickly as possible.

Start using Packer immediately

Install the Packer

To install Packer, we recommend downloading a binary package from Packer’s official website. For Mac OS X users, HomeBrew can also be used to install directly.

$ brew install packer
Copy the code

Preparing configuration Files

To get started, you need to prepare a configuration file, jdcloud.json, in which the parameters are given.

The configuration file template is as follows:

 {
   "builders": [{Service providers and identity information
       "type":             "jdcloud"."access_key":       "<Your access_key>"."secret_key":       "<Your secret_key>".# Cloud host specifications
      "image_id":         "<Base Image Id>"."region_id":        "cn-north-1"."az":               "cn-north-1c"."instance_name":    "packer_demo"."instance_type":    "g.n2.medium"."ssh_password":     "DevOps2018"."image_name":       "packer_image_demo"."subnet_id":        "subnet-jo6e38sdli".# Login Settings (do not change)
      "communicator":     "ssh"."ssh_username":     "root"}]."provisioners": [{"type": "shell"."inline": [

        # Cloud host running script information
        "sleep 30"."sudo apt update"."sudo apt install nginx -y"]]}}Copy the code
  • Service provider and identity information: Service provider – JDCloud, secondly you need to provide your AccessKey/SecretKey to us to explain your identity.
  • Cloud host specifications: Including:

Cloud host/region/Available area/model and specification

Basic image: it can be Centos/Ubuntu officially provided by Jingdong Cloud, or it can be your private image. You can fill in its ID here.

Subnet information: can be empty, if empty, we will create a temporary subnet for you.

Login password: here we choose to use the password to log in, and here is another example that shows the user how to use the secret key to create a cloud host image.

  • Run the command: As an example here, we chose to install an Nginx.

Start creating the image using the configuration file

bash ~ $ packer build jdcloud.json ==> jdcloud: Validating parameters... JDK cloud: validating your subnet:subnet-xxx jdcloud: subnet found: Packer Test subnet jdcloud: Validating your base image:img-1iubdz7gzu JDcloud: Image found:Ubuntu 16.04 64-bit JDcloud: Password detected, we are going to login with this password :) ==> jdcloud: Creating instances jdcloud: Creating public-ip jdcloud: Associating public-ip with instance jdcloud: Hi, we have created the instance, its name=packer_demo, its ID =i-xxxx, and its eIP =116.196.xx.xx :) ==> jdcloud: Using SSH Communicator to connect: 116.196.xx.xx ==> jdCloud: Waitingfor SSH to become available...
==> jdcloud: Connected to SSH!
==> jdcloud: Provisioning with shell script
==> jdcloud: Stopping this instance
    jdcloud: Instance has been stopped :)
==> jdcloud: Creating images
Build 'jdcloud' finished.


==> Builds finished. The artifacts of successful builds are:
--> jdcloud: A VMImage was created: img-riggr2xxx
Copy the code

In the above process, we can see that the image creation process can be roughly divided into four stages:

  1. Stage-1 Parameter verification phase: In this phase, we will verify the validity of parameters, including whether to specify a subnet, whether to create a temporary subnet, whether the given running image exists, whether to specify password login or key login.
  2. Phase -2 Creating a cloud host: In this phase, a cloud host is created based on the cloud host specifications and a public IP address is created for users to log in to the cloud host and run commands.
  3. Stage-3 Command execution stage: The output of the command is printed here.
  4. Stage-4 Image creation stage: Packer will create an image of this cloud host and save it in the image repository. The image ID is IMG-riggr2xxx.

The created image can be used to create cloud hosts manually or automatically through TerraForm.

Further, if you consider multiple regions of the service, users might want to create their own dedicated mirror for each region. In this case, Packer can create all images at a time by adding the configuration information of other regions to the configuration file, which greatly improves the efficiency of image creation.

Packer, with his “Infrastructure as Code” approach, helps users reduce the risk of failure while improving continuous delivery efficiency and business availability, addressing many of the drawbacks of traditional image creation in a cross-cloud platform environment.

After reading this article, do you have a comprehensive understanding of Packer? If you want to know more about jingdong cloud wing related information, please click “here”, enter jingdong cloud official website to learn about related products oh ~

Welcome to”Jingdong cloud”Learn more