Audrey Overview

Audrey Overview

Audrey is a collection of functionality spread across the Aeolus Project that enables post-boot configuration. It is made up of two main components: the Audrey Agent, which is installed on the launched instance and executes configuration scripts; and the Configserver, which is a separate server running in a cloud environment and coordinates instance configuration delivery.

Glossary

component outline: An image descriptor, which indicates the OS, packages to install, repositories where packages are located, and additional information that can be included in the image.

image: A disk image that contains an OS and installed packages and files. It serves as the basis for a virtual machine and is compiled from a component outline.

component blueprint: An instance descriptor, which indicates the image to launch, and any post-boot configuration to include for the running instance.

instance: A running virtual machine. In the case of Aeolus, an instance is started from Conductor and based on a component blueprint.

application blueprint: A collection of component blueprints that indicates how the components will interact with each other.

application: A collection of instances grouped together by their relationships defined in the application blueprint.

Post-boot configuration

In Audrey, the Audrey Agent on the instance requests configuration information from the Configserver and executes that configuration after the instance boots. The post-boot configuration consists of a set of service definitions, where each service definition is an executable script and a set of configuration files.

Services

An Audrey Service comprises an executable script, an optional list of configuration files, and an optional list of parameters. The service definitions for an instance are defined in a component blueprint. When the instance is launched, the Audrey Agent executes the executable script for each service definition. The executable script is responsible for understanding how to interpret the service parameters and what to do with the configuration files (if any exist).

Instance configuration dependencies

Instances can share configuration information within an application by defining configuration dependencies between components. For example, an application blueprint might be composed of a wordpress server and a database server as two separate components (i.e., separate instances). Before configuring the wordpress server, the database server needs to be configured and available. However, there is no guarantee about the launch order of the instances. So, in order to ensure that the database server is available, the configuration for the wordpress server can depend on a configuration parameter from the database server. The database server will “expose” the shared configuration parameter only after the database is configured and available.

To see an example application blueprint that illustrates this, see Appendix C.

Audrey Components

Audrey Agent

Configserver

Complete picture

Appendices

Appendix A: Component Outline example

Appendix B: Component Blueprint example

Appendix C: Application Blueprint example

<deployable name="Wordpress Multi-Instance Deployable">
  <description>This is an example of a multi deployment that deploys wordpress across an apache and mysql instance</description>
  <assemblies>
    <assembly name="apache" hwp="hwp1">
      <image id="beedb0f9-ca05-46a1-bcbb-704887752d8e" build="bf1de77e-50c6-43a3-b38b-ae9e01924c4d"/>
      <services>
        <service name="http">
          <executable url="http://radez.fedorapeople.org/wordpress-http.sh"/>
          <parameters>
            <parameter name="wp_name" type="scalar">
              <value>wordpress</value>
            </parameter>
            <parameter name="wp_user" type="scalar">
              <value>wordpress</value>
            </parameter>
            <parameter name="wp_pw" type="scalar">
              <value>wordpress</value>
            </parameter>
            <parameter name="mysql_ip" type="scalar">
              <reference assembly="mysql" parameter="ipaddress"/>
            </parameter>
            <parameter name="mysql_hostname" type="scalar">
              <reference assembly="mysql" parameter="hostname"/>
            </parameter>
            <parameter name="mysql_dbup" type="scalar">
              <reference assembly="mysql" parameter="dbup"/>
            </parameter>
          </parameters>
        </service>
      </services>
      <returns>
        <return name="hostname"/>
        <return name="ipaddress"/>
      </returns>
    </assembly>
    <assembly name="mysql" hwp="hwp1">
      <image id="beedb0f9-ca05-46a1-bcbb-704887752d8e" build="bf1de77e-50c6-43a3-b38b-ae9e01924c4d"/>
      <services>
        <service name="mysql">
          <executable url="http://radez.fedorapeople.org/wordpress-mysql.sh"/>
          <files>
            <file url="http://radez.fedorapeople.org/dbup.rb"/>
          </files>
          <parameters>
            <parameter name="wp_name" type="scalar">
              <value>wordpress</value>
            </parameter>
            <parameter name="wp_user" type="scalar">
              <value>wordpress</value>
            </parameter>
            <parameter name="wp_pw" type="scalar">
              <value>wordpress</value>
            </parameter>
            <parameter name="apache_ip" type="scalar">
              <reference assembly="apache" parameter="ipaddress"/>
            </parameter>
            <parameter name="apache_hostname" type="scalar">
              <reference assembly="apache" parameter="hostname"/>
            </parameter>
          </parameters>
        </service>
      </services>
      <returns>
        <return name="hostname"/>
        <return name="ipaddress"/>
        <return name="dbup"/>
      </returns>
    </assembly>
  </assemblies>
</deployable>