Commit 089485bc by Paul B

wip: adding common tips for nginx configuration

1 parent fc62a444
Pipeline #6717224 for 089485bc passed in 4 minutes 29 seconds
---
title: Common usage of an NGINX configuration
date: 2017-02-26
tags: nginx, webserver, reliability
---
After more than 3 years trusting Nginx to serve customer traffic. First in my previous working experience where I migrated the public facing webservers from Apache to Nginx. And now in for my current employer where I configure and maintain most of the Nginx configurations. I felt there was a few common configuration which could easily be reusable or useful for other people. This is why I decided to list here a few common use cases.
# Conf directory organisation
~~~
/etc/nginx/
├── nginx.conf
~~~
~~~
├── sites-available
│ ├── default
│ ├── site
├── sites-enabled
│ ├── default -> ../sites-available/default
│ ├── site -> ../sites-available/site
~~~
~~~
├── conf.d
│ ├── loaded_in_alpha_order.conf
~~~
Link to Headers
~~~
├── includes.d
│ ├── include_me_later.conf
~~~
Link to MAPs paragraph
~~~
├── maps.d
│ ├── logic.conf
~~~
# Don't loose your heads
* Watch out when `add(ing)_header`s
* You could think that adding headers one by one in different subsequent blocks will keep all of them, well nope. This is clearly explained in the [nginx documentation]().
* If you need a common set of custom headers to use in a set of different "final" location blocks. I would recommend to keep them in an includable file
# If is evil but Maps are beatiful
* Link to If is evil.
* You almost never need If blocks
* Prepare all your conditions within maps and intermediate variables
# Sequence of two named Locations
After looking quickly at the Nginx documentation you could think that it is not possible to forward requests from one named location block to another named location block. However the following paragraph describes you exactly how to do that.
I found myself in a few situations where
# Minimal Accept-Language parsing (without module)
You could tell me that there is a good nginx module for that (link). However sometimes you don't especially want to recompile an nginx or add extra modules to it. Here is a pretty straight forward way of parsing your accept-language headers to determine your users' prefered language:
# Minimal Mobile User Agent parsing (without module)
Yet another thing that could be solved by an extra module. If you prefer a few nginx configuration lines to parse your users' device and serve mobile ready content, here is what you could do:
# A simplified application sharding solution
Small mruby / lua block of configuration to read sharding mapping. Can be stored in a Redis database or base on a simple computation..
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!