Unfortunately, systemd/nspawn does not benefit from the hype Docker garners, despite being infinitely better. This industry is becoming more and more hype and cargo-cult driven, instead of making sane technological choices
Being easier to try, having clear documentation/marketing, and having a bigger community are also forms of "better". If something is so infinitely technically better then winning is "just" a matter of creating on-ramps to ease its adoption.
Only if one sets the bar quite low, and has very lax standards for doco. Unfortunately, people often do set the bar low in the Linux world. But to those from other worlds the descriptions that come to mind are "acceptable" and "mediocre". As people have pointed out passim over the years, the expected as the norm quality of doco for the worlds of the BSDs and the commercial Unices is noticeably a higher standard than in the Linux world. By those standards, "second to none" is most definitely an exaggeration.
Sadly, "treated as an afterthought" is all too often still applicable, as well; this also being a disease of Linux doco that it hasn't wholly shaken off. The culture of updating the doco in lockstep when the software changes hasn't really taken a firm root, alas.
Just one example of such doco problems is a systemd issue where the doco does not tell the the issue raiser that the entire basis for the issue is wrong. Users have to resort to finding commentary hidden in the source code. Raised as a documentation issue, it requests a documentation change to warn users of something that is not in fact the case at all. Ironically, the true doco issue is actually that it is deficient, and the correct doco change would be to move the commentary into the manual where users can easily see it.
Can you give an example of a better-documented open-source project that is less than 5 years old and has the same level of complexity of the systemd family?
Genuinely curious, how is it "infinitely better"? I'm considering potentially switching away from Docker on my production boxes to something else, but I've mainly only heard about rkt when researching.
Put up a sentence or two of informative discussion, or links or any kind, this is not any kind of way to advance the state of a thread.
"Go on, try it" doesn't help me in any way. I believe that Docker has more attention, you might call it hype. I'd say "eyes" instead. We have here a way to shown to run everything in Docker, parent link of thread (RancherOS.) That's great, I already went ahead and tried it. I'm still waiting to be convinced that I should try nspawn instead.
Without your help, I won't even know what OS Distro I can download to try it, let alone why it's better.
This hasn't always been so, as historically a kernel patched to support aufs was a requirement. It's easier to install docker in 2017 as much of the plumbing shared by the container ecosystem (including nspawn) has become ubiquitous.
I was fishing for an example of any OS or orchestrator that uses systemd-nspawn.
[1] shows me how to run systemd-nspawn by itself.
[2] shows me that it's basically just like chroot when it comes to a user experience.
When do I get to the part that's better than the entire ecosystem of schedulers and orchestration tools that has sprung up built on and around Docker? Are all of those companies wrong? (Are you trying to tell me it's all just hype and I should put everything into the hands of one competent sysadmin that manages nspawn and systemd?) I could be convinced of that, but I just don't see anyone doing that. I guess that's actually what was meant by cargo cult.
This all really just makes me want to go out and spend some more time looking at Rkt instead. We're all not even remotely convinced that this is better. Where is the mantl.io built on systemd-nspawn?
Well, between a good technology with a lot of hype and a better technology with no hype except for a few condescending people, how am I supposed to chose the latter? Tell me.
I just read the ArchWiki page on systemd-nspawn[1] and I fail to see how it is any better by the way. It just looks way harder to use (Docker images vs packages, scripts and per distro instructions ; docker create, docker start, docker ps, docker logs vs pacstrap, systemd-nspawn, machinectl, journalctl) and honestly not very different technically. systemd-nspawn just looks like a less user-friendly Docker to me.
Would you prefer if all those command were prefaced with `systemd`? Because that's all there is to it do docker in your example then.
You're seeing condescension where there is none. I'm just pointing out facts. It's okay, Docker runs on hype, and apparently so do you. But then, I can't expect Red Hat to invest into advertising for a core system component, because developers ought to be aware of it.
nspawn also offers faster startup time, better integration with cgroups and chroot jails, etc.
>Would you prefer if all those command were prefaced with `systemd`?
Well, I'm fine with journalctl and machinectl as they're part of systemd. I'm not really fine with having to install respectively arch-install-script, deboostrap+debian-archive-keyring, debootstrap+ubuntu-archive-keyring to run an Arch, Debian or Ubuntu container. What if I want to run something like CentOS or Alpine?
>But then, I can't expect Red Hat to invest into advertising for a core system component, because developers ought to be aware of it.
That's why Docker has the market. systemd is huge and scary, developers see it as a sysadmin only component. You cannot expect developers to know systemd without explaining it to them in a way they can understand.
>nspawn also offers faster startup time
Is Docker slow? Starting a container is usually instantaneous. Maybe the engine? For me it's managed with systemd and its weird socket binding, it's pretty fast too.. Fast is good but I can't remember thinking "wow docker is slow"
>better integration with cgroups and chroot jails
How? Why do I need this better integration?
- - -
I'm convinced there are not a lot of things Docker cannot do in comparison to systemd-nspawn. On the contrary, with systemd-nspawn:
- how do I spawn a container remotely?
- how do I share my "images"? is there an easy way to bundle the app I want to isolate? something at least kinda portable between Linuxes, so no .deb/.rpm
- can I include a file to my source code and tell my users something like "run docker build, then docker run and you're good to go"?
- my sysadmins just gave me the rights to run the docker command (we configured the user namespace so that I'm not indirectly root on the host), would it be that easy for them with nspawn?
- say I want a specific dependency, redis for example. Can I do something as simple as `docker run -p6379:6379 -v/data/redis:/data --name redis redis` or would I have to manually install the redis in the nspawn?
