Docker is dead

sadaszewski All that sounds like typical Linux-like work--taking Docker stuff and building into jails which is redundancy and complication. Especially introducing foreign software where one has native and better working software.

Just use the superior jail and be done with it.

Please explain.

I never had a glance at that "docker". I now had a short look thru the piece which sadaszewski presents. And, as far as I seem to understand, it is a scripted builder for jails, including their applications (e.g ports) and including their config. So to say, a configuration database.

I once had a customer, and they had decided to put all their configurations into a database, and that was their desaster plan. So if they would loose a mirrored compute-center, they would just run the database, and thousands of machines would automatically self-install and go productive. (They were big enough to go thru the effort to write the necessary interfaces.)

So there is certainly a use-case for such an approach. I don't know if we already have tooling that could do such. But if not, this here might be developed into something, and, if done properly, it might rock (but then it should be called rocker ;) ).
 
Docker is for those who fear and don't understand packaging and wish it would just go away. It's the logical conclusion of the download everything and pipe it into a root shell until things start working approach. Docker automates this shotgun packaging and yields opaque binaries you can download automatically and run on your systems with no knowledge of how they were built or what they contain. What could possibly go wrong?
 
It is true that some people use it like that (e.g. researchers, as explained by someone on this forum).
However, it does not mean that everyone HAS to use it that way.
And in the companies I've worked for, it was NOT used like that.

Docker is for those who fear and don't understand packaging and wish it would just go away. It's the logical conclusion of the download everything and pipe it into a root shell until things start working approach. Docker automates this shotgun packaging and yields opaque binaries you can download automatically and run on your systems with no knowledge of how they were built or what they contain. What could possibly go wrong?
 
Docker is for those who fear and don't understand packaging and wish it would just go away. It's the logical conclusion of the download everything and pipe it into a root shell until things start working approach. Docker automates this shotgun packaging and yields opaque binaries you can download automatically and run on your systems with no knowledge of how they were built or what they contain. What could possibly go wrong?

Unfortunately we don't have docker in FreeBSD, so from some comments, especially this one, we can conclude that quite a lot of people don't really know what docker is or think that it is equivalent to jails, however, it is not. Let's just not call it docker, let's say container. Docker is just one provider or runtime where you can run open-container-initiative (OCI) based containers. Docker is actually a bad example, rkt (dead) or podman are showing us how it is done right (my opinion). We have jails, so this is an amazing technology where we could base our own container solution. I am afraid I cannot clearly express what advantages containers have, but I will try in a few sentences.

Consider you have a repository to download your containers. Someone was offending docker.hub, but most commercial providers offer their own hub, so no need to worry when docker hub vanishes. A container is a layered "archive", with eg. a base layer (for instance ubuntu), then the application installed on another layer, then on top your own layer with scripts or other stuff - similar to unionfs, but all in a package. Also, most projects choose a minimal system, so there is no init in the container, no other tools, really just the basic service and the libraries. So running that package guarantees that you are running always the same container. The advantage? - I can run them unprivileged, restrict i/o per second, network, ram, cpu usage. It is testable: we commit our code to gitlab, gitlab-runner builds the container, the containers spins up, tests are being made, if the tests are ok the container is pushed to our docker repository. Clients then do a "docker pull" which is equivalent to "pkg upgrade" and be done. Upgrades are simple because just the delta is synced, the rest of the layers is already on the client machine running the old version. The cool thing about that is we run them on client servers as well as the cloud. Setting it up in this way is much less work than doing equivalent thing with jails. It guarantees that our client - no matter if they run ubuntu, red hat, gentoo, void or any other linux distribution can use the software. For jail? yeah, deliver a 12.1 release jail tarball and get a call from your client because they are still on 10.2. And good luck if you ship a bunch of services in 20 jails and you send your client the jail.conf who then realize that the network we tested it with cannot be used in their environment because it's their prod DMZ - ask the customer what network we can use to send them the right network jail? - no way. Just a short note ... I could write on and on but then I would rather make one of those gazillion blog posts describing the concept of application containers.

It's just sad that we don't have it in FreeBSD because FreeBSD would be perfect for such stuff ... the base technology is there. Why just use FreeBSD for traditional hosting when it would also be a great "cloud" hosting solution. Not everything in Linux land is bad, and not all container runtimes are bad. The market for this is huge, and some more attraction to FreeBSD would not be too bad.
 
The articles in the very first post claims that Docker is already dead and everyone is flocking to Kubernetes. But Google can change their mind--or when Microsoft completely absorbs Linux--then one will chase the next Linux or Windows tech that reddit is telling you to use NOW!

More and more I find people here drooling over Linux things instead of what we have ourselves. If Docker never makes it to FreeBSD, what are you going to do? Switch to Linux? I guarantee Kubernetes will never make it here so will that make you switch cause why? 1) It can't be done on FreeBSD at all? or 2) You can do it on FreeBSD but ... but ... it's not Docker!! It's not Kubernetes!!
 
Unfortunately we don't have docker in FreeBSD, so from some comments, especially this one, we can conclude that quite a lot of people don't really know what docker is or think that it is equivalent to jails...
Please tell me more about what I know and don't know. This is fascinating!

I am afraid I cannot clearly express what advantages containers have, but I will try in a few sentences.
Where have I heard that before?

A container is a layered "archive", with eg. a base layer (for instance ubuntu), then the application installed on another layer, then on top your own layer with scripts or other stuff - similar to unionfs, but all in a package.
This is really awesome when the Docker container is running your CI system, and every build creates a new layer. It's ok, though 'cause the genius that set it up took this into account and figured out how to prune layers automatically, right? No! I discovered this monstrosity when the build system failed in the middle of the night.

Also, most projects choose a minimal system, so there is no init in the container, no other tools, really just the basic service and the libraries.
This is one of the biggest Docker lies. Fact is, most people discover very quickly that it's very hard to troubleshoot any such lightweight system, and wind up packaging up a whole Linux distro in their "lightweight" container. This was Ubuntu early on, but now lightweight distros like Alpine have gained popularity for this reason.

...we commit our code to gitlab, gitlab-runner builds the container, the containers spins up, tests are being made, if the tests are ok the container is pushed to our docker repository. Clients then do a "docker pull" which is equivalent to "pkg upgrade" and be done.
So basically production deployments are a side effect of commits to your source tree. I ask again, what could possibly go wrong?

...then realize that the network we tested it with cannot be used in their environment because it's their prod DMZ - ask the customer what network we can use to send them the right network jail?
Docker's network 🤷‍♂️ is a feature. Got it.
 
This is one of the biggest Docker lies. Fact is, most people discover very quickly that it's very hard to troubleshoot any such lightweight system, and wind up packaging up a whole Linux distro in their "lightweight" container. This was Ubuntu early on, but now lightweight distros like Alpine have gained popularity for this reason.

I have to admit that lots of people use docker the wrong way ... just because you can do lots of (awkward) stuff does not mean you have to do that. alpine is great, and so would a nanobsd based container be.

And yes, unfortunately docker is a valid reason to choose linux for various requirements, and at least with all my clients the environment surrounding container technologies is becoming more and more important. I have no problem with someone porting kubernetes to FreeBSD, if there is a usecase why not. However, implementing a nice slick container technology based on FreeBSD jails is quite simple compared to kubernetes.
 
There's quite a lot of Linux bashing, here and in the mailing lists, way beyond reason!
And this is quite counter-productive: there are certainly bad things in Linux, but also very good ones.
And not just Docker: also package management, for instance.
Throwing the baby out with the bath water is the best way to miss good ideas and improvement opportunities.

All I read is fear from some (I won't name names) is they think FreeBSD is the be-all, end-all, and egad! that they could take an idea from Linux because it is inferior.
 
I have no problem with someone porting kubernetes to FreeBSD, if there is a usecase why not.

We do have sysutils/apache-mesos, if only someone could write a jails isolator for Mesos, that would a piece of the puzzle solved. We may not even need Kubernetes/Docker on FreeBSD if we can come up with a good way to get Mesos to pull an app+dependencies into a jail (could we just use a local pkg repo)?
 
Well then I'm convinced. After 16 years of using FreeBSD and running a small company with it, I'm switching to Linux starting Monday cause it's obvious FreeBSD can't innovate or keep up. I've always wondered why FreeBSD users are so anxious to diss FreeBSD and convince everyone that it's a bad choice. If you want to get anywhere, choose Linux (or even Windows for that matter).

FreeBSD is dead.
 
Wait, is this turning into a Freebsd is dying thread? What is this, Slashdot circa 2003?

And we all know whatever businesses want now is the Future (tm). That's why Rails dominates today.
 
Wait, is this turning into a Freebsd is dying thread? What is this, Slashdot circa 2003?

Sadly it is. There are also threads in the forum and mail archives about that factoid where the very first post cites articles claiming that FreeBSD is dead.
 
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.
What makes you think that serving business that want/need to implement things that way is FreeBSD target market? That FreeBSD wants to do that? That it would be the right thing for FreeBSB?

By the way, I'm not claiming that I know what the FreeBSD target market is, or that FreeBSD doesn't want to do Docker/Kubernetes/Containers/..., and I definitely don't know what the right thing is. But the mantra "evolve by following what Linux does, or die" does not seem to be the answer.
 
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.
 
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.
 
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.
 
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.
 
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.
 
Back
Top