And here is the second part of the Docker debut

Following my first article, I was now able to run a development environment to create Symfony projects.

Okay, that was all well and good, but for the moment it was only running locally on my MacBook, and that's no way to host a site.

Since shared servers are already a hell of a thing to configure for a simple site, I didn't dare imagine running Docker on them. So I opted for a dedicated server from Scaleway and once I'd placed the order, I installed Docker on Ubuntu 20.04.

I organize the folders on the server, install the tools I'll need (Git among others) and I can clone my part 1 repository running Symfony under Docker.

I run: "docker-compose up -d" and that's it, my dev site is in production!

That's right! Remember, the configuration that works for you locally will also work in production thanks to Docker!

Well, that's all well and good, but now that my site's online, there are two little things left to sort out:

• I don't have a domain name, and to access my server I need its IP address.
• There are no backups of either the site or the database.

Domain name

So let's get it all sorted out. First of all, we need to go to the service that manages our domain name to modify its DNS (Domain Name Service). Here we'll find the domain name with an A category and an IP address. This represents the IP address of the server to which our domain name points.

As you can see, we're going to replace this IP with that of our new dedicated server, so that the domain points to it.

It may take some time for the change to be made, depending on the service provider, but once it's done, we can quickly check that our site is indeed associated with the domain name.

Backup

Great, our site is up and running and in the right place. Now we just need to make backups to make sure we don't lose it, and we'll be good to go!

The idea here is to make a dump of our MySQL database every night, to have it in our set of files (the Docker config + the site files) and then make a global backup of it all.

So we create a cron job on our MySQL container, which will dump the database on a daily basis:

We then create a volume so that this .sql file is among the site and Docker configuration files, and that's it.

Now all we need to do is back it all up, and to do this we're going to use the duplicity command, which enables us to make incremental file backups.

This will create a Tar archive encrypted with GnuPG. This archive will then be uploaded to a dedicated FTP server. Scaleway offers 100GB of storage for backups in its basic package.

This duplicity command will be placed on our dedicated server and will take care of creating the files and uploading them directly every night.

We therefore create a small script on the server and a new cron that will run it every night.

duplicity /var/www/blog ftp://truc.com

That's all there is to it! You've got an environment running on a dedicated server where you can deploy Docker containers and back up all your projects.

Going one step further

The next step you may need to take is to manage multiple sites on a single server. In this case, you'll need to dispatch the different domain names, which will all point to the same server IP.

To do this, we use a proxy that will act as a gateway to your server and automatically send visitors to the right site corresponding to the domain name.

In my case, I used "nginx-proxy" coupled with "nginx-redirect" to manage virtual hosts.

Verdict

Now that I'm beginning to master Docker and see all its subtleties, I understand the hype surrounding this technology.

It's a bit tricky to grasp at first, especially the interactions between each service and especially when you're a pure developer like me who's never really touched the server side.

But you soon get the hang of it after a few coffees, and it's well worth the effort, as the time saved on each project is insane, not to mention the ease with which you can configure just about anything and everything.