Re:Goodbye Docker and Thanks for all the Fish
by jskaggz on Monday March 11, 2019 @02:00AM
(#19356993)
+1 tannhaeuser. I live in a more heterogeneous environment than what docker can provide, and it seems to me that the ground docker covers is like you said, application packaging. This is frustrating since in a lot of cases, "applications" are only being provided as docker images. What the heck can I do with a docker image on something that doesn't provide docker? How do I have assurance that when teams pull docker images in from the wild, that they're actively maintained and not full of 0-day vulnerabilities? I've switched to pkgsrc and highly recommend it for solarish (and solaris), *bsd, centos, debian, mingw+windows, osx and whatever else one would feel like building binaries and dependencies for. The key to me is separating the operating system package manager, and the application dependencies such that when operations runs their mandatory apt/pkg/yum/dnf/whatever updates it doesn't break application dependencies. And on the flip side when applications want to screw with things that aren't in apt/yum/etc those custom needs can be met. This approach also doesn't preclude using the respective os container mechanism (zones/containerd/vmware/hyperv/chroot/etc). We package custom internal packages in our own internal pkgsrc repo, along side of the main repository that provides north of 10,000 packages.
More people should become hip to pkgsrc.
Re:Goodbye Docker and Thanks for all the Fish
by fxfan on Sunday March 10, 2019 @08:51AM
(#19351728)
So only to get on the the same page as you and not to be a smartass- you're saying Docker is like an AppImage without access to host files (I didn't get the last part about GPL circumvention) whose purpose is to provide non-emulated VMs?
If all I use is Debian on my server with a file that always installs the required packages and I don't need isolation between services, should I care about docker as an "end-developer"?
Re:Goodbye Docker and Thanks for all the Fish
by tannhaeuser on Sunday March 10, 2019 @09:56AM
(#19351994)
Difficult to tell. I'd probably stay within a plain dev environment as long as possible. Just keep in mind you can't rely on host auth within Docker if you ever wanted to use it. Besides, it's never wrong to learn something new, and Docker isn't difficult to pickup.
Re:Goodbye Docker and Thanks for all the Fish
by ecnahc515 on Sunday March 10, 2019 @10:33PM
(#19356240)
Often times you want to run a newer version of a package but it has new dependency requirements that conflict with other packages. Most solutions around this involve tweaking the package, or using a chroot. A container lets you avoid this problem as each container has it's own rootfs and can be a different OS and can run different versions of software however you want without worrying about conflicts.
It's somewhat similar to static linking, but at a higher level.
The other thing that Docker does is run in a namespaced environment such that apps don't have access to the local file systems on your host by default. This is also a problem that's been solved since the dawn of Unix by eg. using file permissions (though admittedly not every scenario is served well). Docker apps don't have access to the host's access control infrastructure (/etc/password, pam, etc.) though, so Dockerized apps need to invent their own ad-hoc auth.
The only problem that Docker is really solving is that you can pack more apps on a single host compared to full-blown VMs. Basically, Docker is infrastructure for cloud providers to sell you lots of pods cheaply (for them, that is). Since many images are based off Debian (pull in deps via apt on first start), it could also be argued that Docker is acting as GPL circumvention device of sorts.