This Ansible playbook is used to build the components required to run The Genomics Virtual Laboratory (GVL). The playbook is heavily reliant on the Galaxy CloudMan playbook and is intended for anyone wanting to deploy a customised version of the GVL on a public or private cloud. The overall process for building the GVL follows very closely the one for building Galaxy on the Cloud and hence it is recommended to first read this page that describes the high-level concepts of the build process - just use this playbook instead of the one mentioned in that document.
There are several roles contained in this playbook; the roles manage the build process of different components:
GVL-Image: Installs components required for a GVL image snapshot. Implements only the differences from a base CloudMan image.
GVL-FS: Installs components required for a GVL filesystem snapshot. Implements only the differences from a base CloudMan filesystem.
These roles are intended to be run on an Ubuntu (14.04) system.
To get going, it is necessary to clone this repository and then pull in all the dependent roles:
git clone https://github.com/gvlproject/gvl.ansible.playbook.git
ansible-galaxy install -r requirements.yml -p roles
The easiest method for building the base machine image is to use Packer.
Once you have it installed, check any variables specified at the top of
packer.json, check the formatting of the file with packer validate packer.json,
and run it with packer build packer.json. The command will provision an instance,
run the Ansible image build role, and create a Machine Image. By default, images will be
created on both AWS and the NeCTAR cloud (OpenStack-based). Custom options
can be set by editing packer.json, under the extra_arguments section.
Alternatively, to build an image without Packer, make sure the default values
provided in the gvl.ansible.image role and gvl.ansible.filesystem role suite
you. Create a copy of inventory/builders.sample as inventory/builders, launch
a new instance and set the instance IP address under gvl-image-hosts host
group in the builders file.
ansible-playbook -i inventory/builders playbook.yml --tags "gvl-image" --extra-vars vnc_password=<choose a password> --extra-vars psql_galaxyftp_password=<choose a password> --extra-vars cleanup=yes
On average, the build time takes about 3 hours. Note that after the playbook
has run to completion, you will no longer be able to ssh into the instance! If
you still need to ssh, set --extra-vars cleanup=no in the above command.
If you run with that flag, before creating the image, you must rerun the
playbook with that flag set.
A configuration file exposing adjustable options is available under
group_vars/image-builder.yml. Besides allowing you to set some
of the image configuration options, this file allows you to easily control which
steps of the image building process run. This can be quite useful if a step fails
and you want to rerun only it or if you're just trying to run a certain steps.
Launch an instance of the machine image built in the previous step and when
CloudMan comes up, choose the Cluster only with transient storage option
(under Additional startup options). Insert the instance IP address in
inventory/builders file under galaxyFS-builder host group and change the value
of psql_galaxyftp_password in group_vars/all; run the role with
ansible-playbook -i inventory/builders playbook.yml --tags "gvl-fs" --extra-vars psql_galaxyftp_password=<choose a password>
Running above command will automatically install a number of Galaxy tools. The list of
tools that can be installed can be changed by editing shed_tool_list.yaml.gvl.
You may also want to update the default container
to which the GVL filesystem archive will be uploaded.
This playbook requires a number of configuration options for the Galaxy application,
CloudMan application, PostgreSQL the database, as well as the glue linking those.
The configuration options have been aggregated under
defaults/main.yml in each role, and represent reasonable defaults.
Keep in mind that changing the options that influence how the system is deployed
and/or managed may also require changes in CloudMan.