How's life without Docker?

JohnK said:
Oh? You got my attention. what's SMF?
Click to expand...

It's a unified model for managing services in Solaris. It's really ahead of its time. Unfortunately it relies of a lot of kernel functionality only found in Solaris so it's nearly impossible to port. SMF and some functions would have to be implemented in FreeBSD separately.
 
rbranco said:
This is not true.


Ports solves nothing. Packaging is a mess in all Linux distros. Virtualization comes with overhead and is meant to ship operating systems, not packages.


An aggregator can be anything. With Docker you can package any application.
Click to expand...
Remember, with Docker you are "repackaging", so the following still apply:
  • "Ports solves nothing"
  • "Packaging is a mess in all Linux distro"
  • "Virtualization comes with overhead and is meant to ship operating systems"
Plus you have now also reduced portability to operating systems other than Linux.

rbranco said:
This is not true.
Click to expand...
Think past the "branding" and instead about all layers of the underlying stack. You will then see why virtualization is required to run on every non-Linux OS.
I know their cute little logo of a whale looks clean, simple and encapsulated but Docker is just a wrapper around Linux specific kernel features.
 
Jose said:
Yeah, this is a problem common to all containerization schemes. Pinning versions means that if you have 100 containers, you probably have 50 versions of some library, and around 25 have open CVEs.

Yes, packaging is a mess, but containerization is not a solution. It just moves the problem around.
Click to expand...
The packaging problem is not solvable. Containerization is a solution when it provides isolation.
 
kpedersen said:
Remember, with Docker you are "repackaging", so the following still apply:
  • "Ports solves nothing"
  • "Packaging is a mess in all Linux distro"
  • "Virtualization comes with overhead and is meant to ship operating systems"
Plus you have now also reduced portability to operating systems other than Linux.
Click to expand...
You can use the APE binary format if you want cross-OS compatibility.

Packaging is a mess in ALL distros including *BSD. There are not enough maintainers and most users feel entitled without contributing nothing.
 
Beastie7 said:
It's a unified model for managing services in Solaris. It's really ahead of its time. Unfortunately it relies of a lot of kernel functionality only found in Solaris so it's nearly impossible to port. SMF and some functions would have to be implemented in FreeBSD separately.
Click to expand...
But it could be a fun thought exercise to keep me awake conceptualizing a similar thing (or a subset of). I've been toying with these types of concepts (different than) and they're fun.

rbranco said:
... most users feel entitled without contributing nothing.
Click to expand...
Oh my do I agree with this! I asked some people to just test my thing and the only response I got said: "sorry, my make doesn't work". ...that hurt (welcome to opensource).
 
well I do miss an OCI equivalent standard and it's ecosystem for FreeBSD very much. I'd say that jails is just containers version 1 whereas podman is the improved version 2, and I'd even argue that if FreeBSD had an equivalent to OCI (I do not only mean the standard, but also the great ecosystem around it) it would be in a better shape cause more companies would be interested, at least from my bubble of companies I do work with. I have no idea why many people are so offended by just the idea of adding a modern declarative version of jails, and I have no idea why a "freebsd-containers pull <that-oldfashioned-proprietary-compiler-from-vendorhub> && freebsd-containers run <that-oldfashioned-proprietary-compiler>" seems so wrong to many here. Maybe some tried to use OCI containers like they did with jails, which is the wrong approach and therefore lead to unsatisfied results, maybe some do not like new tech, maybe some do not like tech that comes from Linux, maybe just personal taste. It's the modern, state of the art way to ship software: have your store (repo) or public repo, the container images, all combined with a configuration (network config, permissions etc.) to get your software stack up and running in no time for your clients. Our small team is concentrating on writing software instead of configuring jails, and while we thought about delivering the stack with FreeBSD we chose Linux Containers because the ecosystem is already there - it simply offers a great declarative way to define all the images that should run within a group so they can all communicate, the customer does not even have to know about his own network environment.

While I do admit that the ecosystem grew out of necessity in the mess of Linux distros, it is much more than the solution to the problem we in FreeBSD land do not have. I think it would not even be a lot of work to write a wrapper around jails and offer some kind of repository/hub, as quite some nice tools have popped up for FreeBSD, however, not quite comparable to e.g. podman. Not that I do need an overengineered equivalent like Linux containers, but a basic, simple system to ship software based on jails+configuration with build infrastructure and a repository would be so awesome, I am sure the FreeBSD folks would deliver a much better solution than the Linux variants. The implementation in Linux has quite some flaws, most of which you encounter when you deep dive into that topic, however, still all in all it offers quite good developer experience.
 
rootbert said:
I have no idea why many people are so offended by just the idea of adding a modern declarative version of jails, and I have no idea why a "freebsd-containers pull <that-oldfashioned-proprietary-compiler-from-vendorhub> && freebsd-containers run <that-oldfashioned-proprietary-compiler>" seems so wrong to many here.
Click to expand...
Its not that it sounds wrong, it is the fact that it is impossible because...

rootbert said:
I do not only mean the standard, but also the great ecosystem around it
Click to expand...
This translates to:

"Not only do I want FreeBSD's containers to handle a little different but I also want to run Linux binaries downloaded from the internet"

The former is no problem. We have projects like Focker. But thats not enough for what people want (as you suggested).

But the latter is impossible. The "ecosystem" is a collection of Linux binaries and you simply cannot run Linux binaries on any platform other than Linux (without emulation).

If you asked on the Microsoft forums why Windows doesn't natively support Docker. The answer is the same. Its impossible. FreeBSD runs Docker in the same way as on Windows and macOS (virtualization). Interestingly macOS Docker even uses *our* hypervisor, xhyve a fork of bhyve.
 
rootbert said:
well I do miss an OCI equivalent standard and it's ecosystem for FreeBSD very much. I'd say that jails is just containers version 1 whereas podman is the improved version 2, and I'd even argue that if FreeBSD had an equivalent to OCI (I do not only mean the standard, but also the great ecosystem around it) it would be in a better shape cause more companies would be interested, at least from my bubble of companies I do work with. I have no idea why many people are so offended by just the idea of adding a modern declarative version of jails, and I have no idea why a "freebsd-containers pull <that-oldfashioned-proprietary-compiler-from-vendorhub> && freebsd-containers run <that-oldfashioned-proprietary-compiler>" seems so wrong to many here. Maybe some tried to use OCI containers like they did with jails, which is the wrong approach and therefore lead to unsatisfied results, maybe some do not like new tech, maybe some do not like tech that comes from Linux, maybe just personal taste. It's the modern, state of the art way to ship software: have your store (repo) or public repo, the container images, all combined with a configuration (network config, permissions etc.) to get your software stack up and running in no time for your clients. Our small team is concentrating on writing software instead of configuring jails, and while we thought about delivering the stack with FreeBSD we chose Linux Containers because the ecosystem is already there - it simply offers a great declarative way to define all the images that should run within a group so they can all communicate, the customer does not even have to know about his own network environment.

While I do admit that the ecosystem grew out of necessity in the mess of Linux distros, it is much more than the solution to the problem we in FreeBSD land do not have. I think it would not even be a lot of work to write a wrapper around jails and offer some kind of repository/hub, as quite some nice tools have popped up for FreeBSD, however, not quite comparable to e.g. podman. Not that I do need an overengineered equivalent like Linux containers, but a basic, simple system to ship software based on jails+configuration with build infrastructure and a repository would be so awesome, I am sure the FreeBSD folks would deliver a much better solution than the Linux variants. The implementation in Linux has quite some flaws, most of which you encounter when you deep dive into that topic, however, still all in all it offers quite good developer experience.
Click to expand...
Podman is cli compatible with Docker and reuses lots of existing code.
 
JohnK said:
But it could be a fun thought exercise to keep me awake conceptualizing a similar thing (or a subset of). I've been toying with these types of concepts (different than) and they're fun.
Click to expand...

This mailing list post here outlines a list of things needed to get a working implementation. Seems like a fun challenge. If I had the C chops; I'd do it myself. Converting rc scripts in the ports tree would probably be a long process too.
 
Beastie7 said:
This mailing list post here outlines a list of things needed to get a working implementation. Seems like a fun challenge. If I had the C chops; I'd do it myself. Converting rc scripts in the ports tree would probably be a long process too.
Click to expand...
*blink-blink* 'challenge'?! Man, that's a career! Can you imagine the timeframe for a port for something like this coming from a weekend warrior (that must have been developed by a team)? I don't have the c-chops for something like that either (some of that is pretty deep stuff), but I'll start looking at it for ideas.
 
SMF & Docker are completely different things. Why is SMF even mentioned in a thread about Docker? SMF is Solaris' systemd.
 
rbranco said:
SMF & Docker are completely different things. Why is SMF even mentioned in a thread about Docker? SMF is Solaris' systemd.
Click to expand...
It is? I thought (granted, I only have 10 minutes of reading under my belt at this point) because of the job control/create aspect. -i.e. start/stop/create a "thing" based on a need (be that "create a jail to isolate/make a service because of a need of some sort").
 
JohnK said:
It is? I thought (granted, I only have 10 minutes of reading under my belt at this point) because of the job control/create aspect. -i.e. start/stop/create a "thing" based on a need (be that "create a jail to isolate/make a service because of a need of some sort").
Click to expand...
They're completely unrelated. If you want to compare something in Solaris to containers you better use Solaris Zones.

There are system containers (LXC, OpenVZ et al) and application containers. OCI / Docker is mostly about the latter. Application containers must be treated as cattle, not pets.
 
rbranco said:
Application containers must be treated as cattle, not pets.
Click to expand...
I have heard this slogan before from the Docker community.

But no, for software running on a server, you need to treat it with care and attention, much more like a pet if you want to keep it secure and safe,
 
I took that statement to mean that there should be reliable consistent method for creating it. Like a makefile is to the project. So, if you had a need for a thing (-e.g. I need a media server) you can download the 'makefile' to spin up a plex jail/media server quickly and consistently (destroy it and remake it 10 minutes later). ...this is what I was going after with my simple jail making scripts.

I could be way off though. Sorry.
 
Kubernets of fish too? ... never use it and never miss it , only in a few clients that some "friend of a friend,use the magic recipe to something to work..an NO one can replicate it,and the make a magic cube that contain something"
Allways I use Jails
 
kpedersen said:
I have heard this slogan before from the Docker community.

But no, for software running on a server, you need to treat it with care and attention, much more like a pet if you want to keep it secure and safe,
Click to expand...
Some may be constrained by their time, or in business language: have no client paying the $$ for petting three cats, instead, have to generate revenue by providing complex software. You'd be in a much better position to regard them as cattle, and design a secure fence around, all being declarative and easily and fully reproducible.
 
kpedersen said:
I have heard this slogan before from the Docker community.

But no, for software running on a server, you need to treat it with care and attention, much more like a pet if you want to keep it secure and safe,
Click to expand...
LOL. The slogan also shocked me a bit as English is not my native language. But it's the right approach when containers are supposed to be just sandboxed programs instead of lightweight VM's.

You care about VM's like pets. But sandboxed programs are best treated as cattle.
 
rbranco said:
You care about VM's like pets. But sandboxed programs are best treated as cattle.
Click to expand...
Honestly I treat all public facing programs (sandboxed or not) with care and consideration. I don't just "spin them up" and move on. I plan and maintain them.

rootbert said:
Some may be constrained by their time, or in business language: have no client paying the $$
Click to expand...
Absolutely. Poor quality engineering is everywhere.

But it is not *good* and shouldn't be your aim to manage software like that.

If you don't quite understand what is inside the Docker black box, you can put a meaningful fence around it.
 
kpedersen said:
Honestly I treat all public facing programs (sandboxed or not) with care and consideration. I don't just "spin them up" and move on. I plan and maintain them.
Click to expand...
But don't marry them. They're disposable. The only thing you really care about is the data & configuration, which is to be mounted as volumes.
 
You must log in or register to reply here.
Back
Top
OSZAR »