docker-compose deployed as Device Profile, and packaged with container images?

[NeilCondon]

I'd like to propose an enhancement that uses the C8y's "Device Profile" function to manage containers with a docker-compose (or similar orchestrator of multiple containers/services). In other words, could we treat the docker-compose.yml as a "configuration file", rather than a "software", and combine it with container images deployed as "software" elements.

This would overcome a limitation that exists with the current approach - that containers referenced in a docker-compose.yml can only be instantiated by retrieving them from a container registry (hub.docker.com or similar), and not from the Cumulocity software repository. It would help users who's thin-edge devices cannot access the general internet (maybe they can only access the C8y platform), and do not want to deal with the complexity of setting up and managing their own private container registry alongside C8y.

Maybe this means that we'd need a new software type "container-image" - with it's own sm-plugin, who's role was simply to install the image, but not not to run it (as the "container" plugin does today)? Containers deployed in this way would only be run by docker compose, and not as standalone services?

[reubenmiller]

Thanks @NeilCondon for the ticket. This is definitely something that will be interesting to explore, though I believe there might be another way to solve it rather than using configurations. Configuration have the downside that you have you can only deploy 1 docker compose per configuration type. This mean that every time you want to extend the number of deployed docker compose files, then you have to deploy a new c8y-configuration-plugin.toml file which includes the new variants.

Alternatively we could just provide a new software type which just imports the docker container (packaged as a tarball), and then the container-group (aka docker-compose.yaml) file can reference the local images. The tarball use-case is already supported however the current behaviour is that the container will be executed using docker run ... (which is not intended in this use case)