Posts by: GeoffFranks
I recently had need to rename some BOSH jobs that were deployed with a BOSH v1 manifest, and no Cloud Config. Early in 2016, the bosh rename job command was replaced with the migrated_from feature of the manifest. It’s documented pretty well here so I won’t go into the details in this post. However, if
I recently needed to make use of the cf-multi-buildpack (UPDATE: there is also an updated GPL-licensed fork of cf-multi-buildpack). Its instructions indicate to use the -b https://github.com/pl31/cf-multi-buildpack flag during cf push to make use of it. However, I wanted to make this something available explicitly to all my Cloud Foundry users, and add it as
Slack has a great integration with GitHub, allowing you to have a bot post all kinds of GitHub activity into your slack channels. However, the default settings for this require you to give Slack write-permissions on all your public/private repos. Depending on your level of paranoia, this may not ideal. Fortunately, there is a relatively
Locking down your BOSH VMs? Here’s a handy guide for some options at your disposal for overriding the default password for BOSH’s vcap user: Customize it in your manifest In each resource pool (or VM type) configuration in your BOSH manifest (or cloud config manifest), you can specify env.bosh.password. This will overwrite the value of
A short time ago, I created the fubar-boshrelease with the purpose of providing a broken BOSH release that would help expose operators, and developers to various aspects of troubleshooting things going wrong when working with BOSH. It starts out as a BOSH release repo needing to be built, uploaded, deployed, and made to work. However,
bosh create-env is AWESOME. It lets you deploy BOSH itself using a BOSH manifest, making it really easy to customize your BOSH deployment as you see fit. It allows you to add a backup agent, some monitoring, and some troubleshooting tools, or even swap out the database with an HA alternative. However, there is one
At Stark & Wayne, we love Concourse pipelines! We use them for testing/releasing CLI utilities, deploying Cloud Foundry apps, building docker images, creating and testing BOSH releases, and vetting changes to BOSH deployments in an automated fashion starting in sandbox environments all the way to production. Uh-oh! credentials.yml file got committed? One of the most
A few of our recent posts related to standing up BOSH deployments using Genesis have all revolved around needing Vault to store your credentials safely. The vault-boshrelease makes this fairly straightforward, but there’s now a Genesis Vault template to make running Vault even easier! The procedure is similar to the other Genesis deployments: $ genesis
In this post, we’re going to use Genesis to deploy Cloud Foundry. We will make use of some of Genesis’s cool features to generate unique credentials for each deployment, and Vault to keep the credentials out of the saved manifests. We will do this on BOSH-Lite, but templates exist to easily deploy to AWS with