I wonder if I'm misunderstanding. Why would I want install, uninstall, etc. type actions running in a Docker container? Isn't that going to encourage people to spin up production environments that aren't reproducible?
I'm not very familiar with Ansible, etc., so maybe tools like that have strategies for building deterministic environments, but I can see a lot of people putting `apt-get` or `yum` commands in an install script.
CNAB makes reproducibility possible by providing unified lifecycle management, packaging, and distribution. Of course if bundle authors don't take care to work around problems with imperative logic, that's a risk. In practice, we see declarative models for building bundles offer more reproducibility.
Yeah. I read through some of those existing configs and I see how it works now. My first instinct when I see `cnab/app/run install` is to think it's for installing the app, but now I see it's for provisioning / deploying to the environment. As soon as I think of install, uninstall as deploy, undeploy then it clicks for me.
We may want to discuss changing the keywords from install/uninstall to be deploy/uninstall if that helps signal to the user the intent behind those actions. That's great feedback, thank you!
The goal with CNAB is to be able to version your application with all of its components and then ship that as one logical unit making it reproducible. The package format is flexible enough to let you use the tooling that you're already using.
I'm not very familiar with Ansible, etc., so maybe tools like that have strategies for building deterministic environments, but I can see a lot of people putting `apt-get` or `yum` commands in an install script.