github.com/kikitux/packer@v0.10.1-0.20160322154024-6237df566f9f/website/source/intro/getting-started/parallel-builds.html.md (about)

     1  ---
     2  description: |
     3      So far we've shown how Packer can automatically build an image and provision it.
     4      This on its own is already quite powerful. But Packer can do better than that.
     5      Packer can create multiple images for multiple platforms in parallel, all
     6      configured from a single template.
     7  layout: intro
     8  next_title: Vagrant Boxes
     9  next_url: '/intro/getting-started/vagrant.html'
    10  page_title: Parallel Builds
    11  prev_url: '/intro/getting-started/provision.html'
    12  ...
    13  
    14  # Parallel Builds
    15  
    16  So far we've shown how Packer can automatically build an image and provision it.
    17  This on its own is already quite powerful. But Packer can do better than that.
    18  Packer can create multiple images for multiple platforms *in parallel*, all
    19  configured from a single template.
    20  
    21  This is a very useful and important feature of Packer. As an example, Packer is
    22  able to make an AMI and a VMware virtual machine in parallel provisioned with
    23  the *same scripts*, resulting in near-identical images. The AMI can be used for
    24  production, the VMware machine can be used for development. Or, another example,
    25  if you're using Packer to build [software
    26  appliances](https://en.wikipedia.org/wiki/Software_appliance), then you can build
    27  the appliance for every supported platform all in parallel, all configured from
    28  a single template.
    29  
    30  Once you start taking advantage of this feature, the possibilities begin to
    31  unfold in front of you.
    32  
    33  Continuing on the example in this getting started guide, we'll build a
    34  [DigitalOcean](http://www.digitalocean.com) image as well as an AMI. Both will
    35  be near-identical: bare bones Ubuntu OS with Redis pre-installed. However, since
    36  we're building for both platforms, you have the option of whether you want to
    37  use the AMI, or the DigitalOcean snapshot. Or use both.
    38  
    39  ## Setting Up DigitalOcean
    40  
    41  [DigitalOcean](https://www.digitalocean.com/) is a relatively new, but very
    42  popular VPS provider that has popped up. They have a quality offering of high
    43  performance, low cost VPS servers. We'll be building a DigitalOcean snapshot for
    44  this example.
    45  
    46  In order to do this, you'll need an account with DigitalOcean. [Sign up for an
    47  account now](https://www.digitalocean.com/). It is free to sign up. Because the
    48  "droplets" (servers) are charged hourly, you *will* be charged \$0.01 for every
    49  image you create with Packer. If you're not okay with this, just follow along.
    50  
    51  !> **Warning!** You *will* be charged \$0.01 by DigitalOcean per image
    52  created with Packer because of the time the "droplet" is running.
    53  
    54  Once you sign up for an account, grab your API token from the [DigitalOcean API
    55  access page](https://cloud.digitalocean.com/settings/applications). Save these
    56  values somewhere; you'll need them in a second.
    57  
    58  ## Modifying the Template
    59  
    60  We now have to modify the template to add DigitalOcean to it. Modify the
    61  template we've been using and add the following JSON object to the `builders`
    62  array.
    63  
    64  ``` {.javascript}
    65  {
    66    "type": "digitalocean",
    67    "api_token": "{{user `do_api_token`}}",
    68    "image": "ubuntu-14-04-x64",
    69    "region": "nyc3",
    70    "size": "512mb"
    71  }
    72  ```
    73  
    74  You'll also need to modify the `variables` section of the template to include
    75  the access keys for DigitalOcean.
    76  
    77  ``` {.javascript}
    78  "variables": {
    79    "do_api_token": "",
    80    // ...
    81  }
    82  ```
    83  
    84  The entire template should now look like this:
    85  
    86  ``` {.javascript}
    87  {
    88    "variables": {
    89      "aws_access_key": "",
    90      "aws_secret_key": "",
    91      "do_api_token": ""
    92    },
    93    "builders": [{
    94      "type": "amazon-ebs",
    95      "access_key": "{{user `aws_access_key`}}",
    96      "secret_key": "{{user `aws_secret_key`}}",
    97      "region": "us-east-1",
    98      "source_ami": "ami-fce3c696",
    99      "instance_type": "t2.micro",
   100      "ssh_username": "ubuntu",
   101      "ami_name": "packer-example {{timestamp}}"
   102    },{
   103      "type": "digitalocean",
   104      "api_token": "{{user `do_api_token`}}",
   105      "image": "ubuntu-14-04-x64",
   106      "region": "nyc3",
   107      "size": "512mb"
   108    }],
   109    "provisioners": [{
   110      "type": "shell",
   111      "inline": [
   112        "sleep 30",
   113        "sudo apt-get update",
   114        "sudo apt-get install -y redis-server"
   115      ]
   116    }]
   117  }
   118  ```
   119  
   120  Additional builders are simply added to the `builders` array in the template.
   121  This tells Packer to build multiple images. The builder `type` values don't even
   122  need to be different! In fact, if you wanted to build multiple AMIs, you can do
   123  that as long as you specify a unique `name` for each build.
   124  
   125  Validate the template with `packer validate`. This is always a good practice.
   126  
   127  -> **Note:** If you're looking for more **DigitalOcean configuration
   128  options**, you can find them on the [DigitalOcean Builder
   129  page](/docs/builders/digitalocean.html) in the documentation. The documentation
   130  is more of a reference manual that contains a listing of all the available
   131  configuration options.
   132  
   133  ## Build
   134  
   135  Now run `packer build` with your user variables. The output is too verbose to
   136  include all of it, but a portion of it is reproduced below. Note that the
   137  ordering and wording of the lines may be slightly different, but the effect is
   138  the same.
   139  
   140  ``` {.text}
   141  $ packer build \
   142      -var 'aws_access_key=YOUR ACCESS KEY' \
   143      -var 'aws_secret_key=YOUR SECRET KEY' \
   144      -var 'do_api_token=YOUR API TOKEN' \
   145      example.json
   146  ==> amazon-ebs: amazon-ebs output will be in this color.
   147  ==> digitalocean: digitalocean output will be in this color.
   148  
   149  ==> digitalocean: Creating temporary ssh key for droplet...
   150  ==> amazon-ebs: Creating temporary keypair for this instance...
   151  ==> amazon-ebs: Creating temporary security group for this instance...
   152  ==> digitalocean: Creating droplet...
   153  ==> amazon-ebs: Authorizing SSH access on the temporary security group...
   154  ==> amazon-ebs: Launching a source AWS instance...
   155  ==> digitalocean: Waiting for droplet to become active...
   156  ==> amazon-ebs: Waiting for instance to become ready...
   157  ==> digitalocean: Connecting to the droplet via SSH...
   158  ==> amazon-ebs: Connecting to the instance via SSH...
   159  ...
   160  ==> Builds finished. The artifacts of successful builds are:
   161  --> amazon-ebs: AMIs were created:
   162  
   163  us-east-1: ami-376d1d5e
   164  --> digitalocean: A snapshot was created: packer-1371870364
   165  ```
   166  
   167  As you can see, Packer builds both the Amazon and DigitalOcean images in
   168  parallel. It outputs information about each in different colors (although you
   169  can't see that in the block above) so that it is easy to identify.
   170  
   171  At the end of the build, Packer outputs both of the artifacts created (an AMI
   172  and a DigitalOcean snapshot). Both images created are bare bones Ubuntu
   173  installations with Redis pre-installed.