MIT, see LICENSE file.
We will walk through an example of using with Cloud Foundry.
Be sure to first target your BOSH Director:
bosh target $BOSH_HOST
If you are using bosh-lite you target like so:
bosh target 192.168.50.4 lite
Now clone this release and cd into the directory:
git clone https://.../rdpg-boshrelease.git
cd rdpg-boshrelease
If you intend on using a final release upload it like so:
bosh upload release releases/rdpg-1.yml
Next download your manifest file for the deployment targeted so we can edit it and add the release.
mkdir -p ~/workspace/manifests
bosh download manifest rdpg-development ~/workspace/manifests/rdpg.yml
bosh deployment ~/workspace/manifests/rdpg.yml
Alternatively, you can make your manifest. For example to prepare a manifest for bosh-lite (warden) using the 'centos' stemcell we would do the following:
STEMCELL_OS=centos ./rdpg-dev manifest warden
Edit the manifest file you downloaded (~/workspace/manifests/rdpg.yml
) and add settings as follows.
Add to the list of known releases:
releases:
#...
- name: rdpg
version: latest
For consistency also add to the releases:
section under meta:
meta:
environment: rdpg-development
releases:
- name: cf
version: latest
- name: rdpg
version: latest
Add properties such as tags.
properties:
# ... lots of properties ... at bottom put vv
rdpg:
Now, for every instances:
entry you wish to collocate this release with under jobs:
add the following in the templates:
section:
- name: rdpg
release: rdpg
Now you can deploy,
bosh -n deploy
Note that for each job you create in your release that you want to run on a Job VM you must add a templates:
entry with the name:
of the template and the release:
from which it comes.
The script ./rdpg-dev blobs
is used to prepare the blobs/
directory runs each package's prepare
script from within the blobs/
directory. This will run each package's prepare
script, if it exists, which should download and prepare that package's required blobs (source tarballs, etc...) into the {package}/ directory.
Download your manifest file for the deployment targeted.
Target your BOSH Director as explained above, if you already have a deploy be sure to also download your manifest as per above.
If this is your first time cloning the release repository for develompent first prepare all of the things:
./rdpg-dev prepare warden
This is equivalent to:
./rdpg-dev blobs
./rdpg-dev release
./rdpg-dev stemcell warden
./rdpg-dev manifest warden
Once these steps have all been completed
bosh -n deploy
For more information on the internal components used to manage PostgreSQL databases please refer to the documentation in src/rdpgd/docs/*.md
There is also a large treasure trove of "How To" and similar documents in the Wiki in this repository.
In order to gain access to one of the VMs, from a terminal bosh ssh rdpg {VM Index}
, for example to ssh to the first node:
bosh ssh rdpg 0 # Hop on and have a look around...
If you want to destroy and recreate on specific node, say rdpg/0
, you do the following:
bosh -n recreate rdpg 0 --force
See docs/rdpg.md
for release specific information.
To run acceptance tests:
bosh create release --force && bosh upload release && bosh -n deploy && bosh run errand acceptance_tests
This BOSH release is automatically built and tested upon every commit to master.
The deploy
job will:
- Run
bosh create release
to ensure that the BOSH release can be successfully created - Upload the release to a bosh-lite running on AWS
- Generate a manifest and deploy a cluster (via the
./rdpg-dev manifest warden
manifest generator) - Run the
acceptance_tests
errand
The deploy
job is triggered when:
jobs
orpackages
folders are modified - changing the BOSH release itselftemplates
folders are modified - changing how users might deploy the BOSH releasesrc
folder is modified (see below for jobs that do this via Concourse)config/blobs.yml
is modified - changing the blobs that go into the BOSH release