Docker, the ultimate tool
Docker helps organise your site but doesn't guarantee reliability. Learn about containers, persistent data, and maintenance checks for your business.
Sur cette page4 sections
"But it works on my machine." If you've ever spoken to a developer when a site refuses to work anywhere but on their computer, you might know this phrase. It can be perfectly true and not help you at all: your client is using the site online, not the developer's computer.
This discrepancy is exactly why I'm interested in Docker. The idea is to prepare the environment an application needs, then be able to relaunch it elsewhere without manually redoing the entire installation and hoping nothing was forgotten.
If you're interested in the terminology, the Docker documentation details this distinction. But to understand the daily benefit, imagine two projects needing different versions of the same software. Instead of modifying your computer for one and breaking the other, we prepare their environments separately.
The Docker image serves as the basis for starting these containers. You can fix a version and the elements necessary for the project, rather than depending on what is already installed on everyone's machine.
With Docker, we can make development and production work from the same image, adapting the necessary settings. It brings environments closer together and provides a common ground for troubleshooting. We no longer necessarily start with "what did you install on your machine again?".
Differences will remain: real client accounts, access to external services, available power, or permissions. Docker doesn't erase the world around the application. But it allows us not to start from scratch with every machine change, and that's a huge difference when taking over a project.
Except that the application and what it records are not the same thing. Recreating your booking software doesn't recreate the bookings received yesterday. Data must remain separate; Docker volumes notably allow them to be kept beyond the life of a container.
And keeping them on the server is no substitute for a backup. If the server disappears, the question will be "where is the data and how do we recover it?", not "can we restart the box?".
It doesn't do the updates for us, and access still needs to be set up correctly. Container security is part of this work, as are backups and testing after a new version.
When taking over your hosting, this is the workflow I want to make clear. If we have to change servers or revert to a previous version, we know what we're moving, what we're keeping, and what we're checking. Docker can help us a lot with that. The ultimate tool, maybe not; a good way to escape "it works on my machine", yes.
This discrepancy is exactly why I'm interested in Docker. The idea is to prepare the environment an application needs, then be able to relaunch it elsewhere without manually redoing the entire installation and hoping nothing was forgotten.
A little box with everything to run the project
You can think of a container as a machine dedicated to an application, but without rebuilding an entire computer inside. It runs the application with its files and dependencies in an isolated environment, sharing the host system's kernel. That's the difference with a virtual machine: you don't give it its own complete system.If you're interested in the terminology, the Docker documentation details this distinction. But to understand the daily benefit, imagine two projects needing different versions of the same software. Instead of modifying your computer for one and breaking the other, we prepare their environments separately.
The Docker image serves as the basis for starting these containers. You can fix a version and the elements necessary for the project, rather than depending on what is already installed on everyone's machine.
The famous "on my machine" becomes easier to reproduce
Take a form that works during development but crashes on the server. Perhaps the software version isn't the same, or a component was installed on a computer then forgotten during the deployment process.With Docker, we can make development and production work from the same image, adapting the necessary settings. It brings environments closer together and provides a common ground for troubleshooting. We no longer necessarily start with "what did you install on your machine again?".
Differences will remain: real client accounts, access to external services, available power, or permissions. Docker doesn't erase the world around the application. But it allows us not to start from scratch with every machine change, and that's a huge difference when taking over a project.
The box is replaceable, but client bookings are not
One practical side is that you can recreate a container from its image. To update the application, you prepare a new version and then deploy it. We avoid tinkering with an installation where no one knows exactly what it contains.Except that the application and what it records are not the same thing. Recreating your booking software doesn't recreate the bookings received yesterday. Data must remain separate; Docker volumes notably allow them to be kept beyond the life of a container.
And keeping them on the server is no substitute for a backup. If the server disappears, the question will be "where is the data and how do we recover it?", not "can we restart the box?".
What this changes for your site
The most interesting benefit isn't having the word Docker on a quote. It's being able to install, test, and take over the project with an organisation that is understood, instead of a series of manipulations known only to one person.It doesn't do the updates for us, and access still needs to be set up correctly. Container security is part of this work, as are backups and testing after a new version.
When taking over your hosting, this is the workflow I want to make clear. If we have to change servers or revert to a previous version, we know what we're moving, what we're keeping, and what we're checking. Docker can help us a lot with that. The ultimate tool, maybe not; a good way to escape "it works on my machine", yes.
