Yes. You heard that right. So being able to work with Linux servers is a great skill to have.

In this article, you'll learn how to connect to a Linux server using SSH, how to communicate with other users on the server, and you'll see a handy file transfer mechanism.

A quick note before we dive in: the IP address that I've given in the example commands and the one in the example screenshots will vary. The reason is, I don't have a server to demonstrate everything, so I made my laptop a server. So, all my example screenshots will be displaying my local IP addresses beginning with 192.168....

How to Log in to a Server Running Linux

I love to develop software, but I really dislike DevOps and deployments. When I have some kind of DevOps work, I'll hand it over to the specialist in my team and stay away.

The reason is my lack of experience in handling servers. But sometimes, when my team members are not available, I'm forced to do deployments.

So, the initial step for a (manual) deployment is to log in to the server. To log in, you need to know the IP address and the password of the server.

Above all, you need to have the SSH client installed on your machine. This comes pre-installed on almost all Linux distros.

If you don't have it installed, you can install it by running the below command in the terminal:

sudo apt install openssh-client

In order to access the server via SSH, the server should have SSH Server installed and the service running in it. This will be pre-installed on almost all Linux servers.

Let's connect to the server now.

You need the following items to login to the server:

1. IP Address of the server machine
2. Username of the server
3. The password of the user

ssh user@<ipaddress>

Here's an example command:

ssh ubuntu@45.244.96.73

The above command will ask for the password. If you enter the password, it will log in to the server.

Sample output of connect with Linux Server using SSH Command.

Alternatively, you can log in without any prompt by adding the -p option with the sshpass command prepended to ssh command. You need to have sshpass installed to try this method.

The syntax looks like this:

sshpass -p <password> ssh user@<ipadrress>

And here's a quick example:

sshpass -p password ssh user@45.244.96.73

This is not the recommended way. Command line arguments are visible to all users (for example, ps -ef | grep sshpass). sshpass attempts to hide the argument, but there is still a window during which all users can see your password passed by argument.

There's also a command in Linux called history which displays your past commands. Any user who gain access to your machine may run the history command and find your server login credentials. But if you've entered the password in a prompt, it'll not be shown to users in the history command.

Here's the output of history command:

history command displays past commands

How to Log in to a Particular User in the Linux Terminal

In Linux, we can log in to different users using two different approaches:

1. ssh
2. login

How to log in with SSH

As already discussed with the SSH command, we can login to another user using the same syntax.

ssh <user>@<ipaddress>
ssh root@45.244.96.73

How to log in with the login command

You can use the login command to switch the user inside the server.

Let's assume you've logged into the ubuntu user in the 45.244.96.73 server. Later you found that you want to switch to the ak user to perform some admin operations. In such a case, you can quickly switch the user using the login command.

Syntax for the login command is:

sudo login <username>

And here's an example to switch to the root user:

sudo login ak

The above command will prompt for the password similar to login via SSH.

Sample output to connect with Local User

Hurray, we successfully logged in to another user. Now let’s explore how to communicate with these sessions.

A quick note before jumping onto the communication section. If you wish to log out of the logged-in user, you can simply run the logout command.

How to Communicate Between Sessions in Linux

Did you know that you can use your Linux terminal as a chat interface?

Well, yes – you can. If you and your colleagues are connected as their own users to the same server using SSH, then you all can communicate via the terminal.

As with all such features, there are a few pre-requisites to continue.

First, make sure that message access is enabled in the receiver system. To verify that, type the following command in the terminal:

mesg

Terminal command to verify if message access is enabled

The response will be either yes or no.

is y – Message access enabled

is n – Message access disabled

To toggle this feature, you have to pass the symbol along with the mesg command.

mesg y      # Enable message access
mesg n      # Disable message access

Let's try to communicate with others.

There are two commands available to communicate:

1. write
2. wall

The write and the wall commands use a fairly simple mechanism. Both commands take a message from one session and deliver it to other session(s).

How to use the write command

You can use the write command to message a single user (Direct Message).

write <username>

write ak

After entering this command, it prompts for the input message to send. We can send any number of messages using the write command.

Here's an example showing the communication between the users ak and gogosoon:

Sample output of sending message to the user

Sample output of received message using write command

Let's turn off messaging on the ak user and try to send a message from the gogosoon user.

mesg n

Turn off messaging for ak user

Trying to send a message to ak user from gogosoon user

How to use the wall command

You can use the wall command to write messages to all logged-in users. This command will display the message or the contents of a file to all the logged-in users. Basically, it will broadcast the message to all the sessions.

wall <message>

Sample command to send message to all logged in user

Sample output of received message from user gogosoon

Here we can see the message in the user ak. Similarly, it prompts the message to every logged-in user.

How to Transfer Files to/from the Server Using the Linux Terminal

I believe most people would recommend using FTP to transfer files from and to the server. FTP provides more control over the files such as the ability to rename, delete, move, and modify files from the remote computer.

But FTP does not offer protection against anyone who may be trying to view your network credentials.

We can do this using a Linux terminal – and believe me it's super simple.

You can transfer files using the scp command.

SCP stands for Secure Copy Protocol. This command allow the user to share the files in a secure way. Unlike FTP, SCP is highly secure. It uses secure shell to encrypt both your data and credentials. SCP does not provide facilities to control files.

Since this command follows the end-to-end encryption protocol, it uses encryption over an SSH connection. This will protect the files from suspicious attacks.

Transferring files via SCP will be slow when compared with FTP. But, it's a better alternative to FTP if you need a one-time movement of files.

The syntax for the SCP command looks like this:

scp [OPTIONS] <user>@<src_host>:<file_src_path> <user>@<dest_host>:<file_dest_path>

Using the SCP Command we can do the following operations,

1. Copy the file from our machine to the server machine
2. Copy the file from the server machine to our machine
3. Copy the file from one server to another server

Let's look at each of these operations in more detail now.

How to copy the file from the client machine to the server machine

When copying files from the local to the server machine, you should enable SSH in the server. This is because SCP uses SSH to establish the connection between the client and server machines.

scp <filepath> user@hostname:<filepath>

scp sample.txt ak@45.244.96.73:/home/ak/

Sample Output to transfer files from Local machine to Server

File uploading status

Sample.txt has been transferred to server

The above screenshots show that the file was copied to the server.

How to copy the file from the server machine to the client machine

Let's see how to transfer the file from the server to our local machine:

scp server_username@<server_host>:<filepath> <local_path>

This command will copy the file server_file.txt from the server machine to the local machine in the test directory.

scp ak@45.244.96.73:/home/ak/server_file.txt /home/gogosoon/test

If you leave the local_path empty, the file will be copied to the home directory.

Create file in server to transfer

Sample output of transfer file from server to local

How to copy the file from one server to another server

Let's assume you're taking a backup of a file from a server. You don't want this file to be stored on your machine due to some security concerns. But, you want to transfer this file to another server.

Copying files from one server to another server is also possible with the scp command:

scp <src_user>@<src_host>:<src_path> <dest_user>@<dest_host>.com:/<dest_path>

scp ak@45.244.96.73:/home/ak/script.sh gogosoon@45.244.196.173:/home/gogosoon/

Conclusion

Alright, we've come to the end of this tutorial. I hope you all enjoyed learning about these helpful commands.

If you are a DevOps Engineer, Linux Developer, or you're learning Linux, these commands will be very useful. If you enjoyed this guide, please share it with your colleagues/friends who are more into working on servers.

To learn more about Linux, subscribe to my email newsletter on my site and follow me on social media.

Taking a quiet walk in the woods? What about the smartphone in your pocket. Left the phone in the car? See that cell phone tower just behind those trees? The odds are good that the tower is more than just an antenna. It could also be hosting an edge computing server. And don't think that there weren't computers embedded into the under-the-hood workings of the car (or bus) that drove you over.

Allergies aside, if you want to fully grasp the current state of the compute world, it'll be helpful to understand all the places computers can pop up and what they might look like.

In this article, we'll enumerate the classes into which modern compute devices can fall, and describe their strengths, weaknesses, and potential.

This is a chapter taken from the book, Keeping Up: Backgrounders to All the Big Technology Trends You Can't Afford to Ignore. If you'd prefer to watch this chapter as a video, feel free to follow along here:

What is a Server?

Honestly, I'd been working as a professional system administrator for a while before I could have properly answered that question.

The truth is that every server is a computer, and any computer can be a server. The term server simply implies that the device is providing some service to at least one external device (known as a client).

If the printer that's plugged into your desktop computer can be shared by the other computers in your local network, then your desktop is a server (a printer server, to be precise).

The WiFi router provided by your internet service provider is, by all definitions, a network server – as it serves network access to its clients.

And the tiny, $5 Raspberry Pi Zero single board device that powers your homemade surveillance camera is a video server – although that won't work without attaching a $7 camera module.

But that's not what most people are thinking about when they use the term. The first time I ever walked into the server room belonging to a mid-sized business, I was hit by the sound of dozens of powerful chassis fans and the heat from hard-working CPUs and fast-spinning disk drives. Instantly, I knew how folks normally use the word.

I also soon discovered that the heat was a problem: the admins were struggling to keep their server room properly cooled and would, over time, end up having to write off some expensive hardware due to heat-related failures.

So, by "server," we usually mean computers installed within those rack-mounted, stackable cases built to efficiently house and protect highly performant, expensive, and delicate components.

Server racks will normally live in well vented and cooled rooms with easy access to ample electrical power. You may have to search for them, but such rooms will also always contain colorful bundles of cabling, connecting the servers to networks.

As a rule, servers won't usually have displays or even keyboards plugged in, as they're likely to be managed remotely or, even more likely, fully automated and requiring no administration at all.

Server farms belonging to giant cloud providers like Amazon Web Services will have many thousands of commodity computers running within aisle after aisle of vast warehouses. When one fails, a monitoring panel somewhere will light up and a technician will eventually be dispatched to remove the server, throw it out, and slide a replacement into the newly-available rack.

No tears are shed when we say goodbye to hardworking and devoted old hardware in those places.

What is Linux?

Speaking of servers, did I mention that they all need some kind of operating system installed?

And did I mention further that the vast majority of the servers powering the vast majority of the operations that make the internet and all its functionality possible are running the Linux operating system? Oh, and did you know that the open source Linux operating system is available for free?

I didn't mention all that? My bad.

Well, servers need operating systems. Most servers (well over 90 percent of the virtual machine instances running on Amazon's AWS EC2, for instance) run Linux. And Linux is, indeed, freely available for any use on any server, laptop, desktop, router, embedded system, or supercomputer.

In fact every last one of the world's top 100 supercomputers uses Linux. And the Android smartphone OS? Yup. It's Linux, too.

Strictly speaking, "Linux" is the software kernel that allows a computer user to take control of a computer's physical hardware elements. The kernel translates your keystrokes into a format that will be understood by the drivers controlling your storage drives, memory, network interfaces, displays, and – in fact – keyboard and mouse.

Many thousands of additional software programs are closely associated with Linux, but they're actually part of the user space that hovers "above" the Linux kernel.

Having said all that, Linux, including its broader software ecosystem, dominates the server computing market right now. The fact that you can freely install and fire up as many physical or virtual instances as you like makes Linux very attractive, especially in the scripted workload orchestration world.

Virtualized Linux instances will often be brought to life and then, after completing a task that takes even a few seconds, killed off again.

The versatility and flexibility Linux brings to computing have been the spark of some deeply impressive innovation and creativity.

Part of the Linux versatility is the fact that you can choose from among hundreds of variations (known as distributions).

Are you looking to run enterprise-supported servers? Internet of Things (IoT) devices? Security testing machines? Multimedia management? Video or audio production? All of the above? None of the above? There's bound to be a distribution that's a good match for you.

And if the exact specs you need can't be found, feel free to rewrite the kernel itself and create your own distro.

Full disclosure: I know a thing or three about Linux, being the author of Linux in Action (Manning), a coauthor of Ubuntu Bible (Wiley), and the author of the Linux Fundamentals learning path at Pluralsight.

Fuller disclosure: I'm writing this on an Ubuntu Linux workstation in my home, where all of our many devices have been Linux-powered for more than a decade.

What is Virtualization?

We've already discussed virtualization in some depth as part of Chapter 3 (Understanding the Cloud), so we'll just cover some big-picture conceptual basics here.

In the old days, you'd come up with an idea for a new compute project and submit a proposal with your managers asking for money. When the project was green lighted, you'd estimate your requirements, solicit bids from hardware vendors, order a new server and, when it finally arrived, load it up with your application software. Then you'd fire it up, and let the world see what you'd done.

That's the way things usually worked: One project. One server. Lots of waiting time.

But what if you overestimated your compute needs by 50 percent? That'd be a few thousand dollars down the drain. And if an important but lightweight project didn't really need a full, standalone server, you'd often have to buy it anyway.

How about if the project would only have to run for a few months? Spend the money and hope you'll find a new use for the thing once your initial project shut down.

Awkward. Mountains of awkward.

Virtualization is a (mostly) software trick that lets you fool multiple installed operating systems into thinking they're all alone on a physical computer when they're really sharing it with other OS's. You can provision and run a single virtualization host of one flavor or another and then fill it up with one or a hundred virtual servers.

One of those servers might need a lot of system memory but only a GB or two of storage space. Another one might be heavy on video conversion tasks and storage but is only needed for a half an hour a day. A third could be a 24/7 monitoring system that just needs a quiet place to do its thing without anyone bothering it.

As long as you never push the physical host past its overall resource limits, the virtual machines can all coexist happily together. And when one service is no longer needed, you can reassign its freed-up resources to something else.

The ramp-ups and ramp-downs of a typical virtual server's life cycle are fast. For all intents and purposes, they'll generally launch and shut down instantly.

This is possible because the underlying hardware is always running – and because the OS image is small and, usually, optimized for virtual environments.

As we saw back in Chapter 3, cloud-hosted services are all virtualized. As more and more IT infrastructure moves to the cloud, more and more of your online activities will be driven by virtual machines.

You won't notice the difference, but every time you search the internet or authenticate to an online account, there's a good chance that it's a container or VM you're connecting to, and not directly to a physical machine.

Cloud Computing Terminology

Like virtualization, we also talked about the cloud back in chapter 3. We mentioned how the public cloud market was dominated by AWS and, to a lesser extent, by Microsoft's Azure.

I'll just take a minute or two here to add a quick guide through some of the cloud industry's worst jargon.

Infrastructure as a Service (IaaS) environments give you full access to virtual server instances. The provider will ensure the underlying hardware, networking, and security elements are in place and functioning, while it's your job to manage the OS and other software running on your instance.

Major IaaS players include Amazon's Elastic Compute Cloud (EC2) and Azure's Compute.

Platform as a Service (PaaS) environments hide most or all of the infrastructure administration tasks from you, leaving you with an interface where you can run your own data or code.

One good example is AWS Elastic Beanstalk, which lets you upload your application code from where it'll be automatically deployed to Amazon's cloud. Other providers in this space include Heroku and Salesforce Lightning Platform.

Software as a Service (SaaS) environments expose only an end-user interface, managing all layers of the administration infrastructure invisibly.

Microsoft's Office 365 and Google's G Suite are widely used SaaS office productivity tools.

But there's a growing marketplace of SaaS tools providing online software equivalents to many applications that, in years past, could only be used on standalone workstations. Those applications include accounting, computer assisted design (CAD), and graphic design solutions.

Consumption-based pricing or, as it's sometimes known, pay-as-you-go billing, is a cornerstone of the cloud concept. The idea is that you don't have to gamble by investing up-front in infrastructure, but you can pay incremental amounts for units of compute services as you use them.

It might not always come out cheaper in the long-run. But pay-as-you-go definitely makes it easy to test application stacks and experiment with multiple alternative configurations before pulling the trigger on a full deployment.

It also means that – assuming you don't make any dumb configuration mistakes – it's nearly impossible to badly over-provision.

On-demand is also sometimes referred to as self-service. The ability to request instant delivery of compute resources any time of the day/week/year gives you complete control over your organization's application life cycles. You're never at the mercy of other people's schedules and limitations.

Service Level Agreements (SLAs) are legal disclosures published by companies in the business of providing services.

Even if the standard of resource reliability provided by the major public cloud platforms is generally excellent, accidents will happen. When you pay hourly or monthly fees for cloud services, the company's SLA tells you that you should anticipate downtime of a certain number of minutes or hours each month.

As an example, Amazon's SLA sets its EC2 availability rate at 99.99% each month. If, in a particular month, you encounter greater downtime, you might be eligible for service credits or refunds.

Multitenancy is the placement of virtual instances belonging to multiple cloud customer accounts on a single hardware resource.

A multitenancy setup for a server instance will probably be significantly less expensive than a dedicated instance. Choosing a dedicated instance, however, would guaranty that your instance will never be hosted on a physical server alongside an instance from a second account. Security or regulatory considerations might require that you avoid multitenancy.

Migration describes the process involved with moving existing business application and database workloads from local (on-premises) deployments to a cloud provider. Providers often make specialized tools and free tech support available for migrations.

Elasticity describes the ways virtualized cloud resources can be quickly added to meet growing demand or, equally quickly, reduced in response to dropping demand.

Elastic resources are especially well-suited to maintaining application availability and health without incurring unnecessary costs. Elasticity can usually be automated, so applications will respond instantly to changing environments without the need for manual intervention.

What is "Serverless" Computing?

Serverless computing is no different from server computing. It's just that, even if you squint your eyes real tight, you don't get to see the server.

Or, to put it another way, serverless computing is like running a virtual server instance, but without having to configure its instance settings or log in to set things up.

In other words, you can't run software code of any kind without a computer somewhere processing your commands. So let's say that serverless is a form of virtualization where everything except your application code is abstracted.

In that sense, serverless platforms like Amazon's Lambda and Azure's Functions are a lot like the model used by Amazon Elastic Beanstalk. But they're so simple to use that they can easily be incorporated into a larger, highly automated multi-tier workload.

What is Edge Computing?

Latency is the term we use to describe the time it takes for data to travel from a remote server across a network to your computer – or back in the other direction. Assuming you prefer fast service over slow service (which seems a safe assumption), high latency numbers are a bad thing.

Network engineers can invoke various magical spells – Oops! I mean clever configuration efficiencies – to reduce delays due to latency.

But no matter how many tricks they're hiding in their mysterious black bags, they can't ignore the laws of physics. Even using the best connections and configuration profiles, data still has to physically move across the distances between remote locations.

The only way to reduce this kind of latency is to shorten the distance. I suppose that one way would be for online service providers to very politely ask their customers to sell their houses and move somewhere closer to the servers running in the office (as if real estate prices weren't already high enough in Silicon Valley).

Alternatively, though, how about moving the server closer to the customer?

Ah. You've discovered edge computing: the fine art of installing large distributed networks of smaller servers where mirror copies of server data can be stored and, when necessary, fed to any customers in the area who initiate requests.

If you've got enough of those servers spread evenly through the geographic regions where you customers live, then you can significantly reduce the latency they experience.

One kind of edge computing that performs this function is known as a content distribution network (CDN). Cloudflare and Amazon's CloudFront are among the larger CDNs currently in operation.

Edge computing resources like those used by CDNs have also increasingly been used to manage large streams of data from and to IoT devices like the computers embedded in cars. Placing capable compute devices at the edges of large networks makes it possible to consume and transform such data sets faster than by moving the data all the way back to the more distant cloud.

What Are the Key Compute Form Factors?

Computers, like egos, come in all shapes and sizes. Would you like to carry a rack full of bare metal servers around in your pocket to pay for your shopping? You're probably better off using some kind of mobile payment app on your smartphone.

Size matters. A lot. A device's form factor will determine the dimensions and capacity of its internal components. That means the particular motherboard, memory modules, storage drives, peripheral ports, and power supply you select for a device will be limited by your overall form factor.

The form factor you choose – for either a new project or just for your personal use – will generally be obvious (server racks can be heavy and don't handle travel well). But knowing what's available can make it easier to plan.

Devices using video displays

The term personal computer (PC), these days, is used to describe either desktop or laptop computers.

Laptops, since they're designed to be mobile, are largely self-contained. Desktops, by contrast, generally come with the core compute elements within a box that includes external ports for connecting peripherals like keyboards and monitors.

While you can find computers with power and functionality that's comparable to PCs in very small (credit-card sized) cases, the larger boxes used by desktops allow for easier customization and upgrades.

Gaming consoles – like Sony's PlayStation, Microsoft's Xbox, and the Nintendo Switch – are effectively the equivalent of desktop PCs, except that their software is built on closed systems.

They're "closed" in the sense that their software interface exposes only the functionality the manufacturer wants you to see. Modifying or customizing the OS or internal works of a game console is normally impossible.

A touchscreen device uses the gestures and taps it senses from users as input devices in place of the traditional mouse or keyboard. Touchscreen technologies are the primary inspiration behind smaller form factors for consumers, since there's no need for external input devices.

This, more than just about anything else, has driven the tremendous growth of the tablet and smartphone markets. (It also explains the freakishly agile thumbs of entire generations of young people.)

Devices without video displays

The router that connects devices to a network through either WiFi or ethernet cables contains pretty much the same internal motherboard and network interfaces that you'd find in any other compute device.

The big difference is that there's no HDMI, DVI, or VGA video port. Routers are meant to run autonomously and, when administration is necessary, it'll usually happen through a browser interface across a network.

You launch an admin session with your router by entering its IP address into your browser and authenticating when prompted. In some cases, you can also launch terminal sessions through the Secure Shell (SSH) protocol.

This remote administration model is shared by many display-less device types. Those will include medical (and non-medical) implants or wearables that come with tiny computers built to monitor, report, or even interact with their host environments.

(In the context of wearables, I would at least briefly discuss smart watches here but, for the life of me, I can't figure out why anyone would want one.)

Display-free computers are also embedded in medical devices, appliances, cars, logistics fleets and industrial machinery. All of those embedded computers are components of the growing internet of things.

Thanks for reading!

YouTube videos of all ten chapters from this book are available here. Lots more tech goodness - in the form of books, courses, and articles - can be had here. And consider taking my AWS, security, and container technology courses here.

What if it's not just one server but many? The amount of time you will need to fix all of them will grow exponentially – and because is a manual process it will be more error-prone.

And then the nightmare scenario: You don't have an up-to-date backup, or you have incomplete backups. Or the worst – there are no backups at all. This last case is more common than you think, especially in home labs where you are tinkering and playing around with stuff by yourself.

In this tutorial, I'll show you how you can do a full infrastructure provisioning of a pair of web servers on a Cloud provider, with SSL certificates and monitoring metrics with Prometheus.

What You Need for This Setup

The first thing you need is a cloud provider. Oracle Cloud offers a Free Tier version of their cloud services, which allows you to setup virtual machines for free. This is great for a home lab with lots of rich features that you can use to try new tools and techniques.

You'll also need an automation tool. I used Ansible because its doesn't have many requirements (you only need an SSH daemon and public key authentication to get things going). I also like it because it works equally well regardless of the cloud environment you are trying to provision.

In this tutorial we will use the Open Source version of this tool, as it is more than sufficient for our purposes.

What's included in the Ansible playbook

An Ansible playbook is nothing more than a set of instructions you define to execute tasks that will change the status of a host. These actions are carried out on an inventory of hosts you define.

Here, you are going to learn about the following:

• How to clean inventory sources by using the proper layout in your playbooks.

• How to provision two NGINX instances, with the request of their proper free SSL certificates using Certbot.

• How to set up the local Linux firewalls and add a Prometheus node_exporter agent and one scraper to collect that data.

• Concepts like variables, roles (with task inclusion), and conditional execution.

• Important techniques like task tagging, debug messages, and static validation with ansible-lint.

All the code can be found in this GitHub repository.

What You Should Know Before Trying This

Because we will cover several tasks here, you will probably need to be familiar with several things (I'll provide links as we go along):

• This is not an introductory course on Ansible but more of a "how all things fit together" with a more detailed, but not too complex, playbook.

• An OCI Cloud Free Tier account

• Privileged account, most likely SUDO

• Basic knowledge of TCP/IP and firewalls with firewalld

• How to use RPM and how to package applications (we will not do that here, but it helps to understand when an RPM is better than a complex task in Ansible)

What is not included here

OCI Cloud has a complete REST API to manage a lot of aspects of their cloud environment. Their setup page (specifically the SDK) is also very detailed.

You'll Probably Do Things Differently in Production.

Installing the OCI-Metrics-datasource instead of Prometheus agents on a virtual machine

You can go to this page to install it on your Grafana instance (Bare metal or Cloud). Also you need to setup your credentials and permissions as explained here.

This is probably the most efficient way to monitor your resources as you do not need to run agents on your virtual machines. But I will install instead a Prometheus node_exporter agent and scraper that will be visible from a Grafana Cloud instance.

An exposed Prometheus on the Internet endpoint is not a good idea

It is very clear, I'm exposing my Prometheus scraper to the Internet so Grafana cloud can reach it. On an Intranet with a private cloud and your local Grafana, this is not an issue – but here, a Prometheus agent pushing data to Grafana would be a better option.

Still, Grafana provides a list of public IP addresses that you can use to setup your allow list.

So the following will work:

Oracle Cloud Ingress Rules

But it is not the best. Instead, you want to restrict the specific IP addresses that can pull data from your exposed services. The prometheus exporter can be completely hidden from Grafana on port 9100. Instead we only need to expose the Prometheus scraper that listens on port 9000.

For this home lab, it is not a big deal having such services fully exposed. But if you have a server with sensitive data, you must restrict who can reach the service!

An alternative to the Prometheus endpoint is to push the data to Grafana by using a Grafana agent but I will not cover that option here.

Playbook Analysis

Ansible lets you have a single file with the playbook instructions, but eventually you will find that such a structure is difficult to maintain.

For my playbook I decided to keep the suggested structure:

tree -A 
.
├── inventory
│   └── cloud.yaml
├── oracle.yaml
├── roles
│   └── oracle
│       ├── files
│       │   ├── logrotate_prometheus-node-exporter
│       │   ├── prometheus-node-exporter
│       │   └── requirements_certboot.txt
│       ├── handlers
│       │   └── main.yaml
│       ├── meta
│       ├── tasks
│       │   ├── controller.yaml
│       │   ├── main.yaml
│       │   ├── metrics.yaml
│       │   └── nginx.yaml
│       ├── templates
│       │   ├── prometheus-node-exporter.service
│       │   ├── prometheus.service
│       │   └── prometheus.yaml
│       └── vars
│           └── main.yaml
└── site.yaml

Below is a brief description of how the content is organized:

1. You can have more than one site. You control that inside the [site.yaml](file:///home/josevnz/OracleCloudHomeLab/site.yaml) file.

2. The host list is inside the inventory directory. You can have more than one inventory file or scripts to generate the hostlist, or a combination of both.

3. The roles/oracle group the tasks. We only have one role called 'oracle' because that's the cloud provider I'm focusing on here.

4. Our playbook uses metadata in the form of variables, with each one defined on the 'vars' directory. That way we can customize the behaviour of the playbook in multiple places:

---
# Common variables for my Oracle Cloud environments
controller_host: XXXX.com
ssl_maintainer_email: YYYYYY@ZZZZ.com
architecture: arm64
prometheus_version: 2.38.0
prometheus_port: 9090
prometheus_node_exporter_nodes: "['X-server1:{{ node_exporter_port }}', 'Y-server2:{{ node_exporter_port }}' ]"
node_exporter_version: 1.4.0
node_exporter_port: 9100
internal_network: QQ.0.0.0/24

The roles/oracle files directory contains files that can be copied as is to the remote directory. The templates' directory is similar, but the files in there can be customized for each host by using the Jinja templating language.

# A template for the prometheus scraper configuration file
---
global:
    scrape_interval: 30s
    evaluation_interval: 30s
    scrape_timeout: 10s
    external_labels:
        monitor: 'oracle-cloud-metrics'

scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: {{ prometheus_node_exporter_nodes }}
    tls_config:
      insecure_skip_verify: true

The 'tasks' directory is where we store our tasks, that is the actions that will modify the server state. Note that Ansible will not execute tasks if it's not necessary. The idea is that you can re-run a playbook as many times as needed and the final state will be the same.

# Fragment of the nginx tasks file. See how we notify a handler to restart nginx after the SSL certificate is renewed.
---
- name: Copy requirements file
  ansible.builtin.copy:
    src: requirements_certboot.txt
    dest: /opt/requirements_certboot.txt
  tags: certbot_requirements

- name: Setup Certbot
  pip:
    requirements: /opt/requirements_certboot.txt
    virtualenv: /opt/certbot/
    virtualenv_site_packages: true
    virtualenv_command: /usr/bin/python3 -m venv
  tags: certbot_env

- name: Get SSL certificate
  command:
    argv:
      - /opt/certbot/bin/certbot
      - --nginx
      - --agree-tos
      - -m {{ ssl_maintainer_email }}
      - -d {{ inventory_hostname }}
      - --non-interactive
  notify:
    - Restart Nginx
  tags: certbot_install

There is one special directory called 'handlers'. There we define actions that must happen if a task changes the state of our host.

We now have a picture of how all the pieces work together, so let's talk about some specific details.

Firewall provisioning

With Ansible, you can replace a sequence of commands like this:

sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

With a firewalld module:

---
- name: Enable HTTP at the Linux firewall
  firewalld:
    zone: public
    service: http
    permanent: true
    state: enabled
    immediate: yes
  notify:
    - Reload firewall
  tags: firewalld_https

- name: Enable HTTPS at the Linux firewall
  firewalld:
    zone: public
    service: https
    permanent: true
    state: enabled
    immediate: yes
  notify:
    - Reload firewall
  tags: firewalld_https

Common tasks have nice replacements

So instead of running SUDO with a privileged command:

sudo dnf install -y nginx
sudo systemctl enable nginx.service --now

You can have something like this:

# oracle.yaml file, which tells which roles to call, included from site.yaml
---
- hosts: oracle
  serial: 2
  remote_user: opc
  become: true
  become_user: root
  roles:
  - oracle
# NGINX task (roles/oracle/tasks/nginx.yaml)
- name: Ensure nginx is at the latest version
  dnf:
    name: nginx >= 1.14.1
    state: present
    update_cache: true
  tags: install_nginx
# And a handler that will restart NGINX after it gets modified (handlers/main.yaml)
---
- name: Restart Nginx
  ansible.builtin.service:
    name: nginx
    state: restarted
- name: Reload firewall
  ansible.builtin.systemd:
    name: firewalld.service
    state: reloaded

How to Run the Playbooks

Normally you don't wait to have the whole playbook written, but you run the pieces you need in the proper order. At some point you will have your whole playbook finished and ready to go.

Make sure the playbook behaves properly with --check before making any changes

The very first step is to check your playbook file for errors. For that you can use yamllint:

yamllint roles/oracle/tasks/main.yaml

But doing this for every yaml file in your playbook can be tedious an error-prone. As an alternative, you can run the playbook in a 'dry-run' mode, to see what will happen without actually making any changes:

Another way to gradually test a complex playbook is by executing a specific task by using a tag or group of tags. That way you can do controlled execution of your playbook:

Keep in mind that this will not execute any dependencies that you may have defined on you playbook, tough:

Use Ansible-lint when ansible-playbook --check is not good enough

Some errors are more subtle and will not get caught with ansible-playbook --check. To get a more complete check on your playbooks before minor issues become a headache you can use ansible-lint. So let's get it installed:

python3 -m venv ~/virtualenv/ansiblelint && . ~/virtualenv/ansiblelint/bin/activate
pip install --upgrade pip
pip install --upgrade wheel
pip install ansible-lint

Now we can check the playbook:

(ansiblelint) [josevnz@dmaf5 OracleCloudHomeLab]$ ansible-lint site.yaml 
WARNING  Overriding detected file kind 'yaml' with 'playbook' for given positional argument: site.yaml
WARNING  Listing 1 violation(s) that are fatal
syntax-check[specific]: couldn't resolve module/action 'firewalld'. This often indicates a misspelling, missing collection, or incorrect module path.
roles/oracle/tasks/nginx.yaml:2:3

Strange, firewalld is available on our Ansible installation. What else was installed by ansible-lint?

(ansiblelint) [josevnz@dmaf5 OracleCloudHomeLab]$ ansible --version
ansible [core 2.14.0]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/josevnz/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/josevnz/virtualenv/ansiblelint/lib64/python3.9/site-packages/ansible
  ansible collection location = /home/josevnz/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/josevnz/virtualenv/ansiblelint/bin/ansible
  python version = 3.9.9 (main, Nov 19 2021, 00:00:00) [GCC 10.3.1 20210422 (Red Hat 10.3.1-1)] (/home/josevnz/virtualenv/ansiblelint/bin/python3)
  jinja version = 3.1.2
  libyaml = True

Ansible-lint installed its own ansible [core], and firewalld is part of ansible.posix collection. We will use Ansible Galaxy to install it:

(ansiblelint) [josevnz@dmaf5 OracleCloudHomeLab]$ which ansible-galaxy
~/virtualenv/ansiblelint/bin/ansible-galaxy
(ansiblelint) [josevnz@dmaf5 OracleCloudHomeLab]$ ansible-galaxy collection install ansible.posix
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/download/ansible-posix-1.4.0.tar.gz to /home/josevnz/.ansible/tmp/ansible-local-18099xpw_8usc/tmp8msc9uf5/ansible-posix-1.4.0-_f17f525
Installing 'ansible.posix:1.4.0' to '/home/josevnz/.ansible/collections/ansible_collections/ansible/posix'
ansible.posix:1.4.0 was installed successfully

Running it again:

(ansiblelint) [josevnz@dmaf5 OracleCloudHomeLab]$ ansible-lint site.yaml 
WARNING  Overriding detected file kind 'yaml' with 'playbook' for given positional argument: site.yaml
WARNING  Listing 50 violation(s) that are fatal
name[play]: All plays should be named. (warning)
oracle.yaml:2

fqcn[action-core]: Use FQCN for builtin module actions (service).
roles/oracle/handlers/main.yaml:2 Use `ansible.builtin.service` or `ansible.legacy.service` instead.

fqcn[action-core]: Use FQCN for builtin module actions (command).
roles/oracle/handlers/main.yaml:6 Use `ansible.builtin.command` or `ansible.legacy.command` instead.

Some warnings are pedantic ('Use FQCN for builtin module actions (command)') and others require attention (Commands should not change things if nothing needs doing.).

Ansible-lint found many smells on the playbook, there is one option to re-write the files and correct some of these errors automatically:

There are some guidelines you can follow to correct these issues. Below are some that can be directly applied to the warnings we got earlier:

Note that all the errors are easy to solve. Some commands decide on their own if they should make changes or not but have a hard time communicating back to Ansible:

- name: Get SSL certificate
  ansible.builtin.shell:
    argv:
      - /opt/certbot/bin/certbot
      - --nginx
      - --agree-tos
      - -m "{{ ssl_maintainer_email }}"
      - -d "{{ inventory_hostname }}"
      - --non-interactive
  notify:
    - Restart Nginx
  tags: certbot_install

In our case, certboot prints a message if the certificate is not yet due for renewal. If that output is missing then we trigger the Nginx restart (see defining changed):

- name: Get SSL certificate
  ansible.builtin.shell:
    argv:
      - /opt/certbot/bin/certbot
      - --nginx
      - --agree-tos
      - -m {{ ssl_maintainer_email }}
      - -d {{ inventory_hostname }}
      - --non-interactive
  register: certbot_output # Registers the certbot output.
  changed_when: 
    - '"Certificate not yet due for renewal" not in certbot_output.stdout'
  notify:
    - Restart Nginx
  tags: certbot_install

I do want to use shell, as I need to expand the variable for certbot, but ansible-lint is still not happy:

(ansiblelint) [josevnz@dmaf5 OracleCloudHomeLab]$ ansible-lint site.yaml
WARNING  Overriding detected file kind 'yaml' with 'playbook' for given positional argument: site.yaml
WARNING  Listing 1 violation(s) that are fatal
command-instead-of-shell: Use shell only when shell functionality is required.
roles/oracle/tasks/nginx.yaml:47 Task/Handler: Get SSL certificate

You can skip specific rules or tags by adding them to your configuration file:
# .config/ansible-lint.yml
warn_list:  # or 'skip_list' to silence them completely
  - command-instead-of-shell  # Use shell only when shell functionality is required.

                   Rule Violation Summary                    
 count tag                      profile rule associated tags 
     1 command-instead-of-shell basic   command-shell, idiom 

Failed after min profile: 1 failure(s), 0 warning(s) on 8 files.

Time to treat this error as a warning, as I know they are not issues, by creating a .config/ansible-lint.yml:

(ansiblelint) [josevnz@dmaf5 OracleCloudHomeLab]$ ansible-lint site.yaml
WARNING  Overriding detected file kind 'yaml' with 'playbook' for given positional argument: site.yaml
WARNING  Listing 1 violation(s) that are fatal
command-instead-of-shell: Use shell only when shell functionality is required. (warning)
roles/oracle/tasks/nginx.yaml:47 Task/Handler: Get SSL certificate


                        Rule Violation Summary                         
 count tag                      profile rule associated tags           
     1 command-instead-of-shell basic   command-shell, idiom (warning) 

Passed with min profile: 0 failure(s), 1 warning(s) on 8 files.

Much better now, the warning is not treated as an error.

Jinja best practices

If you plan to use variables and Jinja templates, make sure you quote them (example: "dest: /opt/prometheus-{{ prometheus_version }}.linux-{{ architecture }}.tar.gz")

Constrain where the playbook runs with --limit and --tags

Say that you are only interested in running your playbook on a certain host. In that case, you can also do that by using the --limit flag:

ansible-playbook --inventory inventory --limit fido.yourcompany.com --tags certbot_renew site.yaml

Here we did run only a task tagged certbot_renew on the host fido.yourcompany.com.

How to deal with a real issue

Let's make this interesting: say that I was eager to update one of my requirements for certboot, and I changed versions if pip to '22.3.1':

pip==22.3.1
wheel==0.38.4
certbot==1.32.0
certbot-nginx==1.32.0

When I run the playbook we have a failure:

This is an issue with the versions if specified on the requirements_certboot.txt file. When you install a Python library using a virtual environment you can specify versions like this:

pip==22.3.1 wheel==0.38.1 certbot==1.23.0 certbot-nginx==1.23.0

To fix the issue, we will revert the versions used on the file and then re-run the requirements file and Certbot installation task:

- name: Setup Certbot
  pip:
    requirements: /opt/requirements_certboot.txt
    virtualenv: /opt/certbot/
    virtualenv_site_packages: true
    virtualenv_command: /usr/bin/python3 -m venv
    state: forcereinstall
  tags: certbot_env

ansible-playbook --inventory inventory --tags certbot_env site.yaml

See it in action:

How to run the whole playbook

ansible-playbook --inventory inventory site.yaml

It is time to run the whole playbook:

Wrapping up

This tutorial only touches the surface of what you can do with Ansible. So below are a few more resources you should explore to learn more:

• Improving inventories: How to create dynamic inventory files in Ansible, How to write a Python script to create dynamic Ansible inventories, How to write an Ansible plugin to create inventory files

• Sometimes your playbooks will run slow, and you may need to Assess resource consumption with Ansible callback plugins.

• And there will be a time when deeper debugging is needed.

In Linux, a mirror is a copy of programs available for download. If you are close (in networking terms, maybe or maybe not geographically) to one of the mirror sites listed, you might choose the mirror site as your main source of downloads so you get better response times.

Different Linux-based operating systems have different methods to help you choose the fastest mirrors. But most of the workarounds are pretty much the same.

I've used Manjaro for a pretty long time, and it's one of the most popular Linux-based operating systems out there. So I decided to write this article about it.

As many of us like to use the CLI (Command Line Interface) for downloading the necessary applications and packages in Linux-based operating systems, having a decent internet speed is very useful. Mirror repositories/servers help us with that.

Why Mirror Servers Are Useful

As Linux is getting more and more popular, there are a lot of servers getting created in various countries that keep the same data that is present in the official servers.

We call these mirror servers because those servers only mirror (copy) the original data from the original sources and keep those data in their servers. This helps users nearer to them get the data at a decent speed.

Also, these mirror servers/repositories lessen the pressure on the global international servers.

But keep in mind, all mirror servers might not have a decent reputation for containing malware/non-updated data and so on. The best practice before adding any mirror server is to search on Google/Reddit for that.

I always prefer the official community on Reddit as I can get legit information from their large user base.

If you simply search on Reddit, then you'll get countless subreddits for Linux users. Official forums and docs are also really helpful for this information.

By default, Linux Operating Systems comes with global server/repositories for downloading applications and packages, as they have customers from all over the globe. But if you want to switch to a specific server from where you can download the necessary packages at a decent speed, you can do that manually.

Mirror Server Use Case

If you are not super familiar with these mirror servers/repositories, let me also provide you with a real-case scenario.

Suppose, you want to download a file, and that file is hosted on multiple servers that are situated in different countries.

Let's say you are in Bangladesh, and you want to download an application. When you start downloading the application file, it starts downloading from the global international server located in the USA. Naturally, it will take longer to download from that server given the long distance, right?

But it might also be possible that the same application file is also hosted in India, a country near your country. If you download the application file from the Indian server instead, then it will definitely take less time.

That's because this server is nearer than the other one in the USA – so the distance the data has to travel is smaller. Thus, you can download and get your application file faster.

Now let's see how to enable a mirror server.

How to Enable the Fastest Mirror on Manjaro Linux

Start by simply opening your terminal. Then apply the following command:

sudo pacman-mirrors --country all --api --protocols all --set-branch stable && sudo pacman -Syyu

Enter the password and press the Enter key.

It'll take some time depending on your internet speed. Then it will automatically select the fastest mirror it can find for you.

After that, I would suggest that you reboot your PC / logout and log in to the session again.

That's it! If you want to know more about it, then the official wiki is also available for you here.

Conclusion

Thanks for reading the entire article. If it helps you then you can also check out other articles of mine at freeCodeCamp.

If you want to get in touch with me, then you can do so using Twitter, LinkedIn, and GitHub.

You can also SUBSCRIBE to my YouTube channel (Code With FahimFBA) if you want to learn various kinds of programming languages with a lot of practical examples regularly.

If you want to check out my highlights, then you can do so at my Polywork timeline.

You can also visit my website to learn more about me and what I'm working on.

Thanks a bunch!

The cover image has been taken from here.

If you run a troubleshooter for the issue, you'll get a message like the below:

In your Chrome browser, you might also get an error like the one below:

This is because the Domain Name System (DNS) server is crucial in getting an internet connection on your computer.

As far as websites are concerned, the “DNS server not responding” error could be caused by DNS gaps and a DDoS (Distributed Denial of Service) attack. If this is the problem, you might have to wait for 72 hours for domain gaps to be fixed or the website admins to fix the security issues with the website.

On the user’s end, the “DNS server not responding” error could be caused by numerous reasons such as misconfigured DNS settings and outdated browsers.

If this is the cause, I will show you 7 ways to fix the error so you can restore your internet connection.

Table of Contents

• How Does the DNS System Work?
• 7 Ways to Fix the DNS Server Not Responding Error
  • Solution 1: Switch Browsers
  • Solution 2: Temporarily Disable Your Antivirus
  • Solution 3: Restart your Router or Modem
  • Solution 4: Flush your DNS Cache
  • Solution 5: Manually Change your DNS Server
  • Solution 6: Update Your Network Adapter Driver
  • Solution 7: Disable IPv6
• Final Thoughts

  How Does the DNS System Work?

Whenever you try to access a website, like freeCodeCamp.org, you type in the URL like “freecodecamp.org” to the address bar and hit ENTER.

Under the hood, the DNS server looks up the numerical address for freeCodeCamp.org. This numerical address is called an Internet Protocol (IP) address.

Once the browser gets this IP address, the website (freeCodeCamp.org or any other) will be shown to you. If the browser fails to find this address, then you might get the “DNS server not responding” error.

7 Ways to Fix the DNS Server Not Responding Error

Now let's go through seven ways you can use to get rid of the “DNS server not responding” error so your internet connection can be restored.

Solution 1: Switch Browsers

The “DNS server not responding” error could be showing up because of the browser you’re currently using. Some browsers have their own DNS cache and if there’s an issue with the cache, your internet experience on that browser could be negatively affected.

So, a non-complicated fix is to change to a different browser and see if the error persists.

For example, if you are using Chrome, switch to Edge if you are on Windows or Safari if you are using Mac.

If the website loads up in another browser, then you might need to update your other browser or reinstall it.

Solution 2: Temporarily Disable Your Antivirus

Antivirus programs are notorious for interfering with applications and stopping them from working properly.

If you are getting the “DNS server not responding” error, consider disabling your antivirus program to see if your internet connection works fine.

If you are able to access the internet after disabling the antivirus, then it is the reason you’re getting the error.

In this case, you may want to consider getting another antivirus program.

If you are on Windows 10, you can disable Windows Security (AKA Windows Defender) by following the steps below: Step 1: Press ALT + SHIFT + ESC on your keyboard to open the Task Manager

Step 2: Switch to the Startup tab

Step 3: Locate your Antivirus Program in the list, right-click on it and select "Disable".

Solution 3: Restart your Router or Modem

If your internet connection relies on a router or modem, restarting it could help you get rid of the “DNS server not responding” error.

This is because turning off and then turning on a router or modem clears the cache of IP addresses. This could fix the error in the long run.

To restart your router or modem, locate the power button and long press to turn it off, then turn it on again.

Solution 4: Flush your DNS Cache

If the “DNS server not responding” error is due to misconfiguration on your device, flushing your DNS is one of the most reliable ways to fix it. This is because the process would remove invalid IP configurations and outdated information in the DNS cache.

To flush your computer’s DNS on Windows, follow the steps highlighted below:

Step 1: Hit the WIN button on your keyboard and search for "cmd". Then select "Run as Administrator" on the right.

Step 2: Enter and execute the following commands one after the other:

• ipconfig /flushdns
• ipconfig /release
• ipconfig /renew

Step 3: Restart your computer

Solution 5: Manually Change your DNS Server

Using the default DNS server of your internet service provider could be the reason you are getting the “DNS server not responding” error.

You can change your DNS server to one of the free ones provided by the likes of Google and Cloudflare.

The steps below show you how to change your DNS server to Google's:

Step 1: Right-click on Start and select “Network Connections”:

Step 2: Scroll down and select “Change adapter options”:

Step 3: In the pop-up that appears, right-click on the network you are connected to and select “Properties”:

Step 4: In the next pop-up that appears, double-click on “Internet Protocol Version 4 (TCP/IPv4)”:

Step 5: In the following pop-up that appears, click the radio button that says “Use the following DNS server addresses”:

Step 6: Enter 8.8.8.8 for “Preferred DNS server” and 8.8.4.4 for “Alternate DNS server”:

This is the free DNS server provided by Google.

Step 7: Click “Ok”, and “Ok” again.

N.B.: If your computer is configured to use IPv6 instead of IPv4, then in step 4, you should choose “Internet Protocol Version 6 (TCP/IPv6)” instead of “Internet Protocol Version 4 (TCP/IPv4)”.

Solution 6: Update Your Network Adapter Driver

Updating your network adapter driver can fix a lot of technical issues – including the “DNS server not responding” error, since the new driver could include bug fixes.

To update your network adapter driver, you can do it with the steps below:

Step 1: Click on Start and select Device Manager.

Step 2: Expand Network Adapters.

Step 3: Right-click on the affected driver and select Update driver:

Step 4: Choose Search automatically for updated driver software:

Step 5: Allow your computer to search for a driver online and install it for you. When it is done installing, restart your computer.

Solution 7: Disable IPv6

If your current network is configured to use IPv4 and IPv6 is turned on on your computer, it could lead to negative interference which could make you get the “DNS server not responding” error.

To disable IPv6, the following steps can help you:

Step 1: Right-click on Start and select “Network Connections”:

Step 2: Scroll down and select “Change adapter options”:

Step 3: In the pop-up that appears, right-click on the network you are connected to and select “Properties”:

Step 4: In the next pop-up that appears, uncheck “Internet Protocol Version 6 (TCP/IPv6)”:

Step 6: Click “Ok”, and “Ok” again.

Final Thoughts

The “DNS server not responding” error can be frustrating and disturb your internet experience. But in this article you've learned how to fix it if the error is caused by misconfiguration of DNS from the user’s end.

I hope one of the solutions to the error explained in this article helps you fix the error.

In this tutorial, we will learn how to create a server. We will begin without express and then strengthen the server using express. After that, we will see how to upload images to Cloudinary from the app we have created.

I assume that you already understand the basics of Node.js, express and nodemon so we will just go straight to the practical parts.

Install Node.js and NPM

If you haven't yet done so, you'll need to install Node and npm on your machine.

1. Go to the Node.js website
2. Click on the recommended download button

Nodejs home page

When the download is complete, install Node using the downloaded .exe file (it follows the normal installation process).

Check if the installation was successful

1. Go to your terminal/command prompt (run as administrator if possible)
2. Type in each of the following commands and hit Enter

node -v 
npm -v

Your output should be similar to the image below:

Terminal showing the versions of node and npm

The version may be different but that's OK.

How to Create a Node Server without Express

For the rest of this tutorial, I will be using VS code as my editor. You can use whatever editor you choose.

Let's start by creating a project directory. Open a terminal and type the following to create a directory and open it:

mkdir server-tutorial cd server-tutorial

I named my project directory server-tutorial, but you can name yours as you please.

In the terminal, type npm init. Hit the Enter button for all prompts. When completed, you should have a package.json file seated in your project directory.

The package.json file is just a file with all the details of your project. You don't have to open it.

Create a file called index.js.

In the file, require the HTTP module like so:

  const http = require('http');

Call the createServer() method on it and assign it to a constant like this:

  const server = http.createServer();

Call the listen() method on the server constant like this:

  server.listen();

Give it a port to listen to. Now this could be any free port, but we will be using port 3000 which is the conventional port. So we have this:

  const http = require('http');

  const server = http.createServer();

  server.listen(3000);

Basically, that is all you need do to create a server.

How to Test the Server

In your terminal (should be in the project directory), type node index.js and hit the Enter button.

Open a new tab in postman or any web browser and in the address bar, type http://localhost:3000/, and hit the Enter button. (I will be using postman because of its extended functionality outside the box.)

You will notice that your browser or postman keeps loading indefinitely like so:

Yay! That is fine. Our Server is up and running.

But it's boring already. We need to make the server talk to us.

Let's get to it immediately.

How to Send Back a Response from the Server

Back in the code, add the following to const server = http.createServer();:

 (request, response) => {
    response.end('Hey! This is your server response!');
 }

So we now have:

  const http = require('http');

  const server = http.createServer((request, response) => {
    response.end('Hey! This is your server response!');
  });

server.listen(3000);

In basic terms, the request object tells the server that we want something, the response object tells us what the server has to say about our request, and the end() method terminates the communication with the server response.

Hopefully, that makes sense!

Now, test the server again following the steps we outlined above and your server should be talking to you. This is my output:

Feel free to change the string as you wish.

Use Control/Command + C to terminate the server and run node index to start the server again.

Looking Sharp! Right? All good...

How to Create a Node Server With Express

In this section, we want to make our lives easier by using Express and Nodemon (node-mon or no-demon, pronounce it as you wish).

In the terminal, install the following:

npm install express --save 
npm install nodemon --save-dev

Create a new file named app.js or whatever suits you

In the file,

1. Require express like so:

const express = require('express');

2. Assign the express method to a constant like this:

const app = express();

3. Export the app constant to make it available for use in other files within the directory like so:

module.exports = app;

So we have:

const express = require('express');

const app = express();



module.exports = app;

In the index.js file, require the app we exported a while ago:

const app = require('./app');

Next, set the port using the app like so:

app.set('port', 3000);

And replace the code in the http.createServer() method with just app like this:

const server = http.createServer(app);

This directs all API management to the app.js file helping with separation of concerns.

So our index.js file now looks like this:

const http = require('http');
const app = require('./app');

app.set('port', 3000);
const server = http.createServer(app);

server.listen(3000);

Back in our app.js file, since we have directed all API management to it, let's create an endpoint to speak to us like before.

So before the module.exports = app, add the following code:

app.use((request, response) => {
   response.json({ message: 'Hey! This is your server response!' }); 
});

We now have:

const express = require('express');

const app = express();

app.use((request, response) => {
   response.json({ message: 'Hey! This is your server response!' }); 
});

module.exports = app;

Ahaaa... It's time to test our app.

To test our app, we now type nodemon index in our terminal and hit the Enter button. This is my terminal:

Do you notice that nodemon gives us details of execution in the terminal unlike Node? That's the beauty of nodemon.

You can now go to postman or any browser and in the address bar, type http://localhost:3000/ and hit Enter. See my output:

Walah! It's working.

Now more reasons to use nodemon. Go to the app.js file and change the message string to any string on your choice, save, and watch the terminal.

Wow... It automatically restarts the server. This was impossible with Node. We had to restart the server ourselves.

How to Secure the Server and Make it Future-Proof

In the index.js file, replace all the code with the following:

const http = require('http');
const app = require('./app');

const normalizePort = val => {
  const port = parseInt(val, 10);

  if (isNaN(port)) {
    return val;
  }
  if (port >= 0) {
    return port;
  }
  return false;
};
const port = normalizePort(process.env.PORT || '3000');
app.set('port', port);

const errorHandler = error => {
  if (error.syscall !== 'listen') {
    throw error;
  }
  const address = server.address();
  const bind = typeof address === 'string' ? 'pipe ' + address : 'port: ' + port;
  switch (error.code) {
    case 'EACCES':
      console.error(bind + ' requires elevated privileges.');
      process.exit(1);
      break;
    case 'EADDRINUSE':
      console.error(bind + ' is already in use.');
      process.exit(1);
      break;
    default:
      throw error;
  }
};

const server = http.createServer(app);

server.on('error', errorHandler);
server.on('listening', () => {
  const address = server.address();
  const bind = typeof address === 'string' ? 'pipe ' + address : 'port ' + port;
  console.log('Listening on ' + bind);
});

server.listen(port);

process.env.PORT makes the app dynamic so that it can run any port assigned to it in the future when hosted on a live server.

The normalizePort function returns a valid port, whether it is provided as a number or a string.

The errorHandler function checks for various errors and handles them appropriately — it is then registered to the server.

A listening event listener is also registered, logging the port or named pipe on which the server is running to the console.

YooH! Our server is more secure and robust right now. Notice that nodemon also displays the port we are listening on.

There you have it, a simple, secure and robust Node.js server.

How to Upload Images to Cloudinary

Now that we have a cool server running, let's learn how we can save our images on Cloudinary. This will just be a basic introduction so it should be fun 😊.

Cloudinary helps developers across the world manage images with minimal effort.

How to Create a Cloudinary Account

To create an account, go to the Cloudinary Website.

1. Click the sign up button on the top right.
2. Fill the form that shows up accordingly.
3. Submit the form using the Create Account button.
4. Check your email to finish up by validating your email

You should be able to access your dashboard which looks like mine below:

Notice the Account details. You shouldn't reveal this information to anyone. I am showing it to you here because this is a temporary account that I'm using only for the purposes of this tutorial.

Checkout the Media Library tab too. This is where the uploaded images will appear.

If you have all these showing, then let's rock and roll...

How to Install Cloudinary in Our Project

Open your terminal and navigate into the project directory.

Execute the following command to install Cloudinary:

  npm install cloudinary --save

How to Setup Cloudinary in Our Project

In the app.js file, require cloudinary below the const app = express(); like so:

  const cloudinary = require('cloudinary').v2

Next, add the configuration details from the account details on your dashboard like this:

    cloud_name: 'place your cloud_name here',
    api_key: 'place your api_key here',
    api_secret: 'place your api_secret here',

This is what I have:

  // cloudinary configuration
  cloudinary.config({
    cloud_name: "dunksyqjj",
    api_key: "173989938887513",
    api_secret: "ZPLqvCzRu55MaM1rt-wxJCmkxqU"
  });

How to Create an EndPoint to Upload an Image

To avoid bugs in our code, first replace the existing API with the following code:

  app.get("/", (request, response) => {
    response.json({ message: "Hey! This is your server response!" });
  });

It is basically the same but this time, we are using the get verb in place of the use verb and we added a root end-point (/).

Next, just before the module.exports = app; line, we will be creating our image-upload API.

Let's start by placing this code there:

// image upload API
app.post("/upload-image", (request, response) => {});

Basically, this is how we set up an API. The API makes a POST request to the server telling the server that the request should be handled with a degree of security. It uses two parameters to make this request: an end-point (/upload-image) and a callback function ((request, response) => {}).

Let's breathe life into the API by building out the callback function.

How to Build the Callback Function

Install body-parser

This npm package enables us to handle incoming requests using req.body or request.body as the case may be. We will be installing body-parser using the following code:

  npm install --save body-parser

Configure body-paser for our project

Require body-parse in the app.js like so:

const bodyParser = require('body-parser');

Next, add the following code to set its json function as global middleware for our app like so:

  app.use(bodyParser.json());
  app.use(bodyParser.urlencoded({ extended: true }));

We can now handle our request body appropriately.

Back to Building Our Function

In the function, add the following code to collect any data (images) entered by a user:

    // collected image from a user
    const data = {
        image: request.body.image,
    };

Next, upload the image to cloudinary using the following code:

cloudinary.uploader.upload(data.image);

Basically, this is all we need to upload our image. So our app.js looks like this:

const express = require("express");
const app = express();
const cloudinary = require("cloudinary").v2;
const bodyParser = require('body-parser');

// body parser configuration
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

// cloudinary configuration
cloudinary.config({
  cloud_name: "dunksyqjj",
  api_key: "173989938887513",
  api_secret: "ZPLqvCzRu55MaM1rt-wxJCmkxqU"
});

app.get("/", (request, response) => {
  response.json({ message: "Hey! This is your server response!" });
});

// image upload API
app.post("/image-upload", (request, response) => {
    // collected image from a user
    const data = {
      image: request.body.image,
    }

    // upload image here
    cloudinary.uploader.upload(data.image);

});

module.exports = app;

Now this looks good and it works perfectly. You can test it out using postman. But it's would be awesome if our app could give us feedback when it's done handling our requests, right?

To make this happen, we will add the following then...catch... block to the cloudinary upload like so:

    // upload image here
    cloudinary.uploader.upload(data.image)
    .then((result) => {
      response.status(200).send({
        message: "success",
        result,
      });
    }).catch((error) => {
      response.status(500).send({
        message: "failure",
        error,
      });
    });

So our final code will be:

const express = require("express");
const app = express();
const cloudinary = require("cloudinary").v2;
const bodyParser = require('body-parser');

// body parser configuration
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

// cloudinary configuration
cloudinary.config({
  cloud_name: "dunksyqjj",
  api_key: "173989938887513",
  api_secret: "ZPLqvCzRu55MaM1rt-wxJCmkxqU"
});

app.get("/", (request, response) => {
  response.json({ message: "Hey! This is your server response!" });
});

// image upload API
app.post("/image-upload", (request, response) => {
    // collected image from a user
    const data = {
      image: request.body.image,
    }

    // upload image here
    cloudinary.uploader.upload(data.image)
    .then((result) => {
      response.status(200).send({
        message: "success",
        result,
      });
    }).catch((error) => {
      response.status(500).send({
        message: "failure",
        error,
      });
    });

});

module.exports = app;

How to Test our API

Create a folder/directory in the root directory and name it images like so:

  mkdir images

Copy an image of your choice to this folder. (Now, the path to your image relative to the app.js file should look like this: "images/<your-image.jpg">.)

Now let's proceed to postman.

1. In the address bar, enter this: http://localhost:3000/image-upload
2. Set the Header Key to Content-Type and value to application/json
3. Set the body to the json data we declared in our code like so:

       {
       "image": "images/oskar-yildiz-gy08FXeM2L4-unsplash.jpg"
       }

Hit the Send button and wait for the upload to complete and get your response:

Now, this is the result. The image now has a unique public_id which is randomly generated by Cloudinary and a secure_url which is globally accessible (you can load it in your browser to see).

Finally, checking the Media Library tab on your Cloudinary dashboard, you should have a new image with a new badge on it. This will have a unique id that matches the public_id we saw in the postman result above just like in the image below:

Walah! We are persisting images without stress...That feels good.

Well, one more thing – SECURITY!

Our Cloudinary configuration details rea exposed in our app.js file. If we push our project to GitHub, it becomes publicly available to anyone who cares to check it out. And that becomes a problem if it gets into the wrong hands.

But don't worry about a thing here, there is a fix for almost everything in this space. We will be using the dotenv npm package to hid our configurations from the public.

How to Secure Our Configurations with dotenv

First, you'll need to install dotenv if you haven't already:

npm install dotenv --save

Then require dotenv in app.js like so:

  require('dotenv').config()

Create a new file in the root directory and name it .env.

In the file, enter your Cloudinary configuration details like so:

  CLOUD_NAME=dunksyqjj
  API_KEY=173989938887513
  API_SECRET=ZPLqvCzRu55MaM1rt-wxJCmkxqU

In the app.js file, we will access the configurations in the .env file via the process.env property like so:

// cloudinary configuration
cloudinary.config({
  cloud_name: process.env.CLOUD_NAME,
  api_key: process.env.API_KEY,
  api_secret: process.env.API_SECRET
});

This is my app.js code at the moment:

const express = require("express");
const app = express();
const cloudinary = require("cloudinary").v2;
const bodyParser = require('body-parser');
require('dotenv').config()

// body parser configuration
app.use(bodyParser.json());
  app.use(bodyParser.urlencoded({ extended: true }));

// cloudinary configuration
cloudinary.config({
  cloud_name: process.env.CLOUD_NAME,
  api_key: process.env.API_KEY,
  api_secret: process.env.API_SECRET
});

app.get("/", (request, response, next) => {
  response.json({ message: "Hey! This is your server response!" });
  next();
});

// image upload API
app.post("/image-upload", (request, response) => {
    // collected image from a user
    const data = {
      image: request.body.image,
    }

    // upload image here
    cloudinary.uploader.upload(data.image)
    .then((result) => {
      response.status(200).send({
        message: "success",
        result,
      });
    }).catch((error) => {
      response.status(500).send({
        message: "failure",
        error,
      });
    });
});

module.exports = app;

Let's test our app again to make sure that nothing is broken. Here is my result:

I now have two of the same image but with different public_ids.

And that is it!

Yeeeh! Our application is more secure than it was when we started.

Conclusion

In this tutorial, we went through the steps involved in creating a server using just Node.js. And after that, we improved our server using Express and nodemon.

Finally, we saw how to upload an image to Cloudinary through our Express application and how our configuration details are secured using the dotenv package.

This is just an introduction. You can do a whole lot more if you play around with this application.

You can find the server creation code here.

And the image upload codes are available here.

Thank you for your time. 😊

And if you use Linux, you're in luck – it comes with an excellent feature called SE Linux that helps you add an additional layer of security.

What is SE Linux?

SE Linux was developed by the NSA (National Security Agency) to serve government-related security tasks.

SE Linux stands for Security Enhanced Linux. It gives system administrators more control for providing access to files and processes. With SE Linux, admins can define a context and tag files and permit them within that context.

Access and permissions are usually inherited based on user groups. But there are some sources (like web servers and processes) that need access to network ports and kernel processes. These are usually spawned by the root user or users with special access. SE Linux helps you limit who can access these special processes.

How to work with SE Linux

SE Linux comes by default in most Linux distros. In this post, I will be working on Fedora.

Just keep in mind that working with SE Linux requires sudo or root access.

The SE Linux configuration file is located in the /etc/sysconfig/selinux folder. Let's view its contents:

SE Linux Modes

SE Linux config file

In the config file, we can change the modes and choose any one from the below:

1. Enforced – Enabled by default, filters based on defined policies.
2. Permissive – Does not enforce the defined policies, but records all of the attempts in log files. This mode is useful for troubleshooting.
3. Disabled – SE Linux is completely disabled. This is not recommended as it might expose your system to threats. Also, reverting back to enforced could create certain discrepancies.

You can check your current SE Linux mode with the below commands:

1. getenforce
2. sestatus

If you only need to change the mode for the current session, you can use the below commands:

1. sudo setenforce 0 – sets permissive mode for current session
2. sudo setenforce 1 – sets enforcing mode for current session

SE Linux Policies

In SE Linux, policies define access to users. Users define access to roles and roles define access to domains. Domains then provide access to certain files.

SE Linux Policies

To change and modify accesses, 'booleans' are defined. We'll look into booleans in the next section.

How to manage SE Linux policies with booleans

As you now know, SE Linux policies are managed by booleans.

Let's see a working example of how you'd view and set a boolean. In this example, we will set booleans specific to httpd.

First, list all modules specific to http – getsebool -a | grep httpd.

Here -a lists all booleans.

List of Booleans

Next, let's select and change the yellow highlighted boolean in the code above:

getsebool httpd_can_connect_ftp

Now, set the value to allow.

setsebool -P httpd_can_connect_ftp 1

In the command above,

• The flag P is used to make the change permanent even after reboot.
• 1 is enabling the boolean.

Now, when you list the process again, its value will be allowed.

Boolean 'on'

SE Linux Architecture

The diagram below explains how SE Linux validates an attempt from source:

Troubleshooting and SE Linux Logs

SE Linux produces very detailed logs for each attempt. You can find the logs and view them here: /var/log/audit.

While troubleshooting, you should move into 'permissive' mode so all events can be recorded in the logs. Although policies are not being enforced, attempts are being recorded in logs.

How to disable and enable SE Linux

Disabling SE Linux completely is never a good option. But there are certain scenarios where policies can be by-passed such as when troubleshooting.

Instead of disabling SE Linux if you run into a small issued, it is better to invest some time in troubleshooting.

But if you really need to disable SE Linux, follow these steps:

1. Change the mode from 'enforcing' to 'permissive'.
2. Change mode from 'permissive' to 'disabled'.

Wrapping up

Learning SE Linux is worth your time and there are endless possibilities you can explore when using it.

SE Linux provides admins with a fine-grained level of control. So why not learn it and leverage it to increase your security?

Thanks for reading until the end. Let's connect on Twitter.

NGINX was first released to the public in 2004 under the terms of the 2-clause BSD license. According to the March 2021 Web Server Survey, NGINX holds 35.3% of the market with a total of 419.6 million sites.

Thanks to tools like NGINXConfig by DigitalOcean and an abundance of pre-written configuration files on the internet, people tend to do a lot of copy-pasting instead of trying to understand when it comes to configuring NGINX.

Trust me, it's not that hard...

I'm not saying that copying code is bad, but copying code without understanding is a big "no no".

Also NGINX is the kind of software that should be configured exactly according to the requirements of the application to be served and available resources on the host.

That's why instead of copying blindly, you should understand and then fine tune what you're copying – and that's where this handbook comes in.

After going through the entire book, you should be able to:

• Understand configuration files generated by popular tools as well as those found in various documentation.
• Configure NGINX as a web server, a reverse proxy server, and a load balancer from scratch.
• Optimize NGINX to get maximum performance out of your server.

Prerequisites

• Familiarity with the Linux terminal and common Unix programs such as ls, cat, ps, grep, find, nproc, ulimit and nano.
• A computer powerful enough to run a virtual machine or a $5 virtual private server.
• Understanding of web applications and a programming language such as JavaScript or PHP.

Table of Contents

• Introduction to NGINX
• How to Install NGINX
  • How to Provision a Local Virtual Machine
  • How to Provision a Virtual Private Server
  • How to Install NGINX on a Provisioned Server or Virtual Machine
• Introduction to NGINX's Configuration Files
• How to Configure a Basic Web Server
  • How to Write Your First Configuration File
  • How to Validate and Reload Configuration Files
  • How to Understand Directives and Contexts in NGINX
  • How to Serve Static Content Using NGINX
  • Static File Type Handling in NGINX
  • How to Include Partial Config Files
• Dynamic Routing in NGINX
  • Location Matches
  • Variables in NGINX
  • Redirects and Rewrites
  • How to Try for Multiple Files
• Logging in NGINX
• How to Use NGINX as a Reverse Proxy
  • Node.js With NGINX
  • PHP With NGINX
• How to Use NGINX as a Load Balancer
• How To Optimize NGINX for Maximum Performance
  • How to Configure Worker Processes and Worker Connections
  • How to Cache Static Content
  • How to Compress Responses
• How to Understand the Main Configuration File
• How To Configure SSL and HTTP/2
  • How To Configure SSL
  • How to Enable HTTP/2
  • How to Enable Server Push
• Conclusion

Project Code

You can find the code for the example projects in the following repository:

Introduction to NGINX

NGINX is a high performance web server developed to facilitate the increasing needs of the modern web. It focuses on high performance, high concurrency, and low resource usage. Although it's mostly known as a web server, NGINX at its core is a reverse proxy server.

NGINX is not the only web server on the market, though. One of its biggest competitors is Apache HTTP Server (httpd), first released back on 1995. In spite of the fact that Apache HTTP Server is more flexible, server admins often prefer NGINX for two main reasons:

• It can handle a higher number of concurrent requests.
• It has faster static content delivery with low resource usage.

I won't go further into the whole Apache vs NGINX debate. But if you wish to learn more about the differences between them in detail, this excellent article from Justin Ellingwood may help.

In fact, to explain NGINX's request handling technique, I would like to quote two paragraphs from Justin's article here:

Nginx came onto the scene after Apache, with more awareness of the concurrency problems that would face sites at scale. Leveraging this knowledge, Nginx was designed from the ground up to use an asynchronous, non-blocking, event-driven connection handling algorithm.

Nginx spawns worker processes, each of which can handle thousands of connections. The worker processes accomplish this by implementing a fast looping mechanism that continuously checks for and processes events. Decoupling actual work from connections allows each worker to concern itself with a connection only when a new event has been triggered.

If that seems a bit complicated to understand, don't worry. Having a basic understanding of the inner workings will suffice for now.

NGINX is faster in static content delivery while staying relatively lighter on resources because it doesn't embed a dynamic programming language processor. When a request for static content comes, NGINX simply responds with the file without running any additional processes.

That doesn't mean that NGINX can't handle requests that require a dynamic programming language processor. In such cases, NGINX simply delegates the tasks to separate processes such as PHP-FPM, Node.js or Python. Then, once that process finishes its work, NGINX reverse proxies the response back to the client.

NGINX is also a lot easier to configure thanks to a configuration file syntax inspired from various scripting languages that results in compact, easily maintainable configuration files.

How to Install NGINX

Installing NGINX on a Linux-based system is pretty straightforward. You can either use a virtual private server running Ubuntu as your playground, or you can provision a virtual machine on your local system using Vagrant.

For the most part, provisioning a local virtual machine will suffice and that's the way I'll be using in this article.

How to Provision a Local Virtual Machine

For those who doesn't know, Vagrant is an open-source tool by Hashicorp that allows you to provision virtual machines using simple configuration files.

For this approach to work, you'll need VirtualBox and Vagrant, so go ahead and install them first. If you need a little warm up on the topic, this tutorial may help.

Create a working directory somewhere in your system with a sensible name. Mine is ~/vagrant/nginx-handbook directory.

Inside the working directory create a file named Vagrantfile and put following content in there:

Vagrant.configure("2") do |config|

    config.vm.hostname = "nginx-handbook-box"

    config.vm.box = "ubuntu/focal64"

    config.vm.define "nginx-handbook-box"

    config.vm.network "private_network", ip: "192.168.20.20"

    config.vm.provider "virtualbox" do |vb|
      vb.cpus = 1
      vb.memory = "1024"
      vb.name = "nginx-handbook"
    end

  end

This Vagrantfile is the configuration file I talked about earlier. It contains information like name of the virtual machine, number of CPUs, size of RAM, the IP address, and more.

To start a virtual machine using this configuration, open your terminal inside the working directory and execute the following command:

vagrant up

# Bringing machine 'nginx-handbook-box' up with 'virtualbox' provider...
# ==> nginx-handbook-box: Importing base box 'ubuntu/focal64'...
# ==> nginx-handbook-box: Matching MAC address for NAT networking...
# ==> nginx-handbook-box: Checking if box 'ubuntu/focal64' version '20210415.0.0' is up to date...
# ==> nginx-handbook-box: Setting the name of the VM: nginx-handbook
# ==> nginx-handbook-box: Clearing any previously set network interfaces...
# ==> nginx-handbook-box: Preparing network interfaces based on configuration...
#     nginx-handbook-box: Adapter 1: nat
#     nginx-handbook-box: Adapter 2: hostonly
# ==> nginx-handbook-box: Forwarding ports...
#     nginx-handbook-box: 22 (guest) => 2222 (host) (adapter 1)
# ==> nginx-handbook-box: Running 'pre-boot' VM customizations...
# ==> nginx-handbook-box: Booting VM...
# ==> nginx-handbook-box: Waiting for machine to boot. This may take a few minutes...
#     nginx-handbook-box: SSH address: 127.0.0.1:2222
#     nginx-handbook-box: SSH username: vagrant
#     nginx-handbook-box: SSH auth method: private key
#     nginx-handbook-box: Warning: Remote connection disconnect. Retrying...
#     nginx-handbook-box: Warning: Connection reset. Retrying...
#     nginx-handbook-box: 
#     nginx-handbook-box: Vagrant insecure key detected. Vagrant will automatically replace
#     nginx-handbook-box: this with a newly generated keypair for better security.
#     nginx-handbook-box: 
#     nginx-handbook-box: Inserting generated public key within guest...
#     nginx-handbook-box: Removing insecure key from the guest if it's present...
#     nginx-handbook-box: Key inserted! Disconnecting and reconnecting using new SSH key...
# ==> nginx-handbook-box: Machine booted and ready!
# ==> nginx-handbook-box: Checking for guest additions in VM...
# ==> nginx-handbook-box: Setting hostname...
# ==> nginx-handbook-box: Configuring and enabling network interfaces...
# ==> nginx-handbook-box: Mounting shared folders...
#     nginx-handbook-box: /vagrant => /home/fhsinchy/vagrant/nginx-handbook

vagrant status

# Current machine states:

# nginx-handbook-box           running (virtualbox)

The output of the vagrant up command may differ on your system, but as long as vagrant status says the machine is running, you're good to go.

Given that the virtual machine is now running, you should be able to SSH into it. To do so, execute the following command:

vagrant ssh nginx-handbook-box

# Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-72-generic x86_64)
# vagrant@nginx-handbook-box:~$

If everything's done correctly you should be logged into your virtual machine, which will be evident by the vagrant@nginx-handbook-box line on your terminal.

This virtual machine will be accessible on http://192.168.20.20 on your local machine. You can even assign a custom domain like http://nginx-handbook.test to the virtual machine by adding an entry to your hosts file:

# on mac and linux terminal
sudo nano /etc/hosts

# on windows command prompt as administrator
notepad c:\windows\system32\drivers\etc\hosts

Now append the following line at the end of the file:

192.168.20.20   nginx-handbook.test

Now you should be able to access the virtual machine on http://nginx-handbook.test URI in your browser.

You can stop or destroy the virtual machine by executing the following commands inside the working directory:

# to stop the virtual machine
vagrant halt

# to destroy the virtual machine
vagrant destroy

If you want to learn about more Vagrant commands, this cheat sheet may come in handy.

Now that you have a functioning Ubuntu virtual machine on your system, all that is left to do is install NGINX.

How to Provision a Virtual Private Server

For this demonstration, I'll use Vultr as my provider but you may use DigitalOcean or whatever provider you like.

Assuming you already have an account with your provider, log into the account and deploy a new server:

On DigitalOcean, it's usually called a droplet. On the next screen, choose a location close to you. I live in Bangladesh which is why I've chosen Singapore:

On the next step, you'll have to choose the operating system and server size. Choose Ubuntu 20.04 and the smallest possible server size:

Although production servers tend to be much bigger and more powerful than this, a tiny server will be more than enough for this article.

Finally, for the last step, put something fitting like nginx-hadnbook-demo-server as the server host and label. You can even leave them empty if you want.

Once you're happy with your choices, go ahead and press the Deploy Now button.

The deployment process may take some time to finish, but once it's done, you'll see the newly created server on your dashboard:

Also pay attention to the Status – it should say Running and not Preparing or Stopped. To connect to the server, you'll need a username and password.

Go into the overview page for your server and there you should see the server's IP address, username, and password:

The generic command for logging into a server using SSH is as follows:

ssh <username>@<ip address>

So in the case of my server, it'll be:

ssh root@45.77.251.108

# Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
# Warning: Permanently added '45.77.251.108' (ECDSA) to the list of known hosts.

# root@45.77.251.108's password: 
# Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-65-generic x86_64)

# root@localhost:~#

You'll be asked if you want to continue connecting to this server or not. Answer with yes and then you'll be asked for the password. Copy the password from the server overview page and paste that into your terminal.

If you do everything correctly you should be logged into your server – you'll see the root@localhost line on your terminal. Here localhost is the server host name, and may differ in your case.

You can access this server directly by its IP address. Or if you own any custom domain, you can use that also.

Throughout the article you'll see me adding test domains to my operating system's hosts file. In case of a real server, you'll have to configure those servers using your DNS provider.

Remember that you'll be charged as long as this server is being used. Although the charge should be very small, I'm warning you anyways. You can destroy the server anytime you want by hitting the trash icon on the server overview page:

If you own a custom domain name, you may assign a sub-domain to this server. Now that you're inside the server, all that is left to is install NGINX.

How to Install NGINX on a Provisioned Server or Virtual Machine

Assuming you're logged into your server or virtual machine, the first thing you should do is performing an update. Execute the following command to do so:

sudo apt update && sudo apt upgrade -y

After the update, install NGINX by executing the following command:

sudo apt install nginx -y

Once the installation is done, NGINX should be automatically registered as a systemd service and should be running. To check, execute the following command:

sudo systemctl status nginx

# ● nginx.service - A high performance web server and a reverse proxy server
#      Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
#      Active: active (running)

If the status says running, then you're good to go. Otherwise you may start the service by executing this command:

sudo systemctl start nginx

Finally for a visual verification that everything is working properly, visit your server/virtual machine with your favorite browser and you should see NGINX's default welcome page:

NGINX is usually installed on the /etc/nginx directory and the majority of our work in the upcoming sections will be done in here.

Congratulations! Bow you have NGINX up and running on your server/virtual machine. Now it's time to jump head first into NGINX.

Introduction to NGINX's Configuration Files

As a web server, NGINX's job is to serve static or dynamic contents to the clients. But how that content are going to be served is usually controlled by configuration files.

NGINX's configuration files end with the .conf extension and usually live inside the /etc/nginx/ directory. Let's begin by cding into this directory and getting a list of all the files:

cd /etc/nginx

ls -lh

# drwxr-xr-x 2 root root 4.0K Apr 21  2020 conf.d
# -rw-r--r-- 1 root root 1.1K Feb  4  2019 fastcgi.conf
# -rw-r--r-- 1 root root 1007 Feb  4  2019 fastcgi_params
# -rw-r--r-- 1 root root 2.8K Feb  4  2019 koi-utf
# -rw-r--r-- 1 root root 2.2K Feb  4  2019 koi-win
# -rw-r--r-- 1 root root 3.9K Feb  4  2019 mime.types
# drwxr-xr-x 2 root root 4.0K Apr 21  2020 modules-available
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 modules-enabled
# -rw-r--r-- 1 root root 1.5K Feb  4  2019 nginx.conf
# -rw-r--r-- 1 root root  180 Feb  4  2019 proxy_params
# -rw-r--r-- 1 root root  636 Feb  4  2019 scgi_params
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 sites-available
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 sites-enabled
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 snippets
# -rw-r--r-- 1 root root  664 Feb  4  2019 uwsgi_params
# -rw-r--r-- 1 root root 3.0K Feb  4  2019 win-utf

Among these files, there should be one named nginx.conf. This is the the main configuration file for NGINX. You can have a look at the content of this file using the cat program:

cat nginx.conf

# user www-data;
# worker_processes auto;
# pid /run/nginx.pid;
# include /etc/nginx/modules-enabled/*.conf;

# events {
#     worker_connections 768;
#     # multi_accept on;
# }

# http {

#     ##
#     # Basic Settings
#     ##

#     sendfile on;
#     tcp_nopush on;
#     tcp_nodelay on;
#     keepalive_timeout 65;
#     types_hash_max_size 2048;
#     # server_tokens off;

#     # server_names_hash_bucket_size 64;
#     # server_name_in_redirect off;

#     include /etc/nginx/mime.types;
#     default_type application/octet-stream;

#     ##
#     # SSL Settings
#     ##

#     ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
#     ssl_prefer_server_ciphers on;

#     ##
#     # Logging Settings
#     ##

#     access_log /var/log/nginx/access.log;
#     error_log /var/log/nginx/error.log;

#     ##
#     # Gzip Settings
#     ##

#     gzip on;

#     # gzip_vary on;
#     # gzip_proxied any;
#     # gzip_comp_level 6;
#     # gzip_buffers 16 8k;
#     # gzip_http_version 1.1;
#     # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

#     ##
#     # Virtual Host Configs
#     ##

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


# #mail {
# #    # See sample authentication script at:
# #    # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
# # 
# #    # auth_http localhost/auth.php;
# #    # pop3_capabilities "TOP" "USER";
# #    # imap_capabilities "IMAP4rev1" "UIDPLUS";
# # 
# #    server {
# #        listen     localhost:110;
# #        protocol   pop3;
# #        proxy      on;
# #    }
# # 
# #    server {
# #        listen     localhost:143;
# #        protocol   imap;
# #        proxy      on;
# #    }
# #}

Whoa! That's a lot of stuff. Trying to understand this file at its current state will be a nightmare. So let's rename the file and create a new empty one:

# renames the file
sudo mv nginx.conf nginx.conf.backup

# creates a new file
sudo touch nginx.conf

I highly discourage you from editing the original nginx.conf file unless you absolutely know what you're doing. For learning purposes, you may rename it, but later on, I'll show you how you should go about configuring a server in a real life scenario.

How to Configure a Basic Web Server

In this section of the book, you'll finally get your hands dirty by configuring a basic static web server from the ground up. The goal of this section is to introduce you to the syntax and fundamental concepts of NGINX configuration files.

How to Write Your First Configuration File

Start by opening the newly created nginx.conf file using the nano text editor:

sudo nano /etc/nginx/nginx.conf

Throughout the book, I'll be using nano as my text editor. You may use something more modern if you want to, but in a real life scenario, you're most likely to work using nano or vim on servers instead of anything else. So use this book as an opportunity to sharpen your nano skills. Also the official cheat sheet is there for you to consult whenever you need.

After opening the file, update its content to look like this:

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        return 200 "Bonjour, mon ami!\n";
    }

}

If you have experience building REST APIs then you may guess from the return 200 "Bonjour, mon ami!\n"; line that the server has been configured to respond with a status code of 200 and the message "Bonjour, mon ami!".

Don't worry if you don't understand anything more than that at the moment. I'll explain this file line by line, but first let's see this configuration in action.

How to Validate and Reload Configuration Files

After writing a new configuration file or updating an old one, the first thing to do is check the file for any syntax mistakes. The nginx binary includes an option -t to do just that.

sudo nginx -t

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

If you have any syntax errors, this command will let you know about them, including the line number.

Although the configuration file is fine, NGINX will not use it. The way NGINX works is it reads the configuration file once and keeps working based on that.

If you update the configuration file, then you'll have to instruct NGINX explicitly to reload the configuration file. There are two ways to do that.

• You can restart the NGINX service by executing the sudo systemctl restart nginx command.
• You can dispatch a reload signal to NGINX by executing the sudo nginx -s reload command.

The -s option is used for dispatching various signals to NGINX. The available signals are stop, quit, reload and reopen. Among the two ways I just mentioned, I prefer the second one simply because it's less typing.

Once you've reloaded the configuration file by executing the nginx -s reload command, you can see it in action by sending a simple get request to the server:

curl -i http://nginx-handbook.test

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 10:03:33 GMT
# Content-Type: text/plain
# Content-Length: 18
# Connection: keep-alive

# Bonjour, mon ami!

The server is responding with a status code of 200 and the expected message. Congratulations on getting this far! Now it's time for some explanation.

How to Understand Directives and Contexts in NGINX

The few lines of code you've written here, although seemingly simple, introduce two of the most important terminologies of NGINX configuration files. They are directives and contexts.

Technically, everything inside a NGINX configuration file is a directive. Directives are of two types:

• Simple Directives
• Block Directives

A simple directive consists of the directive name and the space delimited parameters, like listen, return and others. Simple directives are terminated by semicolons.

Block directives are similar to simple directives, except that instead of ending with semicolons, they end with a pair of curly braces { } enclosing additional instructions.

A block directive capable of containing other directives inside it is called a context, that is events, http and so on. There are four core contexts in NGINX:

• events { } – The events context is used for setting global configuration regarding how NGINX is going to handle requests on a general level. There can be only one events context in a valid configuration file.
• http { } – Evident by the name, http context is used for defining configuration regarding how the server is going to handle HTTP and HTTPS requests, specifically. There can be only one http context in a valid configuration file.
• server { } – The server context is nested inside the http context and used for configuring specific virtual servers within a single host. There can be multiple server contexts in a valid configuration file nested inside the http context. Each server context is considered a virtual host.
• main – The main context is the configuration file itself. Anything written outside of the three previously mentioned contexts is on the main context.

You can treat contexts in NGINX like scopes in other programming languages. There is also a sense of inheritance among them. You can find an alphabetical index of directives on the official NGINX docs.

I've already mentioned that there can be multiple server contexts within a configuration file. But when a request reaches the server, how does NGINX know which one of those contexts should handle the request?

The listen directive is one of the ways to identify the correct server context within a configuration. Consider the following scenario:

http {
    server {
        listen 80;
        server_name nginx-handbook.test;

        return 200 "hello from port 80!\n";
    }


    server {
        listen 8080;
        server_name nginx-handbook.test;

        return 200 "hello from port 8080!\n";
    }
}

Now if you send a request to http://nginx-handbook.test:80 then you'll receive "hello from port 80!" as a response. And if you send a request to http://nginx-handbook.test:8080, you'll receive "hello from port 8080!" as a response:

curl nginx-handbook.test:80

# hello from port 80!

curl nginx-handbook.test:8080

# hello from port 8080!

These two server blocks are like two people holding telephone receivers, waiting to respond when a request reaches one of their numbers. Their numbers are indicated by the listen directives.

Apart from the listen directive, there is also the server_name directive. Consider the following scenario of an imaginary library management application:

http {
    server {
        listen 80;
        server_name library.test;

        return 200 "your local library!\n";
    }


    server {
        listen 80;
        server_name librarian.library.test;

        return 200 "welcome dear librarian!\n";
    }
}

This is a basic example of the idea of virtual hosts. You're running two separate applications under different server names in the same server.

If you send a request to http://library.test then you'll get "your local library!" as a response. If you send a request to http://librarian.library.test, you'll get "welcome dear librarian!" as a response.

curl http://library.test

# your local library!

curl http://librarian.library.test

# welcome dear librarian!

To make this demo work on your system, you'll have to update your hosts file to include these two domain names as well:

192.168.20.20   library.test
192.168.20.20   librarian.library.test

Finally, the return directive is responsible for returning a valid response to the user. This directive takes two parameters: the status code and the string message to be returned.

How to Serve Static Content Using NGINX

Now that you have a good understanding of how to write a basic configuration file for NGINX, let's upgrade the configuration to serve static files instead of plain text responses.

In order to serve static content, you first have to store them somewhere on your server. If you list the files and directory on the root of your server using ls, you'll find a directory called /srv in there:

ls -lh /

# lrwxrwxrwx   1 root    root       7 Apr 16 02:10 bin -> usr/bin
# drwxr-xr-x   3 root    root    4.0K Apr 16 02:13 boot
# drwxr-xr-x  16 root    root    3.8K Apr 21 09:23 dev
# drwxr-xr-x  92 root    root    4.0K Apr 21 09:24 etc
# drwxr-xr-x   4 root    root    4.0K Apr 21 08:04 home
# lrwxrwxrwx   1 root    root       7 Apr 16 02:10 lib -> usr/lib
# lrwxrwxrwx   1 root    root       9 Apr 16 02:10 lib32 -> usr/lib32
# lrwxrwxrwx   1 root    root       9 Apr 16 02:10 lib64 -> usr/lib64
# lrwxrwxrwx   1 root    root      10 Apr 16 02:10 libx32 -> usr/libx32
# drwx------   2 root    root     16K Apr 16 02:15 lost+found
# drwxr-xr-x   2 root    root    4.0K Apr 16 02:10 media
# drwxr-xr-x   2 root    root    4.0K Apr 16 02:10 mnt
# drwxr-xr-x   2 root    root    4.0K Apr 16 02:10 opt
# dr-xr-xr-x 152 root    root       0 Apr 21 09:23 proc
# drwx------   5 root    root    4.0K Apr 21 09:59 root
# drwxr-xr-x  26 root    root     820 Apr 21 09:47 run
# lrwxrwxrwx   1 root    root       8 Apr 16 02:10 sbin -> usr/sbin
# drwxr-xr-x   6 root    root    4.0K Apr 16 02:14 snap
# drwxr-xr-x   2 root    root    4.0K Apr 16 02:10 srv
# dr-xr-xr-x  13 root    root       0 Apr 21 09:23 sys
# drwxrwxrwt  11 root    root    4.0K Apr 21 09:24 tmp
# drwxr-xr-x  15 root    root    4.0K Apr 16 02:12 usr
# drwxr-xr-x   1 vagrant vagrant   38 Apr 21 09:23 vagrant
# drwxr-xr-x  14 root    root    4.0K Apr 21 08:34 var

This /srv directory is meant to contain site-specific data which is served by this system. Now cd into this directory and clone the code repository that comes with this book:

cd /srv

sudo git clone https://github.com/fhsinchy/nginx-handbook-projects.git

Inside the nginx-handbook-projects directory there should a directory called static-demo containing four files in total:

ls -lh /srv/nginx-handbook-projects/static-demo

# -rw-r--r-- 1 root root 960 Apr 21 11:27 about.html
# -rw-r--r-- 1 root root 960 Apr 21 11:27 index.html
# -rw-r--r-- 1 root root 46K Apr 21 11:27 mini.min.css
# -rw-r--r-- 1 root root 19K Apr 21 11:27 the-nginx-handbook.jpg

Now that you have the static content to be served, update your configuration as follows:

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;
    }

}

The code is almost the same, except the return directive has now been replaced by a root directive. This directive is used for declaring the root directory for a site.

By writing root /srv/nginx-handbook-projects/static-demo you're telling NGINX to look for files to serve inside the /srv/nginx-handbook-projects/static-demo directory if any request comes to this server. Since NGINX is a web server, it is smart enough to serve the index.html file by default.

Let's see if this works or not. Test and reload the updated configuration file and visit the server. You should be greeted with a somewhat broken HTML site:

Although NGINX has served the index.html file correctly, judging by the look of the three navigation links, it seems like the CSS code is not working.

You may think that there is something wrong in the CSS file. But in reality, the problem is in the configuration file.

Static File Type Handling in NGINX

To debug the issue you're facing right now, send a request for the CSS file to the server:

curl -I http://nginx-handbook/mini.min.css

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 12:17:16 GMT
# Content-Type: text/plain
# Content-Length: 46887
# Last-Modified: Wed, 21 Apr 2021 11:27:06 GMT
# Connection: keep-alive
# ETag: "60800c0a-b727"
# Accept-Ranges: bytes

Pay attention to the Content-Type and see how it says text/plain and not text/css. This means that NGINX is serving this file as plain text instead of as a stylesheet.

Although NGINX is smart enough to find the index.html file by default, it's pretty dumb when it comes to interpreting file types. To solve this problem update your configuration once again:

events {

}

http {

    types {
        text/html html;
        text/css css;
    }

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;
    }
}

The only change we've made to the code is a new types context nested inside the http block. As you may have already guessed from the name, this context is used for configuring file types.

By writing text/html html in this context you're telling NGINX to parse any file as text/html that ends with the html extension.

You may think that configuring the CSS file type should suffice as the HTML is being parsed just fine – but no.

If you introduce a types context in the configuration, NGINX becomes even dumber and only parses the files configured by you. So if you only define the text/css css in this context then NGINX will start parsing the HTML file as plain text.

Validate and reload the newly updated config file and visit the server once again. Send a request for the CSS file once again, and this time the file should be parsed as a text/css file:

curl -I http://nginx-handbook.test/mini.min.css

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 12:29:35 GMT
# Content-Type: text/css
# Content-Length: 46887
# Last-Modified: Wed, 21 Apr 2021 11:27:06 GMT
# Connection: keep-alive
# ETag: "60800c0a-b727"
# Accept-Ranges: bytes

Visit the server for a visual verification, and the site should look better this time:

If you've updated and reloaded the configuration file correctly and you're still seeing the old site, perform a hard refresh.

How to Include Partial Config Files

Mapping file types within the types context may work for small projects, but for bigger projects it can be cumbersome and error-prone.

NGINX provides a solution for this problem. If you list the files inside the /etc/nginx directory once again, you'll see a file named mime.types.

ls -lh /etc/nginx

# drwxr-xr-x 2 root root 4.0K Apr 21  2020 conf.d
# -rw-r--r-- 1 root root 1.1K Feb  4  2019 fastcgi.conf
# -rw-r--r-- 1 root root 1007 Feb  4  2019 fastcgi_params
# -rw-r--r-- 1 root root 2.8K Feb  4  2019 koi-utf
# -rw-r--r-- 1 root root 2.2K Feb  4  2019 koi-win
# -rw-r--r-- 1 root root 3.9K Feb  4  2019 mime.types
# drwxr-xr-x 2 root root 4.0K Apr 21  2020 modules-available
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 modules-enabled
# -rw-r--r-- 1 root root 1.5K Feb  4  2019 nginx.conf
# -rw-r--r-- 1 root root  180 Feb  4  2019 proxy_params
# -rw-r--r-- 1 root root  636 Feb  4  2019 scgi_params
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 sites-available
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 sites-enabled
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 snippets
# -rw-r--r-- 1 root root  664 Feb  4  2019 uwsgi_params
# -rw-r--r-- 1 root root 3.0K Feb  4  2019 win-utf

Let's have a look at the content of this file:

cat /etc/mime.types

# types {
#     text/html                             html htm shtml;
#     text/css                              css;
#     text/xml                              xml;
#     image/gif                             gif;
#     image/jpeg                            jpeg jpg;
#     application/javascript                js;
#     application/atom+xml                  atom;
#     application/rss+xml                   rss;

#     text/mathml                           mml;
#     text/plain                            txt;
#     text/vnd.sun.j2me.app-descriptor      jad;
#     text/vnd.wap.wml                      wml;
#     text/x-component                      htc;

#     image/png                             png;
#     image/tiff                            tif tiff;
#     image/vnd.wap.wbmp                    wbmp;
#     image/x-icon                          ico;
#     image/x-jng                           jng;
#     image/x-ms-bmp                        bmp;
#     image/svg+xml                         svg svgz;
#     image/webp                            webp;

#     application/font-woff                 woff;
#     application/java-archive              jar war ear;
#     application/json                      json;
#     application/mac-binhex40              hqx;
#     application/msword                    doc;
#     application/pdf                       pdf;
#     application/postscript                ps eps ai;
#     application/rtf                       rtf;
#     application/vnd.apple.mpegurl         m3u8;
#     application/vnd.ms-excel              xls;
#     application/vnd.ms-fontobject         eot;
#     application/vnd.ms-powerpoint         ppt;
#     application/vnd.wap.wmlc              wmlc;
#     application/vnd.google-earth.kml+xml  kml;
#     application/vnd.google-earth.kmz      kmz;
#     application/x-7z-compressed           7z;
#     application/x-cocoa                   cco;
#     application/x-java-archive-diff       jardiff;
#     application/x-java-jnlp-file          jnlp;
#     application/x-makeself                run;
#     application/x-perl                    pl pm;
#     application/x-pilot                   prc pdb;
#     application/x-rar-compressed          rar;
#     application/x-redhat-package-manager  rpm;
#     application/x-sea                     sea;
#     application/x-shockwave-flash         swf;
#     application/x-stuffit                 sit;
#     application/x-tcl                     tcl tk;
#     application/x-x509-ca-cert            der pem crt;
#     application/x-xpinstall               xpi;
#     application/xhtml+xml                 xhtml;
#     application/xspf+xml                  xspf;
#     application/zip                       zip;

#     application/octet-stream              bin exe dll;
#     application/octet-stream              deb;
#     application/octet-stream              dmg;
#     application/octet-stream              iso img;
#     application/octet-stream              msi msp msm;

#     application/vnd.openxmlformats-officedocument.wordprocessingml.document    docx;
#     application/vnd.openxmlformats-officedocument.spreadsheetml.sheet          xlsx;
#     application/vnd.openxmlformats-officedocument.presentationml.presentation  pptx;

#     audio/midi                            mid midi kar;
#     audio/mpeg                            mp3;
#     audio/ogg                             ogg;
#     audio/x-m4a                           m4a;
#     audio/x-realaudio                     ra;

#     video/3gpp                            3gpp 3gp;
#     video/mp2t                            ts;
#     video/mp4                             mp4;
#     video/mpeg                            mpeg mpg;
#     video/quicktime                       mov;
#     video/webm                            webm;
#     video/x-flv                           flv;
#     video/x-m4v                           m4v;
#     video/x-mng                           mng;
#     video/x-ms-asf                        asx asf;
#     video/x-ms-wmv                        wmv;
#     video/x-msvideo                       avi;
# }

The file contains a long list of file types and their extensions. To use this file inside your configuration file, update your configuration to look as follows:

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;
    }

}

The old types context has now been replaced with a new include directive. Like the name suggests, this directive allows you to include content from other configuration files.

Validate and reload the configuration file and send a request for the mini.min.css file once again:

curl -I http://nginx-handbook.test/mini.min.css

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 12:29:35 GMT
# Content-Type: text/css
# Content-Length: 46887
# Last-Modified: Wed, 21 Apr 2021 11:27:06 GMT
# Connection: keep-alive
# ETag: "60800c0a-b727"
# Accept-Ranges: bytes

In the section below on how to understand the main configuration file, I'll demonstrate how include can be used to modularize your virtual server configurations.

Dynamic Routing in NGINX

The configuration you wrote in the previous section was a very simple static content server configuration. All it did was match a file from the site root corresponding to the URI the client visits and respond back.

So if the client requests files existing on the root such as index.html, about.html or mini.min.css NGINX will return the file. But if you visit a route such as http://nginx-handbook.test/nothing, it'll respond with the default 404 page:

In this section of the book, you'll learn about the location context, variables, redirects, rewrites and the try_files directive. There will be no new projects in this section but the concepts you learn here will be necessary in the upcoming sections.

Also the configuration will change very frequently in this section, so do not forget to validate and reload the configuration file after every update.

Location Matches

The first concept we'll discuss in this section is the location context. Update the configuration as follows:

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        location /agatha {
            return 200 "Miss Marple.\nHercule Poirot.\n";
        }
    }
}

We've replaced the root directive with a new location context. This context is usually nested inside server blocks. There can be multiple location contexts within a server context.

If you send a request to http://nginx-handbook.test/agatha, you'll get a 200 response code and list of characters created by Agatha Christie.

curl -i http://nginx-handbook.test/agatha

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 15:59:07 GMT
# Content-Type: text/plain
# Content-Length: 29
# Connection: keep-alive

# Miss Marple.
# Hercule Poirot.

Now if you send a request to http://nginx-handbook.test/agatha-christie, you'll get the same response:

curl -i http://nginx-handbook.test/agatha-christie

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 15:59:07 GMT
# Content-Type: text/plain
# Content-Length: 29
# Connection: keep-alive

# Miss Marple.
# Hercule Poirot.

This happens because, by writing location /agatha, you're telling NGINX to match any URI starting with "agatha". This kind of match is called a prefix match.

To perform an exact match, you'll have to update the code as follows:

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        location = /agatha {
            return 200 "Miss Marple.\nHercule Poirot.\n";
        }
    }

}

Adding an = sign before the location URI will instruct NGINX to respond only if the URL matches exactly. Now if you send a request to anything but /agatha, you'll get a 404 response.

curl -I http://nginx-handbook.test/agatha-christie

# HTTP/1.1 404 Not Found
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 16:14:29 GMT
# Content-Type: text/html
# Content-Length: 162
# Connection: keep-alive

curl -I http://nginx-handbook.test/agatha

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 16:15:04 GMT
# Content-Type: text/plain
# Content-Length: 29
# Connection: keep-alive

Another kind of match in NGINX is the regex match. Using this match you can check location URLs against complex regular expressions.

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        location ~ /agatha[0-9] {
            return 200 "Miss Marple.\nHercule Poirot.\n";
        }
    }

}

By replacing the previously used = sign with a ~ sign, you're telling NGINX to perform a regular expression match. Setting the location to ~ /agatha[0-9] means NIGINX will only respond if there is a number after the word "agatha":

curl -I http://nginx-handbook.test/agatha

# HTTP/1.1 404 Not Found
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 16:14:29 GMT
# Content-Type: text/html
# Content-Length: 162
# Connection: keep-alive

curl -I http://nginx-handbook.test/agatha8

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 16:15:04 GMT
# Content-Type: text/plain
# Content-Length: 29
# Connection: keep-alive

A regex match is by default case sensitive, which means that if you capitalize any of the letters, the location won't work:

curl -I http://nginx-handbook.test/Agatha8

# HTTP/1.1 404 Not Found
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 16:14:29 GMT
# Content-Type: text/html
# Content-Length: 162
# Connection: keep-alive

To turn this into case insensitive, you'll have to add a * after the ~ sign.

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        location ~* /agatha[0-9] {
            return 200 "Miss Marple.\nHercule Poirot.\n";
        }
    }

}

That will tell NGINX to let go of type sensitivity and match the location anyways.

curl -I http://nginx-handbook.test/agatha8

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 16:15:04 GMT
# Content-Type: text/plain
# Content-Length: 29
# Connection: keep-alive

curl -I http://nginx-handbook.test/Agatha8

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 16:15:04 GMT
# Content-Type: text/plain
# Content-Length: 29
# Connection: keep-alive

NGINX assigns priority values to these matches, and a regex match has more priority than a prefix match.

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        location /Agatha8 {
            return 200 "prefix matched.\n";
        }

        location ~* /agatha[0-9] {
            return 200 "regex matched.\n";
        }
    }

}

Now if you send a request to http://nginx-handbook.test/Agatha8, you'll get the following response:

curl -i http://nginx-handbook.test/Agatha8

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Thu, 22 Apr 2021 08:08:18 GMT
# Content-Type: text/plain
# Content-Length: 15
# Connection: keep-alive

# regex matched.

But this priority can be changed a little. The final type of match in NGINX is a preferential prefix match. To turn a prefix match into a preferential one, you need to include the ^~ modifier before the location URI:

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        location ^~ /Agatha8 {
            return 200 "prefix matched.\n";
        }

        location ~* /agatha[0-9] {
            return 200 "regex matched.\n";
        }
    }

}

Now if you send a request to http://nginx-handbook.test/Agatha8, you'll get the following response:

curl -i http://nginx-handbook.test/Agatha8

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Thu, 22 Apr 2021 08:13:24 GMT
# Content-Type: text/plain
# Content-Length: 16
# Connection: keep-alive

# prefix matched.

This time, the prefix match wins. So the list of all the matches in descending order of priority is as follows:

Variables in NGINX

Variables in NGINX are similar to variables in other programming languages. The set directive can be used to declare new variables anywhere within the configuration file:

set $<variable_name> <variable_value>;

# set name "Farhan"
# set age 25
# set is_working true

Variables can be of three types

• String
• Integer
• Boolean

Apart from the variables you declare, there are embedded variables within NGINX modules. An alphabetical index of variables is available in the official documentation.

To see some of the variables in action, update the configuration as follows:

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        return 200 "Host - $host\nURI - $uri\nArgs - $args\n";
    }

}

Now upon sending a request to the server, you should get a response as follows:

# curl http://nginx-handbook.test/user?name=Farhan

# Host - nginx-handbook.test
# URI - /user
# Args - name=Farhan

As you can see, the $host and $uri variables hold the root address and the requested URI relative to the root, respectively. The $args variable, as you can see, contains all the query strings.

Instead of printing the literal string form of the query strings, you can access the individual values using the $arg variable.

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        set $name $arg_name; # $arg_<query string name>

        return 200 "Name - $name\n";
    }

}

Now the response from the server should look like as follows:

curl http://nginx-handbook.test?name=Farhan

# Name - Farhan

The variables I demonstrated here are embedded in the ngx_http_core_module. For a variable to be accessible in the configuration, NGINX has to be built with the module embedding the variable. Building NGINX from source and usage of dynamic modules is slightly out of scope for this article. But I'll surely write about that in my blog.

Redirects and Rewrites

A redirect in NGINX is same as redirects in any other platform. To demonstrate how redirects work, update your configuration to look like this:

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;

        location = /index_page {
                return 307 /index.html;
        }

        location = /about_page {
                return 307 /about.html;
        }
    }
}

Now if you send a request to http://nginx-handbook.test/about_page, you'll be redirected to http://nginx-handbook.test/about.html:

curl -I http://nginx-handbook.test/about_page

# HTTP/1.1 307 Temporary Redirect
# Server: nginx/1.18.0 (Ubuntu)
# Date: Thu, 22 Apr 2021 18:02:04 GMT
# Content-Type: text/html
# Content-Length: 180
# Location: http://nginx-handbook.test/about.html
# Connection: keep-alive

As you can see, the server responded with a status code of 307 and the location indicates http://nginx-handbook.test/about.html. If you visit http://nginx-handbook.test/about_page from a browser, you'll see that the URL will automatically change to http://nginx-handbook.test/about.html.

A rewrite directive, however, works a little differently. It changes the URI internally, without letting the user know. To see it in action, update your configuration as follows:

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;

        rewrite /index_page /index.html;

        rewrite /about_page /about.html;
    }
}

Now if you send a request to http://nginx-handbook/about_page URI, you'll get a 200 response code and the HTML code for about.html file in response:

curl -i http://nginx-handbook.test/about_page

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Thu, 22 Apr 2021 18:09:31 GMT
# Content-Type: text/html
# Content-Length: 960
# Last-Modified: Wed, 21 Apr 2021 11:27:06 GMT
# Connection: keep-alive
# ETag: "60800c0a-3c0"
# Accept-Ranges: bytes

# <!DOCTYPE html>
# <html lang="en">
# <head>
#     <meta charset="UTF-8">
#     <meta http-equiv="X-UA-Compatible" content="IE=edge">
#     <meta name="viewport" content="width=device-width, initial-scale=1.0">
#     <title>NGINX Handbook Static Demo</title>
#     <link rel="stylesheet" href="mini.min.css">
#     <style>
#         .container {
#             max-width: 1024px;
#             margin-left: auto;
#             margin-right: auto;
#         }
# 
#         h1 {
#             text-align: center;
#         }
#     </style>
# </head>
# <body class="container">
#     <header>
#         <a class="button" href="index.html">Index</a>
#         <a class="button" href="about.html">About</a>
#         <a class="button" href="nothing">Nothing</a>
#     </header>
#     <div class="card fluid">
#         <img src="./the-nginx-handbook.jpg" alt="The NGINX Handbook Cover Image">
#     </div>
#     <div class="card fluid">
#         <h1>this is the <strong>about.html</strong> file</h1>
#     </div>
# </body>
# </html>

And if you visit the URI using a browser, you'll see the about.html page while the URL remains unchanged:

Apart from the way the URI change is handled, there is another difference between a redirect and rewrite. When a rewrite happens, the server context gets re-evaluated by NGINX. So, a rewrite is a more expensive operation than a redirect.

How to Try for Multiple Files

The final concept I'll be showing in this section is the try_files directive. Instead of responding with a single file, the try_files directive lets you check for the existence of multiple files.

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;

        try_files /the-nginx-handbook.jpg /not_found;

        location /not_found {
                return 404 "sadly, you've hit a brick wall buddy!\n";
        }
    }
}

As you can see, a new try_files directive has been added. By writing try_files /the-nginx-handbook.jpg /not_found; you're instructing NGINX to look for a file named the-nginx-handbook.jpg on the root whenever a request is received. If it doesn't exist, go to the /not_found location.

So now if you visit the server, you'll see the image:

But if you update the configuration to try for a non-existent file such as blackhole.jpg, you'll get a 404 response with the message "sadly, you've hit a brick wall buddy!".

Now the problem with writing a try_files directive this way is that no matter what URL you visit, as long as a request is received by the server and the the-nginx-handbook.jpg file is found on the disk, NGINX will send that back.

And that's why try_files is often used with the $uri NGINX variable.

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;

        try_files $uri /not_found;

        location /not_found {
                return 404 "sadly, you've hit a brick wall buddy!\n";
        }
    }
}

By writing try_files $uri /not_found; you're instructing NGINX to try for the URI requested by the client first. If it doesn't find that one, then try the next one.

So now if you visit http://nginx-handbook.test/index.html you should get the old index.html page. The same goes for the about.html page:

But if you request a file that doesn't exist, you'll get the response from the /not_found location:

curl -i http://nginx-handbook.test/nothing

# HTTP/1.1 404 Not Found
# Server: nginx/1.18.0 (Ubuntu)
# Date: Thu, 22 Apr 2021 20:01:57 GMT
# Content-Type: text/plain
# Content-Length: 38
# Connection: keep-alive

# sadly, you've hit a brick wall buddy!

One thing that you may have already noticed is that if you visit the server root http://nginx-handbook.test, you get the 404 response.

This is because when you're hitting the server root, the $uri variable doesn't correspond to any existing file so NGINX serves you the fallback location. If you want to fix this issue, update your configuration as follows:

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;

        try_files $uri $uri/ /not_found;

        location /not_found {
                return 404 "sadly, you've hit a brick wall buddy!\n";
        }
    }
}

By writing try_files $uri $uri/ /not_found; you're instructing NGINX to try for the requested URI first. If that doesn't work then try for the requested URI as a directory, and whenever NGINX ends up into a directory it automatically starts looking for an index.html file.

Now if you visit the server, you should get the index.html file just right:

The try_files is the kind of directive that can be used in a number of variations. In the upcoming sections, you'll encounter a few other variations but I would suggest that you do some research on the internet regarding the different usage of this directive by yourself.

Logging in NGINX

By default, NGINX's log files are located inside /var/log/nginx. If you list the content of this directory, you may see something as follows:

ls -lh /var/log/nginx/

# -rw-r----- 1 www-data adm     0 Apr 25 07:34 access.log
# -rw-r----- 1 www-data adm     0 Apr 25 07:34 error.log

Let's begin by emptying the two files.

# delete the old files
sudo rm /var/log/nginx/access.log /var/log/nginx/error.log

# create new files
sudo touch /var/log/nginx/access.log /var/log/nginx/error.log

# reopen the log files
sudo nginx -s reopen

If you do not dispatch a reopen signal to NGINX, it'll keep writing logs to the previously open streams and the new files will remain empty.

Now to make an entry in the access log, send a request to the server.

curl -I http://nginx-handbook.test

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Sun, 25 Apr 2021 08:35:59 GMT
# Content-Type: text/html
# Content-Length: 960
# Last-Modified: Sun, 25 Apr 2021 08:35:33 GMT
# Connection: keep-alive
# ETag: "608529d5-3c0"
# Accept-Ranges: bytes

sudo cat /var/log/nginx/access.log 

# 192.168.20.20 - - [25/Apr/2021:08:35:59 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.68.0"

As you can see, a new entry has been added to the access.log file. Any request to the server will be logged to this file by default. But we can change this behavior using the access_log directive.

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        location / {
            return 200 "this will be logged to the default file.\n";
        }

        location = /admin {
            access_log /var/logs/nginx/admin.log;

            return 200 "this will be logged in a separate file.\n";
        }

        location = /no_logging {
            access_log off;

            return 200 "this will not be logged.\n";
        }
    }
}

The first access_log directive inside the /admin location block instructs NGINX to write any access log of this URI to the /var/logs/nginx/admin.log file. The second one inside the /no_logging location turns off access logs for this location completely.

Validate and reload the configuration. Now if you send requests to these locations and inspect the log files, you should see something like this:

curl http://nginx-handbook.test/no_logging
# this will not be logged

sudo cat /var/log/nginx/access.log
# empty

curl http://nginx-handbook.test/admin
# this will be logged in a separate file.

sudo cat /var/log/nginx/access.log
# empty

sudo cat /var/log/nginx/admin.log 
# 192.168.20.20 - - [25/Apr/2021:11:13:53 +0000] "GET /admin HTTP/1.1" 200 40 "-" "curl/7.68.0"

curl  http://nginx-handbook.test/
# this will be logged to the default file.

sudo cat /var/log/nginx/access.log 
# 192.168.20.20 - - [25/Apr/2021:11:15:14 +0000] "GET / HTTP/1.1" 200 41 "-" "curl/7.68.0"

The error.log file, on the other hand, holds the failure logs. To make an entry to the error.log, you'll have to make NGINX crash. To do so, update your configuration as follows:

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        return 200 "..." "...";
    }

}

As you know, the return directive takes only two parameters – but we've given three here. Now try reloading the configuration and you'll be presented with an error message:

sudo nginx -s reload

# nginx: [emerg] invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:14

Check the content of the error log and the message should be present there as well:

sudo cat /var/log/nginx/error.log 

# 2021/04/25 08:35:45 [notice] 4169#4169: signal process started
# 2021/04/25 10:03:18 [emerg] 8434#8434: invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:14

Error messages have levels. A notice entry in the error log is harmless, but an emerg or emergency entry has to be addressed right away.

There are eight levels of error messages:

• debug – Useful debugging information to help determine where the problem lies.
• info – Informational messages that aren't necessary to read but may be good to know.
• notice – Something normal happened that is worth noting.
• warn – Something unexpected happened, however is not a cause for concern.
• error – Something was unsuccessful.
• crit – There are problems that need to be critically addressed.
• alert – Prompt action is required.
• emerg – The system is in an unusable state and requires immediate attention.

By default, NGINX records all level of messages. You can override this behavior using the error_log directive. If you want to set the minimum level of a message to be warn, then update your configuration file as follows:

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        error_log /var/log/error.log warn;

        return 200 "..." "...";
    }

}

Validate and reload the configuration, and from now on only messages with a level of warn or above will be logged.

cat /var/log/nginx/error.log

# 2021/04/25 11:27:02 [emerg] 12769#12769: invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:16

Unlike the previous output, there are no notice entries here. emerg is a higher level error than warn and that's why it has been logged.

For most projects, leaving the error configuration as it is should be fine. The only suggestion I have is to set the minimum error level to warn. This way you won't have to look at unnecessary entries in the error log.

But if you want to learn more about customizing logging in NGINX, this link to the official docs may help.

How to Use NGINX as a Reverse Proxy

When configured as a reverse proxy, NGINX sits between the client and a back end server. The client sends requests to NGINX, then NGINX passes the request to the back end.

Once the back end server finishes processing the request, it sends it back to NGINX. In turn, NGINX returns the response to the client.

During the whole process, the client doesn't have any idea about who's actually processing the request. It sounds complicated in writing, but once you do it for yourself you'll see how easy NGINX makes it.

Let's see a very basic and impractical example of a reverse proxy:

events {

}

http {

    include /etc/nginx/mime.types;

    server {
        listen 80;
        server_name nginx.test;

        location / {
                proxy_pass "https://nginx.org/";
        }
    }
}

Apart from validating and reloading the configuration, you'll also have to add this address to your hosts file to make this demo work on your system:

192.168.20.20   nginx.test

Now if you visit http://nginx.test, you'll be greeted by the original https://nginx.org site while the URI remains unchanged.

You should be even able to navigate around the site to an extent. If you visit http://nginx.test/en/docs/ you should get the http://nginx.org/en/docs/ page in response.

So as you can see, at a basic level, the proxy_pass directive simply passes a client's request to a third party server and reverse proxies the response to the client.

Node.js With NGINX

Now that you know how to configure a basic reverse proxy server, you can serve a Node.js application reverse proxied by NGINX. I've added a demo application inside the repository that comes with this article.

I'm assuming that you have experience with Node.js and know how to start a Node.js application using PM2.

If you've already cloned the repository inside /srv/nginx-handbook-projects then the node-js-demo project should be available in the /srv/nginx-handbook-projects/node-js-demo directory.

For this demo to work, you'll need to install Node.js on your server. You can do that following the instructions found here.

The demo application is a simple HTTP server that responds with a 200 status code and a JSON payload. You can start the application by simply executing node app.js but a better way is to use PM2.

For those of you who don't know, PM2 is a daemon process manager widely used in production for Node.js applications. If you want to learn more, this link may help.

Install PM2 globally by executing sudo npm install -g pm2. After the installation is complete, execute following command while being inside the /srv/nginx-handbook-projects/node-js-demo directory:

pm2 start app.js

# [PM2] Process successfully started
# ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐
# │ id │ name               │ mode     │ ↺    │ status    │ cpu      │ memory   │
# ├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤
# │ 0  │ app                │ fork     │ 0    │ online    │ 0%       │ 21.2mb   │
# └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘

Alternatively you can also do pm2 start /srv/nginx-handbook-projects/node-js-demo/app.js from anywhere on the server. You can stop the application by executing the pm2 stop app command.

The application should be running now but should not be accessible from outside of the server. To verify if the application is running or not, send a get request to http://localhost:3000 from inside your server:

curl -i localhost:3000

# HTTP/1.1 200 OK
# X-Powered-By: Express
# Content-Type: application/json; charset=utf-8
# Content-Length: 62
# ETag: W/"3e-XRN25R5fWNH2Tc8FhtUcX+RZFFo"
# Date: Sat, 24 Apr 2021 12:09:55 GMT
# Connection: keep-alive
# Keep-Alive: timeout=5

# { "status": "success", "message": "You're reading The NGINX Handbook!" }

If you get a 200 response, then the server is running fine. Now to configure NGINX as a reverse proxy, open your configuration file and update its content as follows:

events {

}

http {
    listen 80;
    server_name nginx-handbook.test

    location / {
        proxy_pass http://localhost:3000;
    }
}

Nothing new to explain here. You're just passing the received request to the Node.js application running at port 3000. Now if you send a request to the server from outside you should get a response as follows:

curl -i http://nginx-handbook.test

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Sat, 24 Apr 2021 14:58:01 GMT
# Content-Type: application/json
# Transfer-Encoding: chunked
# Connection: keep-alive

# { "status": "success", "message": "You're reading The NGINX Handbook!" }

Although this works for a basic server like this, you may have to add a few more directives to make it work in a real world scenario depending on your application's requirements.

For example, if your application handles web socket connections, then you should update the configuration as follows:

events {

}

http {
    listen 80;
    server_name nginx-handbook.test

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
    }
}

The proxy_http_version directive sets the HTTP version for the server. By default it's 1.0, but web socket requires it to be at least 1.1. The proxy_set_header directive is used for setting a header on the back-end server. Generic syntax for this directive is as follows:

proxy_set_header <header name> <header value>

So, by writing proxy_set_header Upgrade $http_upgrade; you're instructing NGINX to pass the value of the $http_upgrade variable as a header named Upgrade – same for the Connection header.

If you would like to learn more about web socket proxying, this link to the official NGINX docs may help.

Depending on the headers required by your application, you may have to set more of them. But the above mentioned configuration is very commonly used to serve Node.js applications.

PHP With NGINX

PHP and NGINX go together like bread and butter. After all the E and the P in the LEMP stack stand for NGINX and PHP.

I'm assuming you have experience with PHP and know how to run a PHP application.

I've already included a demo PHP application in the repository that comes with this article. If you've already cloned it in the /srv/nginx-handbook-projects directory, then the application should be inside /srv/nginx-handbook-projects/php-demo.

For this demo to work, you'll have to install a package called PHP-FPM. To install the package, you can execute following command:

sudo apt install php-fpm -y

To test out the application, start a PHP server by executing the following command while inside the /srv/nginx-handbook-projects/php-demo directory:

php -S localhost:8000

# [Sat Apr 24 16:17:36 2021] PHP 7.4.3 Development Server (http://localhost:8000) started

Alternatively you can also do php -S localhost:8000 /srv/nginx-handbook-projects/php-demo/index.php from anywhere on the server.

The application should be running at port 8000 but it can not be accessed from the outside of the server. To verify, send a get request to http://localhost:8000 from inside your server:

curl -I localhost:8000

# HTTP/1.1 200 OK
# Host: localhost:8000
# Date: Sat, 24 Apr 2021 16:22:42 GMT
# Connection: close
# X-Powered-By: PHP/7.4.3
# Content-type: application/json

# {"status":"success","message":"You're reading The NGINX Handbook!"}

If you get a 200 response then the server is running fine. Just like the Node.js configuration, now you can simply proxy_pass the requests to localhost:8000 – but with PHP, there is a better way.

The FPM part in PHP-FPM stands for FastCGI Process Module. FastCGI is a protocol just like HTTP for exchanging binary data. This protocol is slightly faster than HTTP and provides better security.

To use FastCGI instead of HTTP, update your configuration as follows:

events {

}

http {

      include /etc/nginx/mime.types;

      server {

          listen 80;
          server_name nginx-handbook.test;
          root /srv/nginx-handbook-projects/php-demo;

          index index.php;

          location / {
              try_files $uri $uri/ =404;
          }

          location ~ \.php$ {
              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
              fastcgi_param REQUEST_METHOD $request_method;
              fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
      }
   }
}

Let's begin with the new index directive. As you know, NGINX by default looks for an index.html file to serve. But in the demo-project, it's called index.php. So by writing index index.php, you're instructing NGINX to use the index.php file as root instead.

This directive can accept multiple parameters. If you write something like index index.php index.html, NGINX will first look for index.php. If it doesn't find that file, it will look for an index.html file.

The try_files directive inside the first location context is the same as you've seen in a previous section. The =404 at the end indicates the error to throw if none of the files are found.

The second location block is the place where the main magic happens. As you can see, we've replaced the proxy_pass directive by a new fastcgi_pass. As the name suggests, it's used to pass a request to a FastCGI service.

The PHP-FPM service by default runs on port 9000 of the host. So instead of using a Unix socket like I've done here, you can pass the request to http://localhost:9000 directly. But using a Unix socket is more secure.

If you have multiple PHP-FPM versions installed, you can simply list all the socket file locations by executing the following command:

sudo find / -name *fpm.sock

# /run/php/php7.4-fpm.sock
# /run/php/php-fpm.sock
# /etc/alternatives/php-fpm.sock
# /var/lib/dpkg/alternatives/php-fpm.sock

The /run/php/php-fpm.sock file refers to the latest version of PHP-FPM installed on your system. I prefer using the one with the version number. This way even if PHP-FPM gets updated, I'll be certain about the version I'm using.

Unlike passing requests through HTTP, passing requests through FPM requires us to pass some extra information.

The general way of passing extra information to the FPM service is using the fastcgi_param directive. At the very least, you'll have to pass the request method and the script name to the back-end service for the proxying to work.

The fastcgi_param REQUEST_METHOD $request_method; passes the request method to the back-end and the fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; line passes the exact location of the PHP script to run.

At this state, your configuration should work. To test it out, visit your server and you should be greeted by something like this:

Well, that's weird. A 500 error means NGINX has crashed for some reason. This is where the error logs can come in handy. Let's have a look at the last entry in the error.log file:

tail -n 1 /var/log/nginx/error.log

# 2021/04/24 17:15:17 [crit] 17691#17691: *21 connect() to unix:/var/run/php/php7.4-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.20.20, server: nginx-handbook.test, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "nginx-handbook.test"

Seems like the NGINX process is being denied permission to access the PHP-FPM process.

One of the main reasons for getting a permission denied error is user mismatch. Have a look at the user owning the NGINX worker process.

ps aux | grep nginx

# root         677  0.0  0.4   8892  4260 ?        Ss   14:31   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
# nobody     17691  0.0  0.3   9328  3452 ?        S    17:09   0:00 nginx: worker process
# vagrant    18224  0.0  0.2   8160  2552 pts/0    S+   17:19   0:00 grep --color=auto nginx

As you can see, the process is currently owned by nobody. Now inspect the PHP-FPM process.

# ps aux | grep php

# root       14354  0.0  1.8 195484 18924 ?        Ss   16:11   0:00 php-fpm: master process (/etc/php/7.4/fpm/php-fpm.conf)
# www-data   14355  0.0  0.6 195872  6612 ?        S    16:11   0:00 php-fpm: pool www
# www-data   14356  0.0  0.6 195872  6612 ?        S    16:11   0:00 php-fpm: pool www
# vagrant    18296  0.0  0.0   8160   664 pts/0    S+   17:20   0:00 grep --color=auto php

This process, on the other hand, is owned by the www-data user. This is why NGINX is being denied access to this process.

To solve this issue, update your configuration as follows:

user www-data;

events {

}

http {

      include /etc/nginx/mime.types;

      server {

          listen 80;
          server_name nginx-handbook.test;
          root /srv/nginx-handbook-projects/php-demo;

          index index.php;

          location / {
              try_files $uri $uri/ =404;
          }

          location ~ \.php$ {
              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
              fastcgi_param REQUEST_METHOD $request_method;
              fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
      }
   }
}

The user directive is responsible for setting the owner for the NGINX worker processes. Now inspect the the NGINX process once again:

# ps aux | grep nginx

# root         677  0.0  0.4   8892  4264 ?        Ss   14:31   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
# www-data   20892  0.0  0.3   9292  3504 ?        S    18:10   0:00 nginx: worker process
# vagrant    21294  0.0  0.2   8160  2568 pts/0    S+   18:18   0:00 grep --color=auto nginx

Undoubtedly the process is now owned by the www-data user. Send a request to your server to check if it's working or not:

# curl -i http://nginx-handbook.test

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Sat, 24 Apr 2021 18:22:24 GMT
# Content-Type: application/json
# Transfer-Encoding: chunked
# Connection: keep-alive

# {"status":"success","message":"You're reading The NGINX Handbook!"}

If you get a 200 status code with a JSON payload, you're good to go.

This simple configuration is fine for the demo application, but in real-life projects you'll have to pass some additional parameters.

For this reason, NGINX includes a partial configuration called fastcgi_params. This file contains a list of the most common FastCGI parameters.

cat /etc/nginx/fastcgi_params

# fastcgi_param  QUERY_STRING       $query_string;
# fastcgi_param  REQUEST_METHOD     $request_method;
# fastcgi_param  CONTENT_TYPE       $content_type;
# fastcgi_param  CONTENT_LENGTH     $content_length;

# fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
# fastcgi_param  REQUEST_URI        $request_uri;
# fastcgi_param  DOCUMENT_URI       $document_uri;
# fastcgi_param  DOCUMENT_ROOT      $document_root;
# fastcgi_param  SERVER_PROTOCOL    $server_protocol;
# fastcgi_param  REQUEST_SCHEME     $scheme;
# fastcgi_param  HTTPS              $https if_not_empty;

# fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
# fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

# fastcgi_param  REMOTE_ADDR        $remote_addr;
# fastcgi_param  REMOTE_PORT        $remote_port;
# fastcgi_param  SERVER_ADDR        $server_addr;
# fastcgi_param  SERVER_PORT        $server_port;
# fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
# fastcgi_param  REDIRECT_STATUS    200;

As you can see, this file also contains the REQUEST_METHOD parameter. Instead of passing that manually, you can just include this file in your configuration:

user www-data;

events {

}

http {

      include /etc/nginx/mime.types;

      server {

          listen 80;
          server_name nginx-handbook.test;
          root /srv/nginx-handbook-projects/php-demo;

          index index.php;

          location / {
              try_files $uri $uri/ =404;
          }

          location ~ \.php$ {
              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
              fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
              include /etc/nginx/fastcgi_params;
      }
   }
}

Your server should behave just the same. Apart from the fastcgi_params file, you may also come across the fastcgi.conf file which contains a slightly different set of parameters. I would suggest that you avoid that due to some inconsistencies with its behavior.

How to Use NGINX as a Load Balancer

Thanks to the reverse proxy design of NGINX, you can easily configure it as a load balancer.

I've already added a demo to the repository that comes with this article. If you've already cloned the repository inside the /srv/nginx-handbook-projects/ directory then the demo should be in the /srv/nginx-handbook-projects/load-balancer-demo/ directory.

In a real life scenario, load balancing may be required on large scale projects distributed across multiple servers. But for this simple demo, I've created three very simple Node.js servers responding with a server number and 200 status code.

For this demo to work, you'll need Node.js installed on the server. You can find instructions in this link to help you get it installed.

Apart from this, you'll also need PM2 for daemonizing the Node.js servers provided in this demo.

If you haven't already, install PM2 by executing sudo npm install -g pm2. After the installation finishes, execute the following commands to start the three Node.js servers:

pm2 start /srv/nginx-handbook-projects/load-balancer-demo/server-1.js

pm2 start /srv/nginx-handbook-projects/load-balancer-demo/server-2.js

pm2 start /srv/nginx-handbook-projects/load-balancer-demo/server-3.js

pm2 list

# ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐
# │ id │ name               │ mode     │ ↺    │ status    │ cpu      │ memory   │
# ├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤
# │ 0  │ server-1           │ fork     │ 0    │ online    │ 0%       │ 37.4mb   │
# │ 1  │ server-2           │ fork     │ 0    │ online    │ 0%       │ 37.2mb   │
# │ 2  │ server-3           │ fork     │ 0    │ online    │ 0%       │ 37.1mb   │
# └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘

Three Node.js servers should be running on localhost:3001, localhost:3002, localhost:3003 respectively.

Now update your configuration as follows:

events {

}

http {

    upstream backend_servers {
        server localhost:3001;
        server localhost:3002;
        server localhost:3003;
    }

    server {

        listen 80;
        server_name nginx-handbook.test;

        location / {
            proxy_pass http://backend_servers;
        }
    }
}

The configuration inside the server context is the same as you've already seen. The upstream context, though, is new. An upstream in NGINX is a collection of servers that can be treated as a single backend.

So the three servers you started using PM2 can be put inside a single upstream and you can let NGINX balance the load between them.

To test out the configuration, you'll have to send a number of requests to the server. You can automate the process using a while loop in bash:

while sleep 0.5; do curl http://nginx-handbook.test; done

# response from server - 2.
# response from server - 3.
# response from server - 1.
# response from server - 2.
# response from server - 3.
# response from server - 1.
# response from server - 2.
# response from server - 3.
# response from server - 1.
# response from server - 2.

You can cancel the loop by hitting Ctrl + C on your keyboard. As you can see from the responses from the server, NGINX is load balancing the servers automatically.

Of course, depending on the project scale, load balancing can be a lot more complicated than this. But the goal of this article is to get you started, and I believe you now have a basic understanding of load balancing with NGINX. You can stop the three running server by executing pm2 stop server-1 server-2 server-3 command (and it's a good idea here).

How to Optimize NGINX for Maximum Performance

In this section of the article, you'll learn about a number of ways to get the maximum performance from your server.

Some of these methods will be application-specific, which means they'll probably need tweaking considering your application requirements. But some of them will be general optimization techniques.

Just like the previous sections, changes in configuration will be frequesnt in this one, so don't forget to validate and reload your configuration file every time.

How to Configure Worker Processes and Worker Connections

As I've already mentioned in a previous section, NGINX can spawn multiple worker processes capable of handling thousands of requests each.

sudo systemctl status nginx

# ● nginx.service - A high performance web server and a reverse proxy server
#      Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
#      Active: active (running) since Sun 2021-04-25 08:33:11 UTC; 5h 45min ago
#        Docs: man:nginx(8)
#    Main PID: 3904 (nginx)
#       Tasks: 2 (limit: 1136)
#      Memory: 3.2M
#      CGroup: /system.slice/nginx.service
#              ├─ 3904 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
#              └─16443 nginx: worker process

As you can see, right now there is only one NGINX worker process on the system. This number, however, can be changed by making a small change to the configuration file.

worker_processes 2;

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        return 200 "worker processes and worker connections configuration!\n";
    }
}

The worker_process directive written in the main context is responsible for setting the number of worker processes to spawn. Now check the NGINX service once again and you should see two worker processes:

sudo systemctl status nginx

# ● nginx.service - A high performance web server and a reverse proxy server
#      Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
#      Active: active (running) since Sun 2021-04-25 08:33:11 UTC; 5h 54min ago
#        Docs: man:nginx(8)
#     Process: 22610 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=0/SUCCESS)
#    Main PID: 3904 (nginx)
#       Tasks: 3 (limit: 1136)
#      Memory: 3.7M
#      CGroup: /system.slice/nginx.service
#              ├─ 3904 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
#              ├─22611 nginx: worker process
#              └─22612 nginx: worker process

Setting the number of worker processes is easy, but determining the optimal number of worker processes requires a bit more work.

The worker processes are asynchronous in nature. This means that they will process incoming requests as fast as the hardware can.

Now consider that your server runs on a single core processor. If you set the number of worker processes to 1, that single process will utilize 100% of the CPU capacity. But if you set it to 2, the two processes will be able to utilize 50% of the CPU each. So increasing the number of worker processes doesn't mean better performance.

A rule of thumb in determining the optimal number of worker processes is number of worker process = number of CPU cores.

If you're running on a server with a dual core CPU, the number of worker processes should be set to 2. In a quad core it should be set to 4...and you get the idea.

Determining the number of CPUs on your server is very easy on Linux.

nproc

# 1

I'm on a single CPU virtual machine, so the nproc detects that there's one CPU. Now that you know the number of CPUs, all that is left to do is set the number on the configuration.

That's all well and good, but every time you upscale the server and the CPU number changes, you'll have to update the server configuration manually.

NGINX provides a better way to deal with this issue. You can simply set the number of worker processes to auto and NGINX will set the number of processes based on the number of CPUs automatically.

worker_processes auto;

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        return 200 "worker processes and worker connections configuration!\n";
    }
}

Inspect the NGINX process once again:

sudo systemctl status nginx

# ● nginx.service - A high performance web server and a reverse proxy server
#      Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
#      Active: active (running) since Sun 2021-04-25 08:33:11 UTC; 6h ago
#        Docs: man:nginx(8)
#     Process: 22610 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=0/SUCCESS)
#    Main PID: 3904 (nginx)
#       Tasks: 2 (limit: 1136)
#      Memory: 3.2M
#      CGroup: /system.slice/nginx.service
#              ├─ 3904 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
#              └─23659 nginx: worker process

The number of worker processes is back to one again, because that's what is optimal for this server.

Apart from the worker processes there is also the worker connection, indicating the highest number of connections a single worker process can handle.

Just like the number of worker processes, this number is also related to the number of your CPU core and the number of files your operating system is allowed to open per core.

Finding out this number is very easy on Linux:

ulimit -n

# 1024

Now that you have the number, all that is left is to set it in the configuration:

worker_processes auto;

events {
    worker_connections 1024;
}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        return 200 "worker processes and worker connections configuration!\n";
    }
}

The worker_connections directive is responsible for setting the number of worker connections in a configuration. This is also the first time you're working with the events context.

In a previous section, I mentioned that this context is used for setting values used by NGINX on a general level. The worker connections configuration is one such example.

How to Cache Static Content

The second technique for optimizing your server is caching static content. Regardless of the application you're serving, there is always a certain amount of static content being served, such as stylesheets, images, and so on.

Considering that this content is not likely to change very frequently, it's a good idea to cache them for a certain amount of time. NGINX makes this task easy as well.

worker_processes auto;

events {
    worker_connections 1024;
}

http {

    include /env/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-demo/static-demo;

        location ~* \.(css|js|jpg)$ {
            access_log off;

            add_header Cache-Control public;
            add_header Pragma public;
            add_header Vary Accept-Encoding;
            expires 1M;
        }
    }
}

By writing location ~* .(css|js|jpg)$ you're instructing NGINX to match requests asking for a file ending with .css, .js and .jpg.

In my applications, I usually store images in the WebP format even if the user submits a different format. This way, configuring the static cache becomes even easier for me.

You can use the add_header directive to include a header in the response to the client. Previously you've seen the proxy_set_header directive used for setting headers on an ongoing request to the backend server. The add_header directive on the other hand only adds a given header to the response.

By setting the Cache-Control header to public, you're telling the client that this content can be cached in any way. The Pragma header is just an older version of the Cache-Control header and does more or less the same thing.

The next header, Vary, is responsible for letting the client know that this cached content may vary.

The value of Accept-Encoding means that the content may vary depending on the content encoding accepted by the client. This will be clarified further in the next section.

Finally the expires directive allows you to set the Expires header conveniently. The expires directive takes the duration of time this cache will be valid. By setting it to 1M you're telling NGINX to cache the content for one month. You can also set this to 10m or 10 minutes, 24h or 24 hours, and so on.

Now to test out the configuration, sent a request for the the-nginx-handbook.jpg file from the server:

curl -I http://nginx-handbook.test/the-nginx-handbook.jpg

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Sun, 25 Apr 2021 15:58:22 GMT
# Content-Type: image/jpeg
# Content-Length: 19209
# Last-Modified: Sun, 25 Apr 2021 08:35:33 GMT
# Connection: keep-alive
# ETag: "608529d5-4b09"
# Expires: Tue, 25 May 2021 15:58:22 GMT
# Cache-Control: max-age=2592000
# Cache-Control: public
# Pragma: public
# Vary: Accept-Encoding
# Accept-Ranges: bytes

As you can see, the headers have been added to the response and any modern browser should be able to interpret them.

How to Compress Responses

The final optimization technique that I'm going to show today is a pretty straightforward one: compressing responses to reduce their size.

worker_processes auto;

events {
    worker_connections 1024;
}

http {
    include /env/nginx/mime.types;

    gzip on;
    gzip_comp_level 3;

    gzip_types text/css text/javascript;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-demo/static-demo;

        location ~* \.(css|js|jpg)$ {
            access_log off;

            add_header Cache-Control public;
            add_header Pragma public;
            add_header Vary Accept-Encoding;
            expires 1M;
        }
    }
}

If you're not already familiar with it, GZIP is a popular file format used by applications for file compression and decompression. NGINX can utilize this format to compress responses using the gzip directives.

By writing gzip on in the http context, you're instructing NGINX to compress responses. The gzip_comp_level directive sets the level of compression. You can set it to a very high number, but that doesn't guarantee better compression. Setting a number between 1 - 4 gives you an efficient result. For example, I like setting it to 3.

By default, NGINX compresses HTML responses. To compress other file formats, you'll have to pass them as parameters to the gzip_types directive. By writing gzip_types text/css text/javascript; you're telling NGINX to compress any file with the mime types of text/css and text/javascript.

Configuring compression in NGINX is not enough. The client has to ask for the compressed response instead of the uncompressed responses. I hope you remember the add_header Vary Accept-Encoding; line in the previous section on caching. This header lets the client know that the response may vary based on what the client accepts.

As an example, if you want to request the uncompressed version of the mini.min.css file from the server, you may do something like this:

curl -I http://nginx-handbook.test/mini.min.css

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Sun, 25 Apr 2021 16:30:32 GMT
# Content-Type: text/css
# Content-Length: 46887
# Last-Modified: Sun, 25 Apr 2021 08:35:33 GMT
# Connection: keep-alive
# ETag: "608529d5-b727"
# Expires: Tue, 25 May 2021 16:30:32 GMT
# Cache-Control: max-age=2592000
# Cache-Control: public
# Pragma: public
# Vary: Accept-Encoding
# Accept-Ranges: bytes

As you can see, there's nothing about compression. Now if you want to ask for the compressed version of the file, you'll have to send an additional header.

curl -I -H "Accept-Encoding: gzip" http://nginx-handbook.test/mini.min.css

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Sun, 25 Apr 2021 16:31:38 GMT
# Content-Type: text/css
# Last-Modified: Sun, 25 Apr 2021 08:35:33 GMT
# Connection: keep-alive
# ETag: W/"608529d5-b727"
# Expires: Tue, 25 May 2021 16:31:38 GMT
# Cache-Control: max-age=2592000
# Cache-Control: public
# Pragma: public
# Vary: Accept-Encoding
# Content-Encoding: gzip

As you can see in the response headers, the Content-Encoding is now set to gzip meaning this is the compressed version of the file.

Now if you want to compare the difference in file size, you can do something like this:

cd ~
mkdir compression-test && cd compression-test

curl http://nginx-handbook.test/mini.min.css > uncompressed.css

curl -H "Accept-Encoding: gzip" http://nginx-handbook.test/mini.min.css > compressed.css

ls -lh

# -rw-rw-r-- 1 vagrant vagrant 9.1K Apr 25 16:35 compressed.css
# -rw-rw-r-- 1 vagrant vagrant  46K Apr 25 16:35 uncompressed.css

The uncompressed version of the file is 46K and the compressed version is 9.1K, almost six times smaller. On real life sites where stylesheets can be much larger, compression can make your responses smaller and faster.

How to Understand the Main Configuration File

I hope you remember the original nginx.conf file you renamed in an earlier section. According to the Debian wiki, this file is meant to be changed by the NGINX maintainers and not by server administrators, unless they know exactly what they're doing.

But throughout the entire article, I've taught you to configure your servers in this very file. In this section, however, I'll who you how you should configure your servers without changing the nginx.conf file.

To begin with, first delete or rename your modified nginx.conf file and bring back the original one:

sudo rm /etc/nginx/nginx.conf

sudo mv /etc/nginx/nginx.conf.backup /etc/nginx/nginx.conf

sudo nginx -s reload

Now NGINX should go back to its original state. Let's have a look at the content of this file once again by executing the sudo cat /etc/nginx/nginx.conf file:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

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


#mail {
#    # See sample authentication script at:
#    # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
# 
#    # auth_http localhost/auth.php;
#    # pop3_capabilities "TOP" "USER";
#    # imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#    server {
#        listen     localhost:110;
#        protocol   pop3;
#        proxy      on;
#    }
# 
#    server {
#        listen     localhost:143;
#        protocol   imap;
#        proxy      on;
#    }
#}

You should now be able to understand this file without much trouble. On the main context user www-data;, the worker_processes auto; lines should be easily recognizable to you.

The line pid /run/nginx.pid; sets the process ID for the NGINX process and include /etc/nginx/modules-enabled/*.conf; includes any configuration file found on the /etc/nginx/modules-enabled/ directory.

This directory is meant for NGINX dynamic modules. I haven't covered dynamic modules in this article so I'll skip that.

Now inside the the http context, under basic settings you can see some common optimization techniques applied. Here's what these techniques do:

• sendfile on; disables buffering for static files.
• tcp_nopush on; allows sending response header in one packet.
• tcp_nodelay on; disables Nagle's Algorithm resulting in faster static file delivery.

The keepalive_timeout directive indicates how long to keep a connection open and the types_hash_maxsize directive sets the size of the types hash map. It also includes the mime.types file by default.

I'll skip the SSL settings simply because we haven't covered them in this article. We've already discussed the logging and gzip settings. You may see some of the directives regarding gzip as commented. As long as you understand what you're doing, you may customize these settings.

You use the mail context to configure NGINX as a mail server. We've only talked about NGINX as a web server so far, so I'll skip this as well.

Now under the virtual hosts settings, you should see two lines as follows:

##
# Virtual Host Configs
##

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

These two lines instruct NGINX to include any configuration files found inside the /etc/nginx/conf.d/ and /etc/nginx/sites-enabled/ directories.

After seeing these two lines, people often take these two directories as the ideal place to put their configuration files, but that's not right.

There is another directory /etc/nginx/sites-available/ that's meant to store configuration files for your virtual hosts. The /etc/nginx/sites-enabled/ directory is meant for storing the symbolic links to the files from the /etc/nginx/sites-available/ directory.

In fact there is an example configuration:

ln -lh /etc/nginx/sites-enabled/

# lrwxrwxrwx 1 root root 34 Apr 25 08:33 default -> /etc/nginx/sites-available/default

As you can see, the directory contains a symbolic link to the /etc/nginx/sites-available/default file.

The idea is to write multiple virtual hosts inside the /etc/nginx/sites-available/ directory and make some of them active by symbolic linking them to the /etc/nginx/sites-enabled/ directory.

To demonstrate this concept, let's configure a simple static server. First, delete the default virtual host symbolic link, deactivating this configuration in the process:

sudo rm /etc/nginx/sites-enabled/default

ls -lh /etc/nginx/sites-enabled/

# lrwxrwxrwx 1 root root 41 Apr 25 18:01 nginx-handbook -> /etc/nginx/sites-available/nginx-handbook

Create a new file by executing sudo touch /etc/nginx/sites-available/nginx-handbook and put the following content in there:

server {
    listen 80;
    server_name nginx-handbook.test;

    root /srv/nginx-handbook-projects/static-demo;
}

Files inside the /etc/nginx/sites-available/ directory are meant to be included within the main http context so they should contain server blocks only.

Now create a symbolic link to this file inside the /etc/nginx/sites-enabled/ directory by executing the following command:

sudo ln -s /etc/nginx/sites-available/nginx-handbook /etc/nginx/sites-enabled/nginx-handbook

ls -lh /etc/nginx/sites-enabled/

# lrwxrwxrwx 1 root root 34 Apr 25 08:33 default -> /etc/nginx/sites-available/default
# lrwxrwxrwx 1 root root 41 Apr 25 18:01 nginx-handbook -> /etc/nginx/sites-available/nginx-handbook

Before validating and reloading the configuration file, you'll have to reopen the log files. Otherwise you may get a permission denied error. This happens because the process ID is different this time as a result of swapping the old nginx.conf file.

sudo rm /var/log/nginx/*.log

sudo touch /var/log/nginx/access.log /var/log/nginx/error.log

sudo nginx -s reopen

Finally, validate and reload the configuration file:

sudo nginx -t

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

sudo nginx -s reload

Visit the server and you should be greeted with the good old The NGINX Handbook page:

If you've configured the server correctly and you're still getting the old NGINX welcome page, perform a hard refresh. The browser often holds on to old assets and requires a little cleanup.

How To Configure SSL and HTTP/2

HTTP/2 is the newest version of the wildly popular Hyper Text Transport Protocol. Based on Google's experimental SPDY protocol, HTTP/2 provides better performance by introducing features like full request and response multiplexing, better compression of header fields, server push and request prioritization.

Some of the notable features of HTTP/2 is as follows:

1. Binary Protocol - While HTTP/1.x was a text based protocol, HTTP/2 is a binary protocol resulting in less error during data transfer process.
2. Multiplexed Streams - All HTTP/2 connections are multiplexed streams meaning multiple files can be transferred in a single stream of binary data.
3. Compressed Header - HTTP/2 compresses header data in responses resulting in faster transfer of data.
4. Server Push - This capability allows the server to send linked resources to the client automatically, greatly reducing the number of requests to the server.
5. Stream Prioritization - HTTP/2 can prioritize data streams based on their type resulting in better bandwidth allocation where necessary.

If you want to learn more about the improvements in HTTP/2 this article by Kinsta may help.

While a significant upgrade over its predecessor, HTTP/2 is not as widely adapted as it should have been. In this section, I'll introduce you to some of the new features mentioned previously and I'll also show you how to enable HTTP/2 on your NGINX powered web server.

For this section, I'll be using the static-demo project. I'm assuming you've already cloned the repository inside /srv/nginx-handbook-projects directory. If you haven't, this is the time to do so. Also, this section has to be done on a virtual private server instead of a virtual machine.

For simplicity, I'll use the /etc/nginx/sites-available/default file as my configuration. Open the file using nano or vi if you fancy that.

nano /etc/nginx/sites-available/default

Update the file's content as follows:

server {
        listen 80;
        server_name nginx-handbook.farhan.dev;  

        root /srv/nginx-handbook-projects/static-demo;
}

As you can see, the /srv/nginx-handbook-projects/static-demo; directory has been set as the root of this site and nginx-handbook.farhan.dev has been set as the server name. If you do not have a custom domain set up, you can use your server's IP address as the server name here.

nginx -t

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

nginx -s reload

Test the configuration by executing nginx -t and reload the configuration by executing nginx -s reload commands.

Finally visit your server and you should be greeted with a simple static HTML page.

One of the pre-requisite to have HTTP/2 working on your server is to have a valid SSL certificate. Lets do that first.

How To Configure SSL

For those of you who may not know, an SSL certificate is what allows a server to make the move from HTTP to HTTPS. These certificates are issued by a certificate authority (CA). Most of the authorities charge a fee for issuing certificates but nonprofit authorities such as Let's Encrypt, issues certificates for free.

If you want to understand the theory of SSL in a bit more detail, this article on the Cloudflare Learning Center may help.

Thanks to open-source tools like Certbot, installing a free certificate is dead easy. Head over to certbot.eff.org link. Now select the software and system that powers your server.

I'm running NGINX on Ubuntu 20.04 and if you've been in line with this article, you should have the same combination.

After selecting your combination of software and system, you'll be forwarded to a new page containing step by step instructions for installing certbot and a new SSL certificate.

The installation steps for certbot may differ from system to system but rest of the instructions should remain same. On Ubuntu, the recommended way is to use snap.

snap install --classic certbot

# certbot 1.14.0 from Certbot Project (certbot-eff✓) installed

certbot --version

# certbot 1.14.0

Certbot is now installed and ready to be used. Before you install a new certificate, make sure the NGINX configuration file contains all the necessary server names. Such as, if you want to install a new certificate for yourdomain.tld and www.yourdomain.tld, you'll have to include both of them in your configuration.

Once you're happy with your configuration, you can install a newly provisioned certificate for your server. To do so, execute the certbot program with --nginx option.

certbot --nginx

# Saving debug log to /var/log/letsencrypt/letsencrypt.log
# Plugins selected: Authenticator nginx, Installer nginx
# Enter email address (used for urgent renewal and security notices)
#  (Enter 'c' to cancel): shovik.is.here@gmail.com

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Please read the Terms of Service at
# https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
# agree in order to register with the ACME server. Do you agree?
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# (Y)es/(N)o: Y

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Would you be willing, once your first certificate is successfully issued, to
# share your email address with the Electronic Frontier Foundation, a founding
# partner of the Let's Encrypt project and the non-profit organization that
# develops Certbot? We'd like to send you email about our work encrypting the web,
# EFF news, campaigns, and ways to support digital freedom.
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# (Y)es/(N)o: N
# Account registered.

# Which names would you like to activate HTTPS for?
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# 1: nginx-handbook.farhan.dev
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Select the appropriate numbers separated by commas and/or spaces, or leave input
# blank to select all options shown (Enter 'c' to cancel): 
# Requesting a certificate for nginx-handbook.farhan.dev
# Performing the following challenges:
# http-01 challenge for nginx-handbook.farhan.dev
# Waiting for verification...
# Cleaning up challenges
# Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
# Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Congratulations! You have successfully enabled
# https://nginx-handbook.farhan.dev
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# IMPORTANT NOTES:
#  - Congratulations! Your certificate and chain have been saved at:
#    /etc/letsencrypt/live/nginx-handbook.farhan.dev/fullchain.pem
#    Your key file has been saved at:
#    /etc/letsencrypt/live/nginx-handbook.farhan.dev/privkey.pem
#    Your certificate will expire on 2021-07-30. To obtain a new or
#    tweaked version of this certificate in the future, simply run
#    certbot again with the "certonly" option. To non-interactively
#    renew *all* of your certificates, run "certbot renew"
#  - If you like Certbot, please consider supporting our work by:

#    Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
#    Donating to EFF:                    https://eff.org/donate-le

You'll be asked for an emergency contact email address, license agreement and if you would like to receive emails from them or not.

The certbot program will automatically read the server names from your configuration file and show you a list of them. If you have multiple virtual hosts on your server, certbot will recognize them as well.

Finally if the installation is successful, you'll be congratulated by the program. To verify if everything's working or not, visit your server with HTTPS this time:

As you can see, HTTPS has been enabled successfully and you can confirm that the certificate is verified by Let's Encrypt authority. Later on, if you add new virtual hosts to this server with new domains or sub domains, you'll have to reinstall the certificates.

It's also possible to install wildcard certificate such as *.yourdomain.tld for some supported DNS managers. Detailed instructions can be found on the previously shown installation instruction page.

A newly installed certificate will be valid for 90 days. After that, a renewal will be required. Certbot does the renewal automatically. You can execute certbot renew command with the --dry-run option to test out the auto renewal feature.

certbot renew --dry-run

# Saving debug log to /var/log/letsencrypt/letsencrypt.log

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Processing /etc/letsencrypt/renewal/nginx-handbook.farhan.dev.conf
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Cert not due for renewal, but simulating renewal for dry run
# Plugins selected: Authenticator nginx, Installer nginx
# Account registered.
# Simulating renewal of an existing certificate for nginx-handbook.farhan.dev
# Performing the following challenges:
# http-01 challenge for nginx-handbook.farhan.dev
# Waiting for verification...
# Cleaning up challenges

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# new certificate deployed with reload of nginx server; fullchain is
# /etc/letsencrypt/live/nginx-handbook.farhan.dev/fullchain.pem
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Congratulations, all simulated renewals succeeded: 
#   /etc/letsencrypt/live/nginx-handbook.farhan.dev/fullchain.pem (success)
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The command will simulate a certificate renewal to test if it's correctly set up or not. If it succeeds you'll be congratulated by the program. This step ends the procedure of installing an SSL certificate on your server.

To understand what certbot did behind the scenes, open up the /etc/nginx/sites-available/default file once again and see how its content has been altered.

server {

    server_name nginx-handbook.farhan.dev;  

    root /srv/nginx-handbook-projects/static-demo;

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/nginx-handbook.farhan.dev/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/nginx-handbook.farhan.dev/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = nginx-handbook.farhan.dev) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;

    server_name nginx-handbook.farhan.dev;
    return 404; # managed by Certbot
}

As you can see, certbot has added quite a few lines here. I'll explain the notable ones.

server {
    # ...
    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    # ...
}

Like the 80 port, 443 is widely used for listening to HTTPS requests. By writing listen 443 ssl; certbot is instructing NGINX to listen for any HTTPS request on port 443. The listen [::]:443 ssl ipv6only=on; line is for handling IPV6 connections.

server {
    # ...
    ssl_certificate /etc/letsencrypt/live/nginx-handbook.farhan.dev/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/nginx-handbook.farhan.dev/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    # ...
}

The ssl_certificate directive is used for indicating the location of the certificate and the private key file on your server. The /etc/letsencrypt/options-ssl-nginx.conf; includes some common directives necessary for SSL.

Finally the ssl_dhparam indicates to the file defining how OpenSSL is going to perform Diffie–Hellman key exchange. If you want to learn more about the purpose of /etc/letsencrypt/ssl-dhparams.pem; file, this stack exchange thread may help you.

server {
    if ($host = nginx-handbook.farhan.dev) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;

    server_name nginx-handbook.farhan.dev;
    return 404; # managed by Certbot
}

This newly added server block is responsible for redirecting any HTTP requests to HTTPS disabling HTTP access completely.

How To Enable HTTP/2

Once you've successfully installed a valid SSL certificate on your server, you're ready to enable HTTP/2. SSL is a prerequisite for HTTP/2, so right off the bat you can see, security is not optional in HTTP/2.

HTTP/2 support for NGINX is provided by the ngx_http_v2_module module. Pre-built binaries of NGINX on most of the systems come with this module baked in. If you've built NGINX from source however, you'll have to include this module manually.

Before upgrading to HTTP/2, send a request to your server and see the current protocol version.

curl -I -L https://nginx-handbook.farhan.dev

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Sat, 01 May 2021 10:46:36 GMT
# Content-Type: text/html
# Content-Length: 960
# Last-Modified: Fri, 30 Apr 2021 20:14:48 GMT
# Connection: keep-alive
# ETag: "608c6538-3c0"
# Accept-Ranges: bytes

As you can see, by default the server is on HTTP/1.1 protocol. On the next step, we'll update the configuration file as necessary for enabling HTTP/2.

To enable HTTP/2 on your server, open the /etc/nginx/sites-available/default file once again. Find wherever it says listen [::]:443 ssl ipv6only=on; or listen 443 ssl; and update them to listen [::]:443 ssl http2 ipv6only=on; and listen 443 ssl http2; respectively.

server {

    server_name nginx-handbook.farhan.dev;  

    root /srv/nginx-handbook-projects/static-demo;

    listen [::]:443 ssl http2 ipv6only=on; # managed by Certbot
    listen 443 ssl http2; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/nginx-handbook.farhan.dev/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/nginx-handbook.farhan.dev/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = nginx-handbook.farhan.dev) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;

    server_name nginx-handbook.farhan.dev;
    return 404; # managed by Certbot
}

Test the configuration file by executing niginx -t and reload the configuration by executing nginx -s reload commands. Now send a request to your server again.

curl -I -L https://nginx-handbook.farhan.dev

# HTTP/2 200 
# server: nginx/1.18.0 (Ubuntu)
# date: Sat, 01 May 2021 09:03:10 GMT
# content-type: text/html
# content-length: 960
# last-modified: Fri, 30 Apr 2021 20:14:48 GMT
# etag: "608c6538-3c0"
# accept-ranges: bytes

As you can see, HTTP/2 has been enabled for any client supporting the new protocol.

How to Enable Server Push

Server push is one of the many features that HTTP/2 brings to the table. Which means the server can push files to the client without the client having to request for them. In a HTTP/1.x server, a typical request for static content may look like as follows:

But on a server push enabled HTTP/2 server, it may look like as follows:

On a single request for the index.html file the server responds with the style.css file as well, minimizing the number of requests in the process.

In this section, I'll use an open-source HTTP client named Nghttp2 for testing the server.

apt install nghttp2-client -y

# Reading package lists... Done
# Building dependency tree       
# Reading state information... Done
# The following additional packages will be installed:
#   libev4 libjansson4 libjemalloc2
# The following NEW packages will be installed:
#   libev4 libjansson4 libjemalloc2 nghttp2-client
# 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
# Need to get 447 kB of archives.
# After this operation, 1,520 kB of additional disk space will be used.
# Get:1 http://archive.ubuntu.com/ubuntu focal/main amd64 libjansson4 amd64 2.12-1build1 [28.9 kB]
# Get:2 http://archive.ubuntu.com/ubuntu focal/universe amd64 libjemalloc2 amd64 5.2.1-1ubuntu1 [235 kB]
# Get:3 http://archive.ubuntu.com/ubuntu focal/universe amd64 libev4 amd64 1:4.31-1 [31.2 kB]
# Get:4 http://archive.ubuntu.com/ubuntu focal/universe amd64 nghttp2-client amd64 1.40.0-1build1 [152 kB]
# Fetched 447 kB in 1s (359 kB/s)     
# Selecting previously unselected package libjansson4:amd64.
# (Reading database ... 107613 files and directories currently installed.)
# Preparing to unpack .../libjansson4_2.12-1build1_amd64.deb ...
# Unpacking libjansson4:amd64 (2.12-1build1) ...
# Selecting previously unselected package libjemalloc2:amd64.
# Preparing to unpack .../libjemalloc2_5.2.1-1ubuntu1_amd64.deb ...
# Unpacking libjemalloc2:amd64 (5.2.1-1ubuntu1) ...
# Selecting previously unselected package libev4:amd64.
# Preparing to unpack .../libev4_1%3a4.31-1_amd64.deb ...
# Unpacking libev4:amd64 (1:4.31-1) ...
# Selecting previously unselected package nghttp2-client.
# Preparing to unpack .../nghttp2-client_1.40.0-1build1_amd64.deb ...
# Unpacking nghttp2-client (1.40.0-1build1) ...
# Setting up libev4:amd64 (1:4.31-1) ...
# Setting up libjemalloc2:amd64 (5.2.1-1ubuntu1) ...
# Setting up libjansson4:amd64 (2.12-1build1) ...
# Setting up nghttp2-client (1.40.0-1build1) ...
# Processing triggers for man-db (2.9.1-1) ...
# Processing triggers for libc-bin (2.31-0ubuntu9.2) ...

nghttp --version

# nghttp nghttp2/1.40.0

Lets test by sending a request to the server without server push.

nghttp --null-out --stat https://nginx-handbook.farhan.dev/index.html

# id  responseEnd requestStart  process code size request path
#  13      +836us       +194us    642us  200  492 /index.html

nghttp --null-out --stat --get-assets https://nginx-handbook.farhan.dev/index.html

# id  responseEnd requestStart  process code size request path
#  13      +836us       +194us    642us  200  492 /index.html
#  15     +3.11ms      +2.65ms    457us  200  45K /mini.min.css
#  17     +3.23ms      +2.65ms    578us  200  18K /the-nginx-handbook.jpg

On the first request --null-out means discard downloaded data and --stat means print statistics on terminal. On the second request --get-assets means also download assets such as stylesheets, images and scripts linked to this files. As a result you can tell by the requestStart times, the css file and image was downloaded shortly after the html file was downloaded.

Now, lets enable server push for stylesheets and images. Open /etc/nginx/sites-available/default file and update its content as follows:

server {

    server_name nginx-handbook.farhan.dev;

    root /srv/nginx-handbook-projects/static-demo;

    listen [::]:443 ssl http2 ipv6only=on; # managed by Certbot
    listen 443 ssl http2; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/nginx-handbook.farhan.dev/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/nginx-handbook.farhan.dev/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location = /index.html {
        http2_push /mini.min.css;
        http2_push /the-nginx-handbook.jpg;
    }

    location = /about.html {
        http2_push /mini.min.css;
        http2_push /the-nginx-handbook.jpg;
    }

}
server {
    if ($host = nginx-handbook.farhan.dev) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;

    server_name nginx-handbook.farhan.dev;
    return 404; # managed by Certbot
}

Two location blocks have been added to exactly match /index.html and /about.html locations. The http2_push directive is used for sending back additional response. Now whenever NGINX receives a request for one of these two locations, it'll automatically send back the css and image file.

Test the configuration by executing nginx -t and reload the configuration by executing nginx -s reload commands.

nginx -t

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

nginx -s reload

Now send another request to the server using nghttp and do not include --get-assets option.

nghttp --null-out --stat https://nginx-handbook.farhan.dev/index.html

# id  responseEnd requestStart  process code size request path
#  13     +1.49ms       +254us   1.23ms  200  492 /index.html
#   2     +1.56ms *    +1.35ms    212us  200  45K /mini.min.css
#   4     +1.71ms *    +1.39ms    318us  200  18K /the-nginx-handbook.jpg

As you can see, although the assets were not requested, the server has sent them to the client. Looking at the time measurements, process time has gone down and the three responses ended almost simultaneously.

This was a very simple example of server push but depending on the necessities of your project, this configuration can become much complex. This article by Owen Garrett on the official NGINX blog can help you with more complex server push configuration.

Conclusion

I would like to thank you from the bottom of my heart for the time you've spent on reading this article. I hope you've enjoyed your time and have learned all the essentials of NGINX.

Apart from this one, I've written full-length handbooks on other complicated topics available for free on freeCodeCamp.

These handbooks are part of my mission to simplify hard to understand technologies for everyone. Each of these handbooks takes a lot of time and effort to write.

If you've enjoyed my writing and want to keep me motivated, consider leaving starts on GitHub and endorse me for relevant skills on LinkedIn. I also accept sponsorship so you may consider buying me a coffee if you want to.

I'm always open to suggestions and discussions on Twitter or LinkedIn. Hit me with direct messages.

In the end, consider sharing the resources with others, because

Sharing knowledge is the most fundamental act of friendship. Because it is a way you can give something without loosing something. — Richard Stallman

Till the next one, stay safe and keep learning.

Servers listen for requests from clients, which are other computers or devices. When a server hears a request, it reads it and responds by sending data back to the client.

For example, when you enter freecodecamp.org in the address bar, our server hears the request from your browser. Our server reads what page you want and looks for all the data (HTML, CSS, JavaScript, and photos) for that page. Then when everything is ready, it sends that data back to your browser.

Almost any computer with the correct software can act as a server. But the servers behind many popular websites and services are often built with special hardware. This allows the servers to handle many requests at once, and stay online for long periods of time.

Servers play a vital role in organizations. Their primary function is to provide both data and computational services.

Because of the critical role they play, servers hold confidential organizational data and information. Information is like gold nowadays, and hackers are gold miners.

An insecure server is vulnerable to all sorts of security threats and data breaches.

Security vulnerabilities can lead to the loss of critical data or loss of capability and control that can jeopardize the whole organization.

If you do not secure your servers, then you are treading a dangerous path.

You might not know how to secure your servers properly. This article will explain some of the server security tips that you can use to secure your servers.

Server Security Best Practices

1. Constantly Upgrade the Software and the Operating System

Constantly Upgrade the Software and the Operating System

In server security, staying up to date on all software and operating system-related security fixes is essential. Server systems and software technologies are so complicated that some of the security vulnerabilities they carry can easily go unnoticed.

Because of this, security vulnerabilities commonly exist in both old and freshly updated software versions. Also, hackers always try to develop new and innovative ways to gain unauthorized entries into a system.

Fortunately, vendors and cybersecurity experts are constantly working to ensure that their software and operating systems are as secure as possible. Once they discover a security loophole, they will typically move quickly to have the loophole fixed.

Once that's done, they will release a more secure and upgraded version of their operating system or software. For your server's security, you should immediately install the update once the vendor has tested and released it on the market.

Even though most vendors act speedily to address security vulnerabilities, there is always a gap between the time the security vulnerability is discovered, the time it takes to fix it, and the time it takes you to install the new update.

This gap can give hackers an upper hand since they can easily breach your servers before you make the update.

To keep this gap as small as possible, always remain vigilant and aware of any new developments as far as your servers' security is concerned. You should also be mindful of the immediate measures you can take to ensure that you are not affected by the vulnerable software.

For instance, uninstalling the software could be an essential thing to do. Lastly, you should install the new update right away once it has been released. Installing the secure operating system and software version can help reduce your vulnerability.

2. Configure Your Computer to File Backups

Configure Your Computer to File Backups

You should always keep a file backup and have a restoration strategy. You never know when a hacker will succeed in breaching your servers.

When such a breach happens, a backup file could be your savior.

Regularly backing up your data allows you to restore all the information resources that your server held before the data breach took place.

Therefore, for the sake of your data, you should ensure that you regularly undertake the data backup.

When developing a backup plan, make sure that you do a thorough analysis of the following:

• the cost of the backup plan,
• its efficiency and speed,
• the effort required to restore your data after a data breach,
• the speed of the backup process, and
• the amount of disc space that you need to store the data.

You also should carefully consider the location where you store your backup files.

You can choose to keep the files either locally or on on the cloud, which is a safer approach.

3. Set up Access Limitations to Your Computers files

Access Limitations to Your Computers files

Most operating systems will give users the option to specify access privileges. For the safety of your servers, I advise that you be as restrictive as possible.

A user can specify access privileges to directories, networks, files, and other server elements. Access controls can reduce both deliberate and unintended server security breaches.

For instance, limiting read access can help you protect confidential and private information. Similarly, restricting who can modify files and data will help maintain the integrity of the files.

Not all employees should be given access to all the resources of your organization. Applying the principle of the least privilege is an excellent move in securing your servers.

Those who have no business with server resources or do not need them to fulfill their job requirements should not have access to those resources. Some of the worst data breaches have been organized and executed by people within the organization who had access to crucial data and information.

A 2019 Insider Threat Report by Verizon places careless and malicious workers as the top actors in insider cybersecurity threats. Limiting access, therefore, can help protect your servers from insider attacks.

4. Install SSL Certificates

Install SSL Certificates

Secure Socket Layer certificates are security protocols that guard the communication between two systems over the internet.

The Secure Socket Layer is a crucial element of server security. You need to ensure that any communication or data transfers between your server and clients' browsers or other servers are encrypted.

SSL certificates scramble data in transit so that sensitive and confidential information such as health details, credit card details, and financial records remain secure. A hacker who succeeds in accessing the data cannot decipher its meaning.

Only the intended recipient who has the right key to decrypt the information will understand its meaning.

Apart from just encrypting the communication between your servers and other parties, SSL certificates also play a critical role in user authentication.

SSL certificates can authenticate different systems to their particular owners. The certificate, therefore, helps establish your authority. To strengthen your security, you should get and install an SSL certificate.

5. Use Virtual Private Networks (Private Networking)

Use Virtual Private Networks (Private Networking)

Private networks are based on Internet Protocol address space. A VPN is said to be private because no Internet Protocol packets addressed are transmitted via a public network.

A VPN will allow you to create a connection between different computer devices located in different places. It lets you to carry out operations on your servers in a secure manner.

You can exchange information with other servers on the same account without compromises from outside. To ensure that your server is safe, you should set up a Virtual Private Network.

6. Server Password Security

Server Password Security

When it comes to server security, make sure you use password best practices. The first step is to develop clear password policies and rules that all members using the server should follow.

You should enforce minimum character length for passwords, set password complexity guidelines, enable session timeout for inactivity, and use a multiple-factor authentication strategy.

It's also useful to have a clear password expiration policy. Passwords should only be allowed to last a few weeks or months. It's best to encourage all users to implement safe password storage to avoid passwords landing in unsafe hands.

7. Use Firewall Protection

Use Firewall Protection

Firewalls are a must-have to ensure that your servers are safe. They filter incoming and outgoing traffic to allow only specific services and lockout unsafe ones.

There are a few different classifications of firewalls. The first group deals with the public services that anyone on the internet anonymously accesses. The second is the private services that a select group of authorized accounts can access. The last is the internal services that require no exposure to the outside world.

You should restrict access to these services depending on which group fits the situation. You should configure your server to refuse all accesses except those that are mandatory to your servers.

Summing up

After reading this article and implementing the server security measures I explained, you should feel more confident about your server's security.

As a best practice, you should implement these security measures when you first set your server up. It also helps if you implemented more than one of these measures. As a general rule, the more security measures you have, the safer your server will become.

In this tutorial, we are going to learn everything we need to know before deploying a Node app to a production server.

We will start by renting a server on Digital Ocean. Then we'll configure this server, connect to it, install Nginx and configure it, pull or create our Node app, and run it as a process.

As you can see, there is a lot to do and it will be an action-packed tutorial. So let's get started without wasting any time.

You should have some basic knowledge on how the Terminal works and how to work in Vi/Vim before getting started. If you are not familiar with basic commands, I would advise you to read up on them a bit.

I will run the commands in MacOS. If you want to follow this tutorial in Windows, you can use Powershell or some other Unix emulator of your choice.

Although I will use Node.js as the platform of our example application, most of the steps are the same for any web application.

Why Digital Ocean?

I choose Digital Ocean because it is cheap and the interface is really easy to use, compared to the likes of AWS. Also, a $100 credit is included in the GitHub student pack so you do not have to pay anything for a couple of months. It is ideal for deploying a course or hobby project.

It has a concept called Droplets, which is basically your share of a server. You can think of the server as an apartment in which you own or rent a flat.

Droplets work with the help of Virtual Machines which run on the server. So a Droplet is your Virtual Machine on a shared server. Since it is a VM, its CPU and memory share can be easily increased, usually by throwing more money at your provider.

How to Create a Digital Ocean Project

I am assuming that you have already signed up and logged in to Digital Ocean before proceeding. We should first create a project that will contain our droplets. Let's click on the new project button on the left side menu. It will ask you to name your project.

Enter whatever name you want. It will also ask you if you want to move any resources, but for now just click Skip – we will create the droplet later.

How to Create a Droplet on Digital Ocean

Let's create our droplet by clicking the Get Started button.

After clicking the button, it will ask us to choose a VM image.

Choosing an Image

On this page, I will select Ubuntu 20.04 since it is the latest LTS version at the time I am writing this post. LTS means "Long Term Support". It is best to go with the LTS version for actual projects, because the provider guarantees that it will be supported and maintained for a long time. This means you will not have problems in the long run.

I have chosen Ubuntu, and would recommend it to you since it is the most commonly used Linux distribution. This means it's also the easiest to find answers to your future questions.

You can also choose to have a Dedicated CPU if you need it. If you are building your own startup or any business project, I would recommend reading this post which contains detailed instructions about how to pick the right option for you.

I will go with the cheapest option in this case.

Then you will need to select a Datacenter region. You should pick the one that is closest to you to minimize network delay.

Select a Datacenter

Next let's select SSH Keys as the Authentication Method, since it is much more secure than basic password authentication.

Authentication Method

To connect to the server we need to generate a new SSH key on our own device and add it to Digital Ocean.

How to Generate an SSH Key

I will generate the key on my macOS device. If you are using Windows you can refer to this article. Open your terminal and move into the ssh folder:

cd ~/.ssh

Then create your SSH key:

ssh-keygen

If your computer says that it does not know this command, you should install it via brew.

It will ask you to name the file and enter a passphrase. Do not enter a name, just press enter and go with the defaults. You should have these files generated. I have named mine digital-ocean-ssh in this screenshot, so do not get confused by that.

❯ lsid_dsa      id_rsa      known_hosts

Our public key is the id_dsa and the id_rsa is our private key. If you forget which one is private, you can always print one of them to see.

How to Add Your SSH Key to Digital Ocean

Now we want to copy our public key and upload it to Digital Ocean so they will know which key to use in authentication.

Copy this whole key including the ssh-rsa part.

Click on "New SSH Key":

Paste the key in the textbox that appears after you click the button and you should see your SSH key.

How to Connect to the Server

We will use the terminal to connect to our server with SSH. You can also take a look at Termius for a nice interface if you want.

Run this command in your terminal after replacing the IP_ADDRESS with your server's IP address (you can look it up from Digital Ocean's panel).

ssh root@IP_ADDRESS

If everything goes well, now you should be in the server's terminal. We have successfully connected to server. If there is any error, you can debug it by running the command with the "-v" option or "-vv" for even more verbosity.

How to Set Up the Server

We need to do some initial setup before deploying the Node app to the server.

Update and Upgrade Software

We want to update the server's software to make sure we are using the latest versions.

Many servers are vulnerable to attacks because they are using older versions of software with known vulnerabilities. Attackers can search for the vulnerabilities in those software and try to exploit them in order to gain access to your server.

You can update Ubuntu's software using the "apt update" command.

apt updateHit:1 https://repos.insights.digitalocean.com/apt/do-agent main InReleaseGet:2 http://mirrors.digitalocean.com/ubuntu focal InRelease [265 kB]      Hit:3 http://mirrors.digitalocean.com/ubuntu focal-updates InRelease                Get:4 http://security.ubuntu.com/ubuntu focal-security InRelease [109 kB]Hit:5 http://mirrors.digitalocean.com/ubuntu focal-backports InReleaseFetched 374 kB in 1s (662 kB/s)                          Reading package lists... DoneBuilding dependency tree       Reading state information... Done96 packages can be upgraded. Run 'apt list --upgradable' to see them.

If you read the message, it says that "96 packages can be upgraded". We have installed the new software packages but we have not upgraded our software to those versions yet.

To do that, let's run another command:

apt upgrade

Type y when it prompts you and it will upgrade the software.

Create a User

We have connected to the server as the root user (the user with the highest privileges). Being the root is dangerous and can open us up to vulnerabilities.

Therefore we should create a new user and not run commands as root. Replace $username with a username of your choice.

whoamiroot

adduser $username

You need to enter a password for the user. After that point, it will ask a bunch of questions, so just input y until the prompting is over.

The new user has been created but we also need to add this new user to the "sudo" group so that we can perform any action we need.

usermod -aG sudo $USERNAME

We add group with the -aG (add group) option, and we add the group name sudo to our username.

We are still root, so let's switch our user to the newly created user, using the su (switch user) command.

su $USERNAME

After this point, if you run whoami command, you should see your username. You can confirm the existence of the sudo group by running this command:

sudo cat /var/log/auth.log

Only superusers can view this file and OS will ask for your user password after you run this command.

Copy the SSH Key

We have successfully created the user but we have not enabled SSH login for this new user yet.

Therefore, we have to copy the public key that we previously created on our local computer and paste it into this user's SSH folder so SSH can know which key should it use to authenticate our new user.

mkdir -p ~/.ssh

The -p argument creates the directory if it does not exist.

vi ~/.ssh/authorized_keys

We will use vi or vim to create a file and call it authorized_keys.

Copy your public key (id_dsa file) then press "i" to go into insert mode. Then just paste it into this file with CMD + V.

Press esc to quit insert mode, type :wq to save and quit.

If you have any problems about using Vim-Vi, you can check out one of the many tutorials that explain how to use it.

Connect to Server as New User

Now we should be able to connect to the server without any problems using ssh. You can use this command to connect, just remember to insert your username and IP_ADDRESS.

ssh $USERNAME@IP_ADDRESS

If you are having any problems at this point, you should just delete the droplet and start over. It does not take a lot of time to start over but debugging server problems can be difficult.

How to Disable Root Login

It is a good practice to disable Root login as a security precaution, so let's do that now.

It can be useful to change the file permission just in case so that we won't run into problems regarding permissions in the future.

chmod 644 ~/.ssh/authorized_keys

Let's now open our sshd_config file:

sudo vi /etc/ssh/sshd_config

Find this line and change the yes to no in the same way we did earlier with vi.

PermitRootLogin no

Save and quit vi.

How to Install Node.js and Git

We can now go ahead and install Node.js and Git:

sudo apt install nodejs npm

sudo apt install git

We are now ready to create a Node app and run it. You can either pull your Node project from Github or create a Node app here just to test if it works.

Move to a directory of your choice and create an "app.js" file:

sudo vi app.js

You can paste the following snippet into your app.js file:

const express = require('express');const app = express();const port = 3000;app.get('/', (req, res) => {        res.send('Hello World');});app.listen(port, () => console.log(`Example app listening on port ${port}!`));

Now we can run it with the command:

node app.js

You should see "Example app listening on port 3000!" on your terminal.

We can confirm that it is working by sending a request to our server:

GET http://IP_ADDRESS:3000/

Send this request either from an HTTP client like Postman or your browser and you should see the "Hello World" message.

At this point, you should notice that something is wrong: Regular users do not know how to send requests to port 3000.

We should redirect the requests that come to our web server from our IP to port 3000. We can accomplish this with the help of Nginx.

How to Install and Configure Nginx

We will use Nginx as a Reverse Proxy to redirect the requests to our Node app.

Nginx as a Reverse Proxy

Let's install Nginx:

sudo apt install nginx

Start the Nginx service:

sudo service nginx start

We can test to see if it is working by sending a request to our server's IP address from the browser. Type your server's IP address to your browser and you should see this:

It is important to know that Nginx serves from "/var/www/html" by default and you can find this HTML file in that directory as well.

I also advise you to create a folder under "/var/www", call it app, and move your Node app to that folder so it will be easy to find.

How to Configure the Nginx Reverse Proxy

We will edit the Nginx config file to configure a reverse proxy:

sudo vi /etc/nginx/sites-available/default

In this file you need to find the location / block and change it as follows:

location / {                # First attempt to serve request as file, then                # as directory, then fall back to displaying a 404.                proxy_pass http://127.0.0.1:3000/;        }

The proxy_pass directive proxies the request to a specified port. We give the port that our Node application is running on.

Let's restart Nginx so the changes can take effect:

sudo service nginx reload

After this step, we should be able to see the message when we send a request to our server. Congratulations, we have completed the minimum number of steps to deploy a Node app!

But I still advise you to complete the following bonus step as well, as I believe it's quite important.

If you can't see the hello world message, you can check if your app and Nginx are running and restart them.

How to Run your App as a Process

We do not want to start our application manually every time something goes wrong and our app crashes. We want it to restart on its own. Also, whenever the server starts, our app should start too.

To make this happen, we can use PM2. Let's install PM2 and configure it.

sudo npm i -g pm2

We are installing pm2 globally by using the "-g" option so that it will be accessible from every folder.

pm2 start app.js

This makes sure that the app will restart if it exits due to an error.

Let's save the current process list.

pm2 save

We also need to convert it to a daemon that runs whenever the system starts:

pm2 startup systemd

As a reminder, in this tutorial, I'm using the commands for Ubuntu. If you are using any other Linux distro, you should replace systemd in this command.

We can confirm that the service is getting restarted by rebooting the server and sending a request without running app.js by hand:

sudo reboot

After sending a request as we did earlier, you should be able to see the hello world message.

Conclusion

In this tutorial we started from scratch, rented a server for ourselves, connected to it, and configured it in a way that it serves our Node.js app from port 80.

If you have followed along and were able to complete all steps, congratulations! You can be proud of yourself, as this was not the easiest topic :). I hope that you have learned a lot. Thank you for your time.

I am planning to explore this topic further by connecting the server to a domain name, then connecting it to CircleCI for continuous integration. I'll also go through the required steps to make your Node.js/React app production ready. This post had already gotten long enough, though, so those topics are reserved for another post :)

If you have enjoyed reading and want to get informed about my future posts, you can subscribe to my personal blog. You can see my previous posts there if you are interested in reading more. I usually write about web development-related topics.

Every resource used on the internet has a media type, also known as a MIME type which stands for Multipurpose Internet Mail Extension. This information is necessary for transactions between server and client.

The browser needs to know the media type of resources sent to it so that it can handle them properly.

The same goes for the server. It needs to know the type of resources sent to it for accurate parsing and processing.

Where is the Content-Type declared?

The media type of any resource is declared in the Content-Type property of the request header (on the client, when making a request to the server) or in the response header (on the server, when sending a response).

Without explicitly declaring the content type of a resource, the client may attempt to automatically detect the type, but the result may not be accurate. This is why it's important to explicitly declare it.

Media Types

Media types exist in various forms. They are categorized into various groups:

• application
• audio
• font
• example
• image
• message
• model
• multipart
• text
• and video

These categories also have their types. For example, application/json is a type under application and text/html is a type under text.

You can find a complete list of media types in the IANA (a body that coordinates some of the key elements on the internet) media types.

All these types cover various data types like text, audio, images, HTML, and many more types that are used across the internet.

The browser needs to know the media type of a resource

As I mentioned above, the browser needs to know what type of content it receives. Here's an example to illustrate that.

The following code is a Node server that serves an HTML file:

const http = require("http");
const fs = require("fs");
const path = require("path");

const server = http.createServer(function (req, res) {
    const filePath = path.join(__dirname, "index.html");
    var stat = fs.statSync(filePath);

    res.writeHead(200, {
        "Content-Type": "text/css",
        "Content-Length": stat.size,
    });

    const readStream = fs.createReadStream(filePath);
    readStream.pipe(res);
});

server.listen(5000);

console.log("Node.js web server at port 5000 is running..");

Do not worry about the specifics of the code. All you're concerned with is the index.htm file we're serving and that the Content-Type is text/css.

Here's the content of index.html:

<h1>Homepage</h1>

Of course, an HTML document is different from a CSS file. Here's the result on localhost:5000 when the server is started:

You can also confirm the response gotten by checking the headers in the network tab of the DevTools.

Here's the result on a Chrome browser:

The browser got the content as a CSS type, therefore, it tried treating it as CSS.

Also, note that full knowledge of the type of content gotten by the browser also reduces security vulnerabilities as the browser knows security standards to put in place for that data.

Now that you understand the concept of MIME types and their importance, let's head over to JSON.

The Correct Content-Type for JSON

JSON has to be correctly interpreted by the browser to be used appropriately. text/plain was typically used for JSON, but according to IANA, the official MIME type for JSON is application/json.

This means when you're sending JSON to the server or receiving JSON from the server, you should always declare the Content-Type of the header as application/json as this is the standard that the client and server understand.

Conclusion

As stated above, the server (just like the browser) needs to know the type of data sent to it, say, in a POST request. That's the reason forms with files usually contain the enctype attribute with a value of multipart/form-data.

Without encoding the request this way, the POST request won't work. Also, once the server knows the type of data it has gotten, it then knows how to parse the encoded data.

In this article, we looked at what MIME types are and their purpose. Also, we looked at the official content type for JSON. I hope you now know why it's important to declare resource types when used across the internet.

If you've been online for any amount of time, no doubt you've seen the somewhat vague 503 Service Unavailable error.

In this article we'll go over HTTP status codes, what the 503 error means, and some possible ways to solve it – both for a site you're trying to visit and for your own site.

An overview of HTTP status codes

Servers that host web pages listen for requests from web browsers or devices, also known as clients. The server then uses a bunch of different status codes to communicate back.

These status codes are organized into different classes, which is indicated by the first number of the status code:

• 1xx: Information – the server is still processing the request
• 2xx: Success – the request succeeded and the server responds with the page or resource
• 3xx: Redirection – the page or resource has moved and server will respond with its new location
• 4xx: Client error – there is an error in the request from the browser or device
• 5xx: Server error – there is an error with the server

The last two digits of each HTTP status code represent a more specific status for each class. For example, 301 means that a page or resource has moved permanently, while 302 means the move is temporary.

Check out this page for a list of common HTTP status codes and their meaning: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Most status codes go by totally unnoticed, which is fine because it means everything is working. It's only when you get to the 4xx-5xx range that you might notice a status code because you'll see a page like this:

A typical 503 error page – Source: Stack Overflow

Now that you have a basic understanding of HTTP status codes, let's dig a bit deeper into the 503 Service Unavailable error.

What does the 503 error code mean?

As mentioned above, 5xx status codes mean there's a problem with the server itself.

A 503 Service Unavailable error means that the page or resource is unavailable. There are many reasons why a server might return a 503 error, but some common reasons are maintenance, a bug in the server's code, or a sudden spike in traffic that causes the server to become overwhelmed.

The message that's sent with the 503 error can vary depending on server it's coming from, but here are some of the common ones you'll see:

• 503 Service Unavailable
• 503 Service Temporarily Unavailable
• HTTP Server Error 503
• HTTP Error 503
• Error 503 Service Unavailable
• The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Source

Whatever the reason for the 503 error, it's usually temporary – the server will restart, traffic will die down, and the issue will resolve itself.

How to solve the 503 Status Unavailable error

When trying to solve a 503 error, there are two general camps.

The first is where you're an end user, and you're trying to visit a site that you don't own. In the second, you own the site, and it's throwing 503 errors to people who are trying to visit.

The method to solve 503 errors is different depending on which group you fall into. Let's take a look at some things you can do as an end user if you see a 503 error.

How to solve a 503 Status Unavailable error as an end user

Since 5xx status codes mean that the error is on the server-side, there isn't a lot you can do directly.

Even though 503 errors are usually temporary, there are some things you can do while you wait.

#1: Refresh the page

Sometimes the error is so temporary that a simple refresh is all it takes. With the page open, just press Ctrl - R on Windows and Linux, or Cmd - R on macOS to refresh the page.

#2: See if the page is down for other people

The next thing you can do is use a service like Is It Down Right Now? or Down For Everyone Or Just Me to see if other people are getting the same error.

Just go to either of those sites and enter in the URL for the page you're trying to visit.

The service will ping the URL you entered to see if it gets a response. Then it'll show you some cool stats and graphs about the page:

Checking freeCodeCamp on Is It Down Right Now?

If you scroll down a bit you'll see some comments from other people. Often people will give their general location and other data, so this can be a good way to determine if the error is just affecting certain regions or specific devices.

#3: Restart your router

Sometimes the issue has to do with a DNS server failure.

DNS stands for Domain Name System, and they basically act as translators between IP addresses and human readable URLs.

For example, you can visit Google by entering its long IP address directly (172.217.25.206), or you can just enter in the URL, www.google.com.

It's a DNS, often hosted on a server, that handles all that behind the scenes.

All of that is to say, many routers cache responses from DNS servers (www.google.com <==> 172.217.25.206). But sometimes this cache can get corrupted and cause errors.

An easy way to reset or "flush" the cache is to restart your router. Just unplug your router for about 5 seconds, then plug it back in again.

It should restart after a minute and all of your devices should reconnect automatically. Once they do, try visiting the site again.

How to solve a 503 Status Unavailable error as the site's owner

If you are the owner/developer of the site that's returning 503 errors, there's a bit more you can do to diagnose and resolve the issue.

Here are some general tips to get you started:

#1: Restart the server

Development is tough – even a simple static page can have so many moving parts that it can be difficult to pin down what's causing the 503 error.

Sometimes the best thing to do is to restart the server and see if that fixes the issue.

Source: imgflip

The exact method of restarting your server can vary, but usually you can access it from your provider's dashboard or by SSH'ing into the server and running a restart command.

The server should restart after a couple of minutes. If you've configured everything to run automatically on boot, you can visit your site and see if it's working.

#2: Check the server logs

The next thing to do is check the logs.

The location of the server logs can vary depending on what service you're running, but they're often found in /var/log/....

Take a look around that directory and see if you can find anything. If not, check the manual for your programs by running man program_name.

#3: Check if there's ongoing automated maintenance

Some service providers offer automated package updates and maintenance. Normally this is a good thing – they usually occur during downtime, and help make sure everything is up-to-date.

Occasionally 503 errors are due to these scheduled maintenance sessions.

For example, some hosting providers that specialize in WordPress hosting automatically update WP whenever there's a new release. WordPress automatically returns a 503 Service Unavailable error whenever it's being updated.

Check with your service providers to see if the 503 error is being caused by scheduled maintenance.

#4: Check your server's firewall settings

Sometimes 503 Service Unavailable errors are cause by a misconfigured firewall where connections can get through, but fail to get back out to the client.

Your firewall might also need special settings for a CDN, where multiple connections from a small handful of IP addresses might be misinterpreted as a DDoS attack.

The exact method of adjusting your firewall's settings depends on a lot of factors. Take a look at your pipeline and your service provider's dashboards to see where you can configure the firewall.

#5: Check the code

Bugs, like errors, happen. Try as you might, it's impossible to catch them all. Occasionally one might slip through and cause a 503 error.

If you've tried everything else and your site is still showing a 503 Service Unavailable error, the cause might be somewhere in the code.

Check any server-side code, and pay special attention to anything having to do with regular expressions – a small regex bug is what caused a huge spike in CPU usage, rolling outages, and about three days of panic for us at freeCodeCamp.

Hopefully you'll be able to track down the culprit, deploy a fix, and everything will be back to normal.

In summary

That should be everything you need to know about 503 Service Unavailable errors. While there's usually not much you can do when you see a 503 error, hopefully some of these steps will help the next time you encounter one.

Stay safe, and happy refreshing-until-it-works :)

Have you ever been traveling and couldn't get the same shows you normally watch back home on Hulu? Or have you noticed that some websites are blocked or you can't access certain services while you're connected to different Wi-Fi networks? That's likely due to a proxy being in place.

What is a proxy server?

A proxy server, or just proxy for short, is like having another computer that your internet requests get sent to before going to the real website. It's a server that takes all of the information you've sent out, like a request to buy new shirts on H&M, and routes it through a different IP address.

That's what makes a proxy so powerful. They can make all of your internet activity appear as if it's coming from a completely different location.

Companies use them for security and network performance purposes, individuals use them for privacy concerns, and there's also some cool functionality you can tap into when using proxy servers for your internet browsing that we'll talk about later.

A proxy can be physically located anywhere. You can set up a proxy on your home computer or you can deploy one to the cloud. The main thing that matters is that the proxy has the configurations you need for the functionality you want.

Just remember that a proxy acts like a fancy IP address filter. Similar to filters, there are different kinds of proxies and they all have their specific uses.

To get started, let's talk about the most common kind of proxy and how it works, the forward proxy.

How a proxy works

When you hear or see people talking about proxies, they're most likely referring to forward proxies. These are the most common types of proxy because they easily handle what most people need. Forward proxies act as the middleman between your requests and the server you're trying to connect to.

The way a proxy works is first you make a request, for example you try to go GitHub. So you type in the URL and hit enter. With a proxy, instead of connecting you directly to GitHub with your computer's IP address, your request gets intercepted by the proxy.

Then the proxy takes your request, updates it, and sends it from its own IP address. This can completely remove your IP address and identifying information from the request to the GitHub server.

One of the ways that proxies handle changing your request is directly in the request headers it sends to the server. A proxy request can set headers like Forwarded and Via in the original request before it sends the message to the server you're trying to get information from.

Once the proxy has updated the information from your request, it will send your reformatted request to the GitHub server. That server now thinks your request has come from a different location and it will send the data you wanted back through that location.

Next the proxy takes the data from the GitHub server and does any checks it has been configured to do with that data. It could check for any malicious scripts or other security issues. Then it finally sends the data back to your computer and your page loads.

A proxy server isn't necessarily limited to one user at a time. There can be multiple people sending requests through the same proxy and they can all share the same benefits. There are plenty of reasons you might use a proxy, even if it's a shared one.

Why you would use a proxy

Now that you know what a proxy is, it's good to know some of the common use cases for them.

• You can increase network security by encrypting requests
  ○ Prevent hackers from intercepting sensitive information
  ○ Block malware sites from your real network
• You can lower the amount of network traffic by caching sites
  ○ Cache websites so that only one request to the site is made no matter how many users are on the proxy
• You can control how people use the internet
  ○ Block specific domains
  ○ Monitor and log all web requests
• You can get around blocks set up by companies and countries
  ○ Access content from a different country
  ○ Get around corporate firewalls

This isn't a comprehensive list of everything you can do with proxies, but I also wanted to include some of the other benefits that don't quite fall under the typical categories.

• You always have cookies blocked
• You always have ads blocked
• You can access the deep web
• It removes any search tailoring or tracking your previous searches
• You can scrape data
• You can do research on your competition

Different types of Proxies

There are many different types of proxies that will cover just about any configuration that you can think of. Here, I'll give you a quick overview of 14 different proxy types.

Transparent proxy

Transparent proxies are the simplest kind of proxy. They pass all of your information along, but with the proxy's IP address. These proxies don't offer any kind of privacy protection.

They tell the server you're sending your request to that the request is coming through a proxy. This is enough to get you around simple IP bans. A common use for transparent proxies is setting up website filtering, like schools and companies do.

Anonymous proxy

Anonymous proxies are a commonly used type of proxy. They never pass your IP address to the website you are browsing although they will identify themselves as a proxy in the request. This helps keep your browsing activity private.

When you don't want targeted ads following you around the internet or you don't want your location attached to your request, these are some standard proxies to use. This is usually enough to get around most targeting activities, but there is still a chance that your information might be revealed.

High anonymity proxy

These proxies are the most secure type because they don't pass along your IP address and personal data and they don't identify themselves as a proxy when making requests. They also sporadically change the IP address they use for requests. That's what allows high anonymity proxies to give you the most privacy online.

The TOR browser uses this type of proxy. Since the IP address changes occasionally, that makes it extremely hard for servers to keep track of what traffic belongs to what client. If you don't want to be tracked, this is the best option.

Distorting proxy

A distorting proxy works similarly to an anonymous proxy except it passes an IP that is purposely false. It identifies itself as a proxy and uses that false IP address in requests. This is great when you want to appear as if you were in a specific location.

This is useful when you want to get around specific content restrictions. It's like you get to choose the IP address you want the proxy to use.

Residential proxy

Residential proxies are proxies that use real IP addresses. That means they are the addresses of real computers. These are the best types of proxies to use because they look like regular clients to servers.

Any of the proxy types discussed so far can be a residential proxy. As long as the proxy's IP address is associated with a physical device, these types of proxies tend to be undetectable and they get around some of the geographic problems other proxy types have.

Data center proxy

These are kind of the opposite of residential proxies. Data center proxies have computer generated IP addresses that aren't attached to a real device. It's like having a proxy in the cloud.

An advantage to this kind of proxy is their speed. Usually cloud service providers have incredible internet connections that give you speeds you couldn't get otherwise. Although they would all share similar IP addresses, one server could host hundreds of data center proxies.

Public proxy

Of all the proxy types, these are the most insecure, unreliable proxies available. They can go down at any moment and many are set up by hackers to steal data. The only reason people still use them is because they are free.

While it isn't difficult to find lists of free public proxies, it is a challenge to find good ones. You never know who these proxies are hosted by and it's a huge gamble to send any of your sensitive information through one. Any number of users can be on a public proxy at any time and there's no one regulating who uses it.

Private proxy

Private proxies have some ambiguity around what they are because they're defined by the provider offering the service. This could mean your proxy can only be used by one client at a time or that your proxy needs authentication before you can use it. These are like more reliable versions of public proxies.

A private proxy can be transparent or have high anonymity, similar to some of the others above like the residential or data center proxy. This proxy type has more to do with who can connect to it than how it handles your requests.

Dedicated proxy

A dedicated proxy is like a specific type of private proxy. It just means that the proxy can't be shared by multiple clients at the same time. So only one client can connect and send requests.

This helps prevent the IP address of the proxy from getting banned by different websites and services. It's one of the ways that a proxy provider can control who has access to the proxy to make sure that it isn't being abused.

Shared proxy

These are some of the cheapest proxies available and they work similar to shared servers. Clients pool together and split the cost of the proxy and they can all access it at the same time. Shared proxies have a more complex architecture because they handle a lot of requests at the same time.

Depending on how resources are allocated on the shared proxy, requests might be slower than over your own IP address. Because it's handling multiple requests from multiple users, the configurations of these types of proxies is more critical than the others.

Rotating proxy

Rotating proxies work a little differently from the others. Every time a client connects to the proxy, a new IP address is created for it. So they never use the same IP address more than once.

Every time a client sends a request a new IP address is generated. This is how proxies like the TOR browser work to keep your anonymity. A rotating proxy provides a high level of security and privacy when combined with some of the other types.

SSL proxy

These proxies follow the same protocol as HTTPS requests. The 'S' in HTTPS means SSL which means your web requests are secure between your client and the server you're trying to get to.

That means you get even more security because all of your requests through the proxy are encrypted. Most proxies should be using this by default, but there is still a chance you'll run into some that use HTTP.

Reverse proxy

Reverse proxies are completely different from everything we've covered so far. A reverse proxy hides the IP address of a server you're trying to send a request to. When a server needs security and privacy from clients, that's when these types of proxies come in.

These proxies are great if you need to monitor access to a server for reasons like keeping clients from having unmonitored access to a database. It can also help lower traffic on the network by passing on cached information instead of making a query each time.

Proxy Services

If you've done a quick search for proxy services, you'll know that there are a lot to choose from. Not all of them are created equally, so it's important that you know what features you want from your proxy service.

Most of these services offer combinations of the proxy types. For example, you'll be able to find residential, high anonymity, SSL proxies rolled into one service. There are a few that stand out from the others so here's a list of them, but make sure you research them to see if they meet your needs.

• https://smartproxy.com/
• https://www.megaproxy.com/
• https://whoer.net/webproxy
• https://www.proxysite.com/
• https://hide.me/en/proxy
• https://www.kproxy.com/
• https://www.vpnbook.com/webproxy

Proxy server vs VPN

If you're familiar with VPNs (virtual private networks), then you might be wondering how a proxy is different. The main difference is that a VPN secures all of your network traffic where proxies only secure your internet traffic.

Some things that VPNs secure that proxies don’t include FTP uploads or downloads and background operating system processes, like updates.

The only thing proxies and VPNs have in common is that they make your internet traffic look like it's coming from a different IP address. That is all they have in common. The way they handle this is wildly different because of what they're used for.

A proxy just passes along your internet requests, acting like a middleman. A VPN on the other hand tunnels all of your network activity down to the operating system level. Proxies are typically used by a single application like a browser or torrenting client.

Companies tend to use VPNs to let employees access corporate resources without worrying about the traffic being intercepted or recorded by an ISP (internet service provider). These are usually hosted on a physical computer somewhere on premises.

The great thing about VPNs is that they conceal everything you do. If your ISP were to get a history of your usage, it would only see that you were connected to a VPN. Nothing about your traffic would be seen. When you connect to public Wi-Fi, a VPN is the most secure choice.

With all of the benefits that come with using a VPN, there are still good reasons people choose proxies. To start with, VPNs are typically more expensive than a proxy. You also need decent computer hardware to run a VPN. The connection is usually slower than a proxy would be.

There are plenty of times when you don’t necessarily need the kind of security that a VPN offers. When you just want to mask your activities on a single application at a low cost, a proxy might be worth considering.

Benefits and risks

Now that you know everything about proxies, here's a list of some of the benefits and risks associated with using them.

Benefits

• Secure and private internet browsing
• Ability to get around geo-location restrictions
• Better network performance
• Ability to control what websites clients have access to
• Many types to choose from to suit specific needs

Risks

• Your requests might return really slow
• Not all proxies encrypt your requests so your information could still leak out
• Free or cheap proxies could be set up by hackers or government agencies
• Proxies can disappear at any time
• All of your requests and information always go through a third party that could be run by anyone

There are plenty more benefits and risks to using any of the proxy server types. That's why it is important to only connect to proxy servers you trust. When you are connected to a trusted proxy, the risks should have been taken into account in the configurations so you have less to worry about.

How to set up a simple proxy server

Creating your own private proxy sounds a lot harder than it is. You can make a proxy with a computer in your house that's just as secure as most proxies you can buy. It just takes some patience and a little curiosity.

On a Linux server, you can install Squid and set the configurations for the proxy you want to create. You'll be able to do things like block specific websites or require authentication before a client can connect to the proxy.

Here's a great walk through on setting up a Squid proxy on Linux: https://devopscube.com/setup-and-configure-proxy-server/

On Windows and Mac, you have the option of making a proxy server using Python and the Google App Engine. You will have to pay for the Google App Engine service, but they make it fairly affordable.

Setting up a proxy like this is a little more involved than on Linux, but here's a great walk through: https://www.hongkiat.com/blog/proxy-with-google-app-engine/

How to connect to an existing proxy

Connecting to proxies is usually a straightforward process once you know your proxy's information, like its IP address and port number. No matter what operating system you use, proxies are usually quick to set up.

Typically you'll go into your network settings and find where you can enter your proxy information. Then you should be able to connect and a web page might appear if there's an authentication step included by the proxy. Here's what it looks like on Windows and Ubuntu.

setting up a proxy server though the Windows Settings

setting up a proxy server through the Ubuntu Network Settings

Conclusion

Now you know everything about proxy servers from what they are to how to create one for yourself! I have a little proxy set up on my home network and it does make some things a lot easier to access when I'm away from home.

I write about other random stuff in tech too, like machine learning and VR. You should follow me on Twitter to learn stuff that is just cool sometimes. Plus I've got a website where you can check out my other articles and watch my slow transition from the current site to my shiny new one.

Site speed is important. It affects your users' experience directly, and a good user experience is extremely important to help drive sales and keep customers and visitors happy. Not only does it improve your site's UX, but a correctly configured website eats fewer resources and offloads work from the main server as well.

In this post, I'll discuss what I learned while getting an A grade on GTMetrix on codedamn - a platform for developers to learn programming in a new way. Let's start!

#1: Compress Images

Raw images are highly compressible, and you'd be surprised to find out how much bandwidth and data you could save just by compressing all your images.

For production sites, I recommend tools like TinyPNG CLI which can compress your images on server in a directory. Here's a quick peek of how TinyPNG saved over 2MB on a high res photo I uploaded on their site:

The great thing is TinyPNG allows 500 images free per month, so for a small to medium site, you can almost always stay inside the free quota!

#2: Code Splitting AND Bundle Splitting

Code Splitting means that you split your code up into various chunks and lazily loading them when needed. You always need this on your site

Bundle Splitting refers to splitting individual files generated by code splitting further down into smaller bundles. This improves caching on browsers as well as bytecode caching by browsers.

Although bundle splitting can be frowned upon as you increase HTTP requests, HTTP/2 has little to no impact on multiple requests until concurrency limits hit. And fortunately concurrency limits are in the range of hundreds of requests.

So if you're not making hundreds of HTTP requests (which you're probably not), you should be good with bundle splitting.

For code and bundle splitting, you need to integrate your project with a module bundler like parcel or webpack.

Once you configure them correctly, they work like magic. And they can really bring down the load both on your server and on the client's browsers.

They do this by caching resources and not downloading resources you don't currently need - like, why would you want to send the JS code for /about route when I'm on /feedback route.

You should also minify your JS/CSS builds. For webpack, there are plugins like UglifyJS available. This helps reduce the size by trimming whitespaces, comments, shortening code, and so on – which will eventually reduce the size of the contents.

#3: Do not use shared hosting services

If you're a developer or someone who has a basic understanding of how to work with bash a little, there's simply no reason to go with shared hosting services.

In almost every case, either you can host your static assets for free on sites like GitHub pages, or you can go with more controlled options like cloud hosting. Almost all these cloud hosting players like AWS, Google Cloud, and DigitalOcean provide so many free credits that you can consume a lot of their services for free for a long time!

In some cases, shared hosting is cheaper than alternatives like $5 DigitalOcean hosting. But these servers have very limited resources allocated to your website, which degrades the overall site performance. Jailed shells, shared vCPUs, and limited RAM are some things to begin with.

Since we, as developers, always want to be in control, and going with a IaaS or a PaaS is always a solution.

Although you can go with any cloud provider of your choice, I would recommend DigitalOcean - the one I use for codedamn currently. It is dead simple to setup, and you can get $100 worth of free cloud credits with this link.

Choosing a cloud provider can really give you resources and infrastructure which will automatically bump your server performance (and your site performance) a bit.

#4: Set HTTP Expiry headers

Just like we discussed above, caching is extremely important to setup correctly. HTTP expiry headers inform the browser what to cache and for how long. Cached resources are not fetched from the remote servers, so it's important not to cache main entrypoint resources like index.html - the first file you serve. You must also implement cache busting appropriately.

Again, for module bundlers like webpack, you can implement cache busting by having [contenthash] in the name of the bundles it spits out. Also, this requires that browsers never cache your index.html or any other HTML file you're using as an entrypoint to your site. How can we achieve that?

For static file serving and HTTP expiry headers, use NGiNX. NGiNX can manage all of that stuff for you. Here's a sample configuration recommended for setting HTTP expiry headers:

This configuration simply sets caching off for text/html resources. For others, it sets it to the maximum possible time the browser can hold the cache.

Note that this configuration strongly relies on the fact that you have your cache busting mechanisms implemented in your module bundler (like the [contenthash] we talked about above).

#5: Enable Brotli Compression

Brotli compression is a compression algorithm designed by Google, which is 20-25% more efficient than the well-known GZIP compression.

Brotli compression can be implemented on sites, again, using NGiNX. Let's take a look at an example of what happens when Brotli compression is enabled:

The first file size is 3.33 MB - without compression.

When it is compressed using Brotli - the size drops to 572KB.

When it is compressed using GZIP - the size only drops to 783KB.

Brotli saves over 200KB compared to GZIP, and over 2.5MB compared to no compression. And it is not even performing at its peak! That's over 82% compression! Very cool.

That's it!

That's basically it! Without going much into the details of how to implement these specific techniques, we covered some of the most important things to consider when speeding up your site.

I did not go into the specific details as your mileage may vary with your server setups and configurations - but the general concept remains same.

Make sure you follow these best practices and let me know what you think by saying Hi on my twitter handle.

If you liked this article, let's meet on social media. Here's my Instagram and Twitter. I'm super active, and would love to have a chat! Let's connect.