github.com/marksheahan/packer@v0.10.2-0.20160613200515-1acb2d6645a0/website/source/intro/getting-started/provision.html.md (about)

     1  ---
     2  description: |
     3      In the previous page of this guide, you created your first image with Packer.
     4      The image you just built, however, was basically just a repackaging of a
     5      previously existing base AMI. The real utility of Packer comes from being able
     6      to install and configure software into the images as well. This stage is also
     7      known as the *provision* step. Packer fully supports automated provisioning in
     8      order to install software onto the machines prior to turning them into images.
     9  layout: intro
    10  next_title: Parallel Builds
    11  next_url: '/intro/getting-started/parallel-builds.html'
    12  page_title: Provision
    13  prev_url: '/intro/getting-started/build-image.html'
    14  ...
    15  
    16  # Provision
    17  
    18  In the previous page of this guide, you created your first image with Packer.
    19  The image you just built, however, was basically just a repackaging of a
    20  previously existing base AMI. The real utility of Packer comes from being able
    21  to install and configure software into the images as well. This stage is also
    22  known as the *provision* step. Packer fully supports automated provisioning in
    23  order to install software onto the machines prior to turning them into images.
    24  
    25  In this section, we're going to complete our image by installing Redis on it.
    26  This way, the image we end up building actually contains Redis pre-installed.
    27  Although Redis is a small, simple example, this should give you an idea of what
    28  it may be like to install many more packages into the image.
    29  
    30  Historically, pre-baked images have been frowned upon because changing them has
    31  been so tedious and slow. Because Packer is completely automated, including
    32  provisioning, images can be changed quickly and integrated with modern
    33  configuration management tools such as Chef or Puppet.
    34  
    35  ## Configuring Provisioners
    36  
    37  Provisioners are configured as part of the template. We'll use the built-in
    38  shell provisioner that comes with Packer to install Redis. Modify the
    39  `example.json` template we made previously and add the following. We'll explain
    40  the various parts of the new configuration following the code block below.
    41  
    42  ``` {.javascript}
    43  {
    44    "variables": ["..."],
    45    "builders": ["..."],
    46  
    47    "provisioners": [{
    48      "type": "shell",
    49      "inline": [
    50        "sleep 30",
    51        "sudo apt-get update",
    52        "sudo apt-get install -y redis-server"
    53      ]
    54    }]
    55  }
    56  ```
    57  
    58  -> **Note:** The `sleep 30` in the example above is very important. Because
    59  Packer is able to detect and SSH into the instance as soon as SSH is available,
    60  Ubuntu actually doesn't get proper amounts of time to initialize. The sleep
    61  makes sure that the OS properly initializes.
    62  
    63  Hopefully it is obvious, but the `builders` section shouldn't actually contain
    64  "...", it should be the contents setup in the previous page of the getting
    65  started guide. Also note the comma after the `"builders": [...]` section, which
    66  was not present in the previous lesson.
    67  
    68  To configure the provisioners, we add a new section `provisioners` to the
    69  template, alongside the `builders` configuration. The provisioners section is an
    70  array of provisioners to run. If multiple provisioners are specified, they are
    71  run in the order given.
    72  
    73  By default, each provisioner is run for every builder defined. So if we had two
    74  builders defined in our template, such as both Amazon and DigitalOcean, then the
    75  shell script would run as part of both builds. There are ways to restrict
    76  provisioners to certain builds, but it is outside the scope of this getting
    77  started guide. It is covered in more detail in the complete
    78  [documentation](/docs).
    79  
    80  The one provisioner we defined has a type of `shell`. This provisioner ships
    81  with Packer and runs shell scripts on the running machine. In our case, we
    82  specify two inline commands to run in order to install Redis.
    83  
    84  ## Build
    85  
    86  With the provisioner configured, give it a pass once again through
    87  `packer validate` to verify everything is okay, then build it using
    88  `packer build example.json`. The output should look similar to when you built
    89  your first image, except this time there will be a new step where the
    90  provisioning is run.
    91  
    92  The output from the provisioner is too verbose to include in this guide, since
    93  it contains all the output from the shell scripts. But you should see Redis
    94  successfully install. After that, Packer once again turns the machine into an
    95  AMI.
    96  
    97  If you were to launch this AMI, Redis would be pre-installed. Cool!
    98  
    99  This is just a basic example. In a real world use case, you may be provisioning
   100  an image with the entire stack necessary to run your application. Or maybe just
   101  the web stack so that you can have an image for web servers pre-built. This
   102  saves tons of time later as you launch these images since everything is
   103  pre-installed. Additionally, since everything is pre-installed, you can test the
   104  images as they're built and know that when they go into production, they'll be
   105  functional.