Docker is dead

[...]
For all my largescale projects FreeBSD is of no interest due to lack of Docker. Providing a cloud system with 100 thousands of docker containers is so incredibly easy, all test driven from a nice CI/CD pipeline.

So stick to Linux. No one's forcing you to use FreeBSD and there's no sense in FreeBSD copying everything Linux does; then it's Linux!

I just don't get this "let's make FreeBSD have everything Linux has". Why not everything Windows 10 has? MacOS? It's nonsensical.
 
I would love to see a docker version on FreeBSD, specifically a jailed version
Talk about piling on. Sounds like web development. Needing a tool that makes things easier for a tool that made things easier that wrapped around another tool that made things easier...ad nauseum.

For all my largescale projects FreeBSD is of no interest due to lack of Docker.
That's why I never use Linux. jails don't work on Linux. If they ever get jails to work there, I might have a use for Linux but, until then, I have no interest in it.
Same thing for the new Windows Edge browser. What use if Linux if they can't get that to work there?
 
I just don't get this "let's make FreeBSD have everything Linux has". Why not everything Windows 10 has? MacOS? It's nonsensical.
That's what Linux already does! Linux is a Windows wannabe. Ubuntu's bug list ranks Windows as the #1 bug so they have to copy everything Microsoft does in order to replace it. Just look at all the people who are now thrilled as .NET and other Microsoft tools get integrated into or run on Linux. They can't wait till there's a Microsoft branded Linux!

Many people just want to run things because they read a headline somewhere on reddit and insist it's now gospel. So they run out, use it themselves, with no understanding of why.
 
yeah, obviously I have to stick to Linux on that projects, unfortunately. But one may dream of containers on FreeBSD, the concept is great ... it's the "new statically linked" contained form of applications. IMHO its the same type of great technology for me as virtualization. Probably I desperately want containers on FreeBSD because what Docker Inc did with containers was a classic showcase of how things go wrong in linux land. The API breaks were insane, and they simply wrote another filesystem because their first attempt did not work as expected.

Anyhow, docker is dead, but containers are more alive than ever, and will probably be in the future, and that tech is probably more alive than Unix.
 
rootbert said:
Having just a few lines of config/docker compose lines producing reproducable, testable containers is one thing I don't ever want to miss again, so imho developing this for FreeBSD would save loads of developer resources if you try to implement this with jails etc. - I think in the end it would pay off.
Poudriere uses jails to provide reproducible builds. Install a particular tool chain into a jail. Build a port in that jail. Get the same binary output.

I see people rave about vagrant and docker community sourced scripts. Sounds like a big productivity boost. The problem is they take these scripts at face value and don't do any analysis to see what side effects - including security implications. When you create your own jail.conf file - you control exactly what your jails can and cannot do.

Not only can a jail provide a reproducible environment - when combined with ZFS you can take snapshots and easily roll back any change to a jail. Upgrade a library in a jail and don't like what you see? ZFS can take you back to where you were.
 
What developers (myself included) desire is really not to run docker on freebsd, but to have something sitting above jails and libs with similar user interface semantics (making jails an implementation detail). "Docker registries" with "images" can be implemented with poudriere or whatever. Out of iocage, cbsd, etc. the closest to this is the new Bastille, afaik.
 
What developers (myself included) desire is really not to run docker on freebsd, but to have something sitting above jails

So a wrapper around a wrapper. Or a tool for a tool?

This sounds like web development nowadays. No one just writes HTML, CSS and JavaScript. You have a tool to make that but, then, someone comes along with a tool to make the first tool better but then someone else needs a tool for that tool and, pretty soon, you have what's going on now--layer upon layer of tools that are all supposed to make life easier but they don't.

As I said, if one is going to use FreeBSD, use jails and be done with it.
 
So a wrapper around a wrapper. Or a tool for a tool?

When a tool is great, that is rich and flexible, its learning curve is necessarily long. And what human beings need when it comes to learning (in any field, not only IT) is a fast and easy way to make ones first steps.

When you work in a given context, you always do more or less the same things. If you have a "tool above a tool" that makes your first steps easier with the underlying one, you can make sense out of what you learn because it pertains to what you're working on. Then, you can easily and gradually learn more because you don't start from scratch and your knowledge increments keep being meaningful to you.

If you later work in a different context, the "tool above the tool" might still be useful, not for learning but as a kick starter if both contexts differ a lot.

Such tools are important in terms of risk management because tools embed corporate knowledge and best practices. If an experienced developer leaves your team for any reason, you'll be happy to have such a tool so the new joiner will not have to go through the full length of his former colleague's learning curve, with all the unpleasant implications this inevitably has for the project.

Tools have a cost, not only an acquisition cost, but also an operating cost, mainly due to the complexity added to the work environment. This cost should be estimated and compared with the costs likely incurred otherwise.
 
I can see Docker being useful for those who either cannot be "arsed" or do not have enough time to do things properly. And that is fine, sometimes I like to fiddle about or am rushed off my feet with tasks.

However, those who cannot be bothered, or do not have enough time are probably also not going to be able to make a quality solution work on FreeBSD either. There are quite a few subtle differences between operating systems and container solutions that Docker will not be able to abstract. They will stick to Linux.

So Docker, as an abstraction layer between platforms is only really useful as a layer above the mess that is Linux distros (including WSL). With FreeBSD we have *one* OS, and so it isn't really needed.

... Jails.
 
20-100-2fe People don't do that. Once they start using that abstract, they won't learn the details. And it's the job of any programmer to know the details. If that person leaves the job, and you no longer have the knowledge they had of that tool, then you need someone to fill that void. Otherwise, you left adrift and dependent on outside sources who now, in a way, control what you do. And your professional system now becomes Windows.
 

That article really nailed it with the term "distributed monolith". I believe so many projects have fallen into that trap. Just look at desktop environments, X11 and most web projects.

Yes, it is all split up into many many parts but they are effectively only ever used together. They are fairly useless when isolated. They are monolithic and provide no modular or "microservice" benefits.

It is pretty much what makes CDE still easily buildable after all these years, and Gnome 3 a pain in the butt to build even in this present day!
I really can understand why the OpenBSD guys put in the effort to maintain Xenocara (a recombined fairly vanilla xorg). Perhaps we should point our xorg port towards that rather than upstream. It would greatly simplify the port ;)
 

I've worked at a company where they used an ESB to slow down their applications with just 100,000+ customers - a really efficient technique to avoid the temptation of gaining market shares.

Now, they're in the process of switching to Docker and REST micro-services, adding infrastructural chaos to poor performance.
A French proverb says 'doing and undoing are both working'...
 
If you would be curious to try out something that takes the best abstractions of Docker (images, volumes, containers) and puts them to good practical use on FreeBSD without the unnecessary fanfare, please take a look at https://github.com/sadaszewski/focker . It can build image recipes similar to Docker and does that using layers so that you can very conveniently work on your build scripts and not suffer from the need to rebuild from scratch every time (the build is picked up from the last successful layer). On top of that there is a docker compose like configuration orchestration that lets you build a couple of images together, create volumes and couple all that in a bunch of jails. All using the FreeBSD primitives only - /etc/jail.conf, ZFS. Fully transparent. Very small footprint, fast operation. Really nice examples I use on my own server - https://github.com/sadaszewski/focker/tree/master/example/gitea and https://github.com/sadaszewski/focker/tree/master/example/gateway . Particularly gateway should be of general interest as it nicely handles setting up Letsencrypt and reverse-proxying. Cheers.
 
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.
 
I like it, whilst for my own use-cases I prefer to use the Jails system directly, this can certainly help me to push FreeBSD on a few more servers maintained by Docker die-hards XD.

drhowarddrfine in many ways this is actually a great project. Look at it this way, next time we get some random Linux kid on these forums whining that Docker doesn't exist, we can simply point them towards this project and they can sod off and bother the next OSS community ;)
 
push/pull of binary images from hub.docker.com in focker. This would make the tool really shine.

It is actually this aspect of Docker that I like the least. Locking a large project down to an "app store" is potentially a very dangerous thing to do. I like to think that my software will outlive hub.docker.com (5 years?) and by relying upon it, it instantly puts a death sentence on my project.

Your work is impressive nontheless, and I am certain that some who crave the Docker workflow can benefit from it. :)
 
Back
Top