Add Initialization Phase (Pre-Start)

[davejohnston]

Description The application I am working on requires some secrets e.g. we generate some auth tokens that are stored as docker secrets and utilized by services in the stack.

Because secrets are dynamically generated, and they need to be created before the services start, this means our deployment is split into 2 phases

1. Initialization - generate tokens + certs and store as secrets
2. Startup - start the services that bind to secrets

A nice enhancement would be to add an initialization phase to the docker-app, with hooks to support this kind of work.

[simonferquel]

Hi @davejohnston, I really like the idea. It needs to be designed in an efficient way though, so that it is easy to work with. My guesses as different options we can investigate:

• CNAB composition: add the ability to add pre-deployment CNABs that will be invoked as part of the docker-app deployment
  • something that we want to enable for some time
  • some tricky parts: where should I run the sub-cnabs invocation images ? (could be resolved with additional credentials). How do we merge CNAB parameters ? (can introduce some weird semantics)
• Init container: add the ability to run a container before the actual stack is deployed
  • Tricky parts: where should we run the image ? (require additional credentials to connect to a docker daemon)
• Invocation image customization: Provide a way to customize the CNAB invocation image to inject some "mix-ins" in it
  • certainly more user friendly (no secondary image to run)
  • constraints over mix-ins (executables must be capable of running in our base invocation image)
• purely declarative
  • identify common pre-start scenarios, and implement them in the docker-app code base
  • certainly the most user-friendly case
  • but far less flexible (we might want to enable scenarios such as "provision a cloud-managed database" that might not be possible to maintain within the docker-app code base)

[davejohnston]

@simonferquel thanks for the quick response. Yes, I agree solving in a generic way that works for most use-cases could be tricky.

Rather than a 'init container' could it be an 'init template'. That would give us a certain amount of flexibility. There would need to be some notification system - or perhaps just a 'ready' endpoint to indicate when the first template was done/ready, prior to starting the main application.

I could see a lot of use for this - especially around initializing identity services or secret stores, ingest proxies etc for stand-alone apps. These are the kind of things that form the foundation for a lot of other apps, but there is a good separation.