Skip to main content

Reverse Proxy/Load Balancing with Nginx

Today we’re going to be talking about reverse proxy/load balancing with Nginx. Why is this important? It comes down to not wanting your web apps to have one single point of failure. Performance also plays a big role here. With reverse proxying, there are 3 load balancing methods:

1) Round Robin (goes around in a circle of servers essentially).
2) Least-connected (goes to the server with the least amount of load)
3) IP Hash (chooses what server should be used for the next request

For our testing purposes, we will have 3 servers. Two of them are RedHat 7.5 and the third is Ubuntu 18.04. All of these servers will have Nginx configured.
The first thing we want to do is confirm connection between all servers. In a production environment, you would confirm they’re all on the same subnet and have communication between one-another. In something cloud based like AWS, you would want to confirm they’re in proper security groups that allow certain types of connection and communication. This is out of the scope of this blog, but there is a ton of information out there. A good note to keep in mind is ICMP is NOT turned on by default in security groups if you are trying to ping other hosts for communication testing.
After we have confirmed communication between the servers, update those bad boys so we can get to the fun stuff.

First things first, we need to install Nginx. To install Nginx on RedHat, do the following;

```sudo rpm -ivh```
```Yum update –y```
```yum install nginx –y```

Aptitude made it easy for us and put it right in the package manager, so for Ubuntu, do the following;

```Apt-get install nginx```
After that, confirm Nginx is running. On RedHat;

```Systemctl status nginx```

On Ubuntu;

```Service nginx status```

After that, do a curl to localhost and confirm you see HTML;

```Curl localhost```

As RedHat 7.5 will be our Reverse Proxy host, we want to cd (change directory) to the following location;

```Cd /etc/nginx```

You’re going to see several configuration files here. Run a cat on nginx.conf.

This is the default Nginx configuration file. In production, we need to create a new Nginx config file. On RedHat, it will be in /etc/nginx/conf.d. In Debian based systems, it will be in /etc/nginx/sites-enabled
Lets cd (change directory) to the conf.d file and run;

```touch myserver.conf```

Use vim or vi and paste in your first block;

server {
        Listen 80;

Above is the beginning to your configuration. This says “hey Mr. RedHat server, listen to traffic on port 80 on this server”.
Remember this config block, because we will be coming back here shortly. The next thing we want to do is put in an “upstream server” block. This allows the reverse proxy/load balancer to look at all of the servers in the block and point to them. For our purposes, we are going to use IP addresses. You can use hostnames as well. This block is going to be posted ABOVE the server block.
    ```upstream mynewserver {

The last thing we are going to do is our proxy_pass line. The proxy_pass is what makes all of the magic happen in a reverse proxy. It’s saying “hey, push the traffic to the upstream blog”
At the end, your config should look like the below;

PLEASE pay attention to the opening and closing brackets. These are very important and one wrong placement will throw your config out of wack.
Now it’s time to test!
Run the following;

```nginx –t```
Your output should show something similar to the following. If not, please go back and see if you missed any steps;

```nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful```

Next, restart nginx;

```Systemctl restart nginx```


Popular posts from this blog

Run PowerShell code with Ansible on a Windows Host

Ansible is one of the Configuration Manager kings in the game. With it's easy-to-understand syntax and even easier to use modules, Ansible is certainly a go-to when you're picking what Configuration Management you want to use for your organization. Your question may be "but Ansible is typically on Linux and what happens when I'm in a Windows environment?". Luckily I'm here to tell you that Ansible will still work! I was pleasantly surprised with how easy it is to use Ansible on Windows with a little WinRM magic. Let's get started.

Pre-requisites for this post:
1) WinRM set up to connect to your Windows host from Ansible
2) Ansible set up for Windows Remote Management
3) SSH access to the Ansible host
4) Proper firewall rules to allow WinRM (port 5985) access from your Ansible host to your Windows host
5) Hosts file set up in Ansible that has your IP or hostname of your Windows Server.
6) At least one Linux host running Ansible and one Windows Server host …

Running PowerShell commands in a Dockerfile

As Docker continues to grow we are starting to see the containerization engine more and more on Windows. With the need for containers on Windows, we also need the same automation we get in Linux with Dockerfiles. Today we're going to create a Dockerfile that runs PowerShell cmdlets.
Prerequisites; 1. Docker for Windows
2. A code editor (VSCode preferred)

Let's go ahead and get our Dockerfile set up. Below is the Dockerfile I used for this post.

from MAINTAINER Michael Levan RUN powershell -Command Install-WindowsFeature -Name Web-Server RUN powershell -Command New-Item -Type File -Path C:\ -Name config
As you can see from the above, this is a tiny Dockerfile. What this will do is install the IIS Windows 

Feature and create a new file in C:\ called "config".
You should see something very similar to the below screenshot;

Next let's create a running container out of our image. First we'll need to run docker container ls to

 get o…

DevOps tooling in the Microsoft realm

When I really started to dive into automation and practicing DevOps with specific tooling, there were a few key players. At the time Microsoft was not one of them. They were just starting to embrace the open source world, including the art and practice of DevOps. Since then Microsoft has went all in and the tech giant has made some incredible tooling. Recently I switched to a Microsoft-heavy environment and I love it. I went from AWS/Python/Ansible/Jenkins to Azure/PowerShell/ARM/Azure DevOps. My first programming language was PowerShell so being back in the saddle allowed me to do a full circle between all of the different types of tooling in both worlds. Today I want to share some of that tooling with you.

The first thing I want to talk about is ARM. What is ARM? ARM is a configuration management tool that allows you to perform software-defined-infrastructure. Much like Ansible and Terraform, ARM allows you to define what you want your environment to look like at scale. With ARM, yo…