Web server

We can choose any web server software here, but since we have already worked with NGINX earlier, it makes sense that we would try to reuse bits and pieces of this component--it is practically what the container architecture is all about! The web server component will provide some basic authentication, cache data, and act as a reverse-proxy for the application server behind it. Our basic setup that we worked on earlier can be used here, but we will modify it a bit so that instead of serving files directly, it acts as a proxy and then use authentication based on a credentials file we will create in our Dockerfile. Let's create a new folder named web_server and add these files to it:

nginx_main_site.conf:

server {
listen 80;
server_name _;

root /srv/www/html;

location ~/. {
deny all;
}

location / {
auth_basic "Authentication required";
auth_basic_user_file /srv/www/html/.htpasswd;

proxy_pass http://172.17.0.1:8000;
}
}

There are three interesting parts about this configuration here. The first one is the inclusion of auth_basic_ commands that enable HTTP Basic authentication on all endpoints provided by this configuration. The second, if you were observant enough of the new .-prefixed credentials file, is the fact that our denial of fetching all files starting with a . is needed now since we added .htpasswd. The third and the final interesting thing here is the use of proxy_pass, which allows the server to route all traffic that is authenticated to the backend application server. Why we use http://172.17.0.1:8000 as the destination is beginning to open the proverbial Pandora's box of Docker networking, so we will explain why we used it later as we will derail our service building if we cover it now.

Warning! In most cases, using basic authentication is a practical joke of security without HTTPS as we use it here since anyone on the network can sniff out your credentials in plaintext with the simplest of tools. In your services, at the very least, mandate the HTTPS protocol is you use basic auth or rely on stronger forms of credentials-passing before deploying services to anything with direct Internet access.

We can now add our new Dockerfile in that same directory, which will look like this:

FROM nginx:latest
# Make sure we are fully up to date
RUN apt-get update -q &&
apt-get dist-upgrade -y &&
apt-get install openssl &&
apt-get clean &&
apt-get autoclean

# Setup any variables we need
ENV SRV_PATH /srv/www/html

# Get a variable defined for our password
ARG PASSWORD=test

# Remove default configuration
RUN rm /etc/nginx/conf.d/default.conf

# Change ownership of copied files
RUN mkdir -p $SRV_PATH &&
chown nginx:nginx $SRV_PATH

# Setup authentication file
RUN printf "user:$(openssl passwd -1 $PASSWORD) " >> $SRV_PATH/.htpasswd

# Add our own configuration in
COPY nginx_main_site.conf /etc/nginx/conf.d/

As you can see, we've made a couple of changes here from our original work in the previous chapter. The initial thing that should stick out is the new way to write the RUN apt-get line, which we've annotated here briefly:

RUN apt-get update -q &&          # Update our repository information
apt-get dist-upgrade -y && # Upgrade any packages we already have
apt-get install openssl && # Install dependency (openssl)
apt-get clean && # Remove cached package files
apt-get autoclean # Remove any packages that are no longer needed on the system

Unlike in previous images, here, we install the openssl package since we will need it to create NGINX-encrypted passwords for authentication, but the clean and autoclean  lines are here to make sure we remove any cached apt packages on the system and remove orphaned packages, giving us a smaller image which is something we should always strive for. Just like before, we combine all of the lines in a similar manner early on so that the filesystem difference between the previous and current layer will only be the required changes and nothing else, making it a very compact change. When writing your own images, if you find yourself needing even more fat trimming, many more things can be removed (such as removing documentation files, /var directories, unnecessary optional packages, and so on), but these two should be the ones to use in most cases as they're simple to do and work pretty well on Debian-based systems.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset