You can have multiple instances of the server running on the machine without interfering with each other.
You can limit file system access for the server to only a certain folder.
You can similarly limit port access and manage conflicts (e.g. multiple servers can think they are listening on a certain open port but those are mapped to something else on the host).
If you have multiple machines with different operating systems or even architecture you can deploy your server as a container more easily on them without needing to rebuild or test for each one.
You can have the same environment running locally while development or on CI servers without complicated setups.
The system can scale out a lot more easily to hundreds/thousands of machines if you decide to use something like Kubernetes.
You have to login to some docker repository anyways and know the series of commands to actually run it. Cloning a repo and running a shell script is probably a lot easier and faster than that.
What kind of work are you doing that requires really fast auto scaling? Is a few minutes to spin up a new instance really that cumbersome? Can you not signal for it to spin up a new instance a tiny bit earlier than when it's needed when you see traffic increases?
> You have to login to some docker repository anyways and know the series of commands to actually run it. Cloning a repo and running a shell script is probably a lot easier and faster than that.
In isolation, yes. But if, for instance, you're already running a container orchestration tool with hundreds of containers, and have CI/CD pipelines already set up to do all of that, it's easier just to tack on another container.
Ok when you say a few off the top of my head it implies that there are a bunch and these are like some super obvious ones, but it sounds like this is actually only useful if you have a bunch of infrastructure set up to serve sites for projects and customers that need containerization and then you just throw this simple little static site docker instance in there because when you're maintaining a lot of docker instances it is just simpler to do?
Which seems like sort of an edge case for value adding, and makes me feel like it really doesn't add any value to do this unless you already are doing it for everything, and thus you really wouldn't be throwing out any value by just serving the static site without the docker overhead.
Adding to some of the other responses, one reason I chose to deploy a SPA I'm working on as a Docker image is atomicity - if I want to deploy a newer version I simply switch out the tag in my container orchestrator's config (Nomad in this case, but the same principles apply to k8s and friends) and it's guaranteed that the new deployment will be pristine, without the risk of leftover files from a rsync or similar - and if I need to roll back I do the exact same.
There’s value in that, but you don’t need Docker with its related debugging and maintenance overhead to get it. NixOS, among other tools, will do the same thing while constructing a “flat” operating system image.
Anything else, though? There’s got to be more to it than that, or it wouldn’t be as popular as it is.
You can limit file system access for the server to only a certain folder.
You can similarly limit port access and manage conflicts (e.g. multiple servers can think they are listening on a certain open port but those are mapped to something else on the host).
If you have multiple machines with different operating systems or even architecture you can deploy your server as a container more easily on them without needing to rebuild or test for each one.
You can have the same environment running locally while development or on CI servers without complicated setups.
The system can scale out a lot more easily to hundreds/thousands of machines if you decide to use something like Kubernetes.