EaaS support scripts
Before running any of the bwFLA client scripts a corresponding docker container has to be downloaded. Assuming that client has installed "docker" application (tested against v1.8.1) only image pulling is required, e.g.:
docker pull eaas/bwfla:demo-august-15
After the operation finishes, client is able to run desired module by executing corresponding script. It is possible to run multiple containers (max. 1 per module) with the same public ip. However, if IP addresses are identical for one or more containers on the same node, then client needs to specify different ports for each such container. E.g.
./run-flavor-emucomp.sh --docker eaas/bwfla:demo-august-15 --public-ip-port 18.104.22.168:8080 ./run-flavor-imagearchive.sh --docker eaas/bwfla:demo-august-15 --public-ip-port 22.214.171.124:8081 \ --archive-dir /mnt/data/image-archive
When docker boots-up, the internally running application server will be accessible for the outside world via public IP and Port (in the above example '126.96.36.199:8080' and '188.8.131.52:8081' correspondingly) Docker takes care of temporary setting of 'iptables' rules such that client doesn't need to perform mapping of 'host <---> guest' ports (i.e. NAT). Make sure that your Firewall doesn't interfere with the rules set-up by Docker application.
NOTE: In the following, explanation of the two mandatory parameters (
--public-ip-port) will be omitted.
./run-flavor-emucomp.sh --docker eaas/bwfla:demo-august-15 --public-ip-port 184.108.40.206:8080
This script starts 'emucomp' module, which is responsible for running individual emulators on dedicated compute nodes (possibly in a cluster/cloud environment). As of now emulators supported in the docker are the following: Qemu, SheepShaver, Basilisk, DosBox, Hatari.
./run-flavor-eaas.sh --public-ip-port 220.127.116.11:8082 --docker eaas/bwfla:demo-august-15 \ --emucomp 18.104.22.168:8080,4 --emucomp 22.214.171.124:8080,8
This module serves as a scheduler/proxy node for individual 'emucomp' modules deployed in the cloud/cluster.
When starting the module at least one
--emucomp <VALUE> has to be specified on the command line. Repeat the
argument if multiple 'emucomp' modules have to be connected to this 'eaas' module.
Value of the arguments is composed of the IP:PORT of the 'emucomp' to be connected and the number of sessions
it should supports (usually set to the node's CPU-count) coming after comma.
./run-flavor-imagearchive.sh --docker eaas/bwfla:demo-august-15 --public-ip-port 126.96.36.199:8081 \ --archive-dir /mnt/data/image-archive
This script run the 'imagearchive' module. It requires the location of the image archive directory as a parameter. The 'nbd-export' directory should not contain any symbolic links that point to locations outside of the image-archive directory (i.e. only relative paths). NOTE: This is due to the fact that the image-archive is mounted inside the docker container, which in turn has no access to the host's file-system.
./run-flavor-workflows.sh --docker eaas/bwfla:demo-august-15 --public-ip-port 188.8.131.52:8083 --image-archive 184.108.40.206:8080 --eaas-gateway 220.127.116.11:8080 [--object-files test/object-files --base-uri http://object.store/objects/] [--object-metadata test/object-metadata] [--swarchive-incoming test/swarchive/incoming] [--swarchive-storage test/swarchive/storage]
This script starts the 'Workflows' module, which represents a reference implementation of bwFLA usage by a client. It contains sample preservation workflows which include archival "ingest/access" of digital objects, full disk images, any accompanying software/libraries.
--image-archive should point to a location of an image-archive, which contains base image of emulated systems,
their derivatives, etc.
--eaas-gateway should point to a location of an EAAS module, which will serve as a main 'facade' for accepting
and performing emulation tasks by using one or more 'emucomp' modules on dedicated compute-nodes.
--object-files should point to a directory containing user-objects that will appear in the 'ingest' workflow.
The directory should contain objects in the form "OBJECT_NAME/OBJECT_NAME.iso". E.g. 'test/object-files/OBJECT1/OBJECT1.iso'.
--base-uri must be specified iff.
--object-files was specified previously. This argument defines the URL-prefix for
the location of the objects via which the object can be download through HTTP protocol ('emucomp' module needs to be able to
download the object to inject it into the environment).
--object-metadata argument is specified the the metadata for ingested objects will be kept permanently on the host
inside the corresponding directory. This metadata results from the ingest workflow and describes the object's rendering
environment, which can be tested via 'access' workflow.
--swarchive-incoming is specified, then it must point to the location of the directory which contains software subject
to 'Software Archive' workflow.
--swarchive-storage is specified, then it must point to a directory which will keep the content and the metadata of the
software ingested by the 'Software Archive' workflow.