Hacker News new | ask | show | jobs
by rapsey 941 days ago
> there's little need to SSH into the system in the first place (except for debugging purposes).

Pretty big except though.

This concept has been done multiple times and has always failed. It's solving a problem that few care about.

4 comments

In the kind of corporate environments I work on, you won't be doing any SSH into the production containers.

Nothing that a classical UNIX admin would expect is installed on those images.

... we had to wait for k8s 1.25 to get ephemeral containers to get some tools ... (https://kubernetes.io/docs/tasks/debug/debug-application/deb...)
Those kind of corporate environments would also never use a technology like MirageOS that very few people know how to use.
In those kind of corporate environments liability is a concern, and something like MirageOS would be quite appealing.

These are the same kind of environments where CI/CD can only fetch from internal repos, where stuff only gets installed after IT and legal had a say on it.

Sure they would. I've be interested in Mirage and I don't believe that developers should have SSH access to systems.

I could see the value in a debug port or something, though. But giving full remote code execution is total overkill.

Yes. Welcome to the hell of "No debugging, no fixing anything. Call vendor support and hope for the best"
It is more like, what isn't there can't be used for CVEs.
I haven’t SSH’d into a machine/container to debug or fix a production issue in years. You flat out can’t even SSH into anything on the last few prod setups I’ve worked on: permissions prevent it, and most containers have sshd and friends stripped out.

I would love a super slimmed down stack to run workloads on. Most of the time when I run workloads, I want to run the workload and nothing else. The OS in the container exists to start the binary I care about and then basically very little else-these applications aren’t making use of a scheduler, or the init system (because again, I’m only running my binary), users and permissions go unused a good chunk of the time. With stuff like quic becoming more popular we’ve got user space networking too, so that’s out. So by this stage we’ve got a whole OSCthats doing almost nothing except passing stuff between layers an incurring a performance and risk overhead.

If we could have the same functionality, with better performance and the same or better security, why wouldn’t I do that?

> This concept has been done multiple times and has always failed

Isn’t it likely that this idea was just “before its time”? The compute landscape these days is pretty different to ~20+ years ago: massively available public cloud compute, prolific container usage, etc. Software stacks are deeper, more ossified and less fully understood than ever, I definitely see solutions that reduce that complexity being appealing.

What schedules your threads?
exactly this, debugging is a pretty big part when it comes to operational aspects.

but I feel like similar to kubernetes container injection systems. I suspect in future we would see dynamic injection into the unikernel where you can enable debugging environment instantly.

like the library unikernel exposes a plugin system that you can inject in future, this way the unikernel is lightweight and only gets bloated when you eventually want to debug something.

What you already can do is attaching gdb -- either live or at a core dump. Please see https://github.com/Solo5/solo5/blob/master/docs/debugging.md for detailed instructions ;)

What you as well can do is record-replay -- well, at least there used to be this option, I'm now lost whether it has never been merged anywhere, or it is stuck in some PR somewhere. This was truly great - since the external interface is so thin, it is easily doable to dump all external events (API calls and returns) onto disk and replay one-by-one, inspecting the state.

actually I think this might be the intention of mirage as well, especially since they put "modularity" in the title
> It's solving a problem that few care about.

Security?