By adding a few details to the CF deployment phase, it's possible that apps deployed from a Concourse pipeline would be visible as proper "server groups" inside a Spinnaker installation monitoring the same space.
Env Variables
![screen shot 2016-09-26 at 10 39 30 am](https://cloud.githubusercontent.com/assets/311040/18841027/125c0ee6-83d6-11e6-8a04-515eb94fa8b1.png)
This screenshot shows full complement of variables, that when set, makes a server group visible to Spinnaker.
- SPINNAKER_LOAD_BALANCERS is the name of the route from which the CF app would be visible, i.e. it's public URL (minus the domain). This is required.
However, just about everything else is optional, and provides extra information, but isn't needed for the app to be visible to Spinnaker (though if avaiable, let's populate!)
App name
The other thing needed to make the CF app visible to Spinnaker as a "server group" is the actual name of the application. There is a precise format that must be followed or it doesn't work.
While it might be old habit to name some demo pushed to CF spring-a-gram-demo-for-jug
, Spinnaker has a library to enforce a format that looks like this => springagram-dev-demo-for-jug-v023
.
The app name is split up by -'s, and tokenized as follows:
- springagram - app name. Think of github repo where the code comes from. Or if you have a set of microservices that work together, this could be common element between all of them.
- dev - stack. It's a logical label, often using things like "dev", "staging", "production", "gh123". This can also be how you distinguish a suite of microservices running in staging vs. the same stuff in production.
- demo-for-jug - details. A free form where you can put anything, even dashes. When you have a set of microservices, it's great for describing each one, e.g. "circuit-breaker", "service-discovery", "email-service", "frontend", etc.
- v023 - version. The last piece which denotes the exact version. Has to start with "v", and has to contain exactly three digits. Instead of "blue" and "green", they simply bump up the number and NEVER update an existing CF app, but instead push out a newer copy. For an out-of-the-box pipeline, we merely need to start with "v000".
NOTE: None of this dictates what org/space an app is deployed into.
Issues with this
- This can introduce complexity. That's why I'm leaning toward making it an option. The extra metadata and formatting of the app can add confusion we don't want if the user doesn't intend to use Spinnaker.
- If someone starts without Spinnaker-compatible, they can't expect to convert already deployed stuff into Spinnaker-compatible.
- It also introduces a wrinkle if you intend to support blue/green deployments. Blue/green deployments that are Spinnaker-compatible would require a poor man's version of what Spinnaker does. When pushing, instead of finding the inactive side and updating it, instead find the latest, bump up the version by 1, and push things out, then move the route. Issues arise when you see potential roll over scenarios, e.g. v999 and v000 currently deployed.