Also published at: www.initpals.com
Background
This article explains how easily you can externalize your configurations, from web.config to environment variables or any other external sources like Spring Cloud Config Server (which is available in Pivotal Platform(PAS-Cloud Foundry) as marketplace service), using and extension buildpack called Web Config Transform Extension Buildpack. The most interesting thing to note here is, that you need not change any code to make this happen.
Usually it will be a bit challenging process when we try to pull the configuration out, from web.config because of the tight coupling with the framework. That problem will be solved completely using this extension buildpack approach. This especially helps when doing a lift and shift, with minimal or no code change.
If you are familiar with Cloud Foundry, you should be already familiar with buildpacks and its staging process. If not, please refer to cloud foundry, buildpacks and buildpack staging process, before continuing further.
How does this buildpack work?
This is an extension buildpack that will pull the configurations from environment variables and Spring Cloud Config Server (if bound), then modifies the web.config
file during the buildpack staging process
- Uses Steeltoe Configuration to pull in the configuration from environment variables and Spring Cloud Config Server
- Apply web.config transformations (which is more similar to the traditional approach)
- Apply token/placeholder replacement to any of the web.config content
Highlights
No code change required
, when pushing any ASP.NET application to Pivotal Platform (PAS)- So it
reduces the effort
in lifting and shifting a legacy ASP.NET application to Pivotal Platform (PAS), more interestingly if you are already using transformation techniques for handling configurations, you can just use it as is.
Pre-Requisites
- Pivotal Platform (PAS) environment with
cf push
access - WEB-CONFIG-TRANSFORM-BUILDPACK should be already installed, use
cf buildpacks
to verify - Optional – A Spring Cloud Config Server tile in marketplace
- Basic understanding of Cloud Foundry and buildpacks
High Level Steps
Info: You can find more detailed information and steps here
- Add the buildpack in WEB-CONFIG-TRANSFORM-BUILDPACK to the manifest as below.
---
applications:
- name: redis-buildpack-sample
memory: 1024M
stack: windows2016
buildpacks:
- WEB-CONFIG-TRANSFORM-BUILDPACK
- hwc_buildpack
env:
ASPNETCORE_ENVIRONMENT: development
Warning: The order of buildpacks matters, always have the system buildpack at the last
- If you have a Spring Cloud Config Server instance bounded, that will be added as another configuration source, which you have to mention as a service in the application
manifest.yml
. If you want to know more about setting up Spring Cloud Config Server, please refer to this recipe - Now we have two choices,
using config transformations
ortoken replacement
orboth
. Let’s look at the transformations first.
1. Web Config Transformation
- You should have a basic understanding of, how
web config transform
works, if not please go through Microsoft docs - Usually the transformations will be applied based on the
build configuration
, but in our case it’s a bit different. - Create the transformation configs as many as environments you have. The name of the file should be
web.{app-environment}.config
whereapp-environment
is the value of environment variableASPNETCORE_ENVIRONMENT
, in our sample manifest above, I have set it todevelopment
. So my config file for development environment names likeweb.development.config
- Modify the transformation files based on the transformations you need
- Simply, push the application using
cf push
command, you should see the transformations applied during the build staging process and the applications will make use of the transformed configuration values - If you have
cf ssh
access, you can get into into your application’s container and see the transformedweb.config
file
2. Web Config Token Replacement
- This is the most useful functionality from this buildpack as it helps in
externalizing the configuration
to various sources. This helps the application adhering to one of the cloud native factorsConfiguration, credentials, and code
- Let’s say that you have an
appSetting
configuration with keyfoo
, to be externalized. So we need to modify theappSettings
section as below
<appSettings><add key="foo" value="#{appSettings:foo}"/></appSettings>
appSettings:foo
is any name that you can provide, it’s just an environment variable name, but it should match the token name- Now you can set your environment variable, based on the target environment, lets say I have set
appSettings:foo
tobar
- Push the application now, you will be seeing logs as below, where the token
#{appSettings:foo}
will be replaced with the valuebar
.
================================================================================
=============== WebConfig Transform Buildpack execution started ================
================================================================================
-----> Using Environment: development
-----> Replacing token `#{appSettings:foo}` in web.config
================================================================================
============== WebConfig Transform Buildpack execution completed ===============
========================================================================
- If you have
cf ssh
access, you can get into into your application’s container and see theappSettings
section inweb.config
file, as below
<appSettings><add key="foo" value="bar"/></appSettings>
Hope you had fun pushing the application to cloud with no or minimal code changes!
Quick References
comments powered by Disqus