https://github.com/timstaley/ansible-comet

Ansible role for provisioning a Comet VOEvent broker
https://github.com/timstaley/ansible-comet

ansible ansible-role comet voevent

Last synced: about 2 months ago
JSON representation

Ansible role for provisioning a Comet VOEvent broker

• Host: GitHub
• URL: https://github.com/timstaley/ansible-comet
• Owner: timstaley
• Created: 2015-06-23T16:48:21.000Z (over 9 years ago)
• Default Branch: master
• Last Pushed: 2018-06-20T22:53:12.000Z (over 6 years ago)
• Last Synced: 2024-07-30T16:55:20.115Z (5 months ago)
• Topics: ansible, ansible-role, comet, voevent
• Language: Shell
• Homepage: https://galaxy.ansible.com/detail#/role/5895
• Size: 23.4 KB
• Stars: 0
• Watchers: 3
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# timstaley.comet

An [Ansible][] [role][] that provides an installation of the 

[Comet][] [VOEvent][] broker.

[Ansible]: http://www.ansible.com/configuration-management

[role]: http://docs.ansible.com/ansible/playbooks_roles.html

[VOEvent]: http://voevent.rtfd.org

[Comet]: http://comet.readthedocs.org/

## Outline

This role will install the bare minimum to get a

[Comet](http://comet.readthedocs.org/) instance up and running, and won't

actually do anything with the VOEvents they receive. The Comet-invocation script

can be supplied as a role-argument, so you can easily change that to set up

passing of VOEvents to your own custom code.

## Deployment details

The scripts create a pair of non-sudo users, defined by default as 

`cometdeploy` and `cometserve`.

VOEvent handling code and virtualenvs are dropped into ``/home/cometdeploy``,

then run in read-only mode as the `cometserve` user (this provides extra

security in the worse-case scenario that Comet has some serious security exploit

hole, e.g. to malformed packets). Logs etc are dumped into 

`/home/cometserve/working_dir`. 

## Usage

### Setup

Note that building the LXML package (which is a dependency) usually requires

significantly more than 512MB of RAM. 

For the test-VM setup we make use of a

swapfile, via a ready-made role from

[kamaln7](https://github.com/kamaln7/ansible-swapfile). 

You'll need to install the role using the `ansible-galaxy` command line tool

before running the tests.

### Vagrant VM for testing

To pull up a working VM with Comet installed:

    cd vagrant

    ansible-galaxy install -r requirements.txt

    vagrant up

    

    

### Ansible on a pre-existing Ubuntu installation

Running against a pre-existing machine is a bit more complicated because there 

are more possible variables, and you may want to familiarize yourself with 

the Ansible docs first. In short, you'll need to:

 - Configure your ansible 

  [inventory](http://docs.ansible.com/intro_inventory.html#inventory)

  to reach the desired machines. Test with e.g. `ansible -m ping all`.

 - Modify [test-comet-role.yml](test/test-comet-role.yml) as required. 

  You probably don't want/need swapfile configuration, and you will need to set 

  the `hosts` to match your inventory.

 - Run your new [playbook](http://docs.ansible.com/ansible/playbooks.html) 

  file using the `ansible-playbook` command.