This repo contains a bash script and examples about how to setup a folder structure to easily create and deploy environments. The script will be showing the commands it runs (and logging to a file) to make it easy to copy and reproduce manually.
Moreover it can be sourced (. bosh.sh
) to make all the functions availabe in another shell scripts (upload stemcells, releases, etc)
and automatically define all bosh environment variables (certs, user, environment) to operate bosh-cli
againts a director.
The script was created to manage Bosh Director environments, but it can be used to deploy other environments like concourse, jumpbox, etc
Type ./bosh.sh --help
to see the usage.
Probably you will need to initialize the upstream git submodules:
git submodule init
git submodule update
Features:
-
The script looks for a folder with the same name as the script. So if the script is called
bosh.sh
it will expect a folder calledbosh
, if the script isconcourse.sh
(it can be a link) it will look for a folder calledconcourse
. -
The folder should have a
operations
folder with at least one base yml file, the rest of the optinonal files (or links) are operations files which add or remove keys/values defined on the first file. The files are sorted lexicographically, so a good patter is always use a naming convention like00-bosh.yml
,50-cpi-vpshere.yml
, ... and so on. The idea is defining each dozen as a group of setting regarding one particular aspect, for example:50-cpi-vsphere.yml
and55-vsphere-resource-group.yml
are in the 50th dozen which in this example is for cpi configuration. It is also important to try not use sequential numbers to leave holes for other future settings. The rest of the files without.yml
extension are ignored. -
Variables. The script expects two files
director.yml
anddirector-secrets.yml
. The first one normally includes IPs, CPI settings and the second one includes passwords regarding the CPI, etc.director-secrets.yml
should include passwords/certs/users which should not be auto generated by bosh-cli, the passwords/certs which cannot be autogenerated. Autogenerated passwords will be stored in a file calledcreds.yml
and they will be different on each deployment. A folder calledvariables
can also be created to define other variable files (especially useful for stemcells and release versions). -
The previous seetings can be managed/changed by defining environment variables. See the script.
-
If the script deploys a Bosh Director you can make use of Bosh specific arguments:
- It can apply runtime-config defined in
runtime-config
folder (interpolating operations files, if there are more than one) after deploying a bosh-director (argbosh-init
). - Manage cloud-config by interpolating all files in
cloud-config
folder. - Talk with
credhub
to read secrets and certificates and make them availabe as environemnt variables by sourcing the script. - Show with
bosh-env
arg how to get the env variables fromcredhub
andsecrets
to define as environment variables.
- It can apply runtime-config defined in
-
The upstream deployments repos are included as submodules inside each folder which makes easy the usage of links, specially to link the base files and other common operations files. It is also usefull to track upstream versions.
-
There is an additional
deployments
folder which is meant to store the manifest for all deployments of a bosh director.
bosh.sh
:bosh
,runtime-config
,cloud-config
anddeployments
folders.concourse.sh
:concourse
andpipelines
folders.jumpbox
:jumpbox
folder.
Important! You can encrypt the secrets files, you will NEED to do the following, otherwise you will not be able to proceed
# Install git-crypt(https://github.com/AGWA/git-crypt)
# Get the key used for encryption and decryption of files
pass keys/gitrepos/bosh-cli-wrapper.key > ~/.bosh-cli-wrapper.key
# Tell git crypt to use the key for encryption and decryption in your repo
cd bosh-cli-wrapper
git-crypt unlock ~/.bosh-cli-wrapper.key
Apache 2.0 (c) Springernature Platform Engineering