Appliance Development
and Conary
Stephanie Watson
Flourish Conference || April 4, 2008
Appliance Development and Conary
Topics
- The Appliance Concept
- What is an appliance?
- Why should I use appliances?
- Why Conary for Appliances?
- Application to Appliance Process
To step through a hands-on experience in using the information covered in this presentation, see Application to Appliance: A Hands-on Guide at the rPath Wiki (wiki.rpath.com).
To discuss Conary and appliance development with other community users, visit the rPath Forum (forum.rpath.com).
Presenter Stephanie Watson, 1996 graduate of NCSU, is a technical writer and traininer with rPath, Inc., and may be contacted by email at stef@rpath.com.
The Appliance Concept
What is a software appliance?
- Application software + just enough OS
- Fast and easy server deployment and configuration
- Simple administration interface
- Updates do not conflict with deployed configuration
- Support focused on the application
What makes a software appliance?
A "software appliance" is application software plus just enough operating system to run that software on server class harware or as a virtual machine (making it a "virtual appliance"). Furthermore, the software appliance has an administrative interface that does not require familiarity with the underlying operating system in order to perform ongoing maintenance.
On the receiving end, a customer of a particular software application can focus on a hardware purchase or virtual machine allocation sufficient for the appliance without budgeting for a separate operating system installation to support the application. After receiving installation media, the customer can step through a quick install and straightforward configuration and have a successfully deployed server in an hour or two. Besides the simple administrative interface, customers can have confidence that appliance updates will work without concern about compatibility with custom configurations.
By reducing the time and cost of installing, configuring, and maintaining the server software, the software customer can experience a larger value in the software purchase itself.
On the development end, software developers can spend less research and development resources on OS compatibility and certification and put more effort into the core application. The vendors can also, in turn, assure that support is focused on the application and not flooded with issues created by custom configurations on one of several server OS environments.
The Appliance Concept
Changing Server Management
- General-purpose OS + application software...
- Install OS, then application software, then step through hours of setup and configuration
- Evaluate updates, plan downtime, and troubleshoot update issues
- Troubleshooting and maintenance requires OS familiarity
- Software appliances...
- Install and configure within minutes
- Schedule an update window and click one button to update
- Troubleshooting and maintenance can be done in a customized GUI
In terms of system administration, software that is installed on a general-purpose operating system may require hours of setup and configuration. Appliances, though, are designed to be installed and configured within minutes with the underlying operating system automatically configured and optimized to run the application software.
Server management is also simplified with appliances. Updates to software on a general-purpose OS may require extensive planned downtime with a large window for troubleshooting updates. An appliance is designed to update either automatically or with the click of a single button in a GUI, and updates are not likely to conflict with the deployed configuration.
In addition to simplified deployment and updates, appliances are designed to eliminate the need for OS familiarity when troubleshooting and performing regular maintenance. In the appliance model, a user should need little more than a basic custom GUI (such as a web interface) to perform administrative tasks.
The Appliance Concept
Changing Software Development
- General-purpose OS + application software...
- Software is developed for multiple OSs
- Developers must "certify" the software for each OS
- Software updates are manual and can have unpredictable points of failure
- Software appliances...
- Just enough OS is wrapped around the software
- OS components are custom-tailored for the appliance
- Appliance updates are automatic or one-click and are tested on appliance software before release
Software developers can also see benefits by working in an appliance model. When software is developed for a general-purpose operating system, developers may have to develop code to work for several contrasting OSes. Also, they must "certify" the software to work in each OS, which can be costly in addition to time-consuming, and which can present an obstacle for smaller companies wishing to break into the server software market. Even when the software is certified, providing updates does not guarantee that those updates will work on all systems, and the software vendor will still need to provide extensive support when updates go awry. Appliance updates can be tested and released with confidence that custom configurations on deployed appliances will not create conflicts with those updates..
The Appliance Concept
Ideal Choice for Virtualization
- Appliances have "just enough OS" instead of an entire general-purpose OS
- Appliances can be deployed quickly as needed in a virtual environment
- Tools like rBuilder create images ready to be launched in one of several virtual environments
Virtualization is a growing trend to better make use of hardware resources and to conserve money and energy used to run servers in a corporate environment. Appliances are the ideal way to provide software for virtual environments. Virtual appliances are software appliances deployed as virtual machines on one of several common hypervisors. Virtual appliances take up less resources by having just enough OS to run the application. Also, virtual appliances can be deployed quickly as needed in a virtual environment.
rPath's rBuilder is the first product designed to take a binary set of packages and create images ready to launch in any of several virtual envirnments.
Why Conary for Appliances?
To make it smaller...
- Packaged files are assigned to components
- Dependencies determined at the file level
- Dependencies resolved at the component level, not the package level
Why Conary for Appliances?
To make updates more reliable...
- Searches for updates in a consistent set of locations
- Determines and downloads only the changes needed to update to the desired version
- Dependencies are automatically resolved
- File updates use diff+merge operations to ensure user changes are saved
- Update an entire system with one command
Why Conary for Appliances?
To provide reliable rollbacks...
- Built-in rollback stack
- Applied like "reverse updates"
Why Conary for Appliances?
A simple recipe defines the appliance...
- Single top-level Conary group defines the appliance
- The rPath Appliance Platform automatically includes just enough OS
- Scripts can provide one-time runs of pre-update or post-update operations
Why Conary for Appliances?
Packaging software is efficient...
- Most build requirements are automatically discovered
- Built-in Python methods provide most common build tasks
- Existing packages can be shadowed and modified without forking development
- Particular versions of packages can be grouped to install and manage together
- Build simultaneously in multiple flavors to accomodate certain install conditions
- rMake tool provides further features
Why rBuilder for Appliance Development?
- Single tool provides Conary repositories and image building features
- Browse repository contents in a web interface
- Generate images ready to deploy in several hardware or virtual deployment scenarios
- The same resources used to create an image can be used to provide ongoing updates to the software
How do I build an appliance?
The basic equation...
 |
+ |  |
= |  |
How do I build an appliance?
The basic appliance group recipe...
loadSuperClass('group-appliance=conary.rpath.com@rpl:1')
class GroupExample(ApplianceGroupRecipe):
name = 'group-example'
version = '0.1'
def addPackages(r):
r.add('example-application')
How do I build an appliance?
Add rAPA for administration...
loadSuperClass('group-appliance=conary.rpath.com@rpl:1')
class GroupExample(ApplianceGroupRecipe):
name = 'group-example'
version = '0.1'
# Set the label from which to obtain rAPA
rapaLabel = 'raa.rpath.org@rpath:rapa-3'
def addPackages(r):
r.add('example-application')
# Add a package for any rAPA customizations
r.add('rapa-customizations')
How do I build an appliance?
Add modified packages...
loadSuperClass('group-appliance=conary.rpath.com@rpl:1')
class GroupExample(ApplianceGroupRecipe):
name = 'group-example'
version = '0.1'
rapaLabel = 'raa.rpath.org@rpath:rapa-3'
def addPackages(r):
r.add('example-application')
r.add('rapa-customizations')
# Replace a rAP package with a shadowed and
# modified version, custom to the appliance
r.replace('core-rap-package')