Skip to main content

Command Palette

Search for a command to run...

Day 19: Server - NGINX ~ Your Swiss Army Knife for Web Hosting!

Updated
5 min read
Day 19: Server - NGINX ~ Your Swiss Army Knife for Web Hosting!
A

Experienced Senior DevOps Engineer with a passion for optimizing software development and delivery processes. Excels in designing and implementing CI/CD pipelines, automating infrastructure, and optimizing cloud architectures. Proficient in a wide range of DevOps tools such as Docker, Kubernetes, Jenkins, Ansible, Git, and AWS services. Strong collaborator, adept at fostering cross-functional teamwork and continuous improvement. Thrives in dynamic environments, utilizing problem-solving skills to overcome complex challenges. Dedicated to delivering high-quality software products on time and within budget.

NGINX is a high-performance, open-source web server, and reverse proxy server. It is designed to handle a large number of concurrent connections efficiently, making it a popular choice for serving static content, acting as a load balancer, and proxying requests to other application servers. NGINX is known for its lightweight and low resource consumption, making it an excellent choice for high-traffic websites and modern web applications.

Here are the different types of NGINX and their use cases:

  1. NGINX as a Web Server:
    Use Case: NGINX can serve static files, such as HTML, CSS, JavaScript, and images, directly to clients, handling static content delivery efficiently. It is an excellent choice for hosting static websites and assets.

    Example Configuration:

     server {
         listen 80;
         server_name example.com;
    
         location / {
             root /var/www/example;
             index index.html;
         }
     }
    

    In this example, NGINX listens on port 80 for requests to example.com. It serves static content from the directory /var/www/example and the default file for directory listing is index.html

  2. NGINX as a Reverse Proxy:
    Use Case: NGINX can act as a reverse proxy, forwarding client requests to backend application servers. This setup is often used to load balance requests across multiple application servers, improving application performance and ensuring high availability.

    Example Configuration:

     upstream backend_servers {
         server 192.168.0.101:8080;
         server 192.168.0.102:8080;
     }
    
     server {
         listen 80;
         server_name api.example.com;
    
         location / {
             proxy_pass http://backend_servers;
         }
     }
    

    In this example, NGINX acts as a reverse proxy for the backend application servers located at 192.168.0.101 and 192.168.0.102, which serve requests on port 8080. NGINX forwards client requests to these backend servers based on the proxy_pass directive.

  3. NGINX as a Load Balancer:
    Use Case: NGINX can distribute incoming client requests across multiple backend servers, balancing the load to prevent any single server from being overwhelmed. It ensures even distribution of traffic and helps scale applications horizontally.
    Example Configuration:

     upstream backend_servers {
         server 192.168.0.101;
         server 192.168.0.102;
     }
    
     server {
         listen 80;
         server_name app.example.com;
    
         location / {
             proxy_pass http://backend_servers;
         }
     }
    

    In this example, NGINX acts as a load balancer for the backend servers at 192.168.0.101 and 192.168.0.102. NGINX distributes incoming requests between these servers using a simple round-robin algorithm.

  4. NGINX as an SSL/TLS Termination Proxy:

    Use Case: NGINX can handle SSL/TLS encryption and decryption for incoming requests, relieving the backend application servers from this resource-intensive task. It is often used to offload SSL processing and improve the performance of application servers.
    Example Configuration:

     server {
         listen 443 ssl;
         server_name secure.example.com;
    
         ssl_certificate /path/to/certificate.crt;
         ssl_certificate_key /path/to/private.key;
    
         location / {
             proxy_pass http://backend_server;
         }
     }
    

    In this example, NGINX listens on port 443 for secure requests to secure.example.com. It terminates SSL/TLS encryption using the provided certificate and key before forwarding requests to the backend server.

  5. NGINX as an API Gateway:
    Use Case: NGINX can act as an API gateway, routing and proxying API requests to backend services. It provides rate limiting, authentication, and request/response transformations to simplify API management and improve security.

    Example Configuration:

     server {
         listen 80;
         server_name api.example.com;
    
         location /v1/ {
             limit_req zone=api_limit burst=10 nodelay;
             proxy_pass http://backend_server;
         }
     }
    

    In this example, NGINX listens on port 80 for requests to api.example.com. It uses the limit_req directive to set a request rate limit for the /v1/ endpoint. Requests exceeding the rate limit will be delayed (nodelay) or rejected.

  6. NGINX for Microservices Architecture:
    Use Case: In a microservices architecture, NGINX can be used as an API gateway and reverse proxy to handle incoming client requests and route them to the appropriate microservices. It helps decouple services and improves overall scalability and maintainability.
    Example Configuration:

     upstream service_one {
         server 192.168.0.101:8080;
     }
    
     upstream service_two {
         server 192.168.0.102:8080;
     }
    
     server {
         listen 80;
         server_name api.example.com;
    
         location /service1/ {
             proxy_pass http://service_one;
         }
    
         location /service2/ {
             proxy_pass http://service_two;
         }
     }
    

    In this example, NGINX forwards requests for /service1/ to the backend service at 192.168.0.101:8080, and requests for /service2/ to the backend service at 192.168.0.102:8080.

  7. NGINX as a Caching Proxy:
    Use Case: NGINX can cache static content and responses from backend servers, reducing the load on the application servers and improving response times for clients.
    Example Configuration:

     proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m;
    
     server {
         listen 80;
         server_name example.com;
    
         location / {
             proxy_pass http://backend_server;
             proxy_cache my_cache;
             proxy_cache_valid 200 304 1d;
             proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
         }
     }
    

    In this example, NGINX uses a cache named my_cache to store responses from the backend server. Responses with a 200 or 304 status code will be cached for 1 day.

  8. NGINX for Web Application Firewall (WAF):

    Use Case: NGINX can be configured as a WAF to inspect incoming traffic, filter out malicious requests, and protect web applications from common attacks like SQL injection, cross-site scripting (XSS), and more.

    Here's an example configuration for using NGINX as a Web Application Firewall (WAF) to protect a web application from common attacks like SQL injection and Cross-Site Scripting (XSS):

     # nginx.conf
    
     http {
         # Define the WAF rules
         map $request_uri $block_request {
             default                     0;
             ~*sql_injection             1;
             ~*xss_injection             1;
         }
    
         server {
             listen 80;
             server_name myapp.example.com;
    
             # Block requests based on WAF rules
             if ($block_request) {
                 return 403;
             }
    
             location / {
                 # Forward the request to the backend application server
                 proxy_pass http://backend_server;
             }
         }
     }
    

    In this example:

    1. We define two WAF rules using the NGINX map directive. The first rule sql_injection is designed to match requests with potential SQL injection attempts in the request URI ($request_uri). The second rule xss_injection is designed to match requests with potential Cross-Site Scripting (XSS) attempts in the request URI.

    2. Inside the server block, we check if the request URI matches any of the defined WAF rules using the if ($block_request) condition. If there is a match, the request is blocked with a 403 Forbidden response.

    3. If the request passes the WAF checks, it is considered safe, and we forward it to the backend application server using the proxy_pass directive.

NGINX is a versatile and powerful tool that can be used in various scenarios to enhance the performance, security, and scalability of web applications and services. Its flexibility and extensive feature set have made it a popular choice for many high-traffic websites, web applications, and API services.

Thanks for reading! I hope you found this blog informative and insightful. For more technology-related content, don't forget to follow me on GitHub and LinkedIn

A

For more in details checkout: https://www.freecodecamp.org/news/the-nginx-handbook/#introduction-to-nginx

More from this blog

Untitled Publication

68 posts