Docker is dead

I just wanted to make your lives easier before the mentions of Focker get flooded with other sub-par FreeBSD solutions. At this point in time I have tested them all and they are a far cry from Docker-like abstractions provided by Focker. Nvm I will stop mentioning it in old posts but I will keep recommending it in new threads the same way people always reply with the old, sub-par (and honestly not even remotely similar in functionality to Focker) solutions (iocage, ezjail, qjail, etc).
 
I think the problem is not the lack of an alternative to docker. There is an alternative: Bastillebsd, Focker, CBSD...
The problem is that we cannot convert Linux binaries of real docker images. And the FreeBSD ( BastilleBSD/Focker/CBSD) community is too small to create and maintain its own app images. For this reason, all these utilities do not matter much. All we have for the docker is the bhyve.
 
I think the problem is not the lack of an alternative to docker. There is an alternative: Bastillebsd, Focker, CBSD...
The problem is that we cannot convert Linux binaries of real docker images. And the FreeBSD ( BastilleBSD/Focker/CBSD) community is too small to create and maintain its own app images. For this reason, all these utilities do not matter much. All we have for the docker is the bhyve.
Last time I checked it is not the Docker developers who maintain images for different distributions and software applications. Now we need to market something to the software developers so that they start preparing and maintaining their own images. I think Focker is much better positioned for that as it resembles Docker a lot, concept-wise and workflow-wise, and the developers presumably all know Docker.
 
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.
Your comment reminded me of seitting up java for software developemen.t
 
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.
I would like to add my 5¢ to discussion.

The main reason why web devs use docker is to have consistent environment in development, demo and production. For instance, node.js code may behave different on different OS. Most devs have either MacOS/Windows as their dev machine, but production is running on FreeBSD. Because docker uses Linux, I'm as a web dev who loves FreeBSD, forced to use some Linux distro both on the server container and on my dev machine in my local docker client.

Therefore, if FreeBSD developers want to make their OS more popular and as a result to get more donations will have to jump on the trends of web dev and create some FreeBSD alternative of docker. When I say alternative of docker I mean execution of FreeBSD jail layers on MacOS/Windows easier than to run VM, i.e. some sort of containerization.
 
For instance, node.js code may behave different on different OS.
The purpose of node is to use javascript for consistency on the web. Different behavior based on OS is the opposite of its purpose and containers don't solve that. There are other issues at hand there. Of course, relying on node is a problem in itself.
Most devs have either MacOS/Windows as their dev machine, but production is running on FreeBSD.
Most? Designers maybe but not developers. And especially not FreeBSD.

Note: This month marks 17 years since I started a web dev company using FreeBSD
if FreeBSD developers want to make their OS more popular and as a result to get more donations will have to jump on the trends of web dev and create some FreeBSD alternative of docker.
Make FreeBSD act like Linux? No thank you. FreeBSD is a professional operating system for professionals. Linux is popular among the hobbyists which is why you hear more about it. Remove the hobbyists and usage drops by 80%.

You want great networking? You should be using FreeBSD, not Linux. Look at why NASA, Netflix and Juniper are using BSD for networking as documented everywhere. If you want containers, use jails. Don't be copying Linux's problem solvers that have problems themselves. (If Docker is so great, why do people use Kubernetes?)
 
The purpose of node is to use javascript for consistency on the web. Different behavior based on OS is the opposite of its purpose and containers don't solve that. There are other issues at hand there. Of course, relying on node is a problem in itself.
So true. Node's "download the Internet for every build" means that installs on the same machine from a couple of hours ago can be different from an install you do now. The last time I worked on a node project (and I was paid to) we used some tool to keep 2-3 versions of node around because of the significant compatibility problems new versions introduced, and new versions happened early and often.
Therefore, if FreeBSD developers want to make their OS more popular and as a result to get more donations will have to jump on the trends of web dev and create some FreeBSD alternative of docker. When I say alternative of docker I mean execution of FreeBSD jail layers on MacOS/Windows easier than to run VM, i.e. some sort of containerization.
So Freebsd should have embraced Ruby on Rails? Asp.net? Java servlets and JSPs? Apache with mod_perl? SOAP? CORBA? So many missed opportunities!
 
The purpose of node is to use javascript for consistency on the web. Different behavior based on OS is the opposite of its purpose and containers don't solve that. There are other issues at hand there. Of course, relying on node is a problem in itself.
...

Thanks for your response. I'm not looking to argue who is right and who is wrong.

The thing is that I'm as the user of FreeBSD looking for solution which will make my life easier.
If you personally, don't want to invest time into it, no one is looking to force you to do that.
Just say that you don't want to do that, whatever encouragement I'm offering, whether it is donations or fame, recognition as influential developer etc.

It doesn't matter.

FreeBSD is open source and FreeBSD license is very liberal as far as I understand and anyone can create solution in demand especially if:
...NASA, Netflix and Juniper are using BSD...

Anyway, thank you for your answer. Happy New Year!
 
Established in June 2015 by Docker ...
Reads more like a Docker compatible project.

But Docker is dead. I saw an article about this again a couple of days ago. That everyone is switching to Kubernetes. Docker somehow managed to raise $32 million dollars but that really isn't a lot for a big business.
 
yeah, Docker might be dead, but the technology behind is not (thats what I was refering to) ... whatever, let's call it OCI container, whether it is kubernetes, podman, runc, docker, containerd etc. that runs the application container does not matter. Just wanted to point out that there is an interesting application container project for FreeBSD growing
 
The thing is that I'm as the user of FreeBSD looking for solution which will make my life easier.
If by easy you mean simple, it doesn't get any easier than editors/leafpad. I picked up where I left off on NotePad when I switched from Windows.

I've never used anything but a text editor and valid XHTML or CSS on my sites since I taught myself how to write it at w3schools.com when it came out in 2000.

Docker was a type of khakis Jeans back then. Fireworks was what people who wore them and couldn't write XHTML or CSS used.

Like black Jeans and LeafPad were to those who could.
 
  • Thanks
Reactions: a6h
yeah, Docker might be dead, but the technology behind is not (thats what I was refering to) ... whatever, let's call it OCI container, whether it is kubernetes, podman, runc, docker, containerd etc. that runs the application container does not matter. Just wanted to point out that there is an interesting application container project for FreeBSD growing
The truth is that Docker is commoditized product. Docker's "decline" is a product of their own making, they are just a leader in a piece of software that's easy to replace.

Docker thought they would give their software free and open source so everyone would use Swarm. But then Kubernetes came along and everyone used that, and hence Docker is struggling. Docker is just the container engine, abstracted behind Kubernetes.

Docker might "re-focus" on "Developer Tools", but why would I use something with the "Docker" name instead of the tools my cloud provider gives me and not worry about another bill? Just because Docker was "cool" and "upcoming" in 2015? Look at HTC, they were "cool" 10 years ago and now HTC is history, they lost to Apple, Samsung, and the various number of Chinese OEMs.

Look at Hadoop vendors like Cloudera, they once had the world come around them in 2011 and now Hadoop (and Spark) is just a managed service in AWS or Azure. Why use "Cloudera" when I can just use the Hadoop which comes with my cloud subscription? Same applies to Docker.

In comparison, look at Microsoft. Say what you want about them, but a lot of companies use Microsoft products mainly since they only have to worry about one vendor for OSes, productivity software, and cloud. Many (not all) Microsoft products have "alternatives", but a lot of companies are Microsoft shops since they're the one-stop shop for a lot of an enterprise's software needs. But at the same time, many other companies may go with AWS or Slack or Zoom or Google Workspace and just use Windows and Office.

The one-stop shop analogy can be said about networking with Cisco and Huawei respectively for enterprise and service-provider roles.

Docker has essentially become plumbing. Plumbing that isn't exactly BSD-friendly so we have to rip apart Dockerfiles and build systems in order to put newer software in Ports. Hopefully Docker will eventually get abstracted out of DevOps so we are able to get portable software again. Or maybe what systemd was to the desktop, Docker is for the server: the thing we hate but have to deal with to get software out of it indefinitely. a pain for Ports maintainers but "loved" by developers who only think about Ubuntu on AWS or GNOME on Fedora.

Disclaimer: I work at Microsoft, but not on Azure. I do however deal with the Azure "Big Data" ecosystem heavily.
 
A good part of me wants to start another thread with a different title just to clear the air, but I think it's useful to at least plant a flag and clarify some of the asks and discussion points.

Kubernetes does not replace Docker. Kubernetes is all about cluster deployment, oversight, and management (most importantly your software-defined network and Head Node equivalent). It is your Infrastructure as Code or Infrastructure as a Service.

Docker is a runtime image in which your deployed code, its applicable middleware (jvm, node, python dist), environment variables/secrets, file system paths, virtual network interfaces, and a DNS white list have been bundled up together. It is your Vagrant equivalent.

Dockerfile and docker-compose.yml are really the fulcrum of this discussion. What THOSE TWO are, are the portable System Definition and Composition files used by Open Container Initiative. Openshift, ContainerD, and Triton (Joyent) all have verbatim copies of these files and use them the same way to construct and deploy a bundle of off-the-shelf tools (middleware, databases, ngnix, ...) and a developer's custom code that uses those tools together in a much more lightweight manner than spinning up Vagrants.

No one (sane) ever runs a production workload where the application server and DB server are the exact same physical machine, but a developer is working off of one workstation/laptop/remote VM for most of their work. The Image Definition and Composition files are portable. They can be handed to any OCI runtime, and a container image with the tools needed is constructed in a manner compatible with the host machine, with far stronger compatibility guarantees than a VM can ever give you (Virtualbox on Mac OS anyone?) WITH the benefit of both the host and guest platforms being separately, continuously upgradable (keeps Security happy) since the OCI runtime only provides a Linux Call Table compatibility layer (OS virtualization).

What OCI environments give us is the beauty of NOT having to defend against unstable crap combos like Python 2+3 and Ansible AND Vagrant (on Mac) getting in the way of developer onboarding and productivity into a software product built to run on a completely different OS from their company-provided machine.

And BECAUSE the Postgres, Cassandra, AdoptOpenJDK, <ad_nauseum>, and OCI dev communities work together so closely, you don't wind up in a scenario where the newbie got the newest model of laptop with a new Mac OS that Apple changed a zillion things on stomping all over a set of Vagrant, Python, and Ansible configs & routines last updated 2 years ago "because they just work" and it takes one of the old wizard senior devs a week to triage it.

BSD doesn't need Docker. It doesn't even need Kubernetes (occasional use of free-tier provided/managed services for sandboxing is probably fine). I do, however, think BSD would benefit immensely from having an Open Container Initiative-compliant/compatible "container" runtime.

Whether you use Jails/Zones and ZFS and network tools du jour to achieve this, that's up to the ports developers.
The benefit of having such a toolchain should be crystal clear even IF you yourselves never intend to deploy your software to a managed container service of any kind. If you want your user base to grow, this will bring in tons who at the very least HATE Docker Desktop For Mac but still need to work with Docker for their jobs. Because it's not about Docker. It's about OCI. Docker is dead. Long live Docker.
 
Kubernetes does not replace Docker. Kubernetes is all about cluster deployment, oversight, and management (most importantly your software-defined network and Head Node equivalent). It is your Infrastructure as Code or Infrastructure as a Service.
 
I fail to see how that contradicts what I said. The useful thing about Docker is the image and composition spec (which is now the triumvirate bedrock of OCI). Kubernetes doesn't support the runtime that the Docker company started with. You still build a set of "Docker" containers and deploy them TO Kubernetes. What runtime is used for execution (Docker, ContainerD, Triton) is an implementation detail of Kubernetes.

Docker (the runtime) is dead. Long live Docker (OCI) containers.
 
IF you yourselves never intend to deploy your software to a managed container service of any kind. If you want your user base to grow, this will bring in tons who at the very least HATE Docker Desktop For Mac but still need to work with Docker for their jobs. Because it's not about Docker. It's about OCI.
What this basically translates to is "If you stop using FreeBSD, you will need Docker".

Yes, I possibly agree but if we did stop using FreeBSD, we would be using Linux or macOS like you suggested and they *do* support Docker. However we use FreeBSD to avoid this mess of platforms and instead use tools specialized for FreeBSD rather than basically a heavy abstraction layer.

No one (sane) ever runs a production workload where the application server and DB server are the exact same physical machine, but a developer is working off of one workstation/laptop/remote VM for most of their work.

What did people do before Docker got marketed? Basically we still do the same thing (Jails).

Not to mention, Docker is an abstraction layer. It is them that are meant to abstract FreeBSD. Not the other way round. If FreeBSD ever got popular enough, I am pretty sure Docker would have no choice but to do the work to support us themselves.
 
looks at forums.freebsd.org with suspicion
I've seen two catastrophic big iron mainframe failures in my short 5-year career. No matter how much the community kicks and screams, the distributed systems philosophy of "servers are cattle, not pets" has proven correct for everything BUT the transactional workloads for which only the biggest iron will suffice. You want to spread your failure risk out and be running app instances on multiple physical machines behind redundant load balancers. Where I currently work, you either do the work to shard your app so Postgres can scale horizontally, or you use multiple production datacenters with data replication constantly running between them for failover. There have been close calls, but no total outages caused by a slight misconfiguration at the OS or network level. Previous employers had multi-million dollar outage fines because of their tiny mistake on a single mission-critical server (mainframe). And even if they hadn't made a mistake, a long-running power outage was inevitable someday, and corporate didn't want to pay for a second electricity provider as emergency backup.

No one (sane) puts everything into one box, and that includes all members of this community. Yes, it's filled with excellent engineers. Engineers are not risk managers constantly asking themselves "should I do this, even though I can and can code it up fast?"
 
What this basically translates to is "If you stop using FreeBSD, you will need Docker".

Yes, I possibly agree but if we did stop using FreeBSD, we would be using Linux or macOS like you suggested and they *do* support Docker. However we use FreeBSD to avoid this mess of platforms and instead use tools specialized for FreeBSD rather than basically a heavy abstraction layer.



What did people do before Docker got marketed? Basically we still do the same thing (Jails).
No, because Jails are not portable even between between OS versions, let alone other platforms (you want people to migrate to BSD, right?), and not everyone has a private datacenter where they can roll everything themselves as the BSD community seems to have the luxury of in shockingly high concentrations.

Having OCI compatibility (not Docker compatibility) makes BSD much more palatable to developer communities and system admins who would love to be able to use it but for the fact BSD is a walled garden that chains the organization to private datacenters.

It's not about Docker. Ignore the word Docker. It's about application portability and packaging, as well as developer productivity and symbiosis with the broader software ecosystem in ways that are complementary without being overshadowed by Big Tech powers (like Red Hat and SystemD).
 
Back
Top