> Am I alone here? Am I doing it wrong? Is it the case that I am not the intended audience, and it's meant for larger teams?
No. Probably not. Maybe, but also probably not, you may just not have had the "Ah-hah!" moment. A lot of technologies are like that.
Take any random Windows or Linux server someone else has built. Log in to it. Now tell me how it was built such that that build can be reproduced on a slightly different platform, e.g.: a different processor or base image.
Good luck with that.
Traditional operating systems are write only. Trying to get the configuration back out after the fact is effectively impossible in the general case.
Even if you have a "scripted process", "policy", "documentation", or "declarative state configuration", drift occurs anyway because of things such as disk corruption, updates applying out-of-order, different levels of updates, quick fixes/tests, etc, etc...
It is basically impossible to keep a large fleet of supposedly identical machines identical.
As a random example from the Windows world: I've seen Group Policy applied to user accounts such that when an admin user logs on to a server, that triggers an on-login install of some software. Could be anti-virus, a print utility or whatever. Suddenly pristine servers become... not so pristine.
People have tried to work around this kind of thing... clumsily.
For example, in the Windows world you can build standard operating environment (SOE) disk images for servers using a tool like System Center Configuration Manager (SCCM) task sequences. This can deploy Java runtimes, ODBC drivers, or whatever you business app needs. (Linux has things like Packer)
The principle is fine, the implementations however are terrible.
A complex SCCM Task Sequence might run for hours and then fail at step number 57 out of 83. Fix it, start from the beginning.
Oops, failed again after several more hours. Fix it, try again.
Success! Now step #62 is failing. Fix it, try again.
This can mean days down the drain. Wouldn't it be just awesome if the build system could take snapshots of the VM at each step, so that it could restart at the last known good step, making the edit-build cycle super fast?
Docker does that.
Build systems like SCCM task sequences or Packer aren't typically parameterised, or the parameters are "baked in" at build time, and/or get passed at annoying points such as a very early "network boot" step, which has technical and security limitations.
Docker does the right thing, simply passing in parameters as environment variables at runtime. This allows one image to be used in many environments, without changing it. If you test something in UAT, then production will by byte-for-byte identical (SHA256 hashed!), except for the minimum required config changes.
Typical build systems produce a single opaque binary image. This could contain anything, and the "link" to the source script that produced that build is immediately lost.
Docker maintains the step-by-step build script that lead to the final docker image, in the image itself.
Typical build/deployment systems require "full VMs" and associated images, which start from merely big at ~32 GB and go up to a way-too-big ~127 GB as is the typical case for servers in the cloud. These are mostly blank space, and need the wiggle-room for things such as after-the-fact updates.
Docker maintains an efficient content-addressed store of image layers. A small change on top of an existing chain of image layers might need just tens of megabytes. Deploying this to the production environment similarly requires only tens of megabytes, allowing very efficient blue-green deployments rolled out automatically via dev-ops. Existing deployments are maintained as-is and there's no side effects of a roll-back. Compared to this, updating any shared framework or system-wide installed component is very risky on any traditional operating system.
Traditional server management ends up growing "paperwork" and "processes" like crazy. This is required to work around the risks listed above. So for example, changes have to be submitted to a change control system, but this is not enforced in any mechanical way. The paperwork can say "X", but the physical change can be "Y". Or details may not be present. Or whatever.
Docker lets you check the "dockerfile" into Git. That's authoritative, versioned, and can be made subject to mandatory branch security policy such as forced code review. It can be set up such that no paperwork is needed. The code is the code, and if it's in the "main" branch it has been reviewed. The image it builds is the image that is in production, end of story.
DISCLAIMER: Having said all of the above, I have literally never deployed containers in production, despite working in the cloud for years. My issue is similar to yours: I'd have to convince a lot of people to change their fundamental workflow and embrace a "different way of doing things". This can be challenging, especially in large enterprise with unmotivated staff, unions, third-party support contracts, etc...