How are porter mixins able to affect the host machine?

[richbai90]

From all the documentation I have read, Porter works by bundling all the tools and commands into a utility container. Those commands then are executed from inside that container to deploy the application in whatever way is required. What I am having a difficult time wrapping my head around, is how these mixins can affect the machine they're running on. For example, if I want to deploy a simple docker-compose application, I could use the docker-compose mixin. At build time, all the docker images required are downloaded and added to the bundle, along with the docker-compose tool itself. When I deploy the app on my host server, do I have to set --allow-host-access to true for the bundle to deploy these containers on the host and not inside the utility container? Then in general, is it fair to say that the mixin has to provide a strategy for declaring the appropriate behavior at deployment time, and if host access is required, --allow-host-access must also be set to true?

[carolynvs]

The bundle and its mixins only have access to what the user explicitly provides when they run the bundle, either through parameters, credentials or in the case of docker, the --allow-docker-host-access flag. It is up to the bundle author to declare what's needed by the bundle through those mechanisms.

For bundles that require access to the docker host (usually because they are using the docker or docker-compose mixins), the bundle author should call that out by adding the following lines to the bundle. This tells porter that the bundle requires docker access, and porter will then help prompt the user to specify that flag. Right now porter doesn't have a way for the mixin to directly communicate this to Porter, so the bundle author needs to remember to do it.

required:
  - docker

docker-compose readme

[richbai90]

Thank you, that makes sense. One follow up, is it possible to directly modify the host through a bundle ala bind mounts for example? I saw another discussion #1823 that references this idea, but no follow-up that I could find.

[carolynvs]

Bind mounts are still not supported unfortunately. Porter was originally designed to deploy to remote environments and isolation from the host (which we assumed was a CI server) which is why we have a bit of a gap in this area. Right now Porter works best when you provide the bundle credentials to connect to a remote environment to perform a deployment.

We aren't against the bind mount suggestion but it would need more design and vetting before it would be ready to implement.

[richbai90]

Understood. The challenge in my case is that I support a customer trying to migrate to a high availability deployment model, but they have many legacy apps not designed to work in the cloud. I have found a work around for now. Using the --allow-host-access command I can run a version of this docker command to get root shell access on the host machine

docker run -ti 
    --privileged 
    --net=host --pid=host --ipc=host 
    --volume /:/host 
    busybox 
    chroot /host

It's a hack to be sure, but it works for my use case.

[carolynvs]

I'm glad that you found a workaround! Thanks for sharing it.