Cockpit Application in separate container

[rhwood]

Is it possible to deploy a Cockpit application in a separate container from the core Cockpit service? If not, should it be?

[garrett]

I think we already have this with the cockpit-ws container as mentioned at https://cockpit-project.org/running.html#coreos — and I know @martinpitt mentioned interest in improving Cockpit-in-a-container recently.

Additionally, depending on your use, we also have Cockpit Client, if you're intending on using the Cockpit container to connect to a remote host. Cockpit Client is a desktop app that lets you connect to a Cockpit service that doesn't need to have a port exposed — it just needs SSH access (and parts of Cockpit installed, but not necessarily listening).

[rhwood]

I think I need to clarify the question.

I understand Cockpit allows developers to write applications that can be added to the Cockpit UI (such as cockpit-podman). Is it possible to write one of those applications in a container and have (I think) cockpit-ws in another container add that application to the menu presented to a Cockpit user? Or would I instead need to maintain my cockpit app in the host OS (or container) running cockpit-ws?

[martinpitt]

As of current Cockpit 270 this is not possible, sorry. cockpit-bridge looks into $XDG_DATA_DIRS, i.e. /usr/share/cockpit, /usr/local/share/cockpit/, and ~/.local/share/cockpit by default (plus any other directory which you set in the system environment). You could do something like ship the cockpit application as a container, expose it to the host as a volume, and then point $XDG_DATA_DIRS to that (or tell podman/docker to bind-mount the volume from one of the default places), but IMHO that does not help you that much -- you'd still need to do some setup on the host.

We are currently starting the work on shipping the bridge and the cockpit pages inside the flatpak or the cockpit/ws container -- once that is finished, you could build your own cockpit/ws container that includes your page. But (1) that's still going to take a while, and (2) it still does not discover pages in other containers.

How would you envision this to work? There must be something on the host that can point cockpit-bridge to "look for pages in the container → over there", and that can only realistically happen through a volume shared on the host. At that point this might just as well be the already existing $XDG_DATA_DIRS. Or you deploy your application using git/rsync/syncthing/Ansible as plain directory copied from some primary source.

Do you have another idea? I'm all ears for that, how to make it easier/more practical for real-life admins to deploy custom pages.

Thanks!

[rhwood]

While having a shared space that all containers can write to is probably easiest when running but most complex when installing, I am thinking that if I am correct in assuming that a rootless container can connect to the system bus on the host, the following can work for discovery of apps:

• Configure cockpit-bridge and the containerized app(s) to communicate over the host system bus
• When the bridge (re)starts it sends out a "what apps are running" message on the bus and running containerized apps respond with "running cockpit app" messages
• When a containerized app (re)starts, it sends out an unsolicited "running cockpit app" message so a running bridge can learn of it

In the "running cockpit app" message, I'd include either the complete manifest contents, or some pointer that allows the bridge to get the app's manifest, as well as a pointer to the static app content (I thought that this pointer would be to a http URL that is proxied by cockpit-ws or cockpit-bridge, but seeing that rootless networking in Podman's security model is very different than networking root containers in Docker, I'm not sure how easy that would be).

[martinpitt]

assuming that a rootless container can connect to the system bus on the host

Connect locally yes, but (1) not from a different network namespace (i.e. from a container), and (2) not own a service there (that would need an explicit policy in /usr/share/dbus-1/system.d -- every owned service needs that). This might work with some hacks for user containers on the user bus, when running containers on the host namespace. So this would rather need some kind of "registry" REST service on the host where things can connect to and tell about their location.

But still, this feels like a solution in search of a problem: Why do you want to use a container to ship a cockpit page in the first place? This only introduces a lot of barriers like the above, when all that you really want is to put a directory somewhere. If that is somehow inconvenient, we can talk about supporting scanning of .tar or .zip files which bundle everything. But still, if you want to use the distribution mechanisms of containers, going via volumes and bind-mounts still appears a lot easier to me, and you can do it with the current versions without having to invent anything new.

[rhwood]

I asked this question while exploring how to manage an application that is delivered as containers and if I could reuse cockpit (i.e., just write a cockpit app), or needed to write a complete web UI of my own. It seems the complete Web UI may be the way to go unless I want to deliver the management piece outside a container (this is separate from the Web UI for using the app).

Thank you for the pointers towards understanding some of the security controls around dbus and containers.