Sure you could convert later, but now you have to move your whole workflow over during a time you're in dire need of the new features instead of casually from the start. Now instead of your artifact history being consistent, its truncated at the point you switched over.
I guess I don't understand whats so complicated about docker?
Maybe the deployment is on "pet servers" and not on-demand, which means if you are a responsible admin and have a nftables config you need to analyze how docker will mess up your rules (or why it is not working).
Maybe you don’t want to lose time setting up an artifactory, and a docker registry with proper access controls.
Maybe you don’t want to have to focus on the ops side of things until you actually need it. Yes that may mean losing time later when you need it fast, but at the same time this can be done iteratively when things are ramping up.
From experience at a previous workplace, using docker as part of your local development process can be a huge PITA, and getting developers to adopt it without grumbling and complaining about it every day is also a hurdle. Given enough computers, you will get weird network errors, some borked modules due to an upgrade, some containers refusing to die, etc…
I am not saying it cannot be done, and in the general case docker mostly works without (too many) glitches, but it is always another layer that hinders your productive work.
(also, "docker" in production nowadays is mostly a shortcut for k8s, and that is a whole new amount of investment required)
It didn't help that Docker tied docker compose to swarm and then swarm kinda died. So I'm really scratching my head at the people recommending docker in this thread. I'm assuming they mean K8S but at the same time surely they can't be serious.
Today if you need something at the startup/mid range level you're probably looking at Dokku, Caprover, or maybe even nomad. This is still more complexity than scp, of course.
You get turn key environments with a ton of flexibility for what is honestly much less effort than even maintaining the setup documentation for installing the apps directly.
Overlay filesystem performance across distros?
Attaching a debugger to a process?
Idk. Just some ideas off the top of my head. I don’t think it’s unimaginable to consider how docker is an increase in complexity and understanding.
You can just use --net=host if you don't like it.
> Overlay filesystem performance across distros?
I've used docker on several distros and never noticed an issue with this.
> Attaching a debugger to a process?
This is also not an issue if you don't use bridge networking.
I imagine one could install GDB in the container and connect to it remotely? Or from the container's shell?
IIRC, you just need to install gdb when you build your image and use `docker run -it bash` to run any shell commands in your container
Since the remote stuff is sometimes an incredible pain to set up and use, I usually install gdb and just use its CLI in the container. That's usually trivial in comparison, and it's a decent skill to learn regardless since so many debuggers use a similar CLI UX. It's extremely cross-platform and cross-language, so you can just jump on a new thing and be a wizard from day 1.
Using legitimate tools to handle building and deploying has nothing to do with Docker, but the author of this blog post has combined them.
Without this, deployment starts being spread over various bash files with often poor documentation (they’re already mentioning such a script in their article). Then when it becomes too messy, time to write that Dockerfile I guess, except now it’s more complicated than if it had been done from the start.