Posts by: Ashley Gerwitz
We need Docker images to package absolutely anything into BOSH releases, and we need to embed those Docker images inside BOSH release. The new bosh-gen v0.20 makes this very simple. Very simple indeed: bosh-gen package consul-image –docker-image progrium/consul Later, on a BOSH VM, it will be available again in Docker as image progrium/consul. An example
You can now deploy/scale/upgrade a single server using any of dozens of community BOSH releases WITHOUT needing BOSH server running. What do you get? A single VM. A single persistent disk – attached and mounted. And either can be scaled/resized over time. And you can upgrade between BOSH releases over time. At the time of
Post 2, Electric Boogaloo This is the second part of a series of posts about monitoring your CloudFoundry installations. You can find the first post in the series here. This post will cover some of the basics to encourage non Ruby developers to help us interface with services they’ve written. So… You want a BOSH
As mentioned yesterday, BOSH manifests can be huge – 3000 lines of YAML for deploying Cloud Foundry into bosh-lite for example. I wanted to quickly pull out information from a manifest. yaml2json This little CLI will convert YAML to JSON. go get github.com/bronze1man/yaml2json We can pipe any BOSH deployment manifest into it and out comes
Earning Your Trust Cloud Foundry and BOSH make an excellent platform and set of tools and they continue to get better. But all software has shortcomings. Keeping an eye on present and future gaps in the platform is on the mind of most of our clients. This is the first in the series of posts
The declarative nature of a BOSH manifest can give a team solid confidence about what is actually running in production. Give BOSH a deployment manifest and BOSH will make it happen. But if the manifest is 3000 lines long, and you have three of them – sandbox, staging and production – your solid confidence can
Here is a Pager Duty alert for a persistent disk being greater than 80% full on an etcd node: It turned out to be relatively simple to "turn on" disk monitoring on all jobs that contained persistent disks, across all deployments, across all stages of our client’s pipeline. We created a simple BOSH release that
Latest Cloud Foundry releases, and Pivotal Web Services itself, how supports a new container filesystem based on Ubuntu Trusty called cflinuxfs2. Thanks to Simon Johansson [@KarlSimonJohan] the incubator staticfile-buildpack now works on this new stack too! Release notes for other improvements as well: https://github.com/cloudfoundry-incubator/staticfile-buildpack/releases/tag/v0.5.0 As a developer you can now use this buildpack immediately with
Yesterday a user of the Staticfile buildpack noted that cf push would fail to upload files & start the deployment sometimes. "It takes forever and fails". We spotted the root cause: "Why is it uploading 26,000 files? The final project in dist folder only has a few." The problem was that we were uploading the