Is it possible to get the reference to the invocation image via a porter template variable?

[bherw]

Hi, I have a usecase where I want the installer to perform some actions on the host filesystem via bind mounts, configured using porter parameters. The installer image doesn't run with any bind mounts, and I can't add any new ones once the container is up, so my solution was to add an install step which runs docker with the configured bind mount, and perform the actions inside that.

I really only need a shell to perform these actions, so I'd like to reuse the invocation image if possible, for example by running {{ bundle.images.invocationImage.repository }}@{{ bundle.images.invocationImage.digest }}. I could take the reference as a parameter, but I'd like to avoid adding additional coupling. Another solution would be to bundle a busybox image just to perform some additional actions.

[carolynvs]

We have a template variable {{bundle.invocationImage}} but I just tested it out and found some bugs. We totally should fix those bugs but it would be even better to just support what you are trying to do without workarounds. I think other people would like bind mounts as well.

I would be open to adding the ability to do bind mounts (for the v1 prerelease) if you'd like to help design how that should work. We already have a config setting allow-docker-host-access that controls if we allow the bundle to do things like connect to the docker socket.

What we would need to figure out a few things:

• How does the bundle communicate the mounts it requires? e.g. Does porter inspect the invocation image and look for declared volumes?
• How does the user specify what to mount? Would it make sense to have it be a special type of parameter, that they could set with --param or by passing a pre-defined parameter set?
• Is this something that should be separate from the allow-docker-host-access config setting or do we think it's safe to roll into the existing setting?

[bherw]

The ability to bind mount directly into the installer would be really helpful, thanks! I recall some other use-case that involved using a temporary docker container to setup initial volume contents that would probably be better modeled as installer steps as well.

https://porter.sh/authors/templates/ says that {{bundle.invocationImage}} is deprecated, so I thought it was going away soon.

I can certainly help with the design, at least from the point of view of my use-case.

How does the bundle communicate the mounts it requires? e.g. Does porter inspect the invocation image and look for declared volumes?
Perhaps, but this seems overly complicated:

• Usually porter is constructing the invocation image for us.
• It would split up the list of inputs between the porter.yaml and invocation image Dockerfile, reducing readability
• Docker lets us mount volumes and bind mounts without specifying a VOLUME declaration.

How does the user specify what to mount? Would it make sense to have it be a special type of parameter, that they could set with --param or by passing a pre-defined parameter set?
A new parameter type (or perhaps two, one for file, one for directory) makes a lot of sense to me. We already have a file parameter type which, if I understand correctly, copies a file specified by --param to a target file in the invocation image. The bind-mount parameter(s) could be a similar, but more powerful parameter type, which allows a rw/ro bind-mount of a directory or file specified by the user to a target path in the invocation image.

Using a parameter type would allow use of the usual template mechanism to pass the path of that bind mount on the host on to some mixins in the install action, for example to a docker-compose mixin which wants to mount some volumes based on the user's requested location on the host.

For what it's worth, right now I'm simply passing in a "string" parameter which is named and documented as a directory path bind-mount parameter. Until today I was simply passing it along to docker-compose since I didn't need it in the installer. A type-checked parameter could be useful even if it isn't used in the installer directly.

Is this something that should be separate from the allow-docker-host-access config setting or do we think it's safe to roll into the existing setting?

allow-docker-host-access is extremely powerful; with this the invocation image can run docker containers as privileged, and can effectively do anything root on the host can. Letting the user explicitly give the invocation image read-write access to some directories or files on the host using a parameter seems a lot more limited to me. It is a form of host access, but given its limited and explicit nature I'm not sure if it should require allow-docker-host-access. Perhaps it could require some other, less powerful permission in addition to the --param /host/mount, though I'm not sure if even that is necessary.