Allow Docker Manager to rebuild container and install plugins

AI-generated summary

A discussion is underway about enhancing Docker Manager to rebuild containers and install plugins. hunterboerner initiated the conversation, highlighting the current manual process as “messy” and “confusing.” ichpen and cdesch expressed interest in the feature, but riking raised concerns about potential security vulnerabilities and layering violations.

sam proposed a long-term plan to develop a separate, low-impact daemon for Docker Manager, which could provide a recovery mechanism in case of a site crash. The choice of programming language for the daemon is being discussed, with hunterboerner suggesting Haskell and sam emphasizing the importance of a “tiny” memory footprint and easy maintainability. chapel pointed out that Go could be a suitable option due to its small runtime requirements and easy binary installations.

It would be nice if docker manager could handle rebuilding the app and installing plugins. Both of these things currently require sshing into the server and manually editing a config file which feels very messy and is confusing for a lot of people.

Is this possible?

6 Likes

I second this feature request. Plugin management needs some love.

This would be nice but I think it might be tough because the container needs to be rebuilt to integrate the changes from the plugin.

It’s also a bit of a layering violation, and would require either a suid root binary to be available inside the container to de-chroot and de-namespace, or a constantly running daemon outside the container (again as root) ready to rebuild when asked. And I certainly don’t trust myself to avoid writing a confused deputy vulnerability.

My long term plan is to write a separate, mini-daemon for docker manager (probably in golang or something else that is very low impact). That way you can always recover from a crashed site.

This is on the cards but not scheduled and very complex.

2 Likes

Haskell? It’s much less verbose than go.

This is a long long term discussion, nothing is going to happen for a bit, but the key is “tiny” amount of resident memory and something we can maintain easily.

It’s possible we could pull this off with frameworkless rack, or even have NGINX trigger a launch of it on demand.

The point is something small at runtime and and Go also has the benefit of easy binary installs.