First Update After Docker and GitHub integration

So, today I have been playing around with getting my development environment up and running properly. The ultimate goal was that I wanted a way to deploy DearDiary.Net onto a new machine and have it run exactly as the live site does with no manual intervention.

I’ve almost achieved that goal with the exception of the Nginx server configuration. This is because the live server has genuine SSL certificates installed and kept up to date, whereas any other server I deploy for development work won’t have. They’ll be plain. I tried having a script that would automatically remove the SSL configuration file during installation if development mode was specified.

And as I am writing this, like a lightning out of the blue, I realise exactly why the script failed. Duh. I’ve spent all afternoon trying to figure it out.

The script which knows whether I’m deploying to live or development is running in the database container. The database container knows absolutely NOTHING about Nginx. It doesn’t know it exists nor does it care. No wonder the script kept saying the file wasn’t found. It isn’t there. It’s in the Nginx container.

It’s confusing unless you know Docker 🙂 But I’ll explain cos I think it’s interesting. And it gives you a bit of insight into the new architecture.

The DearDiary service is now split into a number of specific service containers. They are, by and large, isolated parts of the service that are needed to make up the whole platform, but exist independently of each other. The can talk to each other across the network and on some occasions the services can, where appropriate share files with each other. But they’re individual services that go to make up the whole.

Those services are;

• Nginx container. This is the container that accepts connections from the internet (your web browser) and sends data back to you. It shares a filesystem with the ‘wordpress’ container. The Nginx container runs the PHP services inside itself as well, to provide the parsing of the scripts necessary to convert information from the MySQL container into something pretty for you.
• DearDiary container. This is the container that holds the WordPress core code primarily. It shares some of its files with the outside world so that plugins, themes and DearDiary code can easily be modified using GitHub. The core WordPress files though are solely housed within the container and not exposed to the outside world. The whole containers wordpress directory is shared across to the Nginx container though, otherwise Nginx wouldn’t be able to serve the site to you.
• MySQL container. This container holds the database server. It is a self contained system and shares nothing at all with any other container, except a network connection over which the Nginx PHP services connect to ask questions. It’s this container that the script I’ve been working on all afternoon resides though, since it has to adapt database entries if we’re setting up a development environment.
• WordPress-CLI container. This container houses the WordPress command line interface code. This is a seperate system from WordPress itself, but does use the WordPress installation to do its work. This is so that I can run updates and things from a command line if need be. It is also what causes the WordPress cron (scheduled tasks) to operate. Although this bit is still in development. The Patreon Engine and the Migration Engine rely on WordPress cron (scheduled tasks) to operate.
• CertBot container. Finally, this container is responsible solely for keeping the SSL certificates up to date. The Nginx container exposes a couple of directories to this container so that the SSL certificates can be updated if they’re about to expire.

This all sounds complicated but the seperation between the entities is nothing short of fantastic. Instead of me having to deal with one giant amorphous blob of configuration like i have in the past, I know that if I have a problem with SSL certificates expiring when they shouldn’t then something is wrong with the CertBot container. I only need look there.

If the database breaks, I know that absolutely everything to do with the database is in the MySQL container.

Furthermore, each container is logically separated from each other. The MySQL container cannot interfere in any way with the Nginx container. Similarly – and perhaps significantly more importantly, the Nginx container cannot interfere with any files in the MySQL container. They are, to all intents and purposes, separate machines. This means a bug in one container can’t break another container. The isolation between them reduces the damage a hack or a bug can do.

The other final point about Docker for DearDiary should now be clear from the above ramblings too.

In the past, when moving server I’ve had to remember all the different places within the file system that have been changed to configure different services. With Docker everything is stored in my home directory. Everything. Web server configuration – in the home directory. Database configuration – yep, home directory. CertBot configuration – you guessed it, home directory.

And it’s that, which makes storing the whole thing on GitHub possible. So, spinning up a new machine if Vultr hike their prices for example, is as simple as grabbing an up to date database dump, installing Docker (which has no configuration to do anyway!) and cloning the whole thing from GitHub. Within 20 minutes the whole thing is back up and running somewhere else.

It’s brilliant. It’s an absolute gamechanger.