Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support spawning containers through Kubernetes API

See original GitHub issue

Feature Suggestion

Hello all. At my place we’ve been looking into using backstage and have just bumped into something (sorry if this has been discussed before).

Several plugins (eg techdocs and the scaffolder) work by spawning external processes, with the choice of running either locally or with Docker. Running locally is fine in development but it’s not ideal if your API server gets OOM-killed because techdocs had a lot of work to do; running in Docker is better in principle, but because Backstage talks directly to the Docker agent, it’s not ideal if you’re running in a modern cloud environment (ie Kubernetes). The API server would have to be run as a privileged container which is a security nightmare.

What would be nice is if it also supported spawning these subprocesses by talking to the Kubernetes API. This would obviously be a complicated thing to implement, but would bring it in line with how other things are typically run nowadays.

Possible Implementation

An implementation might create a Job in a given cluster and namespace that runs the subcommand, and watches until the job is complete, then doing whatever final necessary steps.

A significant complication is with storage - the current implementation uses Docker mounts to extract file output. Doing the equivalent with k8s storage APIs will involve code gymnastics of some sort.

Maybe this would also present an opportunity to centralise the ‘runner’ functionality (which is largely duplicated between different plugins at the moment AFAICT - eg, here and here)