NGINX: Basics and Best Practices EMEA

NGINX: Basics and Best
Practices

Faisal Memon
Product Marketing Manager, NGINX
Formerly:
• Sr. Technical Marketing Engineer, Riverbed
• Technical Marketing Engineer, Cisco
• Software Engineer, Cisco
Who am I?

Owen Garrett
Head of Products, NGINX
Formerly:
• Head of Products, OnApp Connect
• Director, Product Management, Riverbed
Leif Beaton
Solutions Architect, NGINX
Formerly:
• Senior IT Engineer, Qualcomm
• Field Solutions Architect, Quest Software
Who are we?

Agenda
• Introducing NGINX
• Installing NGINX and NGINX Plus
• Key files, commands, and directories
• Basic configurations
• Advanced configurations
• Logging and monitoring
• Summary

“I wanted people to use it, so I
made it open source.”
- Igor Sysoev, NGINX creator and founder

336,529,382
web sites
running on NGINX
Source: Netcraft June 2018 Web Server Survey

64%
Busiest 10,000
run on NGINX
Source: w3techs, June 2018

What is NGINX?
Internet
Web Server
Serve content from disk
Reverse Proxy
FastCGI, uWSGI, gRPC…
Load Balancer
Caching, SSL termination…
HTTP traffic
- Basic load balancer
- Content Cache
- Web Server
- Reverse Proxy
- SSL termination
- Rate limiting
- Basic authentication
- 7 metrics
NGINX Open Source NGINX Plus
+ Advanced load balancer
+ Health checks
+ Session persistence
+ Least time alg
+ Cache purging
+ High Availability
+ JWT Authentication
+ OpenID Connect SSO
+ NGINX Plus API
+ Dynamic modules
+ 90+ metrics

About NGINX, Inc.
• Founded in 2011, NGINX Plus first released in
2013
• VC-backed by enterprise software industry
leaders
• Offices in SF, London, Cork, Singapore,
Sydney, and Moscow
• 1,500+ commercial customers
• 200+ employees

NGINX mainline and stable
NGINX Mainline receives new features, updates and bug fixes, and is updated approximately every 6 weeks
16% of users use
mainline
Updated ~6 weekly
1.13 (mainline) 1.15 (mainline)

NGINX mainline and stable
NGINX Mainline receives new features, updates and bug fixes, and is updated approximately every 6 weeks
NGINX Stable receives no new features, and only critical bug fixes.
16% of users use
mainline
Updated ~6 weekly
84% of users use
stable
Updated yearly
1.12 (stable) 1.14 (stable)
1.13 (mainline) 1.15 (mainline)
Each April

NGINX Plus
NGINX Plus receives all new features, once they have been tested and proven in NGINX mainline.
Additional enterprise-specific features are included in NGINX Plus.
NGINX Plus is released approximately every 3-4 months.
R13 R14 R15

NGINX Installation Options
• Official NGINX repo:
- Mainline (recommended) -- Actively developed; new minor releases made
every 4-6 weeks with new features and enhancements.
- Stable -- Updated only when critical issues or security vulnerabilities need
to be fixed.
- NGINX Plus (commercial) – accessed using your private subscription key
• OS vendor and other 3rd party repos:
- Typically built off NGINX Stable branch
- Not as frequently updated; for example, Debian Stretch has NGINX 1.10.3

NGINX Installation Process
• For full installation details: http://nginx.org/en/linux_packages.html
- List of all supported distros and CPUs
- Suse Linux installation instructions
• For NGINX Plus, see: https://cs.nginx.com/repo_setup
- List of all supported distros and CPUs, including FreeBSD

Verifying Installation
$ nginx -v
nginx version: nginx/1.15.0
$ ps -ef | grep nginx
root 1088 1 0 19:59 ? 00:00:00 nginx: master process /usr/sbin/nginx -c
/etc/nginx/nginx.conf
nginx 1092 1088 0 19:59 ? 00:00:00 nginx: worker process

server {
listen <parameters>;
location <url> {
----------------
}
}
upstream {
-------------------
}
server {
location <url> {
----------------
}
}
upstream {
-------------------
}
Key NGINX Files and Directories
/etc/nginx/
--------------------------
--------------------------
http {
----------------------
include conf.d/*.conf;
}
Global settings
(tunings, logs, etc)
HTTP block
nginx.conf virtualserver1.conf
server {
location <url> {
----------------
}
}
upstream {
-------------------
}
/etc/nginx/conf.d/
/var/log/nginx/
error.log
access.log
Important operational messages
Record of each request (configurable)
Listen for
requests
Rules to handle
each request
Optional: proxy
to upstreams

Key NGINX Commands
• nginx –t Check if NGINX configuration is ok
• nginx –s reload Check config is ok and gracefully reload NGINX processes
• nginx –V Similar to –v, but with more detailed information
• nginx –T Dump full NGINX configuration
• nginx –h Display NGINX help menu
• After config change, test and reload : nginx –s reload

Simple Virtual Server
http {
server {
listen 80 default_server;
server_name www.example.com;
return 200 "Hello, World!";
}
}
• server defines the context for a
virtual server
• listen specifies IP/port NGINX
should listen on. No IP means bind
to all IPs on system
• server_name specifies hostname
of virtual server, matching the Host
header in the request
• return tells NGINX to respond
directly to the request.

Basic Web Server Configuration
server {
location / {
root /usr/share/nginx/html;
# alias /usr/share/html;
index index.html index.htm;
}
}
www.example.com -> /usr/share/nginx/html/index.html
www.example.com/i/file.txt -> /usr/share/nginx/html/i/file.txt
• root specifies directory where files
are stored
• index defines files that will be used
as an index

Basic Load Balancing Configuration
upstream my_upstream {
server server1.example.com;
least_time;
}
server {
location / {
proxy_set_header Host $host;
proxy_pass http://my_upstream;
}
}
• upstream defines the load balancing pool
• Default load balancing algorithm is round robin.
Others available:
• least_conn selects server with least
amount of active connections
• least_time factors in connection count
and server response time. Available in
NGINX Plus only.
• proxy_pass links virtual server to upstream
• By default NGINX rewrites Host header to name
and port of proxied server. proxy_set_header
overrides and passes through original client
Host header.

Basic Caching Configuration
proxy_cache_path /var/run/cache levels=1:2
keys_zone=my_cache:10m max_size=10g
inactive=60m use_temp_path=off;
server {
location / {
proxy_cache my_cache;
}
}
• proxy_cache_path defines the
parameters of the cache.
• keys_zone defines the size of
memory to store cache keys in. A
1 MB zone can store data for
about 8,000 keys.
• max_size sets upper limit of
cache size. Optional.
• inactive defines how long an
object can stay in cache without
being accessed. Default is 10 m.
• proxy_cache enables
caching for the context it is in

Basic SSL Configuration
server {
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl default_server;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
location / {
index index.html index.htm;
}
}
• Force all traffic to SSL is good for
security and SEO
• Use Let’s Encrypt to get free SSL
certificates, see:
nginx.com/blog/using-free-
ssltls-certificates-from-
lets-encrypt-with-nginx

Basic HTTP/2 Configuration
server {
listen 443 ssl http2 default_server;
}
• HTTP/2 improves performance with little
to no backend changes
• Add http2 parameter to listen
directive of existing SSL-enabled virtual
server. HTTP/2 is only supported with
SSL in all browsers.
• NGINX only does HTTP/2 client side,
server side is still HTTP/1.1. gRPC is a
special case.
• Note: HTTP/2 requires OpenSSL 1.0.2
or later to work properly

Multiplexing Multiple Sites on One IP
server {
# ...
}
server {
listen 80;
server_name www.example2.com;
# ...
}
server {
listen 80;
server_name www.example3.com;
# ...
}
• NGINX can multiplex a single IP/port
using the Host: header.
• default_server defines the
virtual server to use if Host header
is empty. It is best practice to have
a default_server.
• See http://nginx.org/en/docs/http/
request_processing.html

Layer 7 Request Routing
server {
# ...
location /service1 {
proxy_pass http://upstream1;
}
location = /dashboard.html {
root /var/nginx/html;
}
location ~ ^(.+.jsp)(.*)$ {
proxy_pass http://tomcat$1$2;
}
}
• location blocks are used to do
Layer 7 routing based on URL
• Prefix matches are most common
• Exact matches and Regex
matching can also be used in
location blocks

Modifications to main nginx.conf
user nginx;
worker_processes auto;
# ...
http {
# ...
keepalive_timeout 300s;
keepalive_requests 100000;
}
• Set in main nginx.conf file
• Default value for worker_processes varies on
system and installation source
• auto means to create one worker process per
core. This is recommended for most deployments.
• keepalive_timeout controls how long to keep
idle connections to clients open. Default: 75s
• keeplive_requests Max requests on a single
client connection before its closed
• keepalive_* can also be set per virtual server

HTTP/1.1 Keepalive to Upstreams
keepalive 32;
}
server {
location / {
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
• keepalive enables TCP connection
cache
• By default NGINX uses HTTP/1.0 with
Connection: Close
• proxy_http_version upgrades
connection to HTTP/1.1
• proxy_set_header enables keepalive by
clearing Connection: Close HTTP
header

SSL Session Caching
server {
listen 443 ssl default_server;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
}
• Improves SSL/TLS performance
• 1 MB session cache can store
about 4,000 sessions
• Cache shared across all NGINX
workers

Advanced Caching Configuration
proxy_cache_path /path/to/cache levels=1:2
keys_zone=my_cache:10m max_size=10g
inactive=60m use_temp_path=off;
server {
location / {
proxy_cache my_cache;
proxy_cache_lock on;
proxy_cache_revalidate on;
proxy_cache_use_stale error timeout updating
http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
}
}
• proxy_cache_lock instructs NGINX
to only send one request to the
upstream when there are multiple
cache misses for the same file.
• proxy_cache_revalidate instructs
NGINX to use If-Modified-Since
when refreshing cache.
• proxy_cache_use_stale instructs
NGINX to serve stale content instead
of an error.
• proxy_cache_background_update
instructs NGINX to do all cache
updates in the background.
Combined with
proxy_cache_use_stale updating,
stale content will be served.

gRPC Proxying with SSL Termination
server {
listen 443 ssl http2;
ssl_certificate server.crt;
ssl_certificate_key server.key;
location / {
grpc_pass grpc://localhost:50051;
}
}
• Configure SSL and HTTP/2 as usual
• Go sample application needs to modified to
point to NGINX IP Address and port.

zone my_upstream 64k;
server server1.example.com slow_start=30s;
}
server {
# ...
location /health {
internal;
health_check interval=5s uri=/test.php
match=statusok;
proxy_set_header HOST www.example.com;
}
match statusok {
# Used for /test.php health check
status 200;
header Content-Type = text/html;
body ~ "Server[0-9]+ is alive";
}
Active Health Checks – NGINX Plus only
• Polls /test.php every 5 seconds
• If response is not 200, server marked
as failed
• If response body does not contain
“ServerN is alive”, server marked as
failed
• Recovered/new servers will slowly
ramp up traffic over 30 seconds
• Exclusive to NGINX Plus

Cookie Session Persistence – NGINX Plus only
sticky cookie name expires=1h
domain=.example.com path=/;
}
• NGINX will insert a cookie using the specified
name
• expires defines how long the cookie is valid
for. The default is for the cookie to expire at the
end of the browser session.
• domain specifies the domain the cookie is
valid for. If not specified, domain field of cookie
is left blank
• path specifies the path the cookie is set for. If
not specified, path field of cookie is left blank

NGINX Stub Status Module
server {
location /basic_status {
# put access control here...
stub_status;
}
}
• Provides aggregated NGINX
statistics
• Access should be locked down
so its not publically visible
$ curl http://www.example.com/basic_status
Active connections: 1
server accepts handled requests
7 7 7
Reading: 0 Writing: 1 Waiting: 0

NGINX Plus Extended Status
• Provides detailed NGINX Plus
statistics
• Over 90+ additional metrics
• JSON data output
• Monitoring GUI also available,
see demo.nginx.com
server {
listen 8080;
location /api {
api write=on;
# Limit access to the API
allow 10.0.0.0/8;
deny all;
}
location = /dashboard.html {
}

NGINX Access Logs
log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status
$bytes_sent ' '"$http_referer" "$http_user_agent"';
• Enabled by default, can be shut off by adding “access_log off” to improve
performance
• By default lists client IP, date, request , referrer, user agent, etc. Can add additional
NGINX variables, see nginx.org/en/docs/varindex.html
• Log format configurable with the log_format directive
192.168.179.1 - - [15/May/2017:16:36:25 -0700] "GET / HTTP/1.1" 200 612 "-"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/58.0.3029.110 Safari/537.36"
192.168.179.1 - - [15/May/2017:16:36:26 -0700] "GET /favicon.ico HTTP/1.1" 404 571
"http://fmemon-redhat.local/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Summary
• It is recommended to use the NGINX mainline branch for most deployments
• All configuration should go into separate files in /etc/nginx/conf.d/*.conf
• Forcing all traffic to SSL improves security and improves search rankings
• Keepalive connections improve performance by reusing TCP connections
• SSL session caching and HTTP/2 improve SSL performance
• NGINX status module and logging capability provide visibility
Try NGINX Plus for free at nginx.com/free-trial-request

Q & ATry NGINX Plus free for 30 days: nginx.com/free-trial-request

NGINX: Basics and Best Practices EMEA

More Related Content

What's hot (20)

Similar to NGINX: Basics and Best Practices EMEA (20)

More from NGINX, Inc. (20)

Recently uploaded (20)

NGINX: Basics and Best Practices EMEA