Bastille: FreeBSD Jails Management(bastillebsd.org)
bastillebsd.org
Bastille: FreeBSD Jails Management
https://bastillebsd.org/
27 comments
Yet another Jails management tool, written in sh. There are plenty of them already: ezjail, cbsd, iocage and many others. All those tools does pretty much the same thing and all of them has the same problem - poor user experience and unfinished product. And if you use jails in production, you're always better of by creating and managing them without third party products. FreeBSD Jails stuck in the loop for years - core devs does not provide fully packaged product, and everyone else tries to implement their own version.
FreeBSD and Jails are a fully packaged product, but the product isn't what you would like it to be, simply. They are meant to be building blocks for your own customised solutions, not a 'software application' like Docker is.
I've been using FreeBSD since around 2002 (including Jails), and the mentioned problem is still why majority of readers or Docker users have never ever heard of FreeBSD Jails, though it was released about 14 years before Docker. It just never took off for casual users and it was far from 'fully packaged product' back in a day. It got better, but it still suffer from the same problems as as it was 19 years ago. And partly because FreeBSD core team have a specific view on it.
> [..] majority of readers or Docker users have never ever heard of FreeBSD Jails [..]
I would argue that said users have never heard of UNSHARE(1) either, although Linux pretty much wipes the floor with anything else when it comes to containers. You can use UNSHARE(1) to create your container, extract a base image of your preferred distribution, configure it and start an instance. Heck, you can even create and package a shell script that does all the above for you. Nobody does that on Linux even though UNSHARE(1) (and friends) are very much finished products. They are not the products people want, that is, application specific containerization solutions like Docker, or something that can be easily deployed at scale in a reproducible and compliant way.
I would argue that said users have never heard of UNSHARE(1) either, although Linux pretty much wipes the floor with anything else when it comes to containers. You can use UNSHARE(1) to create your container, extract a base image of your preferred distribution, configure it and start an instance. Heck, you can even create and package a shell script that does all the above for you. Nobody does that on Linux even though UNSHARE(1) (and friends) are very much finished products. They are not the products people want, that is, application specific containerization solutions like Docker, or something that can be easily deployed at scale in a reproducible and compliant way.
Thanks for that. I was building containers pre docker but didn't know about unshare. I'm going to play around with this.
I've heard of jails but haven't used BSD enough to ever use them. (And I'm not old enough to have ever mucked with zones. My Solaris boat anchors were just toys for a teen collector.)
I've heard of jails but haven't used BSD enough to ever use them. (And I'm not old enough to have ever mucked with zones. My Solaris boat anchors were just toys for a teen collector.)
This looks great!
A quick illustration of commands that really ought to be on the landing page and not hidden behind three layers of hyperlinks if you want to pique potential users' interest:
A quick illustration of commands that really ought to be on the landing page and not hidden behind three layers of hyperlinks if you want to pique potential users' interest:
ishmael ~ # bastille create folsom 11.2-RELEASE 10.8.62.1
RELEASE: 11.2-RELEASE.
NAME: folsom.
IP: 10.8.62.1.
ishmael ~ # bastille cmd folsom 'ps -auxw'
[folsom]:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 71464 0.0 0.0 14536 2000 - IsJ 4:52PM 0:00.00 /usr/sbin/syslogd -ss
root 77447 0.0 0.0 16632 2140 - SsJ 4:52PM 0:00.00 /usr/sbin/cron -J 60 -s
root 80591 0.0 0.0 18784 2340 1 R+J 4:53PM 0:00.00 ps -auxw
ishmael ~ # bastille stop folsom
[folsom]:
folsom: removed
ishmael ~ # bastille destroy folsom
Deleting Jail: folsom.
Note: jail console logs not destroyed.
/usr/local/bastille/logs/folsom_console.logThe docker 0% thing is misleading. There's literally nothing stopping you from building a full OS in a container. I've built containers that you could SSH into and never know you were in a container. Docker folks push the single process thing hard but it's not the only way and most people who deal with a lot of containers know that.
I'm interested in jails because I have a BSD need, so this is timely but starting with misinformation puts off.
I'm interested in jails because I have a BSD need, so this is timely but starting with misinformation puts off.
I think it means there is 0% Docker involved, but I am not sure...claiming to be 100% secure is more suspect to me.
You may be right. Its in the "Jails Contain All The Things!" section so maybe I read it wrong. The 100% security thing makes more sense your way. But the no 12-factor app statement and then Docker 0% is confusing.
Not a great layout. Not the fault if jails though.
Not a great layout. Not the fault if jails though.
From my archaic (and by no means first hand) understanding of jails they are basically a docker alternative (long) long before Docker. They have been tried and tested probably arent 100% secure but damn near enough to be worthwhile. Jails is the main concept that interested me in BSD. I just dont want to deal with drivers. If I pop in an ISO I want things to work period. So I stick with Linux instead.
What kind of drivers? Pop an iso of what, where? I hardly can think of anything one could do with FreeBSD and Jails that would involve any 'drivers' - mind elaborating a bit?
I should of stepped back and explained, I'm on about installing the OS itself. If the road of entry is a nogo for me, I wont be able to try jails.
It isn't clear to me how this differs from iocage, other than it expects to run on the loopback interface instead of the public one.
This looks like a viable alternative to docker, at least for BSD. Any opinions on that statement?
The compelling part of Docker is container distribution and deployment using easily created and replicated container images. The templating feature is a step in the right direction towards recreating Docker's replicable container functionality, but is still quite different and less beneficial than the container image repository approach.
BSD Jails (and Solaris zones) predate Linux containers in general by a number of years, but the adoption and development of large-scale BSD container orchestration systems seem to have lagged behind the likes of Kubernetes.
On the other hand this stuff really isn't rocket science and shouldn't be as complicated as we are making it.
On the other hand this stuff really isn't rocket science and shouldn't be as complicated as we are making it.
> This looks like a viable alternative to docker, [...]
This looks more like something in the spirit of systemd-nspawn plus templates if I'd compare it to the Linux domain.
This looks more like something in the spirit of systemd-nspawn plus templates if I'd compare it to the Linux domain.
As much as I applaud any initiatives of creating workable solutions with great FreeBSD primitives (Jail containers, ZFS, great TCP/IP stack and so on) pretty much anything that's not working with widespread adopted standards (Kubernetes, Docker, OCI, etc.) doesn't stand a chance of becoming relevant on the market.
That’s the thing. I am a long time BSD fan, grew up with it an even tan FreeBSD on the desktop for years. But then came the cloud, docker, kubernetes, and the whole shebang, and it simply does not make sense to even consider hosting applications on FreeBSD again if you are deploying a modern stack.
Yes, of course, there are ways around that, but it just doesn’t make economical sense for most organizations.
Yes, of course, there are ways around that, but it just doesn’t make economical sense for most organizations.
I know this might hit a nerve for some. I agree with the limitations of FreeBSD compared to Linux.
I run a research cluster, and here’s how I built it.
Firewall+DNS= OpenBSD(pf)
File server(NFS) = FreeBSD (ZFS)
Compute nodes = Fedora latest with some optimizations.
Identity provider = CentOS( FreeIPA)
Database server = CentOS(Postgres)
Web servers = CentOS podman(nginx)
FreeBSD for ZFS fileserver has been solid and dependable like nothing I have ever worked with before - it is hard to believe that it is free in cost and open source. I probably would not even think about running FreeBSD for compute nodes because it is not its thing.... almost all research software in the wild are being written with Linux in mind.
I run a research cluster, and here’s how I built it.
Firewall+DNS= OpenBSD(pf)
File server(NFS) = FreeBSD (ZFS)
Compute nodes = Fedora latest with some optimizations.
Identity provider = CentOS( FreeIPA)
Database server = CentOS(Postgres)
Web servers = CentOS podman(nginx)
FreeBSD for ZFS fileserver has been solid and dependable like nothing I have ever worked with before - it is hard to believe that it is free in cost and open source. I probably would not even think about running FreeBSD for compute nodes because it is not its thing.... almost all research software in the wild are being written with Linux in mind.
Colin Percival (creator of Tarsnap) runs FreeBSD on AWS (discussed here on HN several times). More info:
https://www.daemonology.net/blog/2018-12-26-the-many-ways-to...
https://www.daemonology.net/blog/2018-12-26-the-many-ways-to...
Sure you can run FreeBSD on AWS, but that’s not the point I’m trying to make. A modern stack orchestrates containers on a higher level, using kubernetes, nomad, or something similar. I’m having a hard time seeing how FreeBSD could fit into this type of architecture.
Well, I would argue that it still makes sense, depending on what you want to achieve: world-top networking performance? FreeBSD. 1st class ZFS support? FreeBSD. Not being vulnerable to widespread Linux exploits (Shellshock, for example)? FreeBSD. And the list could go on.
The most used feature of docker in our org is image distribution. Make an image once, and you can be sure the same code runs on stage, prod, and dev desktops.
This feature seems to be missing here.
This feature seems to be missing here.
Can you do CPU and Memory limiting with this?
I wasn't able to figure it out from the documentation.
I know that jails do support cpu and memory limits (via rctl).
I know that jails do support cpu and memory limits (via rctl).