BOSH is a system for running your production systems on AWS, OpenStack, vSphere, vCHS, Google Compute Engine and more. A production system is described by a BOSH release. Some BOSH releases are for bespoke internal applications; others are communal open source systems such as Cloud Foundry.
As an author, it should be easy to create BOSH releases. It should also be easy to share BOSH releases. Continuously lowering these barriers has been one of my goals for the last two years.
bosh-gen is a tool for rapidly creating BOSH releases that is almost two years old and has been used to create nearly all BOSH releases. But in the past it hasn’t made it easier to share them.
It should be as easy as possible to share internal BOSH releases internally; and community BOSH releases with the community.
The latest version of bosh-gen (v0.17) now takes two steps forward to make BOSH releases more social.
Faster and more fool-proof to get started
In order to create and share a BOSH release you:
- Use a public source control repository
- Use a public blobstore (such as AWS S3)
- Optionally, publicly share pre-created final release tarballs via a HTTP URL.
Previously the creation of blobstores was manual, setting the correct public policies was tedious, and almost no one creates final release tarballs and shares them via HTTP URLs. This is now much better.
bosh-gen new command now prompts for blobstore credentials, automatically creates the new blobstore and tries to fail fast.
Here’s an example of the new flow for creating a BOSH release and uploading its first blobs:
You will be either prompted for your AWS S3 or OpenStack Swift credentials; OR prompted to choose from pre-configured ~/.fog credentials (the later is featured in the animated demo above).
The command only succeeds if it can create the blobstore (an AWS S3 bucket in the example above) and set its bucket policy to be publicly readable.
Easy to share release tarballs
I already knew that I could upload stemcells to BOSH via a remote URL:
$ bosh upload stemcell https://bosh-jenkins-artifacts.s3.amazonaws.com/bosh-stemcell/aws/bosh-stemcell-2427-aws-xen-ubuntu.tgz
But I only learned recently that it is also possible to import BOSH releases the same way.
$ bosh upload release https://hostname/my-project-123.tgz
Awesome! Except nearly no one, not even the Cloud Foundry project that sponsors BOSH, is making BOSH release tarballs publicly available.
The new bosh-gen v0.17 now includes a BOSH CLI plugin to make it very simple.
You can create a final release and share it:
$ bosh create release --final --with-tarball
$ bosh share release releases/my-project-123.tgz
https://my-project-boshrelease.s3.amazonaws.com/boshrelease-my-project-123.tgz
The example animation above shows that you can also share dev releases.
The output URL represents a publicly downloadable BOSH release stored in your target blobstore (AWS S3 buckets are best supported at time of writing).
Easy to use a shared BOSH release
How would you, your colleagues, or the wider BOSH community now use this shared BOSH release?
You would document the following in your project’s README:
$ bosh upload release https://my-project-boshrelease.s3.amazonaws.com/boshrelease-my-project-123.tgz
If your BOSH does not have public Internet access, then you will need to manually download it and bring it into your data center.
More social?
As an author, it should be easy to create BOSH releases. It should also be easy to share BOSH releases.
As a user, it should be easy to find BOSH releases and use them.
These improvements above to bosh-gen and the BOSH community are relatively small, but hopefully helpful.
I’m pretty envious of the Ruby community’s Gemcutter project by Nick Quaranto (http://rubygems.org/). It is very easy to find projects (http://rubygems.org/search?utf8=✓&query=bosh shows all "bosh" rubygems), to author new projects/rubygems, to add other users as authors/owners, and more. An experience like this would be ideal.
There is also the challenge of helping BOSH release users (the people who invoked bosh upload release) to create functional BOSH deployment manifests. Currently the popular options are to include spiff templates or to document example manifests. I’ve also experimented with dedicated BOSH CLI plugins to prompt users through information gathering to create the resulting manifests (see bosh-cloudfoundry).
I’m still not sure what the best path forward is there. Interesting problems to solve indeed.
Hopefully you’re having a great experience using BOSH to run your production systems; and hopefully bosh-gen keeps making it easy to create and share releases!
Remember to thank current and past BOSH core team members whenever you meet one! It is an incredible free open source project.
Spread the word
