How to Set Up a Cloud Foundry Infrastructure for .NET Apps in Minutes
How it works
So, what is the mechanism that provides Cloud Foundry support for .NET apps? Of course, we are talking about the Garden-Windows back-end for Diego and software for bringing Diego to Windows machines and adding them to a CF cluster. Until recently, the work on these components was in progress, but a month ago it became generally available. (For details, refer to the docs in the diego-windows-release repository.)
In this post, I’ll show you that all you need to set up such an infrastructure is an AWS account and maybe some tea to drink while things are getting installed. We’ll focus on achieving a working deployment in as few steps as possible—even before your tea goes cold.
Prerequisites
First, we need to have the following tools installed on our local machine:
I also presume that you have a kettle and some tea in your apartment. 😉
Step #1: Install Cloud Foundry and Diego
Before we can set up some Windows cells, we need to have a regular CF/Diego deployment. For this purpose, we will use a repository created by Altoros with ‘convention over configuration’ in mind. It contains CloudFormation scripts that will do all the hard work of installing CF on the Amazon cloud for us. Here is how to use it on the Linux/UNIX command line:
git clone https://github.com/Altoros/cf-minimal-deployment-aws-script cd cf-minimal-deployment-aws-script cp .envrc-template .envrc # edit .envrc to provide some essential information (mainly credentials) direnv allow . # or `source .envrc` if you do not want to use direnv ./scripts/stack.sh create
That’s it. Now you can open your Amazon CloudFormation console and see your new stacks being created. And if you’ve made yourself a nice cup of flavory tea, now is the perfect time to go for it.
Step #2: Create Windows cells
This is where CloudFormation comes in handy again. The *diego-windows-release* repo contains a template that can be used to set up the required number of Windows cells.
At this point, we need to reveal some details about how our deployment has been configured. The main one is—Cloud Foundry virtual machines talk to the outer world through a NAT VM. This VM has a security group attached that only allows inbound traffic from the internal CF subnet where all the platform components reside.
Since diego-windows-release scripts create a separate subnet for Windows machines, we need to extend the security rules, so that they allow traffic originating from this new network, as well. The CIDR range of the Windows subnet is 10.0.100.0/24 and this is what the new rule of the NAT VM security group should look like:
Now the infrastructure we have built is ready to accept a new member from the Windows envelope. Let’s try it out.
Here is a template to use. The link corresponds to version v0.180, the latest at the time this post was written and also tested with CF v221. Download the template and upload it to Amazon S3 via the CloudFormation UI after you have pressed the “Create Stack” button.
Before creating a stack, CloudFormation asks you for a number of parameters. Point it to the NAT VM and VPC created during step one. The BOSH user is admin. The BOSH password is the secret that you have specified in the .envrc file. The BOSH host can be seen on the Output tab of the *-jumpbBox stack. Follow the hints provided by the template to fill out the rest of the fields.
Run it and wait until the status turns green. You can return back to your tea for now.
Step #3: Inform Cloud Controller
The last thing we need to do before we can use our new Windows cluster is tell Cloud Controller about the windows2012R2 stack, which is now supported by the platform:
cf curl /v2/stacks -X POST -d ‘{"name":"windows2012R2","description":"Any description"}’For details on how to add new stacks to the Cloud Foundry, see this page in the Cloud Controller API docs.
Step #4: Enjoy the possibilities
Congratulations! Your platform is ready to host Windows applications. Although, it is worth verifying the installation with some smoke tests first. You know, just to be sure.
The tests repository also contains a simple .NET application. Let’s push it:
cf push my-first-dotnet-app -p assets/dotnet_simple/Published -s windows2012R2 -b staticfile_buildpack
Note that we have pushed a compiled piece of code, using staticfile_buildpack. At this time, there are no official buildpacks for pushing .NET source code to the Windows stack. However, having MS Visual Studio at hand gives us a possibility to build applications from source and then push them to the platform.
Below, is a short demo of our cluster at work. In this video, you can also see how to install the CF extension for MS Visual Studio and push an application with it. The tool we use to view and navigate between platform entities is Admin UI.
Step #5: Clean things up
After you are done playing with your deployment, you will probably want to delete it and release the resources—otherwise, Amazon will eventually consume all of your balance.
First, delete the Windows stack by simply pressing the corresponding button in the CloudFormation UI.
Then, ssh into your BOSH jumpbox (see the IP in the Output tab of the *-jumpbox stack) and execute:
./scripts/destroy_all.sh
Afterwards, leave the jumpbox, enter the folder you launched the deployment from, and run:
./scripts/cleanup.sh
Watch things being deleted in the CloudFormation UI. Using cleanup.sh is not mandatory—feel free to remove the remaining resources manually via the AWS console, if you wish.
Don’t forget to clean your tea cup, as well. 😉
Hope you have enjoyed this tutorial. If you have any questions, feel free to ask them in the comments.
Further reading
