Feature Request: Support for thin, mutable app bundles
kinghuang opened this issue · 9 comments
Description
#432 introduced a change to forbid variable substitution on image fields. This is designed to support the creation of thick CNAB bundles, where the bundle contains all of the images referenced in the bundle descriptor (see Thick and Thin Bundles). To accomplish this, images cannot be specified with install-time parameters.
This behaviour is useful when the goal is to produce a immutable release of software. However, when I'm building a bundle, my goal isn't always to create a release of software. For me, there are two major use cases where thick, immutable bundles are not desirable.
Use Case 1: Configuring and Deploying Third-Party Software
I have created Docker Apps using docker-app v0.6.0 containing configurations of third-party software images such as confluentinc/cp-zookeeper and confluentinc/cp-kafka. In this scenario, I am not interested in storing and distributing the images produced by Confluent in my Docker Apps. Instead, my goal is only to distribute configurations of services, volumes, networks, etc., for use in local swarms.
Use Case 2: Running Apps for Development and Review
For software that we produce, we often have several image variants for non-production purposes. For example, the final image for a microservice only contains the binary for the service. But, there are other variants that include the build tools, mock responses, and proxied responses for use in development, testing, and debugging.
A public example of this is traefik. Its images tagged with just the version number (v1.7.10) only contain the traefik binary. While, the alpine tags (v1.7.10-alpine) have the binary on top an alpine base for debugging use.
With docker-app v0.6.0, we can easily take the bundle that's used for production deployments and swap out specific images with variants. Forbidding variable substitution makes this impossible.
Proposal
Docker App should provide an option to produce thin bundles that don't include images, similar to docker-app v0.6.0. For thin bundles, variable substitution on image fields should be allowed.
@kinghuang thanks for the feedback. We are aware of this limitation, and it is actually a behavior that we want, for publishing: we want a published application to be actually immutable down to service images.
however, we have some ideas to add some flexibility:
- add support for buildargs: build args are a category of parameters, that are resolved when creating the CNAB bundle. That means, you can set them when working with docker-app sources, but once the package has been pushed as a CNAB in a registry, they are not overridable anymore. We are not sure yet about the user experience, but that might be done purely by convention (eg. every parameter prefixed with
buildargs.would be considered as a build-time parameter). This is quite symetric with Dockerfile buildargs. - add a new yaml file in the package
images.ymlproviding a library of images consumable within the compose-file: that means we will allow either statically defined image names in the composefile, or parameterized one, but we would restrict parameter values to names defined in thisimages.ymlfile. Thisimages.ymlfile would also pave the way to define "image cooking rules" so that we could introducedocker app buildand various developer-oriented features.
I think that for use-case 1, this immutability guarantee makes sense, as a configuration written for a specific version of a 3rd party software might have subtle (and unwanted) different behavior with a different version. (solution 2 described above might be interesting for this case, like being able to provide an exhaustive list of versions tested and validated for your package).
For use-case 2, solution 1 might be ideal (developers being able to leverage build-args to replace a production image with an instrumented image for debugging)
We are also interested in other ideas that could bring flexibility while still guaranteeing the level of immutability we want for published applications.
I agree that that bundling the images is desirable when publishing software, and I'm really looking forward to that. However, what docker-app 0.6.0 also provides is an efficient way to publish Docker stack configurations. In the latter case, I really don't want to include any images with the built app, and would like to allow service images to be dynamically specified at install time.
I'm quite worried that the changes for the next release of docker-app are going to make it unusable for almost all of my use cases, except for the final step of publishing a finished app. Beyond the two major use cases I provided above, the inability to produce thin bundles will also dramatically increase the cost of my CI workflows for feature branches. And, the inability to arbitrarily swap out service images eliminates the use of generic apps for common projects.
I think what's needed is the ability to produce different types of Docker App bundles. One is the thick, immutable type that the latest code produces. Another, is the thin, mutable type.
For those use case, would it be ok to work with a docker-app in its source format (instead of shared trough a registry)?
If the app itself is being worked on, then yes. But, for the most part, the answer is no. If I'm working on a service repository and I have to separately get the source of a Docker App instead of being able to pull it from a registry, then I might as well go back to the old system using Docker Compose to render out configs and calling docker stack deploy … with environment variables.
I'm happy to jump on a call or chat to discuss this in more detail, if it would help.
The title of the feature request prevented me from finding this, and I created a similar issue. The image variable restriction has broken our dockerapp files, which allowed for identical configurations against similar images.
Our primary repository is Docker Hub for our dockerapp files. We specifically need to be able to push the images with variables there still to avoid breaking our use case, the to be able to use render and inspect to use them as docker compose files. Otherwise you’re requiring us to write a wrapper around Docker App which would allow use to replace the image name with another name.
I’m not exactly sure what the CNAB requirement is that forced the introduction of this change, but we need some kind of override to this restriction to keep working as we would expect.
@jhrabi Sorry about the potentially confusing issue title! I originally reported the same problem as you in #481 about the inability to override the image with parameters. There's some details there about why this change was made in Docker App.
After reading through the CNAB specification, I've come to realize what I want is for Docker App to be able to produce thin bundles with mutable images, in addition to the thick bundles with immutable images that the 0.8.0 release implements. That's what this feature request focuses on.
Would this feature would ever get implemented? Our company had built some features around v0.6 which is the one on the main page of this repo to find out the released version with docker-ce-cli was v0.8 and it broke our usecase for the docker-app completely.
Hello @omidyoosefi we hear your concern. We have now reached the release candidate step in the release process, and can't unfortunately add more features. We are definitely working on this subject for the next release 👍
As many users reported about feature degradation that tied to the unavailability to changes the image name in the docker-compose.yml - we also suffered from it.
We also used that feature to generate bundles with different container image names for different environments. Now we are forced to use the old release.
Is there any way to have multiple environments that differs only by image name?
Is there any way to implement the mutable bundles feature soon?