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_HOSTIf you are using bosh-lite you target like so:
bosh target 192.168.50.4 liteNow clone this release and cd into the directory:
git clone https://.../rdpg-boshrelease.git
cd rdpg-boshreleaseIf you intend on using a final release upload it like so:
bosh upload release releases/rdpg-1.ymlNext 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.ymlAlternatively, 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 wardenEdit 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: latestFor consistency also add to the releases: section under meta:
meta:
environment: rdpg-development
releases:
- name: cf
version: latest
- name: rdpg
version: latestAdd 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: rdpgNow you can deploy,
bosh -n deployNote 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 wardenThis is equivalent to:
./rdpg-dev blobs
./rdpg-dev release
./rdpg-dev stemcell warden
./rdpg-dev manifest wardenOnce these steps have all been completed
bosh -n deployFor 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 --forceSee 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 releaseto 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 wardenmanifest generator) - Run the
acceptance_testserrand
The deploy job is triggered when:
jobsorpackagesfolders are modified - changing the BOSH release itselftemplatesfolders are modified - changing how users might deploy the BOSH releasesrcfolder is modified (see below for jobs that do this via Concourse)config/blobs.ymlis modified - changing the blobs that go into the BOSH release
