Cloud Foundry buildpacks have traditionally been quite monolithic in nature and has focused on containerizing and running a particular type of language. Each buildpack can be thought of as a codified recipe. But who’s to say we can’t use more than a single recipe at a time? This is exactly what multi-buildpack accomplishes. Cloud Foundry manifest allows for more than one buildpack to be specified, each getting a chance to act on the given artifact that affects how the final image gets built. With the V2 version of buildpacks, the end result was a tarball that got mounted on to rootfs base image in Cloud Foundry. To those of you who are familiar with Docker, you may be wondering why this is not done as layers in a standard container. The reason is that the concept of a buildpack actually predates Docker, and the original buildpack contract API was inherited from the one created by Heroku. The V3 version of buildpack spec aka Cloud Native Buildpacks (CNBs) is actually exactly what you would expect: you give it source code or artifact on one end, and you get a working container image on the other. Currently, PCF does not support CNBs, but it will in the near future. You can find more info about them at https://buildpacks.io/
A while back I have developed a simplified .NET template for creating, packaging and releasing buildpacks based on the V2 spec, which you can read about it my previous post. Since then, a whole number of novel use-cases have been found that were tackled using buildpacks. Below you will find a list of buildpacks that have been developed on top of this template and the use cases they tackle:
Web Config Transform Buildpack
This buildpack was one of the original buildpacks that I prototyped and has since been picked up, improved and offered as a supported produced as part of the Pivotal Application Service. It allows legacy .NET framework web applications to have their web.config file transformed to match a target environment. Unlike the configuration management system of .NET Core which is based on a combined representation of multiple config sources, the .NET framework only reads its settings from the Web.config file. The .NET framework supports the concept of web.config transformations which apply XSD transformations for each environment, by creating files such as Web.Release.config and Web.Debug.config. When bundled with the app, the buildpack allows these XSD profiles to be applied when the application is staged. Additionally, a token syntax can be used within both XSD transforms and base web.config to do value-based replaced based on keys found in .NET core configuration sources, which include environmental variables and config server. For example an XML attribute in the `web.config` defined as connectionString="#{connectionStrings:MyDB}". The buildpack combines configuration sources from environmental variables and Spring Cloud Config Server (if the appropriate config server binding is detected for the app). Additionally, any environmental variables that map to IConfiguration path appSettings:KeyName or connnectionStrings:KeyName will automatically be included in the appropriate web.config sections:
<configuration>
<appSettings>
<add name="KeyName" value="MyConfigValue"/>
</appSettings>
<connectionStrings>
<add name="KeyName" value="myconnectionString"/>
</connectionStrings>
</configuration>
Single Page Application Buildpack
An alternative to staticfile_buildpack, this one is powered by .NET Kestrel webserver. It exposes a /config endpoint on the app that will expose configuration information from Config Server in JSON format, allowing SPA apps (ex. Angular) to load their configuration data from Config Server, without having to embed it in the app. Additionally, if RabbitMQ binding is created on the app, the buildpack will hook into Spring Cloud Bus and any apps attached to it (.NET, Spring or other SPA buildpack enabled apps) to allows global configuration refresh of all container instances. This is done by issuing a POST request to /actuator/bus-refresh endpoint.
Another feature of this buildpack is if there is a detected binding to Pivotal Single Signon service, then the related information will be included in the /config endpoint, allowing easy configuration of SPA OAuth2 implicit grant flows. The SSO settings appear under SSO property in the JSON root. Since the secret is not used in an implicit flow, it is stripped from the /config endpoint values.
Finally, the app exposes a SignalR hub called SpringCloudBus allowing messages directed to the app (including bus refresh events) to be sent to the front end via WebSocket, allowing client-side config refreshes initiated by the server. You can test this functionality via integrated test endpoint at /SpringCloudBusTest.
https://github.com/macsux/spa-buildpack
Config Server Buildpack
Allows values in config server to be exposed as individual environmental variables and/or a single JSON block CONFIG_SERVER_APP_JSON. This allows apps written in languages that don’t have config server client libraries (currently only available for Java & .NET) to use config server (ex. NodeJS, PHP, etc).
https://github.com/macsux/config-server-buildpack
Windows Services Buildpack
This buildpack allows running Windows Service projects on Cloud Foundry without having to convert them into console applications. It uses a combination of Harmony and EasyHook to intercept OS calls and emulate Service Control Manager (SCM) in a way that satisfies the application’s contract with the Windows SCM subsystem. This also intercepts calls to the Event Viewer and redirects the emitted log messages to the console.
https://github.com/macsux/cf-buildpack-windows-services
Certificate Buildpack
Allows populating .NET X509Store with application-specific certificates without having to install them for the entire platform. This works on both Windows for .NET framework applications and Linux for .NET Core apps. The certificates can be sideloaded from multiple sources, such as config server, environmental variables, or CredHub.
https://github.com/macsux/certificate-buildpack
In the next post, we’ll introduce another specialty buildpack that helps tackle Integrated Windows Authentication (Kerberos) without domain joining VM or container as this particular problem domain requires additional moving pieces to solve.
