Table of Contents

Mounts: content and sites

Content
Sites

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Mounts: content and sites

Content

Mounting content is quite simple, just bind-mount to /usr/share/nginx/html. Remember to be sure that UID 8080 can read these files! Here’s a full example:

# ensure content is readable by the container, let's assume public readable is fine
chmod -R +r /my/content

# run container with content mounted
docker run -d --name ab-nginx --restart unless-stopped \
  -p 80:80 \
  -v /my/content:/usr/share/nginx/html \
  asifbacchus/ab-nginx

Sites

Server-block configurations within the container are read from files found in /etc/nginx/sites. Within that directory, NGINX will process files with the extension .conf. There are two things to note about this:

Files are read in the same order as they would be listed via the ls command. This may or may not matter in your particular set up. However, it is generally considered good practice to number your configurations to ensure they are executed in the right order. For example, 00-drop-all-unrecognized.conf, 05-main.conf, 10-proxyWebApp.conf, 99-stats.conf.
If you want to disable a server-block, simply rename the file using a different extension – I usually use .conf.disabled. Then, you can restart the container (docker restart ab-nginx) and that server-block will be ignored.

The container has two site-block configuration files: one that is HTTP and is enabled by default and another that is HTTPS and auto-enabled when certificates are mounted. In both cases the server-block contains the following location block:

location / {
  try_files $uri $uri/ =404;
}

Quite simply, this means serve any files in the webroot and its children or return 404 if the requested URI cannot be found.

However, let’s say you want to set up this container as a reverse proxy instead. You can override the default configuration by mounting over it. Let’s create a simple configuration and only use HTTP for simplicity:

# ~/mySites/proxyWebApp.conf
server {
  listen 80;
  server_name example.com www.example.com
  
  # proxy headers
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  
  # set upstream location
  set $upstream_myapp http://127.0.0.1:8888;
  
  location / {
    proxy_pass $upstream_myapp;
  }
  
  # use fun error pages
  include /etc/nginx/snippets/errorpages.conf;
}

Let’s save this file as ~/mySites/proxyWebApp.conf. Now we can mount it in our container, overwriting the default server-blocks. Also, since we are just proxying, there is no need to mount any content - just our server-block configuration:

docker run -d --name ab-nginx --restart unless-stopped \
  -p 80:80 \
  -v ~/mySites:/etc/sites:ro \
  asifbacchus/ab-nginx

As an aside, you’ll note that I add:ro after sites and configuration mounts. This means ‘read-only’ in the container and is a security precaution. Simply put, it means the container cannot change the files in that mount. This is strictly optional and is dependant on your use-case.

Now, what if you wanted to keep the default server block to serve content in the webroot but also run the reverse proxy on a subdomain? In this case, we can add our configuration as another file in the /etc/sites directory. Let’s keep the same configuration as above but make one small change:

server {
  listen 80;
  server_name myapp.example.com;
...

So our configuration file only listens to http://myapp.example.com and the container’s default configuration listens on http://example.com. Now let’s make that actually happen – remember, we are serving content this time so we need to mount some content like in the previous section:

docker run -d --name ab-nginx --restart unless-stopped \
  -p 80:80 \
  -v /my/content:/usr/share/nginx/html \
  -v ~/mySites/proxyWebApp.conf:/etc/nginx/sites/proxyWebApp.conf:ro \
  asifbacchus/ab-nginx

To summarize, in the first example we overwrote the defaults with our server-block while, in the second example, we simply added an additional configuration.