So put the binary in the container. Why does it have to be compiled within the container?
replyThat is what they are doing. It's a 2 stage Dockerfile.
replyFirst stage compiles the code. This is good for isolation and reproducibility.
Second stage is a lightweight container to run the compiled binary.
Why is the author being attacked (by multiple comments) for not making things simpler when that was not claimed that as the goal. They are modernizing it.
Containers are good practice for CI/CD anyway.
I'm not sure why "complicate things unnecessarily" is considered more modern.
replyDon't do what you don't need to do.
You realize the author is compiling a Rust webserver for a static website right?
replyThey are already long past the point of "complicate things unnecessarily".
A simple Dockerfile pales in comparison.
That’s a reasonable deployment strategy, but a pretty terrible local development strategy
replyDevcontainers are a good compromise though - you can develop within a context that can be very nearly identical to production; with a bit of finagling you could even use the same dockerfile for the devcontainer, and the build image and the deployed image
replyBecause he spends a good deal of the intro complaining that this makes his dev practice slow. So don’t do it! It has nothing to do with docker but rather the fact he is wiping the cache on every triggered build.
replyMightily resisting the urge to be flippant, but all of those benefits were achieved before Docker.
replyDocker is a (the, in some areas) modern way to do it, but far from the only way.
Increased security compared to bare hardware, lower than VMs. Also, lower than Jails and RKT (Rocket) which seems to be dead.
reply> process isolation, increased security
replyno, that's sandboxing.