github.com/kaixiang/packer@v0.5.2-0.20140114230416-1f5786b0d7f1/website/source/intro/getting-started/provision.html.markdown (about)

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