Docker is dead

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
 
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.
 
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?
 
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...)
 
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.
 
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.
 
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.
 
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.
 
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 ;)
 
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.
 
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 :)
 
Agreed. On FreeBSD, I always distribute server software in jail(8) containers. How else would the cancerous spread of Python applications and their dependencies be prevented?

And then the best jail management software seems to be iocage, which has a hard dependency on Python...
So you're not preventing the Python spread at all.

Which is fine. Python does have its place in small scripts up to, say, 10,000 lines of code.

Oh, and Python isn't cancer... it is spreading because it is the easiest tool for some kinds of tasks.
If you dislike that (and I can understand why, I am not a big Python fan myself), write or sponsor a better language.
 
And then the best jail management software seems to be iocage, which has a hard dependency on Python...

I very much avoid iocage for this reason. However it isn't necessarily Python that I find bad; it is the developer mindset of dragging in 100+ dependencies just to i.e split a string.
PIP, NPM, Cargo and CPAN all suffer from the same misuse. In fact, Cargo's Crates is possibly the one reason why I don't think Rust will ever manage to replace C++. It makes it too easy to drag in C bindings rather than commit to writing software in Rust directly.

write or sponsor a better language.

No need. Many better languages exist already and I find it very easy to avoid Python in all of my projects.
 
I use Python, but only because I find it less obnoxious than shell. Yes, it's a low bar.

However, it seems that the Python Steering Committee has learned the wrong lesson from the 2.x -> 3.x upgrade debacle and has started to break backwards compatibility even in dot upgrades. I don't understand how they don't see that this subjects their users to a death of a thousand cuts. Who wants to spend time making dozens of little edits all over the place to accommodate terminology "upgrades"? And if you think that using some automated tool to do this is a good idea, I can tell you've never had to review such changes. Or you have, and decided "screw it, let's commit this" after your eyes glazed over.

The only rationale I've seen for this approach is that Python needs to change in order to stay "relevant." I'm probably just a dinosaur, but the preceding sounds like BS hype to me.

Suppose I went to the mat and convinced skeptical coworkers to try Python. Now every little thing they've written in it breaks every time the system Python is upgraded. How does that make me look? How do my colleagues feel about me now?

I've thought about integrating Lua into a shell, but the resulting abomination wouldn't be POSIX-compliant and nobody would use it anyway.

Maybe Perl or Raku are the answer?
 
I very much avoid iocage for this reason.

Just to avoid Python?
Aww come on.

However it isn't necessarily Python that I find bad; it is the developer mindset of dragging in 100+ dependencies just to i.e split a string. PIP, NPM, Cargo and CPAN all suffer from the same misuse.

Same as with pulling in all the dependencies if you install something via pkg.

In fact, Cargo's Crates is possibly the one reason why I don't think Rust will ever manage to replace C++. It makes it too easy to drag in C bindings rather than commit to writing software in Rust directly.

To be useful, a language needs libraries. You can't tell people to go ahead and write an HTTPS library before making their first network connection. And if the language has an HTTPS library, every project will need some other library - just visit the libXxx packages in any operating system with a package manager to see how many libraries might be found useful in any application, no language creation project can start with all these libraries (and do them well to boot).

So at least initially, all languages need a C binding and the ability to import code.

Over time, any successful language project will create its own libraries.
If it does not, using C libraries isn't painful enough to drive people into writing those libraries; either the language semantics is so close to that of C that it wasn't never worth the burden of yet another variant of C, or the language does not support writing good libraries well enough to be worth the burden of yet another programming language in general. (Like every rule of this kind, it has its exceptions - e.g. I'd very much welcome a C successor that finally eliminated all those nasal demons, but we all need our pipe dreams.)

No need. Many better languages exist already and I find it very easy to avoid Python in all of my projects.

Now that begs the question: Which one?
I.e. what language would you have preferred to see used for iocage, for example?
 
Just to avoid Python?
Aww come on.

First of all, I am not *too* religious. If FreeBSD didn't already offer very usable jail utilities as part of base I certainly wouldn't boycott jails just because of Python.

... but yep, Python dependencies breaks too often. I try to use solutions that remain working for the foreseeable future. Honestly that is why I also use FreeBSD over Linux. I wish the FreeBSD handbook would not make so much mention of ezjail, iocage or the next short-lived wrapper.

Same as with pulling in all the dependencies if you install something via pkg.

Yes, you absolutely want to reduce dependencies. Part of the reason why i.e desktop environments on FOSS platforms are so shakey is because so many of these dependencies are breaking over time. As part of my own solutions, I would only seriously rely on software with 2/3 recursive dependent packages max (for a server... for desktop, it is pretty much a free for all because xorg drags in so much crap ;)).

Now that begs the question: Which one?
I.e. what language would you have preferred to see used for iocage, for example?

Preferably C. Harder to develop but much better experience for users and much easier to maintain in the long run.
It would even have a chance at being imported into base then.

It may sound like I am a purist but much of the world chooses C or C++ for this same reason. It becomes less about the "pleasures" of the language and more about the underlying platform and reduction of complexity.

To be useful, a language needs libraries. You can't tell people to go ahead and write an HTTPS library before making their first network connection.
For many libraries, they are a generally good to just merge with the codebase (so they can be updated in a controlled manner). For more complex ones like SSL, sure a single dependency. No problem in C or C++. But check out the dependencies for other languages:
Each one doesn't drag in *one* dependency. It drags in tonnes of random cruft compared to the same solution in C.
These language based package managers cause developers to make a mess of their solutions.
 
However, it seems that the Python Steering Committee has learned the wrong lesson from the 2.x -> 3.x
Reminds me of perl 5 & 6 but in reverse order (6 -> 5)

I don't understand how they don't see that this subjects their users to a death of a thousand cuts.
They have no choice. Make a kludge, not a solution; in the end define the problem.

The only rationale I've seen for this approach is that Python needs to change in order to stay "relevant."
It is not going anywhere soon. Facebook and Google love python.

I'm probably just a dinosaur, but the preceding sounds like BS hype to me.
No, you aren't. You just don't have copy/paste mindset.

I've thought about integrating Lua into a shell
Lua and C are happy couples, reminds me of sqlite/C.

Maybe Perl or Raku are the answer?
Perl (or perl) just sounds more authentic.

Python dependencies breaks too often.
As composer in php. It's the new (php, python, KaliKiddie) scripting common thread.

for a server... for desktop, it is pretty much a free for all because xorg drags in so much crap.
The best part of FreeBSD: Cameron Grant rewrote the sound system for FreeBSD 4.0 (OSS && https://wiki.freebsd.org/Sound).
Looking forward to see Electron as Xorg dependencies

Preferably C. Harder to develop but much better experience for users and much easier to maintain in the long run.
Harder to develop, easier to learn.

It may sound like I am a purist but much of the world chooses C or C++ for this same reason.
C++: There's nothing wrong about OOP, but it sets a bad mindset. kind of: hit and run strategy; ... let's add itnow, fix it later.

These language based package managers cause developers to make a mess of their solutions.
In a smaller scale, "drupal, composer, symfony", comes to mind. That was a big no no. I had to switch somewhere else.
 
Preferably C. Harder to develop but much better experience for users and much easier to maintain in the long run.
It would even have a chance at being imported into base then.

It may sound like I am a purist but much of the world chooses C or C++ for this same reason. It becomes less about the "pleasures" of the language and more about the underlying platform and reduction of complexity.


For many libraries, they are a generally good to just merge with the codebase (so they can be updated in a controlled manner). For more complex ones like SSL, sure a single dependency. No problem in C or C++. But check out the dependencies for other languages:
Each one doesn't drag in *one* dependency. It drags in tonnes of random cruft compared to the same solution in C.
These language based package managers cause developers to make a mess of their solutions.

I wonder if it would seriously make a difference if Focker was written in C/C++. With something as mainstream as Python 3 + three extra packages (tabulate, jailconf, pyyaml) I can't help but think rewriting it in C/C++ would be a classical case of form over function. I mean -- seriously aren't there more important challenges to tackle in the whole containerization game than keeping the software written in C/C++? o_O
 
Possibly not. The idea and design of Docker is already fairly heavy.
You cannot do the same thing Docker does any more lightly. Not speaking about the architecture - the daemon and so on. Those can be optimized, as Podman clearly illustrates. But having a hierarchy of immutable images (or "code" as I like to think about them) and mutable volumes (the "data") is probably as nice as you can organize a big collection of containerized apps. In case of Focker (not Docker), they all end up as zero-overhead Jails anyway (you can remove Focker and they will keep running flawlessly). I can't see anything heavy about that ;)
 
You cannot do the same thing Docker does any more lightly.
I always wonder when someone says that. It was just a few years ago that no one ever mentioned the term and, now, many act like you can't possibly be doing anything unless you use it. No one at my company ever considered it or even brought it up.
 
I am a Python developer with passion, my C and assembler is way too old. "There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup.

However, back to topic: today heise.de had a nice write-up on security research concerning docker images ... the original: https://www.heise.de/news/Studie-80...haben-schwere-Sicherheitsluecken-4785175.html - and english translated by google: https://translate.googleusercontent...5.html&usg=ALkJrhjfd8AmBUJivOVEnaGulM6TTKxotQ ... for those preferring the paper this is based on: https://arxiv.org/pdf/2006.02932.pdf
 
I've been using sysutils/cbsd for years
cbsd is basically a wrapper of jail, jls and jexec. It doesn't have any higher level primitives introduced by Docker (checksummed, layered hierarchies of images, volumes, compositions). It also seems to be a primarily interactive tool which is exactly against the point.

but lately I've been thinking to switch to sysutils/pot
Pot is similar to cbsd with barely some added notions of images and image recipes (flavors). It seems like this could have been a nice solution but I would bet that the author has never used Docker. Somehow in the FreeBSD crowd there seems to be a conviction that it is absolutely impossible that the far bigger Linux/Docker crowd and the industrial crowd might have come up (FOR ONCE) with nice, well thought-out abstractions, better than the ad-hoc, half-hearted, immature and incomplete efforts scattered among so many FreeBSD-compatible projects. Pot has also no notion of compositions.

and sysutils/nomad to scale things horizontally more easily.
Nomad supports Docker, Podman and Singularity as containerization engines. Doesn't seem to be FreeBSD/containerization friendly in this regard.

It can probably be integrated with Jenkins(running on bare metal) for testing and reproducibility.
Anything can be integrated with Jenkins ;)

With a couple more tools like sysutils/consul
Consul is a service discovery, connectivity, heart-beat, etc. tool. A much higher layer than Docker and certainly not a replacement or alternative o_O

and net/traefik you can get a kubernetes-like feeling.
traefik seems to be more or less the same thing as consul. I really appreciate the number of solutions available to some extent for FreeBSD but still the only thing that can give you a Docker-like feeling is Focker ;)
 
Back
Top