As Jamie you suggested, this is a copy-paste of Jamie’s feedback:
“The docker interface is reserved for snaps that the ability to control all aspects of docker containers on the system which therefore grants device ownership to the snap. If the access is required, consider using a brand store or create a forum topic at https://forum.snapcraft.io/ using the ‘store-requests’ category if this can be discussed in public or the ‘sensitive’ category if the discussion should remain private. Please feel free to copy and paste this message in the topic. Thanks!” — Jamie Strandboge
The access to docker is required because:
The alero-connector composed from two main parts, cli tool and a service.
The service part is currently planned to be deployed as a docker image that run in a docker container.
The alero-connector snap performing the docker pull and the docker run commands, this is the reason why this snap needs the docker interface.
If there are better alternatives, I will be happy to consider them.
I think this is the crucial expectation of the docker interface. In your case, if I understand correctly, you only want to distribute your application as a docker image, which is the reason why you request the docker interface; but wrapping a docker image in a snap seems redundant, since for applications, they provide many of the same benefits and features.
Perhaps your application could be repackaged as a snap for distribution? while it’s not a very direct translation, the Dockerfile should give a good starting point for a snapcraft.yaml and bundling your app and dependencies as a snap.
I’m -1 to granting docker to an application for the sole purpose of having it distributed as a docker image that the snap pulls since the powers granted by the interface have wider implications than that.
The issue is that its not a simple application which we currently have packaged as a docker image to distribute. If the current docker image wasn’t as complex, we certainly could do it all via snap.
The reason we want to stay with the docker image is because we are concerned about maintaining the current complexity inside the image on different distributions. There are multiple services - each with different dependencies which would require OS specific configuration and customization on different distributions. Docker allows us to avoid this concern completely via the fully virtualized OS offered via docker. (and not available via snap)
We do however, want to use snap in order to bring different components which could not easily be wrapped via one docker image to the host machine. We are aware that it could be done fully within docker, but it would come at a cost to our users who would then be required to access the container inside of docker, in order to get to the CLI.
Our idea, was to use snap to help bring java, the CLI(jar), and docker using one easy command for our customers. But still leave them with a cleaner user experience - by utilizing snap.
Let me know if something here is unclear or it would help for me to elaborate further.
What kind of customization do you require? You can order services to run after others and do other kinds of configuration today with daemons, using various settings in the snapcraft.yaml. If we are missing features here, it would be good to know what you need in order for what we expose to be useful.
What aspect do snaps not provide in terms of isolation from the host OS? Your snap will run on an Ubuntu based root filesystem no matter what the host OS is, same as if you were using a docker image based on Ubuntu.
