Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Merge branch 'master' of github.com:nimbusproject/nimbus

Conflicts:
	docs/src/platform/cloudinitd/index.html
  • Loading branch information...
commit d2d3ee74624de3621dae999950934375e305928e 2 parents c018658 + 4436eea
@buzztroll buzztroll authored
View
13 docs/src/platform/cloudinitd/ec2bootpgm.py
@@ -1,13 +0,0 @@
-#!/usr/bin/env python
-
-import sys
-import os
-
-f = open("hello.html", "w")
-f.write("<html><body>Hello cloudinit.d!</body></html>")
-f.close()
-
-cmd = "sudo cp hello.html /var/www/"
-os.system(cmd)
-
-sys.exit(0)
View
3  docs/src/platform/cloudinitd/helloec2.conf
@@ -1,3 +0,0 @@
-[runlevels]
-level1: helloec2_level1.conf
-
View
13 docs/src/platform/cloudinitd/helloec2_level1.conf
@@ -1,13 +0,0 @@
-[svc-sampleservice]
-
-iaas_key: env.CLOUDBOOT_IAAS_ACCESS_KEY
-iaas_secret: env.CLOUDBOOT_IAAS_SECRET_KEY
-localsshkeypath: env.CLOUDBOOT_IAAS_SSHKEY
-keyname: env.CLOUDBOOT_IAAS_SSHKEYNAME
-
-ssh_username: ubuntu
-image: ami-30f70059
-allocation: t1.micro
-
-bootpgm: bootpgm.py
-
View
36 docs/src/platform/cloudinitd/impl.html
@@ -1,36 +0,0 @@
-m4_include(/mcs/m4/worksp.lib.m4)
-_NIMBUS_HEADER(cloudinit.d Lanch Plans)
-_NIMBUS_HEADER2(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN
-
-_NIMBUS_LEFT2_CLOUDS1_SIDEBAR(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN_END
-_NIMBUS_CENTER2_COLUMN
-
-<h2> cloudinit.d Launch Plans </h2>
-<ul>
-<li><a href="#introduction">Introduction</a></li>
-<li><a href="#vm">VMs vs. Services</a></li>
-<li><a href="#ssh">Execution of programs</a></li>
-<li><a href="#attrbag">Dependency Information</a></li>
-<li><a href="#repair">Repair</a></li>
-</ul>
-
-<br />
-
-</p>
-
-<a name="introduction"> </a>
-<h2>Introduction _NAMELINK(introduction)</h2>
-
-
-
-<br />
-
-_NIMBUS_CENTER2_COLUMN_END
-_NIMBUS_FOOTER1
-_NIMBUS_FOOTER2
-_NIMBUS_FOOTER3
-
View
77 docs/src/platform/cloudinitd/index.html
@@ -1,77 +0,0 @@
-m4_include(/mcs/m4/worksp.lib.m4)
-_NIMBUS_HEADER(2.9 Administrator Guide)
-_NIMBUS_HEADER2(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN
-_NIMBUS_LEFT2_ADMIN_SIDEBAR(y,n,n,n,n)
-_NIMBUS_LEFT2_COLUMN_END
-_NIMBUS_CENTER2_COLUMN
-_NIMBUS_IS_DEPRECATED
-
-
-<h2>Nimbus Platform cloudinit.d</h2>
-
-<p>
- This guide contains configuration information about the Cloud
- application coordination tool cloudinit.d
-</p>
-
-<ul>
- <li>
- <a href="intro.html">Introduction</a>
- </li>
- <li>
- <a href="quickstart.html#download">Download cloudinit.d</a>
- </li>
- <li>
- <a href="quickstart.html">A Quickstart guide to launching a simple application</a>
- </li>
- <li>
- <a href="wordpress.html">Wordpress Example</a>
- </li>
- <li>
- <a href="service.html">An explanation of cloudinit.d Services</a>
- </li>
-</ul>
-
-<img src="../../clouds/img/cloudinitd_dia.png" width="600" height="400" />
-
-<p>
-Solving the problems in computing often requires a set of services all
-working together in concert. As distributed computing has evolved, the
-management and coordination of these services has become a complicated
-task. The advent of cloud computing has exacerbated this problem by
-providing its users with an explosion of virtual resources
-that need to be started, managed, monitored, and notified of each others
-existence and operational state.
-</p>
-<p>
-Very little can be assumed about the network locations of these
-virtual machines, their IP addresses are dynamically provisioned and
-they can be spread across many clouds potentially all over the world.
-In order for the VMs to work in concert,
-It is critical that communication channels are established.
-</p>
-<p>
-How can we organize, manage, and coordinate
-the bootstrap process of these ever growing cloud applications?
-Infrastructure clouds have delivered the resources but can they be
-leveraged in a sane and repeatable way? Once these applications are
-running how can we ensure that they continue to work and can we recover
-from failures without having to waste valuable time and potential data
-by completely restarting them?
-</p>
-
-To address these questions the Nimbus
-Project is proud to introduce cloudinit.d. cloudinit.d is a tool
-for launching,
-configuring, monitoring, and repairing a set of interdependent virtual
-machines in an IaaS cloud or over a set of IaaS clouds. A single launch
-can consist of many VMs and can span multiple IaaS providers, including
-offerings from commercial and academic space.
-</p>
-
-_NIMBUS_CENTER2_COLUMN_END
-_NIMBUS_FOOTER1
-_NIMBUS_FOOTER2
-_NIMBUS_FOOTER3
View
155 docs/src/platform/cloudinitd/intro.html
@@ -1,155 +0,0 @@
-m4_include(/mcs/m4/worksp.lib.m4)
-_NIMBUS_HEADER(cloudinit.d Intro)
-_NIMBUS_HEADER2(n,n,n,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN
-
-_NIMBUS_LEFT2_CLOUDS1_SIDEBAR(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN_END
-_NIMBUS_CENTER2_COLUMN
-
-<h2> cloudinit.d : The Nimbus Platform tool for controlling cloud applications </h2>
-
-<ul>
-<li><a href="#introduction">Introduction</a></li>
-<li><a href="#overview">Overview</a></li>
- <ul>
- <li><a href="#service">Individual service</a></li>
- <li><a href="#bootlevel">Bootlevel</a></li>
- <li><a href="#launchplan">Launch Plan</a></li>
- </ul>
-<li><a href="#example">Example</a></li>
-</ul>
-
-<br />
-
-</p>
-
-<a name="introduction"> </a>
-<h2>Introduction _NAMELINK(introduction)</h2>
-<p>
-cloudinit.d is a tool for launching, controlling, and monitoring cloud
-applications. If the application is simple or complex, single cloud or
-multi-cloud, VM based or bare metal, or any combination of the above,
-cloudinit.d is designed to make the management and coordination of that
-application easy.
- </p>
-<p>
-Infrastructure clouds bring a wealth of resources to their users
-(typically in the form of virtual machines).
-User now have the ability to create thousands of virtual machines to
-handle the needs of their applications. The architecture of applications
-is becoming much less tied to a single machine. Applications are starting
-to assume the use of reliable/redundant data stores like
-<a href="http://en.wikipedia.org/wiki/Apache_Cassandra">Cassandra</a> and
-reliable messaging services like
-<a href="http://www.rabbitmq.com/">RabbitMQ</a>.
-While this has brought great opportunity, it has also brought an unruly
-amount
-of system administration, coordination and management.
-</p>
-<p>
-It is the goal of cloudinit.d to solve this problem. cloudinit.d
-automates the creation of virtual machines, their contextualization,
-and all of the messaging between VMs needed to boot strap up today's
-more complicated cloud applications. Further, it makes this process
-repeatable.
- </p>
-<p>
-Those familiar with UNIX machines have probably made the connection
-between the name <i>cloudinit.d</i> and <i>init.d</i>. This is, of course,
-intentional. cloudinit.d is the init.d of the cloud. Just like init.d
-organizes, manages, and efficiently runs processes needed for a system,
-cloudinit.d does the same for applications run across clouds.
-</p>
-<p>
-On this page we provide an introduction to some of the important concepts
-of cloudinit.d. The details about command line arguments,
-configuration file syntax, and advanced features are described elsewhere.
-</p>
-<a name="overview"> </a>
-<h2>Overview _NAMELINK(overview)</h2>
-<img src="../../clouds/img/cloudinitd_pres1.png" width="460" height="376" />
-<p>cloudinit.d arranges an application into three basic constructs:
-<ul>
- <li>service</li>
- <li>boot level</li>
- <li>launch plan</li>
-</ul>
-
-<a name="service"> </a>
-<h2>Service _NAMELINK(service)</h2>
- A service can be thought of as a single, configured Virtual Machine.
- However
- this is a very limiting definition. Many services can be configured
- to run in a single VM, or on an existing host that does not even have
- to be a virtual machine at all. A service is really just an entity
- confined to a single machine which is responsible for a well defined
- task. In spite of this fact in most of our examples we will merge the
- understanding of a single VM and a cloudinit.d service.
-</p>
-<p>
-Some example services are an http server, a
-node in a Cassandra pool, or a node in a rabbitmq message queue.
-</p>
-<a name="bootlevel"> </a>
-<h2>Bootlevel _NAMELINK(bootlevel)</h2>
-<p>
- A boot level is a collection of services with no dependencies on each other.
- All services in a boot level are launched at the same time. That boot
- level is considered complete when all of the services is it have
- successfully started.
-</p>
-<p>
- Services in a boot level can be run on 1 single cloud or across many
- different clouds. cloudinit.d makes no assumptions about locality.
- Any service in a bootlevel can depend any service from a previous boot
- level. For example, boot level one forms a mongo DB data store cluster.
- A web application in boot level 2 can <i>depend</i> on that mongo DB
- cluster, meaning, it can acquire all of the information needed to connect
- to it dynamically at boot time.
-</p>
-
-<a name="launchplan"> </a>
-<h2>Launch plan _NAMELINK(launchplan)</h2>
-<p>
-A launch is an ordered set of bootlevels. To make a launch plan first all
-of the services are defined, then those services are arranged into boot levels,
-and finally the boot levels are put in a specific order. This forms a
-complete cloud (or inter-cloud) application.
-</p>
-
-<a name="example"> </a>
-<h2>Example application _NAMELINK(example)</h2>
-<img src="../../clouds/img/cloudinitd_dia.png" width="600" height="400" />
-<p>
-The diagram shows an example cloud application that can benefit from
-cloudinit.d. Here we have a highly available web application which uses
-mongo DB for its data store, apache HTTP servers for its web application,
-and a load balancer to distribute the work.
-</p>
-
-<p>
-For explanatory purposes
-we put each component in a separate cloud, in practice this may or may
-not be practical. Our purpose in doing so was to show the reader that
-such a thing is possible with cloudinit.d.
-</p>
-<p>
-The creator of this application would write a <i>launch plan</i> with
-three boot levels. The first has a cluster of mongo DB servers, the
-second is a set of replicated HTTP servers, and the third is a load
-balancer. The plan is configured in such a way as to route the important
-connection information from the mongo DB cluster, to each HTTP server.
-And similarly the list of HTTP servers is sent to the load balancer once
-boot level 2 completes.
-</p>
-
-<br />
-
-_NIMBUS_CENTER2_COLUMN_END
-_NIMBUS_FOOTER1
-_NIMBUS_FOOTER2
-_NIMBUS_FOOTER3
-
View
38 docs/src/platform/cloudinitd/launchplans.html
@@ -1,38 +0,0 @@
-m4_include(/mcs/m4/worksp.lib.m4)
-_NIMBUS_HEADER(cloudinit.d Lanch Plans)
-_NIMBUS_HEADER2(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN
-
-_NIMBUS_LEFT2_CLOUDS1_SIDEBAR(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN_END
-_NIMBUS_CENTER2_COLUMN
-
-<h2> cloudinit.d Launch Plans </h2>
-<ul>
-<li><a href="#introduction">Introduction</a></li>
-<li><a href="#top">Top Level Configuration File</a></li>
-<li><a href="#runlevel">Run Level Configuration Files</a></li>
-<li><a href="#deps">Dependency Files</a></li>
-<li><a href="#json">Bootconf json files</a></li>
-<li><a href="#clouds">Cloud settings</a></li>
-<li><a href="#deps">Dependencies</a></li>
-</ul>
-
-<br />
-
-</p>
-
-<a name="introduction"> </a>
-<h2>Introduction _NAMELINK(introduction)</h2>
-
-
-
-<br />
-
-_NIMBUS_CENTER2_COLUMN_END
-_NIMBUS_FOOTER1
-_NIMBUS_FOOTER2
-_NIMBUS_FOOTER3
-
View
295 docs/src/platform/cloudinitd/quickstart.html
@@ -1,295 +0,0 @@
-m4_include(/mcs/m4/worksp.lib.m4)
-_NIMBUS_HEADER(cloudinit.d Quick-start)
-_NIMBUS_HEADER2(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN
-
-_NIMBUS_LEFT2_CLOUDS1_SIDEBAR(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN_END
-_NIMBUS_CENTER2_COLUMN
-
-<h2> cloudinit.d Quick-start </h2>
-<ul>
-<li><a href="#download">Download the cloudinit.d</a></li>
-<li><a href="#launchplan">Create a launch plan</a></li>
- <ul>
- <li><a href="#ec2">Simple EC2 example</a></li>
- <li><a href="#top">Top level launch plan</a></li>
- <li><a href="#level">Run level configuration</a></li>
- <li><a href="#bootpgm">Bootpgm</a></li>
- </ul>
-<li><a href="#boot">Boot the launch plan</a></li>
-<li><a href="#monitor">Monitor the launch plan</a></li>
-<li><a href="#terminate">Terminate the launch plan</a></li>
-</ul>
-
-<br />
-
-<a name="download"> </a>
-<h2>Download and install cloudinit.d _NAMELINK(download)</h2>
-
-<p>
-cloudinit.d is a python setup package registered with
-<a href="http://pypi.python.org/pypi">pypi</a> which means you can <i>easy_install</i>
-it. From a python virtualenv or an account with access to the systems
-libraries and pythin in its path run:
-<tt class="literal"> <pre>
-$ easy_install cloudinitd
-</pre></tt>
-This will download cloudinit.d and all of its dependencies and install them.
-</p>
-<p>
-If you prefer to fetch the tarball and have a more manual install you can
-get the latest release <a href="">here</a>. To install it untar, change
-<tt class="literal"> <pre>
-$ tar -zxvf cloudinitd-latest.tar.gz
-...
-$ cd cloudinitd-&lt;version&gt;
-$ python setup.py install
-</pre></tt>
-to the base directory and run <I>python setup.py install</I>
-</p>
-<p>
-You can new test it out!
-<tt class="literal"> <pre>
-$ cloudinitd --help
-Usage: [options] &lt;command&gt; [&lt;top level launch plan&gt; | &lt;run name&gt;]
-Boot and manage a launch plan
-Run with the command 'commands' to see a list of all possible commands
-
-
-Options:
- --version show program's version number and exit
- -h, --help show this help message and exit
- -v, --verbose Print more output
- -x, --validate Check that boot plan is valid before launching it.
- -y, --dryrun Check that boot plan is valid before launching it.
- -q, --quiet Print no output
- -n NAME, --name=NAME Set the run name, only relevant for boot (by default
- the system picks)
- -d DATABASE, --database=DATABASE
- Path to the db directory
- -f LOGDIR, --logdir=LOGDIR
- Path to the base log directory.
- -l LOGLEVEL, --loglevel=LOGLEVEL
- Controls the level of detail in the log file : {debug
- | info | warn | error}
- -c, --noclean Do not delete the database, only relevant for the
- terminate command
-</pre>
-
-
-<a name="launchplan"> </a>
-<h2>Create a launch plan _NAMELINK(launchplan)</h2>
-
-<p>
- A launch plan is set of configuration files that tell cloudinit.d what
- VM images to boot and in what order. It is where the specific cloud
- to use is set along with the credentials needed to access that cloud.
- All aspects of contextualization and testing are also set in the
- launch plan.
-</p>
-<p>
- Here we will walk through a very basic launch plan. To minimize potential
- confusion we will only show a bare minimum set of cloudinit.d features.
-</p>
-<a name="ec2"> </a>
-<h2>Simple EC2 example _NAMELINK(ec2)</h2>
-<p>
- In this example we show a minimal launch plan needed to start a
- VM on Amazon's EC2. In order to use it you will need an account with
- AWS.
- To get an EC2 account see: <a href="https://aws.amazon.com/">AWS</a>
-</p>
-<div class="note">
-For this example to work you need your default security group to have
-port 22 and 80.
-</div>
-
-<p>
- The launch plans used in this example can be found at:
- <a href="helloec2.conf">helloec2.conf</a> and
- <a href="helloec2_level1.conf">helloec2_level1.conf</a>
-</p>
-
-<a name="top"> </a>
-<h2>Top level launch plan _NAMELINK(top)</h2>
-<p>
-In this very simple example the top level configuration file simply enumerates
-the run levels. Because we are only launching a single virtual machine
-there is only 1 run level. The entire configuration file follows:
-</p>
-<div class="panel"><pre>
-[runlevels]
-level1: helloec2_level1.conf
-</pre></div>
-
-<a name="level"> </a>
-<h2>Run level configuration _NAMELINK(level)</h2>
-<p>
- In this example all of the interesting information will be held in the
- run level configuration file. We will need to have the following
- information in order to run this example.
- <UL>
- <li>EC2 access key</li>
- <li>EC2 secret key</li>
- <li>EC2 ssh key name</li>
- <li>path to the matching ssh key</li>
- </UL>
- These are all very standard things that EC2 users have. If you are not
- familiar with these items please check out the EC2 tutorial
- <a href="http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/">here</a>.
-</p>
-<p>
- Once you have obtained the above information please set the following
- environment variables in the following way:
-<div class="panel"><pre>
-% export CLOUDBOOT_IAAS_ACCESS_KEY=&lt;EC2 access key&gt;
-% export CLOUDBOOT_IAAS_SECRET_KEY=&lt;EC2 secret key&gt;
-% export CLOUDBOOT_IAAS_SSHKEY=&lt;EC2 ssh key name&gt;
-% export CLOUDBOOT_IAAS_SSHKEYNAME=&lt;path to the matching ssh key&gt;
-</pre></div>
-</p>
-<p>
- Now that we have all of the security information in place we will look
- at the run level configuration file:
-</p>
-<div class="panel"><pre>
-[svc-sampleservice]
-
-iaas_key: env.CLOUDBOOT_IAAS_ACCESS_KEY
-iaas_secret: env.CLOUDBOOT_IAAS_SECRET_KEY
-localsshkeypath: env.CLOUDBOOT_IAAS_SSHKEY
-keyname: env.CLOUDBOOT_IAAS_SSHKEYNAME
-
-iaas: us-east-1
-image: ami-30f70059
-ssh_username: ubuntu
-allocation: t1.micro
-
-bootpgm: bootpgm.py
-</pre></div>
-
-<div class="note">
- The name of this configuration section is <i>svc-sampleservice</i>.
- What this tells cloudinit.d is that it is a service (svc-) named
- sampleservice. The name must start with <i>svc-</i>
-</div>
-<p>
-The first thing to note from this file are the values corresponding to the
-environment variables we just set. The directive <b>env.</b> tells cloudinit.d
-to get the value for this field from the environment variable of the
-following name. The values for these 4 entries are described above.
-</p>
-<p>
-The remaining entries have the following meanings:
-<UL>
- <li>iaas</li>This is a string describing the cloud with which we will be
- interacting. In this case it is us-east-1 on EC2.
- <li>image</li>This is a handle to an image. The format of this handle
- will vary with different clouds. In our case we are using EC2 so the
- format is ami-XXXXXXX. The specific AMI for use with this example is
- ami-30f70059. It is a publicly available ubuntu image with an apache
- server installed.
- <li>ssh_username</li>This is the username that the VM image has
- associated with the localsshkeypath defined above.
- <li>allocation</li>This string tells the cloud details of the resources
- we want allocated with the image. In our case we pick t1.micro because
- it is the cheapest.
- <li>bootpgm</li>This value is described in the next section.
-</UL>
-</p>
-
-<a name="bootpgm"> </a>
-<h2>Bootpgm _NAMELINK(bootpgm)</h2>
-<p>
-This value points to a program that will be run on your once to contextualize
-it. Once you boot your launch program cloudinit.d will wait until its
-sshd service is running. Once it is this program is uploaded and run as the
-user defined by <i>ssh_username</i>, in our case <i>ubuntu</i>. Below
-is the example bootpgm.
-</p>
-<div class="panel"><pre>
-#!/usr/bin/env python
-
-import sys
-import os
-
-f = open("hello.html", "w")
-f.write("&lt;html&gt;&lt;body&gt;Hello cloudinit.d!&lt;/body&gt;&lt;/html&gt;")
-f.close()
-
-cmd = "sudo cp hello.html /var/www/"
-os.system(cmd)
-
-sys.exit(0)
-</pre></div>
-<p>
-This is a very simple program which simply creates a web page. You can also
-see it here <a href="ec2bootpgm.py">ec2bootpgm.py</a>
-</p>
-<a name="boot"> </a>
-<h2>Terminate _NAMELINK(boot)</h2>
-<p>
-Now that we have and understand a launch plan, lets put it into action with cloudinit.d:
-</p>
-<div class="note">
- You will be charged by AWS for running this command. At the time
- of this writing the charges are less than 3 cents per hour.
-</div>
-
-<div class="panel"><pre>
-$ cloudinitd -v -v -v boot helloec2.conf
-Starting up run 54c03415
- Started IaaS work for sampleservice
-Starting the launch plan.
-Begin boot level 1...
- Started sampleservice
- SUCCESS service sampleservice boot
- hostname: ec2-50-17-4-154.compute-1.amazonaws.com
- instance: i-2ae3a245
-SUCCESS level 1
-
-</pre></div>
-<div class="note">
-The above session shows a successful boot of a launch plan. Notice the use
-the <i>-u</i> option. This simply increases the amount of output that we will
-see.
-</div>
-
-<p>
-Your VM was successfully started! The output shows the hostname assigned to
-the boot as <i>ec2-50-17-4-154.compute-1.amazonaws.com</i>. If we point a
-web browser at http://ec2-50-17-4-154.compute-1.amazonaws.com/hello.html
-we should see the message we configured with our bootpgm.py program.
-</p>
-<a name="terminate"> </a>
-<h2>Terminate _NAMELINK(terminate)</h2>
-<p>
-In order to avoid further service charges from AWS we should clean up this
-launch. This is done by taking the run name from the output of the boot,
-in our case 54c03415 and giving it as an option to the terminate directive:
-</p>
-
-<div class="panel"><pre>
-$ cloudinitd -v -v -v terminate 54c03415
-Terminating 54c03415
-Begin terminate level 1...
- Started sampleservice
- SUCCESS service sampleservice terminate
- hostname: None
- instance: None
-SUCCESS level 1
-deleting the db file /home/bresnaha/.cloudinitd/cloudinitd-54c03415.db
-
-</pre></div>
-
-
-<br />
-
-_NIMBUS_CENTER2_COLUMN_END
-_NIMBUS_FOOTER1
-_NIMBUS_FOOTER2
-_NIMBUS_FOOTER3
-
View
178 docs/src/platform/cloudinitd/service.html
@@ -1,178 +0,0 @@
-m4_include(/mcs/m4/worksp.lib.m4)
-_NIMBUS_HEADER(cloudinit.d Intro)
-_NIMBUS_HEADER2(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN
-
-_NIMBUS_LEFT2_CLOUDS1_SIDEBAR(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN_END
-_NIMBUS_CENTER2_COLUMN
-
-<h2> cloudinit.d Services </h2>
-
-<ul>
-<li><a href="#introduction">Introduction</a></li>
-<li><a href="#svcprograms">Service Programs</a></li>
-<li><a href="#clouds">Cloud settings</a></li>
-<li><a href="#deps">Dependencies</a></li>
-</ul>
-
-<br />
-
-<h3>An animated example of how cloudinit.d brings up a service</h3>
-<div><h3 style="padding: 0px; margin: 3px;"><a href="http://www.authorstream.com/Presentation/buzztroll-971906-cloudinitd-simple/" target="_blank" style="font:normal 18px,arial;">cloudinitd_simple</a></h3><object width="425" height="354" id="player"><param name="movie" value="http://www.authorstream.com/player.swf?p=971906_634389035994692500&pt=3" /><param name="allowfullscreen" value="true" /><param name="allowScriptAccess" value="always"/><embed src="http://www.authorstream.com/player.swf?p=971906_634389035994692500&pt=3" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="354"></embed></object>
-</div>
-
-<a name="introduction"> </a>
-<h2>Introduction _NAMELINK(introduction)</h2>
-<p>
-The primary building block of cloudinit.d is the service.
-For readers familiar with init.d, the cloudinit.d service is
-akin to the <i>program</i> in init.d. On this page we will
-describe the cloudinit.d service construct and how cloudinit.d
-starts and configures its services.
- </p>
-<p>
-Often times a service is composed of many processes running in a single
-VM. This is not strictly true. In fact, a service can be created
-entirely without a VM, and further many cloudinit.d service's can all
-run on the same machine. However, in the classic case a VM is started
-specifically to accommodate the needs of a single server. That VM is
-launched by cloudinit.d, a set of user defined configuration scripts are
-then copied into that VM and run to contextualize it. The healthy of that
-service is then monitored by another service program.
-</p>
-<p>
-The presentation at the beginning of this page illustrates this.
-</p>
-<a name="svcprograms"> </a>
-<h2>Service programs _NAMELINK(svcprograms)</h2>
-<p>
-There are three programs that are associated with a service:
-<ul>
- <li>Bootpgm</li>This program runs once to setup the service. Often
- times it will download and install software (apt-get/yum) and then
- configure that software for use considering the values and locations
- of other services in the boot.
- <li>readypgm</li>This program is run to check the status and health
- of the service. It can be, and typically is, run many times. As an
- example, if the service's goal was to serve http, the readypgm would
- connect to localhost:80, download a know web page and check its content.
- If all is well the readypgm returns 0 and the service is reported as
- working. If not, the services is marked as <i>down</i> and the
- cloud application is in need of a repair.
- <li>terminatepgm</li>The terminate program is run when a service
- is shutdown. It is there to nicely cleanup resources associated
- with the service.
-</ul>
-All of these programs are user defined and written as part of the
-process of creating a cloudinit.d service. None of the programs
-are mandatory. If you can create a service that does not need one
-of them, by all means ignore the unneeded ones. However we have
-found that they tend to be needed.
-</p>
-<p>
-As an example let us say that we want to create a service that runs
-an apache2 web server. We find a base ubuntu VM image on our cloud
-and we associate it with our service. Now we must create the pgms
-needed to turn this VM into a cloudinit.d service. Some possible
-programs are shown below:
-</p>
-<div class="note">
-These programs can be written in any scripting language available on the
-VM on which they will be run.
-</div>
-
-<p>
-bootpgm
-<div class="panel"><pre>
-#!/bin/bash
-
-sudo apt-get install apache2
-exit $?
-</pre></div>
-</p>
-
-<p>
-readypgm
-<div class="panel"><pre>
-#!/bin/bash
-
-wget http://localhost
-exit $?
-</pre></div>
-</p>
-
-<p>
-terminatepgm
-<div class="panel"><pre>
-#!/bin/bash
-
-/etc/init.d/apache2 stop
-exit $?
-</pre></div>
-</p>
-<p>
-All of the above programs are scp'ed to the hosting machine and then
-run via ssh. Thus the user must have ssh credentials that will work on
-the associated cloud and VM, and port 22 must be open to that VM. This
-is a common scenario for infrastructure clouds.
-</p>
-
-<p>
-A bootlevel is a set of services that can all be started at the same time.
-In other words, a set of services that have no dependencies on each other.
-These services are launched at the same time. The boot level is considered
-complete when all of the service's bootpgms successfully complete.
-</p>
-
-
-<a name="clouds"> </a>
-<h2>Cloud settings _NAMELINK(clouds)</h2>
-<p>
-All of the information about where (what cloud) a particular service is to
-be run on is set at the service level. Thus a cloudinit.d application
-can run across many clouds. It is entirely possible (and encouraged) to
-have an application launched with cloudinit.d such that some services are
-in a private cloud and others are in a public cloud. Right now cloudinit.d
-works on EC2, Nimbus, and Eucalyptus. It has a very modular interface that
-will allow us to quickly add other infrastructure cloud types so we expect
-that list to grow quickly.
-</p>
-
-<a name="deps"> </a>
-<h2>Dependencies _NAMELINK(deps)</h2>
-<p>
-The goal of cloudinit.d is to orchestrate many services to work in concert
-together to form a single application. In order for this to be possible
-the services need a way to discover information about each other. For example,
-if we are making a web server backed by a database we would make the database
-one service and the webserver another (as is the case in our
-<a href="wordpress.html">wordpress</a>
-example). Because the web server is dependent upon the database, We would
-put the database at bootlevel 1 and the web server at boot level 2.
-</p>
-<p>
-However, just having the web server wait for the database to be ready is
-not enough. The web server must know the IP address and the port number
-of the data base in order to connect to it. Further they likely need some
-sort of shared secret for making a secure connection. Cloudinit.d handles
-the exchange of this, and similar types of dependency information. Any
-service is allowed to lookup another service (that is at a lower boot level)
-and request an attribute from it. There is a small set of statically
-defined attributes that a service has (ex: hostname, IaaS instance id, etc)
-and the service can further defined its own setup attributes.
-</p>
-<p>
-This secure exchange of service defined attributes is what makes
-cloudinit.d a powerful tool.
-</p>
-
-<br />
-
-_NIMBUS_CENTER2_COLUMN_END
-_NIMBUS_FOOTER1
-_NIMBUS_FOOTER2
-_NIMBUS_FOOTER3
-
View
217 docs/src/platform/cloudinitd/wordpress.html
@@ -1,217 +0,0 @@
-m4_include(/mcs/m4/worksp.lib.m4)
-_NIMBUS_HEADER(cloudinit.d Wordpress Example)
-_NIMBUS_HEADER2(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN
-
-_NIMBUS_LEFT2_CLOUDS1_SIDEBAR(n,n,y,n,n,n,n)
-
-_NIMBUS_LEFT2_COLUMN_END
-_NIMBUS_CENTER2_COLUMN
-
-<h2> cloudinit.d Wordpress example </h2>
-<ul>
-<li><a href="#introduction">Introduction</a></li>
-<li><a href="#quickstart">Quick-Start</a></li>
-<li><a href="#cleanup">Cleanup</a></li>
-<li><a href="#whathappened">What Happened</a></li>
-<li><a href="#launchplan">Launch Plan</a></li>
-<li><a href="#troubleshooting">Trouble Shooting</a></li>
-</ul>
-
-<br />
-
-<a name="introduction"> </a>
-<h2>Introduction _NAMELINK(introduction)</h2>
-
-<p>
-This example will launch an EC2 cloud application which runs a
-<a href="http://wordpress.com/">wordpress</a>. Two virtual machines
-will be launched, the first runs a <a href="http://www.mysql.com/">MySQL</a>
-database, and the second runs the wordpress service.
-</p>
-<div class="note">
-Running VMs on EC2 requires an EC2 account which will be charged. At the
-time of this writing the rates for an m1.small instance is $0.085 per hour.
-Rates can be checked <a href="http://aws.amazon.com/ec2/pricing/">here</a>
-</div>
-
-<a name="quickstart"> </a>
-<h2>Quick-Start _NAMELINK(quickstart)</h2>
-<p>
-Once you have cloudinit.d installed the following commands will get this
-example, boot it in EC2, and present you will a functional wordpress service.
-
-<tt class="panel"> <pre>
-$ export CLOUDBOOT_IAAS_ACCESS_KEY=&lt;your EC2 access key&gt;
-$ export CLOUDBOOT_IAAS_SECRET_KEY=&lt;your EC2 secret key&gt;
-$ export CLOUDBOOT_IAAS_SSHKEY=&lt;the path to your ssh key&gt;
-$ export CLOUDBOOT_IAAS_SSHKEYNAME=&lt;the name of your ssh key in EC2&gt;
-$ wget http://www.nimbusproject.org/downloads/wordpress.tar.gz
-$ tar -zxf wordpress.tar.gz
-$ cloudinitd -v -v -v boot wordpress/top.conf
-</pre></tt>
-
-When this completes a full wordpress service will be ready for your use.
-The output of cloudinit.d will look something like this:
-
-<tt class="panel"> <pre>
-Starting up run c80e7e2c
- Started IaaS work for mysql
- Started IaaS work for wordpress
-Starting the launch plan.
-Begin boot level 1...
- Started mysql
- SUCCESS service mysql boot
- hostname: ec2-50-17-78-14.compute-1.amazonaws.com
- instance: i-f8380797
-SUCCESS level 1
-Begin boot level 2...
-Begin boot level 2...
- Started wordpress
- SUCCESS service wordpress boot
- hostname: ec2-174-129-163-229.compute-1.amazonaws.com
- instance: i-ca3807a5
-SUCCESS level 2
-</pre></tt>
-Note the second hostname printed under the <i>wordpress</i> service
-information: ec2-174-129-163-229.compute-1.amazonaws.com. Simply
-point your web browser at
-http://ec2-174-129-163-229.compute-1.amazonaws.com/wordpress/wp-admin/install.php
-and you have your own personal wordpress service!
-<div class="note">
-For this example to work you need your default security group to have
-port 22, 80 and 3306 open.
-</div>
-</p>
-
-<a name="cleanup"> </a>
-<h2>Cleanup _NAMELINK(cleanup)</h2>
-
-<p>
-You can terminate the entire cloud application with a single command as
-well. The first thing to note is the <i>run name</i> which is printed
-out in the first line of the boot output:
-<tt class="panel"> <pre>
-Starting up run c80e7e2c
-</pre></tt>
-In out case it is <i>c80e7e2c</i>. To terminate the launch run the following command:
-
-<tt class="panel"> <pre>
-$ cloudinitd -v -v -v terminate c80e7e2c
-Terminating c80e7e2c
-Begin terminate level 2...
- Started wordpress
- SUCCESS service wordpress terminate
- hostname: None
- instance: i-ca3807a5
-SUCCESS level 2
-Begin terminate level 1...
-Begin terminate level 1...
- Started mysql
- SUCCESS service mysql terminate
- hostname: None
- instance: i-f8380797
-SUCCESS level 1
-deleting the db file /home/bresnaha/.cloudinitd/cloudinitd-c80e7e2c.db
-</pre></tt>
-All of the resources associated with your cloud application will now
-be cleaned up.
-</p>
-
-<a name="whathappened"> </a>
-<h2>What Happened _NAMELINK(whathappened)</h2>
-
-<p>
-The following presentation shows what happened
-</p>
-<OBJECT ID="MediaPlayer" WIDTH="720" HEIGHT="540"
-STANDBY="Loading Windows Media Player components..." TYPE="application/x-oleobject">
-<PARAM NAME="FileName" VALUE="cid_wp.wmv">
-<PARAM name="autostart" VALUE="false">
-<PARAM name="ShowControls" VALUE="true">
-<param name="ShowStatusBar" value="false">
-<PARAM name="ShowDisplay" VALUE="false">
-<EMBED TYPE="application/x-mplayer2" SRC="http://www.mcs.anl.gov/~bresnaha/cid_wp.wmv" NAME="MediaPlayer"
-WIDTH="720" HEIGHT="540" ShowControls="1" ShowStatusBar="0" ShowDisplay="0" autostart="0"> </EMBED>
-</OBJECT>
-
-<a name="launchplan"> </a>
-<h2>Launch plan _NAMELINK(launchplan)</h2>
-<p>
-The details of the launch are found in the launch plan. The first file is
-<i>top.conf</i>:
-
-<tt class="literal"> <pre>
-[defaults]
-iaas_key: env.CLOUDBOOT_IAAS_ACCESS_KEY
-iaas_secret: env.CLOUDBOOT_IAAS_SECRET_KEY
-localsshkeypath: env.CLOUDBOOT_IAAS_SSHKEY
-sshkeyname: env.CLOUDBOOT_IAAS_SSHKEYNAME
-
-[runlevels]
-level1: mysql_level.conf
-level2: wp_level.conf
-</pre></tt>
-
-Here we see above that key security information is gathered from the
-environment variables (this is why we had to set the prior to launch
-in the quick start). We also see that there are two run levels. The
-first handles the MySQL server, and once that is done, The second uses
-it to handle the wordpress service.
-</p>
-
-<p>
-If we look at the two run level files <i>mysql_level.conf</i> and
- <i>wp_level.conf</i> we see that each has a section that starts with
-<i>svc</i>. What follows <i>svc-</i> is the name of the service to be
-described. In svc-wordpress and svc-mysql
-we see three similar values and three different ones.
-First lets look at the similar values:
-<tt class="panel"> <pre>
-ssh_username: ubuntu
-image: ami-ccf405a5
-allocation: m1.small
-</pre></tt>
-These lines tell cloudinit.d to launch the image name <i>ami-ccf405a5</i>
-(this is a standard ubuntu10.10 image) as a m1.small instance. The
-<i>ssh_username</i> tells cloudinit.d which username can be accessed with
-the previously established keys.
-</p>
-<p>
-Those line are enough to establish two base virtual machines in the associated
-cloud. From there the next thing to do is customize these VMs to do their
-needed jobs, become a mysql server and a wordpress server. The next three
-lines of the configuration file handle this.
-</p>
-<p>
-bootpgm points to a script that is copied into the virtual machine
-where it is run. This script should download, install, and configure
-the machine to do its job. In the case of the MySQL server software
-is installed with apt-get and configured. In the wordpress case
-wordpress is downloaded and installed.
-</p>
-<p>
-Further, the hostname where
-the MySQL service is running is passed to the wordpress VM so that it
-can connect to it. This is handled with the <i>deps</i> directive and the
-<i>bootconf</i> directive. The files in this launch plan serve as a good
-example for how this works.
-</p>
-
-<a name="troubleshooting"> </a>
-<h2>Trouble Shooting _NAMELINK(troubleshooting)</h2>
-
-<p>
-When a service is launched a series of log files are created under:
-~/.cloudinitd/&lt;run name&gt;. Valuable information about the progress
-of a launch can be found in these directories.
-</p>
-
-<br />
-
-_NIMBUS_CENTER2_COLUMN_END
-_NIMBUS_FOOTER1
-_NIMBUS_FOOTER2
-_NIMBUS_FOOTER3
-
View
BIN  docs/src/platform/cloudinitd/wordpress.tar.gz
Binary file not shown
Please sign in to comment.
Something went wrong with that request. Please try again.