31–40 of 95 posts
Earlier quoted context omitted.
>Anyway, I didn’t necessarily blame Docker for it, but it did add force to an argument I’d heard before: Why does Docker need a daemon at all?
Well for one, it can restart the container when it fails or on boot up. I don’t see how having no process minder improves anything, you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too.
Earlier quoted context omitted.
>Anyway, I didn’t necessarily blame Docker for it, but it did add force to an argument I’d heard before: Why does Docker need a daemon at all?
Well for one, it can restart the container when it fails or on boot up. I don’t see how having no process minder improves anything, you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too.
You certainly could.
I’ve managed to resist the hype and still not ever used docker for anything ... I still really struggle to understand what the practical benefits to this kind of containerization actually are ... It seems like people reach for it because they want to have some kind of “compile target” into which they can stick “all the things” their application needs to run — which is supposed to then help them “deploy” into their de…
Here's why I started using it years ago. I had a CentOS 6 machine that I wanted to run Plex, Subsonic and Transmission on, but I couldn't, because they had different (EDIT: and conflicting) requirements for various packages. I might have been able to hack it, but it was looking really tricky.
Enter Docker. I have all three running in separate Docker containers. And it just works. I've never hand a single problem. I made a yum exception for the Docker packages I use, so I can control when they are updated, which is about once a year.
The alternative was to build a new box that met all the requirements, but that seemed like a big waste of resources (electricity and my money).
Earlier quoted context omitted.
>Anyway, I didn’t necessarily blame Docker for it, but it did add force to an argument I’d heard before: Why does Docker need a daemon at all?
Well for one, it can restart the container when it fails or on boot up. I don’t see how having no process minder improves anything, you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too.
Docker is the Myspace of container engines. It's stupidly unreliable, at least on MacOs. I've resorted to running system prune every week or so to keep it from getting totally out of control. Reminds me of NPM and rm-rfing node_modules on every build. I can't wait till something comes along to replace it.
He replaced Docker with something that's basically the same thing?! I don't get it.
I’ve managed to resist the hype and still not ever used docker for anything ... I still really struggle to understand what the practical benefits to this kind of containerization actually are ... It seems like people reach for it because they want to have some kind of “compile target” into which they can stick “all the things” their application needs to run — which is supposed to then help them “deploy” into their de…
> Don’t you still inevitably end up having to manage assumptions about the differences between these environments in order to make this work in practice...?
Yes, and I would do that regardless of my deploy target. If you follow the Twelve-Factor App methodology [1], your settings are always in a config file or passed in as environment variables. If you're using external services (e.g. Stripe) while developing set the appropriate variables to your test credentials.
> Do you actually get any good abstractions out of the container which empower better solutions to deployment challenges? “I don’t have to think about which hosts the (random) http client used in my application is configured to talk to because I can just magically retarget it at the container level by manipulating networking configuration”
The solution to this problem is the same regardless of whether you use Docker or a cloud provider. Use a load balancer to direct traffic to a group of hosts responding to a specific port.
> And what about the impact to developer ergonomics?
Admittedly, debugging is not perfect (at least not with my Docker Compose setup in PyCharm). That said, there are debuggers that attach to Docker containers.
I’ve managed to resist the hype and still not ever used docker for anything ... I still really struggle to understand what the practical benefits to this kind of containerization actually are ... It seems like people reach for it because they want to have some kind of “compile target” into which they can stick “all the things” their application needs to run — which is supposed to then help them “deploy” into their de…
Docker is the Myspace of container engines. It's stupidly unreliable, at least on MacOs. I've resorted to running system prune every week or so to keep it from getting totally out of control. Reminds me of NPM and rm-rfing node_modules on every build. I can't wait till something comes along to replace it.
I've been using latest Docker, sometimes with the bundled Kubernetes on macOS for years without such issues. Of course it's still just a Linux VM.
Earlier quoted context omitted.
Well for one, it can restart the container when it fails or on boot up. I don’t see how having no process minder improves anything, you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too.
> you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too. You certainly could.