...
- DuraStore - this web application provides the access to and management of storage resources, which includes handling the storage portion of the DuraCloud REST API
- StorageProviders - this set is made up of the StorageProvider interfaces and the implementations which connect to distinct cloud stores (currently Amazon S3, Rackspace CloudFiles, and EMC AtmosWindows Azure)
- DuraService - this web application handles the deployment and management of services within DuraCloud, which includes handling the services portion of the DuraCloud REST API
- DuraReport - this web application handles the generation of storage and service reports and provides the reporting portion of the DuraCloud REST API
- DurAdmin - this web application is the UI front end of DuraCloud, it provides users with a view into the information available from the other applications. DurAdmin uses the REST APIs of the other applications to communicate with them.
- Services - the set of all deployable services, as well as the support projects that allow the DuraCloud services infrastructure to function
- ComputeProviders - this set is made up of the ComputeProvider interfaces and the implementation which connect to distinct cloud compute services (currently Amazon EC2, using the typica library)
- Security - handles security for the DuraCloud applications
- Common - a set of projects which provide utilities for other portions of the codebase to reuse
The DuraCloud software, by its very nature, is designed to be integrated with underlying cloud storage and compute providers. As may be expected, these integrations are necessary for the system to be properly exercised. In order for DuraCloud to connect to these underlying providers, appropriate credentials must be available. The build process can be accomplished without these credentials, however, the next step of initializing the deployed applications depend on this informationprovided as part of the application initialization step. It is recommended that you acquire the necessary storage provider credentials prior to attempting to set up DuraCloud. Only one storage provider is required to run DuraCloud. The storage providers which are currently available supported are:
This guide lays out the two tiers of building/testing the baseline:steps necessary to begin using DuraCloud:
- Build and deploy the DuraCloud web applications
- Set up the OSGi services container
- Initialize the DuraCloud applications
- build with unit tests
- build with OSGi services container integration tests
Although this document is written from a Linux environment perspective, analogous builds/installations have been tested in Windows (but may have limitations, as noted below). Any comments or feedback are welcomed.
...
- Maven 2.2.1 or above
- Tomcat 6.x or above
- Java 6 (note: the djatoka service has compatibility issues with open-jdk)
- Subversion
...
Setting up DuraCloud
Info | ||
---|---|---|
|
Build
...
and deploy the DuraCloud web applications
- Check out latest stable release from Subversion repository
Code Block svn co https://svn.duraspace.org/duracloud/tags/duracloud-1.1.0
- Set environment variables
Code Block export JAVA_OPTS="-XX:MaxPermSize=256m" export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=1024m"
- Configure Tomcat
- Add to $CATALINA_HOME/conf/tomcat-users.xml
No Format <tomcat-users> <role rolename="manager"/> <role rolename="admin"/> <user username="[ANY-USERNAME]" password="[ANY-PASSWORD]" roles="admin,manager"/> </tomcat-users>
- Add to $CATALINA_HOME/conf/tomcat-users.xml
- Start tomcat
Code Block $CATALINA_HOME/bin/startup.sh
- Configure Maven2
- Add tomcat user to $M2_HOME/conf/settings.xml
No Format <servers> <server> <id>tomcat-server</id> <username>[ANY-USERNAME]</username> <password>[ANY-PASSWORD]</password> </server> </servers>
- Add tomcat user to $M2_HOME/conf/settings.xml
- Build
- From top of source tree
Note: Due to the length of time required to execute integration tests as well as the nature of "eventually consistent" cloud services to not cooperate with a synchronous test suite, these tests are not included in the build by default.Code Block mvn clean install
- From top of source tree
...
Set up the OSGi services container
...
This step assumes the successful completion of the previous build instructions
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
|
Once the
...
OSGi services
...
container is running, check to ensure that it was created properly
- In the console where the "run
...
- " script was executed, an "osgi" prompt should be available. If it is not available, hitting enter should bring it up.
- Type "ss" and hit enter. This should list all of the available bundles. This list should include 50 items, all of which are either in the ACTIVE or RESOLVED state.
Initialize the DuraCloud applications
- Use the application initialization (app-config) utiltiy to configure the deployed DuraCloud applications
- Build app-config utility, from within the //app-config module
Code Block mvn assembly:assembly
- Run the app-config utility
Code Block java -jar target/app-config-1.1.0-driver.jar <init.props>
- The init.props file is a configuration file which specifies all of the information necessary for the DuraCloud applications to run. An example of this file can be found at //app-config/src/main/resources/init.props. This file will need to be updated to match your environment.
- Build app-config utility, from within the //app-config module
Optional items
Code coverage
- If you plan on using Clover, the following element needs to be added to your maven 'settings.xml'
No Format <profiles> <profile> <id>profile-clover</id> <activation> <property> <name>profile</name> <value>clover</value> </property> </activation> <properties> <cloverLicense>[LOCATION-OF-clover.license-FILE]</cloverLicense> </properties> </profile> </profiles>
- To run clover
Code Block mvn clover2:instrument clover2:aggregate clover2:clover -Pprofile-clover
- A report will be generated in the following directory:
//target/site/clover/
Service tests within OSGi (Linux only)
- Assuming that the OSGi services container is set up and running (as described above), tests that deploy services into the OSGi environment may be run
- From inside the //integration-test module
Code Block mvn install -PrunServicesAdminTests
- From inside the //integration-test module
Logging
- DuraCloud uses the SLF4j logging framework backed by the LogBack implementation
- By adding either a logback.xml or logback-test.xml file on the classpath, logging configuration can be customized
...
- This tool provides a commandline interface for interacting with the 'services-admin' installed in a running OSGi container (see notes above for starting the container)
- To build and run the CLI, from within the //servicesadminclient module
Code Block mvn assembly:assembly java -cp target/servicesadminclient-[VERSION]-cli.jar
...
- This utility takes a config file (example at //app-config/src/main/resources/init.props) and initializes an instance of duracloud
- Until the applications durastore and duraservice are initialized, they are non-functional
- To build and run the app-config utility, from within the //app-config module
Code Block mvn assembly:assembly java -jar target/app-config-1.1.0-driver.jar
StoreClient package
- To create a distributable zip of the storeclient and its dependencies, from within //storeclient run
Code Block mvn install -Ppackage-client
- The zip will be found at /storeclient/target/store-client.zip
...
If you would like to run the ImageConversionService, you must install ImageMagick and have its /bin directory in your PATH, which is essentially what the ImageMagickService does in a linux environment.
root user
application config
...