Docker is dead

PMc

Aspiring Daemon

Reaction score: 269
Messages: 755

Linux has network namespaces and the company I work for, which is a Fortune 200 company, uses them for a tier 1 application (and Kubernetes and Docker are also used.) Even a developer for 9front, a fork of Plan 9, has implemented network namespaces. People see the benefit, so it is being adopted. It might be something FreeBSD should consider. If someone is looking at an operating system for business and wants/needs to implement something in that way, FreeBSD loses out because it doesn't have what's needed.

Then there are those stubbornly refusing to consider such an idea because they've used FreeBSD for 16 years and can't imagine others have different needs.
Just checked what "network namespaces" are supposed to be. They seem to do exactly what I did with Berkeley 20 years ago - because here it can be done natively. And nowadays it's a lot easier.
For instance: I am sitting here at my machine, I am working on my machine, and I am accessing the webserver on this very machine - via the internet. Or, I am starting my Android gadget, connecting to my WLAN, open a VPN tunnel, again, via the internet, onto my own machine. (The pracical use of these is just testing connectivity, but it shows what can be done.)

Those people who believe they need "network namespaces" just did never bother to understand proper routing. And they will not understand "network namespaces" either; they just know that they need them.
Soon they will notice that nothing works with these either -not because network namespaces are bad, but because of a lack of general understanding- and they will drop the issue and return to Windows.

Who needs anti-lock brakes, power steering, A/C, collision warning, backup camera, and other safety features in a car?
Those who cannot drive.
 

illumulli

New Member


Messages: 2

Opinion may not be warranted, but I have always disliked Docker. While I see it as ugly and inelegant, it also just seems unable to "flow" properly with any system I have used it on. It is like playing an electric guitar in a symphony, which can sound great, but it feels out of place to me. A truly great system in my opinion should not need to rely on third party containerization. Also, I have not tested or looked, but I imagine the memory usage is grotesque compared to native containerization.
 

Hakaba

Active Member

Reaction score: 59
Messages: 144

Before Docker, FreeBSD was not used where I work (and as I am a freelance, I work in some places in the web marketing). The reason ? «Hu... This [specific tool] only work on Linux»
So, OS agnostic is a start condition if a project want mix OSs.

Embrassing Linux tools is not the good solution.
The good solution for me is to help the emergence of a standarized «interface».
A script that make a Docker container on linux, jail or behive on FreeBSD and so on.
Kubernetes can be emulated everywhere. The description of what a user want to do when he use Kubernetes can be standardized.
 

kpedersen

Daemon

Reaction score: 731
Messages: 1,724

they think FreeBSD is the be-all, end-all, and egad! that they could take an idea from Linux because it is inferior.
They have been saying the same about Windows for years. We didn't listen to them then and we don't need to listen to them now.

Jails and Solaris zones aren't application containers
Ah, this is why you like Docker. You don't know that Jails and Zones *are* containers. You should try them out. You might realise that you don't need Docker.

Unless you really pine for Linux Containers then... no FreeBSD Containers are not Linux Containers. They are better because we can run the FreeBSD userland in ours :).

Besides, I am fairly sure most of Docker use is to avoid dependency issues due to sloppy web development sprawl. Honestly a chroot is enough for that. OS level virtualization just to consolidate a shedload of NPM libraries seems overkill.
 

sadaszewski

New Member

Reaction score: 9
Messages: 14

There seems to be a lot of energy in this topic. I don't know if FreeBSD needs "docker" but with this much polarization something surely is up. I don't think I will have much trouble explaining why containerization is not a bad thing.

CONTAINERIZATION RATIONALE

1. Packaging system was mentioned in one of the previous posts. Supposedly "people using container technologies do not know / like / can't use" (apologies if the quote is not exact) packaging systems. This statement has two problems. For one, it is at least debatable if deployment should only involve creating a package. I mean, deployment is not only about software installation but also about running the necessary setup procedures, pre-creating databases, customizing config files etc. Furthermore, those procedures can depend on metadata going beyond what the dialogs in FreeBSD ports can provide (i.e. not a matter of simple switches). If one gets stubborn about all that belonging simply in a custom package then I guess one would also have to reject systems like Ainsible, Puppet, Chef, etc. After all, if everything should be done by means of packaging why not just keep installing the same (potentially updated) package every day or every hour which would make sure that the system is in the right state? Secondly, as far as I know FreeBSD packages do not have a way to set up jails for themselves? Therefore, at the very least, one would either do it by hand all the time (really bad waste of time if somebody is running services just for his friends and is not a career sysadmin) OR create some kind of a wrapper script to create a jail and install required packages inside. Sounds familiar? This is essentially what container build systems do. Only it consists of running whatever commands you like but if you choose to only install packages then I guess you would have your dream workflow?

2. Containers are not only about setting up a couple of services. They are also about ISOLATION. Both "physical" (chroot, namespaces, separate IP or VNET, etc.) and logical (the way container projects are organized allow to easily look at a cross-section of the entirety of the customizations / diff to a base system image). Layers make a big part of that logical isolation where you can group different customizations into certain themes. FYI focker allows you to use --squeeze parameter when building images or compositions in order not to use layers at all. With that switch you can have a plain image / jail builder with the output not much different from existing solutions. However, the WORKFLOW is much different / better IMHO.

3. The trio of images, containers and volumes is simply a very nice abstraction. Much more natural than "template jails" in BastilleBSD etc. You simply don't need any "templates". You can just base any image on any other image and then create a jail off of any image. Easy. Then if you want persistence you throw volumes into the mix.

4. Volumes are a wonderful approach to isolate the real data that you care about from the rest of the jail. I cannot stress how happy I am that now when I want to move to a new machine I know precisely what I need to copy over. I just grab all my focker volumes + my Git repository of Fockerfile's etc. Then I don't even need / want to take the old images as I will be at the same time updating to the new version of FreeBSD so it is good to run the build scripts again and let them pull in new versions of software. Perhaps they will also require some gentle tweaks, etc. For me this is a great workflow.

Please give https://github.com/sadaszewski/focker/ a try. Also star it on Github if you please, it will help it gain visibility / recognition.
 

rootbert

Active Member

Reaction score: 55
Messages: 202

Ah, this is why you like Docker. You don't know that Jails and Zones *are* containers. You should try them out. You might realise that you don't need Docker.
here is a free tipp for you: since you don't know what application containers are, read up on application and system containers.

Unless you really pine for Linux Containers then... no FreeBSD Containers are not Linux Containers. They are better because we can run the FreeBSD userland in ours :).
... is like saying green is better than blue. ever heard of projects with different requirements?

Besides, I am fairly sure most of Docker use is to avoid dependency issues due to sloppy web development sprawl. Honestly a chroot is enough for that. OS level virtualization just to consolidate a shedload of NPM libraries seems overkill.
Yes, thats one nice feature: similar to FreeBSDs compat-* we can run legacy containers and separate dependencies like with jails. But now I am really not sure you understood the difference between chroot and jails, another tipp: read up on jails, https://www.freebsd.org/doc/handbook/jails.html
 

kpedersen

Daemon

Reaction score: 731
Messages: 1,724

Yes, thats one nice feature: similar to FreeBSDs compat-* we can run legacy containers and separate dependencies like with jails.
Exactly and we can do it natively with jails. So you agree with me. We don't need additional bloat like Docker.

(There is a reason why Docker's logo is a fat whale ;)

application containers
Jails are containers (hopefully you agree). "Application" containers is a buzzword unique to things like Docker. Docker is not a standard. What Linux has (for a few weeks perhaps) is LXC. *That* is the container technology. Docker is the... set of scripts making it fun and easy to use with a little bit of IPC to control the madness.

What are the cool kids calling it these days? System Container? Infrastructure Container? Whatever. Jails are *the* solution on the FreeBSD platform. Like I said before, give them a try.

ever heard of projects with different requirements?
Yeah, it rhymes with "bad solution" and "microservice anti-patterns" right? (I am trolling) ;)

Don't get me wrong, if I was stuck with Windows, macOS or Linux, I probably would look into using Docker because there is no way in hell I would waste my time learning how to do things "natively" on those platforms. It just so happens that I like FreeBSD and it evolves at a stable enough pace that I can keep up with it and do things without much non-standard 3rd party software. From experience this gives so many benefits in terms of future maintenance and security.
 
OP
D

drhowarddrfine

Son of Beastie

Reaction score: 1,455
Messages: 3,516

ever heard of projects with different requirements?
If one has a specific need for a specific program that only runs on one specific operating system then one should choose that operating system. But one can do the same thing on FreeBSD with jail with little to no thought.

I don't read on Linux about those users desiring jail so much that they want jail there. Why the desperate need for it here. Because Linux told you so?
 

kpedersen

Daemon

Reaction score: 731
Messages: 1,724

The ZFS on Linux (ZoL) port is healthy and maturing. However, at this point in time it is not recommended to use the zfs Docker storage driver for production use unless you have substantial experience with ZFS on Linux.
https://docs.docker.com/storage/storagedriver/zfs-driver/

I actually didn't realize that Docker would be completely inadequate for ZFS in production.

I don't read on Linux about those users desiring jail so much that they want jail there. Why the desperate need for it here. Because Linux told you so?
Probably because FreeBSD users are actually happy with their OS of choice and don't want to mince it into other operating systems!.
Docker users have moaned about getting it on the Windows platform for some time. Before Microsoft threw them WSL they used to use VirtualBox as a "compatibility layer". Frankly, they can do the same here (if there was enough effort...)
 

rootbert

Active Member

Reaction score: 55
Messages: 202

Docker is not a standard. What Linux has (for a few weeks perhaps) is LXC. *That* is the container technology. Docker is the... set of scripts making it fun and easy to use with a little bit of IPC to control the madness.
That is not correct. Linux container technology is actually cgroups and namespaces. LXC (is the Linux equivalent of FreeBSD jails) is the system container solution based on cgroups and namespaces. Docker is the application container solution based on cgroups and namespaces.
Just as a note: I hate Docker! Docker did so much wrong in so many ways, it is the best example of what is going wrong in Linux land. However, the technology is great, and there are developers out there who realized that Docker is awkward. Noone wants to have a big fat daemon running with root privileges just to do containerization. And luckily, some really cool projects emerged from this: I like podman where you can run those app containers without any daemon or script, on a users perspective it looks like what I call "the new statically linked, sandboxed binary" ... it is just a small, secure environment (compared) to run those OCI-standards based containers.

Don't get me wrong, if I was stuck with Windows, macOS or Linux, I probably would look into using Docker because there is no way in hell I would waste my time learning how to do things "natively" on those platforms. It just so happens that I like FreeBSD and it evolves at a stable enough pace that I can keep up with it and do things without much non-standard 3rd party software. From experience this gives so many benefits in terms of future maintenance and security.
Me neither, I am a big fan of jails, it was the technology which got my attention in the FreeBSD 4.x days and made me switch quite a few systems. Fully agree here, I would not want to tinker with Windows ... no idea about macOS, I have not spent more than maybe 50 hours on macos because it just made me sad how Apple crippled everything, especially in the more recent years. appcontainers are native in Linux, so I have no problem with that. Most of the software we use is available to both Linux and FreeBSD, so for system containers we use jails, for app containers we (have to) stick to Linux. Solaris zones is also a great technology, and I could imagine it would also be a great base for app container technology. We used them quite heavily when Solaris 10 was released, but at some point we realized that Solaris had an uncertain future, and since the best Solaris tech is in FreeBSD we switched ... from a business perspective relying on a handful of opensolaris developers is risky so we fully agreed with the management.

When I tried LXC the first time it was a nice experience, however, we just had to wait for the first major upgrade that broke every damn container, so we went back to jails on many services ;-) Same happened with Docker (at the time where docker was more or less "the standard" in the Linux app container landscape), however, a switch back to system containers was not feasible, it would have been too much work, fixing the docker api breaks first and then looking for an alternative was easier.
 

Jose

Active Member

Reaction score: 55
Messages: 145

1. Packaging system was mentioned in one of the previous posts. Supposedly "people using container technologies do not know / like / can't use" (apologies if the quote is not exact) packaging systems.
Really? This is beyond lazy. Here's what I actually said: "Docker is for those who fear and don't understand packaging and wish it would just go away."

...deployment is not only about software installation but also about running the necessary setup procedures, pre-creating databases, customizing config files etc.
All reasonable packaging systems include the capability of running arbitrary scripts in Turing-complete languages. You're not thinking clearly if you think you need more than this.

Furthermore, those procedures can depend on metadata going beyond what the dialogs in FreeBSD ports can provide (i.e. not a matter of simple switches).
Example?

If one gets stubborn about all that belonging simply in a custom package then I guess one would also have to reject systems like Ainsible, Puppet, Chef, etc.
False. I invoke pkg(8) in my Ansible scripts all the time. It's easy and it's fun. Try it! Chef and Puppet are nassty Ruby Hobbitses. Consulting rate goes up if you make me use them.

Please give https://github.com/sadaszewski/focker/ a try. Also star it on Github if you please, it will help it gain visibility / recognition.
Done! And thanks for all your work on this.
 

neel

Member

Reaction score: 29
Messages: 91

Here's the truth about Docker: It's a Linux-centric solution for a Linux problem: distro fragmentation. GNU/Linux distros regardless of use case have been incompatible in the most minor ways, making lives hard for application developers. Trying to standardize minor details on Linux has been hard and with little success, while *BSD, Windows, and macOS have avoided these issues for the longest time.

Docker on the server and Snap/Flatpak on the desktop is a way to hide Linux fragmentation, containing it via OS-level virtualization. In this case, a developer only has to worry about a so-called "single platform". It doesn't solve it at all, just hides it.

If everyone using Linux servers instead used FreeBSD (or about anything else), Docker as it exists today wouldn't even exist. Why? FreeBSD/*BSD variants and Windows don't have distro-level fragmentation to the extent GNU/Linux has. However, if Docker is cool developers will use it even if this means apps from GitHub don't work on *BSD.

A particular BSD variant is more or less similar across versions, userland, packaging manager, etc. Derivatives like pfSense or FreeNAS still maintain compatibility with their source for the most part. However, some incompatibility is still tolerated between versions or within "derivatives" like pfSense versus stock FreeBSD, as long as they don't go far enough to become a separate variant.

On Windows, you explicitly have a single source (Microsoft), and on top of that, backwards compatibility is literally a make-it-or-break-it, to the extent that legacy Windows 95/NT 3.1 apps can run unmodified on the latest Windows 10 Insider build.

I don't know much about Solaris/Illumos so I won't comment on that.

If the world ran FreeBSD instead of Linux, Docker would be more of a Ansible rolled in to a Jail manager. If it were a Windows world, I'm not sure, I've only been using Windows more in the past few months thanks to a day job (see disclaimer) and "Windows Containers" are still new when compared to their Unix equivalents.

Disclaimer: I work at Microsoft, not on Windows or Azure (at the time of writing). I still develop at work using the Windows/.NET/Azure stack as opposed to a FOSS stack.
 

Jose

Active Member

Reaction score: 55
Messages: 145

On Windows, you explicitly have a single source (Microsoft), and on top of that, backwards compatibility is literally a make-it-or-break-it, to the extent that legacy Windows 95/NT 3.1 apps can run unmodified on the latest Windows 10 Insider build.
It is truly remarkable how binaries compiled 20 years ago will still run unmodified on modern Windows.

On the other hand, the original killer use case for virtualization was that damn legacy app running on the Windows server that had to be rebooted daily. Snapshots or "layers" in Docker parlance are also pretty awesome when that same app tends to crash and corrupt its data every so often.

I still think you should fix the problem rather than working around it, but you don't always have the time, and often don't have permission to do that.
 

sadaszewski

New Member

Reaction score: 9
Messages: 14

Really? This is beyond lazy. Here's what I actually said: "Docker is for those who fear and don't understand packaging and wish it would just go away."


All reasonable packaging systems include the capability of running arbitrary scripts in Turing-complete languages. You're not thinking clearly if you think you need more than this.


Example?


False. I invoke pkg(8) in my Ansible scripts all the time. It's easy and it's fun. Try it! Chef and Puppet are nassty Ruby Hobbitses. Consulting rate goes up if you make me use them.


Done! And thanks for all your work on this.
Thanks! There is one more clear and I guess overlooked advantage to Focker as compared to Ainsible etc. It has virtually no learning curve. Yes, you just write commands to make your jail look the way you like and that's it. The only two directives you need to master is "run" and "copy". Ainsible's documentation has dozens upon dozens upon dozens of pages. For someone requiring a clean, concise, easy to maintain solution, Focker is clearly the way to go ;)

As to the example for metadata it could be anything but for me the most important is actually the introspection ability of focker-compose.yml files which lets me for example to automatically set up HTTP(S) reverse-proxying for all the defined jails. Sure you can do that for whatever but then you have to write a sort of focker-compose.yml file anyway so why not just use Focker from the start. That's sort of the point, it is so minimalist that you can only make your life more complicated by using the alternative solutions. Sometimes it might be necessary but not in my and I would guess not in 99% of the people's use cases. And in that 1% of the cases I would use Ainsible to deploy Focker ;)
 

Jose

Active Member

Reaction score: 55
Messages: 145

There is one more clear and I guess overlooked advantage to Focker as compared to Ainsible etc. It has virtually no learning curve. Yes, you just write commands to make your jail look the way you like and that's it.
This to me is a bug and not a feature. I've run into too many "engineers" that had no idea how things they had written and deployed worked. It's all fun and games until you run into a problem you can't fix. That is when all the technical debt you incurred by doing things the fast and easy way comes due.
 

sadaszewski

New Member

Reaction score: 9
Messages: 14

This to me is a bug and not a feature. I've run into too many "engineers" that had no idea how things they had written and deployed worked. It's all fun and games until you run into a problem you can't fix. That is when all the technical debt you incurred by doing things the fast and easy way comes due.
To me Focker is supposed to be a self-service tool. So essentially you should take care of educating yourself enough to be able to configure a jail with shell commands. I am not a fan of publishing applications in the form of ready-made containers. However if you would like to use them in your deployment then it would still be up to you to verify that the recipes generating them are correct and work as expected. Anyway I have a great idea how to avoid the entire "binary blob" download thing. I will keep you posted :)
 
Top