April 2017 – Solutions by Raymond

.NET Build Server using Visual Studio Community 2017

In a previous post, I wrote about building a .NET continuous integration server using Windows Server 2016, Jenkins, and Build tools. For this setup, I avoided installing any Visual Studio software. In my opinion, it was a simple process to get everything installed and building correctly. Now that Visual Studio 2017 has been released, I want to setup a build server using the community edition. Here are the 7 steps I took to get a .NET build server using Visual Studio 2017 Community edition, Jenkins, Git, running on Windows Server 2016.

1. Launch a new Windows Server 2016 instance. I’m currently investing on learning AWS so I’ll use it as my cloud provider. Feel free to use Azure, Google Cloud or your own server.

2. Download and install Visual Studio 2017 Community edition. For this tutorial, I selected ASP.NET and web development option during the installation.

3. Download and install Jenkins. I selected version 2.46.1 for this tutorial. After installing Jenkins, you have the option to install recommended plugins or select them one by one. For this tutorial, I went with the option to installed recommended plugins.

4. Download and install Git. If you have a different source control tool, go ahead and install it. After installing Git, I went to the Global Tool Configuration section and updated the path to C:\Program Files\Git\bin\git.exe.

5. Install MSBuild plugin. Go to Manage Jenkins section and select plugins. From the available tab, find MSBuild and install it. I also updated the path in the Jenkins settings to C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe.

6. Create a new Jenkins job. I used the free style option. For the settings I use Git as my source control tool. Since I’m building a .NET solution, I selected the build action that uses MSBuild and give it the solution or project name.

7. Trigger a new build. If all of the steps above were done correctly, you should have a successful build.

Installing Visual Studio Community edition makes it easier to have a build server setup. After installing it, you get the .NET framework needed plus the MSBuild executable. In my previous setup, I had to install more software. Build Tools 2015, .NET framework 4.5.2, 4.6.2. Hopefully this post helps you setup a reliable build server for your .NET applications.

What resources get created by AWS Elastic Beanstalk?

Creating a new beanstalk application is a simple process. Give it a name and select a platform. That’s it. Simple. However, it is important that we understand what resources get created when we launch a new AWS Beanstalk app. In this post, we will explore all resources created by AWS Beanstalk.

What is AWS Beanstalk?

Before we dive into the details, let’s take a moment and explain what Beanstalk is. This is how AWS defines Elastic Beanstalk, “AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS. You can simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time. There is no additional charge for Elastic Beanstalk – you pay only for the AWS resources needed to store and run your applications.”

Load Balancers

When you launch a new Beanstalk app, you have 2 options available for your scaling needs: single instance and load balancing, auto scaling. If you select single instance, your environment will always run with 1 instance only. You might use this setting to test a simple web app or service. If your app needs to scale out, you can create your environment with load balancing, auto scaling. By default, the minimum instance count is set to 1 and 4 for the maximum instance count. You can also change these values by going to the configuration section.

To see the load balancer created, go to EC2 console and click on the Load Balancers section on the left side menu. Here you can see the load balancer name, dns settings, VPC ID, availability zones, type, and created date. Most of these settings can be controlled by the configuration settings in your Beanstalk console.

Auto Scaling

For the auto scaling settings, we find a launch configuration and auto scaling group created. The launch configuration created contains information about the type of instance required in the auto scaling group. In my example, I see AMI ID ami-365ae520, Instance Type t1.micro, and other settings.

In the auto scaling groups section in the EC2 page, you will see a link to the launch configuration, min and max instances, availability zones, default cooldown, and other sections. Most of these settings can be changes from your Beanstalk configuration.

EC2 Instance

If you go to the Instances section, you will see that a new instance was created. In my case, I see the instance name, instance ID, public DNS, and other settings as well. If you have a scaling trigger set, other instances could be created. The most common option is to scale out based on CPU usage. For example, you can specify that a max of 75% CPU utilization will scale up and a min of 25% will scale down (terminate instances).

In addition to these resources, Beanstalk also creates IAM roles, S3 objects, security groups, and others. Creating a new AWS Elastic Beanstalk is a very simple process but understanding what gets created behind the scenes is crucial.