Skip to content

Launching_Instances

Jump to bottom Edit New page
Matt Wagner edited this page Oct 25, 2012 · 1 revision

Building, Pushing, and Launching Instances

This is a guide to building and pushing images, and then launching them as instances.

Note that this guide overlaps partially with the older document at https://www.aeolusproject.org/page/Launching_a_Deployment_with_CLI_Tools but should be independent.

Prerequisites

In order to proceed, you’ll need:
* A functional Conductor setup
* To build images for providers other than EC2, you will require hardware virtualization capabilities.

Overview

Overall, the process is something like this:
# Create an XML template describing the image you wish to build
# Use the aeolus-image command-line tool to build that image
# Use the aeolus-image command-line tool to push that image to one or more provider account
# Create a deployable definition (in XML), host it on a webserver, and feed it to Conductor
# Use Conductor to launch the deployable

Create an Image Template

You can see a number of examples here: https://github.com/clalancette/oz/tree/master/examples — but we’ll start with this for illustration:

<code class="xml">
 <template>
   <name>SOME NAME HERE</name>
   <os>
     <name>Fedora</name>
     <version>14</version>
     <arch>x86_64</arch>
     <rootpw>THE PASSWORD TO BE USED TO LOG IN AS ROOT</rootpw>
     <install type='url'>
       <url>http://download.fedoraproject.org/pub/fedora/linux/releases/14/Fedora/x86_64/os/</url>
     </install>
   </os>
   <description>SOME DESCRIPTIVE TEXT HERE</description>
 </template>
</code>

For the sake of this example, we’ll save this as ~/template.tpl — the location (and file extension) doesn’t actually matter.

Build an Image from Template

We now want to use the aeolus-image command-line tool to build the image described in the XML.

When building for EC2, this occurs in the form of a “snapshot build” that occurs in the cloud using your EC2 credentials. For all other providers, Image Factory will build an image locally inside of a virtual machine, so hardware virtualization support is required.

Here is an example command:\

 $ aeolus-image build --target ec2 --template \  
    ~/template1.tpl

 Target Image: 193564a1-dd0d-4543-b182-d78d482010de
 Image: 6ae8421f-9ab2-4925-8f8d-ab165862b137
 Build: bf2c3ef3-2d67-455c-9c19-0d9a6bb9bdbb
 Status: COMPLETED
 Percent Complete: 100

Take note of the line beginning “Image:” — this UUID (6ae8421f9ab24925–8f8d-ab165862b137) is important and we will use it in the step below.

For most providers, this will not immediately complete, and you will want to tail -f /var/log/imagefactory.log to watch the build process, until status changes to COMPLETED.

It is possible to build for more than one target by separating them with commas, e.g., with --target ec2,mock.

TODO: List possible targets here, besides ec2.

Push Built Image to a Provider

Once an image is built, you will want to push the built image to one or more providers. You must specify the image ID, which is the Image UUID obtained in the step above. In this step, instead of specifying --target, we will specify the name of the Provider in Conductor.

 $ aeolus-image push --provider ec2-us-east-1 --account matt_ec2 \
   --image 6ae8421f-9ab2-4925-8f8d-ab165862b137 \
   --build bf2c3ef3-2d67-455c-9c19-0d9a6bb9bdbb \
   --targetimage 193564a1-dd0d-4543-b182-d78d482010de

 Provider Image: fa858cbb-0515-4aa4-8197-d739a6a65ba8
 Image: 6ae8421f-9ab2-4925-8f8d-ab165862b137
 Build: bf2c3ef3-2d67-455c-9c19-0d9a6bb9bdbb
 Status: PUSHING
 Percent Complete: 0

This step may take some time. You may wish to tail -f /var/log/imagefactory.log /var/log/iwhd.log to watch for completion.

Create and Host Deployable Definition

Once the image is pushed to one or more providers, you now need to create a Deployable Definition, an XML document describing the image and a Hardware Profile. Be sure that the hardware profile you use exists in Conductor! The image id is the same UUID we used above. Here is an example deployable definition:

<code class="xml">
 <deployable name="Sample">
  <description>This is an example deployment</description>
  <assemblies>
   <assembly name="frontend" hwp="hwp1">
    <image id="6ae8421f-9ab2-4925-8f8d-ab165862b137">
    </image>
   </assembly>
  </assemblies>
 </deployable>
</code>

Conductor expects Deployable Definitions to be consumable over HTTP, so you’ll want to copy this up to a webserver somewhere that Conductor can reach. In the simplest case, it’s often easiest to save this file with a name like /var/www/html/deployable.xml on the Conductor box since it’s running already Apache; this way Conductor needs only access http://localhost/deployable.xml. It does not need to be stored locally, however; any webserver that the box running Conductor can reach is valid. (Larger, production deployments will likely want a different approach here.)

In this example, we specify a Hardware Profile (hwp) of “hwp1”. Be sure you have a Hardware Profile in Conductor with this name, or you will not be able to launch the instance.

Launch through Conductor

With the Deployable Definition saved to a webserver somewhere, all that’s left to do is to launch the instance through Conductor’s web GUI. To do this:
* Visit the appropriate Pool in Conductor
* Click “New Deployment”
* Assign a unique, meaningful name to your Deployment
* Plug in the URL where the deployable definition was hosted above. In this example, http://localhost/deployable.xml was used, but any valid URL can be used.
* Select a realm if appropriate.
* Launch!

Other Reading

Add a custom footer
Add a custom sidebar
Clone this wiki locally