The main drawback I saw on jails is that they are FreeBSD. The owner doesn’t mention, and I have not researched it, but can you run any Linux distribution in a FreeBSD jail?
Back to FreeBSD – Part 2 – Jails
11–20 of 33 posts
Re: Back to FreeBSD – Part 2 – Jails
#12The main drawback I saw on jails is that they are FreeBSD. The owner doesn’t mention, and I have not researched it, but can you run any Linux distribution in a FreeBSD jail?
-ish. There's a compatibility layer that works at the libc level but not the syscall level. In practice anything open source that works in emulation almost certainly has a FreeBSD version and anything proprietary that actually needs Linux will work better in a VM.
Re: Back to FreeBSD – Part 2 – Jails
#13I think they understate the importance of accepting OCI and Dockerfile semantics as a path to an external "run one of these" and having it actually emerge as a jail based outcome. I get saying "we don't need these additional layers/abstractions" but what it ignores is me saying "I want to run this code, and what I have is a suite of Docker based behaviour and I want a low friction path to use that Docker compose meth…
It's a different operating system. You can't point at a dockerfile, say "port this please from linux-such-and-such to FreeBSD" and expect it to work every time. There are nuances even with linux-compat. Contrary to popular belief load-balance/scaleout is orthogonal to containers (and k8s is only one of the ways to go about it), so obviously it's not discussed in an article about containers.
In my practice it was completely normal to build things inside a container to be deployed on Linux using the same sources and basically the same package names and versions as used on a developer macOS machine (which is BSD-like enough down below).
Re: Back to FreeBSD – Part 2 – Jails
#14Code 11
Re: Back to FreeBSD – Part 2 – Jails
#15I find dockerfile layering to be unsatisfying because step 5 might depend on step 2 but not 3 or 4... the linearisation of a DAG makes them harder to maintain and harder to cache cleanly (with us also having monster single-line CMDs all in the main of image results).
So is there a better way that people are using?
Re: Back to FreeBSD – Part 2 – Jails
#16The main drawback I saw on jails is that they are FreeBSD. The owner doesn’t mention, and I have not researched it, but can you run any Linux distribution in a FreeBSD jail?
My main culprit with FreeBSD is that upgrading the kernel is not a simple dnf update command. But its still easier than upgrading RHEL from 9 to 10.
Re: Back to FreeBSD – Part 2 – Jails
#17The main drawback I saw on jails is that they are FreeBSD. The owner doesn’t mention, and I have not researched it, but can you run any Linux distribution in a FreeBSD jail?
To run a Linux distribution in jail you need 2 things:
- Enable "Linux Binary Compatibility"
- copy your Linux distribution base filesystem in the chroot or just pick on that is packaged in FreeBSD and do 'pkg install' (Rocky and Ubuntu if I remember correctly)
But you might not even need to "Run a Linux distribution". Just enabling "Linux Binary Compatibility" and executing the binary often works fine if it doesn't depends on a bunch of libraries.
It is really that simple.
Re: Back to FreeBSD – Part 2 – Jails
#18Ten years in with Docker and Linux containers I felt something was very wrong so I looked at how Solaris and FreeBSD were doing it and I saw the light (too).
I would agree with them: bringing the Dockerfile format to jails doesn't make any sense, unless you just want to attract curious Linux users.
Dockerfiles are useful and familiar but are also an abomination.
What we need is solid way to do configuration management. I guess this is what they are trying to do with their own configuration system [1] but I am not sold on it yet.
Anyway those people are doing some good work !
- [0] https://jail.run/
Re: Back to FreeBSD – Part 2 – Jails
#19Earlier quoted context omitted.
It's a different operating system. You can't point at a dockerfile, say "port this please from linux-such-and-such to FreeBSD" and expect it to work every time. There are nuances even with linux-compat. Contrary to popular belief load-balance/scaleout is orthogonal to containers (and k8s is only one of the ways to go about it), so obviously it's not discussed in an article about containers.
Very often you can, or could, because the software is portable (e.g. Node or Python or Postgres), and / or platform-independent (e.g. written in JS, Python, bash, etc). In my practice it was completely normal to build things inside a container to be deployed on Linux using the same sources and basically the same package names and versions as used on a developer macOS machine (which is BSD-like enough down below).
That's like saying an Ubuntu .deb will work on Gentoo because it's all Linux anyway. It's not that simple. There is dependencies and there are differences in the packages, package managers and surrounding system for a reason. It's not 1:1. Perhaps the naming scheme happened to line up for the packages you where using, but this should be considered not assumed.
It would be nice if there was some sort of translator that could handle "most common cases". I think it would improve the usability of Jails. Perhaps that would require someone to keep a list of packages mapping certain packages between operating systems.
Something like "apt install python3-serial" -> "pkg install py311-pyserial" may suffice.
For anyone that would use something like that, you should implement a prototype, publish it and perhaps someone else will build upon what you started!
Re: Back to FreeBSD – Part 2 – Jails
#20The article is written by the people who created jail.run [0] Ten years in with Docker and Linux containers I felt something was very wrong so I looked at how Solaris and FreeBSD were doing it and I saw the light (too). I would agree with them: bringing the Dockerfile format to jails doesn't make any sense, unless you just want to attract curious Linux users. Dockerfiles are useful and familiar but are also an abomin…