Alongside Richard's good points is how to get an installation of
Brooklyn into that state.
I would like be able to run a command on my machine to provision
Brooklyn on a remote machine. Something like:
$ brooklyn bootstrap --location jclouds:cloud:region --properties file
--catalog file --variousHaOptions--otherOptionsIHaventConsidered
The location option is a standard location spec and is used as direction
to provision a machine for the remote Brooklyn or to use a
pre-provisioned machine. The referenced properties and catalogue files
are copied to the provisioned machine. They are not necessarily the same
files that are used by the local Brooklyn. Per the variousHaOptions some
number of machines are provisioned in a HA setup. There will be several
more flags needed that I haven't considered.
There is no need for the REST server or jsgui to be launched. Once the
remote Brooklyn is running successfully (or is not running and there's
nothing else to try) the local Brooklyn terminates with useful log
messages indicating IPs of servers or problem diagnostics.
Sam
On 27/08/2014 13:15, Richard Downer wrote:
Duncan,
The key considerations are:
- Create a dedicated user for brooklyn (not root) and unpack the
distribution into a known location owned by this user
- Making sure the service starts at boot time - in the absence of
init.d scripts, the simplest way to do this is to add a line to
/etc/rc.local
- Create a location to store persistence data[1] - if you want this to
use HA, this must be on a shared storage system, such as an object
store or NFS NAS - and enable persistence when starting Brooklyn.
- If you want Brooklyn to be accessed over SSL (recommended when using
HTTP authentication to prevent credentials being sent in clear text
over the network) and/or on a low-numbered port like 80 or 443,
configure a web proxy server. nginx can do this, as can Apache httpd
with mod_proxy. You should then configure Brooklyn to listen only on
the localhost interface, to ensure that there is no non-SSL way to
remotely access Brooklyn.
- Consider how to monitor Brooklyn's log files, and how to safely back up.
[Anything else to add, community?]
You are right in saying that the current user guide is a bit too much
focussed on the desktop evaluation and code development aspects and
doesn't go into much detail about production deployments where
Brooklyn is a long-running process that starts on every boot. The team
has experience of deploying Brooklyn into more and more production and
production-evaluation environments recently and we've built up a good
knowledgebase about production environments, so it's mainly a case of
just getting our experiences written down and into the user guide.
We've also discussed development of init.d scripts and other items to
make a sysadmin's life easier when installing Brooklyn into
production. I personally would like to see RPM packages for deployment
onto CentOS/RHEL for an out-of-the-box, fully-integrated install.
Richard.
On 27 August 2014 06:29, Duncan Johnston Watt
<[email protected]> wrote:
If I want to stand up Brooklyn as a long running or "resident" service that
I can connect to remotely what's the recommended configuration?
The quickstart guide[1] assumes I'm running locally.
[1] http://brooklyn.incubator.apache.org/quickstart/
Best
--
Duncan Johnston-Watt
CEO | Cloudsoft Corporation
Twitter | @duncanjw
Mobile | +44 777 190 2653
Skype | duncan_johnstonwatt
Linkedin | www.linkedin.com/in/duncanjohnstonwatt
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
