Series: How to create your own website based on Docker (Part 4 - Planning Docker container architecture)

Let's design our docker container architecture

This is part 4 of the series: How to create your own website based on Docker.

Docker and Docker Compose are now up and running. So it's about time to let them all play together.

Before we start planning our container architecture, we need to make sure that we understand what we're trying to achieve.

1. We want to be able to port our apps to any other platform as easy as possible
2. We want our applications to be as separated as possible (every container should have one purpose)
3. We want to create more instances of an application container if needed
4. We don't want crashed applications to crash other applications

So based on this list we need to figure out what components will be needed for the site.

Let's define all components to be "dockerized"

Component 1: nginx reverse proxy

I usually start with nginx as reverse proxy in front of all other services. This allows me to have a single entry point for all requests and to distribute them internally to all containers which should be accessible from the web. This reverse proxy will listen on port 80 and will redirect all requests based on the context root, the subdomain and/or the hostname.

Here's an example:

• www.project-webdev.com:80 => redirects to my blog which listens on port 8081 internally (the projectwebdev blog will be hosted on another nginx machine).
• api.project-webdev.com:80 => redirects to my REST API which listens on port 3001 internally (the API will be an ioJS/nodeJS application).
• Also possible: www.project-webdev.com:80/api => redirects to my REST API which listens on port 3001 internally (the API will be an ioJS/nodeJS application).

As you can see, all requests will go through the nginx reverse proxy and will be redirected internally to the appropriate service.

What's important to mention: The internal ports (e.g. 8081, 3001,...) should not be exposed to public, so it should not be possible to access the blog directly (like www.project-webdev.com:8081).

This would be our first component, right? Wait! Where should our new nginx reverse proxy run on?

We need an operating system... so basically our first component would actually be a container that contains the operating system. For that I'm going to use Ubuntu 14.04 LTS.

So right now our current architecture would look like this:

Component 2: nginx web server for our website

The next thing we'll need for our web site is the markup for the website. So all we need now is another nginx web service, but this time it will not act as reverse proxy, but as a real web server hosting our files. Since we don't want any port conflicts my basic rule is that 4-digit ports are never exposed to public. (Port 80 and 443 (SSL) are allowed to be accessed from outside).

Since Docker works with container links, we need to add a link to our reverse proxy, so that it can communicate internally with our blog application (nginx web site), which listens on port 8081.

As mentioned before, port 8081 can not be accessed from outside - therefore painted in purple.

You can also see that we've mounted a directory on the docker host into our blog's docker container. We're doing this, because we want to be able to change the website from outside later, without restarting the container.

Technically it would look like the following - I'll go into details later:
In the docker container (our provider's Ubuntu server), we'll create a directory called /opt/docker/projectwebdev/html/ which will be mounted as /var/www/html/ in the container (the directory which nginx uses to load the HTML, CSS and JS files from later). So whenever nginx (the one in our nginx web site container) receives a request from a visitor, it will load the files from our real server (from /opt/docker/projectwebdev/html/) and will provide it to him - I think you've got it, right? It's not that hard.

Component 3: ioJS REST API container

Our website should fetch information from a REST API. Therefore we will need an ioJS application that will provide all data for the website asynchronously. The website will use a call to http://api.project-webdev.com to fetch the contents or any other information needed.

Since this is a new URL, we need to link this container to our nginx as well, so that we can build our redirect to that container internally.

Component 4: mongoDB database container

A REST API does not make sense without any data persistence in the back. Therefore we need to add our mongoDB to that architecture as well. This instance listens on port 3333 and should only be accessible via REST API (and therefore implicitly via our nginx reverse proxy), which is why we need to add a link to our REST API so that it can access the data in the mongoDB.

Additional component: Logs

When running this application stack in the wild later, it's very important to be able to analyse the logs (e.g. using the ELK stack). Since we have several containers, it's does not make to get the logs from each instance separately. So we're creating another volume mount which acts as central storage for all log files of all used containers. This directory can later be used by log file analysis tools, so you can analyse the hell out of your logs. :)

Conclusion

We have now several containers that act as "platform" for a certain purpose. They are all completely encapsulated and are sharing their resources (thanks to Docker).

1. nginx reverse proxy
• links:
• nginx website
• ioJS REST API
• volumes:
• log files (/opt/docker/logs)
2. nginx web site
• links:
• none
• volumes:
• web site files (/opt/docker/projectwebdev/html)
• log files (/opt/docker/logs)
3. ioJS REST API
• links:
• mongoDB database
• volumes:
• ioJS application files (/opt/docker/projectwebdev-api/app)
• log files (/opt/docker/logs)
4. mongoDB database
• links:
• none
• volumes:
• mongoDB files (/opt/docker/mongodb/db)
• log files (/opt/docker/logs)

That's it... that's our "dockerized" architecture for our projectwebdev website based on Docker containers. Let's create our Docker Compose file now... in the next part of this series.