DotNet and Config Server on Cloud Foundry PCF

Share the joy
  •  
  •  
  •  
  •  
  •  
  •  
  •  

When discussing Microservices, we come across numerous references which talk about externalizing configuration.

From the MSDN articles, we can see that externalizing configuration in cloud-based applications is an important pattern.

Managing changes to local configurations across multiple running instances of an application, especially in a cloud-hosted scenario, is a challenging proposition.

Store the configuration information externally and provide an interface that can be used to quickly and efficiently read and update configuration settings… .

Read more here

Externalizing configuration is important for Distributed systems and is an important pattern to implement when moving towards microservices architecture from monolithic ones.

So how can I implement this pattern in DotNet?

Enter .. SteelToe.io

from Steeltoe.io

By leveraging SteelToe.io libraries, we can use Spring Cloud Config Service from DotNet inside Cloud Foundry.

SteelToe

  • Includes .NET client library for connecting into Spring Cloud Config Server on Cloud Foundry (CF)
  • Allows to share configuration across all your apps/microservices inside and outside DotNet

So SteelToe reuses the goodness of SpringCloud and brings it to the DotNet world. It’s a great set of tools for building Microservices like apps leveraging the productivity of Cloud Foundry.

Let’s take a look at an example of a SteelToe Config solution written in DotNet and hosted on Cloud Foundry.

What we need:

  • Cloud foundry installation with Diego Windows enabled
  • Ability to create SpringCloud Configurati0n service within our Org/Space.
  • Ability to build/publish Steeltoe Dotnet solution
  • Visual Studio 2015
  • Command line CF cli installed from here

Another option, if you cannot build/publish this code, is to clone this repo and simply <em class="iw">cf push</em> from command line to view the app on your Space inside CF.

First Login to CF with this:

1
2
3
4
5
6
7
8
<span>$ cf login -a api.[my-cloudfoundry].com
API endpoint: https://api.[my-cloudfoundry].com
 
Email> [my-email]
 
Password> [my-password]
Authenticating...
OK</span>
<span>$ cf login -a api.[my-cloudfoundry].com
API endpoint: https://api.[my-cloudfoundry].com

Email> [my-email]

Password> [my-password]
Authenticating...
OK</span>

Our end solution will run like this …

Final solution

The green box is the Cloud Foundry platform environment within which we have our FOO app running along with Config server, provisioned from the marketplace. Our FOO app is bound to the config server and binding happens once we push the app from the command line using “cf push”. Before binding, the backing service has to be provisioned, in our case this is “Spring Config Server “.

How did we bind our FOO app to the Config service? See the manifest section below…

The GIT repo is accessible to this CF instance. It contains the configuration key-value which the config server will expose to our FOO app. App B and App C are other apps which can similarly access the config once they are bound to the config server within the platform.

Summary of steps from 3000 ft :

  • Fork Git Repo to host key-value configuration. {Fork not clone}
  • Provision Spring Cloud Config Service on CF from marketplace
  • Push our app {FOO} and bind with Config service
  • Check working prototype

Next Fork the Git repo to your github.

Clone Steeltoe project in local dir on your laptop.

1
<span id="3698">git clone <a class="dy in" href="https://github.com/SteeltoeOSS/Samples.git" target="_blank" rel="noopener ugc nofollow">https://github.com/SteeltoeOSS/Samples.git</a></span>
<span id="3698">git clone <a class="dy in" href="https://github.com/SteeltoeOSS/Samples.git" target="_blank" rel="noopener ugc nofollow">https://github.com/SteeltoeOSS/Samples.git</a></span>

Let’s create Spring Config server from the marketplace.

I have Spring Cloud Services available in my CF environment as this image shows. Your CF admin will have to enable the Spring Cloud Services bits in CF for you {the developer} so you can access it via marketplace.

In my space, there are other products installed and available in the marketplace like {p-mysql / p-redis / p-rabbitmq / p-service-registry}.

Check if it is available by typing cf marketplace

We will create a “p-config-server” instance from the marketplace. We will call this instance “myConfigServer”. We will bind to this config server from our FOO app.

Open the Steeltoe “Configuration” code in VisualStudio.

Cd into Steeltoe/samples/Configuration and open the Configuration solution. It opens up the subprojects in VStudio like this.

Select SimpleCloudFoundry project and right click — select “Set as startup project”.

Select the file “config-server.json” and change it to point to your forked config repo {from step 1 of 3000 ft view} in the uri section. I have it pointing to my fork.

We are pointing the p-config-server instance to our forked config git repo by editing the config-server.json, so we can experiment easily and edit yml files.

click to view larger

Edit and Save it.

From the command line, type

“cf create-service p-config-server standard myConfigServer -c ./config-server.json”

It reads “ create a service” of type “p-config-server”. Name it “myConfigServer” and this new service should fetch config keys from the uri mentioned in “config-server.json”.

Once its on its way, we get a “create in progress” message. The services are provisioned Asyncronously. Give it like a minute to finish.

click to view larger

Once it’s finished, we can check the provisioned service in our Org/Space. Our Org is called “DCS-Dev” and Space is “code”. It shows 2 services that are provisioned in my space { mysql and myConfigServer }. I mention using the mysql service in another post.

Services provisioned in my org/space

Up until now we have “myConfigServer” provisioned.

Next let us build/publish the “SimpleCloudFoundry” solution to a local file system, from where we will be able to push the app named FOO to CF.

In VStudio 2015, I select the Project, right click, select “publish” and choose custom and give it a name. I named this “local”.
{You can name it anything.}

On next, choose the Filesystem and select a clean empty directory, where your binary will get published. The idea is to “CF push” this binary from command line and not let VStudio deploy .

On clicking Publish, you can see the console output in VStudio.

Cd into this newly published directory. You can see the manifest.yml file.

CF Manifest : lists the input parameters to cf cli.

This shows the name of the app: Foo, and the services section that it will bind to “myConfigServer”.

When we specify the services to bind to via the manifest, the CF cli will create the app and bind those services for us.

1
2
3
4
5
6
7
8
<span id="25cd" data-selectable-paragraph="">---
applications:
- name: foo
  memory: 1G  
  stack: windows2012R2  
  env:
  services:
   - myConfigServer</span>
<span id="25cd" data-selectable-paragraph="">---
applications:
- name: foo
  memory: 1G  
  stack: windows2012R2  
  env:
  services:
   - myConfigServer</span>

So now we are ready to cf push this FOO app to CF.

From inside the publish folder, type $ cf push

We will get scrolling output and the app “FOO” will start with OK status.

You can see the app running like this… notice the “urls” output in command line, which gives us the url to app. Open it in browser..

Success… but let us validate more… .

Let us inspect our code in VStudio to understand what is happening.

I am highlighting the HomeController.cs. Right up top, you see the glue..<strong class="hv fz">Steeltoe.Extensions.Configuration.CloudFoundry;</strong>

Open “Simple Cloud Foundry” project in VStudio

Once we click in the menu item on our FOO app — called “Config Server Settings”-we get this page.

These are the values our app controller is reading from config keys with help from Spring cloud configuration services.

Before building code, I went ahead and added a new key in Git config repo under {foo-development.properties} called “gitname”.

To read it in the “Config Server Data” tab in the FOO app, I modified the controller section to fetch a value from config called “gitname”.

click to view larger

We see it being displayed.

So what happens if the “FOO” instance crashes ? Will the configs get lost??

Answer : Another FOO instance will be spun up automagically by CF platform and once this instance comes online, it will start reading config from the Spring Cloud Server. Externalizing the config this way, makes the solution resilient to failure.

Looking at the dll’s shipped as part of the publish dir, we see Steeltoe.Extensions.*.dll, Pivotal.Extensions.*.dll , and SimpleCloudFoundry4.dll which do the heavy lifting behind the scenes. They allow the DotNet FOO app to connect to Spring Config service inside CF and fetch the value for given key.

To conclude, Steeltoe brings the power of resilient, scalable microservices to .NET developers. Combine this with power of Cloud Foundry Platform which brings app resiliency and developer productivity a great choice for DotNet ecosystem.

Reference: https://medium.com/


Share the joy
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.