Getting Started
Quick Start Guides
- Amazon Web Services
- Elastic Block Store Models
- Azure Storage Service
- BlueLock vCloud
- Cloud Sigma
- Eucalyptus
- File System
- Go Grid
- HP Cloud Services
- IBM Developer Cloud
- OpenStack
- Rackspace
- RimuHosting
- Terremark eCloud
- Terremark vCloud Express
Release Notes
- 1.5.0-alpha.6
- 1.5.0-alpha.5
- 1.5.0-alpha.4
- 1.5.0-alpha.3
- 1.5.0-alpha.2
- 1.5.0-alpha.1
- 1.4.0
- 1.4.0-rc.3
- 1.4.0-rc.2
- 1.4.0-rc.1
- 1.3.1
- 1.3.0
- 1.3.0-rc-2
- 1.3.0-rc-1
- 1.2.2
- 1.2.1
- 1.2.0
- 1.1.1
- 1.1.0
Maven Sites and Javadocs
- HEAD (Javadoc)
- latest release (Javadoc) permalink
- 1.5.0-alpha.6 (Javadoc)
- 1.5.0-alpha.5 (Javadoc)
- 1.5.0-alpha.4 (Javadoc)
- 1.5.0-alpha.3 (Javadoc)
- 1.5.0-alpha.2 (Javadoc)
- 1.5.0-alpha.1 (Javadoc)
- 1.4.0 (Javadoc)
- 1.4.0-rc.3 (Javadoc)
- 1.4.0-rc.2 (Javadoc)
- 1.4.0-rc.1 (Javadoc)
- 1.3.1 (Javadoc)
- 1.3.0 (Javadoc)
- 1.3.0-rc-2 (Javadoc)
- 1.3.0-rc-1 (Javadoc)
- 1.2.2 (Javadoc)
- 1.2.1 (Javadoc)
- 1.2.0 (Javadoc)
- 1.1.1 (Javadoc)
- 1.1.0 (Javadoc)
User Guides
- Using Blob Store API
- Using Compute API and Tools
- Google App Engine
- VMWare vCloud
- Terremark
- File System Provider
- Init Builder
- Using jclouds with Apache Karaf
- Using EC2
- Using Maven
Samples & Examples
FAQs
Reference
- jclouds Rationale and Design
- Location Metadata Design
- Compute API Design
- Columnar Data Design
- jclouds API
- jclouds OAuth Integration
- Using jclouds with Apache Felix OSGi Container
- Pool Design
- Load Balancer Design
- Logging in jclouds
- VMWare Integration Approach & Design
- Supported Providers
- Apps that use jclouds
- Using Provider Metadata
Developer Resources
- Contributing to jclouds
- Provider Testing
- Contributing to Documentation
- Using Eclipse
- jclouds Continuous Integration
- Provider Metadata
Old versions
Release Notes
- 1.0.0
- 1.0 Beta 8
- 1.0 Beta 7
Maven Sites and Javadocs
Design and Usage of the InitBuilder components
Introduction
InitBuilder gives you a standard, predictable and portable way of controlling
the lifecycle of your applications at a process level. For example, using InitBuilder,
you to setup something like Tomcat on your Windows laptop and move it to a remote Linux machine.
TODO example
InitBuilder introduces standard system variables, directory structures and
writes portable initialization scripts. The initialization scripts help level
the operating environment across operating system platforms.
Standard directory paths help you avoid multi-tenancy conflicts and the need to access the root user.
Vocabulary
- Platform - a cross-platform product, like JBoss, Tomcat, Apache httpd, which as base binaries and configuration applicable to all instantiations of it. Platforms that do not work on most operating systems are out of scope. These include products that only exist on Windows such as IIS
- Instance - an instance of a platform, most often implemented as a process on the host operating system. Multiple instances must be able to run on the same host without conflicts.
- Environment Variable - Environment variables are a set of dynamic named values that can affect the way running processes will behave on a computer. ref
- Environment Module - Introduces environment variables for a particular scope. These are overridable.
Design
Environment Management
Environment Variables are typically set in a user profile.
However, this user profile is generally not built from a source controlled system, and
is unpredictable at best. Process portability requires that we ensure that important variables such as
ones that maintain time zone information (TZ on Unix) and system library search path
(LD_LIBRARY_PATH on Unix or PATH on windows) do not bleed in from the user or the operating system.
When these are not controlled, application portability cannot be guaranteed.
This problem is well known, and projects such as Modules seek to address it.
Like other parts of InitBuilder, this process has to be portable. The "important" environment variables
are not the same across Windows and UNIX-like operating systems like Linux.
InitBuilder process involves the same process, and implements it differently based on the os.
Basically, the script generated by InitBuilder has a sync command.
This sync command reads environment modules and creates a script or service used to run the Instance in the background.
Clearing the Environment
There are a couple environment variables that are named differently on operating system families.
We have normalized names of these so that they can be set in a cross-platform way.
- LIBRARY_PATH - In unix this is
LD_LIBRARY_PATH; in windows, this is an addition toPATH; in java, this isjava.library.path
Environment Modules
Environment modules are exposed in two ways shell functions and source files. These are used to compose the runtime environment of the Instance.
- shell functions - defined in the init script itself to reduce footprint on the host.
- source files - files named
environment.bash(on unix) orenvironment.cmd(on windows).
Environment scopes
CrossPlatform - shell function - In order to work cross-platform and without creating a lot of complexity, some shortcuts are taken.
For example, the process depends on theps auxwwwcommand to work.
As such, on Solaris hosts, this implies /usr/ucb/ps be found first in thePATH.
Eventhough the path /usr/ucb isn't present on other UNIX-style hosts, paths that are not found do not hurt anything. Pragmatically, we prefix /usr/ucb to all unix paths so that we don't need to write a function to determine this per-platform.Instance - shell function - sets up variables like
INSTANCE_NAME,LISTEN_HOST, andLISTEN_PORTPlatform - shell function - sets up additional variables like PATH and NATIVE_PATH, and binds args to the above parameters.
Deployment - optional source file - any deviations needed for the specific application, such as additional java args or classpath entries (in Java), or additional NATIVE_PATH for things like apache httpd.
Operations
All operations need a minimum environment setup such that operations such as ps can operate.
Accordingly, the init script InitBuilder creates always does the following:
- zero out environment variables known to conflict with applications
- load CrossPlatform module
Sync
Sync is a process that composes the environment of a process. This is not performed inline,
as the running process may have a different version of variables from the prior one.
Accordingly, Sync is used to establish a new environment for a process to run.
In UNIX, this implies creation of a shell script, In Windows, this implies creation of a Service.
Stop the service, if not already running
- this unlocks files that we may need to overwrite. For example, in Windows the corresponding service must be stopped before it can be re-written.
Load Instance module
Load Platform module
Load Deployment module
Write new Start process
In Unix, this is technically a shell script that can be
nohuped.
This is named${INSTANCE_NAME}.bashin the${CONFIG_DIR}In Windows, we do two things: create a shell script and also a background process
- The shell script can be used to run the process in the foreground (as supported).
This is named%INSTANCE_NAME%.cmdin the%CONFIG_DIR% - In Windows, it is typically difficult to get a simple shell script to operate
in the background as a service non-attached to the current user.
As such, we use some tool to generate a service called%INSTANCE_NAME%
- The shell script can be used to run the process in the foreground (as supported).
Stop
Stop the instance running in the background. This is typically performed by
looking for INSTANCE_NAME in the process table. This implies that the INSTANCE_NAME
must be unique in the process table.
Run
Run the instance in the foreground (where possible). This technically invokes the
${INSTANCE_NAME}.bash or %INSTANCE_NAME%.cmd file previously created by Sync
Start
Start the process in the background. In Unix, we nohup the ${INSTANCE_NAME}.bash.
In Windows, we executenet start %INSTANCE_NAME%`;
Status
Returns 0 if the process is running, and 1 if the process isn't.