Nginx asp net core windows

$ sudo apt-get install apt-transport-https
$ sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list'
$ sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893
$ sudo apt-get update
$ sudo apt-get install dotnet-dev-1.0.0-preview2-003131

$ sudo apt-get install nginx

Run the “Hello World” App

Install and initialize a “Hello World” app in the parent directory of your choice:

$ cd parent-dir-for-apps
$ mkdir app
$ cd app
$ dotnet restore

To check that the app is working, run the dotnet run command.

Run the Kestrel HTTP Server

1. Edit the ./project.json file to add Kestrel as a dependency to the project.

   {
     "version": "1.0.0-*",
     "buildOptions": {
       "debugType": "portable",
       "emitEntryPoint": true
     },
     "dependencies": {},
     "frameworks": {
       "netcoreapp1.0": {
         "dependencies": {
           "Microsoft.NETCore.App": {
             "type": "platform",
             "version": "1.0.1"
           },
           "Microsoft.AspNetCore.Server.Kestrel": "1.0.0"
         },
         "imports": "dnxcore50"
       }
     }
   }

2. Copy this code for a simple app to a new file called Program.cs. It returns the current date and time, running Kestrel on port 5000 on localhost.

   using System;
   using Microsoft.AspNetCore.Builder;
   using Microsoft.AspNetCore.Hosting;
   using Microsoft.AspNetCore.Http;
   
   namespace ConsoleApplication
   {
       public class Program
       {
           public static void Main(string[] args)
           {
               var host = new WebHostBuilder()
                   .UseKestrel()
                   .Configure(app =>
                   {
                       app.Run(async (context) => await context.Response.WriteAsync("Current date: " + DateTime.Now + "n"));
                   })
                   .Build();
   
               host.Run();
           }
       }
   }

3. Run the dotnet run command to start the .NET Core server:

   $ dotnet run
   Project app (.NETCoreApp,Version=v1.0) will be compiled because inputs were modified
   Compiling app for .NETCoreApp,Version=v1.0
   
   Compilation succeeded.
       0 Warning(s)
       0 Error(s)
   
   Time elapsed 00:00:01.9047678
   
   Hello World!
   Hosting environment: Production
   Content root path: /app/bin/Debug/netcoreapp1.0
   Now listening on: http://localhost:5000
   Application started. Press Ctrl+C to shut down.

4. Run the curl command to test connectivity and HTTP:

   $ curl -v localhost:5000
   * Rebuilt URL to: localhost:5000/
   *   Trying ::1...
   * Connected to localhost (::1) port 5000 (#0)
   > GET / HTTP/1.1
   > Host: localhost:5000
   > User-Agent: curl/7.47.0
   > Accept: */*
   >
   < HTTP/1.1 200 OK
   < Date: Tue, 14 Feb 2017 19:50:59 GMT
   < Transfer-Encoding: chunked
   < Server: Kestrel
   <
   Current date: 02/14/17 12:50:59 PM
   * Connection #0 to host localhost left intact

At this point .NET Core is running on Linux and serving dynamic data using Kestrel as the HTTP server.

Configure NGINX or NGINX Plus to Reverse Proxy the .NET Application

With NGINX or NGINX Plus as a reverse proxy for the .NET application, you can easily configure security with SSL/TLS, HTTP/2 support, and many other features for fast application delivery on the same machine where the .NET Core application is running. The following instructions assume that NGINX and NGINX Plus are already installed on your system; if not, see Install .NET Core, NGINX, and NGINX Plus.

1. Install an SSL certificate. There are several ways to obtain one:

   • Buy it from a well‑known certificate authority (CA)
   • Have your corporate IT group or CA generate it
   • Export it from an existing IIS server
   • Use a free CA like Let’s Encrypt
   • Generate a self‑signed certificate directly

   For the purposes of quickly spinning up a sample .NET Core app with SSL, we’re generating a self‑signed certificate and associated key with this openssl command. We’re installing the certificate and key in the standard location for NGINX, /etc/nginx, but you can choose a different location.

   $ openssl req -x509 -subj /CN=localhost -days 365 -set_serial 2 -newkey rsa:4096 -keyout /etc/nginx/cert.key -nodes -out /etc/nginx/cert.pem
   Generating a 4096 bit RSA private key
   .........++
   ............................++
   writing new private key to '/etc/nginx/cert.key'
   -----

2. Configure reverse proxy in the default NGINX and NGINX Plus configuration file for HTTP virtual servers.

   The main NGINX and NGINX Plus configuration file is /etc/nginx/nginx.conf. However, several NGINX distributions (as well as NGINX Plus) follow the convention that you do not place much actual configuration in the main file, but instead create smaller, function‑specific files in a subdirectory of /etc/nginx:

   • For NGINX Open Source builds provided by nginx.org, and for NGINX Plus, the directory is /etc/nginx/conf.d, and the default file for HTTP virtual servers is default.conf.
   • For NGINX Open Source builds distributed with Ubuntu, the directory is /etc/nginx/sites-enabled, and the default file for HTTP virtual servers is default.

   The content of the function‑specific files in these directories is then read into the main (nginx.conf) file with an include directive, for example:

   include /etc/nginx/conf.d/*.conf;
   include /etc/nginx/sites-enabled/*;

   If you are not sure which is the default configuration file for HTTP virtual servers on your system, find the relevant include directive in /etc/nginx/nginx.conf.

   To configure NGINX or NGINX Plus as a reverse proxy, add the following three configuration blocks to the default configuration file for HTTP virtual servers:

   • The first server block accepts HTTP requests on port 80 and redirects them to the virtual server for HTTPS requests.

   • The second server block accepts HTTPS requests on port 443 and proxies them to a group of one or more upstream (backend) servers, here called dotnet. (If in Step 1 you installed your self‑signed SSL certificate in a directory other than /etc/nginx, substitute the correct path in the ssl_certificate and ssl_certificate_key directives.)

   • The upstream block defines the dotnet group of backend servers.

     In Run the Kestrel HTTP Server, we configured Kestrel on localhost:5000, meaning that it listens for both IPv4 and IPv6 traffic on that port. (Configuring Kestrel for just one protocol can cause instability and potentially 502 errors.) Similarly, NGINX and NGINX Plus resolve localhost to both its IPv4 and its IPv6 address (127.0.0.1 and ::1). For the sake of simplicity, here we identify the upstream server as 127.0.0.1 instead of localhost, so it listens for IPv4 traffic only. You can use localhost if you are comfortable with a more advanced configuration that includes IPv6.

   server {
       listen 80 default_server;
       listen [::]:80 default_server;
       return 301 https://$host$request_uri;
   }
   
   server {
       listen 443 ssl http2 default_server;
       listen [::]:443 ssl http2 default_server;
   
       ssl_certificate /etc/nginx/cert.pem;
       ssl_certificate_key /etc/nginx/cert.key;
   
       location / {
           proxy_pass http://dotnet;
           proxy_set_header Host $host;
       }
   }
   
   upstream dotnet {
       zone dotnet 64k;
       server 127.0.0.1:5000;
   }

3. Run this curl command to test connectivity to the .NET Core app via HTTPS. (You can also point your browser at your Linux server instead.)

   $ curl -kv https://localhost
   * Rebuilt URL to: https://localhost/
   *   Trying ::1...
   * Connected to localhost (::1) port 443 (#0)
   ...[SKIPPED]...
   < HTTP/1.1 200 OK
   < Server: nginx/1.10.0 (Ubuntu)
   < Date: Tue, 14 Feb 2017 20:22:07 GMT
   < Transfer-Encoding: chunked
   < Connection: keep-alive
   <
   Current date: 02/14/17 1:22:07 PM

   Note: If you see 502 Bad Gateway errors, it means that NGINX or NGINX Plus cannot connect to your .NET application. Make sure it’s running and serving responses on port 5000.

   If you have installed the nghttp2 package, you can also run the following nghttp command to test connectivity over HTTP/2. Look for the line highlighted in orange in the following example, near the beginning of the rather lengthy output.

   $ nghttp -v https://localhost
   [  0.000] Connected
   The negotiated protocol: h2
   [  0.009] send SETTINGS frame 
             (niv=2)
             [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
             [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535]
   [  0.009] send PRIORITY frame 
             (dep_stream_id=0, weight=201, exclusive=0)

Configure NGINX Plus Live Activity Monitoring and Active Health Checks

At this point we’ve finished the basic configuration of NGINX or NGINX Plus with .NET Core. NGINX or NGINX Plus is providing HTTP handling, passive health checks, security with SSL/TLS, and HTTP/2 connectivity for our .NET Core app.

If you have installed NGINX Plus, you can configure two additional capabilities: live activity monitoring and active health checks.

Configure Live Activity Monitoring

[Editor – This section has been updated to refer to the NGINX Plus API, which replaces and deprecates the separate extended Status module originally discussed here.]

Add the following server block to the default NGINX configuration file for HTTP virtual servers. We strongly recommend that you restrict access to the statistics and metrics. Here we allow access only to users on localhost and a local network.

For more information on live activity monitoring, see Live Activity Monitoring of NGINX Plus in 3 Simple Steps on our blog and the NGINX Plus Admin Guide.

server {
    listen 8080;
    allow 127.0.0.1;   # Allow localhost to access the statistics
    allow 10.3.3.0/24; # Allow local network to access the statistics
    deny all;          # Prevent access from anywhere else

    root /usr/share/nginx/html;

    location / {
        return 302 /dashboard.html;
    }

    location /api {
        api write=on;
    }

    location = /dashboard.html {
        root /usr/share/nginx/html;
    }

    # Redirect requests made to the old dashboard
    location = /status.html {
        return 301 /dashboard.html;
    }
}

Configure Active Health Checks

Active health checks guarantee that NGINX Plus sends traffic only to applications that are working correctly. You define the HTTP requests that NGINX Plus periodically sends to the app, and the type of response that the app must return to be considered healthy.

Here we require that the response from the app meets the following conditions:

• The response code is 200 OK
• The app server is Kestrel and not some other software
• The body of the response includes the words “Current date”
• The app responds within a 1‑second timeout period

In the default configuration file for HTTP virtual servers, add the following location block to the main server block (the block for HTTPS traffic defined in Step 2 of Configure NGINX or NGINX Plus to Reverse Proxy the .NET Application):

location @healthcheck {
    proxy_pass http://dotnet;
    proxy_set_header Host localhost;
    health_check match=currentdate;
    proxy_connect_timeout 1s;
    proxy_read_timeout 1s;
}

Also add the following match block at the same level in the hierarchy as the server and upstream blocks:

match currentdate {
    status 200;
    header Server = Kestrel;
    body ~ "Current date";
}

You can verify that your backend app is healthy on the Upstreams tab of the built‑in live activity monitoring dashboard (point your browser at //http://nginx-plus-server-address:8080/):

For more NGINX configuration options, see the Microsoft documentation.

Conclusion

For production‑ready deployments of the apps you develop with ASP.NET, NGINX and NGINX Plus provide the traffic‑management features you need in a reverse proxy. NGINX and NGINX Plus provide security, scalability, authentication, traffic limiting, and intelligent routing of your HTTP requests to .NET Core applications.

To try NGINX Plus for yourself, start your free 30-day trial today or contact us to discuss your use cases.

Posted
21 August 2016 —
11 min read

June 28, 2016 by Anuraj Estimated read time : 3 mins

ASP.NET Core Nginx Reverse Proxy Load balancing

This post is about running your ASP.NET Core application with Nginx as reverse proxy on Windows. Nginx is a web server. It can act as a reverse proxy server for HTTP, HTTPS, SMTP, POP3, and IMAP protocols, as well as a load balancer and an HTTP cache. Nginx runs on Unix, Linux, BSD variants, OS X, Solaris, AIX, HP-UX, and Windows. Released under the terms of a BSD-like license, Nginx is free and open source software. Few months back on K-MUG Techday, on a NodeJS session, I asked the question about using NodeJS in enterprise project, then I got introduced to Nginx and reverse proxy concepts in NodeJS. Similar to Node, ASP.NET Core is also supports the Kestrel hosting than IIS, it can be also used along with Nginx and can be hosted in Linux as well..

You can download the Windows version of Nginx from the Nginx download page. You can find more details on Nginx windows version here. Once downloaded, extract the Nginx zip file. And you can run the Nginx.exe file. By default Nginx.exe runs on port 80, if you have IIS installed and running, Nginx.exe will fail to start. You can configure the default port for nginx in the “nginx.conf” file, under “conf” directory. You can modify the server / listen property.

Here is the minimal Nginx configuration to use with Kestrel.

server {
    listen 8080;
    server_name 172.16.198.154;
    
    root /samplewebapp/wwwroot;

    location ~ \.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm|woff2|svg)$ {
        expires 1d;
        access_log off;
        add_header X-Static-File true;
    }

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Connection "";
        proxy_http_version 1.1;
    }
}

You can configure Nginx for load balancing web applications as well. Right now I am configuring Nginx to load balance ASP.NET Core applications running on top of Kestrel. You can do it with Docker as well. For this post I am running Kestrel on different port numbers and load balancing using Nginx default load balancing strategy (Round Robin), and here is the configuraion for load balancing.

upstream localhostapp {
	server 172.16.198.154:5000;
	server 172.16.198.154:5001;
	server 172.16.198.154:5002;
}

server {
	listen       8080;
	server_name  172.16.198.154;

	location / {
		proxy_pass http://localhostapp;
		proxy_set_header Connection keep-alive;
		proxy_set_header Host $host;
	}
}

This configuration tells Nginx to accept requests on port 8080 and proxy those requests to 172.16.198.154:5000, 172.16.198.154:5001 and 172.16.198.154:5002. Now you can shutdown the Nginx.exe using “nginx -s quit” command and restart, and browse the application with 8080 port, you can see your application is load balanced.

Happy Programming

Interesting article? Share it with your friends.

Few weeks ago I showed how to host ASP NET Core on Windows Server behind IIS. Compared to Windows Server, Ubuntu with nginx offers a quicker way to get started and a better control over the kestrel process.
Today we will see how to host an ASP NET Core application on Ubuntu. This post will be composed of three parts:

1. Install nginx
2. Configure nginx
3. Host ASP NET Core

1. Install nginx

Start by installing nginx.

sudo apt-get update
sudo apt-get install nginx

After installing nginx, the daemon should have been installed and started. We should be able to navigate to http://localhost and see the nginx default page.
This page is the default root folder of nginx which can be found under /var/www/html/.

We should also be able to interact with it just like any other daemon managed by systemd:

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl status nginx

And similarly it can be debugged via journald:

sudo journalctl -xeu nginx

If you aren’t familiar with systemd, you can read my previous blog post on how to Manage Kestrel process with systemd.

2. Configure nginx reverse proxy

Nginx is configured using configuration files known as sites.

It is made of modules containing directives allowing us to configure the behaviors of the proxy. The full documentation list all modules.

Here we will use server and location directives coming from the main module and some other directives coming the proxy module.

Nginx comes with a default configuration which can be found under the sites available /etc/nginx/sites-available/default. This is the default created with runs the index page from nginx.

We can create multiple configutations under the sites-available folder like so:

/sites-available/default
/sites-available/myapp.com
/sites-available/helloworld.net

Those configurations will not yet be used by nginx. We need to enable them by having them in the sites-enable folder. This is achieved by creating a symlink, if we navigate to /etc/nginx/sites-enabled, we can find the symlink of default.

ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp

In this example we will setup a frontend with an api. The frontend is a static html page which calls the backend via an api which is built in ASP NET Core.
To setup this, we can start by making our static page available by putting it into our app folder.
/usr/share/myapp/www/index.html.

Then we can setup the first location.

server {
    listen 80 default;
    listen [::]:80;
    server_name myapp.com www.myapp.com;
    root /usr/share/myapp/www;

    location / { }
}

Here we created a server which serves the default index on myapp.com. We listen on port 80 where [::]:80 is meant for ipv6.
root is used to change the root folder to find the index file.
server_name defines the hostname which is handled by this configuration.
The location targets / with an empty content. This will then look for the default page which is the index file.

Now that the static files are served, we can proxy calls going to /api to our kestrel process:

server {
    listen 80;
    listen [::]:80;
    server_name myapp.com www.myapp.com;
    include /etc/nginx/conf.d/http;

    location / { }

    location /api/ {
        include /etc/nginx/proxy_params;
        proxy_pass http://localhost:5000/;
    }
}

include is a directive from the core module which allows us to include a set of directives.
We included proxy_params which is a set of directives condensed for proxying. This file can be found in /etc/nginx/proxy_params.
We also included a set of http params which set the connection to keep-alive.

# /etc/nginx/conf.d/http
proxy_http_version 1.1;
proxy_set_header Connection keep-alive;
proxy_set_header Upgrade $http_upgrade;
proxy_cache_bypass $http_upgrade;

For http://localhost:5000/, the URI / is important as it indicates to nginx that we want to append the rest of the path and remove the matching part. Because of that, on /api/, the trailing slash is equally important as nginx appends a slash (else the proxy would be http://localhost/api/a/b/c => http://localhost:5000//a/b/c which won’t be valid).

Once we are done we can check if the configuration is valid nginx -t. Next we can reload nginx with sudo systemctl restart nginx.
Provided that the symlink was already created, we should now be able to navigate to our static index and to our api endpoints.

3. Host ASP NET Core

Just to complete the loop, we can create a simple ASP NET Core application with a single endpoint returning a json object.

public class HomeController: Controller
{
    [HttpGet("/home")]
    public IActionResult Get()
    {
        return Json(new { test = "test" });
    }
}

We can then uploaded on our server via scp. If you are not familiar with ssh on linux, you can refer to my previous blog post on ssh

scp -r /myapp hostname1:~/
sudo mv ~/myapp /usr/share/myapp

We upload our binaries to /usr/share/myapp as it is the recommended linux filesystem path.

https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Then we can start the process using systemd like how I explained on my previous blog post on How to manage Kestrel with systemd.

And that conclude this post. Now that we have our app setup and nginx setup, we should be able to navigate to the site!

Conclusion

Today we saw how we could configure nginx to proxy our static content and our api. We saw how to work with nginx modules and directives and more importantly where to find the documentation. Lastly we saw how we could put our application on the server and have it proxied behind nginx. Hope you like this post, see you next time!